EU CRA : traçabilité du code et gestion des vulnérabilités en vertu de la loi
Loi américaine sur la cyber-résilience (EU Cyber Resilience Act) : la sécurité des logiciels est désormais une obligation légale assortie du marquage CE
Le règlement (UE) 2024/2847 fait de la cybersécurité une exigence de mise sur le marché pour tout produit comportant des éléments numériques au sein de 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 désormais 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 justifient leur cycle de vie de développement sécurisé (SDL) · depuis 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 Git génère la chaîne de traçabilité cryptographique du code, commit après 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é facultative qui n’est ajoutée que si le marché l’exige. La loi européenne sur la cyber-résilience 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é de 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 :
- Oct. 2024Adoption du règlementLe compte à rebours commence pour les fabricants
- 11 septembre 2026 · déjà en vigueurSignaler les vulnérabilités exploitéesArt. 14 : notification à l’ENISA et au CSIRT dans des délais courts
- 11 décembre 2027Application intégraleExigences de l’annexe I et marquage CE de cybersécurité
- Tout au long du cycle de vie du produitAssistance et mises à jourGestion documentée des vulnérabilités, version par version
Pour chaque version, V-PROOF consigne de manière sécurisée quel code a été publié, ce qui a été corrigé et à quelle date : c'est cette traçabilité qu'exigera un organisme notifié.
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 la mise en place d'un cycle de vie de développement sécurisé (Secure Development Lifecycle), 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 pour chacun d'entre eux
Couverture V-PROOF conformément aux exigences de l'UE et de la CRA
| Obligation EU CRA | Condition requise | Couverture | Module V-PROOF |
|---|---|---|---|
| Art. 13, Cycle de vie de développement sécurisé | |||
| Art. 13, paragraphe 1, de la loi sur le travail (SDL), tel qu'il figure dans le texte officiel | 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 Core Intégration Git |
| Art. 14, Notification des vulnérabilités et des incidents | |||
| Art. 14, paragraphe 1,24 h, alerte de l'ENISA | Enregistrement, via timestamp, du moment exact de la découverte de la vulnérabilité exploitée | ✓ Terminé | V-Seal Core |
| Art. 14, paragraphe 2, point72h, Notification | Relevé des mesures prises depuis la découverte jusqu'à la notification officielle | ✓ Terminé | V-Seal Core |
| 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 Core |
| 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 Noyau |
| Convergence entre la loi européenne sur les comptes rendus (EU CRA) et la loi européenne sur l'IA (EU AI Act), pour les logiciels comportant des composants d'IA | |||
| Art. 13 du CRA de l'UE+ art. 12 de la loi européenne sur l'IA | 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 à la loi européenne sur l'IA. 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’une intelligence artificielle (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 loi européenne sur l’IA (EU AI Act) et des produits comportant des éléments numériques au sens du règlement européen sur la traçabilité des produits (EU CRA). Le fabricant doit se conformer aux exigences de traçabilité du cycle de vie du logiciel (CRA de l’UE, art. 13) ainsi qu’aux exigences d’enregistrement des événements et de supervision humaine du système d’IA (loi européenne sur l’IA, art. 12 et 14) pour ce même produit.
V-PROOF couvre l'intersection grâce à une seule intégration
Le module AI Orchestrator de V-PROOF enregistre 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 enregistrée 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 données à caractère personnel (CRA) (art. 13) et par la loi européenne sur l’IA (art. 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 modifie 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 le cadre de 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 Git Integration assure la traçabilité du code depuis son siège social situé 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 face à 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, le SDL documenté et vérifiable exigé par l'article 13, mise en place au cours du développement normal Art. 13, SDL vérifiable
- Timestamp chaîne de blocs indiquant le moment exact de la découverte de chaque vulnérabilité, élément essentiel 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 permettant de générer et de vérifier la SBOM visée à l'article 16 Article 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 couverture au titre de la CRA de l’UE et de la loi européenne sur l’IA pour 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 n'est pas 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 ceux des classes I et II, qui font l'objet d'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 et de la loi européenne sur l'IA, et qui 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 européenne sur l’IA (EU AI Act)
- La conception de l'architecture de sécurité du produit : V-PROOF fournit des preuves vérifiables 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 scelle 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 génère le registre vérifiable 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 fournit les éléments techniques nécessaires à 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 propose 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 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 (loi européenne sur l'IA) · référence de convergence avec la CRA de l'UE pour les logiciels dotés d'IA, EUR-Lex
