NIS2 deux ans après : les 5 erreurs de mise en conformité que je vois répéter partout

La directive NIS2 est en vigueur depuis octobre 2022. La deadline de transposition dans le droit national des États membres était fixée à octobre 2024. Nous sommes en août 2026. Et pourtant, sur le terrain, je rencontre encore des entités essentielles qui ne savent pas précisément ce que leur impose la directive, des RSSI qui pensent avoir coché la case parce qu'ils ont réalisé un questionnaire fournisseur, et des directions générales qui ont délégué le sujet en croyant qu'il se traiterait tout seul. Voici les cinq erreurs les plus fréquentes — et les plus coûteuses — que j'observe dans ma pratique quotidienne.

Rappel du cadre : ce que NIS2 impose vraiment

Avant d'entrer dans les erreurs, posons le cadre. NIS2 (Network and Information Security Directive 2) remplace NIS1 avec un périmètre considérablement élargi. En France, la transposition a été assurée par la loi du 17 octobre 2024, imposant des obligations aux entités opérant dans dix-huit secteurs critiques, contre sept sous NIS1.

La directive distingue deux catégories : les entités essentielles (EE) et les entités importantes (EI). Les EE regroupent les opérateurs de services dans des secteurs hautement critiques : énergie, transport, secteur bancaire, infrastructure des marchés financiers, santé, eau potable, eaux usées, infrastructure numérique, gestion des services TIC, espace et administration publique. Les EI couvrent des secteurs critiques supplémentaires : services postaux, gestion des déchets, fabrication de produits critiques, industrie chimique, alimentation et certains fournisseurs de services numériques.

Concrètement, NIS2 impose aux entités concernées de :

• Mettre en place des mesures de gestion du risque cybersécurité formalisées : politique de sécurité, gestion des actifs, sécurité de la chaîne d'approvisionnement, contrôle d'accès, chiffrement, gestion des vulnérabilités et continuité d'activité.
• Notifier les incidents significatifs à l'ANSSI dans des délais stricts : alerte précoce sous 24h, notification complète sous 72h, rapport final dans le mois.
• Assurer une responsabilité des organes de direction : les dirigeants peuvent être personnellement sanctionnés en cas de manquement grave résultant de leur négligence.
• Se soumettre à des audits et contrôles réalisés ou mandatés par l'ANSSI, y compris des audits proactifs pour les entités essentielles.

Les sanctions prévues sont dissuasives : jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial pour les entités essentielles, et jusqu'à 7 millions d'euros ou 1,4 % du CA pour les entités importantes. Ces plafonds s'appliquent par infraction constatée.

Erreur n°1 : confondre entité essentielle et entité importante — et en tirer les mauvaises conclusions

C'est l'erreur la plus fréquente et elle a des conséquences directes sur le niveau d'effort consenti. Beaucoup d'organisations qui auraient dû s'enregistrer comme entité essentielle ont choisi — délibérément ou par ignorance — de se qualifier en entité importante, croyant bénéficier ainsi d'un régime moins contraignant.

La réalité est plus nuancée. Si les sanctions sont effectivement calibrées différemment, les obligations de fond sont quasi-identiques : les mesures de gestion du risque listées à l'article 21 de la directive s'appliquent aux deux catégories avec la même exigence. Ce qui diffère vraiment, c'est le régime de surveillance : les entités essentielles font l'objet d'une surveillance ex ante (proactive, y compris des audits imposés sans déclenchement préalable), tandis que les entités importantes sont principalement surveillées ex post (après incident ou plainte). Mais "moins surveillé" ne signifie pas "moins d'obligations" — un incident majeur chez une EI révélant un défaut de conformité déclenche exactement les mêmes analyses et potentiellement les mêmes sanctions qu'une EE.

La confusion sur la classification entraîne des lacunes concrètes. J'ai accompagné des groupes industriels de taille intermédiaire, opérant dans la fabrication de produits critiques (catégorie EI), qui n'avaient pas formalisé leur politique de gestion des incidents cyber car ils pensaient "n'être qu'importants". Un incident ransomware en janvier 2026 leur a coûté trois semaines d'arrêt de production et une notification tardive à l'ANSSI — déposée 8 jours après la détection au lieu des 24h réglementaires. Le résultat : une procédure administrative en cours et un coût de remédiation estimé à 1,2 million d'euros, sans compter le manque à gagner de la période d'arrêt.

La bonne pratique : réaliser une analyse formelle de classification avec un juriste spécialisé et un expert technique, en vérifiant non seulement le secteur d'activité mais aussi les seuils de taille (nombre d'employés, chiffre d'affaires) qui déterminent l'applicabilité. Cette analyse doit être documentée, datée et mise à jour annuellement — la structure organisationnelle d'un groupe peut changer et modifier le périmètre NIS2 applicable.

Un point souvent oublié : les sous-groupes de grands groupes peuvent eux-mêmes relever de catégories différentes. Une filiale de services informatiques d'un groupe industriel peut être en EE via la catégorie "gestion des services TIC" (MSP/MSSP fournissant des services à des entités critiques) même si la maison mère est classée EI dans le secteur industriel. L'analyse doit se faire entité juridique par entité juridique, pas au niveau du groupe consolidé.

Erreur n°2 : croire que la cartographie des actifs est un exercice ponctuel

La cartographie des systèmes d'information est le fondement de toute démarche NIS2. L'article 21 de la directive exige explicitement une gestion des actifs dans le cadre des mesures de gestion du risque. La plupart des entités que je rencontre ont réalisé une cartographie — généralement entre fin 2024 et courant 2025, au moment de leur première démarche de conformité. Le problème : la grande majorité ne l'ont pas mis à jour depuis.

Les SI ne sont pas statiques. En dix-huit mois, une organisation de taille intermédiaire peut intégrer une dizaine de nouveaux services SaaS, déployer plusieurs solutions d'IA générative qui traitent des données sensibles sans que la DSI en soit clairement informée, migrer des briques d'infrastructure vers le cloud, ajouter plusieurs sous-traitants avec des accès techniques VPN, et refondre une ou plusieurs applications métier critiques. Chacun de ces changements modifie le périmètre NIS2 et l'exposition aux risques.

Dans ma pratique, l'écart entre la cartographie documentée et la réalité terrain est régulièrement de l'ordre de 30 à 40 % des actifs — des services en production qui n'apparaissent nulle part dans le CMDB, des interconnexions avec des systèmes tiers non documentées, des accès administrateurs accordés il y a deux ans et jamais révoqués. Cet angle mort est particulièrement dangereux pour NIS2, car un incident affectant un actif non cartographié sera doublement problématique : la détection sera retardée (pas d'alertes configurées), et la notification à l'ANSSI sera incomplète ou erronée.

Selon une étude de l'ENISA publiée en mars 2026 portant sur 340 entités NIS2 européennes, 67 % d'entre elles n'avaient pas mis à jour leur cartographie d'actifs dans les 12 mois précédant l'audit. Parmi les entités ayant subi un incident significatif déclaré, 82 % avaient des actifs non inventoriés impliqués dans la chaîne d'attaque. Ce chiffre est éloquent : la cartographie défaillante n'est pas seulement un problème de conformité, c'est un facilitateur d'incident.

La solution n'est pas de réaliser une cartographie tous les trimestres — c'est irréaliste pour la plupart des organisations sans équipe dédiée. C'est de mettre en place un processus continu d'inventaire automatisé couplé à des jalons de revue formels semestriels. Des outils comme les scanners de découverte réseau (Rumble Network Discovery, Lansweeper), les CSPM pour les actifs cloud (Wiz, Prisma Cloud, Microsoft Defender for Cloud) et les catalogues SaaS (Torii, BetterCloud) permettent de maintenir une cartographie vivante sans effort manuel excessif. L'objectif n'est pas la perfection — c'est une amélioration continue et traçable de la couverture d'inventaire.

Un point clé souvent sous-estimé : la cartographie NIS2 doit inclure les actifs des sous-traitants critiques ayant accès à votre SI, pas seulement les actifs en propriété directe. Un prestataire de maintenance industrielle connecté via VPN permanent avec un compte à privilèges fait partie de votre périmètre d'exposition NIS2, même si les équipements physiques lui appartiennent.

Erreur n°3 : déléguer la conformité sans gouvernance réelle

NIS2 est explicite sur un point que de nombreux dirigeants auraient préféré ne pas voir dans la directive : la responsabilité personnelle des organes de direction. L'article 20 impose aux États membres de prévoir des mécanismes permettant de tenir les dirigeants d'entités essentielles et importantes personnellement responsables en cas de violation grave des obligations NIS2 résultant de leur négligence. En France, la transposition prévoit des sanctions pouvant aller jusqu'à l'interdiction temporaire d'exercer des fonctions de direction.

Malgré cette clarté, la configuration la plus fréquente que j'observe est la suivante : le RSSI (ou, dans les organisations plus petites, le DSI) a été mandaté pour "gérer le NIS2". Il rend compte trimestriellement au comité de direction via deux ou trois slides. Le CODIR valide, passe à l'ordre du jour suivant, et considère le sujet réglé. Cette configuration est un risque juridique pour les dirigeants eux-mêmes et un risque opérationnel pour l'organisation.

Le problème n'est pas la délégation en elle-même — il est impossible que le PDG d'un groupe industriel soit en première ligne de l'application des mesures techniques NIS2. Le problème est l'absence de gouvernance réelle derrière la délégation. Une gouvernance NIS2 effective suppose plusieurs éléments non négociables :

• Un programme de sécurité formalisé et budgété, approuvé par la direction et révisé annuellement, avec des objectifs mesurables, des indicateurs de suivi et un tableau de bord clair sur l'état de conformité.
• Des revues de direction régulières (trimestrielles au minimum) incluant l'état des risques significatifs, les incidents en cours ou récents, et les écarts par rapport au programme de conformité.
• Une formation des dirigeants aux enjeux cyber et aux obligations NIS2 : la directive impose explicitement que les membres de la direction suivent des formations adaptées. Ce n'est pas une option — c'est une exigence qui sera vérifiée lors d'un audit ANSSI.
• Des procédures de crise documentées et testées : le plan de réponse aux incidents doit prévoir explicitement qui décide de notifier l'ANSSI, selon quel processus de qualification et dans quel délai. Cette décision ne peut pas reposer sur une seule personne.

Un exemple concret de ce que j'observe : une collectivité territoriale classée EE dans la catégorie administration publique avait nommé son DSI référent NIS2. Le DSI avait produit un beau document de politique de sécurité, mais ne disposait d'aucun budget d'investissement dédié et ne participait pas aux instances décisionnelles de la collectivité. Résultat lors d'un incident de sécurité majeur en mars 2026 : décision de notification ANSSI bloquée pendant 48h parce que le DGS (Directeur Général des Services) n'était pas au courant des obligations légales et craignait les répercussions politiques d'une déclaration publique d'incident. La notification a finalement été déposée avec 26h de retard sur la deadline des 24h — déclenchant une procédure administrative.

Erreur n°4 : ignorer la chaîne d'approvisionnement — le talon d'Achille collectif

L'article 21 de NIS2 impose explicitement de gérer les risques liés à la chaîne d'approvisionnement (supply chain), notamment en évaluant les pratiques de sécurité de ses fournisseurs, prestataires et sous-traitants. C'est probablement l'obligation la moins bien assimilée et la plus difficile à mettre en oeuvre — mais c'est aussi celle qui concentre le plus grand risque d'incident majeur.

Les données sont éloquentes. Selon le rapport Verizon DBIR 2026, 41 % des incidents chez les entités NIS2 européennes impliquaient un vecteur tiers (prestataire, fournisseur logiciel, partenaire avec accès distant). Ce chiffre est en hausse de 8 points par rapport à 2024. Les attaques de supply chain les plus médiatisées de 2026 — la compromission de bibliothèques JavaScript via ViteVenom et ChainVeil, les packages npm infectés ciblés sur l'écosystème blockchain, les bibliothèques Python utilisées par des fournisseurs industriels — illustrent exactement ce vecteur d'attaque de plus en plus prisé par les groupes APT et les opérateurs RaaS.

Sur le terrain, la gestion de la chaîne d'approvisionnement NIS2 est souvent réduite à l'envoi d'un questionnaire de sécurité annuel aux fournisseurs "critiques". Ce questionnaire est généralement auto-déclaratif, sans vérification des réponses, et ne couvre pas les sous-sous-traitants — les tiers des tiers qui ont souvent un accès technique à vos systèmes via leurs propres outils de supervision ou de maintenance. C'est insuffisant — et c'est exactement ce que vérifient les auditeurs ANSSI.

Une approche rigoureuse de la supply chain NIS2 suppose plusieurs niveaux d'action :

• Classification des fournisseurs par criticité : identifier les fournisseurs dont la compromission aurait un impact direct sur la continuité ou la sécurité de vos services NIS2-critiques. Ce sont vos fournisseurs "de premier rang" à risque élevé — ils méritent un traitement différencié et approfondi.
• Clauses contractuelles adaptées : tous les contrats avec des fournisseurs critiques doivent inclure des clauses imposant un niveau de sécurité minimum, une obligation de notification d'incident sous 24h, le droit d'audit de sécurité, et l'obligation de respecter les exigences NIS2 si le fournisseur est lui-même une entité concernée.
• Due diligence technique : pour les fournisseurs de services managés (MSP, hébergeurs, prestataires d'infogérance), exiger des certifications (ISO 27001, SOC 2 Type II) ou des preuves d'audit récentes — moins de 12 mois. Une certification ISO 27001 datant de 3 ans sans surveillance annuelle est une garantie faible.
• Monitoring des incidents tiers : mettre en place une veille sur les incidents et vulnérabilités affectant vos fournisseurs critiques. Quand un fournisseur SaaS critique est compromis (comme l'incident Adform de juillet 2026 sur les scripts publicitaires), vous devez le savoir avant vos utilisateurs — pas après.

Je rencontre régulièrement des entités qui ont investi massivement dans leur propre sécurité — SOC interne, EDR dernière génération, authentification multifacteur généralisée — mais qui accordent des accès VPN permanents à des prestataires de maintenance industrielle dont le niveau de sécurité n'a jamais été évalué. Ces prestataires travaillent depuis des postes non supervisés, potentiellement partagés entre plusieurs clients, avec des comptes à privilèges élevés sur les systèmes les plus sensibles. C'est l'angle mort classique, et c'est souvent par là qu'entrent les attaquants.

L'erreur n'est pas de faire confiance à ses fournisseurs — c'est de faire confiance sans vérifier. La gestion de la supply chain NIS2 n'est pas une question de méfiance envers les partenaires, c'est une question de responsabilité partagée et de visibilité mutuelle sur les risques. Les fournisseurs matures en sécurité comprennent et respectent ces exigences — ceux qui résistent sont souvent ceux qui ont le plus à cacher sur leurs pratiques internes.

Erreur n°5 : sous-estimer les obligations de notification d'incident

C'est la dernière grande erreur — et souvent la plus visible lors des contrôles ANSSI. NIS2 impose des délais de notification très stricts : une alerte précoce à l'ANSSI dans les 24 heures suivant la prise de connaissance d'un incident significatif, une notification complète dans les 72 heures, et un rapport final dans le mois. Ces délais sont cumulatifs et non exclusifs : on notifie sous 24h même si on n'a pas encore l'image complète de l'incident — c'est précisément le but de l'alerte précoce.

La définition d'"incident significatif" est au coeur du problème. La directive et sa transposition française donnent des critères généraux : un incident est significatif s'il cause ou est susceptible de causer une perturbation grave des services, d'affecter d'autres entités, d'entraîner des pertes financières importantes, ou de toucher un grand nombre de personnes. Dans la pratique, cette définition laisse une marge d'interprétation qui conduit à deux comportements opposés : la sous-notification par excès de prudence ("ce n'est peut-être pas significatif") et la sur-notification par excès de zèle ("on notifie tout pour se couvrir").

La sous-notification est de loin le problème le plus répandu. Sur les incidents que j'ai accompagnés depuis octobre 2024, un tiers auraient dû faire l'objet d'une notification à l'ANSSI et ne l'ont pas été — soit parce que l'entité n'avait pas de procédure claire de qualification, soit parce que la décision de notifier a été différée en attendant d'avoir "une image complète", soit parce que les équipes craignaient d'alerter l'ANSSI pour rien. Cette dernière crainte est infondée : l'ANSSI communique clairement qu'elle préfère être notifiée d'un incident qui s'avère mineur plutôt que de ne pas l'être d'un incident majeur.

Autre point régulièrement négligé : la notification à l'ANSSI est distincte des notifications aux personnes concernées relevant du RGPD, des notifications aux régulateurs sectoriels (ACPR pour les banques et assurances, ARS pour les hôpitaux, Banque de France pour les établissements financiers), et des éventuelles communications de crise vers les clients ou partenaires. Un incident majeur peut déclencher simultanément plusieurs obligations de notification vers des destinataires différents, avec des délais différents et des formats différents. Sans procédure préparée et testée à l'avance, gérer ces notifications en parallèle d'une crise opérationnelle active est une épreuve qui fragilise à la fois la réponse technique et la communication institutionnelle.

Les meilleures pratiques que j'observe chez les entités les mieux préparées :

• Des modèles de notification NIS2 pré-remplis (alerte précoce, notification intermédiaire, rapport final) adaptés aux typologies d'incidents les plus probables pour leur secteur.
• Un arbre de décision de qualification permettant à l'équipe de réponse aux incidents de décider rapidement (en moins d'une heure) si un incident est significatif au sens NIS2.
• Une désignation claire du décisionnaire pour la notification ANSSI, avec un suppléant identifié — cette décision ne doit pas être bloquée par l'indisponibilité d'une seule personne en pleine crise.
• Des exercices de simulation annuels incluant la composante notification : tester non seulement la réponse technique mais aussi la capacité à notifier l'ANSSI dans les délais réglementaires.

Le bilan côté régulateur : où en est l'ANSSI en 2026 ?

L'ANSSI a lancé sa première vague de contrôles NIS2 sur les entités essentielles au premier trimestre 2026. Les résultats, partiellement publiés dans le rapport semestriel de l'agence de juin 2026, sont instructifs. Sur les 87 entités essentielles auditées, 61 % présentaient au moins une non-conformité majeure au sens de la directive, et 23 % avaient des lacunes suffisamment graves pour justifier une mise en demeure formelle assortie d'un délai de correction contraint.

Les trois déficiences les plus fréquemment constatées lors de ces audits sont, dans l'ordre : l'absence de politique de gestion des accès à privilèges (PAM) formalisée et auditée, la gestion insuffisante de la chaîne d'approvisionnement, et l'absence de tests réguliers du plan de continuité d'activité (PCA) et du plan de reprise d'activité (PRA). Ce dernier point mérite une attention particulière : beaucoup d'organisations ont un PCA sur le papier mais ne l'ont jamais testé en conditions réelles. Les exercices de simulation (tabletop exercises, tests de basculement réels) sont explicitement mentionnés dans les bonnes pratiques NIS2 et seront de plus en plus vérifiés lors des audits.

Sur le plan des sanctions, l'ANSSI n'a pas encore prononcé de sanctions financières maximales à ce stade. Les premières sanctions publiées concernent des entités qui avaient refusé de coopérer avec les audits ou qui n'avaient pas procédé aux notifications requises dans les délais légaux. Ce positionnement pragmatique du régulateur — sanctionner d'abord le refus de coopération et les manquements aux obligations procédurales — peut rapidement évoluer si les résultats des contrôles s'avèrent systématiquement insuffisants et si des incidents majeurs révèlent des défauts de conformité évidents.

Ce qui reste à faire pour être vraiment conforme en 2026

La mise en conformité NIS2 n'est pas un projet à "terminer" mais un programme continu d'amélioration de la posture de sécurité. En août 2026, les entités qui n'ont pas encore engagé de démarche sérieuse ont perdu deux ans — mais il est encore possible de corriger les lacunes les plus critiques rapidement en suivant un ordre de priorité clair.

Pour une entité qui commence ou dont la conformité est partielle, voici les priorités dans l'ordre :

• Enregistrement ANSSI : confirmer sa catégorie (EE ou EI) et s'assurer d'être enregistré dans le registre NIS2 de l'ANSSI — c'est une obligation légale, non facultative, et l'ANSSI dispose des données sectorielles pour identifier les entités non enregistrées.
• Gap analysis structuré : réaliser une analyse d'écart formelle par rapport aux exigences de l'article 21 de la directive, idéalement avec un expert externe pour éviter les biais d'auto-évaluation. L'ANSSI a publié un guide méthodologique qui constitue une bonne base de référence.
• Procédure de notification documentée et testée : formaliser et tester la procédure de notification d'incident à l'ANSSI — c'est le point le plus facilement vérifiable lors d'un contrôle et le plus susceptible de générer une sanction immédiate en cas d'incident.
• Formation des dirigeants : organiser une session de sensibilisation NIS2 pour les membres de la direction — courte (2 à 3 heures), factuelle, centrée sur leurs responsabilités personnelles et les critères de qualification d'un incident significatif.
• Revue des contrats fournisseurs : identifier les 10 à 20 fournisseurs les plus critiques et vérifier que les clauses contractuelles de sécurité et de notification sont à jour et conformes aux exigences NIS2.

Conclusion

NIS2 n'est pas une contrainte administrative supplémentaire à gérer à minima. C'est un cadre qui, correctement mis en oeuvre, améliore réellement la résilience cyber d'une organisation. Les entités qui ont pris la directive au sérieux dès 2024 le constatent aujourd'hui : elles détectent les incidents plus vite, elles notifient dans les délais légaux — ce qui limite les sanctions et protège leur réputation — et elles ont une meilleure maîtrise de leur surface d'attaque, y compris côté supply chain.

Les cinq erreurs décrites dans cet article ne sont pas des erreurs de mauvaise volonté. Ce sont des erreurs de compréhension du cadre, de gouvernance insuffisante et de sous-estimation du travail réel que représente la conformité. Les corriger demande du temps, des ressources et un accompagnement expert. Attendre le premier contrôle ANSSI ou le premier incident majeur pour s'y mettre revient à se retrouver en position de faiblesse dans les deux cas — avec des délais d'action compressés et un régulateur ou un attaquant dans le dos.