CRA : les fournisseurs face aux premières obligations

Depuis le 11 septembre 2026, le Cyber Resilience Act (CRA) est entré dans une première phase opérationnelle : les fabricants doivent désormais notifier les vulnérabilités activement exploitées et certains incidents graves affectant leurs produits. Cette échéance constitue surtout un premier test avant l’application générale du règlement, prévue le 11 décembre 2027.

Le champ couvert est particulièrement large. Le CRA concerne les « produits comportant des éléments numériques » (Products with Digital Elements, PDE), c’est-à-dire des matériels ou logiciels destinés à être connectés, directement ou indirectement, à un dispositif ou à un réseau. Il peut ainsi s’appliquer aussi bien à des objets connectés du quotidien qu’à des logiciels, des équipements réseau, des automates ou des systèmes industriels complexes.

Sur le terrain, le niveau de préparation est contrasté. François Baligant, Group CTO & Partner Cybersecurity chez Theodo, pointe les difficultés persistantes à identifier rapidement les produits concernés par une faille et à mobiliser des équipes capables de réagir dans les délais impartis. Cédric Le Labousse, Managing Director France de Wireless Logic observe de son côté une industrie déjà largement engagée dans la sécurisation des produits connectés, même si les PME et les systèmes anciens restent plus exposés.

Loïs Samain, Responsable de la stratégie cybersécurité du groupe RATP, et administrateur du CESIN, voit surtout dans le CRA un changement de rapport avec les fournisseurs. Les exigences de sécurité, jusqu’ici souvent négociées contrat par contrat, vont progressivement devenir un socle commun imposé aux fabricants. Pour les grands donneurs d’ordre industriels, le règlement dépasse ainsi la seule conformité cyber : il touche directement les achats, la maintenance et la durée de vie des équipements.

La notification en 24 heures révèle les écarts de maturité

Cette première échéance agit surtout comme un révélateur de la maturité opérationnelle des fabricants. Pour François Baligant, la difficulté commence avant la déclaration elle-même : il faut pouvoir identifier rapidement les produits et les versions réellement concernés par une vulnérabilité. “Le formulaire d’alerte n’est pas le point dur. Sous 24 heures, le règlement européen attend un premier signal, pas un rapport complet. Le vrai problème consiste à savoir que nous sommes touchés. Sans inventaire à jour par version et par application, retrouver les produits qui embarquent une dépendance vulnérable peut prendre plusieurs jours”, analyse-t-il.

Cédric Le Labousse porte un regard plus rassurant sur les entreprises déjà habituées aux produits connectés. Selon lui, les plus matures d’entre elles adaptent leurs processus de réponse aux incidents, leurs inventaires de composants et leurs dispositifs de suivi existants. Les difficultés concernent davantage les PME, qui disposent de ressources plus limitées pour formaliser ces mécanismes.

Loïs Samain considère également cette première étape comme préparatoire : “Je ne pense pas que ce sera le volet le plus compliqué ou le plus impactant. Le véritable changement interviendra en décembre 2027, lorsque nous devrons nous assurer que toute la démarche prévue par le CRA est effectivement intégrée”.

Le CRA redéfinit la relation avec les fournisseurs

Pour les grands donneurs d’ordre industriels, l’impact du CRA dépasse la notification des vulnérabilités. Le groupe RATP en mesure les effets sur ses achats, ses contrats et la maintenance. Le groupe de transports doit en effet vérifier que chaque fournisseur respectera les obligations de cybersécurité pendant toute la durée de vie des matériels livrés. Or une rame de métro regroupe des centaines de sous-systèmes, de capteurs et de flux de données : Loïs Samain la compare à un “datacenter” roulant. 

“Le CRA nous oblige à regarder la relation fournisseur sur toute la durée de vie de l’équipement. Dans l’industrie, certains systèmes restent en service dix, vingt ou trente ans. Il faut donc anticiper la façon dont les vulnérabilités seront suivies, les correctifs fournis et les responsabilités réparties dans le temps. C’est un sujet qui dépasse la seule équipe cyber”, note Loïs Samain.

Le responsable de la RATP distingue deux situations : les COTS (commercial off-the-shelf), produits standards vendus en série, doivent respecter le règlement par défaut, tandis que les systèmes conçus sur mesure exigent un travail spécifique avec chaque industriel. Il attire enfin l’attention sur la notion de modification substantielle, qui oblige la RATP à encadrer strictement la personnalisation de ses équipements.

Ce cadre modifie l’équilibre entre client et fournisseur. La cybersécurité figurait déjà dans les contrats de la RATP, mais son niveau dépendait de ce que chaque négociation permettait d’obtenir. “Jusqu’à présent, nous devions nous battre avec les fournisseurs pour intégrer la cybersécurité dans les contrats. Le CRA permet d’aller plus loin : les fournisseurs assureront ce niveau de sécurité par défaut, et non plus au terme d’une négociation contractuelle, avec des exigences très concrètes. Un produit qui ne serait pas au niveau pourrait même être retiré du marché par l’ANFR [Agence nationale des fréquences]”, commente Loïs Samain.

SBOM, legacy, patching : le rendez-vous de fin 2027

À l’approche du 11 décembre 2027, la chaîne d’approvisionnement logicielle s’impose au centre des préparatifs. François Baligant rappelle que plus de 95 % des bases de code intègrent de l’open source. Or le CRA impose un SBOM (Software Bill of Materials, inventaire des composants d’une application) lisible par une machine, qui couvre au minimum les dépendances de premier niveau.

“Être maître de son SBOM est clé. C’est un axe de progression important pour les entreprises soumises au CRA. Choisir une dépendance devient une décision d’achat. Chaque librairie est un fournisseur à suivre pendant toute la période de support, au moins cinq ans. Maintenance active, réactivité du mainteneur et historique de sécurité entrent dans le choix”, insiste François Baligant.

Cette exigence ne freine pas pour autant les équipes de développement. Le CTO de Theodo conteste l’opposition habituelle entre sécurité et vitesse : une équipe qui livre plusieurs fois par jour s’est outillée, estime-t-il, pour réagir rapidement. Les contrôles automatisés intégrés à la chaîne d’intégration, de la génération du SBOM à la détection de secrets (identifiants ou clés d’accès laissés dans le code), accélèrent selon lui la publication des correctifs.

Le parc installé pose des difficultés d’une autre nature. Loïs Samain cite les automates industriels devenus obsolètes, que leurs fabricants ne peuvent plus corriger. Les retirer du marché contraindrait certaines usines à reconstruire des lignes entières. Face à cette contrainte, le groupe RATP concentre ses efforts sur les systèmes exposés et sur ceux qui jouent un rôle critique pour la sécurité.

La mise en conformité pèse davantage sur les plus petits fournisseurs. Loïs Samain se souvient d’un boîtier industriel examiné il y a sept ou huit ans dans une autre entreprise : l’équipement était pourvu d’un chiffrement quasi inexistant, dû à des tailles de clé très faibles. “Nous ne pouvons pas nous contenter d’exiger d’un fournisseur qu’il soit ‘à l’état de l’art’. Il est nécessaire de fixer des exigences de cybersécurité concrètes, adaptées à des sous-traitants qui n’ont aucune expertise”, précise-t-il. Les grands clients partagent, à ses yeux, cette responsabilité. Il leur revient de formuler des exigences précises et d’accompagner les sous-traitants les moins matures.

Dans le secteur ferroviaire, cet effort prend une dimension collective. Les opérateurs et constructeurs européens (parmi lesquels la RATP, SNCF, Deutsche Bahn, Alstom, Siemens ou Hitachi) travaillent à une lecture commune d’un texte complexe, dont certains termes diffèrent entre les versions anglaise et française. 

La normalisation accompagne également ce mouvement. Des travaux européens visent notamment à adapter la norme EN IEC 62443 aux exigences du CRA afin que les futures normes harmonisées puissent fournir une présomption de conformité pour les exigences qu’elles couvriront. Pour Loïs Samain, cette mobilisation illustre l’ampleur du changement : le CRA concerne l’ensemble de l’écosystème industriel, bien au-delà du seul secteur numérique ou informatique traditionnel.