L'actu cyber du jour

jeudi 12 novembre 2026

10 actualités, 40 sources. Chaque information est attribuée à ses sources d'origine : suivez les liens pour en lire le détail.

Lecture : 16 min

L'essentiel

Journée de vulnérabilités critiques en série : Apache HTTP/2 (CVSS 9.8, exécution de code à distance sans authentification), Red Hat Quay (9.8, prise de contrôle de la signature des jetons de registre), MongoDB (9.5), PTC Windchill (9.2), Zoom (9.6). Plusieurs de ces failles sont exposées sur Internet par défaut.
La supply chain reste le vecteur dominant : 4 837 comptes GitHub détournés ont poussé un voleur de secrets CI dans au moins 1 806 dépôts, et une campagne ScreenConnect a infiltré 288 postes dans 48 organisations en moins de 24 heures.
Le secteur MSP (prestataires de services managés) est attaqué sur deux fronts simultanés : N-central (Able2Shell, puis 4EverAble2Shell et Agent2Shell qui contournent le correctif du 10 novembre) et les extensions tierces de ScreenConnect.
L'IA devient à la fois une cible et une arme : des clés API Claude volées transforment Claude Code en implant télécommandé (démonstration en laboratoire), tandis que Symantec documente un attaquant ayant relancé une intrusion bloquée en basculant sur des commandes générées par IA.
Les données sensibles fuient par les interfaces IA : Notion confirme l'exposition de transcriptions de conversations Notion AI après le piratage de son fournisseur d'inférence Fireworks AI.
Tendance de fond : la cadence de correction dépasse la capacité d'absorption des équipes (1 259 correctifs Microsoft ce mois), ce qui déplace la valeur défensive vers la réduction de surface exposée et la rotation des secrets.

01 / 10CritiqueVulnérabilité

Apache HTTP Server : une faille HTTP/2 à 9.8 permet l'exécution de code à distance sans authentification

Concerné: Apache HTTP Server 2.4.55 à 2.4.70 avec le module mod_http2 activé (directive Protocols réglée sur h2 ou h2c, au niveau serveur ou dans un virtual host). Builds autonomes mod_h2 2.0.8 à 2.0.42. Red Hat Enterprise Linux 8 et antérieurs ne contiennent pas le code vulnérable.
Correctif: Oui. Apache HTTP Server 2.4.71 (publié le 11 novembre 2026). RHEL 9 : mod_http2-2.0.26-7.el9_9.1. La 2.4.71 corrige aussi un plantage dans mod_md (important) et un écrasement d'un octet en pile dans mod_vhost_alias (faible).

Ce qui s'est passé: Le module qui fait parler Apache en HTTP/2, la version moderne du protocole web, contient un défaut de gestion mémoire. Un attaquant qui peut joindre le serveur, sans aucun compte ni mot de passe, peut détourner le processus Apache et y faire tourner son propre code. Tous les sites hébergés par ce serveur deviennent alors compromettables, y compris leurs certificats TLS et leurs secrets applicatifs.
Ce que ça change: Exécution de code arbitraire avec les privilèges du processus web (souvent www-data ou apache), donc lecture des fichiers de configuration, des clés privées TLS, des identifiants de base de données, et pivot vers les systèmes internes joignables depuis le serveur. Sur un reverse proxy ou un frontal de mutualisation, l'attaquant touche potentiellement des dizaines de sites.
Ce qu'il faut faire: Inventorier tous les Apache exposés (y compris conteneurs, appliances et images de base non reconstruites), vérifier l'activation effective de HTTP/2 et non la simple présence du module, puis passer en 2.4.71 ou appliquer le paquet du distributeur. Si le patch ne peut pas être appliqué immédiatement, désactiver h2 et h2c dans Protocols. Surveiller les processus httpd enfants anormaux, les connexions sortantes inattendues et les écritures de fichiers dans les répertoires web.
Ce qui reste incertain: La réalité et la fiabilité de l'exploit public revendiqué par Red Hat ne sont pas confirmées par une source indépendante, et Wiz affirme l'inverse. Le caractère réellement exploitable en configuration par défaut sur les builds des distributions reste à établir.

Sources :thehackernews.com httpd.apache.org access.redhat.com

02 / 10CritiqueVulnérabilité / Attaque

N-central : des exploits contournent le correctif publié il y a deux jours et donnent root puis SYSTEM

Concerné: N-central On-premise, y compris la version 2026.4.1 HF2 (build 2026.4.1.26) publiée le 10 novembre 2026 pour corriger Able2Shell. Environnements hébergés par N-able déclarés non affectés par le nouveau problème.
Correctif: Partiel. N-able a corrigé les failles non authentifiées d'Able2Shell dans 2026.4.1.26, mais les nouveaux exploits fonctionnent justement contre ce build. La parade immédiate est la désactivation de l'API Legacy.

Ce qui s'est passé: N-central est une console d'administration utilisée par les prestataires informatiques pour piloter à distance le parc de leurs clients. Un chercheur mécontent du traitement de ses signalements a publié plus de 30 failles, puis deux nouvelles chaînes d'exploitation. La première, 4EverAble2Shell, donne une exécution de code à distance avec privilèges root sur le serveur N-central. La seconde, Agent2Shell, enchaîne plus de dix failles zero-day pour exécuter des commandes sur les machines Windows supervisées, avec les droits SYSTEM.
Ce que ça change: La compromission d'une seule console N-central ouvre l'accès à l'ensemble des clients du prestataire. L'attaquant obtient root sur le serveur central, puis SYSTEM sur les postes et serveurs managés, avec la capacité de déployer des rançongiciels, d'exfiltrer des données ou de désactiver les sauvegardes à grande échelle.
Ce qu'il faut faire: Désactiver immédiatement l'API Legacy sur toute instance N-central auto-hébergée et interdire son exposition sur Internet ; vérifier l'exposition via une recherche Internet en conditions autorisées ; rechercher les connexions sortantes vers 157.20.241.16 ; auditer les créations de comptes administrateurs et les commandes inhabituelles sur les agents Windows ; isoler les consoles d'administration derrière un accès nomade ou une liste blanche stricte ; suivre les avis N-able et watchTowr.
Ce qui reste incertain: N-able affirme que le problème dépend d'une configuration non par défaut (API Legacy activée et exposée). Cette atténuation est plausible mais ne couvre pas Agent2Shell, dont les conditions exactes de déclenchement restent débattues. L'ampleur réelle des compromissions chez les MSP n'est pas connue.

Sources :thehackernews.com securityweek.com uptime.n-able.com github.com

03 / 10CritiqueSupply Chain

4 837 comptes GitHub détournés pour voler les secrets de chaînes CI dans des milliers de dépôts

Concerné: GitHub.com, dépôts accessibles en écriture par les comptes compromis, workflows GitHub Actions, paquets npm avec hook postinstall
Correctif: Sans objet (pas de vulnérabilité logicielle). Remédiation par révocation des identifiants et rotation des secrets.

Ce qui s'est passé: L'attaquant a utilisé des identifiants GitHub volés pour ouvrir, depuis une branche nommée wfx-docs, des pull requests au titre anodin « docs: dependency audit notes ». Ces PR servaient de test pour savoir quels dépôts le compte pouvait modifier : 61 764 dépôts ont été testés. Là où l'écriture était possible, un voleur de secrets a été ajouté au workflow, ou glissé dans un hook postinstall npm. Le code exfiltrait ensuite les secrets et les rôles cloud accessibles au pipeline, avant d'être annulé en quelques minutes et les journaux effacés.
Ce que ça change: Un attaquant récupère les jetons de déploiement, clés d'API, identifiants de registres de conteneurs et rôles cloud (AWS, GCP, Azure) auxquels les workflows avaient accès. Depuis un pipeline compromis, il peut publier une version piégée d'un paquet ou d'une image, donc atteindre tous les clients en aval. Le hook npm étend la compromission aux postes de développeurs exécutant npm install.
Ce qu'il faut faire: Révoquer les jetons, autorisations OAuth, clés SSH et sessions de tout compte ayant ouvert une PR de ce type, même si le voleur n'a pas tourné ; activer le 2FA ; faire tourner tous les secrets et variables lisibles par les dépôts touchés ; considérer les rôles cloud des workflows comme compromis et auditer CloudTrail ou équivalent ; durcir GitHub Actions (épinglage par SHA, permissions minimales du GITHUB_TOKEN, environnements protégés, interdiction des PR de forks en écriture) ; bloquer les hooks postinstall non nécessaires.
Ce qui reste incertain: Le mode d'obtention des 4 837 identifiants n'est pas expliqué par les analyses publiées. La part exacte des dépôts où le voleur a réellement exécuté n'est pas connue avec certitude, et les deux comptages (1 806 et 8 093) mesurent des périmètres différents.

Sources :thehackernews.com aikido.dev safedep.io helpnetsecurity.com

04 / 10CritiqueAttaque

ScreenConnect : des clients pirates installés sur 288 postes dans 48 organisations, avec propagation façon ver

Concerné: ConnectWise ScreenConnect, panneaux hébergés chez des partenaires, extensions tierces Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link, RMM+ Password Link
Correctif: Sans objet. Mesure de contournement : désactivation des extensions tierces concernées et des composants installés.

Ce qui s'est passé: Des attaquants ont pris la main sur des panneaux ScreenConnect (outil de prise en main à distance très répandu chez les prestataires) et utilisé la fonction d'exécution de commandes pour déployer un client ScreenConnect pirate sur les postes supervisés. Ce client crée une porte dérobée autonome, indépendante du panneau d'origine. Quand un technicien se connecte à une machine infectée, le malware remonte vers son poste, vole les sessions navigateur et les jetons d'authentification, puis rebondit vers d'autres panneaux auxquels ce technicien a accès.
Ce que ça change: Contrôle à distance persistant de postes de travail et de serveurs chez des clients finaux, vol de sessions permettant de contourner la double authentification, et propagation latérale d'un MSP vers ses clients puis vers d'autres MSP. La boîte à outils SCKit assure la persistance et la capacité de rebond.
Ce qu'il faut faire: Désactiver immédiatement les cinq extensions listées ; purger les clients ScreenConnect non approuvés sur les postes et les stations des techniciens ; rechercher les artefacts sckit-run.bat, sckit-decoder.ps1, TrapWatch.ps1, Panel-Lateral.ps1, Run-Lateral-Full.bat, runnew.cmd, ToolboxRelayUploader.exe, Sqlite3.exe ; bloquer les IP 185.99.255.28 et 155.94.150.39 ainsi que les domaines mo7sen.dev, payproofkit.com, cdn007-digitaldownloads.com, newnewnew.gotdns.org, Soxnewwork.homedns.org ; réinitialiser les sessions et jetons des techniciens ; exiger la double authentification résistante au phishing sur les consoles d'administration à distance.
Ce qui reste incertain: Le vecteur d'accès initial exact reste inconnu. Huntress penche pour des identifiants compromis ou des sessions d'opérateur détournées, mais ne l'a pas établi. ConnectWise n'exclut pas formellement une compromission de son infrastructure et dit poursuivre la validation.

Sources :thehackernews.com bleepingcomputer.com connectwise.com huntress.com

05 / 10ÉlevéeVulnérabilité

Red Hat Quay : une faille à 9.8 permet de forger des jetons et de lire les images privées d'un registre

Concerné: Red Hat Quay, déploiements où le service de gestion des clés de signature est joignable par des clients non fiables. Version corrigée non précisée dans l'avis.
Correctif: Inconnu. Ni l'avis ni le rapport Bugzilla n'identifient de version corrigée, mais des correctifs ont été fusionnés dans le dépôt GitHub du projet le 11 novembre 2026.

Ce qui s'est passé: Quay est un registre de conteneurs d'entreprise, le placard où l'on stocke et distribue les images applicatives. Le service qui gère les clés servant à signer les jetons d'accès est accessible à des clients non fiables. Un attaquant sans compte, quand l'accès anonyme est ouvert, obtient un jeton puis exploite les faiblesses de la rotation des clés pour installer sa propre clé de signature de confiance. Il peut ensuite fabriquer des jetons donnant lecture et écriture sur n'importe quel dépôt.
Ce que ça change: Lecture des images privées et donc des secrets qu'elles embarquent (identifiants de base de données, clés d'API, certificats), et surtout remplacement d'images légitimes par des images piégées que les systèmes en aval téléchargeront puis exécuteront. La clé malveillante peut être configurée sans expiration et survit aux redémarrages. La rotation des clés supprime au passage la clé légitime, ce qui peut paralyser le registre.
Ce qu'il faut faire: Restreindre l'accès réseau au service de gestion des clés aux seuls composants Quay ; auditer les journaux à la recherche de changements de clés non planifiés ; supprimer les clés non autorisées ; vérifier l'intégrité des images publiées récemment (signatures, digests) ; ne pas compter sur la désactivation de l'accès anonyme, car tout compte Quay valide suffit, ni sur la rotation des mots de passe ou des jetons robot, qui n'invalide pas une clé de signature non autorisée. Le constructeur prévient que l'attaquant peut réinstaller sa clé tant qu'aucun correctif n'est déployé.
Ce qui reste incertain: L'absence de version corrigée publiée empêche de confirmer quels déploiements sont réellement protégés. La condition exacte d'exposition du service de clés (topologie réseau, options de déploiement) n'est pas détaillée.

Sources :securityweek.com

06 / 10ÉlevéeIA & Sécurité

Notion : les transcriptions de Notion AI exposées via le piratage de Fireworks AI

Concerné: Notion AI (fonctionnalité Insights), fournisseur d'inférence Fireworks AI
Correctif: Sans objet

Ce qui s'est passé: Notion utilise Fireworks AI pour faire tourner des modèles de langage ouverts au service de ses fonctions d'IA. Les attaquants ont atteint les transcriptions des conversations Notion AI exploitées par la fonction Insights, qui sert aux clients à comprendre leur usage de l'IA. Moins de 1 % des espaces de travail sont concernés et la plupart des transcriptions ne sont rattachables ni à un client ni à un espace de travail. Le second incident de Fireworks est associé à la recrudescence d'activité de « LLMJacking », le détournement de capacités de calcul IA pour le compte de tiers.
Ce que ça change: Des secrets opérationnels saisis par des utilisateurs dans un assistant IA (mots de passe, clés d'API, données internes copiées dans une conversation) ont pu être lus par un tiers. C'est un rappel que le contenu confié à un assistant est traité par une chaîne de sous-traitants, chacun devenant une surface d'exposition.
Ce qu'il faut faire: Traiter les transcriptions comme exposées ; faire tourner tout identifiant collé dans Notion AI pendant la période concernée ; interdire par politique et par filtrage préventif le collage de secrets dans les assistants ; auditer les sous-traitants d'inférence IA (contrat, cloisonnement, journalisation, délai de purge) ; exiger le chiffrement et la séparation des données par locataire chez le fournisseur.
Ce qui reste incertain: Notion ne précise pas le nombre de clients touchés. Fireworks n'a pas détaillé comment l'attaquant a obtenu les identifiants internes lors du premier incident. Le lien exact entre le second incident et les groupes de LLMJacking reste une attribution de chercheurs, pas une confirmation judiciaire.

Sources :securityweek.com bleepingcomputer.com

07 / 10ÉlevéeIA & Sécurité

Des clés API Claude volées transforment Claude Code en implant piloté à distance

Concerné: Claude Code (agent de codage en ligne de commande), fonctionnalité memory stores de Claude Console, API Files d'Anthropic
Correctif: Sans objet côté vulnérabilité. Remédiation par rotation des clés et durcissement des postes développeurs.

Ce qui s'est passé: Les chercheurs ont créé un « memory store », ces fichiers texte attachés à un espace de travail Claude pour que les agents se souviennent d'une session à l'autre, contenant trois fichiers : un battement de cœur, une entrée pour les tâches et une sortie pour les résultats. Chaque nouveau processus Claude Code écrit son check-in, lit une tâche en langage naturel, l'exécute et publie le résultat. L'opérateur lit la sortie et écrit la tâche suivante. Comme les instructions sont en anglais courant, le modèle se charge de traduire l'objectif en commandes système.
Ce que ça change: Dans le test, un petit payload a trouvé Claude Code sur une machine Linux, récupéré les identifiants et posé un service systemd relançant l'agent avec l'option --dangerously-skip-permissions, qui désactive les confirmations d'outils. En neuf tâches, l'agent a cartographié le réseau, récupéré un mot de passe sur un partage FTP anonyme, généré 190 noms d'utilisateur candidats, pulvérisé le mot de passe contre le contrôleur de domaine, trouvé le compte correspondant, listé les partages SMB, téléchargé un fichier de 1 Go, l'a découpé en trois et l'a envoyé via l'API Files. Tout le trafic est passé par api.anthropic.com, l'adresse que l'agent appelle normalement, donc il ressemblait à un agent de codage au travail.
Ce qu'il faut faire: Traiter les clés API d'agents comme des secrets de production (coffre, rotation courte, portée minimale, surveillance de la consommation) ; ne jamais laisser d'identifiants de développeur en clair sur un poste ; interdire --dangerously-skip-permissions en dehors de bacs à sable jetables ; journaliser et corréler les appels aux API d'agents (volumétrie, heures, taille des uploads) car la destination est légitime ; cloisonner les postes de développeurs et limiter leur accès réseau latéral ; alerter sur les créations de memory stores et les uploads volumineux vers les API de fournisseurs d'IA.
Ce qui reste incertain: La transposition de cette technique à d'autres plateformes d'agents (mentionnée par les chercheurs) n'est pas démontrée publiquement. Le risque réel dépend de l'hygiène des postes développeurs, non mesurée ici.

Sources :helpnetsecurity.com

08 / 10ÉlevéeVulnérabilité

AMD Turin : trois failles de canal auxiliaire permettent de lire la mémoire d'autres processus dans une VM

Concerné: Processeurs AMD EPYC de 5e génération (Zen 5, nom de code Turin). Séries de machines Google Cloud C4D, N4D, H4D, Z4D et G4, y compris les instances bare metal C4D et Z4D.
Correctif: Oui, côté logiciel. Il faut le correctif du système d'exploitation invité, puis un arrêt et un démarrage de la VM (un simple redémarrage de l'OS ne suffit pas, selon Google). Google a déjà appliqué des atténuations pour les attaques entre VM et entre VM et hôte.

Ce qui s'est passé: Trois défauts de type « Transient Scheduler Attack » exploitent la façon dont le processeur planifie spéculativement les tâches. Un attaquant qui exécute du code sur le même cœur physique qu'une victime peut déduire des données appartenant à d'autres processus, voire au noyau. Deux de ces failles étaient connues depuis juillet 2025 sur des générations antérieures ; AMD indique que Zen 5 est « impacté différemment » et le projet Xen note qu'AMD affirmait auparavant que Zen 5 n'était pas vulnérable à TSA-SQ et TSA-L1.
Ce que ça change: Dans un cloud public, la frontière entre locataires est en jeu. Si l'atténuation entre VM et hôte tient, le risque résiduel est interne à une VM : un processus compromis, par exemple un conteneur mal isolé ou un code tiers exécuté dans la même instance, peut espionner les autres processus de cette instance et en extraire des secrets (clés, jetons).
Ce qu'il faut faire: Appliquer les mises à jour noyau des distributions supportées, puis programmer un stop/start des VM Turin concernées ; vérifier après coup que les mitigations sont actives (fichiers sysfs des mitigations CPU) ; pour les instances bare metal, appliquer les correctifs de l'hyperviseur ou de l'OS hôte ; réduire la co-tenancy sur les cœurs sensibles quand c'est paramétrable ; surveiller les charges anormales de type side-channel (consommation CPU étrange, timings).
Ce qui reste incertain: Les scores CVSS officiels n'ont pas été relevés dans les sources consultées. L'efficacité réelle des atténuations de Google contre une attaque intra-VM n'est pas quantifiée publiquement. Aucune preuve d'exploitation réelle n'existe à ce jour.

Sources :thehackernews.com docs.cloud.google.com amd.com amd.com

09 / 10ÉlevéeVulnérabilité

MongoDB : deux requêtes suffisent à faire tomber un serveur qui devient primaire (CVE-2026-118383)

Concerné: MongoDB Server, membres d'un replica set, y compris les membres shard et config server des clusters shardés. Un mongod isolé, hors replica set, n'est pas affecté. Toutes les versions antérieures d'une branche affectée sont concernées depuis sa première release. La branche 8.2 n'est pas listée parmi les versions affectées et est en fin de vie depuis le 31 juillet ; une preuve de concept publiée sur GitHub affirme toutefois que 8.2.12 présente encore le bug en laboratoire, avec un réglage réservé aux tests.
Correctif: Oui, versions corrigées publiées le 10 novembre 2026 pour chaque branche concernée (voir l'enregistrement CVE). Les clusters Atlas reçoivent la correction automatiquement lors de la maintenance.

Ce qui s'est passé: Il s'agit d'un usage après libération (use-after-free) : le serveur utilise une zone mémoire qu'il a déjà rendue. Un attaquant non authentifié envoie deux requêtes. Elles ne provoquent le plantage que si ce serveur est ensuite élu primaire alors qu'il lui manque encore des écritures récentes, par exemple après une panne du primaire en cours. Activer l'authentification n'empêche pas les deux requêtes d'aboutir.
Ce que ça change: Déni de service sur une base critique, au pire moment, c'est-à-dire pendant un failover. Un attaquant peut entretenir une instabilité et empêcher la reprise, sans avoir besoin du moindre compte. L'attaquant ne peut toutefois ni forcer un membre à prendre du retard, ni choisir l'élection, ni observer quand elle a lieu.
Ce qu'il faut faire: Mettre à niveau tous les membres des replica sets, y compris ceux en conteneur et ceux qui étaient hors ligne pendant la maintenance, puis vérifier la version réellement en cours sur chaque membre ; ne pas exposer les ports MongoDB sur Internet ; restreindre les sources autorisées par pare-feu et authentification mutuelle TLS ; surveiller les élections de primaire anormales et les redémarrages répétés ; pour Atlas, ne pas différer la maintenance.
Ce qui reste incertain: Le comportement exact sur la branche 8.2 (non listée comme affectée) reste contesté par une preuve de concept de tiers. Les versions corrigées précises par branche n'ont pas été recopiées faute de les avoir lues directement dans l'enregistrement CVE.

Sources :thehackernews.com cve.org mongodb.com

10 / 10ÉlevéeVulnérabilité

PTC Windchill et FlexPLM : une faille de désérialisation à 9.2 rouvre le dossier Cl0p

Concerné: PTC Windchill 11.0 M030, 11.1 M020, 11.2.1.0, 12.0.2.0, 12.1.2.0, 13.0.2.0, 13.1.0.0, 13.1.1.0, 13.1.2.0, 13.1.3.0, 13.1.4.0. PTC FlexPLM 11.0 M030, 11.1 M020, 11.2.1.0, 12.0.2.0, 12.1.2.0, 13.0.2.0, 13.1.0.0, 13.1.1.0, 13.1.2.0, 13.1.3.0.
Correctif: Oui. Les environnements hébergés par PTC sont déjà corrigés. Les installations sur site doivent appliquer le correctif sans délai.

Ce qui s'est passé: Windchill et FlexPLM servent à gérer le cycle de vie des produits et les nomenclatures dans l'industrie. La faille combine une validation d'entrée insuffisante et une désérialisation de données non fiables : une requête forgée peut amener le serveur à exécuter du code arbitraire. Ce type de défaut est particulièrement dangereux car il ne demande souvent aucun compte, et les serveurs PLM sont fréquemment exposés à Internet pour permettre l'accès des partenaires et fournisseurs.
Ce que ça change: Prise de contrôle du serveur PLM, puis accès aux plans, nomenclatures, secrets industriels et identifiants de fournisseurs. C'est exactement le scénario des campagnes Cl0p de 2026 contre le manufacturing, avec chantage à la triple extorsion : chiffrement, fuite, puis pression sur les clients et partenaires.
Ce qu'il faut faire: Appliquer les correctifs PTC sur toutes les instances exposées, y compris les environnements de test et les serveurs oubliés ; recenser l'exposition Internet des serveurs Windchill et FlexPLM et fermer ce qui ne doit pas être public ; rechercher les webshells JSP et les fichiers déposés dans les répertoires web ; surveiller les connexions sortantes anormales depuis les serveurs PLM ; segmenter ces serveurs du reste du SI industriel ; vérifier l'absence de persistance laissée par une exploitation antérieure de CVE-2026-12569.
Ce qui reste incertain: Les sources ne précisent pas si la faille est exploitable sans authentification dans toutes les configurations. Aucune attribution d'exploitation n'existe pour cette CVE précise, l'analogie avec Cl0p portant sur la faille précédente.

Sources :thehackernews.com cve.org ptc.com

Demain aussi

Suivez DecodeVox pour ne rien manquer.

L'essentiel de l'actu cyber en vidéo courte, chaque jour, sur vos réseaux.

Tous les jours du radar Flux RSS du radar