NIS2, article 21 : ce que la cartographie SI aide réellement à démontrer

La directive NIS2 ne dit pas « achetez un outil de cartographie ». Elle demande aux entités concernées de prendre des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées pour gérer les risques qui menacent les réseaux et systèmes d’information et réduire les conséquences des incidents.1

L’article 21 couvre notamment l’analyse des risques, la gestion des incidents, la continuité, la chaîne d’approvisionnement, la sécurité du développement et de la maintenance, l’évaluation de l’efficacité des mesures, l’hygiène cyber, la cryptographie, le contrôle d’accès, la gestion des actifs et, lorsque cela est approprié, l’authentification multifacteur et des communications sécurisées.1

Le rôle de la cartographie est donc indirect mais important : elle aide à connaître le périmètre, relier les dépendances et contextualiser les actifs. Elle ne constitue pas, à elle seule, une preuve de conformité.

Sujet NIS2	Apport de la cartographie	Preuve à conserver ailleurs
Gestion des actifs	Périmètre, propriétaires, dépendances	Inventaires contrôlés, procédures
Continuité	Chaînes de dépendances	Plans, sauvegardes, tests de reprise
Incidents	Impact potentiel en contexte	Journaux, tickets, chronologie
Contrôle d’accès	Zones et rôles documentés	IAM, revues d’accès, logs

Ce que l’article 21 demande réellement

Le principe général est une gestion du risque adaptée au contexte de l’entité.1 Cela implique deux conséquences utiles pour la lecture d’une cartographie.

Premièrement, le périmètre technique ne peut pas être dissocié des services rendus. Un composant prend de l’importance parce qu’il supporte une activité, porte une donnée, fournit un accès ou crée une dépendance.

Deuxièmement, une mesure n’est pas évaluée seulement par son existence. Il faut pouvoir montrer qu’elle est appliquée au bon périmètre, qu’elle est adaptée au risque et, pour certaines exigences, qu’elle est testée ou évaluée.

Le règlement d’exécution (UE) 2024/2690 précise des exigences techniques et méthodologiques pour certaines catégories d’entités numériques visées par NIS2 — notamment plusieurs fournisseurs de services numériques, cloud, data centres et services managés.2 Il ne faut donc pas appliquer mécaniquement son annexe à toutes les entités NIS2. ENISA a publié en 2025 un guide d’implémentation pour aider les entités concernées par ce règlement à interpréter ces exigences.3

Cette distinction de périmètre est importante : directive, règlement d’exécution et guide ENISA n’ont pas exactement le même champ.

Gestion des actifs : la cartographie aide à savoir ce que l’on protège

La gestion des actifs figure explicitement dans l’article 21.1 Un inventaire peut fournir une liste d’équipements ou d’applications. Une cartographie ajoute les relations : quel processus dépend de quelle application ? quel service cloud héberge quelles données ? quel tiers fournit une brique critique ?

Cette structure permet d’éviter une criticité déconnectée du réel. Un serveur n’est pas « critique » en soi : il le devient parce qu’une ou plusieurs chaînes de service dépendent de lui.

L’ANSSI présente justement la cartographie comme un outil contribuant à la maîtrise, à la protection, à la défense et à la résilience du SI.4

Approfondir
Cartographie SI : les 5 étapes de l’ANSSI transformées en plan opérationnel →

Continuité : visualiser la chaîne avant de tester sa reprise

NIS2 cite la continuité des activités, la gestion des sauvegardes, la reprise après sinistre et la gestion des crises.1

Une cartographie peut répondre à la première question : quels composants doivent fonctionner pour que ce service existe ? Elle aide à construire une chaîne processus → application → identité → données → infrastructure → tiers.

Mais la carte ne démontre pas que la reprise fonctionne. Les preuves se trouvent ailleurs : rapports de tests, journaux de restauration, résultats d’exercices, procédures, mesures de temps de reprise ou de perte de données. La cartographie fournit le contexte qui permet de choisir ce qu’il faut tester et dans quel ordre.

Gestion des incidents : réduire le temps nécessaire pour comprendre l’impact

Pendant un incident, une liste d’actifs répond rarement à la question la plus urgente. Les équipes veulent savoir ce que le composant touché supporte, avec quoi il communique et quelles données ou activités peuvent être affectées.

Une cartographie maintenue peut raccourcir cette phase de compréhension. Elle peut aussi aider à préparer les listes de parties prenantes ou de propriétaires à contacter. En revanche, elle ne détecte pas l’incident, ne remplace pas les journaux et ne constitue pas la chronologie d’investigation.

Chaîne d’approvisionnement : rendre les tiers visibles dans le système

La sécurité de la chaîne d’approvisionnement et les relations avec les fournisseurs figurent dans les mesures de l’article 21.1

Une vue d’écosystème peut documenter SaaS, hébergeurs, opérateurs, sous-traitants techniques, interconnexions et services externes. Le point intéressant n’est pas d’avoir « une liste fournisseurs » supplémentaire, mais de montrer quels services internes dépendent de quel tiers.

Cette vue peut orienter une revue contractuelle ou une évaluation de risque. Elle ne remplace pas les clauses, questionnaires, audits ou attestations que l’organisation décide de conserver comme preuves.

Sécurité du développement et des changements : relier le composant au propriétaire

NIS2 couvre également la sécurité de l’acquisition, du développement et de la maintenance des réseaux et systèmes, y compris le traitement des vulnérabilités.1

La cartographie peut faciliter l’attribution : qui possède l’application ? quel dépôt, pipeline ou fournisseur est associé ? quel service est exposé ? quelles dépendances risquent d’être affectées par une modification ?

Elle ne remplace pas un inventaire de vulnérabilités ni un processus de patch. Elle donne le contexte nécessaire pour transformer « CVE sur un composant » en « risque sur un service ».

Contrôle d’accès et identités : documenter les zones ne prouve pas les droits

Une cartographie peut représenter des annuaires, des fournisseurs d’identité, des zones d’administration ou des relations de confiance. Cela aide à comprendre où l’accès est concentré et quelles dépendances communes existent.

Mais la preuve du contrôle d’accès réside dans les configurations IAM, les revues d’habilitations, les journaux, les mécanismes MFA et les procédures de gestion du cycle de vie des comptes. La cartographie doit donc rester un index vers le contexte, pas devenir un substitut aux systèmes de preuve.

Mesurer l’efficacité : la carte aide à choisir quoi contrôler

L’article 21 mentionne les politiques et procédures permettant d’évaluer l’efficacité des mesures de gestion des risques.1 Une cartographie peut aider à construire un échantillonnage cohérent : services critiques, dépendances partagées, zones sensibles, fournisseurs importants.

Par exemple, si dix services dépendent du même fournisseur d’identité, tester la résilience et les contrôles de cette brique est probablement plus structurant que de choisir dix actifs au hasard. C’est une décision d’audit rendue possible par la compréhension des dépendances.

Trois couches à ne jamais confondre

Pour éviter de transformer la cartographie en « dossier NIS2 », il est utile de séparer :

1. les faits de structure : actifs, flux, propriétaires, tiers, dépendances ;
2. les mesures : MFA, chiffrement, sauvegardes, filtrage, monitoring, procédures ;
3. les preuves : configurations, journaux, rapports de tests, comptes rendus, tickets, décisions d’acceptation.

Une même exigence peut mobiliser les trois couches, mais aucune ne remplace les deux autres.

Un exemple de chaîne de preuve

Prenons un service métier critique hébergé dans le cloud.

La cartographie montre que le service dépend d’une application, d’un fournisseur d’identité, d’une base de données et d’un prestataire SaaS. Le référentiel de mesures indique que MFA, sauvegarde et journalisation sont requis. Les systèmes opérationnels fournissent ensuite les preuves : configuration MFA, résultat du dernier test de restauration, journaux d’accès, rapport de revue du fournisseur.

La conformité n’est donc pas « dans la carte ». La carte rend la preuve navigable et contextualisée.

Checklist : ce que la cartographie devrait pouvoir fournir à une démarche NIS2

Sans prétendre couvrir l’ensemble de la conformité, un référentiel utile devrait permettre de retrouver rapidement :

• les services et activités critiques ;
• les applications et infrastructures qui les supportent ;
• les propriétaires ;
• les principales dépendances techniques et externes ;
• les flux significatifs ;
• les tiers et fournisseurs associés ;
• les données ou catégories d’information importantes ;
• les points de concentration comme IAM, réseau, cloud ou sauvegarde ;
• la date et le périmètre de la dernière vérification.

Si ces faits sont fiables, ils deviennent une base commune pour l’analyse de risque, la continuité, la gestion d’incident et la préparation des preuves. C’est là que la cartographie apporte le plus de valeur : elle relie les sujets sans prétendre les remplacer.