Presque tous les résumés de l'obligation de notification du règlement sur la cyberrésilience la présentent comme trois délais comptés depuis le même instant : une alerte précoce sous 24 heures, une notification sous 72 heures, un rapport final sous 14 jours. Les deux premiers sont exacts. Le troisième est faux, et faux d'une manière qui compte le jour venu.
L'article 14 du règlement (UE) 2024/2847 s'applique depuis le 11 septembre 2026. Voici ce qu'il dit, et où les 14 jours commencent réellement.
Deux voies, trois délais chacune
L'article 14 établit deux voies de notification distinctes. Le paragraphe 1 crée l'obligation de notifier une vulnérabilité activement exploitée dans un produit comportant des éléments numériques. Le paragraphe 3 crée l'obligation de notifier un incident grave ayant un impact sur la sécurité d'un tel produit. Aucun des deux paragraphes ne parle de délai. Les délais figurent aux paragraphes 2 et 4, qui commencent chacun par « aux fins de la notification visée au paragraphe 1 » (ou 3) et énumèrent trois points.
Pour une vulnérabilité activement exploitée, article 14, paragraphe 2 :
| Étape | Délai | Court à partir de |
|---|---|---|
| a) Alerte précoce | 24 heures | la connaissance par le fabricant |
| b) Notification de vulnérabilité | 72 heures | la connaissance par le fabricant |
| c) Rapport final | 14 jours | la disponibilité d'une mesure corrective ou d'atténuation |
Pour un incident grave, article 14, paragraphe 4 :
| Étape | Délai | Court à partir de |
|---|---|---|
| a) Alerte précoce | 24 heures | la connaissance par le fabricant |
| b) Notification d'incident | 72 heures | la connaissance par le fabricant |
| c) Rapport final | un mois | la soumission de la notification visée au point b) |
Les deux rapports finaux ont des points de départ différents, et aucun des deux n'est la connaissance.
Ce que cela signifie pour une vulnérabilité
L'article 14, paragraphe 2, point c), dit, dans sa partie opérante : le rapport final est dû « au plus tard 14 jours après qu'une mesure corrective ou d'atténuation est disponible ». La mesure est le point de départ. Pas l'exploitation, pas la découverte, pas la notification de 72 heures.
Trois conséquences en découlent, et la pratique se trompe sur les trois.
Le délai du rapport final peut ne pas encore exister. Si vous avez déposé l'alerte précoce et la notification et que vous travaillez encore à un correctif, il n'y a pas de date. Pas une date lointaine, pas de date. Un outil qui affiche « rapport final dû le 25 septembre » quatorze jours après votre prise de connaissance a inventé un délai que le règlement ne fixe pas. Un outil qui affiche « pas de délai tant qu'une mesure corrective n'est pas disponible » lit le texte.
Un contournement déclenche l'horloge, pas seulement un correctif. Le libellé est « mesure corrective ou d'atténuation ». Un changement de configuration documenté, une fonctionnalité que vous demandez aux clients de désactiver, une règle réseau : si cela atténue l'exploitation et que vous l'avez rendu disponible, les 14 jours ont commencé, que le correctif de code soit prêt ou non. Les équipes qui supposent que l'horloge attend la livraison seront en retard.
La date à consigner est celle où la mesure est devenue disponible, pas celle où vous l'avez diffusée. Un correctif construit le lundi, publié le mercredi et annoncé le vendredi : la lecture honnête est mercredi, le jour où un utilisateur pouvait l'obtenir. Notez ce jour sur le moment, parce que dans le rapport final vous le décrirez.
Ce que cela signifie pour un incident
L'article 14, paragraphe 4, point c), court à partir de la soumission de la notification de 72 heures, et la période est « un mois », un mois calendaire et non 30 jours. Le rapport final n'a pas de délai tant que la notification n'est pas déposée, et une fois qu'elle l'est, le délai est fixé par l'heure du dépôt et par rien d'autre.
Les mois calendaires ont un cas limite qu'un tableur rate. Une notification soumise le 31 janvier reçoit sa réponse au plus tard le 28 février (29 une année bissextile), parce que le 31 février n'existe pas et que le mois finit où il finit. Un logiciel qui ajoute 30 jours atterrit le 2 mars ; un logiciel qui ajoute un mois avec une arithmétique de dates naïve bascule en mars. Les deux vous offrent en silence des jours que vous n'avez pas. Notre calculateur borne à la fin du mois, et c'est la même fonction que le produit exécute, pas une copie écrite pour la page.
Pourquoi la connaissance reste le moment qui compte le plus
Rien de tout cela ne rend l'horodatage de la connaissance moins important. Il ancre deux des trois délais sur les deux voies, et les lignes directrices de la Commission du 27 juillet 2026 fixent le seuil de la connaissance à un degré raisonnable de certitude qu'une vulnérabilité de votre produit est activement exploitée : ni la première rumeur, ni la fin de l'analyse forensique. « Activement exploitée » est elle-même définie à l'article 3, point 42), comme une vulnérabilité « pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée dans un système sans l'autorisation du propriétaire du système », ce qui exclut les vulnérabilités théoriques et les preuves de concept non exploitées.
L'enregistrement dont vous avez besoin est donc trois horodatages, pas un :
- quand vous avez eu connaissance, au sens de la Commission ;
- quand vous avez soumis la notification de 72 heures ;
- quand une mesure corrective ou d'atténuation est devenue disponible.
Le premier déclenche les horloges de l'alerte précoce et de la notification. Le deuxième déclenche le rapport final d'incident. Le troisième déclenche le rapport final de vulnérabilité. Une procédure qui ne capture que le premier produira une date de rapport final assurée et fausse, et une entreprise qui manque la vraie se trouve dans le palier de sanction le plus élevé au titre de l'article 64, paragraphe 2, aux côtés des exigences de l'annexe I elles-mêmes.
La version courte à mettre dans votre procédure
- 24 heures et 72 heures courent à partir de la connaissance, sur les deux voies.
- Le rapport final de vulnérabilité court 14 jours à partir de la disponibilité d'une mesure corrective ou d'atténuation. Tant qu'il n'y en a pas, il n'y a pas de délai, et vous devriez le dire plutôt qu'en afficher un.
- Le rapport final d'incident court un mois calendaire à partir de la notification de 72 heures.
- Consignez les trois moments de départ quand ils surviennent, parce que le rapport les demandera.
Où va le rapport est l'autre moitié de la question, et la réponse est une équipe précise dans un État membre précis, choisie par une règle sur votre entreprise plutôt que sur l'incident.
Sources
- Règlement (UE) 2024/2847, article 14, paragraphes 1 à 4, lu dans le texte consolidé sur EUR-Lex ; article 3 pour la définition d'une vulnérabilité activement exploitée ; article 64, paragraphe 2, pour le palier de sanction ; article 71, paragraphe 2, pour la date d'application.
- Lignes directrices de la Commission européenne C(2026) 5252 du 27 juillet 2026, sur le sens de la connaissance et de l'exploitation active.
Ceci n'est pas un avis juridique. L'article 14 est court, et les renvois aux paragraphes ci-dessus sont là pour que vous puissiez vérifier la lecture plutôt que l'adopter.