Le Cyber Resilience Act se gagne dans votre chaîne de livraison, pas dans un classeur
Point de vue : le CRA est avant tout une histoire d'ingénieurs et de bonnes pratiques. Ce que cela change pour l'entreprise, où mettre le budget, et ce que l'audit apporte.
Par Florian Mahon, fondateur d’ADNT Sàrl (point de vue).
En bref. Le Cyber Resilience Act (CRA) est une obligation ; l’enjeu est d’en faire une opportunité d’améliorer votre chaîne d’approvisionnement logicielle. Vous êtes concerné dès que vous mettez sur le marché européen un produit qui contient du logiciel, sauf exceptions étroites. Deux dates : 11 septembre 2026 pour la notification des vulnérabilités exploitées, 11 décembre 2027 pour l’ensemble des exigences. C’est le fabricant qui répond, pas son sous-traitant ni son équipe de développement. Et la vraie décision est budgétaire : financer une conformité sur papier, ou consolider la chaîne qui construit et livre votre logiciel.
Le Cyber Resilience Act arrive comme une contrainte réglementaire de plus : des obligations, des échéances, des preuves à fournir.
Je le vois autrement. Ce que le CRA demande, savoir ce qui tourne dans votre produit, détecter qu’une vulnérabilité le touche, corriger et livrer la mise à jour rapidement, c’est exactement ce qu’une équipe d’ingénieurs qui maîtrise sa chaîne cherche déjà à faire.
Le règlement ne fait qu’en faire une exigence de marché.
L’agilité a apporté au développement logiciel des boucles de retour plus courtes et la capacité de faire évoluer un produit sans dégrader l’existant. Elle repose concrètement sur la livraison continue, les tests automatisés, la revue de code, l’observabilité et une chaîne d’approvisionnement logicielle automatisée et reproductible.
Pour les entreprises qui s’en saisissent, c’est l’occasion de consolider ces pratiques et d’en faire un avantage : livrer plus vite, plus sûrement, et pouvoir le prouver.
Le règlement général sur la protection des données (RGPD) a fait entrer la protection des données dans la conception des services web. Le CRA peut faire entrer la sécurité et la maintenabilité dans la conception des logiciels et des firmwares.
Ce que le CRA change pour l’entreprise
Le règlement (UE) 2024/2847 introduit deux échéances clés.
Dès le 11 septembre 2026, les fabricants doivent notifier les vulnérabilités activement exploitées et les incidents graves ayant une incidence sur la sécurité de leurs produits. Dès le 11 décembre 2027, l’ensemble des exigences s’applique : conception sécurisée, gestion des vulnérabilités, mises à jour pendant la période de support, inventaire des composants logiciels (une SBOM) et évaluation de conformité.
Les détails de notification et les catégories de produits sont définis dans le règlement. Le fait important est ailleurs : les obligations portent sur le produit et sur la capacité réelle de l’organisation à le maintenir. La documentation est nécessaire, mais elle ne remplace pas cette capacité.
Les bonnes pratiques réduisent déjà l’écart
Le CRA ne demande pas d’inventer une sécurité à côté du logiciel.
Une équipe qui sait ce qu’elle livre, détecte les vulnérabilités, corrige sans régression, déploie des mises à jour fiables et réagit de manière organisée a déjà construit l’essentiel.
Un inventaire des composants logiciels (une SBOM, Software Bill of Materials), la surveillance des vulnérabilités publiées et de leurs références CVE, les tests, les builds reproductibles, les mises à jour signées et un dispositif de réponse aux vulnérabilités (un PSIRT) ne sont donc pas des cases à cocher. Ce sont les pratiques qui rendent le produit maintenable et permettent de répondre à un incident. Pour le détail de leur mise en œuvre, voir notre article SBOM et audit CVE en CI/CD pour l’embarqué baremetal.
Vous voulez passer du principe à l’implémentation ? Nous documentons les aspects techniques — SBOM, VEX (Vulnerability Exploitability eXchange, le document qui indique si un produit est réellement affecté), signature, intégrité, sécurité — dans CRA & Dev, notre wiki destiné aux développeurs. Il montre comment ces problématiques se traduisent côté développement ; il ne remplace ni l’évaluation de conformité ni les décisions décrites plus loin.
Il reste un travail de conformité : conserver les preuves, documenter les décisions et choisir la procédure d’évaluation de conformité applicable. Mais le point de départ n’est pas un classeur vierge ; c’est une chaîne de production qui fonctionne déjà. Cela réduit le risque, le délai et le coût de mise en conformité.
La maîtrise de la chaîne de livraison rend le CRA atteignable
Il ne s’agit pas de sprints ni d’un outil de suivi. L’apport essentiel de ces pratiques est de raccourcir la boucle entre un problème observé, une décision et une livraison. Appliquée à la sécurité, cette boucle permet à l’équipe de comprendre l’impact d’une vulnérabilité, choisir une réponse, livrer un correctif et en tirer les leçons.
Les tests automatisés, l’intégration continue et des releases fréquentes permettent de corriger sans paralyser l’activité. La reproductibilité ajoute une garantie décisive : une version historique peut être reconstruite et examinée au lieu d’être seulement supposée. Le CRA donne à cette capacité opérationnelle une importance de marché.
La sécurité protège l’utilisateur et l’entreprise
Ces pratiques ne servent pas seulement à satisfaire une autorité de surveillance. Elles protègent les données de l’utilisateur, la disponibilité du produit et sa confiance dans les mises à jour.
Réduire l’exposition, limiter les accès au nécessaire et corriger vite lorsqu’un problème survient : c’est ainsi que la sécurité devient une qualité du produit, et un facteur de confiance pour l’entreprise.
L’audit a un rôle utile : il vérifie que cette capacité existe et que ses preuves sont disponibles. Il ne doit pas la remplacer.
Transformer une obligation en investissement durable
Le budget CRA peut financer une bureaucratie parallèle, ou améliorer durablement la façon dont le logiciel est construit et livré.
La seconde option crée de la valeur après l’échéance réglementaire : des correctifs plus rapides, moins de régressions, une meilleure maîtrise des versions en production et moins de risque opérationnel.
La valeur n’est pas dans le rituel ni dans le document. Elle est dans la capacité de l’équipe à apprendre, corriger et livrer. Le CRA rend cette capacité visible et exigible.
Une responsabilité d’entreprise, pas seulement d’équipe
C’est une histoire d’ingénieurs, mais elle ne se joue pas qu’entre ingénieurs. L’équipe technique peut construire la capacité à savoir, détecter, corriger et livrer. Trois décisions, elles, ne peuvent pas être prises depuis la chaîne de build :
- Porter la démarche, pas seulement la déléguer. Nommer un responsable, lui donner du temps d’ingénierie, et suivre l’avancement comme n’importe quel chantier produit.
- Exiger des preuves issues du build, pas des documents. Une SBOM générée à chaque version, un scan des CVE dans l’intégration continue et un exercice de réponse à incident valent plus qu’une politique signée.
- Arbitrer la période de support par produit. C’est un engagement commercial et financier : combien de temps chaque produit recevra des correctifs, et avec quels moyens.
Aucun de ces choix ne demande de compétence technique. Ils demandent que la sécurité du logiciel soit traitée au même titre que la sécurité physique du produit.
Le CRA impose le calendrier ; à vous d’en faire un levier de qualité logicielle
Après décembre 2027, ce qui restera ne sera pas un classeur. Ce sera une équipe mieux outillée, un produit plus fiable et des utilisateurs mieux protégés. Le règlement fixe une date ; les bonnes pratiques, elles, restent avec vous. La décision de les financer vous appartient.
Aller plus loin : du point de vue au diagnostic
Nous accompagnons éditeurs de logiciels et fabricants de produits embarqués sur toute la démarche, en partant de leur chaîne de build : notre accompagnement conformité CRA.
➡️ Vérifier si votre produit est concerné : 3 minutes, sans e-mail