EU CRA : traçabilité des codes et gestion des vulnérabilités en tant qu'obligation légale
Loi américaine sur la cyber-résilience (EU Cyber Resilience Act) : la sécurité des logiciels est désormais une obligation légale avec le marquage CE
Le règlement (UE) 2024/2847 fait de la cybersécurité une condition de mise sur le marché pour tout produit comportant des éléments numériques dans l'UE. La traçabilité du code, la gestion des vulnérabilités et la liste vérifiable des composants logiciels (SBOM) ne sont plus de simples bonnes pratiques, mais deviennent des obligations légales.
Points clés
- Le règlement (UE) 2024/2847 (EU CRA), publié le 23 octobre 2024, établit des exigences obligatoires en matière de cybersécurité pour tous les produits comportant des éléments numériques commercialisés dans l'UE.
- Les obligations de notification des vulnérabilités activement exploitées (art. 14) s'appliquent à compter du 11 septembre 2026 — première date butoir pour les éditeurs de logiciels.
- La mise en œuvre intégrale du règlement, y compris le marquage CE de cybersécurité, entrera en vigueur le 11 décembre 2027.
- L'article 13 exige que les fabricants documentent et certifient leur cycle de développement sécurisé (SDL), de la conception jusqu'à la fin de vie du produit.
- L'article 16 rend obligatoire la « Software Bill of Materials » (SBOM) : une liste vérifiable de tous les composants logiciels du produit.
- L'intégration V-PROOF génère la chaîne de traçabilité cryptographique du code, commit par commit — ce qui constitue la base technique permettant de se conformer simultanément aux articles 13, 14 et 16.
EU CRA : quand le principe « secure by design » cesse d'être un simple slogan pour devenir une obligation légale
Pendant des décennies, le secteur des logiciels a fonctionné selon un principe implicite : la cybersécurité est une fonctionnalité optionnelle qui n’est ajoutée que si le marché l’exige. La loi européenne sur la cyber-résilience (EU Cyber Resilience Act) met fin à ce modèle. À compter de décembre 2027, aucun produit comportant des éléments numériques ne pourra être commercialisé dans l’UE sans qu’il soit démontré qu’il respecte les exigences de sécurité énoncées à l’annexe I du règlement.
Publié le 23 octobre 2024 au Journal officiel de l'UE, le règlement (UE) 2024/2847 s'applique à tout produit matériel ou logiciel comportant des « éléments numériques » — une définition délibérément large qui couvre aussi bien les appareils IoT industriels que les applications mobiles, en passant par les systèmes de contrôle d'accès et les logiciels de gestion d'entreprise. Seuls sont explicitement exclus les produits déjà couverts par une réglementation sectorielle spécifique (dispositifs médicaux, véhicules, aviation) et les logiciels en tant que service (SaaS) purs, sans téléchargement de composants sur l'appareil de l'utilisateur.
Le changement de paradigme de l'EU CRA
L'EU CRA transfère la responsabilité de la cybersécurité de l'utilisateur final au fabricant. Jusqu'à présent, lorsqu'un logiciel présentait des vulnérabilités, l'utilisateur « acceptait le risque » en installant le produit. Avec l'EU CRA, le fabricant est responsable de la sécurité du produit tout au long de son cycle de vie, y compris la gestion des vulnérabilités après la mise sur le marché pendant au moins cinq ans ou pendant la durée d'utilisation prévue si celle-ci est plus longue.
Les sanctions en cas de non-respect sont lourdes : jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial en cas de non-respect des exigences essentielles en matière de cybersécurité prévues à l'annexe I, et jusqu'à 10 millions d'euros ou 2 % en cas de non-respect d'autres obligations, telles que la notification des vulnérabilités. Les autorités nationales de surveillance du marché sont chargées de la surveillance dans chaque État membre.
Trois catégories, trois niveaux d'exigence
L'EU CRA classe les produits en trois catégories en fonction de leur niveau de risque en matière de cybersécurité. La catégorie détermine la procédure d'évaluation de la conformité requise pour obtenir le marquage CE :
Les dates que les équipes produit doivent inclure dans leur feuille de route
Pourquoi commencer maintenant et non en 2027 ?
L'EU CRA exige des fabricants qu'ils démontrent l'existence d'un « Secure Development Lifecycle » — un cycle de développement sécurisé — et non pas seulement que le produit final réponde à des exigences ponctuelles. Un processus s'appuie sur un historique. Les audits de conformité porteront sur le passé : un fabricant qui commencera à sécuriser cryptographiquement son processus de développement entre 2024 et 2026 disposera de deux ou trois ans d’historique vérifiable au moment de l’évaluation. Celui qui commencera en décembre 2027 n’aura aucun historique démontrable.
Les articles qui nécessitent des preuves techniques — et ce que V-PROOF génère V-PROOF chacun d'entre eux
Couverture V-PROOF l'obligation de l'UE CRA
| Obligation EU CRA | Condition requise | Couverture | Module V-PROOF |
|---|---|---|---|
| Art. 13 — Cycle de vie du développement sécurisé | |||
| Art. 13, paragraphe 1, de laSDL, tel que documenté | Historique vérifiable du processus de développement sécurisé, de la conception au déploiement | ✓ Terminé | Intégration Git |
| Art. 13, paragraphe 3 :Gestion des correctifs | Traçabilité de l'application des correctifs de sécurité : quand, quelle version, qui l'a autorisée | ✓ Terminé | Intégration Git |
| Art. 13, paragraphe 6 :Documentation technique | Documentation technique à jour et vérifiable aux fins de l'évaluation de la conformité | ✓ Terminé | V-Seal Intégration Git |
| Art. 14 — Notification des vulnérabilités et des incidents | |||
| Art. 14, paragraphe 1,24h — Alerte de l'ENISA | Enregistrement avec timestamp le moment exact de la découverte de la vulnérabilité exploitée | ✓ Terminé | V-Seal |
| Art. 14, paragraphe 2, point72h — Notification | Relevé des mesures prises depuis la découverte jusqu'à la notification officielle | ✓ Terminé | V-Seal |
| Art. 14, paragraphe 7 :Notification à l'ENISA | La notification officielle à l'ENISA incombe au fabricant | — Responsabilité du fabricant | Processus réglementaire |
| Art. 16 — Liste des composants logiciels (SBOM) | |||
| Art.16SBOM vérifiable | Liste complète et vérifiable des composants logiciels, y compris les dépendances tierces et open source | ✓ Terminé | Intégration Git |
| Annexe I — Exigences essentielles en matière de cybersécurité | |||
| Annexe I — PartieI Exigences relatives au produit | Preuve de la mise en œuvre de chaque mesure de sécurité requise dans la conception du produit | ✓ Terminé | V-Seal |
| Annexe I — PartieII : Gestion des vulnérabilités | Processus vérifiable d'identification, d'analyse et de correction des vulnérabilités tout au long du cycle de vie | ✓ Terminé | Intégration Git V-Seal |
| Convergence entre l'EU CRA et EU AI Act Pour les logiciels comportant des composants d'IA | |||
| Art. 13 de la CRA de l'UE+ EU AI Act . 12 EU AI Act | Traçabilité du cycle de vie des modèles d'IA intégrés dans des produits logiciels : versions, apprentissage, déploiement | ✓ Terminé | AI Orchestrator Intégration Git |
EU CRA + EU AI Act: la double obligation pour les logiciels intégrant l'IA
Tout logiciel intégrant des composants d'IA est soumis à la fois au CRA de l'UE et à EU AI Act. Et cette convergence engendre des obligations supplémentaires qu'aucun des deux cadres ne couvre à lui seul.
Un système de détection des anomalies basé sur l’apprentissage automatique (ML) intégré à un logiciel de cybersécurité, un assistant de codage doté d’IA, un système de recommandation en matière de sécurité sur une plateforme SaaS : tous ces éléments constituent des systèmes d’IA au sens de la EU AI Act des produits comportant des éléments numériques au sens du règlement européen sur la traçabilité des cycles de vie des logiciels (EU CRA). Le fabricant doit se conformer aux exigences de traçabilité du cycle de vie du logiciel (article 13 de la CRA de l’UE) ainsi qu’aux exigences d’enregistrement des événements et de supervision humaine du système d’IA (EU AI Act 12 et 14EU AI Act ) pour ce même produit.
V-PROOF l'intersection en une seule intégration
Le module AI Orchestrator de V-PROOF de manière cryptographique l'intégralité du cycle de vie des modèles d'IA intégrés au produit : ensembles de données d'entraînement, versions du modèle, indicateurs d'évaluation et chaque décision prise en production. Le module Git Integration enregistre le code qui les met en œuvre. Ensemble, ils répondent aux obligations de traçabilité prévues par le règlement européen sur les produits de consommation (CRA) (art. 13) et par EU AI Act arts. 12, 16) sans duplication de l’intégration.
L'EU CRA et la sécurité de la chaîne d'approvisionnement logicielle
L'EU CRA introduit un concept qui bouleverse la manière dont les équipes de développement doivent envisager leurs dépendances : la responsabilité de la chaîne d'approvisionnement logicielle. Les fabricants sont responsables des vulnérabilités des composants tiers qu'ils intègrent dans leurs produits, y compris les bibliothèques open source.
Cette responsabilité s'étend aux fournisseurs d'outils de développement auxquels le fabricant a recours dans son processus de SDL. Un fabricant qui utilise une plateforme de CI/CD ou de gestion de code basée aux États-Unis pour gérer son processus de développement sécurisé introduit dans sa chaîne d’approvisionnement un élément soumis au CLOUD Act. Si les autorités américaines exigent l’accès à l’historique de développement du produit — y compris les registres des vulnérabilités découvertes et leurs délais de résolution —, ce fournisseur ne peut garantir la confidentialité.
V-PROOF Integration assure la traçabilité du code depuis son siège social en Espagne. Les registres du SDL sont souverains : la chaîne de conservation cryptographique du processus de développement reste sous la juridiction de l'UE.
V-PROOF à l'EU CRA
Atouts, cas d'utilisation dans le domaine réglementaire et limites du champ d'application
- Chaîne de traçabilité cryptographique de chaque commit — la SDL documentée et vérifiable exigée par l’article 13, établie au cours du développement normal Art. 13 — SDL vérifiable
- Timestamp indiquant le moment exact de la découverte de chaque vulnérabilité — indispensable pour prouver le respect du délai de 24 heures prévu à l'article 14 Art. 14 — Notification des vulnérabilités
- Traçabilité des dépendances et des composants tiers, commit par commit — la base technique pour générer et vérifier la SBOM visée à l’article 16 Art. 16 — SBOM
- Historique vérifiable de la mise en œuvre des contrôles de l'annexe I — éléments justificatifs pour la documentation technique relative à l'évaluation de la conformité et au marquage CE Annexe I — Exigences essentielles
- Double conformité à la CRA de l'UE et à EU AI Act les logiciels intégrant des composants d'IA — une seule intégration pour deux cadres réglementaires Convergence réglementaire 2026–2027
- Fournisseur dont le siège social est situé en Espagne : le processus SDL enregistré dans V-PROOF est V-PROOF soumis au CLOUD Act américain Souveraineté de la chaîne d'approvisionnement
- Les éditeurs de logiciels indépendants (ISV) qui commercialisent des logiciels dans l'UE et doivent documenter leur SDL avant décembre 2027 Art. 13 — Éditeurs de logiciels
- Fabricants d'appareils IoT industriels et grand public dotés d'un logiciel intégré — en particulier les appareils de classe I et II soumis à des exigences d'évaluation plus strictes Classes I–II — Produits critiques
- Les équipes DevSecOps qui ont besoin de sécuriser cryptographiquement leur pipeline CI/CD afin d'attester de la sécurité du processus de développement Art. 13 — Pipeline CI/CD
- Les RSSI préparent la documentation technique nécessaire aux évaluations de conformité des dispositifs de classe I et II le plus tôt possible Articles 24 à 32 — Évaluation de la conformité
- Les éditeurs de logiciels intégrant l'IA, soumis à la double obligation de la CRA de l'UE EU AI Act recherchent une infrastructure unique de traçabilité Convergence entre la loi européenne sur la responsabilité en matière de données (EU CRA) et la loi EU AI Act)
- La conception de l'architecture de sécurité du produit : V-PROOF que le processus de mise en œuvre s'est déroulé correctement, mais ne conçoit pas l'architecture de sécurité. Conception du produit
- Tests d'intrusion et tests de sécurité (annexe I) : V-PROOF les résultats des tests, mais ne les réalise pas. Les tests sont effectués par l'équipe de sécurité ou par un tiers spécialisé. Annexe I — Tests de sécurité
- La notification officielle des vulnérabilités à l’ENISA (art. 14) : V-PROOF un enregistrement immuable de la découverte ; la notification officielle à l’autorité de régulation incombe au fabricant. Art. 14 — Notification à l'ENISA
- Le marquage CE (art. 47) : il nécessite une évaluation de la conformité par un organisme notifié pour les classes I et II. V-PROOF les éléments techniques qui facilitent cette évaluation, mais ne la délivre pas. Art. 47 — Marquage CE
Votre équipe de développement dispose-t-elle de la documentation relative au cycle de vie du logiciel (SDL) que les évaluateurs de conformité CRA exigeront ?
V-PROOF un diagnostic stratégique en 48 heures qui recense les obligations CRA de l'UE applicables à vos produits, identifie les lacunes existantes en matière de traçabilité du code et définit l'intégration Git nécessaire.
Demander un diagnostic stratégique EU CRASources et références réglementaires
- Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 — EUR-Lex CELEX:32024R2847
- ENISA — Guide de mise en œuvre de la directive CRA de l'UE, 2025 — enisa.europa.eu
- Commission européenne — Foire aux questions sur l'EU CRA — digital-strategy.ec.europa.eu
- CEN/CENELEC — Mandat de normalisation pour l'EU CRA (normes techniques harmonisées) — cencenelec.eu
- BSI (Office fédéral allemand pour la sécurité informatique) — Guide d'orientation de l'EU CRA à l'intention des fabricants, 2025 — bsi.bund.de
- Règlement (UE) 2024/1689 (EU AI Act) — référence de convergence avec la CRA de l’UE pour les logiciels dotés d’IA — EUR-Lex
