Un nouveau régime de signalement qui bouscule les éditeurs et fabricants
Depuis le 11 septembre 2024, le règlement (UE) 2024/2847, dit Cyber Resilience Act, fait entrer les obligations de signalement dans le quotidien des directions numériques. Le texte ne vise pas seulement la cybersécurité des infrastructures, il cible directement les produits à éléments numériques et les logiciels mis sur le marché européen, qu’ils soient propriétaires ou open source intégrés dans une offre commerciale. Pour un fabricant de produit connecté ou un éditeur de logiciels métier, la frontière entre conformité réglementaire et stratégie de marché se déplace brutalement, avec un cadre juridique désormais détaillé dans les articles 11 à 16 du règlement.
Le cœur de cette nouvelle phase du CRA, souvent résumé sous l’expression « obligations de notification du Cyber Resilience Act à l’horizon 2026 », tient en une exigence simple : toute vulnérabilité activement exploitée ou tout incident grave doit faire l’objet d’une première alerte sous 24 heures. Cette obligation de notification s’applique aux produits et aux produits à éléments numériques, qu’il s’agisse d’un routeur industriel, d’un objet médical connecté ou d’un logiciel de gestion embarqué dans une appliance. Les COMEX qui traitaient encore le CRA comme un futur règlement de marquage produit découvrent que la responsabilité de l’entreprise est déjà engagée par ce régime de notification, avec une entrée en application progressive entre 2025 et 2027, incluant une période de transition pour les produits déjà mis sur le marché.
Concrètement, le Cyber Resilience Act (ou resilience act dans les documents de travail) impose une chaîne de gestion des vulnérabilités qui dépasse la seule DSI. Les obligations de signalement créent un pont direct entre les équipes de sécurité, les équipes produit et la direction juridique, car chaque signalement engage la conformité globale de l’entreprise au règlement. Le CRA se distingue ici de la directive NIS, qui cible les opérateurs de services essentiels, alors que l’act CRA vise les produits et les éléments numériques mis sur le marché, avec une logique de surveillance du marché et de sécurité par conception, sous le contrôle des autorités nationales compétentes et de l’ENISA, et des sanctions administratives pouvant atteindre jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial en cas de manquement grave.
Signalement en 24 heures : un test de maturité opérationnelle, pas un exercice théorique
La nouveauté la plus sous-estimée des obligations de notification du Cyber Resilience Act est le calendrier de déclaration, qui impose un tempo industriel. En cas de vulnérabilité activement exploitée sur un produit ou un logiciel, le fabricant ou l’éditeur doit :
- envoyer une première alerte sous 24 heures ;
- transmettre un rapport détaillé sous 72 heures ;
- fournir un rapport final sous un mois via la plateforme de l’ENISA, avec en France un relais opérationnel assuré par le CERT-FR et l’ANSSI.
Dans un cas type, une faille critique détectée un lundi matin doit ainsi être qualifiée dans la journée, notifiée avant le lendemain, documentée dans les trois jours, puis suivie jusqu’à la mise à disposition d’un correctif et la clôture formelle de l’incident, avec une traçabilité complète des décisions prises.
Pour une PME ou une ETI éditrice de logiciels, la question n’est donc pas de savoir si le CRA est un règlement de plus, mais si son processus de détection permet réellement de tenir ces délais sans sacrifier la qualité de l’analyse. Il faut une chaîne de gestion des vulnérabilités qui relie la sécurité de conception, la supervision en production, le support client et la fonction juridique, avec des exigences de sécurité claires à chaque étape de la vie du produit. Les exigences essentielles du texte imposent aussi une traçabilité sur la mise à jour, la correction et la communication vers les clients, ce qui transforme le support en maillon critique de la conformité et expose, en cas de manquement grave, à des sanctions administratives potentiellement alignées sur les pratiques européennes en matière de cybersécurité, comme le résume un directeur technique d’éditeur interrogé : « Nous avons dû formaliser en six mois un processus de réponse aux incidents qui, auparavant, reposait surtout sur la bonne volonté des équipes ».
Les directions doivent intégrer que la conformité au CRA devient un critère d’accès au marché, au même titre que les normes harmonisées ou l’évaluation de conformité pour d’autres réglementations techniques. Dans plusieurs appels d’offres publics récents, la capacité à respecter les obligations de signalement et à démontrer une gestion structurée des vulnérabilités est déjà utilisée comme filtre de présélection. Pour préparer ces discussions en comité de pilotage, un bon point de départ consiste à articuler le budget de cybersécurité autour de ces nouvelles exigences, comme le montre l’analyse sur le budget de cybersécurité présenté au COMEX, tout en s’appuyant sur les ressources officielles publiées par l’ENISA et l’ANSSI.
Du produit à la chaîne d’approvisionnement : transformer le CRA en avantage compétitif
Le Cyber Resilience Act ne se limite pas à imposer des exigences de sécurité sur un produit isolé, il étend la responsabilité à la chaîne d’approvisionnement numérique complète. Un fabricant qui assemble plusieurs produits à éléments numériques, intègre des composants open source et s’appuie sur des services tiers doit être capable de démontrer une gestion des vulnérabilités cohérente sur l’ensemble de ce périmètre. La sécurité de conception, la surveillance du marché et la gestion active des incidents deviennent des arguments commerciaux autant que des obligations réglementaires, notamment pour rassurer les clients sur la robustesse des mises à jour et la qualité du processus de signalement, dans un contexte où les audits de cybersécurité se généralisent.
Pour les DSI et responsables IT, l’enjeu est de transformer ces obligations de signalement en levier de gouvernance, en alignant les pratiques de cybersécurité avec la stratégie produit et la feuille de route business. Cela suppose de cartographier les éléments numériques critiques, de définir des exigences de sécurité minimales par catégorie de produits et de mettre en place une évaluation de conformité continue, plutôt qu’un audit ponctuel en fin de vie produit. Les organisations qui structurent déjà leur plateforme technique autour d’approches de type Platform Engineering, comme celles décrites dans l’analyse sur le chaînon manquant entre DevOps et vélocité produit, partent avec un avantage clair pour industrialiser la détection, la remontée et la documentation des incidents, en intégrant nativement les exigences du CRA dans leurs pipelines.
Reste un point souvent oublié : le CRA va se croiser avec d’autres cadres comme NIS2 et les futures règles sur l’IA, ce qui impose une gouvernance des données et des incidents beaucoup plus intégrée. Les directions qui traitent encore chaque règlement comme un silo réglementaire vont multiplier les coûts de mise en conformité et perdre en lisibilité vis-à-vis du marché. À l’inverse, celles qui posent dès maintenant des garde-fous de gouvernance, comme le suggère l’analyse sur la gouvernance des données face aux agents d’IA, pourront utiliser le Cyber Resilience Act comme un socle de confiance pour leurs produits numériques, en s’alignant sur les orientations publiées dans les documents de référence officiels de la Commission européenne et en anticipant les contrôles des autorités nationales compétentes.
FAQ : délais et périmètre des obligations de signalement du CRA
Quels sont les délais de notification prévus par le Cyber Resilience Act ?
- Première alerte sous 24 heures après la découverte d’une vulnérabilité activement exploitée ou d’un incident grave ;
- rapport plus détaillé sous 72 heures, incluant les premières mesures d’atténuation ;
- rapport final dans un délai d’un mois, afin de documenter les mesures correctives, les mises à jour déployées et la clôture de l’incident.
Quels produits sont concernés par ces obligations de signalement ? Sont visés les produits à éléments numériques et les logiciels mis sur le marché de l’Union européenne, qu’il s’agisse d’équipements connectés, de solutions industrielles, d’objets médicaux, d’applications embarquées ou de logiciels métier intégrés dans une offre commerciale, y compris lorsqu’ils reposent sur des composants open source, dès lors qu’ils relèvent du champ d’application défini par le règlement (UE) 2024/2847.