7 min. de lecture<\/p>\n
Le R\u00e8glement EU Cyber Resilience Act (CRA) est en vigueur depuis d\u00e9cembre 2024 et touche tous les fabricants qui introduisent des produits avec des \u00e9l\u00e9ments num\u00e9riques sur le march\u00e9 europ\u00e9en. \u00c0 partir de septembre 2026, les premi\u00e8res obligations de d\u00e9claration s’appliquent, et \u00e0 partir de d\u00e9cembre 2027, tous les produits doivent satisfaire aux nouvelles exigences de cybers\u00e9curit\u00e9. Pour les entreprises de taille interm\u00e9diaire, cela signifie que tout capteur connect\u00e9, tout contr\u00f4leur de machine et chaque composant logiciel sont soumis \u00e0 la r\u00e9glementation. Le temps d’action est limit\u00e9.<\/strong><\/p>\n Le R\u00e8glement Cyber Resilience est la premi\u00e8re r\u00e9glementation de l’UE \u00e0 introduire des exigences de cybers\u00e9curit\u00e9 contraignantes pour tous les produits avec des \u00e9l\u00e9ments num\u00e9riques. Le champ d’application est consciencieusement large : il englobe des composants mat\u00e9riels connect\u00e9s tels que les routeurs, les appareils Smart Home et les capteurs IoT industriels, ainsi que du logiciel pur, y compris les applications, les syst\u00e8mes d’exploitation et les pare-feux.<\/p>\n Pour les entreprises de taille interm\u00e9diaire, les cons\u00e9quences sont profondes. Tout contr\u00f4leur de machine avec connexion r\u00e9seau, tout capteur avec fonctionnalit\u00e9 de mise \u00e0 jour de firmware et chaque syst\u00e8me embarqu\u00e9 dans une installation de production sont soumis \u00e0 la r\u00e9glementation. <\/p>\n Particuli\u00e8rement pertinent pour les entreprises de taille interm\u00e9diaire : Les importateurs et distributeurs qui mettent en circulation des produits dans l’UE ont \u00e9galement des responsabilit\u00e9s. Celui qui importe un module IoT chinois et le vend sous son propre label est consid\u00e9r\u00e9 comme un fabricant et doit prouver la conformit\u00e9 compl\u00e8te au CRA. Cela touche de nombreux fabricants d’outillage et des int\u00e9grateurs de syst\u00e8mes qui int\u00e8grent des composants d’\u00c9tats tiers dans leurs solutions.<\/p>\n Les exceptions sont limit\u00e9es : les produits m\u00e9dicaux (r\u00e9gul\u00e9s par la MDR), les v\u00e9hicules automobiles (r\u00e9glementation UNECE), la technologie a\u00e9ronautique et certaines produits de s\u00e9curit\u00e9 nationaux. Le logiciel open-source n’est concern\u00e9 que si il est commercialis\u00e9.<\/p>\n \n\u00ab\u00a0Le CRA garantit que les produits mat\u00e9riels et logiciels avec moins de vuln\u00e9rabilit\u00e9s arrivent sur le march\u00e9 et que les fabricants prennent la s\u00e9curit\u00e9 au cours de tout le cycle de vie d’un produit au s\u00e9rieux.\u00a0\u00bb Le CRA est entr\u00e9 en vigueur le 10 d\u00e9cembre 2024 et sera applicable en trois \u00e9tapes. La premi\u00e8re date limite arrive plus rapidement que ce que de nombreux entreprises attendent.<\/p>\n 11 juin 2026:<\/strong> La notification des centres d’\u00e9valuation de conformit\u00e9 sera effective. \u00c0 partir de cette date, les autorit\u00e9s nationales doivent avoir nomm\u00e9 les centres d’\u00e9valuation autoris\u00e9s pour \u00e9valuer les produits \u00e0 haut risque (cat\u00e9gories I et II).<\/p>\n 11 septembre 2026:<\/strong> La responsabilit\u00e9 de signaler les faiblesses et les incidents de s\u00e9curit\u00e9 commencera. Les fabricants doivent signaler les faiblesses activement utilis\u00e9es dans les 24 heures \u00e0 l’ENISA. Pour les incidents de s\u00e9curit\u00e9 graves, la p\u00e9riode de signalement est de 72 heures. Cette obligation prend effet six mois avant l’application compl\u00e8te et est pour de nombreux entreprises la premi\u00e8re date limite s\u00e9rieuse.<\/p>\n 11 d\u00e9cembre 2027:<\/strong> Application compl\u00e8te de toutes les exigences. \u00c0 partir de cette date, seuls les produits CRA-conformes avec la marque CE pourront \u00eatre commercialis\u00e9s sur le march\u00e9 EU. Les produits qui \u00e9taient already sur le march\u00e9 avant cette date et n’ont pas \u00e9t\u00e9 significativement modifi\u00e9s b\u00e9n\u00e9ficient d’un protection temporaire.<\/p>\n Le CRA divise les produits en trois classes de risque qui d\u00e9terminent la fa\u00e7on dont l’\u00e9valuation de la conformit\u00e9 doit \u00eatre effectu\u00e9e. L’attribution de ces classes a des implications directes sur les co\u00fbts et les efforts n\u00e9cessaires.<\/p>\n Produits standard (environ 90 pour cent des produits):<\/strong> Il s’agit de capteurs IoT simples, appareils Smart Home sans fonctionnalit\u00e9s de s\u00e9curit\u00e9, logiciels de consommation et appareils de bureau. Les fabricants peuvent prouver la conformit\u00e9 par une auto-\u00e9valuation. Aucun examinateur externe n’est n\u00e9cessaire.<\/p>\n Produits importants (cat\u00e9gorie I):<\/strong> Syst\u00e8mes d’exploitation, pare-feux, routeurs, logiciels VPN, syst\u00e8mes de gestion r\u00e9seau. Une \u00e9valuation selon des normes harmonis\u00e9es ou une v\u00e9rification par un tiers est n\u00e9cessaire.<\/p>\n Produits critiques (cat\u00e9gorie II):<\/strong> Modules de s\u00e9curit\u00e9 mat\u00e9riels, passerelles Smart Meter, syst\u00e8mes de contr\u00f4le industriels<\/a> et infrastructure de cl\u00e9 publique. Une v\u00e9rification de conformit\u00e9 par un tiers effectu\u00e9e par une autorit\u00e9 nomm\u00e9e est obligatoire.<\/p>\n Les exigences CRA peuvent \u00eatre divis\u00e9es en trois domaines : d\u00e9veloppement s\u00e9curis\u00e9, gestion des faiblesses et documentation.<\/p>\n Security by Design :<\/strong> Les produits doivent \u00eatre con\u00e7us en fonction du principe \u00ab\u00a0Secure by Default\u00a0\u00bb. Cela signifie : faible surface d’attaque, communication chiffr\u00e9e, pas de mots de passe cod\u00e9s en dur et m\u00e9canismes de mise \u00e0 jour s\u00e9curis\u00e9s. Les fabricants doivent pouvoir d\u00e9montrer que la s\u00e9curit\u00e9 n’est pas ajout\u00e9e de mani\u00e8re post\u00e9rieure, mais est int\u00e9gr\u00e9e d\u00e8s le d\u00e9but du processus de conception.<\/p>\n Gestion des faiblesses :<\/strong> Les fabricants doivent fournir des mises \u00e0 jour de s\u00e9curit\u00e9 tout au long du cycle de vie du produit, au moins pendant les cinq ann\u00e9es suivant leur introduction sur le march\u00e9. Les faiblesses activement exploit\u00e9es doivent \u00eatre signal\u00e9es \u00e0 l’ENISA dans les 24 heures. Cela n\u00e9cessite un processus PSIRT (Product Security Incident Response Team) efficace.<\/p>\n Documentation technique :<\/strong> Pour chaque produit, une documentation compl\u00e8te est n\u00e9cessaire : analyse des risques, description de l’architecture de s\u00e9curit\u00e9, rapports de test, SBOM (Software Bill of Materials) et d\u00e9claration de conformit\u00e9 europ\u00e9enne. Un aspect souvent n\u00e9glig\u00e9 est la responsabilit\u00e9 de fournir des mises \u00e0 jour de s\u00e9curit\u00e9 gratuites pendant au moins cinq ans. Pour les fabricants de composants industriels avec des cycles de vie de dix \u00e0 vingt ans, cela repr\u00e9sente une obligation \u00e0 long terme importante. Qui livre un module de contr\u00f4le connect\u00e9 aujourd’hui, doit garantir qu’il puisse \u00eatre s\u00e9curis\u00e9 par des mises \u00e0 jour jusqu’en 2032. Cela n\u00e9cessite une architecture logicielle durable et une infrastructure de mise \u00e0 jour fonctionnelle qui d\u00e9passe le cycle de vie de l’article standard.<\/p>\n En pratique, cela signifie \u00e9galement que les fabricants doivent revoir leurs relations avec leurs fournisseurs. Si une biblioth\u00e8que open source utilis\u00e9e dans un produit n’est plus maintenue, le fabricant doit d\u00e9velopper des correctifs soi-m\u00eame ou remplacer la composante. L’SBOM devient un syst\u00e8me de pr\u00e9avis : il montre les d\u00e9pendances existantes et o\u00f9 les risques se cachent.<\/p>\n L’SBOM est particuli\u00e8rement pertinent car elle doit inclure toutes les composantes logicielle, y compris les biblioth\u00e8ques open source.<\/p>\n La Software Bill of Materials est l’un des nouveaux instruments centraux du CRA. En pratique, elle est comparable \u00e0 une liste des ingr\u00e9dients sur un aliment : elle \u00e9num\u00e8re chaque composante logicielle utilis\u00e9e dans un produit. Pour de nombreux petits et moyens entreprises, cela repr\u00e9sente un d\u00e9fi, car les d\u00e9pendances dans les piles de logiciels modernes sont complexes.<\/p>\n Un syst\u00e8me embarqu\u00e9 typique dans une commande de machine comprend un syst\u00e8me d’exploitation en temps r\u00e9el, des biblioth\u00e8ques de communication, des modules de cryptographie et des dizaines de composantes suppl\u00e9mentaires, souvent int\u00e9gr\u00e9es en tant qu’open source. Chaque composante de ces derni\u00e8res peut contenir des faiblesses dont le fabricant doit \u00eatre conscient et ma\u00eetriser.<\/p>\n La bonne nouvelle : des normes et des outils \u00e9tablis existent. CycloneDX et SPDX sont les deux formats SBOM les plus couramment utilis\u00e9s. Les outils de build tels que Syft ou Grype g\u00e9n\u00e8rent automatiquement des SBOM \u00e0 partir du d\u00e9p\u00f4t de code. Pour les entreprises qui utilisent already CI\/CD pipelines, l’int\u00e9gration de la cr\u00e9ation de SBOM dans le processus de build existant est possible sans perturber le workflow de d\u00e9veloppement.<\/p>\n Pour les entreprises qui ne d\u00e9veloppent pas leur propre logiciel, mais qui acqui\u00e8rent des composantes de fournisseurs, il est recommand\u00e9 de demander \u00e0 leurs fournisseurs une SBOM. Le CRA transf\u00e8re la responsabilit\u00e9 le long de la cha\u00eene de fournisseurs. Qui int\u00e8gre des composantes sans SBOM dans ses produits, assume la responsabilit\u00e9 des faiblesses inconnues.<\/p>\n Les co\u00fbts de conformit\u00e9 d\u00e9pendent fortement de la cat\u00e9gorie de produit et du niveau de maturit\u00e9 des processus de s\u00e9curit\u00e9 existants. Pour les produits standard avec auto-\u00e9valuation, les experts du secteur pr\u00e9voient des d\u00e9penses uniques de 20 000 \u00e0 50 000 euros par ligne de produits, principalement pour la documentation, l’analyse des risques et la cr\u00e9ation de la SBOM.<\/p>\n Pour les produits de cat\u00e9gorie I et II qui n\u00e9cessitent une v\u00e9rification externe, les co\u00fbts augmentent \u00e0 80 000 \u00e0 200 000 euros. En outre, des co\u00fbts de fonctionnement pour la gestion des faiblesses sont \u00e0 prendre en compte : un processus PSIRT (Product Security Incident Response Team) d\u00e9di\u00e9 avec suivi, d\u00e9veloppement de correctifs et notifications ENISA n\u00e9cessite au moins une demi-v\u00e9ritable, en pratique souvent plus.<\/p>\n Le rapport co\u00fbt-b\u00e9n\u00e9fice : les co\u00fbts moyens d’un incident de cybers\u00e9curit\u00e9 sont, selon le BSI, de 500 000 euros pour les entreprises de taille interm\u00e9diaire. Un seul incident majeur d\u00e9passe les co\u00fbts de conformit\u00e9 sur plusieurs ann\u00e9es. En outre, il y a un avantage de march\u00e9 : celui qui est CRA-conform peut commercialiser sans restrictions \u00e0 l’\u00e9chelle europ\u00e9enne, tandis que les concurrents non conformes sont exclus du march\u00e9.<\/p>\n Le CRA ne fonctionne pas isol\u00e9ment. Ensemble avec NIS2<\/a> (S\u00e9curit\u00e9 des r\u00e9seaux et des informations) et le AI Act<\/a>, il constitue une triade r\u00e9glementaire qui frappe les entreprises europ\u00e9ennes simultan\u00e9ment. Pour les entreprises de taille interm\u00e9diaire, cela signifie : rep\u00e9rer les chevauchements et utiliser les synergies.<\/p>\n NIS2 exige que les exploitants d’infrastructures critiques et importantes g\u00e8rent les risques et signalent les incidents. Le CRA exige que les fabricants des produits utilis\u00e9s par ces exploitants s’y conformer. Par exemple, si une entreprise fabrique des capteurs IoT pour fournisseurs d’\u00e9nergie ou des logiciels de contr\u00f4le pour des usines d’eau, elle doit respecter le CRA pour ses produits et \u00e9galement satisfaire aux exigences de NIS2 de ses clients.<\/p>\n La bonne nouvelle : de nombreuses exigences se chevauchent. Qui plus est, si une entreprise exploite already un syst\u00e8me de gestion de la s\u00e9curit\u00e9 des informations conforme \u00e0 l’ISO 27001, elle a d\u00e9j\u00e0 couvert la majeure partie des exigences organisationnelles. La demande de SBOM du CRA s’ajoute aux obligations de transparence de l’AI Act pour les composants d’IA dans les produits.<\/p>\n Le d\u00e9cembre 2027 semble lointain, mais les obligations de signalement \u00e0 partir de septembre 2026<\/a> sont \u00e0 six mois. Une feuille de route pragmatique.<\/p>\n 1. Inventaire des produits cr\u00e9er.<\/strong> Quels produits avec des \u00e9l\u00e9ments num\u00e9riques vendent l’entreprise ? Quels d’entre eux ont une connexion r\u00e9seau, du firmware ou des composants logiciels ? L’inventaire est la base pour la classification des risques.<\/p>\n 2. Cat\u00e9gorie de risque d\u00e9terminer.<\/strong> Pour chaque produit, v\u00e9rifier : standard, cat\u00e9gorie I ou cat\u00e9gorie II ? L’\u00e9valuation d\u00e9termine si une auto-\u00e9valuation suffit ou si un v\u00e9rificateur externe est n\u00e9cessaire.<\/p>\n 3. Processus PSIRT mettre en place.<\/strong> \u00c0 partir de septembre 2026, les faiblesses doivent \u00eatre signal\u00e9es dans les 24 heures. Pour cela, un processus de r\u00e9ponse aux incidents fonctionnant avec des responsabilit\u00e9s claires, des coordonn\u00e9es ENISA et un m\u00e9canisme de signalement document\u00e9 est n\u00e9cessaire.<\/p>\n 4. SBOM cr\u00e9er.<\/strong> Pour chaque produit, cr\u00e9er une Software Bill of Materials qui liste tous les composants logiciels, y compris les versions et les licences. Des outils comme CycloneDX ou SPDX automatisent ce processus.<\/p>\n 5. D\u00e9veloppement s\u00e9curis\u00e9 int\u00e9grer.<\/strong> La s\u00e9curit\u00e9 par conception doit \u00eatre int\u00e9gr\u00e9e dans le processus de d\u00e9veloppement. Cela comprend la mod\u00e9lisation des menaces, les r\u00e9visions de code, les tests d’intrusion et des m\u00e9canismes de mise \u00e0 jour s\u00e9curis\u00e9s.<\/p>\n Un fabricant de capteurs de la Suisse, avec 80 employ\u00e9s, produit des capteurs de temp\u00e9rature et de humidit\u00e9 pour l’industrie alimentaire. Ces capteurs sont \u00e9quip\u00e9s d’une connexion Wi-Fi, envoyent les donn\u00e9es de mesure \u00e0 une plateforme cloud et recevront des mises \u00e0 jour de firmware en ligne. Jusqu’\u00e0 pr\u00e9sent, il n’y avait pas de gestion structur\u00e9e des faiblesses et aucune liste de composants logiciels (SBOM).<\/p>\n \u00c9tape 1 : Inventaire des produits. L’entreprise identifie trois lignes de produits avec des \u00e9l\u00e9ments num\u00e9riques, tous avec un risque standard (auto-\u00e9valuation possible). \u00c9tape 2 : Cr\u00e9ation de l’SBOM. Un fournisseur externe analyse le code de la firmware et g\u00e9n\u00e8re une SBOM CycloneDX. R\u00e9sultat : 47 composants logiciels, dont 12 biblioth\u00e8ques open source, dont trois ne sont plus maintenus depuis plus d’un an. Ces trois doivent \u00eatre remplac\u00e9s ou correct\u00e9s manuellement.<\/p>\n \u00c9tape 3 : Mise en place d’un PSIRT. Le responsable de d\u00e9veloppement logiciel assume le r\u00f4le de responsable de s\u00e9curit\u00e9. Un processus simple est d\u00e9fini : surveillance des faiblesses via la base de donn\u00e9es nationale des vuln\u00e9rabilit\u00e9s (NVD), \u00e9valuation dans les 48 heures, signalement \u00e0 ENISA dans les 24 heures en cas d’exploitation active. \u00c9tape 4 : Documentation. Une analyse des risques, une architecture de s\u00e9curit\u00e9 et des rapports de tests sont r\u00e9dig\u00e9s. Co\u00fbt total : environ 35 000 euros et trois mois de dur\u00e9e du projet.<\/p>\n Le Cyber Resilience Act changera durablement la conception de produits en Europe. Pour les entreprises artisanales productrices, il n’est pas une recommandation optionnelle, mais une condition obligatoire pour l’acc\u00e8s au march\u00e9. Quiconque souhaite vendre des produits connect\u00e9s dans l’UE doit \u00eatre CRA-compliant d’ici d\u00e9cembre 2027.<\/p>\n La premi\u00e8re deadline s\u00e9v\u00e8re n’est pas d\u00e9cembre 2027, mais septembre 2026 : \u00e0 partir de cette date, les faiblesses doivent \u00eatre signal\u00e9es. Six mois ne sont pas beaucoup de temps pour mettre en place un processus PSIRT si celui-ci n’existe pas encore. Celui qui commence maintenant r\u00e9ussit. Celui qui attend se verra contraint de travailler sous pression. L’investissement dans la CRA-compliance n’est pas seulement une d\u00e9pense, c’est une investment dans la qualit\u00e9 des produits, la s\u00e9curit\u00e9 des clients et l’acc\u00e8s \u00e0 long terme au march\u00e9 dans un Europe o\u00f9 la cybers\u00e9curit\u00e9 est devenue une condition pr\u00e9alable.<\/p>\n Oui, si votre logiciel est commercialis\u00e9. Le CRA s’applique \u00e0 tous les produits avec des \u00e9l\u00e9ments num\u00e9riques, y compris les logiciels pur. Les logiciels open source non commerciaux sont exempt\u00e9s.<\/p>\n<\/details>\n Une Software Bill of Materials (SBOM) est une liste compl\u00e8te de toutes les composantes logicieles dans un produit, y compris les biblioth\u00e8ques open source, les versions et les licences. Le CRA exige une SBOM dans le cadre de la documentation technique.<\/p>\n<\/details>\n Au moins cinq ans apr\u00e8s l’introduction sur le march\u00e9 ou au-del\u00e0 de la dur\u00e9e de vie pr\u00e9vue du produit, selon lequel des p\u00e9riodes sont plus courtes. Les mises \u00e0 jour doivent \u00eatre gratuites et fournies rapidement.<\/p>\n<\/details>\n Pour les produits de la cat\u00e9gorie II (critiques), comme les passerelles Smart-Meter ou les syst\u00e8mes de contr\u00f4le industriels. Les produits standard (environ 90 pour cent) peuvent \u00eatre \u00e9valu\u00e9s par le fabricant.<\/p>\n<\/details>\n Des amendes pouvant atteindre 15 millions d’euros ou 2,5 pour cent du chiffre d’affaires global. De plus, les autorit\u00e9s peuvent refuser l’acc\u00e8s au march\u00e9 : les produits non conformes ne peuvent pas \u00eatre vendus dans l’UE.<\/p>\n<\/details>\n NIS2 r\u00e9glemente les op\u00e9rateurs d’infrastructure et de services, tandis que le CRA r\u00e9glemente les fabricants de produits. Si votre entreprise fabrique des produits connect\u00e9s, vous devez satisfaire le CRA. Si vous utiliser ces produits, les obligations NIS2 s’appliquent.<\/p>\n<\/details>\n AI Act \u00e0 partir d’ao\u00fbt 2026 : KI \u00e0 haut risque dans le mittelstand<\/a><\/p>\n Attaque de Supply Chain GlassWorm : 400+ outils compromis – SecurityToday<\/a><\/p>\nLes points cl\u00e9s en bref<\/h2>\n
\n
Qu’applique le CRA et \u00e0 qui s’applique-t-il<\/h2>\n
\n– Commission europ\u00e9enne, Communiqu\u00e9 de presse sur le CRA, septembre 2022<\/cite>\n<\/p><\/blockquote>\nLes trois d\u00e9lais: Quand et comment<\/h2>\n
Cat\u00e9gories de produits: Standard, Important, Critique<\/h2>\n
Qu’ils doivent concr\u00e8tement mettre en \u0153uvre, les fabricants<\/h2>\n
SBOM : Pourquoi la liste de composition logicielle devient un changement de paradigme<\/h2>\n
Quelles sont les co\u00fbts concrets du CRA pour les entreprises de taille interm\u00e9diaire<\/h2>\n
CRA, NIS2 et AI Act : La triade r\u00e9glementaire<\/h2>\n
Checkliste : Cinq \u00e9tapes vers la conformit\u00e9 CRA<\/h2>\n
Exemple de pratique : Un entreprise artisanale sur la voie de la CRA-compliance<\/h2>\n
Conclusion<\/h2>\n
Foire aux questions<\/h2>\n
Suis-je concern\u00e9 en tant qu’ing\u00e9nieur logiciel par le CRA ?<\/strong><\/summary>\n
Qu’est-ce qu’une SBOM ?<\/strong><\/summary>\n
Combien de temps dois-je fournir des mises \u00e0 jour de s\u00e9curit\u00e9 ?<\/strong><\/summary>\n
Ai-je besoin d’une \u00e9valuation externe ?<\/strong><\/summary>\n
Qu’arrive-t-il en cas de non-conformit\u00e9 ?<\/strong><\/summary>\n
En quoi diff\u00e8re le CRA de NIS2 ?<\/strong><\/summary>\n
Conseils de lecture de la r\u00e9daction<\/h2>\n
\n
Plus du r\u00e9seau MBF Media<\/h2>\n
\n
Lectures compl\u00e9mentaires<\/h2>\n