03 RUBRIQUE / CYBERCORIA
Relier textes officiels, obligations de gouvernance et réalité du système d’information sans transformer la conformité en slogan.
NIS2, DORA, RGPD, recommandations ANSSI/CNIL/ENISA et articulation entre exigences, actifs et preuves.
Nous distinguons ce que les textes exigent, ce que les autorités recommandent et ce que la cartographie ou les contrôles techniques peuvent réellement aider à démontrer.
01 / Réglementation
Cybercoria sépare trois niveaux : ce que le texte impose, ce qu’une autorité ou une agence recommande, et ce qu’une organisation peut choisir comme moyen opérationnel. Cette distinction évite de transformer une fonctionnalité technique en obligation réglementaire inexistante.
02 / Réglementation
Gestion des actifs, continuité, chaîne d’approvisionnement, données, accès et preuves ne vivent pas dans des documents isolés. Les analyses cherchent à montrer quels objets et quelles relations du système peuvent aider à instruire une exigence, sans prétendre qu’une cartographie suffit à démontrer la conformité.
03 / Réglementation
Une carte peut montrer une dépendance ; elle ne prouve pas qu’une sauvegarde a été restaurée, qu’une revue d’accès a eu lieu ou qu’un incident a été traité dans les délais. Cette séparation entre structure, mesure et preuve est un principe éditorial récurrent de la rubrique.
11 publications
Un PRA documenté ne garantit pas le retour d’une fonction critique. Comment tester les dépendances réelles entre applications, identités, données et prestataires ?
Supprimer les noms ne suffit pas à anonymiser un jeu de données. Avant un export, il faut évaluer ce que le destinataire peut recouper, isoler et inférer.
Entre une page web et un modèle d’IA, une donnée peut être copiée, filtrée, transformée et intégrée à plusieurs artefacts. La provenance permet de reconstruire son parcours.
Une AIPD peut être bien documentée tout en décrivant imparfaitement le système qui traite réellement les données. Relier traitement, flux, applications, stockage et dépendances permet de confronter l’analyse RGPD à l’architecture déployée.
Le premier bilan annuel DORA permet de dépasser la théorie réglementaire : les incidents réels montrent l’importance des dépendances partagées, des fonctions critiques et des causes récurrentes.
Le CRA ne s’arrête pas forcément au logiciel ou au matériel installé : certaines solutions de traitement de données à distance peuvent faire partie du produit avec éléments numériques.
À partir du 11 septembre 2026, certaines obligations de notification du Cyber Resilience Act deviennent applicables. Pour un fabricant, l’enjeu est de pouvoir relier rapidement produit, version, vulnérabilité ou incident, exploitation, correctif et chronologie.
Le premier rapport DORA sur les incidents TIC majeurs montre surtout un besoin opérationnel : disposer immédiatement des données qui relient incident, fonctions, services, tiers et impacts.
Le registre DORA n’est pas une simple liste de fournisseurs. Il relie contrats, services TIC, fonctions, prestataires, sous-traitants et évaluations : le construire à partir des référentiels du SI réduit les incohérences.
Le registre RGPD recense les traitements par finalité. La cartographie SI décrit applications, flux et infrastructures. Les relier peut améliorer la gouvernance sans confondre leurs objectifs.
L’article 21 de NIS2 impose une approche de gestion des risques couvrant notamment incidents, continuité, chaîne d’approvisionnement, accès et gestion des actifs. Où intervient concrètement la cartographie SI ?
Une page n’est publiée que si elle apporte une information, une méthode, une synthèse ou un angle vérifiable qui justifie son existence en dehors d’un objectif de référencement.
