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
