Trois cadres, un incident, plusieurs responsabilités

Ce scénario pédagogique n’est pas un cas client de CYTIZEN. Un éditeur fournit un logiciel connecté utilisé par une entreprise industrielle et par un établissement financier. Une vulnérabilité activement exploitée affecte le produit ; un client constate une interruption. La même chaîne technique peut produire plusieurs obligations, mais les acteurs, les périmètres et les canaux ne sont pas interchangeables. Le fabricant du produit, l’entreprise qui l’utilise et l’entité financière ne se transforment pas en une seule organisation parce qu’ils partagent des données d’incident.

La démarche proposée consiste à réutiliser les faits et les preuves, tout en conservant des décisions réglementaires distinctes. Il serait dangereux de déduire qu’une notification effectuée au titre d’un cadre satisfait automatiquement les autres. La direction de programme peut organiser l’inventaire, la collecte et les exercices ; la qualification juridique et la décision de notification appartiennent aux fonctions compétentes, avec les autorités et textes applicables. Ce dossier n’est pas un avis juridique individuel.

Le calendrier à comprendre au 4 octobre 2026

DORA est applicable depuis le 17 janvier 2025 et concerne la résilience opérationnelle numérique du secteur financier selon son périmètre défini. Une entreprise industrielle n’entre pas automatiquement dans DORA parce qu’elle utilise SAP ou un prestataire cloud. Elle peut néanmoins recevoir des exigences contractuelles d’un client financier ou participer à une chaîne de tiers. Il faut distinguer obligation directe et exigence transmise par contrat : les preuves peuvent se ressembler, la responsabilité ne se déduit pas du nom de l’outil.

NIS2 est une directive. La date limite de transposition était le 17 octobre 2024, mais l’application concrète nécessite de vérifier la situation nationale, la catégorie de l’entité et les règles compétentes. La Commission signalait encore en juillet 2026 un renvoi de plusieurs États, dont la France, devant la Cour de justice pour défaut de notification des mesures de transposition. On ne doit donc pas écrire que tous les États ont appliqué un régime identique et achevé depuis 2024. Les propositions de modification de 2026 ne sont pas assimilées ici à des règles nationales déjà en vigueur.

Le Cyber Resilience Act vise les produits comportant des éléments numériques selon son champ propre. Ses obligations de signalement des vulnérabilités activement exploitées et des incidents graves affectant la sécurité des produits s’appliquent depuis le 11 septembre 2026 ; les principales exigences générales s’appliqueront à partir du 11 décembre 2027. La Commission et ENISA précisent ce calendrier. Un service SaaS n’est pas qualifié automatiquement de produit couvert ou exclu : l’analyse dépend notamment du produit et de ses fonctions de traitement à distance.

Créer une matrice de périmètre avant un tableau de conformité

Amine, responsable de programme dans le scénario, crée une matrice à quatre colonnes : entité juridique, activité ou produit, cadre à examiner et décision de périmètre validée. Une ligne décrit l’établissement financier et ses fonctions critiques ; une autre le fabricant du logiciel ; une troisième l’entreprise industrielle et son secteur. Chaque conclusion renvoie au texte, à l’analyse compétente et à la date de révision. La case « hors périmètre » conserve une justification ; elle n’est pas un silence dans le registre.

La matrice relie ensuite fonctions métiers, applications, infrastructures, données et tiers. Elle ne se limite pas à une liste de fournisseurs. Un même hébergeur peut soutenir plusieurs services qui n’ont pas la même criticité ; une application interne peut dépendre d’un prestataire indirect essentiel. Amine repère les chaînes dans lesquelles un incident d’identité, de connectivité ou de sauvegarde interromprait plusieurs fonctions. Cette carte permet d’identifier les preuves communes sans confondre les obligations.

Les responsables signent les éléments qu’ils connaissent. Le métier décrit l’effet d’une interruption, l’IT la dépendance et la capacité de restauration, les achats le contrat, la sécurité les contrôles, le juridique la qualification. Un registre rempli par le seul PMO serait fragile. Le PMO peut assurer cohérence, versions et décisions ouvertes ; il ne doit pas fabriquer une expertise technique ou juridique à la place de ceux qui doivent l’attester.

Un noyau de faits commun, des sorties séparées

Le noyau commun d’incident comprend l’heure de détection, les faits disponibles, les services et produits concernés, les versions, les effets observés, les populations affectées, les mesures prises et les incertitudes. Les faits et les hypothèses sont séparés. Une chronologie horodatée permet d’expliquer ce qui était connu au moment de chaque décision. Les preuves sont conservées avec des accès limités et une procédure de modification, afin qu’une correction n’efface pas l’état initial.

À partir de ce noyau, chaque propriétaire produit la sortie correspondant à son cadre : qualification, destinataire, contenu et délai vérifiés dans le texte applicable et les instructions de l’autorité compétente. Le présent guide ne propose pas un délai universel de notification ; les délais dépendent du régime, du type d’événement et du déclencheur retenu. Une alerte interne précoce donne aux fonctions responsables le temps de décider. Elle ne doit pas attendre que le fournisseur ait terminé toute son investigation.

La bibliothèque de preuves contient des éléments réutilisables : inventaire de dépendances, contrats, engagements de support, exercices de restauration, gestion des vulnérabilités et décisions d’acceptation de risque. Chaque preuve indique son périmètre, sa date et la version testée. Un rapport ancien ne démontre pas qu’un service récemment modifié peut être restauré. La réutilisation économise la collecte ; elle ne supprime pas le contrôle de pertinence de la preuve pour chaque obligation.

Le test de restauration doit prouver un résultat métier

Amine organise un exercice où un service documentaire et son identité associée deviennent indisponibles. Les équipes restaurent l’application, puis découvrent que certains utilisateurs ne peuvent plus accéder aux documents nécessaires. L’exercice n’est pas clôturé sur le seul retour des serveurs. Il vérifie l’authentification, les droits, les données et le parcours métier. Les objectifs de reprise doivent être définis en fonction de l’activité et acceptés par les propriétaires, plutôt qu’hérités sans discussion d’un contrat technique.

Le compte rendu distingue durée réellement observée, périmètre testé et limites. Un test partiel de restauration de fichiers n’est pas présenté comme une restauration complète du service. Les écarts déclenchent des actions dotées d’un responsable et d’une échéance ; les écarts critiques exigent une décision sur l’exposition courante. Le comité doit savoir si une amélioration a été testée ou seulement demandée au fournisseur.

Les preuves de tiers sont examinées avec la même discipline. Un certificat ou un rapport d’audit peut être pertinent, mais son périmètre doit couvrir le service, l’entité et les opérations concernés. Les exceptions et exclusions sont lues. Un questionnaire fournisseur rempli ne démontre pas la capacité de l’entreprise cliente à poursuivre son activité en cas d’arrêt. Le contrat, l’architecture et l’exercice doivent raconter une histoire cohérente.

Dans la vraie vie : un exercice de décision

L’exercice illustratif commence par une information incomplète du fabricant : une version pourrait être concernée par une exploitation active. Le responsable produit vérifie la version ; le métier évalue les effets d’une suspension ; la sécurité conserve les éléments disponibles ; les responsables réglementaires qualifient leurs propres obligations. Amine tient la chronologie et les décisions ouvertes. Il n’attend pas une certitude parfaite pour réunir ces acteurs, et ne leur impose pas une notification unique.

À la fin, chaque équipe restitue ce qu’elle aurait décidé, sur quels faits et à quelle heure. Le débrief identifie les coordonnées absentes, les contrats qui ne prévoient pas la transmission des faits utiles et les systèmes dont la version ne peut pas être retrouvée rapidement. Ces défauts deviennent des corrections opérationnelles concrètes. Un comité supplémentaire ou un nouveau modèle de questionnaire ne résout pas, à lui seul, leur cause.

Le rôle change la preuve attendue

Une entité financière doit relier les dispositifs à ses fonctions et exigences DORA applicables. Un fabricant doit suivre la sécurité de ses produits et les canaux CRA pertinents. Une entreprise industrielle doit qualifier son éventuel périmètre NIS2 et ses exigences nationales, tout en maîtrisant les dépendances de production. Une société présente dans plusieurs pays vérifie les règles locales au lieu de copier la conclusion du siège. Les faits techniques sont partagés ; les mandats, responsabilités et sorties restent attribués.

Sources, méthode et limites

Sources officielles consultées le 4 octobre 2026. Les calendriers sont ceux des pages citées ; les situations nationales et instructions d’autorités doivent être revérifiées au moment d’une décision. Les scénarios et matrices sont pédagogiques. Ils ne constituent ni attestation de conformité ni conseil juridique.