Le Cyber Resilience Act de l'UE : guide pratique pour les PME

Un avenir numérique plus sûr pour les PME

Et si chaque outil sur lequel tourne votre entreprise, de votre CRM à la paie en passant par l’application de messagerie de votre équipe, devait prouver qu’il est sûr avant que vous l’achetiez ?

C’est ce que le Cyber Resilience Act (CRA) de l’UE apporte au marché. Il va changer la façon dont les petites et moyennes entreprises (PME) de toute l’Europe choisissent, achètent et accordent leur confiance à leurs logiciels et appareils connectés.

Inutile d’être expert en cybersécurité pour en profiter. Il faut savoir quelles questions poser, quels signaux d’alerte repérer, et comment la conformité au CRA peut passer d’une case juridique à cocher à un avantage concurrentiel. Ce guide vous donne les trois.

Trop de produits sont encore livrés avec une sécurité faible : composants obsolètes, mots de passe par défaut, aucune assistance à long terme. Quand des attaquants exploitent ces failles, les PME paient souvent le prix fort en interruptions, pertes de données et atteinte à leur réputation.

Le CRA renverse la logique. Les fabricants doivent démontrer que leurs produits sont sûrs avant qu’ils n’arrivent sur le marché de l’UE. Pour vous, cela signifie des garanties plus solides de la part des fournisseurs et une base ferme pour exiger des preuves avant de signer.

Pensez au marquage CE des produits physiques. Comme ce marquage signale la sécurité, la conformité au CRA deviendra le signal de confiance des produits numériques. La sécurité cesse d’être facultative.

Ce qui distingue cette loi

Le RGPD protège les données personnelles. Le CRA porte sur la sécurité du produit lui-même, dès la conception et pendant toute sa durée de vie. Il impose aux fabricants de :

• corriger rapidement les vulnérabilités et fournir gratuitement les mises à jour de sécurité
• être transparents sur les mises à jour de sécurité et sur la durée d’assistance d’un produit
• documenter les composants tiers de leurs produits
• prouver la conformité avant la mise en vente du produit

Pour les PME, cela signifie que vous pouvez tenir vos fournisseurs pour responsables et attendre des produits plus sûrs.

Les PME en tant que fabricants

Le CRA n’est pas seulement une exigence à adresser à vos fournisseurs. Il s’applique aussi à vous si vous fabriquez des produits comportant des éléments numériques et les vendez dans l’UE. Si votre entreprise construit du matériel, intègre du logiciel dans des appareils ou développe des logiciels qu’elle vend, vous avez les mêmes obligations que les grands fabricants. Les importateurs et distributeurs qui revendent des produits ont leurs propres obligations, plus légères, sauf s’ils vendent le produit sous leur propre nom.

La première étape est votre chaîne d’approvisionnement. En tant que fabricant, vous devez faire preuve de diligence pour chaque composant que vous intégrez, bibliothèques open source comprises. Si le composant d’un fournisseur n’est pas sûr, son risque devient le vôtre.

La deuxième étape consiste à regarder en interne. Le CRA fait de la sécurité dès la conception une obligation légale et non plus une bonne pratique. Cela comprend :

• évaluer vos processus de développement ou d’intégration
• trouver et corriger rapidement les vulnérabilités
• documenter la manière dont la sécurité est intégrée à chaque étape du cycle de vie de votre produit

Les étapes pratiques sont détaillées plus bas.

Le CRA en bref

Calendrier

Pour les PME acheteuses : demandez dès maintenant à vos fournisseurs comment ils se préparent. À partir du 11 décembre 2027, les produits qui ne respectent pas le CRA ne peuvent plus être mis sur le marché de l’UE.

Qui est concerné

Le CRA couvre les produits comportant des éléments numériques : logiciels et matériels qui se connectent à un appareil ou à un réseau. Beaucoup d’outils que les PME utilisent chaque jour en relèvent :

• les logiciels métier installés, comme la comptabilité, le CRM et la bureautique
• les clients de collaboration et de visioconférence
• les ordinateurs portables, téléphones, routeurs et imprimantes
• les logiciels de sécurité, comme les clients VPN et les gestionnaires de mots de passe

Le SaaS pur est hors du champ du CRA ; de nombreux fournisseurs cloud relèvent plutôt de NIS2. Mais un backend cloud dont un produit a besoin pour fonctionner, comme le serveur derrière l’application d’une serrure connectée, fait partie du produit. Les applications et agents téléchargeables fournis avec un service SaaS relèvent en général aussi du CRA.

Voici les acteurs concernés par le CRA :

Classes de produits

Le CRA répartit les produits comportant des éléments numériques en quatre catégories. Plus le risque est élevé, plus l’évaluation de la conformité est stricte. Voici une vue d’ensemble, avec pour chacune ce qu’il faut demander à votre fournisseur :

Par défaut : la catégorie au risque le plus faible

La Commission européenne estime qu’environ 90% des produits couverts par le CRA relèvent de la catégorie par défaut. Ils présentent moins de risque intrinsèque que les catégories listées, mais doivent tout de même respecter toutes les exigences essentielles de cybersécurité du CRA.

Exemples de produits par défaut achetés par les PME :

• logiciels généralistes : suites bureautiques, outils de prise de notes et de gestion de projet, logiciels de comptabilité et de facturation, clients de messagerie, applications de chat et de visioconférence, retouche photo et montage vidéo, et logiciels CRM, RH et ERP installés
• matériel de bureau : ordinateurs portables et fixes, tablettes, smartphones, écrans, souris, claviers et webcams
• appareils de bureau connectés sans fonction de sécurité : éclairage connecté, thermostats, régulateurs de chauffage et de climatisation, imprimantes et projecteurs connectés
• appareils grand public utilisés au travail : téléviseurs connectés, tableaux blancs et systèmes de conférence connectés, et affichage numérique

Un produit par défaut peut néanmoins contenir des composants de classe I. Un ordinateur portable est un produit par défaut, mais le système d’exploitation qu’il exécute est lui-même un produit de classe I.

Les fabricants de produits par défaut évaluent eux-mêmes la conformité. Cela n’abaisse pas le niveau d’exigence : vos fournisseurs ont toujours besoin de sécurité dès la conception, de gestion des vulnérabilités et de documentation. Servez-vous de la liste de contrôle fournisseurs ci-dessous pour demander des preuves.

Important, classe I : risque accru

Les produits de classe I (annexe III, partie I) remplissent des fonctions de sécurité ou contrôlent l’accès aux réseaux et aux systèmes, si bien qu’une compromission a des effets plus larges que pour un produit par défaut. La liste :

• logiciels et matériels de gestion des identités et de gestion des accès à privilèges, y compris les lecteurs d’authentification comme les lecteurs de badges et biométriques
• navigateurs, gestionnaires de mots de passe et logiciels anti-malware
• produits VPN, systèmes de gestion de réseau et systèmes SIEM
• gestionnaires d’amorçage, PKI et logiciels d’émission de certificats, interfaces réseau physiques et virtuelles, et systèmes d’exploitation
• routeurs, modems et commutateurs
• microprocesseurs, microcontrôleurs, ASIC et FPGA dotés de fonctions de sécurité
• assistants virtuels pour la maison connectée, et produits de sécurité pour la maison connectée comme les serrures connectées, les caméras de sécurité, les babyphones et les systèmes d’alarme
• jouets connectés avec interaction sociale ou géolocalisation, et objets connectés portables qui surveillent la santé ou sont destinés aux enfants

Un fabricant ne peut évaluer lui-même un produit de classe I que s’il applique intégralement des normes harmonisées, des spécifications communes ou une certification européenne de cybersécurité. Sinon, un organisme notifié doit intervenir. Peu de normes harmonisées sont citées à ce jour (voir notre panorama des normes harmonisées du CRA), attendez-vous donc à ce que de nombreux produits de classe I passent d’abord par un organisme notifié.

Quand vous achetez un produit de classe I, vérifiez que le fournisseur s’engage à le maintenir sûr dans la durée : marquage CE et déclaration UE de conformité, mises à jour de sécurité régulières, période d’assistance et politique de fin de vie claires, et paramètres par défaut sûrs comme une authentification forte et le chiffrement. Demandez où seront stockées vos données professionnelles, combien de temps le produit sera maintenu, et à quelle vitesse le fournisseur a corrigé les problèmes par le passé. Choisissez des fournisseurs qui assument la responsabilité de la sécurité, pas seulement des fonctionnalités.

Important, classe II : risque élevé

La classe II (annexe III, partie II) est une liste courte :

• hyperviseurs et systèmes d’exécution de conteneurs
• pare-feu et systèmes de détection et de prévention des intrusions, y compris les pare-feu de nouvelle génération et les appliances UTM
• microprocesseurs et microcontrôleurs inviolables

Les fabricants ne peuvent pas évaluer eux-mêmes ces produits, même lorsqu’ils appliquent des normes harmonisées. Il leur faut un organisme notifié, ou un certificat européen de cybersécurité au niveau d’assurance “substantiel” ou supérieur.

Quand vous achetez un produit de classe II, demandez le marquage CE, la déclaration UE de conformité et les coordonnées de l’organisme notifié. La déclaration montre que le fabricant a évalué les risques de cybersécurité du produit et s’engage à le maintenir sûr grâce à des mises à jour. Si un fournisseur ne peut pas la fournir une fois le CRA applicable, cherchez un autre produit.

Produits critiques : le plus haut niveau d’assurance

L’annexe IV énumère trois types de produits :

• les appareils matériels avec boîtiers de sécurité
• les passerelles de compteurs intelligents et autres appareils destinés à des usages de sécurité avancés, y compris le traitement cryptographique sécurisé, comme les modules matériels de sécurité (HSM)
• les cartes à puce et dispositifs similaires, y compris les éléments sécurisés

La Commission peut imposer un certificat européen de cybersécurité pour ces produits par acte délégué, par exemple dans le cadre de l’EUCC, le schéma fondé sur les Critères communs. À défaut, les produits critiques suivent la procédure de la classe II.

N’achetez des produits critiques que si le fournisseur peut présenter une certification valide. Vérifiez que le certificat est à jour, que le produit reçoit des mises à jour de sécurité pendant toute sa période d’assistance, et que le fournisseur a un plan pour corriger rapidement les problèmes. Ces appareils protègent vos données et fonctions métier les plus sensibles.

Choisir des produits conformes au CRA

Liste de contrôle fournisseurs pour les PME

Utilisez cette liste lors de vos échanges avec les fournisseurs. La conformité au CRA, des mises à jour régulières et la gestion des vulnérabilités ne sont pas négociables. Le reste renforce votre position.

1. Conformité au CRA

• Le fournisseur fournit une déclaration UE de conformité et le produit porte le marquage CE.
• La catégorie du produit est claire : par défaut, classe I, classe II ou critique.
• Lorsqu'un certificat est exigé, il est à jour et couvre la version que vous achetez.

2. Mises à jour de sécurité

• Les mises à jour de sécurité sont régulières et gratuites.
• La période d'assistance est indiquée. Pour la plupart des produits, le CRA exige au moins cinq ans.
• Les mises à jour peuvent s'installer automatiquement et sont signées numériquement.

3. Gestion des vulnérabilités

• Le fournisseur dispose d'un processus formel pour signaler et corriger les vulnérabilités.
• Une politique de divulgation coordonnée des vulnérabilités et un contact sécurité sont publiés.
• Les vulnérabilités sont communiquées et corrigées rapidement.
• Bonus : le fournisseur a un programme de bug bounty.

4. Protection des données et vie privée

• On sait clairement où sont stockées vos données professionnelles.
• Le produit vous aide à respecter vos obligations au titre du RGPD.
• Les données sont chiffrées au repos et en transit.

5. Fonctions de sécurité intégrées

• Paramètres par défaut sûrs : aucun mot de passe par défaut, authentification multifacteur disponible, chiffrement activé.
• Un contrôle d'accès fondé sur les rôles est disponible.
• Des journaux et des pistes d'audit existent.

6. Responsabilité et documentation

• Le fournisseur fournit des consignes de sécurité et des instructions d'utilisation.
• La politique de fin de vie est claire.
• Le fournisseur assume la responsabilité de la sécurité, pas seulement des fonctionnalités.

7. Interopérabilité et portabilité

• Le produit prend en charge des standards ouverts.
• Vous pouvez exporter vos données si vous changez de fournisseur.
• Le produit fonctionne avec vos systèmes informatiques existants.

8. Assurance indépendante (facultatif mais recommandé)

• Le fournisseur détient des certifications tierces comme ISO/IEC 27001, SOC 2 ou, pour les produits industriels, IEC 62443.
• Le fournisseur partage des rapports de tests d'intrusion ou d'audits de sécurité.
• Les résultats des tests de sécurité sont publiés ou vérifiables.

Aller plus loin : vérifier les pratiques de sécurité dès la conception

Si vous voulez plus que la conformité de base au CRA, demandez davantage de preuves que le produit a été conçu de manière sécurisée :

• Demandez la politique de cycle de développement logiciel sécurisé (SSDLC) du fournisseur. Elle doit décrire les activités de sécurité en détail. Pour chaque activité, demandez la preuve qu’elle a été réalisée au cours de l’année écoulée.
• Demandez comment les menaces sont identifiées et atténuées pendant la conception. La modélisation des menaces doit faire partie de la politique SSDLC.
• Demandez la nomenclature logicielle (SBOM) et chargez-la dans un outil gratuit comme OWASP Dependency-Track pour voir les vulnérabilités connues des composants listés. Les fabricants doivent établir une SBOM mais pas la publier, certains ne la partageront donc que sous NDA.
• Demandez le plan de réponse aux incidents, y compris la façon dont le fournisseur respecte l’alerte précoce sous 24 heures que le CRA exige pour les vulnérabilités activement exploitées et les incidents graves.
• Demandez si le produit présente des vulnérabilités critiques connues et comment elles sont traitées. Le CRA exige que les produits soient livrés sans vulnérabilité exploitable connue.

Ces vérifications vous disent si la sécurité faisait partie du produit dès le départ ou si elle a été ajoutée après coup.

Signaux d’alerte

Considérez un produit comme à haut risque, et examinez des alternatives, si vous constatez l’un de ces signaux :

Aucune preuve de conformité au CRA

• Le fournisseur ne peut pas fournir de déclaration UE de conformité ni de marquage CE une fois le CRA applicable.
• La certification est obsolète, incomplète ou floue.

Aucune transparence

• Il n’existe aucune documentation sur la gestion des vulnérabilités.
• Aucun contact sécurité n’est publié, comme une adresse security@, un PSIRT ou une politique de divulgation.
• Il n’y a aucune déclaration claire sur la conformité au CRA.

Logiciels et matériels obsolètes ou non maintenus

• Les appareils sont livrés avec un système d’exploitation en fin de vie ou des bibliothèques non corrigées.
• Il n’y a aucun engagement de mises à jour de sécurité pendant la période d’assistance du produit.
• Les notes de version sont absentes ou vagues.

Un mauvais processus de mise à jour

• Les mises à jour doivent être appliquées à la main, sont téléchargées depuis un site quelconque ou ne sont pas signées numériquement.
• Il n’existe aucun mécanisme de mise à jour automatique ou sécurisé.
• Le fournisseur refuse de dire combien de temps les mises à jour seront fournies.

Paramètres par défaut faibles ou dangereux

• Le produit est livré avec des mots de passe par défaut impossibles à modifier.
• L’authentification multifacteur n’est pas prise en charge.
• Le produit utilise des protocoles obsolètes comme SSL ou TLS 1.0.

Aucune pratique de développement sécurisé

• Il n’y a aucune preuve de sécurité dès la conception ou de programmation sécurisée.
• Le fournisseur ne sait pas expliquer comment il teste les vulnérabilités.
• Les tests d’intrusion, revues de code ou la modélisation des menaces ne sont jamais mentionnés.

Aucune assurance indépendante

• Il n’y a ni ISO/IEC 27001 ni, pour les produits industriels, IEC 62443, et aucune évaluation de sécurité par un tiers, pas même volontaire.
• Le fournisseur écarte les questions de conformité comme “inutiles” ou “trop chères”.

Comportement commercial risqué

• Il n’existe aucun processus clair de gestion des incidents ou des violations de données.
• Le fournisseur a déjà ignoré des signalements de vulnérabilités ou retardé des correctifs.

Obligations des PME qui fabriquent des produits connectés

Comme l’explique l’introduction, le CRA s’applique à tout fabricant qui vend des produits comportant des éléments numériques dans l’UE, pas seulement aux éditeurs de logiciels. Les PME qui construisent du matériel, intègrent du logiciel dans des appareils ou vendent leurs propres logiciels ont les mêmes obligations que les grands fabricants. Et cela va bien au-delà des achats : la conception, le développement, la fabrication et la maintenance après vente sont concernés.

La suite de ce guide entre davantage dans le détail technique pour les équipes de développement produit.

Obligations de sécurité essentielles

L’objectif du CRA est que chaque produit comportant des éléments numériques sur le marché de l’UE soit conçu de manière sécurisée et maintenu après la vente pendant une période raisonnable. Les fabricants doivent pouvoir prouver leurs activités de sécurité, de la gouvernance et la conception jusqu’à la fin de vie.

Le CRA attend des pratiques de sécurité éprouvées tout au long du cycle de développement. Voici un exemple de cycle de développement logiciel sécurisé (SSDLC) avec les activités de sécurité correspondantes :

Sécurité dès la conception

La sécurité doit faire partie du produit dès la première conception, et non être ajoutée plus tard. Les fabricants appliquent les principes de sécurité dès la conception et par défaut tout au long du cycle de développement. Cela comprend :

• réaliser une évaluation des risques de cybersécurité et définir les exigences de sécurité lors de la planification et de l’architecture, par exemple au moyen de la modélisation des menaces
• appliquer des pratiques de programmation sécurisée et des tests automatisés
• livrer avec des configurations par défaut sûres qui réduisent l’exposition

Vous documentez ces pratiques dans la documentation technique de votre évaluation de la conformité.

Gestion des vulnérabilités

La sécurité après la release compte autant que le développement sécurisé. Les fabricants ont besoin d’un processus de gestion des vulnérabilités qui comprend :

• identifier les composants du produit et les surveiller pour détecter les vulnérabilités connues, dans votre propre code comme dans les composants tiers
• publier des avis de sécurité et corriger les vulnérabilités sans tarder
• diffuser gratuitement les mises à jour de sécurité, séparément des mises à jour fonctionnelles lorsque c’est possible

La période d’assistance doit refléter la durée d’utilisation prévue du produit et être d’au moins cinq ans, sauf si le produit doit être utilisé moins longtemps. Chaque mise à jour de sécurité doit rester disponible au moins dix ans, ou pour le reste de la période d’assistance si celle-ci est plus longue.

Transparence

Les fabricants doivent fournir :

• une SBOM dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. Elle fait partie de la documentation technique, vous n’êtes donc pas obligé de la publier.
• une documentation technique décrivant les fonctions de sécurité du produit et la manière dont la conformité a été évaluée
• une déclaration UE de conformité
• des informations pour l’utilisateur, notamment la date de fin de la période d’assistance et un point de contact unique pour les signalements de vulnérabilités

Les produits portent le marquage CE selon les règles CE habituelles : sur le produit si possible, sinon sur l’emballage et dans la documentation. Pour un logiciel, le marquage CE figure dans la déclaration UE de conformité ou sur le site web qui accompagne le logiciel.

La transparence s’étend à la chaîne d’approvisionnement : vous devez faire preuve de diligence pour que les composants tiers, open source compris, ne compromettent pas la sécurité du produit.

Signalement des incidents

Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement de l’ENISA. Le signalement est adressé au CSIRT national désigné comme coordinateur et à l’ENISA :

• une alerte précoce dans les 24 heures suivant la prise de connaissance
• une notification plus détaillée dans les 72 heures
• un rapport final dans les 14 jours suivant la disponibilité d’un correctif pour une vulnérabilité, ou dans un délai d’un mois pour un incident grave

Vous devez aussi informer les utilisateurs concernés et leur indiquer comment atténuer le problème. Ces obligations s’appliquent à tous les produits comportant des éléments numériques, y compris les produits purement logiciels, et aussi aux produits déjà sur le marché avant décembre 2027.

Le CRA fait passer la cybersécurité du réactif au proactif. La sécurité dès la conception, une gestion structurée des vulnérabilités, la transparence et un signalement rapide deviennent la norme pour vendre des produits numériques dans l’UE.

Une feuille de route pratique pour la conformité

Des correctifs de sécurité isolés ne vous mèneront pas à la conformité au CRA. Il vous faut une approche structurée et mesurable du développement logiciel sécurisé. Les modèles de maturité SSDLC sont l’un des moyens les plus efficaces d’y parvenir, par exemple :

• OWASP SAMM (Software Assurance Maturity Model)
• BSIMM (Building Security In Maturity Model)

Ces cadres vous aident à :

• évaluer votre niveau actuel de sécurité logicielle
• fixer des objectifs d’amélioration réalistes
• aligner vos pratiques de développement sur les obligations essentielles du CRA : sécurité dès la conception, gestion des vulnérabilités, transparence et signalement des incidents

Avec un modèle de maturité dans votre feuille de route, ces principes font partie de la façon de travailler de vos équipes d’ingénierie, au lieu d’être une série de cases réglementaires à cocher.

OWASP SAMM : un cadre structuré pour le développement sécurisé

Le schéma ci-dessous présente les pratiques de sécurité définies par OWASP SAMM.

Le modèle OWASP SAMM. Source : owaspsamm.org, CC BY-SA 4.0.

La structure modulaire de SAMM permet :

• une évaluation initiale de la maturité actuelle de votre organisation en matière de sécurité
• des niveaux de maturité cibles fondés sur le risque, les objectifs métier et les exigences du CRA
• une feuille de route sur mesure pour combler les écarts constatés
• des recommandations concrètes pour les activités de gouvernance, conception, implémentation, vérification et exploitation

Cette souplesse rend SAMM bien adapté à la préparation au CRA : vous pouvez prioriser les améliorations selon la classe de produit, l’exposition au marché et les capacités dont vous disposez déjà.

Étape 1 : Confronter votre portefeuille de produits au champ du CRA

Commencez par identifier lesquels de vos produits sont des produits comportant des éléments numériques au sens du CRA.

• Incluez les produits purement logiciels aussi bien que le matériel avec logiciel embarqué.
• Rattachez chaque produit à une catégorie : par défaut, classe I, classe II ou critique.
• Déterminez quels produits nécessitent un organisme notifié et pour lesquels le contrôle interne (module A) suffit.

Cela définit votre périmètre de conformité et montre où concentrer vos efforts en premier, selon le risque et l’exposition réglementaire.

Étape 2 : Repérer les écarts dans les processus de développement et d’après-vente

Utilisez SAMM pour évaluer votre niveau actuel de sécurité logicielle dans ses cinq fonctions métier : Governance, Design, Implementation, Verification et Operations.

• Réalisez une évaluation initiale de maturité avec le système de notation de SAMM.
• Identifiez les pratiques absentes ou faibles, comme l’absence de modélisation des menaces, des correctifs lents ou des rôles flous en réponse aux incidents.
• Portez une attention particulière aux obligations après la vente, comme la surveillance des vulnérabilités et les périodes d’assistance, souvent négligées.

Le site d’OWASP SAMM propose des conseils pour démarrer, ainsi que des outils gratuits pour évaluer, visualiser et communiquer votre maturité en sécurité logicielle. Ils facilitent le repérage des écarts, la planification des améliorations et le suivi des progrès. Le graphique ci-dessous montre un exemple d’évaluation, avec les points forts actuels et la progression prévue sur quatre trimestres.

Étape 3 : Mettre en place des pratiques de développement sécurisé

Sur la base de votre analyse des écarts, fixez un niveau de maturité cible pour chaque fonction métier et commencez par les améliorations les plus prioritaires.

• Commencez par les domaines directement liés aux obligations du CRA, comme les standards de programmation sécurisée, la génération de SBOM et les mécanismes de mise à jour sécurisés.
• Appuyez-vous sur les recommandations de SAMM pour intégrer la sécurité au travail de développement quotidien.
• Adaptez la profondeur des mesures et de la documentation à la classe du produit. Les produits critiques demandent davantage des deux.

Étape 4 : Préparer la divulgation des vulnérabilités et la gestion des correctifs

Le CRA exige un processus de gestion des vulnérabilités et des mises à jour dans des délais raisonnables.

• Publiez une politique de divulgation coordonnée des vulnérabilités (CVD).
• Définissez des circuits internes de tri, de correction et de communication, y compris le délai de signalement de 24 heures.
• Assurez-vous que la livraison de vos correctifs est sécurisée, fiable et documentée.

La fonction métier Operations de SAMM décrit en détail les pratiques de gestion des incidents et des correctifs.

Étape 5 : Former vos équipes aux obligations continues

La conformité n’est pas un événement ponctuel. Elle exige une vigilance continue et des responsabilités claires.

• Formez les équipes d’ingénierie, produit et support aux obligations du CRA et aux pratiques de développement sécurisé.
• Intégrez des sujets CRA comme le marquage CE, les délais de signalement et la documentation dans l’intégration des nouveaux arrivants et la formation continue.
• Utilisez la fonction métier Governance de SAMM pour formaliser les rôles, les responsabilités et les indicateurs.

Notre EU CRA Practitioner Training couvre ces obligations pour les équipes d’ingénierie, produit et conformité. Si vous préférez ne pas faire ce chemin seul, l’EU CRA Compliance Journey parcourt ces étapes avec vous, de la classification des produits à la déclaration UE de conformité.

Logiciels open source

Le CRA ne réglemente pas le développement open source en tant que tel. Ses obligations s’appliquent lorsqu’un logiciel est mis à disposition sur le marché dans le cadre d’une activité commerciale. Les bénévoles et communautés qui partagent du code sans intention commerciale ne sont pas directement concernés.

Open source non commercial

Les logiciels open source développés et partagés sans intention commerciale, comme les projets personnels, les outils de recherche ou les bibliothèques communautaires sur GitHub, sont hors du champ du CRA. Les contributeurs n’ont besoin ni d’évaluation de la conformité ni de documentation.

Usage commercial de l’open source

Une entreprise qui intègre de l’open source dans un produit qu’elle vend dans l’UE est responsable de la conformité au CRA du produit entier, parties open source comprises. Elle doit faire preuve de diligence envers ces composants, gérer leurs vulnérabilités et les documenter. La responsabilité incombe à l’entreprise qui met le produit sur le marché, pas au contributeur individuel. Si vous trouvez et corrigez une vulnérabilité dans un composant open source, vous devez aussi la signaler et partager le correctif avec les mainteneurs du projet.

Intendants de logiciels open source

Le CRA crée la figure de l’intendant de logiciels open source (open-source software steward) : une personne morale, autre qu’un fabricant, qui soutient systématiquement le développement de logiciels open source destinés à un usage commercial et en assure la viabilité. Des fondations comme l’Eclipse Foundation et la Linux Foundation en sont des exemples typiques, tout comme les entreprises qui hébergent et maintiennent des projets open source.

Les intendants relèvent d’un régime léger. Ils doivent :

• mettre en place et documenter une politique de cybersécurité qui couvre la gestion des vulnérabilités
• coopérer avec les autorités de surveillance du marché
• signaler les vulnérabilités activement exploitées et les incidents graves, dans la mesure où ils participent au développement

Les intendants ne réalisent pas d’évaluation de la conformité et n’apposent pas le marquage CE. Cela change lorsqu’une organisation met elle-même le logiciel à disposition dans le cadre d’une activité commerciale, par exemple en le faisant payer. Elle devient alors fabricant, avec l’ensemble des obligations.

Tous les projets open source n’ont pas d’intendant. Le CRA n’impose aucune obligation aux contributeurs individuels, mais il rend les entreprises pleinement responsables de l’open source qu’elles livrent. La qualité, la transparence et la maintenance des composants open source pèseront donc davantage dans les choix des entreprises.

Erreurs fréquentes et comment les éviter

Le CRA fixe des attentes claires en matière de développement sécurisé et de gestion du cycle de vie, mais de nombreuses organisations trébuchent lors de la mise en œuvre. La plupart des faux pas viennent du fait de traiter le CRA comme une liste de contrôle plutôt que comme un changement dans la façon de construire, maintenir et piloter le logiciel. Voici trois erreurs fréquentes, et comment OWASP SAMM vous aide à les éviter.

1. Traiter le CRA comme un projet ponctuel

Beaucoup d’équipes abordent le CRA comme un sprint de conformité avant une échéance, sans construire de pratiques de sécurité durables. Cela mène à des correctifs superficiels qui se dégradent avec le temps et laissent les produits vulnérables après la release.

SAMM intègre l’amélioration continue. Ses scores de maturité vous aident à suivre les progrès dans le temps, à fixer des objectifs qui évoluent avec vos produits et à réévaluer vos pratiques à mesure que les produits et les menaces changent. Avec SAMM dans votre SSDLC, la conformité au CRA devient un processus continu.

2. Tout laisser à l’ingénierie

La sécurité repose souvent sur la seule ingénierie, sans le juridique, les achats ou la gestion de produit. Cela crée des angles morts en matière de responsabilité, de risque fournisseur et d’obligations de marché.

La fonction métier Governance de SAMM fait de la sécurité un effort transversal. Elle vous aide à définir les rôles et responsabilités entre services, à aligner les équipes juridiques, achats et produit sur les objectifs de sécurité, et à donner à chaque obligation du CRA, comme le marquage CE, le signalement des incidents et l’assurance fournisseurs, un responsable clairement identifié. La sécurité est l’affaire de toute l’entreprise, et l’ingénierie n’en est qu’une partie.

3. Sous-estimer la documentation

Les équipes se concentrent souvent sur les mesures techniques et négligent la documentation exigée par le CRA, notamment l’évaluation des risques, les SBOM, les procédures de gestion des vulnérabilités et la déclaration de conformité.

SAMM rattache la documentation à chaque fonction métier :

• Design et Implementation consignent les décisions d’architecture et les pratiques de programmation sécurisée.
• Verification enregistre les résultats de tests et les preuves pour l’évaluation de la conformité.
• Operations tient les journaux de correctifs, les rapports d’incident et les périodes d’assistance.

La documentation grandit alors avec le travail, au lieu d’être rédigée dans l’urgence avant une évaluation.

Perspectives

Le CRA s’inscrit dans un ensemble plus large de règles européennes. NIS2 couvre la cybersécurité des entités essentielles et importantes, et l’AI Act encadre une intelligence artificielle digne de confiance. Ces textes sont liés : un système d’IA à haut risque qui respecte les exigences essentielles du CRA est réputé respecter l’exigence de cybersécurité de l’AI Act.

Pour les entreprises, cette convergence est une opportunité. Celles qui adoptent tôt les pratiques du CRA, avec une sécurité intégrée, de la transparence et une gestion du cycle de vie, peuvent se positionner comme fournisseurs de confiance pendant que leurs concurrents se pressent pour rattraper leur retard avant décembre 2027.

À retenir

Le CRA conditionne votre accès au marché de l’UE

• À partir du 11 décembre 2027, la conformité au CRA est une condition pour mettre des produits sur le marché de l’UE.
• Les produits non conformes s’exposent à un retrait, à des rappels et à des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial.
• Les obligations de signalement s’appliquent déjà.
• Se préparer tôt vous laisse le temps de construire des pratiques de sécurité dès la conception plutôt que de précipiter des correctifs à la dernière minute.

Adoptez une approche structurée et un modèle de maturité comme SAMM

• Des efforts de sécurité ponctuels ne passeront pas une évaluation de la conformité. Le CRA exige des pratiques systématiques et démontrables.
• OWASP SAMM vous aide à évaluer votre situation actuelle, à fixer des objectifs d’amélioration et à bâtir une feuille de route alignée sur les obligations du CRA.
• Un modèle de maturité répartit la sécurité entre les équipes et sur tout le cycle de vie, au lieu de la laisser à une seule équipe ou de réagir aux incidents.

Repensez le choix de vos composants et fournisseurs

• Vous êtes responsable de chaque composant de votre produit, y compris l’open source et les logiciels tiers.
• Évaluez fournisseurs et bibliothèques selon leur niveau de sécurité, leur activité de maintenance et leur alignement sur le CRA.
• Attendez-vous à davantage de questions sur les SBOM, les licences et la divulgation des vulnérabilités, de la part de vos clients comme envers vos fournisseurs.

Vous voulez savoir où vous en êtes ? Faites l’Autoévaluation EU CRA gratuite ou réservez un entretien stratégique EU CRA gratuit.

Glossaire

Ressources utiles

• Texte juridique du CRA sur EUR-Lex : la publication officielle du règlement.
• Politiques de cybersécurité de l’UE : la vue d’ensemble de la Commission européenne, y compris le CRA et NIS2.
• FAQ CRA du hub CRA de l’ORC WG : une FAQ maintenue par la communauté sur les questions fréquentes relatives au CRA.
• Présentation du CRA par l’ORC WG : des ressources de l’Open Regulatory Compliance Working Group.
• OWASP SAMM : le modèle, les outils et les recommandations.