Cyber Resilience Act : 24 heures pour signaler une faille, c'est parti

Le Cyber Resilience Act est entré dans sa phase mordante le 11 septembre 2026. Ce n'est plus une échéance lointaine inscrite au Journal officiel de l'Union européenne : depuis vendredi dernier, un éditeur de logiciel qui découvre qu'une faille de son produit est activement exploitée dispose de vingt-quatre heures pour le signaler. Pas trois jours, pas une semaine. Un jour.

Et contrairement à ce qu'imaginent beaucoup de dirigeants de PME tech, ça ne concerne pas que les fabricants d'objets connectés.

Ce qui a basculé vendredi

L'article 14 du règlement s'applique désormais. Il impose deux temps de notification :

• sous 24 heures : une alerte précoce, dès qu'une vulnérabilité activement exploitée ou un incident grave affectant la sécurité du produit est constaté ;
• sous 72 heures : une notification détaillée, avec une première évaluation de la situation, de la gravité et de l'impact.

Point qui échappe à beaucoup : l'obligation vaut y compris pour les produits déjà vendus. Un logiciel livré en 2023, toujours en service chez des clients européens, tombe dans le champ. Il n'y a pas de clause d'antériorité confortable.

Côté plumbing institutionnel, l'ENISA — l'agence européenne de cybersécurité — opère la plateforme centralisée de collecte. En France, c'est le CERT-FR de l'ANSSI qui assure la réception, l'analyse et la coordination du traitement des signalements. Autrement dit : le point d'entrée national existe, il est identifié, et il n'y a plus d'excuse du type « on ne savait pas à qui écrire ».

Qui est concerné — la réponse est large

Le périmètre du règlement couvre tout produit comportant des éléments numériques mis sur le marché de l'Union. Concrètement :

• les fabricants de matériel intégrant du logiciel (routeurs, caméras, automates, dispositifs connectés) ;
• les éditeurs de logiciels indépendants, y compris purement logiciels, y compris SaaS packagé livré on-premise ;
• les importateurs, qui doivent vérifier la conformité avant distribution dans l'UE ;
• les distributeurs, avec des obligations plus légères mais une responsabilité engagée s'ils savent qu'un produit n'est pas conforme.

Les responsables de logiciels open source — les stewards, au sens du règlement — entrent dans le dispositif plus tard, à partir du 11 décembre 2027, avec un régime allégé. Le législateur européen a manifestement compris qu'imposer un délai de 24 heures à un mainteneur bénévole n'avait aucun sens.

Le cas qui pique, c'est la petite structure française de dix personnes qui édite un logiciel métier vendu à des clients belges et allemands. Elle est fabricante au sens du CRA. Elle a les mêmes obligations de signalement qu'un groupe du CAC 40. Elle n'a ni SOC, ni juriste, ni astreinte de nuit.

Les autres obligations qui viennent avec

Le signalement en 24 heures est la partie visible. Le règlement embarque un socle d'exigences de sécurité qui structurent tout le cycle de vie du produit :

• configuration sécurisée par défaut : le produit est livré sans vulnérabilité exploitable connue, et avec des réglages par défaut qui ne sont pas une porte ouverte ;
• SBOM (Software Bill of Materials) : un inventaire lisible par machine de tous les composants logiciels embarqués, dépendances tierces comprises ;
• canal de divulgation de vulnérabilité : un processus public, documenté, permettant à un chercheur externe de signaler une faille sans devoir jouer au détective pour trouver un contact ;
• support de sécurité d'au moins cinq ans : des mises à jour gratuites, sauf si la durée de vie prévue du produit est manifestement plus courte.

Le SBOM est probablement le chantier le plus sous-estimé. Générer, tenir à jour et publier l'inventaire complet d'une application moderne — avec ses milliers de dépendances npm ou Maven transitives — suppose une chaîne d'outillage dans la CI/CD. Ce n'est pas un document Word qu'on rédige une fois.

Quant au support cinq ans, il tue un modèle économique entier : celui du produit vendu, encaissé, puis abandonné quand l'équipe passe à la version suivante.

Le bâton : 15 millions d'euros

Les sanctions prévues montent jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. C'est le niveau RGPD, transposé au produit.

Deux nuances honnêtes.

D'abord, l'appareil de sanction complet est adossé au marquage CE, qui ne devient obligatoire qu'en décembre 2027. La phase actuelle est essentiellement une montée en charge : les autorités de surveillance nationales se structurent, les organismes notifiés sont opérationnels depuis juin 2026.

Ensuite, et c'est plus immédiat : la conformité au CRA s'invite déjà dans les appels d'offres publics et dans les clauses contractuelles B2B. Bien avant qu'un régulateur ne frappe à la porte, c'est un acheteur qui va demander le SBOM et la politique de divulgation. Un éditeur incapable de fournir ces documents sort du short-list. La sanction économique arrivera avant la sanction administrative.

Les angles morts

Le délai de 24 heures pose un problème opérationnel réel. Que se passe-t-il quand une faille est découverte un vendredi soir dans une boîte de quinze personnes ? Le règlement ne prévoit pas de week-end.

Il y a aussi une tension classique avec la divulgation responsable. Signaler vite à l'ENISA et au CERT-FR est une chose ; ces informations circulent ensuite entre autorités nationales, et la surface d'exposition d'une vulnérabilité non corrigée s'élargit mécaniquement. Le règlement prévoit des garde-fous, mais la communauté sécurité regarde ce point de très près.

Enfin, la définition de « vulnérabilité activement exploitée » laisse de la marge d'appréciation. Une preuve de concept publiée sur GitHub compte-t-elle ? Un pic de tentatives dans les logs d'un client ? Les premiers mois de pratique feront jurisprudence, et les entreprises prudentes sur-signaleront.

À noter au passage le contexte français : le Premier ministre a récemment annoncé un plan d'action face à l'intensification des attaques visant les systèmes de l'État, avec la fusion de la DINUM et de la DITP pour créer une autorité numérique de l'État. Le CRA arrive dans un climat où la pression réglementaire et politique monte des deux côtés.

Le calendrier à noter

• décembre 2024 : entrée en vigueur du règlement, désignation des évaluateurs par les États membres
• juin 2026 : organismes notifiés opérationnels pour la certification
• 11 septembre 2026 : article 14 applicable — signalement 24 h / 72 h
• 11 décembre 2027 : application pleine, marquage CE obligatoire, entrée des stewards open source, importateurs et distributeurs

Pour une équipe technique qui découvre le sujet aujourd'hui, l'ordre des priorités est assez évident : publier une page security.txt et un canal de divulgation, brancher un générateur de SBOM dans la chaîne de build, désigner nommément qui décroche en cas d'incident et à quel numéro, et vérifier ce que le contrat client promet en matière de durée de support. Ces quatre actions se mènent en quelques semaines. La suite, notamment le marquage CE, demandera nettement plus.