Le 11 septembre 2026, l'article 14 du Cyber Resilience Act est entré en vigueur. Beaucoup d'équipes l'ont traité comme un événement isolé : un nouveau canal de notification, une nouvelle plateforme ENISA, un nouveau délai de 24 heures. Ce cadrage est incomplet. Pour une portion significative des organisations concernées, cet article ne s'ajoute pas à un vide : il s'ajoute à NIS2 et au RGPD, deux régimes déjà actifs. Un incident peut désormais déclencher trois processus de notification simultanés, avec des destinataires différents, des contenus différents et des délais qui s'enchevêtrent. Cette combinaison n'a pas encore été documentée par la plupart des équipes GRC.
Trois régimes, trois cadrans, une seule équipe
Le premier régime est le CRA, article 14. Il s'applique aux fabricants de produits comportant des éléments numériques : matériels, logiciels, solutions embarquées. Dès qu'un fabricant prend connaissance d'une vulnérabilité activement exploitée ou d'un incident grave affectant son produit, il dispose de 24 heures pour soumettre une alerte précoce à la plateforme ENISA Single Reporting Platform (SRP). La notification complète suit dans les 72 heures. Le rapport final est dû 14 jours après la disponibilité d'un correctif pour une vulnérabilité activement exploitée, ou dans le mois suivant la notification de 72 heures pour un incident grave.
Le deuxième régime est NIS2. Il s'applique aux entités essentielles et importantes : opérateurs de services numériques, entités financières, établissements de santé, fournisseurs d'infrastructures. En cas d'incident significatif, l'entité dispose de 24 heures pour envoyer une alerte précoce à l'autorité nationale compétente (en France, le CERT-FR via le portail MonEspaceNIS2), de 72 heures pour la notification complète, et d'un mois pour le rapport final.
Le troisième régime est le RGPD, article 33. Il s'applique à tout responsable de traitement qui subit une violation de données à caractère personnel. La notification à l'autorité de contrôle compétente (la CNIL en France) est due dans les 72 heures suivant la prise de connaissance de la violation, sauf si celle-ci est « peu susceptible d'engendrer un risque pour les droits et libertés des personnes physiques ».
Qui cumule les trois ?
La population concernée est plus large qu'on ne l'imagine. Elle inclut notamment les éditeurs de logiciels B2B qui fournissent des entités du secteur financier (soumis à DORA et NIS2), les hébergeurs de données de santé certifiés HDS, les fournisseurs de services cloud classifiés entités importantes sous NIS2, et plus généralement tout éditeur SaaS qui traite des données personnelles de clients professionnels à grande échelle et dont le logiciel est qualifié de produit avec éléments numériques au sens du CRA.
Selon l'analyse d'impact publiée par la Commission européenne en octobre 2022, le CRA couvre plus de 160 000 fabricants à l'échelle mondiale. Parmi eux, une fraction significative opère également comme entité NIS2 ou DORA et traite des données personnelles. Ces organisations n'ont pas un problème de notification : elles en ont trois.
Un exemple : le SaaS financier au 14 septembre
Un éditeur de logiciels de conformité pour le secteur bancaire découvre ce matin qu'un composant d'authentification de sa plateforme fait l'objet d'une exploitation active. L'incident a entraîné l'accès non autorisé à des données clients, dont des noms, des identifiants et des journaux de transactions. La plateforme a subi une interruption de service de cinq heures la nuit précédente.
À 9h00, les trois cadrans démarrent simultanément. Le CRA impose une alerte précoce à la SRP avant 9h00 le lendemain. NIS2 impose une alerte précoce au CERT-FR avant 9h00 le lendemain. Le RGPD impose une notification à la CNIL avant 9h00 après-demain. Ces délais ne se substituent pas l'un à l'autre : ils s'empilent. L'équipe doit produire trois documents distincts, vers trois portails distincts, avec trois définitions légèrement différentes de ce qui doit y figurer.
L'alerte CRA porte sur la vulnérabilité et le produit. L'alerte NIS2 porte sur l'impact sur le service. La notification RGPD porte sur la nature et le volume des données affectées, les catégories de personnes concernées et les mesures prises. Ces contenus se recoupent partiellement mais ne se substituent pas. Un document unique ne satisfait aucun des trois régimes.
Les frictions structurelles
Trois différences rendent le processus difficile à gérer de manière unifiée. La première est le déclencheur : sous le CRA, c'est la prise de connaissance d'une vulnérabilité activement exploitée ; sous NIS2, c'est l'incident significatif affectant le service ; sous RGPD, c'est la violation de données personnelles. Ces trois événements peuvent intervenir simultanément, comme dans l'exemple ci-dessus, ou à des moments différents selon la séquence de l'incident. Le même événement peut déclencher les trois à la même heure, ou la chaîne peut se dérouler sur plusieurs jours.
La deuxième friction est organisationnelle. Les équipes qui gèrent les notifications CRA sont souvent distinctes de celles qui gèrent NIS2 (sécurité opérationnelle) et RGPD (DPO ou équipe juridique). En cas d'incident, la coordination entre ces trois équipes sous pression, avec des délais de 24 heures sur deux des trois obligations, suppose une chaîne d'escalade que beaucoup d'organisations n'ont pas encore formalisée. Les contrôles de l'ACPR en 2026 ont identifié que 35 % des entités inspectées présentaient des insuffisances significatives dans leur cadre de gestion des risques ICT, incluant les lacunes dans les processus de détection et d'escalade des incidents. Ce chiffre illustre l'écart entre la conformité documentaire et la préparation opérationnelle réelle.
La troisième friction est le suivi post-incident. Les rapports finaux ont des délais différents selon le régime : 14 jours (CRA, vulnérabilité activement exploitée), un mois (NIS2 et CRA incidents graves), 72 heures initiales puis rapport complémentaire sans délai fixe (RGPD). Une organisation qui suit ses obligations post-incident dans un seul tableau de bord doit gérer au moins cinq livrables sur des calendriers distincts pour un incident unique déclenchant les trois régimes.
Ce que votre organisation doit préparer
Quatre actions permettent de réduire le risque d'improvisation.
La première est la cartographie des incidents déclencheurs. Dressez la liste des types d'incidents qui, dans votre environnement spécifique, peuvent simultanément déclencher le CRA, NIS2 et le RGPD. Pour chaque type, identifiez les déclencheurs précis de chaque régime et les délais qui s'appliquent. Cette cartographie est la base de tout le reste.
La deuxième est la désignation d'un coordinateur de notification. Il ne s'agit pas d'une personne qui rédige les trois notifications, mais d'une personne qui tient le tableau de bord, vérifie que les trois délais sont respectés et coordonne les équipes CRA, NIS2 et RGPD. Sans ce rôle, chaque équipe notifie dans son couloir sans vue d'ensemble sur les obligations parallèles.
La troisième est la construction d'un formulaire d'intake commun. Un premier document d'évaluation, rempli dans les premières heures de l'incident, doit permettre d'alimenter simultanément les trois ébauches de notification. Les champs se recoupent suffisamment pour que ce travail ne soit pas triplé, à condition qu'il soit structuré en amont.
La quatrième est un exercice de simulation. Organisez un exercice sur table où un incident déclenche les trois régimes simultanément. Cet exercice révélera les lacunes de coordination que les procédures sur papier ne font pas apparaître. Les équipes qui ont simulé ce processus, même une seule fois, arrivent à un incident réel avec un avantage mesurable. L'article sur les cinq pièges opérationnels de la notification NIS2 en 24 heures décrit les erreurs les plus fréquentes sur ce seul régime — ils s'appliquent, mutatis mutandis, aux deux autres.
La fenêtre de préparation
L'entrée en vigueur de l'article 14 du CRA le 11 septembre 2026 marque l'activation du troisième régime. Les organisations qui ont traité CRA, NIS2 et RGPD comme trois projets distincts ont maintenant une raison concrète de les réunir dans un processus de notification intégré. Ce travail de coordination ne prend pas de budget exceptionnel. Il prend du temps et une décision : désigner un responsable, cartographier les scénarios de cumul, tester le processus une fois avant qu'un incident ne force l'improvisation.
La prochaine fois que trois cadrans démarrent simultanément, votre organisation sera dans l'un de deux états : elle aura répété ce scénario, ou elle le découvrira en conditions réelles.