Cinq horloges pour un même incident : la notification d’incident à l’épreuve de la simplification européenne

En une décennie, l’Europe a transformé la notification d’incident en réflexe réglementaire. En novembre 2025, elle propose de tout rationaliser d’un même geste. Entre l’empilement hérité et le remède annoncé, que fait réellement un RSSI quand l’alerte tombe à deux heures du matin ?

Cinq horloges pour un même incident : la notification d’incident à l’épreuve de la simplification européenne
Photo by K HOWARD / Unsplash

Il est 2h14. Un EDR signale une exfiltration probable depuis un service exposé, et les identifiants d’un compte d’administration circulent déjà sur un canal Telegram. Le sang-froid technique, on l’a ou on apprend à l’avoir. Ce qui s’est complexifié ces dernières années, en plus de la réponse à incident, c’est l’arrière-plan juridique qui se déclenche en même temps qu’elle.

Car selon ce qui a fuité, qui vous êtes et ce que vous vendez, un même incident peut déclencher non pas une, mais quatre ou cinq obligations de signalement distinctes, chacune avec son horloge, son autorité, son format et ses conséquences propres. C’est cet empilement, et la tentative européenne d’y remédier, que je veux dérouler ici.

Un même incident, des régimes qui se superposent

Reprenons le scénario et regardons-le, cette fois, du point de vue de la conformité.

S’il y a des données personnelles dans le bucket (et il y en a presque toujours), le RGPD impose une notification à la CNIL sous 72 heures dès lors qu’un risque pour les droits des personnes est avéré (article 33). C’est l’horloge la plus ancienne, et celle que les équipes connaissent le mieux.

Si votre organisation entre dans le périmètre de NIS2 (probable car ce périmètre a explosé, passant en France de quelques centaines d’opérateurs à une estimation de près de 15 000 entités) il s’ajoute le triptyque devenu standard : alerte précoce sous 24 heures -> notification sous 72 heures -> rapport final sous un mois, à destination de l’ANSSI et du CERT-FR.

Si vous êtes une entité financière, DORA s’applique depuis le 17 janvier 2025, avec son propre régime de classification et de notification d’incident majeur vers l’autorité compétente (ACPR ou AMF ou Banque de France selon les cas) et son fameux Registre d’Information des prestataires TIC à constituer, maintenir et transmettre.

Et si vous fabriquez ou distribuez un produit comportant des éléments numériques, le Cyber Resilience Act entrera dans la danse : à compter du 11 septembre 2026, tout fabricant devra signaler à l’ENISA et au CSIRT national les vulnérabilités activement exploitées et les incidents graves, selon un tempo qui ne vous sera pas étranger: 24 heures -> 72 heures, puis rapport final sous 14 jours après correctif.

Faites le compte. Pour un seul événement, le RSSI peut se retrouver à alimenter le RGPD, NIS2, DORA et le CRA, sans parler des obligations sectorielles ou strictement contractuelles. Quatre cadres, quatre guichets, quatre horloges qui démarrent au même instant mais ne s’arrêtent pas aux mêmes échéances.

Ce n’est plus un problème de réponse à incident. C’est un problème d’orchestration.

Pourquoi cet empilement ? Et pourquoi il a du sens

Avant de critiquer l’édifice, rendons-lui justice : il ne s’est pas construit par accident.

Le Panorama des menaces 2025 de l’ENISA, qui analyse 4 875 incidents entre juillet 2024 et juin 2025, rappelle pourquoi le législateur s’est emparé du sujet. La donnée brute est spectaculaire : près de 80 % des incidents recensés sont d’origine idéologique, portés par des campagnes DDoS hacktivistes. Le seul collectif NoName057(16) en concentre plus de 60 % via sa plateforme DDoSia.

Mais c’est ici qu’un RSSI expérimenté doit résister à une lecture paresseuse. Le volume n’est pas l’impact. L’ENISA le rappelle : à peine 2% de ces attaques DDoS provoquent une interruption réelle de service. La menace qui fait vraiment mal reste le rançongiciel, ainsi que les compromissions de la chaîne d’approvisionnement, peu nombreuses en volume mais souvent plus graves par leurs effets, leurs temps de présence, parfois de plusieurs mois, et leur objectif d’accès durable. L’administration publique est devenue la cible la plus visée, avec 38% des incidents, et les entités essentielles représentent désormais plus de la moitié des organisations touchées.

La conclusion du régulateur coule de source : si les acteurs critiques sont en première ligne et que les dépendances se propagent, alors la transparence sur les incidents devient un bien commun. On ne défend pas collectivement ce qu’on ne mesure pas. La notification obligatoire est, sur le principe, une bonne idée.

Le problème n’est donc pas l’intention. Il est que chaque texte a été pensé dans son silo : le RGPD par la donnée, NIS2 par le secteur, DORA par le risque financier, le CRA par le produit. Quatre logiques cohérentes prises séparément, qui produisent ensemble de la redondance, des doublons de déclaration et une charge de coordination qui retombe sur la même personne.

Le Digital Omnibus : la simplification par le guichet unique

Le 19 novembre 2025, la Commission européenne a présenté le Digital Omnibus, un paquet de simplification qui propose notamment un point d’entrée unique pour certaines notifications d’incidents au titre de plusieurs textes européens, dont le RGPD, NIS2 et DORA. Cette solution reste toutefois une proposition soumise au processus législatif.

Le geste s’inscrit dans un récit politique plus large, marqué par le rapport Draghi sur la compétitivité et la Boussole de compétitivité de janvier 2025. L’objectif affiché est d’alléger la charge administrative sans renoncer au cadre européen de protection.
Un guichet commun ne fusionne pas les régimes : il simplifie la notification, mais ne supprime ni les seuils, ni les autorités compétentes, ni les effets juridiques propres à chaque texte.

Enfin, l’Omnibus n’est pas encore adopté, alors que les obligations actuelles continuent de s’appliquer et que la transposition de NIS2 en France reste en cours, la Commission ayant adressé un avis motivé à la France le 7 mai 2025.

Ce que le guichet unique résout et ce qu’il déplace

Voici où je passe de l’analyse à l’interprétation, en assumant cette part de lecture.

Un guichet commun ne fusionne pas les régimes : il simplifie la déclaration, mais il ne supprime ni les seuils, ni les autorités compétentes, ni les effets juridiques propres à chaque texte.

Derrière le guichet unique, il faudra toujours déterminer quels régimes sont déclenchés par l’incident. Le gain est donc surtout opérationnel : moins de redondance, mais pas moins d’analyse.

Deuxième point : la simplification de forme peut aussi déplacer le débat vers le fond. Plusieurs analyses relèvent que le Digital Omnibus envisage de redéfinir certains aspects du RGPD, d’ouvrir une base juridique plus favorable à l’entraînement des systèmes d’IA, et de repousser certaines échéances de l’AI Act.

Soyons justes : tout cela n’a pas la même portée normative, et une partie des ajustements vise surtout à clarifier ou harmoniser des interprétations existantes. Mais d’autres touchent clairement à la substance des garanties, ce qui explique les critiques d’une partie de la doctrine et des praticiens.

Une proposition, pas encore une règle

Troisième point, essentiel : l’Omnibus n’est qu’une proposition. Le texte doit encore passer par le Parlement et le Conseil, tandis que les obligations actuelles continuent de s’appliquer.

En parallèle, la transposition de NIS2 en France reste inachevée : la Commission a adressé un avis motivé à la France le 7 mai 2025 pour défaut de notification de la transposition complète.

La situation est donc paradoxale : on promet un guichet unique pour demain, alors même que les obligations de signalement d’aujourd’hui restent fragmentées et que certaines transpositions nationales ne sont pas encore finalisées

Ce que le RSSI doit faire, maintenant

Attendre le guichet unique pour s’organiser serait une erreur. Ce qui distingue, dans la pratique, une cellule de crise préparée d’une cellule qui découvre ses obligations au milieu de la nuit, c’est l’existence de processus claires, testées et partagées en amont.

Construire une matrice de qualification d’incident. Pour chaque famille de scénario: fuite de données, indisponibilité, compromission d’un prestataire, vulnérabilité produit, cartographier à l’avance les régimes applicables, le délai le plus contraignant, l’autorité destinataire et le format attendu. Cette matrice n’est pas un livrable de conformité de plus : c’est un outil de crise, conçu pour être utilisé sous contrainte.

Piloter par l’horloge la plus contraignante. Lorsque plusieurs régimes se superposent, la procédure doit être calée sur le délai le plus exigeant, par exemple l’alerte précoce de 24 heures prévue dans certains cadres de cybersécurité, puis déclinée vers les autres obligations, comme la notification RGPD dans les 72 heures après connaissance de la violation.

Pré-rédiger les trames. Alerte précoce, notification intermédiaire, rapport final : ces documents doivent exister sous forme de gabarits, validés par le juridique et les métiers concernés, avant l’incident. On ne rédige pas une qualification réglementaire en situation d’urgence.

Intégrer la conformité à l’architecture, pas à côté. Le registre DORA des informations sur les prestataires tiers ICT, comme la documentation logicielle attendue dans l’esprit du CRA, ne sont pas des productions ponctuelles : ce sont des inventaires vivants. Cartographie des prestataires, nomenclature logicielle, clauses d’auditabilité et traçabilité doivent être intégrées au SMSI et aux plans de continuité, pas rangées dans un dossier parallèle ressorti seulement à l’audit.

Ne pas restructurer ses processus pour un guichet qui n’existe pas encore. Il faut concevoir des procédures suffisamment modulaires pour absorber, demain, un point d’entrée mutualisé, sans dépendre de lui aujourd’hui.

Conclusion : simplifier la forme sans dissoudre le fond

L’empilement réglementaire européen est réel, et la fatigue qu’il provoque dans les équipes sécurité l’est tout autant. À ce titre, un guichet unique de notification constitue une simplification opérationnelle bienvenue.

Mais il ne faut pas confondre les deux mouvements à l’œuvre. Rationaliser la déclaration d’un incident est une bonne chose ; affaiblir les obligations qui rendent cet incident déclarable en serait une autre. La vraie question posée par le Digital Omnibus n’est pas de savoir si l’Europe doit simplifier (elle le doit), mais si elle saura simplifier la tuyauterie sans toucher à l’équilibre du cadre. Le « Brussels Effect » s’est construit sur l’exigence ; il ne survivrait pas à une érosion silencieuse de ses garanties.

Pour le RSSI, en attendant, la discipline ne change pas, quel que soit le nombre de guichets. Connaître son incident. Connaître ses délais. Et n’avoir jamais à les découvrir dans l’urgence.


Vous avez peut-être remarqué une incohérence : le titre parle de 5 horloges réglementaires, mais l’article n’en décrit concrètement que 4 (RGPD, NIS2, DORA, CRA).

La cinquième, et certainement la plus importante, n’est pas écrite dans aucun texte européen.
Celle qui, en réalité, dicte le vrai tempo : l’horloge de la crise.

Celle qui commence quand l’incident se produit, quand les données partent, quand les systèmes tombent, quand la direction demande « qu’est-ce qui se passe ? » — et pas quand le RGPD ou NIS2 le permettent théoriquement.

Les 4 horloges réglementaires, vous pouvez les cartographier, les pré-rédiger, les automatiser.

La cinquième, vous ne pouvez que la respecter:

  • C'est elle qui définit votre charge mentale
  • C'est elle qui définit comment préserver les équipes de sécurité
  • C'est elle qui dit quand il faut se poser et passer le relai.

Protéger l'humain est l'objectif ultime de toute politique de sécurité (et sa première prérogative) mais il ne faut pas s'oublier soi, car comme les délais réglementaires ont des limites, nous en avons aussi, mais pas toujours formalisées.