Depuis le 11 septembre 2026, un fabricant de produits comportant des éléments numériques qui prend connaissance d’une vulnérabilité activement exploitée dans l’un de ses produits, ou d’un incident grave affectant leur sécurité, doit envoyer une alerte précoce dans les 24 heures. Il le fait par la plateforme unique que l’ENISA, l’agence européenne de cybersécurité, a ouverte le même jour, et dont elle décrit elle-même la mise en service comme une « capacité opérationnelle initiale » (traduction ELMARQ), dans son communiqué du 11 septembre. La foire aux questions de la plateforme, mise à jour le 15 octobre 2026, en donne la mesure concrète : une interface en anglais seulement, aucune interface de programmation, des comptes strictement personnels, et un compteur qui affiche l’échéance des 72 heures 48 heures après l’envoi de l’alerte, et non à partir du moment où le fabricant a pris connaissance de l’événement.
Ces détails d’outil déplacent la question pour un dirigeant. L’alerte réglementaire part avant le communiqué, souvent avant que la cause soit connue, et elle part du compte d’une personne nommée. Le même incident peut en outre engager l’entreprise à 3 titres : comme fabricant d’un produit, au titre du règlement sur la cyberrésilience ; comme opérateur d’un service, au titre de la directive NIS 2, que la France n’a pas encore transposée ; comme responsable de traitement, au titre du RGPD si des données personnelles sont touchées. Soit 3 destinataires, 3 délais qui se ressemblent et 3 points de départ distincts. Le communiqué arrive après tout cela.
Qui doit alerter, et à partir de quel signal ?
L’article 14 du règlement sur la cyberrésilience vise le fabricant. Pour une vulnérabilité activement exploitée, c’est-à-dire une faille dont il existe une preuve fiable qu’un acteur malveillant l’a exploitée, il doit envoyer une alerte précoce « au plus tard 24 heures après en avoir eu connaissance », une notification « au plus tard 72 heures » après, puis un rapport final « au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation ». Pour un incident grave, le rapport final est dû dans le délai de 1 mois à compter de la notification. Un incident est grave lorsqu’il entache, ou peut entacher, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou lorsqu’il conduit, ou peut conduire, à l’introduction ou à l’exécution d’un code malveillant dans le produit ou dans les systèmes d’un utilisateur. La notification va au CSIRT coordinateur de l’État où se prennent principalement les décisions de cybersécurité du fabricant ; pour la France, la liste de l’ENISA renvoie au CERT-FR. Le manquement à l’article 14 expose à une amende administrative pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, selon l’article 64.
Le champ est plus large que ne le croient beaucoup d’industriels. Selon la FAQ de la Commission publiée le 3 décembre 2025, l’obligation couvre aussi les produits mis sur le marché avant décembre 2027. Lorsqu’une faille exploitée vient d’un composant intégré, le fabricant du produit doit la notifier, et le fabricant du composant aussi si celui-ci a été mis sur le marché. Une faille dont le fabricant avait connaissance avant le 11 septembre 2026 n’a pas à être déclarée rétroactivement ; une faille ancienne découverte exploitée après cette date, si. Pour les gestionnaires de logiciels libres, les obligations correspondantes ne s’appliqueront qu’à partir du 11 décembre 2027, comme le rappelle la page de la Commission.
Reste le point de départ. Nous avions montré, dans notre analyse du 12 septembre 2026, que le délai de 24 heures est tenable et que l’instant à partir duquel il se compte, la prise de connaissance, ne l’est pas. La Commission le confirme sans détour : le règlement « ne précise pas comment un fabricant doit prendre connaissance » d’une vulnérabilité ou d’un incident (traduction ELMARQ). Elle cite des voies possibles, un client, un chercheur, une agence publique, la télémétrie, et précise que cette liste n’impose aucune surveillance particulière.
Que demande la plateforme le jour où il faut notifier ?
La FAQ de l’ENISA décrit un outil qui impose une organisation. Chaque déclarant agit avec son propre compte EU Login, protégé par une authentification à plusieurs facteurs : « les comptes EU Login sont personnels » (traduction ELMARQ). Un fabricant compte 1 seul représentant principal, qui administre l’accès, et jusqu’à 20 représentants secondaires. L’association entre un représentant et l’entreprise est validée par le CSIRT, à son rythme ; en attendant, un représentant peut déposer jusqu’à 20 notifications. L’agence recommande pourtant de ne s’enregistrer qu’au moment où une notification est nécessaire, pour limiter la charge des CSIRT. Les brouillons sont stockés dans le compte de chaque représentant et restent invisibles pour ses collègues. Aucune interface de programmation n’est prévue au lancement : la notification se saisit à la main, en anglais.
Si la plateforme est indisponible, le fabricant doit attendre son retour, ou contacter directement son CSIRT s’il juge une communication immédiate nécessaire, puis déposer quand même sa notification une fois le service rétabli. Le compteur, enfin, ne suit pas le droit. L’agence l’écrit : dans la version actuelle, l’échéance affichée est fixée 48 heures après l’alerte précoce, si bien qu’une notification peut apparaître en retard avant que 72 heures se soient écoulées depuis la prise de connaissance. Selon le calcul d’ELMARQ, une alerte envoyée 6 heures après la prise de connaissance fait afficher une échéance à 54 heures, soit 18 heures avant l’échéance légale ; les 2 ne coïncident que pour une alerte envoyée à la 24e heure. L’erreur joue dans le sens de la prudence, mais elle rappelle que l’horodatage qui compte est celui que l’entreprise aura consigné elle-même. Sur la plateforme européenne de signalement, l’alerte part d’un compte personnel : les déclarants se désignent avant l’incident, pas pendant les 24 heures.
Combien d’horloges un même incident déclenche-t-il ?
Le règlement sur la cyberrésilience s’ajoute aux régimes existants sans les remplacer. La directive NIS 2 impose aux entités essentielles et importantes de notifier tout incident important à leur CSIRT ou à leur autorité compétente : alerte précoce dans les 24 heures, notification dans les 72 heures, rapport final au plus tard 1 mois après. Elle ajoute une phrase que les directions juridiques devraient lire aux comités de crise : « Le simple fait de notifier un incident n’accroît pas la responsabilité de l’entité qui est à l’origine de la notification. » Le RGPD, lui, demande au responsable de traitement de notifier une violation de données à la CNIL « dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance », avec les motifs d’un éventuel retard, puis d’informer les personnes concernées lorsque le risque pour elles est élevé. Sur ce dernier point, la Commission tranche dans sa FAQ : entre le règlement sur la cyberrésilience et le RGPD, il n’existe « aucun chevauchement juridique » (traduction ELMARQ). Les 2 notifications sont donc distinctes.

| Régime | L’entreprise agit comme | Ce qui déclenche | Destinataire | Délais | Statut au 11 novembre 2026 |
|---|---|---|---|---|---|
| Règlement sur la cyberrésilience, article 14 | Fabricant d’un produit | Vulnérabilité activement exploitée ou incident grave touchant le produit | CSIRT coordinateur (CERT-FR en France) et ENISA, par la plateforme unique | Alerte en 24 heures, notification en 72 heures, rapport final à 14 jours du correctif ou à 1 mois | Applicable depuis le 11 septembre 2026 |
| Directive NIS 2, article 23 | Entité essentielle ou importante | Incident important touchant ses services | CSIRT ou autorité compétente | Alerte en 24 heures, notification en 72 heures, rapport final à 1 mois | Non transposée en France |
| RGPD, articles 33 et 34 | Responsable de traitement | Violation de données personnelles présentant un risque | CNIL, puis personnes concernées si le risque est élevé | Notification en 72 heures si possible, motifs du retard sinon | Applicable |
En France, la colonne NIS 2 reste conditionnelle. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat le 12 mars 2025 selon son dossier législatif, a été transmis à l’Assemblée nationale le 13 mars 2025 sous le n° 1112, adopté en commission spéciale le 10 septembre 2025 (texte n° 1779), et sa discussion en séance publique s’est ouverte le lundi 9 novembre 2026, selon le dossier législatif de l’Assemblée. Près de 20 mois ont donc séparé le vote du Sénat de l’examen en séance. Le Monde Informatique évalue à près de 15 000 le nombre d’organisations concernées. Le 8 juillet 2026, la Commission avait saisi la Cour de justice contre la France, l’Irlande, l’Espagne et les Pays-Bas, en demandant des sanctions financières. Un fabricant français qui exploite aussi un service essentiel connaît donc aujourd’hui avec certitude 2 de ses 3 horloges.
Bruxelles a vu la difficulté. Dans son omnibus numérique de novembre 2025, la Commission propose un guichet unique, géré par l’ENISA sur l’expérience de la plateforme du règlement sur la cyberrésilience, pour déposer en 1 fois les notifications dues au titre de NIS 2, du RGPD, du règlement DORA et d’autres textes. Sa FAQ précise que ce guichet « ne modifiera pas les obligations de signalement existantes ni les autorités désignées » pour les recevoir (traduction ELMARQ). Même adopté, il simplifierait la saisie ; il ne fusionnerait ni les déclencheurs ni les destinataires. Un même incident peut engager une entreprise comme fabricant, comme opérateur et comme responsable de traitement, avec 3 points de départ que nul outil ne fusionne.
L’arbitrage déplacé : qui parle aux utilisateurs ?
Le paragraphe 8 de l’article 14 est le plus important pour une direction de la communication, et le moins commenté. Après avoir pris connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant « informe les utilisateurs du produit comportant des éléments numériques touchés et, s’il y a lieu, tous les utilisateurs », ainsi que des mesures qu’ils peuvent prendre. La phrase suivante change l’équilibre : « Lorsque le fabricant n’informe pas les utilisateurs du produit comportant des éléments numériques en temps utile, les CSIRT notifiés désignés comme coordinateurs peuvent fournir ces informations aux utilisateurs lorsqu’ils le jugent proportionné et nécessaire pour prévenir ou atténuer les répercussions de cette vulnérabilité ou de cet incident. » La FAQ de la Commission le reprend dans les mêmes termes.
Le calendrier de la parole n’est donc plus entièrement entre les mains de l’entreprise. Elle garde la maîtrise de sa communication publique, mais le message aux utilisateurs exposés, lui, est une obligation, et une autorité peut s’y substituer. Dans l’autre sens, le règlement ménage une protection : dans des « circonstances particulièrement exceptionnelles », le CSIRT peut retarder la diffusion de la notification aux autres États, y compris à la demande du fabricant, selon des conditions qu’un acte délégué du 11 décembre 2025 précise. NIS 2 prévoit de son côté l’information des destinataires des services, et le RGPD celle des personnes concernées. Nous relevions en septembre, à propos de l’audit de la Cour des comptes européenne du 21 septembre 2026, qu’aucun État membre n’avait déclaré d’incident cyber de grande ampleur depuis 2016 : les dispositifs existent, c’est le seuil de déclaration qui fait défaut. Le règlement sur la cyberrésilience autorise le CSIRT à informer lui-même les utilisateurs si le fabricant tarde : la parole sur l’incident n’appartient plus entièrement à l’entreprise.
| Fait | Source | Limite |
|---|---|---|
| Alerte sous 24 heures, notification sous 72 heures, rapport final | Règlement (UE) 2024/2847, article 14 | La prise de connaissance n’est définie par aucun texte |
| Plateforme opérationnelle le 11 septembre 2026 | ENISA, communiqué du 11 septembre 2026 | Capacité initiale ; signalement volontaire prévu plus tard |
| Compteur des 72 heures calé sur l’alerte précoce | ENISA, FAQ mise à jour le 15 octobre 2026 | Correction annoncée sans date |
| Le CSIRT peut informer les utilisateurs à la place du fabricant | Règlement (UE) 2024/2847, article 14, paragraphe 8 | Aucun cas d’application public retrouvé |
| Projet de loi NIS 2 en séance du 9 au 13 novembre 2026 | Le Monde Informatique, 10 novembre 2026 | Vote et promulgation à confirmer |
| Guichet unique de signalement | Commission, FAQ de l’omnibus numérique, 20 novembre 2025 | Proposition, non adoptée |
Les faits à vérifier d’ici à décembre 2027
Le premier test est immédiat. Si l’Assemblée nationale adopte cette semaine le projet de loi de transposition, une commission mixte paritaire ou une nouvelle lecture, puis la promulgation et les décrets d’application, diront quand l’horloge NIS 2 s’imposera aux entreprises françaises ; un nouveau report la laisserait suspendue, sous la menace d’une condamnation par la Cour de justice. Le 2e test tient à l’outil : l’ENISA a annoncé que le compteur des 72 heures serait recalculé à partir de l’heure de prise de connaissance ; la date de cette correction n’est pas fixée. Le 3e est documentaire : l’agence doit publier un rapport de tendances tous les 2 ans, le 1er dans les 24 mois suivant l’entrée en application des obligations, soit au plus tard en septembre 2028 selon le calcul d’ELMARQ. Ce sera la 1re mesure publique du nombre et de la nature des notifications. D’ici là, le 11 décembre 2027, le reste du règlement entrera en application et les gestionnaires de logiciels libres rejoindront le circuit. L’ANSSI résume ce calendrier en une phrase : le règlement « entrera en application progressivement entre juin 2026 et décembre 2027 ». Le signalement de septembre 2026 n’en est que la 1re marche visible pour les entreprises. Pour s’y préparer, la Commission a publié le 27 juillet 2026 des lignes directrices (document C(2026) 5252) qui traitent notamment de « How to meet reporting obligations », avec 67 exemples pratiques destinés en particulier aux PME. Elles sont « non-binding » : elles éclairent l’obligation sans la modifier.
Pour une entreprise, le test le plus utile ne dépend d’aucune de ces dates. Il consiste à vérifier, sur un exercice à froid, que les déclarants ont un compte actif, que l’heure zéro est consignée par quelqu’un, et que le message aux utilisateurs peut être validé dans le délai. Si l’une de ces 3 conditions manque, le premier incident réel le révélera devant une autorité.
Le communiqué reste nécessaire. Il vient simplement après une alerte déjà partie, d’un compte nominatif, vers une autorité qui peut parler aux utilisateurs si l’entreprise se tait. C’est cette chaîne qu’il faut avoir construite avant la nuit où elle servira.
Le règlement (UE) 2024/2847, la directive (UE) 2022/2555 et le règlement (UE) 2016/679 ont été lus sur EUR-Lex en version française. La page de la Commission sur les obligations de signalement (mise à jour du 11 septembre 2026), sa FAQ sur la mise en œuvre du règlement (3 décembre 2025), la FAQ de l’omnibus numérique (20 novembre 2025) et le communiqué du 8 juillet 2026 sur NIS 2 ont été lus en anglais ; le communiqué de l’ENISA du 11 septembre 2026, la FAQ de la plateforme mise à jour le 15 octobre 2026 et la liste des CSIRT coordinateurs également ; les citations traduites le sont par ELMARQ. Le dossier législatif du Sénat (projet de loi n° 33, 2024-2025) a été consulté sur senat.fr ; le calendrier d’examen à l’Assemblée nationale est cité d’après Le Monde Informatique du 10 novembre 2026. L’écart entre le compteur de la plateforme et l’échéance légale, et l’échéance de septembre 2028, sont des calculs d’ELMARQ. Aucun retard de notification d’une entreprise n’est allégué. Aucune personne privée n’est nommée. Marc Lugand-Sacy, fondateur et président d’ELMARQ, a dirigé la communication d’une préfecture.



