L'obligation de notification du règlement sur la cyberrésilience, article 14 du règlement (UE) 2024/2847, s'explique d'ordinaire par ses horloges : 24 heures, 72 heures et un rapport final. Les horloges ne démarrent que lorsque l'une de deux choses se produit, et les deux sont définies dans le règlement plus étroitement que la plupart des résumés ne le laissent entendre. Tout notifier est un échec autant que ne rien notifier : cela submerge le CSIRT, n'apprend rien aux utilisateurs et habitue l'organisation à ignorer sa propre procédure.

Voici les deux déclencheurs tels que le texte les définit, et la ligne que chacun trace.

Déclencheur un : une vulnérabilité activement exploitée

L'article 14, paragraphe 1, impose au fabricant de notifier « toute vulnérabilité activement exploitée contenue dans le produit comportant des éléments numériques dont il a connaissance ».

L'article 3, point 42, définit le terme : une vulnérabilité activement exploitée est « 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 ».

Trois mots portent la définition.

« Preuves fiables. » Pas le score de gravité d'un scanner, pas une preuve de concept sur un blog de sécurité, pas une CVE assortie d'une rumeur d'« exploitation dans la nature ». Des preuves que l'exploitation a eu lieu, d'une qualité sur laquelle vous agiriez. Les lignes directrices de la Commission du 27 juillet 2026 fixent la connaissance à un degré raisonnable de certitude : ni la première rumeur, ni la fin de l'analyse forensique.

« Un acteur malveillant. » L'exploitation par vos propres testeurs d'intrusion, par un chercheur qui l'a signalée de façon responsable, ou par un client testant son propre déploiement n'est pas une exploitation par un acteur malveillant. La vulnérabilité peut être grave ; elle n'est pas, sur cette seule base, un déclencheur.

« Dans un système. » N'importe quel système, pas seulement celui de votre client. Des preuves fiables que la vulnérabilité de votre produit a été exploitée par un attaquant quelque part suffisent ; vous n'attendez pas qu'un de vos propres utilisateurs soit touché.

Ce qui est dehors : les vulnérabilités théoriques, les preuves de concept non exploitées, les vulnérabilités trouvées par vos propres tests, et les vulnérabilités de composants connues et en cours de correction pour lesquelles il n'existe aucune preuve d'exploitation. Ce sont des travaux de l'annexe I, partie II, traités et divulgués au titre des exigences de gestion des vulnérabilités, pas des notifications de l'article 14.

Déclencheur deux : un incident grave ayant un impact sur la sécurité du produit

L'article 14, paragraphe 3, impose la notification de « tout incident grave ayant un impact sur la sécurité du produit comportant des éléments numériques ». L'article 14, paragraphe 5, dit quand un incident est grave :

a) il a ou est susceptible d'avoir une incidence négative sur la capacité d'un produit comportant des éléments numériques à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ; ou b) il a conduit ou est susceptible de conduire à l'introduction ou à l'exécution de code malveillant dans un produit comportant des éléments numériques ou dans les réseaux et systèmes d'information d'un utilisateur du produit.

Deux choses à remarquer.

« Est susceptible de. » Les deux branches couvrent les incidents qui pourraient avoir l'effet, pas seulement ceux qui l'ont eu. Un incident contenu avant toute perte de données reste grave s'il était susceptible de la provoquer.

Il s'agit de la sécurité du produit, pas de celle de votre entreprise. Une intrusion dans votre messagerie d'entreprise est un incident, et au titre de NIS2 il peut être à notifier, mais ce n'est un déclencheur de l'article 14 que s'il a un impact sur la sécurité du produit que vous mettez sur le marché : votre chaîne de construction, votre serveur de mise à jour, la clé de signature, le back-end en nuage dont un produit dépend. Le test est de savoir si la capacité du produit à protéger les données ou fonctions de ses utilisateurs est affectée, ou si du code malveillant pourrait atteindre le produit ou les systèmes de ses utilisateurs par ce biais.

La troisième obligation qui accompagne les deux : informer vos utilisateurs

Article 14, paragraphe 8 : après avoir eu connaissance de l'un ou l'autre déclencheur, le fabricant « informe les utilisateurs touchés du produit comportant des éléments numériques et, le cas échéant, tous les utilisateurs, de cette vulnérabilité ou de cet incident et, si nécessaire, des mesures d'atténuation des risques et des mesures correctives que les utilisateurs peuvent déployer pour en atténuer l'impact », le cas échéant dans un format structuré et lisible par machine. Si le fabricant n'informe pas les utilisateurs en temps utile, le CSIRT peut le faire à sa place.

C'est l'obligation que la plupart des procédures de notification oublient. Le CSIRT et l'ENISA sont un destinataire. Les utilisateurs sont l'autre, et le moyen de les atteindre, la formulation et le format lisible par machine sont à décider avant le jour venu.

Non notifiable reste à consigner

Une vulnérabilité ou un incident qui ne répond à aucune des deux définitions n'est pas notifié au titre de l'article 14, mais la détermination qu'il n'y répond pas est un enregistrement à conserver : ce qui s'est passé, pourquoi il a été jugé ne pas relever de 3, point 42, ou de 14, paragraphe 5, qui l'a jugé et quand. Si les preuves changent, la connaissance au sens de l'article 14 commence alors, et l'enregistrement montre que l'horloge était surveillée. C'est la différence entre une entreprise qui a décidé de ne pas notifier et une qui n'a rien remarqué.

Quoi faire

Écrivez les deux définitions dans la procédure d'incident mot pour mot, avec les trois questions pour chacune : existe-t-il des preuves fiables, d'une exploitation par un acteur malveillant, dans un système quelconque ; l'incident affecte-t-il ou menace-t-il la protection par le produit de données ou fonctions sensibles, ou du code malveillant dans le produit ou les systèmes d'un utilisateur. Nommez qui tranche, et consignez chaque décision, y compris le « non ». Puis les horloges, vers votre CSIRT et l'ENISA, et le message aux utilisateurs.

Sources

  • Règlement (UE) 2024/2847, article 3, point 42 (cité), article 14, paragraphes 1, 3, 5 (cité) et 8 (cité). Lu dans le texte du Journal officiel sur EUR-Lex le 11 septembre 2026.
  • Lignes directrices de la Commission européenne C(2026) 5252 du 27 juillet 2026, sur le sens de la connaissance.

Ceci n'est pas un avis juridique. Les deux définitions sont deux phrases du règlement ; elles ont leur place dans votre procédure telles qu'écrites, pas telles que mémorisées.