L'article 14 est celui qui déclenche l'horloge

Vous ne savez pas si le CRA s'applique à votre produit ? Vérifiez votre classe de risque en quatre étapes.

1. Ce qu'exige l'article 14

L'article 14 impose au fabricant d'un produit comportant des éléments numériques de signaler deux types d'événements : toute vulnérabilité activement exploitée présente dans le produit, et tout incident grave ayant une incidence sur la sécurité de ce produit. L'obligation vise le CSIRT désigné comme coordinateur et, en parallèle, l'ENISA, via la plateforme de signalement unique.

L'assujetti est le fabricant, ni le revendeur ni l'utilisateur final : celui qui développe ou fabrique le produit, ou le fait développer ou fabriquer et le commercialise sous son nom ou sa marque, porte l'obligation. Le champ est le produit mis sur le marché, quelle que soit sa date de première vente. Un produit commercialisé depuis des années entre pleinement dans le champ.

2. Les trois délais, sur deux chaînes parallèles

Chaque événement à signaler passe par trois étapes : une alerte précoce, une notification de vulnérabilité et un rapport final. Les deux premiers délais sont identiques sur les deux chaînes — 24 heures pour l'alerte précoce, 72 heures pour la notification — mais le rapport final a deux délais différents selon ce que l'on signale. Confondre les deux est l'erreur la plus fréquente dans les procédures internes qu'on nous montre.

Chaîne un, vulnérabilités activement exploitées : alerte précoce dans les 24 heures suivant la connaissance ; notification de vulnérabilité dans les 72 heures ; rapport final dans les 14 jours suivant la mise à disposition d'une mesure corrective ou d'atténuation. Le délai final s'accroche à la disponibilité du correctif, pas au calendrier.

Chaîne deux, incidents graves ayant une incidence sur la sécurité du produit : alerte précoce dans les 24 heures, notification dans les 72 heures, puis un rapport final dans le mois suivant la notification. Mêmes deux premières étapes, point de départ différent pour la dernière. Comme le calcul du délai final dépend de la qualification donnée à la première étape, celle-ci doit être consignée avec l'article appliqué.

3. Exploitée n'est pas la même chose que signalée

La chaîne des vulnérabilités ne démarre pas à chaque vulnérabilité. Elle démarre seulement lorsqu'il existe des preuves fiables que quelqu'un a exploité la vulnérabilité dans un système sans l'autorisation du propriétaire. La divulgation responsable d'un chercheur, un article académique, un scanner qui signale une vieille bibliothèque : rien de tout cela, en soi, ne déclenche l'horloge des 24 heures, parce que rien de tout cela n'est la preuve d'une exploitation non autorisée dans la nature.

Cette distinction coupe dans les deux sens. Trop peu signaler vous expose à une sanction ; tout signaler brûle votre crédibilité auprès du CSIRT et consomme le temps qu'il vous faudra pour les vrais cas. La décision qu'un signalement donné n'est pas — ou pas encore — une vulnérabilité activement exploitée doit être prise vite et, surtout, écrite : un « non » motivé est une défense, un « non » implicite ne laisse aucune trace le jour où un inspecteur demande pourquoi vous n'avez pas déposé.

4. L'horloge part de la connaissance, pas du lundi

Les 24 heures courent à partir du moment où l'entreprise a connaissance de l'événement. Pas à partir du moment où le responsable ouvre l'e-mail, pas du lundi matin, pas de la réunion de cadrage. Si un signalement arrive à l'adresse publique à 23 h 40 un samedi, c'est cet instant que vous devrez défendre devant le CSIRT et, le cas échéant, devant l'autorité de surveillance du marché.

Cela déplace le problème du domaine technique vers l'organisationnel. Trois choses en découlent directement : un canal d'entrée unique et tenu, que quelqu'un surveille réellement ; une règle de qualification écrite disant qui décide si l'horloge a démarré et sur quels critères ; et une chaîne d'astreinte avec des seuils horaires et des suppléants nommés. Les entreprises que nous avons vues en difficulté n'avaient pas un problème de compétence — elles avaient un problème de disponibilité.

5. Deux obligations que presque tout le monde oublie

La première est l'information des utilisateurs. Après avoir notifié les autorités, et sans retard injustifié, le fabricant informe les utilisateurs du produit de l'incident ou de la vulnérabilité et, le cas échéant, des mesures correctives ou d'atténuation qu'ils peuvent prendre. Une copie de ce qui a été diffusé, et de la date, doit être conservée : l'information des utilisateurs est une obligation à part entière, pas une courtoisie.

La seconde est le signalement en amont. Si la vulnérabilité se situe dans un composant tiers — y compris open source —, le fabricant doit la signaler à la personne ou à l'entité qui maintient le composant et coopérer avec elle. Cette obligation, posée par l'art. 13(6), est matériellement impossible sans une nomenclature logicielle à jour : sans SBOM, vous ne savez ni lesquels de vos produits intègrent le composant, ni à qui écrire.

6. Sanctions : combien, et ce qui les atténue

Les manquements aux obligations des articles 13 et 14 — dont font partie les obligations de signalement décrites — sont passibles d'amendes administratives pouvant aller jusqu'à 15 millions d'euros ou, si l'auteur est une entreprise, jusqu'à 2,5 % de son chiffre d'affaires mondial total annuel de l'exercice précédent, le montant le plus élevé étant retenu. C'est la tranche la plus haute du régime de sanctions du règlement, et elle vise les obligations de signalement, pas seulement la non-conformité du produit.

Le montant n'est pas automatique. Pour fixer l'amende, l'autorité pèse la nature et la gravité du manquement, sa durée, son caractère intentionnel ou négligent, et le degré de coopération avec les autorités. En pratique, c'est là que la diligence documentée paie : une décision de qualification écrite, un journal d'entrée horodaté et des preuves de coopération rapide changent l'issue d'un même fait.

7. Que faire avant le 11 septembre 2026

Trois choses opérationnelles, par ordre d'urgence. Un canal public de réception des signalements, associé à une politique de divulgation coordonnée publiée là où les chercheurs la cherchent — un fichier security.txt sur votre domaine. Une règle de qualification écrite disant qui décide si l'horloge a démarré et sur quels critères. Une chaîne d'astreinte avec des seuils horaires et des suppléants nommés, pour que le cas du samedi soir ait un responsable.

Ensuite deux prérequis administratifs qui suivent des calendriers qui ne sont pas les vôtres : les identifiants EU Login nécessaires pour atteindre la plateforme de signalement, et la désignation de votre point de contact auprès du CSIRT national. Les demander le jour de l'urgence, c'est arriver en retard pour une raison qui n'a rien de technique. Identifiez à l'avance les personnes pouvant agir comme représentant désigné (Assigned Representative) sur la plateforme, et achevez l'inscription et le rattachement à la plateforme de signalement unique en suivant les indications de l'ENISA en vigueur au moment de la notification — la procédure peut évoluer, ne la tenez pas pour figée. CRAnotify prépare le dépôt mais n'automatise pas la soumission finale sur la SRP : il n'existe pas d'API SRP automatique, et le dépôt reste un acte du fabricant, accompli avec ses propres identifiants. Le mode d'emploi est sur la page dédiée.

Le reste — le registre des produits, la nomenclature logicielle, les intégrations — se construit dans les mois qui suivent. Mais sans ces cinq choses prêtes, le premier signalement réel vous prendra à découvert, et ce premier signalement peut arriver le lendemain du 11 septembre 2026.

Cet article expose notre lecture du texte réglementaire et ne constitue pas un conseil juridique.