Le réseau des Campus Cyber s’engage sur une Charte commune quelques mois après la feuille de route d’actions communes adoptée début 2026.
Signée par les directrices et directeurs des Campus Cyber national et territoriaux, la Charte est soutenue par l’ANSSI, Cybermalveillance.gouv.fr et les Régions qui ont labellisé des Campus Cyber. Elle formalise les missions du réseau, ses principes de coopération et ses engagements dans la durée.
Un maillon territorial de la stratégie nationale
Les Campus Cyber se présentent comme des relais locaux pour faire le lien entre la stratégie nationale et les feuilles de route des régions. Ils s’engagent sur cinq axes :
Porter la voix du terrain : avec l’ANSSI et Cybermalveillance.gouv.fr, contribuer à concevoir des dispositifs nationaux adaptés à la réalité des territoires.
Anticiper NIS 2 : le croisement de données publiques a permis de cartographier les acteurs potentiellement concernés par la réglementation. Ces outils, ouverts à tous, offrent une première base de connaissance partagée pour bâtir des accompagnements sur mesure.
Étendre la sensibilisation : des alliances public-privé multiplient les points de contact, notamment par des actions itinérantes, pour que l’accompagnement soit accessible à tous.
Faciliter l’accès à l’offre cyber pour les TPE et PME : le réseau met en relation offre et demande par des parcours clairs, afin d’aider des dirigeants souvent perdus face à une offre abondante et peu lisible.
Outiller les prestataires locaux : en encourageant les solutions souveraines, les Campus Cyber soutiennent les prestataires en cybersécurité de proximité et leur apportent une meilleure connaissance du terrain.
Pour Vincent Strubel, directeur général de l’ANSSI, la Stratégie nationale pose le défi du « dernier kilomètre », c’est-à-dire toucher les organisations et citoyens les moins matures. Face à l’enjeu de généraliser les bonnes pratiques d’hygiène numérique, les Campus Cyber ont selon lui un rôle crucial pour proposer une offre accessible aux entreprises et collectivités des territoires.
Jérôme Tré-Hardy, conseiller régional de Bretagne, représentant du Collège des Régions du Campus Cyber et président de Bretagne Cyber Alliance, estime que la Charte formalise des actions très concrètes, dont certaines sont déjà menées par le collectif. Elle consacre aussi, d’après lui, le rôle des territoires dans la cybersécurité du « dernier kilomètre » et installe une dynamique d’acteurs engagés dans les régions au service de la stratégie nationale.
À partir de ses observations sur des incidents de sécurité, le CERT-FR détaille plusieurs faiblesses récurrentes dans la conception et l’exploitation des applications web. Ses recommandations portent autant sur la protection des données que sur l’authentification, la journalisation et la configuration des infrastructures.
Protéger les données stockées : le CERT-FR préconise le chiffrement systématique des supports, avec des clés gérées par des composants matériels ou des serveurs dédiés. Une erreur de maintenance chez un prestataire avait notamment exposé des données médicales.
Réduire les possibilités d’exposition : séparer les services par noms d’hôte plutôt que par chemins d’URL facilite l’application de politiques de filtrage distinctes. Les services d’administration inutilisés doivent être désactivés ou rendus inaccessibles depuis Internet.
Renforcer l’authentification : le CERT-FR invite à dépasser le couple identifiant-mot de passe, à surveiller le standard DBSC contre le vol de cookies de session et à envisager des mécanismes Zero Trust.
Améliorer la détection : les journaux doivent conserver les adresses IP sources, être horodatés à la milliseconde et s’appuyer sur une source de temps commune. Les règles de détection doivent aussi refléter la logique métier des applications.
Qui n’a pas son homologation RGS ?
Dans son dernier « retour d’expérience », le CERT-FR n’en dit mot. Il rappelle néanmoins que la démarche est obligatoire pour toutes les entités publiques…
En fait de retex, il s’agit plutôt d’une liste de préconisations agrémentée de quelques constats de terrain. Sujet : les violations de données dans le contexte d’applications web.
Les bonnes combinaisons pour chiffrer les disques
Le CERT-FR évoque le cas du fournisseur d’une solution de télétransmission de données médicales. Celui-ci a, en conséquence d’une erreur lors d’une intervention de maintenance sur un serveur, exposé des données de patients sur les sites qu’il concevait.
Cet exemple introduit une série de recommandations en matière de politique de gestion des données. Le CERT-FR conseille entre autres de protéger les supports de stockage contre l’extraction, y compris après usage. Moyen suggéré : le chiffrement systématique par une clé gérée dans des composants cryptographiques matériels ou par un serveur de clé. Sur Linux, on associera typiquement Clevis à LUKS pour lier le disque au TPM, avec un serveur Tang pour le déverrouillage à distance. Sous Windows, on combinera BitLocker au service Network Unlock.
Penser aux restrictions basées sur les en-têtes
Dans plusieurs incidents, le CERT-FR a relevé l’usage d’adresses IP publiques à l’intérieur d’infrastructures applicatives. Il n’y a pas de risque tant que les routages sont strictement segmentés. Mais cela complique l’interprétation des flux observés, en plus d’aggraver toute erreur de configuration des protocoles de routage et de provoquer des erreurs dans certains produits de sécurité informatique qui font des inférences sur la base des sous-réseaux IP utilisés. Aussi, on respectera les plans d’adressage de la RFC 1918, qui définit les plages IPv4 réservées pour les réseaux privés.
Pour limiter l’exposition des applications, le CERT-FR invite aussi à préférer distinguer les services par nom d’hôte que par chemin. Par exemple, privilégier hxxps://admin.example.com à hxxps://www.example.com/admin. Motif : cela permet d’exercer plus facilement des politiques de filtrage différentes, tout en minimisant à la fois les risques d’exposition croisée sur les services portant le routage d’URL et les partages de données implicites dans le navigateur.
Autre recommandation : configurer les applications qui manipulent les flux HTTP pour qu’elles incluent, dans les en-têtes, de quoi garder l’origine de la connexion. On utilisera par exemple le champ X-Forwarded-For. En parallèle, on intégrera l’adresse IP dans les journaux des pare-feu, VPN et équipements périmétriques, par exemple avec le champ remoteip.
Au niveau des applications, on peut compléter le filtrage par adresse IP avec des restrictions basées sur les en-têtes. De nombreux attaquants y laissent des valeurs marquantes, explique le CERT-FR. Et de donner l’exemple d’un compte utilisateur effectuant une connexion valide avec un user-agent caractéristique d’une bibliothèque Python. C’est un indicateur que ses identifiants sont potentiellement compromis.
Surveiller le standard DBSC pour la protection des cookies de session
Pas de retour terrain à proprement parler pour ce qui est de l’authentification. Mais un rappel : le W3C travaille sur le standard DBSC (Device Bound Session Credentials), destiné à luttter contre le vol de cookies et le piratage de sessions. Dans les grandes lignes, le navigateur génère une paire de clés stockée dans le TPM et prouve régulièrement la possession de la clé privée pour renouveler les cookies en arrière-plan. Les cookies, éphémères, ne peuvent être rafraîchis sur une autre machine, sauf si on parvient à extraire ladite clé privée.
Pour le moment, parmi les principaux navigateurs, seul Chrome gère DBSC. L’adoption du standard exige une légère évolution de la négociation dans les applications (gestion de la cinématique Secure Station Registration). Dans les architectures web modernes, cela se fait souvent au niveau de l’IDP.
Ne pas oublier l’option zero trust
Appelant à dépasser le couple login / mot de passe, le CERT-FR propose, entre autres, des mesures de transition pour les utilisateurs internes des applications. Il part du principe que tous les facteurs d’authentification qu’on doit saisir à la main sont vulnérables au phishing. Solution proposée : déployer bi-clés et certificats TLS dans les navigateurs des postes clients à protéger. Une méthode cryptographiquement forte, mais qui ne résiste pas aux infostealers capables d’extraire les certificats et leurs clés privées non protégées par du matériel de sécurité.
Les mesures traditionnelles de protection des cookies de session (marquage en http_only et secure, chiffrement strict des communications par TLS) ne protègent pas non plus des infostealers, ajoute le CERT-FR. D’où la référence à DBSC. Même si, en attendant que ce standard se diffuse, on peut jouer sur le délai d’expiration des sessions, en y associant des mesures qui facilitent la reconnexion rapide, comme les passkeys. Ou choisir l’option zero trust : « lier la session à ses conditions d’utilisation », pour reprendre les mots du CERT-FR. En n’oubliant pas, dans ce cas, les usagers mobiles, dont l’adresse IP peut changer fréquemment.
Adopter une journalisation UNIX à la milliseconde
Le CERT-FR dit rencontrer souvent des configurations de serveurs de journaux UNIX qui stockent les horodatages sans date et ont une précision limitée à la seconde. Il recommande d’adopter un format de flux conforme au protocole Syslog (RFC 5424) et une précision à la milliseconde. Ainsi que d’avoir une source de temps commune sur tous les équipements qui émettent des journaux et des événements. Et d’harmoniser le fuseau horaire des enregistrements (GMT conseillé).
Autres configurations souvent rencontrées : des logs applicatifs qui perdent l’information d’adresse IP source. Les connexions semblent alors toujours provenir de l’équipement frontal. Sur ces derniers, on utilisera donc, comme au niveau des applications, les en-têtes HTTP (champs X-Forwarded-For, Forwarded, X-Real-IP…).
Des interfaces réseau aux services d’administration, désactiver ce qui n’est pas utilisé
Le CERT-FR explique avoir souvent observé des services destinés à un usage local mais configurés pour écouter sur toutes les interfaces réseau du système. Il recommande d’éviter cette pratique. Et conseille, en complément, de désactiver les services d’administration et de supervision non utilisés dans les applications et dans le socle système. Par exemple SNMP, actif sur beaucoup d’équipements.
Sur l’interdiction des flux d’Internet vers les consoles d’administration, le CERT-FR s’arrête sur les services qui ne sont distingués de la production que par un chemin (par exemple, « /admin »). Il suggère de les bloquer au niveau du WAF ou du proxy inverse.
Refléter la logique applicative dans la structure des requêtes
Pour définir les seuils de détection d’anomalies, on discutera idéalement avec les métiers. Et face à des attaquants qui travaillent sur des durées longues, on prévoira des seuils cumulatifs.
Le CERT-FR attire l’attention sur le paramétrage de blocages et de bridages dans le WAF. Il est des seuils faciles à définir, comme ceux basés sur la quantité de données par session ou la source de connexion. Mais pour des règles plus fines (par exemple, qui corrèlent les groupes d’utilisateurs avec les accès aux objets), la logique applicative doit être reflétée dans la structure des requêtes. Dans la négative, l’analyse est plus complexe. Les frontaux peuvent même devenir des causes de déni de service.
L'ANSSI vient de dévoiler ses conclusions sur la cyberattaque nationale qui a compromis les frigos de centaines de supermarchés en France. Au cœur de l'attaque, on ne trouve pas une faille de sécurité sophistiquée, mais des « défauts de sécurisation élémentaires », comme des mots de passe faciles à deviner. Explications.
Devant le Sénat, Vincent Strubel, le directeur général de l'Anssi, a attribué le piratage des frigos de supermarchés à des « défauts de sécurisation élémentaires ». Il écarte la piste des failles publiées par des chercheurs ces deux dernières années.
Le retour d’expérience de l’ANSSI sur le vol de données à la DGFiP met en évidence six niveaux de protection à renforcer, de l’exposition des applications métiers à la gestion des comptes compromis. L’enjeu est d’éviter qu’un identifiant dérobé permette d’extraire massivement des données sans détection ni réaction suffisamment rapides.
Les protections à renforcer : exposition des applications, authentification, droits d’accès, quotas de consultation, détection et réponse aux incidents.
Le risque : qu’un compte légitime compromis soit utilisé pour accéder à des données et les extraire à grande échelle.
La nuance : toutes les mesures recommandées par l’ANSSI ne correspondent pas à des failles avérées. Un audit complet reste nécessaire pour identifier l’ensemble des vulnérabilités exploitables.
Le document ( une vingtaine de pages) met en évidence une série de contrôles à renforcer autour des applications métiers, de l’authentification, des droits d’accès, de la détection et de la réponse à incident.
Il faut toutefois distinguer les faits des recommandations. L’ANSSI précise elle-même que seul un audit complet du SI et des applications concernées permettra d’identifier avec exhaustivité les vulnérabilités exploitables. Les mesures qu’elle énumère ne constituent donc pas toutes la liste de failles avérées.
Elles dessinent néanmoins une chaîne de défense dont plusieurs maillons ont pu être insuffisamment robustes. Six niveaux ressortent particulièrement.
1- Une exposition des applications métiers à mieux maîtriser
La première faiblesse concerne la manière dont les applications métiers sont exposées.
L’ANSSI distingue trois catégories. Les applications internes devraient être accessibles uniquement depuis des postes administrés par la DGFIP et ne pas être directement accessibles depuis Internet, sauf au travers d’un VPN dédié aux agents.
Pour les applications destinées à un usage externe limité, l’agence préconise également un accès depuis les réseaux internes ou via un VPN pour les partenaires. À défaut, une limitation à une liste d’adresses IP autorisées peut être envisagée.
Cette recommandation est importante dans le contexte de l’incident. Plus une application métier est directement exposée à Internet, plus elle doit disposer de mécanismes complémentaires pour contrôler qui peut s’y connecter et ce qu’il peut y faire.
L’ANSSI ne dit pas que toutes les applications concernées étaient inutilement exposées. Mais la réduction de cette exposition constitue clairement l’un des axes de remédiation identifiés après l’incident.
Pour les applications qui doivent rester publiques, l’agence recommande notamment le géofiltrage, le filtrage des adresses IP mal réputées et l’utilisation de la source de connexion comme critère d’alerte lorsque son blocage n’est pas possible.
2 – Une authentification qui doit résister à la compromission des identifiants
Deuxième niveau : la protection des comptes.
Le retour d’expérience de l’ANSSI accorde une place importante à la prévention du vol d’identifiants. L’agence recommande notamment de proscrire l’utilisation d’appareils personnels pour accéder aux ressources professionnelles et de renforcer le niveau de sécurité des postes administrés : mises à jour, EDR, antivirus et VPN always-on sont cités parmi les mesures à mettre en œuvre.
Elle préconise également le déploiement de l’authentification multifacteur sur tous les applicatifs.
Mais l’ANSSI apporte une précision importante : tous les MFA ne se valent pas.
Le second facteur doit rester indépendant de la compromission du premier. Un code à usage unique transmis par e-mail n’est ainsi pas considéré comme suffisamment protecteur si la messagerie est elle-même accessible avec le même couple identifiant-mot de passe.
L’agence recommande plutôt des tokens physiques ou des applications d’authentification et préconise, lorsque cela est possible, l’utilisation d’un appareil différent pour le second facteur.
Cette partie du retour d’expérience montre que la question n’est donc pas seulement de savoir si un MFA existe. Il faut aussi déterminer contre quel scénario de compromission il protège réellement.
L’ANSSI demande parallèlement de renforcer les mots de passe et de mieux séparer les usages professionnels et personnels afin d’éviter qu’un environnement non administré par la DGFIP ne devienne le point d’entrée vers des identifiants professionnels.
3 – Des droits d’accès et des périmètres de consultation trop larges
C’est le troisième maillon et l’un des plus importants pour comprendre comment une compromission peut se transformer en extraction de données.
L’ANSSI recommande une gestion fine des droits applicatifs afin que chaque utilisateur ne puisse accéder qu’aux informations nécessaires à l’exercice de sa fonction.
Elle demande également la mise en place de plafonds de consultation des ressources métiers.
La nuance est importante. Un utilisateur peut être légitimement autorisé à accéder à une application sans pour autant devoir pouvoir consulter une quantité illimitée de données.
Cette distinction entre droit d’accès et capacité de consultation est fondamentale dans un scénario de scraping.
Un attaquant disposant d’identifiants valides peut en effet produire des requêtes qui, prises individuellement, ressemblent à une activité légitime. Le problème apparaît lorsque le compte permet d’enchaîner ces requêtes et d’explorer un périmètre de données beaucoup plus large que celui nécessaire à l’activité normale de l’utilisateur.
La limitation des droits ne constitue donc pas seulement une mesure de confidentialité. Elle sert aussi à contenir l’impact d’une compromission de compte.
4- Des mécanismes de limitation du scraping insuffisants
Le quatrième niveau est celui du contrôle du volume.
L’ANSSI demande explicitement l’application de quotas portant sur :
le volume de ressources métiers consultées ;
le nombre de requêtes ;
le volume de données échangées sur une période donnée.
Ces mesures sont particulièrement adaptées à la prévention du scraping automatisé.
Elles permettent de distinguer un utilisateur qui consulte ponctuellement une ressource d’un compte qui enchaîne des milliers de requêtes ou récupère des volumes de données incompatibles avec son usage habituel.
L’ANSSI préconise également des plafonds de consultation des ressources métiers. Il s’agit donc de créer plusieurs niveaux de limitation plutôt que de compter uniquement sur l’authentification.
Cette protection aurait un rôle essentiel dans un scénario où les identifiants ont déjà été compromis : même connecté avec un compte valide, l’attaquant ne devrait pas pouvoir exploiter indéfiniment l’application.
Il faut toutefois rester prudent sur la formulation. Si le texte de l’ANSSI recommande ces mécanismes, il ne permet pas, à lui seul, d’affirmer que chacun d’eux était absent au moment des opérations de scraping.
5 – Une détection et une réaction qui doivent être plus rapides
Cinquième maillon : la supervision.
L’ANSSI recommande que les applications soient systématiquement intégrées à un SIEM et que plusieurs indicateurs puissent déclencher des mesures de restriction : réputation IP, géolocalisation ou comportement inhabituel.
Le document fournit surtout un élément concret : des recherches suspectes sur E-Contact ont généré de vrais positifs.
Cette précision est intéressante parce qu’elle montre que le problème ne se situe pas nécessairement dans l’absence totale de détection.
Détecter une activité suspecte n’est toutefois qu’une première étape. Il faut ensuite pouvoir qualifier l’événement et interrompre rapidement l’activité malveillante.
C’est pourquoi l’ANSSI propose d’étudier la possibilité de déclencher automatiquement le blocage des comptes après certaines recherches suspectes.
Dans le cas d’une opération automatisée, cette capacité peut faire une différence considérable. Une alerte traitée manuellement peut laisser à l’attaquant une fenêtre d’exploitation supplémentaire. Un mécanisme automatisé peut au contraire interrompre la chaîne avant que le volume de données extrait ne devienne important.
L’enjeu est donc celui du passage d’une logique de détection à une logique de détection-réaction.
6 – Une gestion des comptes compromis à renforcer
Le dernier niveau concerne la réaction à la compromission elle-même.
L’ANSSI estime que la réinitialisation du mot de passe ne doit pas constituer la seule mesure.
Lorsqu’un compte est considéré comme compromis, son activité doit être analysée depuis la date présumée de la compromission. L’objectif est notamment d’identifier les applications auxquelles l’attaquant a pu accéder et les données qu’il a pu consulter.
La cartographie du SI devient ici un élément essentiel. Sans connaissance précise des applications auxquelles un compte peut accéder, il est difficile de mesurer correctement l’étendue d’une compromission.
L’ANSSI recommande également de révoquer les sessions actives sur tous les applicatifs et portails accessibles.
Cette mesure répond à un problème classique : modifier un mot de passe ne suffit pas nécessairement à mettre fin à une session déjà établie.
Enfin, si un même compte est compromis à plusieurs reprises, l’agence préconise une analyse approfondie de la cause racine.
La réponse à incident ne doit donc pas seulement consister à « changer le mot de passe ». Elle doit permettre de comprendre ce qui a été compromis, pendant combien de temps, par quels accès et pourquoi la compromission a pu se reproduire.
Selon l’ANSSI, un plan d’action prenant en compte les défaillances exploitées a été défini avec la DGFiP. Reste à connaitre le calendrier des déploiements.
C'est une histoire quelque peu ironique. L’ANSSI, l’agence nationale chargée de protéger les systèmes d’information de l’État, et la DINUM, qui pilote une partie du numérique public, ont été touchées par… des fuites de données.
Attention : il y a dans Metabase une vulnérabilité critique qui permet l’injection SQL sans authentification.
Le 10 septembre 2026, le CERT-FR avait émis une alerte de sécurité à ce sujet. Il disait avoir connaissance de nombreuses compromissions. Parmi elles, il y avait très probablement celle de Zéro Logement Vacant.
Ce service, que les collectivités territoriales utilisent pour identifier les propriétaires de logements durablement vacants et prendre contact avec eux, a visiblement subi un vol de données. L’acte a en tout cas été revendiqué, d’après l’ANSSI, qui affirme en avoir été informée le 28 août. « Le point d’entrée serait la compromission d’une instance Metabase », explique-t-elle désormais dans son premier point de situation sur le dispositif REACTIV.
Le document liste une vingtaine d’incidents survenus depuis début juillet. Leur point commun : des exfiltrations potentielles ou avérées. Certains restent en cours de qualification. Pour les autres, l’ANSSI communique, avec plus ou moins de certitude, des bilans chiffrés. Parfois sur les victimes, parfois sur les volumes de données, parfois sur les deux.
Les incidents chiffrés avec certitude
Le 12 août, une agence de ministère de l’Europe et des affaires étrangères a été ciblée. En l’occurrence, l’AEFE (Agence pour l’enseignement français à l’étranger). Un compte compromis a perms l’accès à l’annuaire interne. Et la récupération d’informations concernant « plus de 30 000 personnes » : identité, coordonnées, certifications professionnelles, qualifications, expériences, évaluations, financement des parcours VAE.
Le 7 août, soit quatre jours avant sa fermeture, le service Bloctel a subi une exfiltration de données. Le vecteur : un compte professionnel d’une entreprise. Butin : une archive qui contenait la liste des numéros qu’avait soumis ce professionnel, ainsi que la liste après traitement par Bloctel. La combinaison permettait d’identifier environ 600 000 numéros inscrits.
Toujours dans la sphère des ministères économiques et financiers, un incident a touché TRACFIN. Levier : la compromission du sous-traitant de l’opérateur du module d’assistance aux usagers intégré au portail de déclaration utilisé par les professionnels assujettis. L’exfiltration s’est étalée entre fin juin et mi-juillet. Elle concerne 136 professionnels. Butin : des noms, prénoms, fonctions, adresses électroniques et numéros de téléphone. Ainsi que le contenu de 213 demandes d’assistance envoyées au support technique.
Il y a bien sûr aussi la série d’attaques dirigées, les 12 et 13 août, contre la DGFiP. Une première a exposé les données fiscales d’environ 353 000 particuliers (état civil, coordonnées, numéro fiscal, situation familiale, revenu fiscal de référence, taux de prélèvement à la source et liste de demandes). Et de 252 000 professionnels (SIREN, dénomination, adresse, liste de demandes). Une seconde a permis de récupérer, depuis le serveur professionnel de données cadastrales, environ 2 millions de données concernant quelque 434 000 usagers (noms, dates de naissance, adresses, identifiants fonciers, parcelles, nature des droits).
L’ANSSI touchée elle aussi
Le 25 août, on a détecté la compromission de plus de 300 comptes utilisateurs de BNUM (Bureau Numérique). Cette application que porte le pôle ministériel Écologie fournit aux agents publics un portail d’accès à leurs outils de travail. Elle a permis d’exfiltrer le contenu de boîtes de messagerie et de l’espace de fichiers partagé.
Autre portail touché : OISO (Outil informatique de surveillance des organismes). Le ministère de l’Écologie s’en sert pour contrôler le respect des normes environnementales par des prestataires privés. L’utilisation du compte compromis d’un organisme privé a permis d’énumérer des données personnelles de 22 000 agents et organismes agréés.
L’application Qualicharge aide la puissance publique à gérer les infrastructures de recharge des véhicules électriques. L’exploitation de la vulnérabilité Metabase (CVE-2026-72898) a engendré l’exfiltration de 102 000 sessions de recharge. Et d’une centaine de comptes techniques (identifiants, adresses électroniques, mots de passe chiffrés).
Cette même vulnérabilité a aussi permis de cibler… le laboratoire d’innovation de l’ANSSI. Dans la nasse, 118 comptes utilisateurs, dont une trentaine d’externes. Butin : des données statistiques d’utilisation, des identifiants, des adresses électroniques et des mots de passe hachés.
Les incidents chiffrés sans certitude
L’ANSSI évoque l’attaque survenue fin juillet sur le SI du ministère de l’Éducation nationale. Elle explique que l’attaquant « a potentiellement pu exfiltrer » des données de 4,35 millions d’enseignants (identité, affectation, grade, formation, indemnités).
Ces données ont pour partie alimenté une autre revendication, faite le 17 août… et qui a aussi révélé un vol massif dans l’académie de Créteil : la base d’un million d’élèves, de leurs responsables légaux et d’enseignants.
Bilan également incertain pour Préférence Formations, outil du réseau national des EPLEFPA (Établissements publics locaux d’enseignement et de formation professionnelle agricoles). La fuite porterait sur 5265 personnes (identifiant, nom, prénom, adresse électronique, ville, pays, fuseau horaire).
Une attaque contre le portail du SNU (Service national universel) aurait exposé les données de 275 000 utilisateurs. Plus précisément, identifiants, noms, adresses électroniques, numéros de téléphone, rôles, statuts, informations géographiques et activité. La faute à une vulnérabilité IDOR (Insecure Direct Object Reference ; contrôle inapproprié des permissions par une application ou une API).
Les incidents non chiffrés
À la DINUM aussi, il y a eu compromission d’instances Metabase. Deux en l’occurrence, rattachées à ProConnect et à Nuage Public. Les informations que l’opération a exposées sont déjà publiques, assure l’ANSSI. Elles concernent des organismes publics (SIREN, SIRET, budgets, effectifs). Il s’y trouve aussi des métadonnées de contribution à des projets logiciels open source, et des historiques de connexion anonymisés.
Metabase toujours pour le portail France VAE, compromis le 8 août. L’intégralité des données des utilisateurs ont filtré (identité, contact, certifications, qualification, expériences, évaluations, financement). Et donc « a priori » aussi pour Zéro Logement Vacant.
Pas non plus de bilan chiffré concernant la compromission du compte Tchap d’un agent de l’Éducation nationale. Détectée le 19 août, elle a permis l’accès à des salons publics et privés, dont certains du cadastre et de la DGFiP (à ce sujet, consulter notre article sur le « décloisonnement » de Tchap à base de Matrix…).
L’ANSSI dit aussi avoir établi, le 21 août, un lien entre la compromission de trois comptes de messagerie d’agents de la DGDDI (Direction générale des douanes et droits indirects) et celle d’un serveur utilisé pour les échanges entre agents et prestataires. Un de ces comptes y avait effectivement accès…
Des identifiants volés, des accès trop ouverts et une exfiltration de données passée inaperçue. Dans un rapport publié le 29 septembre 2026, l'ANSSI revient sur le piratage de la DGFiP, qu'elle décrit comme révélateur de faiblesses structurelles.
REACTIV, c’est une « bascule d’effort temporaire » pour « limiter la casse ».
Vincent Strubel, directeur général de l’ANSSI, décrit ainsi ce dispositif lancé le 1er septembre 2026.
En toile de fond, une injonction du Premier ministre. Fin août, celui-ci avait demandé que soit constituée, autour de l’agence, « une unité de première intervention, engagée dès la violation d’un accès sensible et présente jusqu’au rétablissement ».
En résulte donc REACTIV (RÉponse et ACTion Interministérielle face aux Violations de données).
L’ANSSI ne spécifie pas l’ampleur de cette « capacité renforcée de réaction, d’intervention et d’assistance aux services de l’État ». Elle affirme toutefois renforcer, dans ce cadre, son autorité. Elle pourra en l’occurrence « faire prendre aux ministères, dans des délais contraints, les mesures immédiates qui s’imposent pour protéger les données des citoyens confiées aux administrations ».
« Limiter la casse » face au « hit & run »
Vincent Strubel recontextualise : depuis environ un an, le paysage de la cybermenace connaît une évolution majeure. Aux attaques étatiques et de groupes du crime organisé s’ajoutent celles de « jeunes Français, peu coordonnés mais qui exploitent des bases de comptes compromis par des infostealers ou des intrusions antérieures ». L’ANSSI, assure-t-il, n’a pas connaissance de leurs motivations profondes. Ni de ce qui a déclenché cette montée en puissance.
Toujours est-il que leurs attaques posent un défi particulier. D’une part, parce qu’elles s’en prennent à des systèmes peu ciblés jusque-là. De l’autre, parce que le mode opératoire est différent. On est sur « hit & run », sans recherche de privilèges élevés ni réel effort pour masquer les traces.
Cinconscrit à la partie post-incident, REACTIV constitue une forme de rustine, appliquée en attendant que les mesures inscrites dans la feuille de route 2026-2027 de sécurité numérique de l’État prennent effet. Y sont définis, entre autres priorités absolues, le renforcement des authentifications et des accès, ainsi que la résorption des obsolescences.
« Vers un formulaire commun de déclaration ACPR/AMF + ANSSI + CNIL ? [..] Les entreprises l’attendent. »
Le député Philippe Latombe a récemment interpellé, en ces mots, le directeur général de l’ANSSI Vincent Strubel.
L’intéressé a répondu se méfier des guichets ou formulaires uniques, qui « peuvent rapidement servir de cache-misère ». Si le droit européen crée des injonctions contradictoires, il faut l’harmoniser plutôt que de se reposer sur de la « tuyauterie administrative ».
Un formulaire commun DORA / NIS 2 est toutefois prévu. D’après Vincent Strubel, deux cadres sont suffisamment compatibles. De sorte qu’un document unique ne nuira pas à la « célérité nécessaire pour saisir les ‘cyberpompiers’ avant qu’il ne soit trop tard ».
L’articulation avec le RGPD est plus délicate, explique le DG de l’ANSSI. Qu’il s’agisse des délais, de l’analyse d’impact ou de la cinématique de notification, les exigences sont suffisamment différentes pour qu’une « fusion brutale » des guichets et formulaires « place les entreprises dans une situation impossible, en les obligeant à satisfaire dans une même notification plusieurs injonctions contradictoires ».
La cyber offensive, récemment entérinée par l’État
Toile de fond à cet échange : un accord entre l’ANSSI, la Banque de France et l’ACPR (institution intégrée à cette dernière). Il prévoit un renforcement de leur coopération SSI autour de quatre axes… dont les « tests d’intrusion avancés ».
Cette orientation fait écho aux propos récents de Sébastien Lecornu. En visite à l’ANTS, piratée mi-avril, le Premier ministre avait déclaré avoir appelé les services de l’État à tester leurs vulnérabilités. À cette même occasion, il avait évoqué un projet de fusion entre la DINUM et la DITP.
L’ANSSI et l’ACPR avaient déjà signé un accord du genre, en 2018. Elles n’en avaient pas détaillé les axes, expliquant simplement prévoir un « échange régulier d’informations ».
En matière de DevSecOps, la recherche académique et industrielle a une influence limitée.
Ainsi en juge l’ANSSI. La plupart des papiers qu’elle a analysés se concentrent sur des aspects techniques isolés : enrichissement des SBOM, analyse de la supply chain logicielle, automatisation CI/CD… Les modèles holistiques sont rarement explorés.
Malgré la pression réglementaire, le domaine repose encore sur des approches descriptives, avec peu de tests en conditions réelles, poursuit l’agence. Cela conduit à des éclairages fragmentés plutôt qu’à un cadre S-SDLC unifié.
On aura noté que l’analyse n’est pas exhaustive : elle a englobé 8 publications. Dont certaines non évaluées par les pairs. L’ANSSI le reconnaît et l’impute aux « contraintes temporelles de l’étude ». Sa sélection « demeure sujette à caution et ne reflète que partiellement l’état de l’art en DevSecOps », ajoute-t-elle.
L’IA ne l’a pas encore emporté sur les faux positifs
Au-delà de l’état de la recherche, l’ANSSI a sondé l’état du marché, selon une classification en 12 catégories de solutions AppSec.
Type de solution
Description
Static Application Security Testing (SAST)
Identifie les vulnérabilités en analysant le code source ou les binaires, sans exécuter l’application.
Dynamic Application Security Testing (DAST)
Détecte les problèmes de sécurité en testant l’application en fonctionnement, en simulant des attaques externes.
Interactive Application Security Testing (IAST)
Combine les techniques SAST et DAST en instrumentant l’application pour analyser son comportement en temps réel.
Runtime Application Self-Protection (RASP)
Surveille et protège l’application en détectant et en bloquant les menaces lors de l’exécution.
Software Composition Analysis (SCA)
Détecte les vulnérabilités et les risques liés aux composants logiciels tiers et open source, en s’appuyant généralement sur un Software Bill of Materials (SBOM) pour fournir un inventaire structuré de tous les composants, dépendances et risques associés.
Scanner IaC (Infrastructure as Code)
Analyse les modèles IaC (p. ex. Terraform, CloudFormation) afin de détecter les mauvaises configurations et les risques de sécurité avant le déploiement.
Artefact scanner
Examine les artefacts compilés (p. ex. conteneurs, binaires) afin de détecter les vulnérabilités connues et les problèmes de conformité.
Solutions de détection et gestion des secrets
Stockent de manière sécurisée les données sensibles et détectent les secrets codés en dur ou exposés dans le code et les pipelines.
Solutions de modélisation des menaces
Aident à identifier et évaluer les menaces potentielles durant la phase de conception du cycle de vie logiciel.
Solutions de signature d’artefacts
Garantissent l’authenticité et l’intégrité des artefacts logiciels grâce à des signatures cryptographiques.
Application Security Posture Management (ASPM)
Agrège et priorise les résultats de sécurité issus de différentes solutions afin de fournir une visibilité sur la posture de sécurité des applications.
AppSec/DevSecOps Training Platforms
Fournit des formations axées sur les pratiques de développement sécurisées et l’intégration de la sécurité dans les flux de travail DevOps.
Trois de ces catégories (SCA/SBOM, ASMP et gestion/scan de secrets) ont fait l’objet d’une étude approfondie. D’une part, à travers des entretiens avec 13 fournisseurs (dont 6 européens). De l’autre, en interrogeant 9 organisations avec un questionnaire basé sur le référentiel de maturité OWASP DevSecOps.
S’il en ressort une tendance à la « plateformisation » (10 fournisseurs sur 13 ont pris le pli), certaines intégrations demeurent partielles. Par exemple entre gestion des SBOM et détection des vulnérabilités : les workflows, les sources de données et les parcours utilisateurs restent souvent distincts.
Comme sur quantité d’autres marchés, l’IA se diffuse, mais la maturité varie considérablement. L’ANSSI l’estime insuffisante pour réduire significativement les faux positifs – fréquents notamment avec le SAST – ou améliorer la priorisation après analyse. Les organisations développent certes des solutions internes, mais qui progressent lentement et produisent des résultats limités. Elles attendent par ailleurs que les fournisseurs basculent des LLM généralistes vers des modèles spécialisés.
La remédiation aussi s’avère complexe. Surtout avec les scanners de secrets et les résultats des analyses SCA (impliquant parfois une restructuration importante du code).
À ces éléments s’ajoutent des cadres réglementaires « formulés à haut niveau ». Les orientations opérationnelles sont limitées : il est difficile de traduire les exigences en pratiques concrètes.
Compromission de systèmes, fuite de données sensibles, actions potentiellement destructrices… Les risques que pose OpenClaw sont connus et reconnus.
Le CERT-FR les a récemment synthétisés en un bulletin d’alerte. Il étend son propos à l’ensemble des « produits d’automatisation par IA agentique sur les postes de travail ». Outre OpenClaw, Claude Cowork est mentionné.
Consigne : en l’état, hors de question d’utiliser ces assistants en production. On s’en tiendra impérativement à des environnements de test isolés, sans données sensibles. On limitera par ailleurs les actions et les outils accessibles, tout en définissant des listes de canaux de communication et d’interlocuteurs autorisés. L’activation pourra être restreinte, par exemple en imposant l’invocation explicite des assistants (mentions @). Et l’usage de commandes système, soumis à validation humaine.
La formulation défensive des prompts peut contribuer à réduire les risques, même si les attaques par injection peuvent la contourner, précise le CERT-FR.
Le CERT chinois déplore un OpenClaw « extrêmement fragile »
Il y a quelques semaines, le CERT chinois avait émis une alerte de la même teneur, centrée toutefois sur OpenClaw. Il en soulignait la « configuration par défaut extrêmement fragile ». Et rappelait les privilèges élevés dont l’outil peut disposer (acès au système de fichier local, lecture des variables d’environnement, installation de plug-in…).
Son alerte n’interdisait pas formellement le déploiement en prod. Elle établissait néanmoins des prérequis parmi lesquels :
Renforcer le contrôle du réseau et ne pas exposer à Internet le port de gestion par défaut
Isoler l’environnement d’exécution et utiliser des technos comme les conteneurs pour limiter les privilèges excessifs
Ne pas stocker de clés dans des variables d’environnement
Gérer de manière stricte les sources des plug-in et désactiver leur mise à jour automatique
Selon que vous serez une entité « importante » ou « essentielle », la NIS 2 s’appliquera différemment.
Le principe est connu. L’ANSSI y apporte cependant une nouvelle grille de lecture, en l’objet du ReCyF (Référentiel Cyber France). Elle y décline les dispositions de la directive en 20 objectifs.
En attendant la transposition dans le droit français, le ReCyF n’est diffusé qu’en tant que document de travail – il n’a d’ailleurs pas encore fait l’objet d’une consultation. L’agence prévoit de publier un référentiel complémentaire qui en reprendra un sous-ensemble pour les entités moins matures.
Un principe de proportionnalité s’applique. Les entités importantes (EI) sont ainsi exemptées de 5 objectifs, qui ne s’appliquent qu’aux entités essentielles (EE). Ils concernent, dans les grandes lignes :
Gouvernance par les risques
Programme d’audit SSI
Sécurisation de la configuration des ressources des SI
(En particulier, n’installer que les logiciels nécessaires et réduire le risque sinon)
Réseaux d’administration dédiés
Supervision de la SSI
(Dimensionnement du SI en adéquation avec la capacité opérationnelle de l’équipe chargée de cette supervision, démarche d’amélioration continue de cette activité, conservation des données au moins 3 mois, etc.)
Les 15 autres objectifs s’appliquent aux EE comme aux EI. Mais on n’attend pas de ces dernières qu’elles mettent en œuvre autant de moyens pour les atteindre.
Sur la gouvernance de la sécurité numérique
L’ANSSI attend des EI que leur dirigeant exécutif soit responsable de la sécurité informatique. Mais pas qu’il désigne au moins une personne pour le conseiller et l’accompagner dans l’exercice de cette responsabilité.
Sur l’intégration de la sécurité numérique dans la gestion des RH
On n’attend pas des EI qu’elles prévoient des clauses de sécurité dans les contrats de travail.
Sur la maîtrise des SI
Au rang des éléments attendus des EI, il y a une cartographie des SI. Mais pas une procédure de MCO/MCS des ressources matérielles et logicielles. Ni la planification et l’installation des correctifs de sécurité sur l’ensemble de ces ressources.
Sur la maîtrise des accès physiques aux locaux
L’ANSSI attend d’une EI qu’elle mette en place des mesures pour limiter l’accès de personnes non autorisées à ses locaux (registre des visiteurs, badges…). Mais pas qu’elle s’assure de leur protection physique (vidéosurveillance, gardiennage, alarme). Ni que les droits d’accès physique soient attribués au regard du besoin strictement nécessaire à l’exécution des missions des personnes.
Sur la sécurisation de l’architecture des SI
Les EI cloisonneront physiquement et/ou logiquement l’ensemble de leurs SI vis-à-vis des autres SI.
On n’attend pas, en revanche, qu’elles mènent des réflexions sur la pertinence de définir des sous-systèmes. Et, par là même, qu’elles en définissent au moins un de type « passerelle sortante » (proxy) et un de type « passerelle entrante » (proxy inversé ou relais).
Deux autres « attendus » ne s’appliquent pas aux sous-systèmes. D’une part, s’assurer que seules les interconnexions nécessaires aux activités de l’EI ou à son MCO/MCS soient mises en œuvre entre ses SI et les SI tiers (ainsi que ceux auxquels elle a choisi de ne pas appliquer les objectifs de sécurité). De l’autre, définir et documenter ces mêmes connexions.
Sur la sécurisation des accès distants aux SI
L’ANSSI attend des EI des mécanismes de chiffrement et d’authentification conformes à ses recommandations. Mais elle n’attend pas nécessairement de multifacteur avec au moins un facteur de connaissance. Elle n’attend pas non plus des mesures de réduction du risque associé aux accès qui ne peuvent être couverts par du MFA pour raisons techniques ou opérationnelles. Ni un chiffrement et une authentification à l’état de l’art pour les disques des postes de travail et des équipements mobiles qui permettent les accès à distance depuis des lieux qu’elle ne maîtrise pas.
Sur la protection des SI contre les codes malveillants
On attend d’une EI qu’elle définisse les ressources matérielles autorisées à se connecter à ses SI. Mais pas qu’y connectent uniquement celles dont elle – ou un prestataire – assure la gestion et qui particpent à ses activités ou à son MCO/MCS.
Sur la gestion des identités et des accès aux SI
L’ANSSI escompte, de la part des EI, un mécanisme d’authentification impliquant au moins un élément secret. Elle attend des mesures de réduction du risque lorsque des raisons techniques ou opérationnelles empêchent la modification du secret. Mais pas, dans le cadre de cette exception, la mise en œuvre d’une traçabilité des accès.
Sur la maîtrise de l’administration des SI
Il est attendu que les actions d’administration soient effectuées exclusivement à partir de comptes d’administration. Et que ces derniers ne soient pas utilisés à d’autres fins.
L’ANSSI n’attend cependant pas que les EI tiennent à jour la liste des comptes d’administration de leurs SI. Ni que lors de la modification d’un de ces comptes, elles vérifient la cohérence des droits d’accès et des besoins d’utilisation.
Autre élément non attendu des EI : la désignation d’un « cœur de confiance » réunissant un annuaire et les ressources matérielles et logicielles qui l’hébergent ou permettent d’en prendre le contrôle. Ni, par voie de conséquence :
Réalisation des actions d’administration sur ce cœur de confiance depuis des comptes d’administration dédiés à cette tâche
Filtrage des connexions externes au cœur de confiance et à ses ressources d’administration
La revue annuelle de la configuration des annuaires n’est pas non plus un « attendu » pour les EI.
Sur l’identification et la réaction aux incidents de sécurité
Comme les EE, les EI mettront en œuvre des mécanismes d’analyse et de qualification des événements remontés et d’identification des incidents. On n’attend par contre pas d’elles :
Des mécanismes organisationnels et techniques pour réagir en cas d’incident et limiter les conséquences sur la fourniture de services
Une analyse des causes de chaque incident de sécurité
La conservation des relevés techniques pouvant servir d’éléments de preuve en cas de judiciarisation
La protection de ces relevés contre un incident qui les rendrait inexploitables
Sur la continuité et la reprise d’activité
L’ANSSI n’attend pas d’une EI qu’elle définisse et documente, pour chacun de ses activités et services, la durée maximale d’interruption admissible et le point de rétablissement des données. Ni qu’elle ait un PCA et un PRA cohérents vis-à-vis de ces deux indicateurs.
Sur la réaction aux crises d’origine cyber
En la matière, pas d’attentes envers les EI concernant :
Critères permettant d’activer et de désactiver le dispositif de gestion de crise prenant en compte les menaces cyber
Procédures et mécanismes de gestion de crise adaptés à la menace cyber et s’appuyant sur les recommandations de l’ANSSI
Mesures pour isoler, protéger et, le cas échéant, reconstruire les SI concernés
Stratégie de com adaptée
Moyens de communication de secours
Sur les exercices, tests et entraînements
L’ANSSI attend, chez les EI, au moins un exercice sur table – à la fréquence jugée adéquate – pour les personnes mobilisables dans le dispositif de gestion des crises cyber.
Elle n’attend pas, en revanche, de stratégie d’entraînement comportant une liste des acteurs amenés à participer aux différents dispositifs, une liste d’exercices, des objectifs et des moyens d’évaluer leur atteinte, des scénarios de risque ou d’attaques à tester en priorité et une comitologie de suivi.
L’IA générative ne crée pas de nouvelles formes d’attaques, elle les industrialise. C’est l’un des constats majeur de l’édition 2025 du » Panorame de la cybermenace » de l’ANSSI.
L’agence identifie plusieurs effets directs. D’abord, une hausse de la qualité des leurres utilisés dans les campagnes d’hameçonnage.
Les erreurs grammaticales et stylistiques qui permettaient auparavant à un utilisateur averti de repérer un e-mail malveillant tendent à disparaître. L’IA aide à produire des contenus plus convaincants, en plus grand nombre, avec une diversité accrue et à moindre coût.
L’ANSSI note également une réduction du coût de maintien des infrastructures d’attaque, ce qui abaisse la barrière d’entrée pour des acteurs moins sophistiqués.
Des sites malveillants indétectables à l’œil nu
L’un des signaux les plus concrets relevés par l’agence concerne la création de sites web à l’apparence légitime, entièrement générés par des systèmes d’IA.
Ces sites servent à héberger des charges malveillantes ou à effectuer ce que l’ANSSI appelle de la caractérisation, autrement dit, le profilage technique des visiteurs avant de les compromettre.
Comment les équipes de l’agence ont-elles détecté la nature artificielle de ces sites ? Par une anomalie révélatrice : l’insertion de textes incohérents au beau milieu de paragraphes, sans lien logique avec le reste du contenu. Un signe subtil, qui confirme que la vigilance humaine reste, pour l’instant, un maillon essentiel de la détection.
Le cercle vicieux de la pollution des données d’entraînement
L’IA générative ne se retourne pas seulement contre les utilisateurs finaux, elle menace aussi l’intégrité des modèles eux-mêmes.
L’ANSSI identifie ici un risque systémique : la multiplication de contenus fallacieux sur Internet finit par contaminer les jeux de données utilisés pour entraîner les futurs modèles.
Le mécanisme est simple. Les grands modèles de langage apprennent à partir des données disponibles sur le web. Si ces données sont massivement polluées par des contenus artificiels et erronés produits par d’autres IA, dans un but malveillant ou non, les modèles de nouvelle génération intègreront ces biais et inexactitudes dans leurs réponses.
Selon l’agence nationale, des acteurs malveillants exploitent délibérément ce vecteur : en inondant le web de contenus fabriqués, ils cherchent à altérer le comportement des services d’IA pour fausser leurs résultats. Les services d’IA générative sont ainsi devenus des cibles prioritaires à part entière.
L’IA dans les entreprises : une surface d’attaque qui s’élargit
L’intégration croissante de l’IA dans les flux opérationnels des entreprises entraîne mécaniquement un élargissement de leur surface d’attaque et les conséquences d’une compromission peuvent être sévères.
L’agence en identifie plusieurs catégories :
Confidentialité et intégrité des données. Un système d’IA compromis peut servir de point d’entrée vers le reste du système d’information, avec des risques d’exfiltration de données sensibles ou d’atteinte à l’intégrité des SI connectés.
La chaîne d’approvisionnement logicielle. C’est peut-être le risque le plus structurel identifié par l’ANSSI : la compromission d’un système d’IA spécialisé dans la génération de code pourrait introduire des vulnérabilités ou des portes dérobées dans le code produit, à l’insu total des équipes de développement. Une nouvelle forme d’attaque supply chain, silencieuse et difficile à détecter.
Les risques réputationnels et économiques. Toute fuite de données liée à un système d’IA fait peser un risque sur la confiance des clients, avec des implications potentiellement existentielles pour certaines organisations.
Les recommandations de l’ANSSI : cloisonner, surveiller, auditer
Pour répondre à ces risques, l’ANSSI a publié un guide dédié à la sécurisation des solutions d’IA générative basées sur des LLM.
Les grandes lignes sont les suivantes.
> Cloisonnement. C’est le principe central. L’agence recommande une isolation physique ou fonctionnelle des systèmes d’IA pour éviter qu’une compromission ne se propage. Pour les logiciels dont la conception n’est pas totalement maîtrisée par l’organisation, la recommandation est claire : les déployer sur un poste isolé et dédié.
> Surveillance des flux. Le cloisonnement seul ne suffit pas. Une surveillance active des échanges d’informations des composants d’IA est nécessaire pour détecter toute anomalie comportementale.
> Audits larges. L’ANSSI déconseille les audits à périmètre restreint, qui peuvent laisser dans l’ombre des chemins de compromission entre l’environnement IA et le SI bureautique.
> Ne pas tout miser sur les outils. L’agence pointe une limite importante : une stratégie de sécurité qui repose exclusivement sur des produits — EDR, MFA — est insuffisante. Les attaquants apprennent à contourner ces outils, ou à s’injecter directement dans les sessions utilisateurs légitimes.
> Préparer la gestion de crise. En cas d’incident, la priorité doit être l’isolation immédiate des systèmes compromis, combinée à la révocation des accès de l’attaquant. Cette séquence doit être anticipée dans les plans de continuité (PCA) et de reprise d’activité (PRA).
L’évolution rapide des usages de l’IA impose, selon l’ANSSI, une réévaluation régulière de la menace. Une mise en garde qui s’adresse autant aux RSSI qu’aux directions générales : l’IA n’est plus seulement un outil de productivité, c’est désormais un vecteur de risque à part entière, qui exige une gouvernance de sécurité adaptée.
L’ANSSI ne minimise pas le tableau. Si le nombre de cas de rançongiciels est en légère baisse – 128 incidents traités en 2025 contre 141 l’année précédente – l’agence nationale se garde bien d’y voir un signe d’accalmie.
La menace se reconfigure plutôt qu’elle ne recule : on observe une montée en puissance des exfiltrations de données sans chiffrement, exploitées à des fins de chantage ou revendues sur les marchés clandestins. La pression sur les victimes reste donc entière, même sans blocage des systèmes.
L’édition 2025 de son » Panorame de la cybermenace » confirme une tendance lourde : des acteurs étatiques, notamment nord-coréens et chinois, s’emparent désormais d’outils cybercriminels à des fins purement lucratives. La dichotomie traditionnelle entre espionnage d’État et cybercriminalité organisée s’efface, rendant l’attribution des attaques et la réponse institutionnelle bien plus complexes.
Espionnage, sabotage : les États toujours à la manœuvre
Du côté de l’espionnage stratégique, les groupes réputés liés à la Russie -Callisto, Laundry Bear – et à la Chine – Salt Typhoon, APT31 – maintiennent un effort soutenu pour compromettre les réseaux diplomatiques et les infrastructures critiques dans les secteurs des télécommunications et de l’énergie. Une activité de fond, discrète mais persistante, qui vise le long terme.
Le sabotage, lui, prend des formes plus visibles. Fin 2025, des opérations coordonnées ont ciblé les infrastructures électriques polonaises. Des groupes hacktivistes s’en prennent par ailleurs à de petites installations industrielles ( énergies renouvelables, réseaux d’eau ) pour des actions à fort retentissement médiatique. L’objectif n’est plus seulement de paralyser, mais aussi de créer un effet de sidération dans l’opinion publique.
L’arsenal technique se diversifie et s’industrialise
Sur le plan tactique, l’année 2025 confirme plusieurs évolutions structurelles. Les attaquants s’appuient de plus en plus sur des outils légitimes pour brouiller les pistes : logiciels d’accès à distance comme AnyDesk ou TeamViewer, services de stockage cloud tels que Google Drive ou MEGA. En se fondant dans le trafic normal des entreprises, ils compliquent considérablement la détection.
L’intelligence artificielle générative s’impose comme un accélérateur de menace. Elle améliore la qualité et la crédibilité des tentatives d’hameçonnage, permet de générer à grande échelle des sites malveillants à l’apparence légitime, et s’insère progressivement dans les flux opérationnels des organisations pour en exploiter les failles.
L’ingénierie sociale, de son côté, se raffine. Le SIM-Swapping, le MFA Fatigue – technique consistant à saturer un utilisateur de demandes d’authentification jusqu’à ce qu’il valide par lassitude – ou encore la méthode dite « Clickfix », qui pousse la victime à exécuter elle-même une commande malveillante, sont en forte recrudescence.
Ces méthodes misent sur la faillibilité humaine plutôt que sur des vulnérabilités techniques, ce qui les rend particulièrement difficiles à contrer par des outils seuls.
La surface d’attaque s’élargit : bordure, cloud, mobile
Les équipements de bordure – pare-feu, VPN, proxys – restent des portes d’entrée privilégiées. En 2025, des vulnérabilités affectant des solutions majeures comme Ivanti, Fortinet, Citrix ou Microsoft SharePoint ont été massivement exploitées. Ces points névralgiques, exposés directement sur Internet, constituent une cible de choix pour les attaquants cherchant un accès initial discret.
La chaîne d’approvisionnement numérique est également dans le viseur : compromettre un prestataire de services ou un hébergeur cloud permet d’atteindre simultanément un grand nombre de clients finaux.
De nombreux incidents ont ainsi concerné en 2025 le chiffrement de ressources hébergées dans le cloud, illustrant la vulnérabilité des environnements mutualisés.
Enfin, les terminaux mobiles ne sont pas épargnés. Les logiciels espions de type Pegasus ou Triangulation, exploitant des failles « zéro-clic » dans des applications populaires comme WhatsApp, continuent de cibler aussi bien les appareils personnels que professionnels.
Les 4 secteurs les plus exposés
L’éducation et la recherche arrivent en tête des secteurs victimes avec 34 % des incidents traités, devant les ministères et collectivités territoriales (24 %), la santé (10 %) et les télécommunications (9 %). Des secteurs souvent caractérisés par des ressources en cybersécurité limitées, des systèmes d’information hétérogènes et une forte exposition aux données sensibles.
Connexion
