Adopté fin 2024, le Cyber Resilience Act (CRA) marque une nouvelle étape dans la régulation européenne de la cybersécurité, en imposant des exigences inédites sur les produits numériques mis sur le marché. Entre contrainte réglementaire et opportunité stratégique, ce texte oblige les acteurs à repenser leurs pratiques de conception, de gouvernance et de gestion des risques. Dans cet avis d’expert, Stéphane Dubreuil, Directeur du conseil cyber chez Softeam Consulting, filiale conseil et services de Docaposte, livre son analyse et ses clés de lecture pour transformer le CRA en levier de compétitivité plutôt qu’en simple obligation.
Le règlement relatif aux exigences de cybersécurité applicables aux produits comportant des éléments numériques (CRA), a été adopté il y a un an (le 23 octobre 2024). Ce texte vient compléter le corpus législatif qui cadre les attendus en termes de cybersécurité et cyberdéfense dans notre société en définissant les obligations sur les produits.
Avec le RGPD nous avions tous des obligations sur le traitement et la sécurisation de la donnée personnelle. Avec NIS 2 nous avions des obligations sur les systèmes d’informations sensibles de nos entités publiques et privées. Mais jusqu’à ce règlement, à l’exception de quelques secteurs (aviation, automobile, défense, …), il n’existait pas d’obligation sur les produits intégrés au sein de nos systèmes d’information.
Pour faire un raccourci facile : s’il y avait bien un code de la route, il n’y avait pas d’obligation de sécurité sur les véhicules eux-mêmes.
Comme tout règlement de l’Union européenne, il n’y a pas à attendre de transposition dans le droit national, il est d’application directe et ce, à partir du 11 décembre 2027 (art. 71.2 du règlement). Ce délai a vocation à permettre à l’ensemble des acteurs concernés de se mettre en conformité : passer du texte à la réalité peut nécessiter de transformer significativement ses produits, sa chaîne de valeur et sa gouvernance.
Passer du texte réglementaire à la feuille de route opérationnelle
Le CRA marquera un tournant pour l’industrie logicielle et les produits connectés. Pour la première fois, la sécurité devient une exigence légale à toutes les étapes du cycle de vie et cette obligation ne se résume pas à une liste de cases à cocher. Elle impose une révision en profondeur des pratiques de conception, de mise à jour, de support et de communication.
Ces trois années « offertes » par l’U.E ne seront pas de trop pour réaliser cette transformation technique et organisationnelle. Dès aujourd’hui, les fabricants doivent identifier et référencer l’ensemble des composants de leurs produits, identifier dans le CRA les exigences applicables selon les classes de risque définies par le règlement et évaluer leurs processus internes. Le diagnostic initial et l’analyse d’écart au texte constituent les fondations d’une feuille de route efficace.
La priorité stratégique consiste à mettre en place un cadre de gouvernance clair. Cette gouvernance induit l’identification et la nomination d’un référent CRA ainsi que l’implication des décideurs et des métiers.
La priorité opérationnelle doit rechercher les quick-wins. Parmi ceux-ci, la notification des incidents graves ou la veille sur les vulnérabilités de ses composants sont des processus relativement simples à mettre en place. Ces exigences figurent parmi les premières que les autorités peuvent contrôler. La plateforme de notification de l’ENISA est en cours de déploiement et les CSIRT nationaux seront en première ligne pour accompagner ces signalements.
Sécurité intégrée, responsabilité partagée
La portée du CRA est très large. Elle couvre tous les produits connectés mis sur le marché européen, avec quelques exceptions sectorielles comme les dispositifs médicaux ou les logiciels open source non commerciaux, mais un logiciel en mode SaaS, un routeur Wi-Fi ou une application embarquée entrent pleinement dans le champ d’application.
Et pour ce qui rentre dans son champs d’application, le CRA impose l’intégration de la sécurité “by design” et “by default”. Cela nécessite un changement de culture technique. La sécurité n’est plus un correctif ajouté en fin de chaîne mais un prérequis fonctionnel. Les cycles de développement intégrant la sécurité (DevSecOps), l’automatisation des tests, l’audit des dépendances logicielles et la journalisation deviennent la norme.
Cette transformation est aussi organisationnelle. Elle engage les équipes produits, juridiques, supports et achats. Toute la chaîne de valeur doit prendre en compte les exigences du CRA, y compris les fournisseurs tiers, les prestataires SaaS et les composants open source utilisés. Le texte distingue clairement les rôles des fabricants, importateurs et distributeurs, mais dans les faits, la responsabilité s’étend à toute la supply chain par effet contractuel.
Anticiper intelligemment, arbitrer lucidement
L’un des facteurs de succès de cette transformation réside dans la définition d’un plan de mise en conformité progressif, aligné sur la maturité de l’organisation, la criticité des usages et les priorités fixées par les autorités de contrôle. Certaines exigences feront l’objet d’une tolérance temporaire ; d’autres, comme la gestion des vulnérabilités, seront exigibles immédiatement.
A contrario, viser d’emblée les exigences les plus élevées, telles que la classe II ou la certification EUCC, sans avoir validé le niveau de risque réel du produit à l’échec. En effet ce surdimensionnement complique la mise en conformité et entraîne une mobilisation excessive de ressources (financières, humaines et techniques).
Des recommandations claires émanent d’ores et déjà de l’ENISA ou de l’ANSSI. Identifier les composants critiques, allouer des ressources dédiées à la gestion des vulnérabilités ou structurer une documentation technique solide (dont un Software Bill of Materials) figurent parmi ces attentes concrètes.
L’échéance de 2027, si elle peut être perçue comme un couperet, doit surtout être vue comme une opportunité. En effet le CRA sera aussi le tampon « CE » des produits numériques et apportera donc, sur le territoire européen, un avantage concurrentiel aux produits qui le respectent. Aussi, nous ne devons pas subir cette réglementation mais au contraire en faire un catalyseur de l’innovation donnant à ceux qui s’en empareront un coup d’avance « cyber » sur la concurrence.
