L’article 14 contient deux obligations de notification, pas une, et leurs rapports finaux ne courent pas sur la même horloge

Le 11 septembre 2026, l’article 14 du Cyber Resilience Act devient applicable. Il arrive quinze mois avant le reste du règlement (UE) 2024/2847, généralement applicable à partir du 11 décembre 2027, et il n’attend pas que vous ayez terminé vos travaux de conformité.

C’est précisément cet écart qui pose problème. Un fabricant très loin du marquage CE, sans documentation technique ni évaluation de la conformité, reste pleinement soumis à l’article 14 dès septembre. Être à mi-parcours n’excuse pas un délai de 24 heures manqué.

La plupart des résumés de l’article 14 disent la même chose : « 24 heures, 72 heures, 14 jours ». C’est l’une des deux séquences, et la lire comme si elle résumait tout l’article produit trois erreurs prévisibles :

• traiter l’article 14 comme une seule obligation alors qu’il y en a deux, avec des déclencheurs différents,
• calculer le rapport final à 14 jours à partir de la prise de connaissance, ce qui invente un délai que le règlement ne prévoit pas,
• surveiller uniquement les CVE, alors que la seconde obligation peut se déclencher sans aucune vulnérabilité.

Ce texte s’adresse à la personne qui devra effectivement notifier, et au conseil qui doit expliquer à un client ce que septembre implique.

En bref, ce qu’il faut faire aujourd’hui (60 minutes)

• Déterminez si vous êtes fabricant d’un produit comportant des éléments numériques mis sur le marché de l’Union. Dans le cas contraire, rien de tout ceci ne s’applique, et cette détermination devrait être écrite plutôt que supposée.
• Identifiez quel CSIRT reçoit vos notifications. Il est déterminé par l’établissement principal au titre de l’article 14(7), et non par le lieu d’immatriculation.
• Consignez deux chemins d’escalade, pas un : vulnérabilité activement exploitée et incident grave.
• Corrigez le calcul des délais dans votre runbook. Les deux rapports finaux ne courent pas à partir du même événement.
• Confiez l’obligation des 24 heures à une astreinte, pas à une personne. Un délai de 24 heures qui démarre un vendredi soir est celui que l’on manque.
• Notez que l’article 14 vise les produits déjà sur le marché au 11 septembre 2026, et pas seulement ce que vous livrerez ensuite.

Les deux obligations

L’article 14(1) vise une vulnérabilité activement exploitée dans votre produit. L’article 14(3) vise un incident grave ayant une incidence sur la sécurité de votre produit. Ce sont des obligations distinctes, aux déclencheurs distincts, et les deux se notifient simultanément au CSIRT désigné comme coordinateur et à l’ENISA, via la plateforme de notification unique établie au titre de l’article 16.

C’est la seconde que les équipes manquent, parce qu’un incident grave ne suppose aucune vulnérabilité. L’article 14(5) le définit en deux branches, dont chacune suffit :

• il compromet, ou est susceptible de compromettre, 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
• il a conduit, ou est susceptible de conduire, à l’introduction ou à l’exécution de code malveillant.

Lisez « ou est susceptible de » attentivement. Un incident qui aurait pu produire ces effets relève du texte même s’ils ne se sont pas produits. Une supervision qui n’observe que les vulnérabilités publiées ne voit pas du tout cette catégorie.

Les deux horloges, qui n’ont pas la même forme

C’est la partie qui est mal rapportée, et elle mérite de la précision : les deux séquences commencent par une alerte précoce à 24 heures identique.

Pour une vulnérabilité activement exploitée, article 14(2) :

Pour un incident grave, article 14(4) :

Deux différences comptent. Le rapport final d’un incident grave est dû dans le mois suivant la notification à 72 heures, et non sous 14 jours. Et le rapport final d’une vulnérabilité court à partir de la disponibilité du correctif, non de la prise de connaissance. Un runbook qui compte 14 jours depuis la prise de connaissance notifie contre un délai inexistant, et n’aura rien d’utile à dire tant que le correctif n’existe pas.

L’alerte précoce à 24 heures pour un incident grave comporte en outre une mention absente du volet vulnérabilité : elle doit indiquer au minimum si l’incident est soupçonné de résulter d’actes illicites ou malveillants.

L’obligation que personne ne lit, parce qu’elle vient après les notifications

L’article 14(8) est une obligation envers les utilisateurs, non envers une autorité. Après avoir eu connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, le fabricant informe les utilisateurs concernés, et lorsque cela est approprié l’ensemble des utilisateurs, de la vulnérabilité ou de l’incident et, si nécessaire, des mesures d’atténuation et des mesures correctives qu’ils peuvent déployer.

Elle se trouve après les paragraphes de notification, et c’est exactement pour cela qu’on la saute. Notifier correctement son CSIRT et ne rien dire à ses clients n’est pas la conformité à l’article 14. C’est la conformité à l’essentiel de celui-ci.

Où part réellement votre notification

L’article 14(7) achemine la notification vers le point de terminaison électronique du CSIRT désigné comme coordinateur de l’État membre où se trouve votre établissement principal, c’est-à-dire là où les décisions relatives à la cybersécurité du produit sont majoritairement prises. Pour les fabricants sans établissement dans l’Union, une règle de rattachement en plusieurs étapes s’applique.

Cela mérite d’être tranché à l’avance, par écrit. Vingt-quatre heures ne suffisent pas pour établir à la fois ce qui s’est passé et à qui notifier.

Une horloge que vous ne maîtrisez pas

L’article 14(6) permet au CSIRT coordinateur de demander, lorsque cela est nécessaire, un rapport intermédiaire sur l’état d’avancement. Cela ne se planifie ni ne s’anticipe. Ce qui se prépare, c’est l’existence d’un processus capable d’y répondre, ce qui signifie en pratique que quelqu’un porte le dossier entre la notification à 72 heures et le rapport final.

Ce que cela implique si vous conseillez des fabricants

Si vous accompagnez des entreprises produit, septembre est une conversation que vous pouvez ouvrir dès maintenant, avec une date. Votre client n’a besoin ni de marquage CE, ni de documentation technique, ni d’évaluation de la conformité pour être visé. Il doit être fabricant d’un produit comportant des éléments numériques sur le marché de l’Union, et il lui faut un runbook au 11 septembre.

C’est une mission d’une netteté inhabituelle : une date fixe, un livrable délimité, et un client qui ne peut pas soutenir que l’échéance est en 2027.

Les obligations, avec le texte sur lequel elles reposent

Chaque obligation ci-dessus figure dans la carte des obligations CRA, avec le texte du Journal officiel dont elle provient et sa date d’application. La page de l’article 14 est obligations de notification des fabricants.

Deux choses qui peuvent faire gagner du temps avant septembre :

• Si vous n’êtes pas certain que le CRA vous concerne, la vérification du champ d’application du CRA y répond dans votre navigateur, avec l’article sur lequel repose chaque étape. Gratuite, sans compte, sans conservation.
• Si vous ne voulez que le calcul des délais sur une page, les délais de notification de l’article 14 y sont présentés avec leurs sources.

Rien de ceci ne constitue un conseil juridique, et une détermination est un point de départ, non une décision de conformité. Là où le CRA s’applique, les obligations qui suivent incombent au fabricant, et aucun outil ne l’en décharge.