Cyber Resilience Act : 24 heures pour signaler, depuis hier

L’article 14 du règlement européen sur la cyberrésilience est entré en application le 11 septembre. Depuis hier, tout fabricant d’un produit comportant des éléments numériques doit signaler à l’agence européenne de cybersécurité les vulnérabilités activement exploitées et les incidents graves affectant ses produits.

Le délai est de vingt-quatre heures pour la première alerte. L’obligation vaut pour les produits déjà commercialisés, quelle que soit leur date de mise sur le marché.

Ce qu’il faut signaler, et dans quels délais

Deux types d’événements déclenchent l’obligation : une vulnérabilité activement exploitée affectant un produit, et un incident grave ayant un impact sur sa sécurité.

Le calendrier se déroule en trois temps. Une alerte précoce dans les vingt-quatre heures suivant la prise de connaissance. Un rapport avec une première évaluation dans les soixante-douze heures. Un rapport complet dans les quatorze jours.

Ces délais sont volontairement identiques à ceux de la directive sur la sécurité des réseaux et des systèmes d’information, dans un objectif d’harmonisation du cadre européen. Une entreprise déjà soumise à ce second texte connaît donc la mécanique.

Les notifications passent par une plateforme unique administrée par l’ENISA, qui redistribue l’information aux équipes nationales de réponse aux incidents des États membres où le produit est distribué. En France, le point d’entrée est l’ANSSI.

Qui est concerné, et c’est plus large qu’on ne le croit

Le périmètre couvre tout produit comportant des éléments numériques mis à disposition sur le marché de l’Union dans le cadre d’une activité commerciale : logiciels, matériels, et les solutions de traitement de données à distance qui leur sont associées.

En pratique : une application mobile, un logiciel de gestion, une montre connectée, une caméra de surveillance, un équipement domotique, un babyphone. La liste est vaste parce que la définition l’est.

Trois points méritent attention, et ce sont ceux que les entreprises découvrent tard.

L’obligation est rétroactive. Elle s’applique aux produits déjà sur le marché. Un logiciel commercialisé pour la première fois en 2018, toujours vendu ou toujours utilisé chez des clients, entre dans le champ dès le premier jour. L’argument selon lequel une version ancienne n’est plus commercialisée ne suffit pas.

Elle ne s’arrête pas aux frontières de l’Union. Un éditeur établi hors de l’Union qui distribue à des clients européens est soumis aux mêmes règles.

Elle vise aussi celui qui commercialise sous son nom. Une entreprise qui revend sous sa marque un produit conçu ailleurs est considérée comme fabricant.

Les sanctions prévues par le règlement atteignent 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial pour les manquements aux obligations essentielles.

Le point de calendrier qui interroge

Un élément de séquencement mérite d’être relevé, et il est peu commenté.

L’obligation de signaler entre en application aujourd’hui. Mais l’obligation de mettre en place une politique coordonnée de divulgation des vulnérabilités, c’est-à-dire le canal par lequel un chercheur en sécurité prévient un fabricant qu’une faille est exploitée, ne devient généralement exigible qu’en décembre 2027.

Autrement dit, l’obligation de déclarer précède de quinze mois l’obligation de disposer du dispositif par lequel la plupart des déclarations arrivent.

Ce n’est pas un oubli, selon l’analyse qu’en font plusieurs cabinets spécialisés, mais un choix assumé de séquencement : attendre que l’ensemble de l’infrastructure soit en place retarderait de plusieurs années la réduction du risque. Le raisonnement se défend. Il crée néanmoins une période où l’obligation pèse sur des entreprises qui n’ont pas nécessairement les moyens organisationnels de la remplir.

Pour une petite structure éditrice de logiciel, la conséquence pratique est simple : sans point de contact de sécurité publié et sans circuit de tri interne, elle apprendra l’exploitation d’une de ses failles par un client mécontent, plusieurs semaines après le délai de vingt-quatre heures.

Pourquoi ça compte

Il faut regarder ce texte à côté des autres, parce que l’année 2026 concentre plusieurs échéances européennes qui se recoupent.

Nous suivons le calendrier des obligations du règlement sur l’intelligence artificielle, dont la prochaine échéance tombe le 2 décembre. Une entreprise qui édite un logiciel intégrant un modèle d’IA et le commercialise dans l’Union relève simultanément des deux textes, avec des autorités, des délais et des sanctions différents.

Le rapprochement n’est pas théorique. Nous avons documenté en août des modèles capables d’identifier seuls des failles inconnues et de mener des attaques. Un produit vulnérable exploité par un système automatisé relève du signalement en vingt-quatre heures, exactement comme s’il avait été exploité par un humain.

Pour les entreprises françaises, la préparation minimale tient en trois éléments : un point de contact de sécurité publié et surveillé, un registre produit reliant les versions diffusées à un responsable interne, et une procédure permettant une déclaration initiale incomplète, quitte à l’enrichir ensuite. Attendre un rapport d’expertise définitif avant de déclarer revient à perdre l’essentiel de la fenêtre.

Les angles morts

Nous n’avons pas lu le texte intégral du règlement (UE) 2024/2847, mais sa présentation par la Commission et les analyses juridiques publiées ces dernières semaines.

La définition de l’incident grave n’est pas détaillée dans les sources que nous avons consultées. C’est pourtant elle qui détermine si une entreprise doit déclarer ou non, et l’appréciation reviendra en pratique au fabricant lui-même.

Aucune décision de sanction n’existe, le texte s’appliquant depuis hier. Les montants sont connus, la pratique décisionnelle non.

Enfin, la capacité de l’ENISA et des équipes nationales à traiter le volume de signalements attendu n’est pas documentée publiquement. Une obligation de déclaration ne vaut que par ce qui est fait des déclarations.