En 2026, NIS2 n’est plus un sujet “à garder dans un coin”. Les organisations se retrouvent face à une réalité simple : il faut être capable de démontrer (et pas seulement d’affirmer) que l’on maîtrise ses risques cyber, ses actifs, ses dépendances et ses processus.
En France, la transposition de NIS2 progresse via le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025 et poursuivant son parcours à l’Assemblée nationale :
En parallèle, l’ANSSI a ouvert un pré-enregistrement sur MonEspaceNIS2 depuis le 24 novembre 2025 :
L’objectif de cet article est :
- Suis-je concerné par NIS2 ? (auto-diagnostic, erreurs fréquentes, check-list)
- Article 21 : ce que l’on attend vraiment (mesures minimales traduites en “preuves”)
- Cartographie SI pour NIS2 (inventaire, dépendances, criticité, ownership)
Cet article propose une approche opérationnelle (DSI/RSSI). Il ne remplace pas un avis juridique. En cas de doute sur votre statut exact (entité essentielle/importante, cas frontières, exceptions), appuyez-vous sur les canaux officiels et/ou un conseil spécialisé.
1) NIS2 : suis-je concerné ? (auto-diagnostic fiable)
1.1 Comprendre la logique : secteur + taille + exceptions
NIS2 élargit fortement le périmètre par rapport à NIS1. Le principe de lecture est le suivant :
- Votre secteur / sous-secteur figure-t-il dans les annexes I ou II de la directive ?
- Votre taille atteint-elle au moins le niveau “moyenne entreprise” (au sens UE) ?
- Existe-t-il des exceptions ou des cas où la taille est moins déterminante (certaines entités ou services étant considérés critiques par nature) ?
Texte de référence (directive NIS2) : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555
Définition UE des catégories d’entreprises (PME, etc.) : Recommandation 2003/361/CE
https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2003:124:0036:0041🇫🇷PDF
Ce qu’il faut retenir : si vous êtes dans un secteur listé (annexe I/II) et que vous n’êtes pas une “petite” structure, il est prudent de considérer que NIS2 vous concerne et de vous préparer à produire des preuves.
1.2 Entité “essentielle” vs “importante” : sans jargon
NIS2 distingue :
- les entités essentielles,
- les entités importantes.
Cette distinction influence notamment la supervision et les plafonds de sanctions, mais dans les deux cas, vous devez mettre en place un socle de mesures de gestion des risques (Article 21).
Référence : directive NIS2 (voir le texte officiel) : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555
1.3 Mini arbre de décision (pratique)
Répondez “oui / non / je ne sais pas” :
-
Q1 — Fournissez-vous des services / exercez-vous des activités dans l’UE ?
- Non → NIS2 probablement hors champ.
- Oui → Q2.
-
Q2 — Votre organisation opère-t-elle dans un secteur listé en annexe I ou II ?
- Non / je ne sais pas → Q2bis.
- Oui → Q3.
-
Q2bis — Êtes-vous un acteur fortement numérique (ex. cloud, datacenter, services managés, etc.) ?
- Non → revalidez votre secteur (annexes) et votre statut.
- Oui → attention : ces activités sont fréquemment citées comme critiques selon la lecture et la transposition.
-
Q3 — Votre organisation est-elle au moins “moyenne entreprise” (référentiel UE) ?
- Non → la taille peut vous exclure, sauf exceptions.
- Oui → Q4.
-
Q4 — Vos clients / votre écosystème dépendent-ils de vos services au point qu’une indisponibilité majeure créerait un impact important (continuité, sécurité, santé, économie…) ?
- Oui → probabilité forte : préparez conformité et preuves.
- Non → probabilité possible : vérifiez votre catégorisation exacte.
1.4 Erreurs fréquentes (qui font perdre du temps)
-
“On fera ça quand ce sera obligatoire.”
Problème : les mesures structurantes (inventaire, ownership, PRA, gestion des incidents, supply chain) ne se déploient pas en 15 jours.
-
Confondre “être conforme” avec “avoir des documents”.
NIS2 attend des mesures effectives et une capacité à démontrer (preuves, traçabilité, tests, gouvernance).
-
Croire que l’inventaire est un fichier Excel isolé.
Un inventaire utile est relié aux services, aux dépendances, aux accès, aux tiers, et il est maintenu.
-
Sous-estimer la supply chain (prestataires, SaaS, infogérance, éditeurs).
L’Article 21 inclut explicitement la sécurité de la chaîne d’approvisionnement.
Sur MonEspaceNIS2, l’ANSSI précise des informations “obligatoires” à communiquer (nom, coordonnées, secteur, etc.) et notamment les plages d’adresses IP exposées sur Internet.
Référence (FAQ officielle) : https://aide.monespacenis2.cyber.gouv.fr/fr/article/quelles-sont-les-informations-obligatoires-quune-entite-regulee-par-la-directive-nis-2-doit-communiquer-a-lautorite-nationale-competente-19y0pxm/
Exemples de champs à anticiper :
- Nom de l’entité
- Adresse et coordonnées (emails, téléphones)
- Plages d’IP exposées sur Internet
- Secteur et sous-secteur (annexe I/II)
- États membres où vous fournissez des services (si applicable)
Signal important : si vous ne savez pas répondre rapidement à ces éléments (notamment IP exposées), vous avez déjà un chantier prioritaire : l’inventaire et l’attaque surface.
2) Article 21 : ce que l’on attend vraiment (et comment le prouver)
2.1 L’Article 21, c’est “gouvernance + mesures + preuves”
L’Article 21 décrit les mesures de gestion des risques en cybersécurité (techniques, opérationnelles et organisationnelles) qui doivent être appropriées et proportionnées.
Texte officiel : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555
Le point souvent sous-estimé : l’approche est conçue pour être auditable. Autrement dit, vous devez être capable de répondre à des questions du type :
- Quels risques majeurs avez-vous identifiés ?
- Quelles mesures réduisent ces risques ?
- Qui est responsable ?
- Quels indicateurs prouvent que cela fonctionne ?
- Quelles preuves (tests, incidents, revues) le démontrent ?
2.2 Les 10 mesures minimales (a → j) traduites en livrables
NIS2 cite “au moins” les mesures suivantes (Article 21). Voici une traduction très opérationnelle en livrables/proofs.
a) Politiques d’analyse des risques et de sécurité des SI
À produire :
- Méthode de gestion des risques (même simple, mais formalisée)
- Politique SSI (ou PSSI) concise, applicable, versionnée
Preuves :
- Registre des risques + critères d’évaluation
- PSSI signée/validée (ou PV de validation)
b) Gestion des incidents
À produire :
- Processus de détection, qualification, escalade, traitement
- Rôles (y compris hors horaires) et contacts
Preuves :
- Playbooks (ransomware, fuite, indispo, compromission compte admin…)
- Journal d’incidents + retours d’expérience
c) Continuité d’activité (PCA/PRA), sauvegardes, gestion de crise
À produire :
- Stratégie de sauvegarde, objectifs RTO/RPO
- Plan de gestion de crise
Preuves :
- Tests de restauration (datés, tracés) + résultats
- Exercices de crise (compte rendu)
d) Sécurité de la chaîne d’approvisionnement (fournisseurs / prestataires)
À produire :
- Cartographie des tiers critiques
- Exigences de sécurité (contrats, clauses, engagements)
Preuves :
- Liste des fournisseurs + criticité + dépendances
- Évaluation du risque tiers (questionnaires, audits, attestations…)
e) Sécurité acquisition/développement/maintenance + gestion des vulnérabilités
À produire :
- Patch management (cibles, délais, responsabilités)
- Processus vulnérabilités (détection, qualification, correction, suivi)
Preuves :
- Indicateurs de patching + exceptions justifiées
- Traces de traitement CVE / tickets / changements
f) Évaluation de l’efficacité des mesures
À produire :
- KPI / tableaux de bord
- Audits, revues, plan d’amélioration continue
Preuves :
- Rapports de contrôle / audit
- Plan d’actions + suivi (statuts, dates, responsables)
À produire :
- Règles simples (MFA, mots de passe, phishing, poste de travail)
- Plan de sensibilisation
Preuves :
- Sessions de formation (traces, taux de complétion)
- Campagnes de simulation phishing (résultats)
h) Cryptographie / chiffrement (si approprié)
À produire :
- Politique chiffrement (données sensibles, transit, repos)
- Gestion des clés / secrets
Preuves :
- Standard crypto retenu + gouvernance des secrets
- Revue de configuration (ex. TLS, stockage chiffré)
i) Sécurité RH, contrôle d’accès, gestion des actifs
À produire :
- Processus entrées/sorties, revues des accès
- Inventaire des actifs + ownership
Preuves :
- Revues d’habilitations périodiques (datées)
- Inventaire maintenu (actifs, applications, services)
j) MFA / communications sécurisées + communication d’urgence
À produire :
- MFA sur comptes critiques (administration, accès distant, outils clés)
- Canaux de secours (si messagerie indisponible)
Preuves :
- Taux de couverture MFA
- Procédure de communication d’urgence (testée)
2.3 Sanctions (pour comprendre le niveau d’exigence)
La directive prévoit des plafonds d’amendes administratives “au moins” :
- Entités essentielles : jusqu’à 10 M€ ou 2 % du CA annuel mondial
- Entités importantes : jusqu’à 7 M€ ou 1,4 % du CA annuel mondial
Référence : texte officiel NIS2 sur EUR-Lex
https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555
Lecture utile : l’enjeu n’est pas “cocher des cases”, mais de pouvoir démontrer une démarche de gestion des risques, avec priorisation, responsabilité, et preuves.
3) Cartographie SI pour NIS2 : méthode pragmatique + modèles
Si l’on résume l’Article 21, une grande partie des mesures devient impossible à piloter sans répondre à ces questions :
- Quels services métiers sont critiques ?
- Quelles applications soutiennent ces services ?
- Quelles infrastructures, comptes, flux et dépendances rendent ces services possibles ?
- Quels tiers (SaaS, infogérance, cloud, éditeurs, hébergeurs) sont indispensables ?
- Où sont les points d’entrée et quelles IP/URL sont exposées ?
- Qui est responsable (owner) de chaque actif ?
- Qu’est-ce qui a changé (traçabilité), quand et par qui ?
Une cartographie SI utile NIS2 n’est pas un schéma “statique”. C’est un référentiel vivant : inventaire + relations + criticité + ownership + preuves (liens vers procédures, tests, contrôles).
Si votre cartographie ne sert pas à prioriser un plan d’actions et à répondre en incident, elle vous coûtera du temps sans créer de valeur.
3.2 Le périmètre “minimum viable” (à viser en premier)
Commencez par ce qui fait le plus gagner en preuves Article 21 :
- Services métiers (10 à 30) + criticité
- Applications (incluant SaaS) + données clés
- Infrastructures supportant les applications critiques (on-prem / cloud / datacenter)
- IAM / SSO / comptes à privilèges + MFA
- Expositions (IP publiques, DNS, reverse proxy, VPN, API publiques)
- Flux (internes/externes) et dépendances
- Tiers (infogérance, MSSP, hébergeur, éditeurs) + criticité
3.3 Méthode en 6 étapes (conçue pour produire des preuves vite)
Étape 1 — Définir l’objectif et les règles de mise à jour
- Pourquoi cartographier ? (NIS2, audit, gestion d’incident, PRA, supply chain)
- Quel périmètre ? (services critiques d’abord)
- Qui maintient ? (owners)
- À quel rythme ? (changement, revue mensuelle, revue trimestrielle)
Livrable : 1 page “charte de cartographie” (périmètre, règles, responsabilités).
Étape 2 — Lister les services métiers et les classer
Pour chaque service :
- Owner métier
- Owner technique
- Criticité (impact opérationnel / financier / réglementaire)
- RTO/RPO cibles (même approximatifs au départ)
Livrable : tableau Services + score criticité.
Étape 3 — Relier applications ↔ services
Pour chaque application :
- Rôle (supporte quel service)
- Données traitées (sensibilité)
- Mode d’hébergement
- Points d’entrée (URL/IP exposées)
- Dépendances majeures
Livrable : matrice Services x Applications + fiches Applications critiques.
Étape 4 — Descendre sur l’infrastructure (sans chercher l’exhaustivité)
Ne cartographiez pas “tout”. Cartographiez d’abord :
- les composants qui portent les applis critiques
- les briques transverses (IAM, sauvegarde, supervision, DNS, messagerie…)
- les points de passage (VPN, proxy, reverse proxy, bastion)
Livrable : vue “Application critique → composants techniques → dépendances”.
Étape 5 — Ajouter la supply chain (tiers critiques)
Pour chaque application critique :
- éditeur / infogérant / MSSP / hébergeur
- engagements (SLA, notification incident, support, réversibilité)
- criticité et risques associés
Livrable : carte des tiers + fiche “tiers critique”.
Étape 6 — Attacher les preuves Article 21 aux objets cartographiés
Exemples :
- L’objet “SSO/IAM” pointe vers la procédure MFA, les revues d’accès, la politique mots de passe.
- L’objet “Application CRM” pointe vers le PRA, la stratégie de sauvegarde, les tests de restauration, le patching.
- L’objet “Prestataire d’infogérance” pointe vers les clauses contractuelles, preuves d’audit, engagement de notification.
Livrable : un lien “preuve” par exigence Article 21, rattaché aux actifs concernés.
FAQ (SEO / questions fréquentes)
“NIS2, c’est pour quand en France ?”
La France transpose NIS2 via un projet de loi dédié. Le texte a été adopté par le Sénat le 12 mars 2025 et poursuit son parcours à l’Assemblée nationale.
Références :
https://www.senat.fr/dossier-legislatif/pjl24-033.html
https://www.assemblee-nationale.fr/dyn/17/dossiers/DLR5L17N50731
“Le pré-enregistrement MonEspaceNIS2 est-il déjà disponible ?”
Oui : l’ANSSI a annoncé l’ouverture du pré-enregistrement le 24 novembre 2025.
Référence : https://cyber.gouv.fr/actualites/nis-2-les-entites-assujetties-peuvent-se-pre-enregistrer
“Pourquoi la cartographie SI revient toujours dans NIS2 ?”
Parce que sans inventaire et dépendances, vous ne pouvez pas :
- prioriser les risques,
- sécuriser la supply chain,
- prouver MFA/contrôle d’accès,
- tester PRA/PCA de façon réaliste,
- ni produire les preuves attendues en audit.
“Quel est le premier livrable à faire si on manque de temps ?”
Un inventaire des services critiques + applications critiques + points d’entrée exposés + owners, puis rattacher 5 preuves prioritaires : MFA, patching, sauvegardes+tests, procédure incident, logs/supervision.
Ressources officielles (à garder sous la main)
Comprendre NIS2 et l’Article 21, c’est une étape. Le plus difficile ensuite, c’est de tenir dans la durée une capacité à démontrer :
- quels services métiers sont critiques, et quelles applications les supportent,
- où sont les dépendances (infra, cloud, SaaS, tiers) et quels points d’entrée sont exposés,
- qui est responsable de quoi (owners, RACI),
- ce qui a changé (traçabilité) et pourquoi,
- où sont les preuves (PRA/PCA, MFA, patching, incidents, audits) et comment les relier aux actifs concernés.
C’est précisément l’objectif de Cartographit : vous aider à construire une cartographie SI exploitable, multicouche (métier → applicatif → infrastructure), et à la maintenir à jour pour répondre aux exigences de conformité (NIS2, ISO 27001, DORA…), sans repartir de zéro à chaque audit.
Ce que vous pouvez obtenir rapidement
- une vue claire des services critiques et de leurs dépendances,
- un inventaire structuré (applications, serveurs, flux, tiers) avec criticité et ownership,
- une base solide pour prioriser les risques et piloter un plan d’actions,
- une traçabilité des modifications (utile pour audit et retour d’expérience incident).
Vous voulez voir à quoi ça ressemble sur votre contexte ?
Conclusion
La cartographie du système d’information n’est plus un nice-to-have : c’est un prérequis pour maîtriser les risques, optimiser les coûts et accélérer la transformation. Avec Cartographit, vous disposez d’une cartographie vivante, automatisée et orientée décision — alignée sur les exigences de conformité et les réalités opérationnelles.
