CRA : qui est concerne par le Cyber Resilience Act ?
Le Cyber Resilience Act concerne les fabricants, importateurs et distributeurs de produits numeriques. Votre organisation est-elle dans le champ du CRA ?
Le Cyber Resilience Act (reglement (UE) 2024/2847) est entre en vigueur le 10 decembre 2024. Ce texte impose des exigences de cybersecurite a l’ensemble de la chaine de valeur des produits comportant des elements numeriques. La question centrale pour toute organisation operant sur le marche europeen est donc simple : etes-vous concerne ?
La reponse est rarement triviale. Le champ d’application du CRA est volontairement large, et les mecanismes d’exemption sont precis. Cet article decortique methodiquement qui est vise, ce qui est couvert, et ce qui ne l’est pas.
Les trois categories d’operateurs economiques
Le CRA ne se limite pas aux seuls fabricants. Il structure ses obligations autour de trois categories d’operateurs economiques, chacune soumise a des obligations distinctes mais complementaires.
1. Les fabricants (manufacturers)
Le fabricant est l’acteur central du dispositif. Il s’agit de toute personne physique ou morale qui developpe ou fait developper un produit comportant des elements numeriques et le commercialise sous son propre nom ou sa propre marque (article 3, point 13).
Concretement, si votre entreprise conçoit un objet connecte, developpe un firmware, ou edite un logiciel distribue sur le marche europeen – meme a titre gratuit dans certains cas – vous etes fabricant au sens du CRA.
Les obligations du fabricant sont les plus lourdes : evaluation de conformite, gestion des vulnerabilites pendant toute la duree de vie du produit (et au minimum 5 ans), documentation technique, declaration de conformite et marquage CE.
Exemple pratique : une entreprise française qui developpe des capteurs IoT industriels et les vend sous sa marque est fabricant. Mais une ESN qui developpe un firmware pour le compte d’un donneur d’ordre qui le commercialise sous sa propre marque n’est pas fabricant – c’est le donneur d’ordre qui l’est.
2. Les importateurs
L’importateur est toute personne physique ou morale etablie dans l’Union qui met sur le marche un produit comportant des elements numeriques provenant d’un fabricant etabli hors de l’UE (article 3, point 16).
L’importateur doit verifier que le fabricant a bien realise l’evaluation de conformite, que la documentation technique est disponible, et que le marquage CE a ete appose. Il engage sa propre responsabilite.
Exemple pratique : un distributeur français qui importe des cameras IP d’un fabricant chinois pour les revendre en France est importateur au sens du CRA. Il doit s’assurer que le fabricant a respecte l’ensemble des exigences avant la mise sur le marche.
3. Les distributeurs
Le distributeur est toute personne physique ou morale dans la chaine d’approvisionnement, autre que le fabricant ou l’importateur, qui met un produit a disposition sur le marche (article 3, point 17).
Ses obligations sont plus legeres mais reelles : il doit verifier que le produit porte le marquage CE, que le fabricant et l’importateur ont respecte leurs obligations d’identification, et que les informations d’utilisation sont fournies. Le distributeur doit aussi cooperer avec les autorites de surveillance du marche. Lorsque les produits distribues traitent des donnees personnelles, les exigences de securite des donnees au titre du RGPD s’appliquent egalement.
Exemple pratique : un revendeur informatique qui distribue des routeurs Wi-Fi deja importes en France est distributeur. S’il constate qu’un produit ne respecte pas les exigences, il ne doit pas le mettre a disposition sur le marche.
Qu’est-ce qu’un “produit comportant des elements numeriques” ?
La notion est definie a l’article 3, point 1, du CRA. Il s’agit de tout produit logiciel ou materiel, ainsi que de ses solutions de traitement de donnees a distance, y compris les composants logiciels ou materiels mis sur le marche separement.
Cela couvre un spectre extremement large :
- Produits materiels avec logiciel embarque : routeurs, cameras IP, capteurs IoT, automates industriels, terminaux de paiement, systemes domotiques.
- Logiciels autonomes : systemes d’exploitation, navigateurs, gestionnaires de mots de passe, clients VPN, applications de bureau.
- Composants : bibliotheques logicielles, microcontroleurs, modules de communication vendus separement.
Le critere determinant est la presence d’une connexion logique ou physique a un reseau ou a un dispositif. Un logiciel qui ne se connecte a rien et ne traite aucune donnee provenant de l’exterieur peut echapper au champ d’application, mais ces cas sont aujourd’hui marginaux.
Ce qui est exclu du champ
Le CRA exclut explicitement certaines categories :
- Les services cloud purs (SaaS) ne sont pas directement couverts en tant que “produits”, sauf si le composant logiciel distant fait partie integrante d’un produit comportant des elements numeriques. En pratique, si votre SaaS est indissociable du fonctionnement d’un objet connecte, il entre dans le champ.
- Les logiciels developpes exclusivement pour un usage interne a l’organisation, sans mise sur le marche.
- Les produits deja couverts par des reglementations sectorielles specifiques (voir ci-dessous).
Classification des produits : criticite et categories
Le CRA distingue trois niveaux de risque, avec des consequences directes sur les procedures d’evaluation de conformite.
| Categorie | Description | Exemples | Evaluation de conformite |
|---|---|---|---|
| Produits par defaut (non critiques) | La grande majorite des produits numeriques | Logiciels de traitement de texte, jeux video, enceintes connectees, disques durs | Auto-evaluation par le fabricant (module A) |
| Produits importants – Classe I | Produits presentant un risque de cybersecurite significatif | Gestionnaires de mots de passe, interfaces reseau, microcontroleurs, systemes domotiques, routeurs domestiques, OS non couverts par la Classe II | Application d’une norme harmonisee (auto-evaluation possible) ou evaluation par un tiers |
| Produits importants – Classe II | Produits a risque eleve de cybersecurite | Pare-feux industriels, systemes de detection d’intrusion, routeurs industriels, modules cryptographiques, OS pour serveurs/desktops, hyperviseurs, PKI, microprocesseurs securises | Evaluation de conformite par un tiers obligatoire (organisme notifie) |
| Produits critiques | Produits dont la compromission aurait des consequences systemiques | Dispositifs physiques de type smartcard, secure element, HSM, passerelles intelligentes de compteurs (smart meter gateways) | Certification europeenne de cybersecurite (schema EUCC ou equivalent) |
Classe I vs Classe II : la distinction cle
La difference entre Classe I et Classe II ne porte pas uniquement sur le type de produit, mais sur le niveau de risque lie a son exploitation. Un routeur Wi-Fi domestique est Classe I ; un routeur industriel utilise dans une infrastructure critique est Classe II. Un systeme d’exploitation embarque dans un objet grand public est Classe I ; un OS serveur est Classe II.
La consequence pratique majeure : en Classe II, l’intervention d’un organisme notifie (tiers evaluateur) est obligatoire. Impossible de s’auto-certifier. Pour un CTO, cela signifie des delais et des couts supplementaires dans le processus de mise sur le marche.
En Classe I, le fabricant peut encore s’auto-evaluer a condition d’appliquer une norme harmonisee couvrant l’ensemble des exigences essentielles. A defaut, il devra lui aussi passer par un organisme notifie.
Les exemptions sectorielles
Le CRA a ete conçu pour eviter les doublons reglementaires, dans une logique similaire a l’articulation entre la directive NIS2 et le CRA. Plusieurs categories de produits sont exclues de son champ d’application lorsqu’elles sont deja soumises a des exigences de cybersecurite dans le cadre de reglementations sectorielles :
-
Dispositifs medicaux : les produits couverts par les reglements (UE) 2017/745 (dispositifs medicaux) et (UE) 2017/746 (dispositifs medicaux de diagnostic in vitro) sont exclus. Si vous developpez un logiciel qualifie de dispositif medical, c’est le cadre MDR/IVDR qui s’applique.
-
Vehicules a moteur : les produits relevant du reglement (UE) 2019/2144 relatif a la securite generale des vehicules sont exclus. Le reglement UNECE R155 sur la cybersecurite automobile continue de s’appliquer.
-
Aviation : les produits couverts par le reglement (UE) 2018/1139 (regles communes dans le domaine de l’aviation civile) sont exclus.
-
Equipements marins : les produits couverts par la directive 2014/90/UE sont exclus.
Attention : l’exemption ne vaut que si le produit est effectivement couvert par la legislation sectorielle. Un composant logiciel utilise dans un vehicule mais vendu aussi separement pour d’autres usages peut rester dans le champ du CRA pour ces autres usages.
Le cas particulier de l’open source
Le CRA a fait l’objet de debats intenses concernant les logiciels open source. Le texte final introduit une distinction importante :
-
Les logiciels open source developpes dans un cadre commercial (c’est-a-dire mis sur le marche dans le cadre d’une activite commerciale) sont soumis aux memes obligations que les logiciels proprietaires. Le simple fait qu’un logiciel soit open source ne l’exclut pas du CRA.
-
Les logiciels open source developpes hors activite commerciale sont exclus. Un developpeur benevole qui contribue a un projet open source sans remuneration et sans cadre commercial n’est pas considere comme fabricant.
-
Les intendants de logiciels open source (open source software stewards), c’est-a-dire les fondations et organisations qui soutiennent le developpement de logiciels open source sans les commercialiser directement, sont soumis a un regime allege. Ils doivent mettre en place une politique de cybersecurite, cooperer avec les autorites et signaler les vulnerabilites activement exploitees, mais ne sont pas soumis aux obligations de conformite completes.
Exemple pratique : une entreprise qui distribue une distribution Linux commerciale est fabricant. La fondation communautaire qui maintient le noyau Linux en amont est potentiellement intendant. Un developpeur individuel qui contribue au noyau sur son temps libre n’est pas concerne.
Pour un CISO, cela signifie que l’utilisation de composants open source dans vos produits n’exonere pas votre organisation de ses responsabilites en tant que fabricant. Vous devez evaluer et gerer les vulnerabilites de l’ensemble de vos composants, y compris ceux issus de l’open source.
Comment determiner si vous etes concerne
Voici une grille d’analyse rapide :
-
Vous developpez un produit logiciel ou materiel qui se connecte a un reseau ou a un autre dispositif ? Vous etes probablement fabricant au sens du CRA.
-
Vous importez des produits numeriques de fabricants hors UE pour les vendre sur le marche europeen ? Vous etes importateur.
-
Vous revendez ou distribuez des produits numeriques sans les modifier ? Vous etes distributeur.
-
Votre produit est un SaaS pur, sans composant logiciel local et sans lien avec un produit physique ? Vous etes probablement hors champ – mais verifiez attentivement les cas limites.
-
Votre produit est deja couvert par une reglementation sectorielle (medical, automobile, aviation) ? Verifiez si l’exemption couvre l’integralite de votre produit.
-
Vous contribuez a un projet open source sans activite commerciale ? Vous n’etes pas concerne en tant que fabricant – mais votre employeur peut l’etre s’il integre votre contribution dans un produit commercial.
Calendrier d’application
Les obligations du CRA s’appliquent de maniere progressive :
- 11 septembre 2026 : obligation de signalement des vulnerabilites activement exploitees et des incidents graves.
- 11 juin 2027 : regles relatives aux organismes notifies et a l’evaluation de conformite.
- 11 decembre 2027 : application de l’ensemble des obligations, y compris les exigences essentielles de cybersecurite et les obligations de gestion des vulnerabilites.
Conclusion
Le Cyber Resilience Act a un champ d’application deliberement large. Fabricants, importateurs et distributeurs de produits comportant des elements numeriques sont tous concernes a des degres divers. La classification en produits par defaut, Classe I et Classe II determine le niveau de contrainte pour l’evaluation de conformite – et donc les ressources a mobiliser.
Pour les organisations qui developpent ou distribuent des produits numeriques sur le marche europeen, l’analyse de conformite au CRA doit debuter sans attendre. Les delais de mise en conformite sont significatifs, en particulier pour les produits de Classe II necessitant l’intervention d’un organisme notifie.
Pour une vue d’ensemble du reglement, consultez notre guide complet sur le Cyber Resilience Act.
Restez informe sur la conformite
Recevez nos analyses et guides pratiques sur le RGPD, NIS2, AI Act et plus. Rejoint par 52 000+ professionnels.