Le Cyber Resilience Act entre en application — chaque dépendance de votre logiciel doit être documentée, signée et traçable sous 36 mois
Le règlement européen 2024/2847, dit Cyber Resilience Act, entre en application progressive à partir de 2026. Il impose à tout éditeur commercialisant un produit logiciel dans l’UE de produire un SBOM complet, de corriger les vulnérabilités connues sous cinq jours ouvrés et de notifier les incidents critiques à l’ENISA sous 24 heures. Voici ce que votre organisation doit faire avant la première échéance contraignante.
Le Cyber Resilience Act (CRA) — règlement européen 2024/2847 adopté le 10 octobre 2024 — n’est plus un texte en discussion. Il entre en application progressive à partir de 2026, avec une première échéance contraignante au 11 juin 2027 pour les obligations de notification. Pour la première fois, l’Union européenne impose à tout éditeur — du géant du SaaS à la PME qui vend un plugin WordPress — de documenter, maintenir et sécuriser l’intégralité de sa chaîne d’approvisionnement logicielle.
Le CRA ne fait pas de distinction entre un produit matériel contenant du logiciel (un routeur, une caméra IP), un logiciel embarqué, un SaaS ou une bibliothèque open source utilisée dans un produit commercial. Si le logiciel est « mis sur le marché » européen, il est concerné. La période de transition est de 36 mois à compter de l’entrée en vigueur (décembre 2024), ce qui place les premières obligations opérationnelles au 11 décembre 2027 — avec des jalons intermédiaires dès 2026.
Les trois obligations qui changent tout
Le CRA s’articule autour de trois obligations structurantes :
1. SBOM obligatoire pour tout produit logiciel
Chaque produit logiciel mis sur le marché européen doit être accompagné d’un Software Bill of Materials au format SPDX 3.0 ou CycloneDX 1.6. Le SBOM doit lister :
- Toutes les dépendances directes et transitives, avec leur version exacte et leur origine.
- Les licences de chaque composant.
- Les CVE connues affectant chaque dépendance, avec leur score CVSS et leur statut de correction.
L’obligation couvre aussi bien le code first-party (votre application) que le code third-party (bibliothèques, conteneurs de base, runtimes) et les services externes intégrés (API tierces dont la compromission affecterait la sécurité du produit). La Commission européenne estime que cette obligation s’appliquera à plus de 30 000 éditeurs dans l’UE.
Pour une équipe de développement, cela signifie intégrer Syft, Trivy ou cdxgen dans le pipeline CI/CD avant la fin 2026. Générer un SBOM rétroactivement pour 150 microservices et 8 000 dépendances transitives n’est pas un exercice qu’on improvise en décembre 2027.
2. Correction des vulnérabilités sous cinq jours ouvrés
Le CRA impose aux éditeurs de corriger les vulnérabilités activement exploitées dans un délai de cinq jours ouvrés après la divulgation publique. Pour les vulnérabilités critiques sans exploitation connue, le délai est de 30 jours. Cette obligation est continue pendant toute la durée de vie annoncée du produit — et la durée de vie minimale est fixée à cinq ans à compter de la date de commercialisation.
Ce délai de cinq jours est le plus agressif jamais imposé par une réglementation. À titre de comparaison, la directive NIS2 (2023) prévoyait un délai de 24 heures pour la notification d’incident, mais aucun délai contraignant de correction. Le CRA va plus loin : il ne suffit pas de dire « nous travaillons sur un correctif ». Le correctif doit être livré, documenté et vérifiable.
Pour les organisations qui maintiennent des logiciels en fin de vie ou des versions legacy non couvertes par un contrat de maintenance, le CRA crée une obligation juridique de continuer à corriger ou de retirer le produit du marché. C’est un changement radical pour l’industrie du logiciel d’entreprise, où les versions N-2 sont souvent laissées sans correctif faute de budget.
3. Notification à l’ENISA sous 24 heures
Toute vulnérabilité exploitée ou tout incident de sécurité affectant un produit logiciel doit être notifié à l’ENISA (Agence européenne pour la cybersécurité) dans un délai de 24 heures suivant la prise de connaissance. La notification doit inclure :
- La nature de la vulnérabilité, le score CVSS, le vecteur d’attaque.
- Le périmètre des produits affectés (versions, configurations).
- Les mesures de remédiation disponibles ou le calendrier prévisionnel.
- Une évaluation de l’impact transfrontière.
L’ENISA agira comme un CSIRT européen centralisé pour les vulnérabilités produits, en coordination avec les CSIRT nationaux. Le non-respect de cette obligation expose l’éditeur à des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial — le même plafond que le RGPD.
Open source : la première exception structurée
Le CRA contient une exception importante pour l’open source après un intense lobbying de la Linux Foundation, de l’Eclipse Foundation et de l’Open Source Initiative. Les logiciels open source fournis gratuitement et sans modèle commercial direct sont exclus du champ d’application — à condition qu’ils ne soient pas intégrés dans un produit commercial.
En clair : le mainteneur bénévole d’une bibliothèque npm n’est pas soumis au CRA. Mais l’entreprise qui intègre cette bibliothèque dans son produit SaaS l’est intégralement — et c’est à elle de produire le SBOM couvrant la bibliothèque open source, de surveiller ses CVE et d’appliquer les correctifs dans les délais.
Cette distinction crée une asymétrie de responsabilité qui inquiète la communauté open source : les grands consommateurs de logiciel libre (AWS, Google, Microsoft) devront surveiller et corriger les vulnérabilités de composants qu’ils n’ont pas écrits, maintenus par des bénévoles sans obligation de correction rapide. La Linux Foundation a proposé la création d’un fonds de maintenance CRA financé par les entreprises pour soutenir les mainteneurs critiques — le débat est ouvert.
Le calendrier précis des échéances
| Date | Obligation |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du CRA (publication au JOUE) |
| 11 juin 2027 | Obligation de notification à l’ENISA pour les incidents critiques |
| 11 septembre 2027 | Obligation de notification pour les vulnérabilités exploitables |
| 11 décembre 2027 | Application complète : SBOM obligatoire, correctifs 5/30 jours, durée de support 5 ans |
Le 11 décembre 2027 est la date à laquelle un produit logiciel non conforme ne pourra plus être commercialisé dans l’UE. Les autorités de surveillance nationales (l’ANSSI en France, le BSI en Allemagne) seront chargées des contrôles et des sanctions.
Verdict : ce que votre organisation doit faire maintenant
Le CRA n’est pas une formalité administrative lointaine. C’est une refonte de la responsabilité logicielle qui arrive dans 16 mois pour les premières obligations et 18 mois pour la conformité complète. Voici le plan d’action minimal :
- Avant mars 2027 : intégrez un générateur de SBOM (Syft, Trivy, cdxgen) dans votre pipeline CI/CD. Générez un SBOM pour chaque build et stockez-le avec l’artefact. Le format CycloneDX 1.6 est le bon compromis entre compatibilité outillage et conformité CRA.
- Avant juin 2027 : mettez en place une procédure de notification ENISA. Identifiez qui dans votre organisation est responsable de la qualification CVSS, de la rédaction du rapport et de la soumission dans le délai de 24 heures. Testez la procédure sur un exercice.
- Avant septembre 2027 : auditez votre capacité à corriger une vulnérabilité critique en cinq jours ouvrés. Si votre processus de release actuel prend deux semaines de QA, vous n’êtes pas conforme. L’automatisation des tests de non-régression et le déploiement progressif (canary releases) deviennent des prérequis de conformité réglementaire.
- Avant décembre 2027 : pour chaque produit logiciel que vous maintenez, vérifiez que vous pouvez produire un SBOM complet couvrant l’intégralité de la chaîne de dépendances. Si un composant n’a pas de SBOM, vous ne pouvez pas légalement le livrer dans l’UE.
Le Cyber Resilience Act coûtera cher en ingénierie et en processus aux organisations qui ne l’ont pas anticipé. Mais pour celles qui l’intègrent dès maintenant, il deviendra un avantage concurrentiel : un SBOM vérifiable et une politique de correction en cinq jours ouvrés seront les nouveaux standards de confiance du marché logiciel européen.
Références
- Parlement européen et Conseil, « Règlement (UE) 2024/2847 concernant des exigences horizontales en matière de cybersécurité pour les produits comportant des éléments numériques (Cyber Resilience Act) », JOUE, 10 décembre 2024
- ENISA, « Cyber Resilience Act Implementation Guidelines — Draft », juillet 2026
- Linux Foundation, « CRA and Open Source : Impact Analysis V2 », juin 2026
- Open Source Initiative, « CRA FAQ for Open Source Maintainers », mise à jour avril 2026
- « Executive Order 14028 — Improving the Nation’s Cybersecurity », The White House, mai 2021