Une obligation précise, et non l’application complète du CRA
Le 11 septembre 2026 a marqué le début de l’application de l’obligation de signalement du Cyber Resilience Act (CRA) pour les fabricants. Ceux-ci doivent signaler les vulnérabilités activement exploitées et certains incidents graves ayant une incidence sur la sécurité des produits comportant des éléments numériques. Cette date compte, mais il faut la décrire précisément : elle ne signifie ni que toutes les obligations du règlement ont commencé ce jour-là, ni que tout problème de sécurité doit automatiquement être signalé par cette voie. Le périmètre immédiat est plus limité et dépend du respect des conditions prévues par le texte. Cette date ouvre une obligation de signalement spécifique, et non un régime pleinement applicable.
Le CRA est le règlement (UE) 2024/2847, qui établit un cadre européen de exigences de cybersécurité pour les produits comportant des éléments numériques. La Commission européenne distingue les signalements déjà requis des autres dispositions qui s’appliqueront ultérieurement. Pour les équipes produit, sécurité et conformité, il ne s’agit donc pas de présumer que toutes les obligations futures sont déjà actives, mais d’identifier les cas soumis au signalement et de mettre en place une procédure permettant de les repérer et de les transmettre aux responsables concernés. Distinguer clairement la phase de signalement du calendrier général permet d’éviter aussi bien les omissions que l’assimilation de chaque préoccupation de sécurité à un signalement réglementaire. Cet article porte sur cette obligation initiale et ses conséquences pratiques, et non sur une prétendue application intégrale du règlement.
Qui est concerné et quels cas doivent déclencher un examen
L’obligation en vigueur concerne les fabricants de produits comportant des éléments numériques entrant dans le champ du CRA. Les indications de la Commission décrivent deux situations à signaler : une vulnérabilité activement exploitée et un incident grave ayant une incidence sur la sécurité du produit. Le signalement ne doit donc pas être assimilé à une liste générale de défauts, d’alertes ou de vulnérabilités potentielles. L’organisation doit évaluer si les faits relèvent des catégories juridiques et conserver une trace documentée de sa décision. Un signal peut justifier une enquête sans nécessairement atteindre le seuil de signalement ; à l’inverse, un cas qui remplit les critères ne doit pas être manqué parce qu’il a d’abord été traité comme un simple problème technique.
Le terme fabricant a un sens réglementaire : il ne désigne pas simplement tout développeur ou toute équipe participant à un logiciel. Le texte organise les obligations en fonction du rôle de chaque opérateur économique et prévoit également des dispositions pour les responsables de logiciels libres. La Commission précise que leurs obligations de signalement commencent le 11 décembre 2027, et non au début de la phase actuelle applicable aux fabricants. En présence de chaînes d’approvisionnement, de composants tiers ou de produits reposant sur des logiciels libres, il convient de déterminer qui est responsable au titre du règlement avant d’attribuer la tâche de signalement. L’étiquette technique d’une entreprise ne remplace pas l’analyse de son rôle juridique. Il peut être nécessaire d’examiner comment le produit est mis sur le marché et quelles responsabilités le CRA attribue aux différents acteurs. La seule participation technique ne détermine pas la responsabilité juridique.
Les délais de signalement
Selon les informations de la Commission, la procédure prévoit une alerte précoce dans les 24 heures suivant le moment où le fabricant a connaissance du cas, puis un signalement complet dans les 72 heures. Elle exige également un rapport final, dont le délai varie selon la situation : pour les vulnérabilités activement exploitées, au plus tard 14 jours après la mise à disposition d’une mesure corrective ; pour les incidents graves, dans le mois suivant le signalement effectué sous 72 heures. Il s’agit d’étapes distinctes, et non d’une seule échéance calculée à partir de la découverte. Cette succession permet d’alerter rapidement les autorités concernées, puis de compléter les informations au fil de la réponse.
La référence au moment où le fabricant prend connaissance du cas rend importants les processus de détection, de validation et d’escalade des signaux. Une procédure interne qui attend la fin de l’enquête avant d’associer les fonctions responsables pourrait compliquer le respect du délai d’alerte précoce. Dans le même temps, un premier signalement ne dispense pas de compléter les informations ni de transmettre le rapport final lorsqu’il est requis. Le règlement et les instructions officielles doivent guider l’interprétation des délais dans chaque situation. Une réponse opérationnelle doit distinguer l’évaluation initiale, le signalement complet et la clôture, en attribuant à chaque étape des responsables et des traces documentaires. Consigner le moment où l’organisation a eu connaissance des faits et la manière dont elle les a évalués contribue à la bonne gestion des différentes étapes.
La plateforme unique et le cheminement du signalement
Les fabricants transmettent leurs signalements par la CRA Single Reporting Platform (SRP), créée par l’ENISA en coopération avec le réseau des CSIRT. Ce canal est opérationnel depuis le 11 septembre 2026. Selon la Commission, le fabricant transmet le signalement une seule fois : celui-ci est adressé au CSIRT de l’État membre où se trouve son établissement principal et, sauf circonstances exceptionnelles, les informations sont mises simultanément à la disposition de l’ENISA. Cette procédure fournit un point d’entrée défini au système de signalement, sans obliger le fabricant à envoyer plusieurs signalements initiaux à tous les destinataires concernés.
Le CSIRT destinataire transmet sans délai le signalement aux autres CSIRT sur le territoire desquels le produit a été mis à disposition sur le marché. La Commission précise également qu’en circonstances exceptionnelles et pour des motifs de cybersécurité justifiés, la diffusion à d’autres équipes peut être retardée. La plateforme ne doit donc être comprise ni comme un mécanisme de publication ouverte, ni comme un moyen pour une entreprise de choisir individuellement tous ses destinataires. En pratique, les procédures internes devraient préciser qui peut préparer l’envoi, qui l’autorise et comment les informations signalées sont conservées. L’ENISA publie des guides sur l’utilisation de la plateforme ; ils facilitent l’emploi du canal, mais ne remplacent pas l’analyse juridique du champ de l’obligation. Les équipes chargées du signalement devraient pouvoir accéder à la SRP et savoir l’utiliser lorsqu’un envoi est nécessaire.
Ce que cette phase ne permet pas de conclure
L’entrée en vigueur de l’obligation de signalement ne signifie pas que toutes les dispositions de fond du CRA s’appliquent déjà. La date générale prévue pour l’application de la plupart des dispositions du règlement est le 11 décembre 2027, tandis que l’obligation de signalement a commencé plus tôt. Ce calendrier échelonné explique qu’une entreprise puisse devoir préparer et transmettre des signalements dès maintenant tout en poursuivant ses travaux sur d’autres obligations dont la date d’application n’est pas encore arrivée. Distinguer ces échéances aide à planifier correctement, sans repousser le travail de signalement actuel ni présenter à tort les exigences ultérieures comme déjà applicables.
Cette présentation ne permet pas non plus de conclure que toute organisation qui écrit ou distribue du code est un fabricant, ni que tout service hébergé dans le cloud relève du CRA. Le règlement définit son champ en fonction des produits comportant des éléments numériques et de fonctions déterminées ; il prévoit aussi des conditions spécifiques pour les solutions de traitement de données à distance associées à un produit. Cet article résume l’obligation initiale de signalement, mais ne tranche pas les questions particulières de classification, d’exemption ou d’interaction avec d’autres règles européennes. Lorsqu’un produit ou un modèle économique se situe à la limite du champ juridique, il faut examiner le texte réglementaire et les clarifications officielles applicables. Une orientation générale peut guider l’analyse, mais ne remplace pas l’examen du cas concret.
Ce qu’il convient de préparer dès maintenant
Une préparation utile peut commencer par l’inventaire des produits mis à disposition sur le marché de l’Union européenne, des fabricants qui en sont responsables et des canaux de réception des signalements de vulnérabilités et d’incidents. L’entreprise peut ensuite définir des critères d’escalade permettant d’évaluer rapidement si un cas pourrait correspondre à une exploitation active ou à un incident grave ayant une incidence sur la sécurité du produit. Ce travail ne présume pas que chaque signal doit être déclaré. Il vise à faire parvenir la décision aux bonnes personnes à temps et à éviter que des faits pertinents se perdent entre les équipes techniques, de sécurité, juridiques et de conformité.
Il est également judicieux d’attribuer les responsabilités pour évaluer le cas, rassembler les informations techniques, valider le contenu du signalement et l’envoyer par la SRP. Il convient de garder une trace du moment où l’organisation a eu connaissance des faits et des décisions prises, car les délais officiels courent à partir de cette prise de connaissance et la procédure comporte plusieurs étapes. Enfin, le calendrier de conformité doit distinguer le jalon déjà en vigueur du 11 septembre 2026 des obligations qui commencent le 11 décembre 2027. Le point de départ pratique consiste à vérifier le champ d’application, tester le circuit de décision et consulter les instructions officielles de l’ENISA. Il ne faut ni supposer que le signalement est universel, ni attendre le dernier moment pour désigner les personnes chargées de répondre.