7 min de lecture<\/p>\n
Le R\u00e8glement europ\u00e9en sur la cyberr\u00e9silience (CRA) est entr\u00e9 en vigueur en d\u00e9cembre 2024 et concerne tout fabricant mettant sur le march\u00e9 europ\u00e9en des produits comportant des \u00e9l\u00e9ments num\u00e9riques. \u00c0 compter de septembre 2026, les premi\u00e8res obligations de d\u00e9claration entreront en vigueur ; \u00e0 partir de d\u00e9cembre 2027, tous les produits devront satisfaire aux nouvelles exigences en mati\u00e8re de cybers\u00e9curit\u00e9. Pour les entreprises industrielles du moyen secteur, cela signifie que chaque capteur connect\u00e9, chaque syst\u00e8me de commande de machine et chaque composant logiciel rel\u00e8ve de ce r\u00e8glement. Le temps d’agir devient court.<\/strong><\/p>\n Le R\u00e8glement sur la cyberr\u00e9silience constitue le premier texte r\u00e9glementaire de l’Union europ\u00e9enne \u00e0 introduire des exigences contraignantes en mati\u00e8re de cybers\u00e9curit\u00e9 pour tous les produits comportant des \u00e9l\u00e9ments num\u00e9riques. Son champ d’application est d\u00e9lib\u00e9r\u00e9ment large : il englobe aussi bien le mat\u00e9riel connect\u00e9 (routeurs, appareils domestiques intelligents, capteurs industriels IoT) que les logiciels purs, y compris les applications, les syst\u00e8mes d’exploitation et les pare-feu.<\/p>\n Pour les entreprises industrielles du moyen secteur, cela a des cons\u00e9quences consid\u00e9rables. Chaque syst\u00e8me de commande de machine dot\u00e9 d’une connexion r\u00e9seau, chaque capteur disposant d’une fonction de mise \u00e0 jour du micrologiciel (firmware) et chaque syst\u00e8me embarqu\u00e9 int\u00e9gr\u00e9 dans une installation de production rel\u00e8ve de ce r\u00e8glement.<\/p>\n Particuli\u00e8rement pertinent pour le moyen secteur : les importateurs et distributeurs qui mettent des produits sur le march\u00e9 de l’UE assument \u00e9galement des obligations propres. Celui qui importe un module IoT chinois et le commercialise sous sa propre marque est consid\u00e9r\u00e9 comme \u00ab fabricant \u00bb et doit prouver la conformit\u00e9 compl\u00e8te au CRA. Cela concerne un grand nombre de constructeurs de machines et d’int\u00e9grateurs de syst\u00e8mes qui int\u00e8grent des composants provenant de pays tiers dans leurs solutions.<\/p>\n M\u00eame ceux qui ne fabriquent pas eux-m\u00eames ces produits, mais les int\u00e8grent dans leurs propres solutions, supportent, en tant qu’int\u00e9grateurs, des obligations de conformit\u00e9.<\/p>\n Seules quelques cat\u00e9gories sont express\u00e9ment exclues : les dispositifs m\u00e9dicaux (d\u00e9j\u00e0 r\u00e9glement\u00e9s par le R\u00e8glement sur les dispositifs m\u00e9dicaux, MDR), les v\u00e9hicules automobiles (r\u00e9glementation UNECE), les \u00e9quipements a\u00e9ronautiques et certains produits nationaux li\u00e9s \u00e0 la s\u00e9curit\u00e9. Les logiciels open source ne sont concern\u00e9s que lorsqu’ils sont commercialis\u00e9s \u00e0 des fins commerciales.<\/p>\n \n\u00ab\u00a0Le CRA garantit que les produits mat\u00e9riels et logiciels arrivent sur le march\u00e9 avec moins de vuln\u00e9rabilit\u00e9s et que les fabricants prennent au s\u00e9rieux la s\u00e9curit\u00e9 tout au long du cycle de vie d’un produit.\u00a0\u00bb Le CRA est entr\u00e9 en vigueur le 10 d\u00e9cembre 2024 et sera appliqu\u00e9 progressivement en trois \u00e9tapes. La premi\u00e8re \u00e9ch\u00e9ance arrive plus t\u00f4t que beaucoup d’entreprises ne l’attendent.<\/p>\n 11 juin 2026 :<\/strong> l’habilitation des organismes d’\u00e9valuation de la conformit\u00e9 devient effective. \u00c0 compter de cette date, les autorit\u00e9s nationales doivent avoir d\u00e9sign\u00e9 les organismes habilit\u00e9s \u00e0 \u00e9valuer les produits \u00e0 haut risque (cat\u00e9gories I et II).<\/p>\n 11 septembre 2026 :<\/strong> les obligations de d\u00e9claration relatives aux vuln\u00e9rabilit\u00e9s et aux incidents de s\u00e9curit\u00e9 entrent en vigueur. Les fabricants doivent signaler \u00e0 l’ENISA, dans les 24 heures, toute vuln\u00e9rabilit\u00e9 activement exploit\u00e9e. Pour les incidents de s\u00e9curit\u00e9 graves, le d\u00e9lai de d\u00e9claration est de 72 heures. Cette obligation entre en vigueur six mois avant l’application compl\u00e8te du r\u00e8glement et constitue, pour de nombreuses entreprises, la premi\u00e8re \u00e9ch\u00e9ance contraignante.<\/p>\n 11 d\u00e9cembre 2027 :<\/strong> application int\u00e9grale de toutes les exigences. \u00c0 compter de cette date, seuls les produits conformes au CRA portant le marquage CE seront autoris\u00e9s \u00e0 \u00eatre commercialis\u00e9s sur le march\u00e9 de l’UE. Les produits d\u00e9j\u00e0 pr\u00e9sents sur le march\u00e9 avant cette date et non substantiellement modifi\u00e9s b\u00e9n\u00e9ficient d’une protection du statu quo.<\/p>\n Le CRA classe les produits en trois niveaux de risque, d\u00e9terminant ainsi la proc\u00e9dure d’\u00e9valuation de la conformit\u00e9. Cette classification a des r\u00e9percussions directes sur les co\u00fbts et les efforts requis.<\/p>\n Produits standard (environ 90 % de tous les produits) :<\/strong> capteurs IoT simples, appareils domestiques intelligents sans fonction de s\u00e9curit\u00e9, logiciels grand public et \u00e9quipements de bureau. Les fabricants peuvent attester leur conformit\u00e9 par auto-\u00e9valuation. Aucun organisme tiers n’est requis.<\/p>\n Produits importants (cat\u00e9gorie I) :<\/strong> syst\u00e8mes d’exploitation, pare-feu, routeurs, logiciels VPN, syst\u00e8mes de gestion r\u00e9seau. Une \u00e9valuation selon des normes harmonis\u00e9es ou une v\u00e9rification par un tiers est requise.<\/p>\n Produits critiques (cat\u00e9gorie II) :<\/strong> modules mat\u00e9riels de s\u00e9curit\u00e9, passerelles de compteurs intelligents, syst\u00e8mes de commande industrielle<\/a> et infrastructures \u00e0 cl\u00e9 publique (PKI). Une \u00e9valuation de la conformit\u00e9 par un organisme tiers d\u00e9sign\u00e9 est imp\u00e9rativement obligatoire.<\/p>\n Les exigences du CRA se r\u00e9partissent en trois domaines : d\u00e9veloppement s\u00e9curis\u00e9, gestion des vuln\u00e9rabilit\u00e9s et documentation.<\/p>\n S\u00e9curit\u00e9 par conception (Security by Design) :<\/strong> les produits doivent \u00eatre d\u00e9velopp\u00e9s d\u00e8s la phase de conception selon le principe du \u00ab s\u00e9curis\u00e9 par d\u00e9faut \u00bb. Cela implique une surface d’attaque minimale, des communications chiffr\u00e9es, l’absence de mots de passe cod\u00e9s en dur et des m\u00e9canismes de mise \u00e0 jour s\u00e9curis\u00e9s. Les fabricants doivent d\u00e9montrer que la s\u00e9curit\u00e9 n’a pas \u00e9t\u00e9 ajout\u00e9e a posteriori, mais int\u00e9gr\u00e9e d\u00e8s le d\u00e9part.<\/p>\n Gestion des vuln\u00e9rabilit\u00e9s :<\/strong> les fabricants doivent fournir des mises \u00e0 jour de s\u00e9curit\u00e9 pendant toute la dur\u00e9e du cycle de vie du produit, et au minimum pendant cinq ans apr\u00e8s sa mise sur le march\u00e9. Toute vuln\u00e9rabilit\u00e9 activement exploit\u00e9e doit \u00eatre signal\u00e9e \u00e0 l’ENISA dans les 24 heures. Cela exige la mise en place d’un processus PSIRT fonctionnel (\u00e9quipe de r\u00e9ponse aux incidents de s\u00e9curit\u00e9 des produits).<\/p>\n Documentation technique :<\/strong> pour chaque produit, une documentation exhaustive doit \u00eatre disponible : analyse des risques, description de l’architecture de s\u00e9curit\u00e9, rapports de tests, SBOM (liste des composants logiciels) et d\u00e9claration UE de conformit\u00e9.<\/p>\n Un point souvent sous-estim\u00e9 : l’obligation de fournir gratuitement des mises \u00e0 jour de s\u00e9curit\u00e9 pendant au moins cinq ans. Pour les fabricants de composants industriels dont le cycle de vie s’\u00e9tend sur dix \u00e0 vingt ans, cela repr\u00e9sente un engagement \u00e0 long terme substantiel. Celui qui lance aujourd’hui un module de commande connect\u00e9 doit garantir qu’il pourra encore \u00eatre correctement mis \u00e0 jour en 2032. Cela exige une architecture logicielle durable et une infrastructure de mise \u00e0 jour op\u00e9rationnelle allant bien au-del\u00e0 du cycle de vie typique d’un produit.<\/p>\n Dans la pratique, cela signifie \u00e9galement que les fabricants doivent repenser leurs relations avec leurs fournisseurs. Si une biblioth\u00e8que open source int\u00e9gr\u00e9e dans un produit n’est plus maintenue, le fabricant doit soit d\u00e9velopper lui-m\u00eame les correctifs, soit remplacer la composante. La SBOM devient ici un syst\u00e8me d’alerte pr\u00e9coce : elle identifie les d\u00e9pendances existantes et les risques latents.<\/p>\n La SBOM est particuli\u00e8rement pertinente, car elle doit lister exhaustivement tous les composants logiciels, y compris les biblioth\u00e8ques open source.<\/p>\n La Software Bill of Materials (SBOM) constitue l’un des nouveaux instruments centraux du CRA. Dans la pratique, elle est comparable \u00e0 la liste des ingr\u00e9dients figurant sur un emballage alimentaire : elle recense chaque composant logiciel int\u00e9gr\u00e9 dans un produit. Pour de nombreux acteurs du moyen secteur, cela repr\u00e9sente un d\u00e9fi, car les d\u00e9pendances dans les piles logicielles modernes sont complexes.<\/p>\n Un syst\u00e8me embarqu\u00e9 typique dans une commande de machine comprend un syst\u00e8me d’exploitation temps r\u00e9el, des biblioth\u00e8ques de communication, des modules cryptographiques et des dizaines d’autres composants, souvent int\u00e9gr\u00e9s sous forme open source. Chacun de ces composants peut contenir des vuln\u00e9rabilit\u00e9s que le fabricant doit conna\u00eetre et ma\u00eetriser.<\/p>\n La bonne nouvelle : des normes et outils \u00e9prouv\u00e9s existent. CycloneDX et SPDX sont les deux formats SBOM dominants. Des outils de construction comme Syft ou Grype g\u00e9n\u00e8rent automatiquement des SBOM \u00e0 partir du r\u00e9f\u00e9rentiel de code. Pour les entreprises utilisant d\u00e9j\u00e0 des pipelines CI\/CD, la g\u00e9n\u00e9ration de SBOM peut \u00eatre int\u00e9gr\u00e9e dans le processus de construction existant, sans perturber le flux de d\u00e9veloppement.<\/p>\n Pour les entreprises ne d\u00e9veloppant pas elles-m\u00eames de logiciels, mais achetant des composants aupr\u00e8s de fournisseurs, la r\u00e8gle est la suivante : exigez une SBOM de vos fournisseurs. Le CRA d\u00e9place la responsabilit\u00e9 le long de la cha\u00eene d’approvisionnement. Celui qui int\u00e8gre des composants d\u00e9pourvus de SBOM dans ses propres produits assume lui-m\u00eame la responsabilit\u00e9 des vuln\u00e9rabilit\u00e9s 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 faisant l’objet d’une auto-\u00e9valuation, les experts sectoriels estiment les co\u00fbts ponctuels \u00e0 20 000 \u00e0 50 000 euros par gamme de produits, principalement destin\u00e9s \u00e0 la documentation, \u00e0 l’analyse des risques et \u00e0 la cr\u00e9ation de la SBOM.<\/p>\n Pour les produits des cat\u00e9gories I et II, n\u00e9cessitant une \u00e9valuation externe, les co\u00fbts augmentent \u00e0 80 000 \u00e0 200 000 euros. S’y ajoutent des co\u00fbts r\u00e9currents li\u00e9s \u00e0 la gestion des vuln\u00e9rabilit\u00e9s : un processus PSIRT d\u00e9di\u00e9, incluant surveillance, d\u00e9veloppement de correctifs et d\u00e9clarations \u00e0 l’ENISA, n\u00e9cessite au minimum une demi-\u00e9quivalent temps plein, voire davantage en pratique.<\/p>\n L’autre face de la m\u00e9daille : selon le BSI (Office f\u00e9d\u00e9ral de la s\u00e9curit\u00e9 informatique), le co\u00fbt moyen d’un incident de cybers\u00e9curit\u00e9 dans le moyen secteur s’\u00e9l\u00e8ve \u00e0 500 000 euros. Un seul incident grave d\u00e9passe les co\u00fbts de conformit\u00e9 sur plusieurs ann\u00e9es. S’y ajoute l’avantage concurrentiel li\u00e9 \u00e0 l’acc\u00e8s au march\u00e9 : celui qui est conforme au CRA peut commercialiser ses produits partout en Europe sans restriction, tandis que les concurrents non conformes sont exclus du march\u00e9.<\/p>\n Le CRA n’existe pas isol\u00e9ment. Avec le NIS2<\/a> (s\u00e9curit\u00e9 des r\u00e9seaux et des syst\u00e8mes d’information) et le R\u00e8glement IA<\/a>, il forme une triade r\u00e9glementaire qui touche simultan\u00e9ment les entreprises europ\u00e9ennes. Pour le moyen secteur, cela signifie : identifier les chevauchements et exploiter les synergies.<\/p>\n Le NIS2 oblige les op\u00e9rateurs d’infrastructures critiques et importantes \u00e0 mettre en place une gestion des risques et \u00e0 d\u00e9clarer les incidents. Le CRA, quant \u00e0 lui, oblige les fabricants des produits utilis\u00e9s par ces op\u00e9rateurs. Ainsi, celui qui fabrique des capteurs IoT pour les fournisseurs d’\u00e9nergie ou des logiciels de commande pour les usines d’eau doit respecter \u00e0 la fois les exigences du CRA pour ses produits et celles du NIS2 applicables \u00e0 ses clients.<\/p>\n La bonne nouvelle : de nombreuses exigences se recoupent. Celui qui dispose d\u00e9j\u00e0 d’un syst\u00e8me de management de la s\u00e9curit\u00e9 de l’information conforme \u00e0 la norme ISO\/IEC 27001 couvre d\u00e9j\u00e0 une grande partie des exigences organisationnelles. L’exigence de SBOM du CRA compl\u00e8te les obligations de transparence du R\u00e8glement IA concernant les composants d’intelligence artificielle int\u00e9gr\u00e9s dans les produits.<\/p>\n D\u00e9cembre 2027 semble lointain, mais les obligations de d\u00e9claration \u00e0 compter de septembre 2026<\/a> interviennent dans six mois. Voici une feuille de route pragmatique.<\/p>\n 1. \u00c9tablir un inventaire des produits.<\/strong> Quels produits comportant des \u00e9l\u00e9ments num\u00e9riques l’entreprise commercialise-t-elle ? Lesquels disposent d’une connexion r\u00e9seau, d’un micrologiciel ou de composants logiciels ? Ce recensement constitue la base de la classification des risques.<\/p>\n 2. D\u00e9terminer la classe de risque.<\/strong> Pour chaque produit, v\u00e9rifier s’il rel\u00e8ve de la cat\u00e9gorie \u00ab standard \u00bb, \u00ab cat\u00e9gorie I \u00bb ou \u00ab cat\u00e9gorie II \u00bb. Cette classification d\u00e9termine si une auto-\u00e9valuation suffit ou si un organisme tiers est requis.<\/p>\n 3. Mettre en place un processus PSIRT.<\/strong> \u00c0 compter de septembre 2026, les vuln\u00e9rabilit\u00e9s doivent \u00eatre d\u00e9clar\u00e9es dans les 24 heures. Cela exige un processus de r\u00e9ponse aux incidents fonctionnel, avec des responsabilit\u00e9s clairement d\u00e9finies, des coordonn\u00e9es de contact de l’ENISA et une proc\u00e9dure de d\u00e9claration document\u00e9e.<\/p>\n 4. Cr\u00e9er une SBOM.<\/strong> Pour chaque produit, \u00e9tablir une Software Bill of Materials recensant tous les composants logiciels, y compris leurs versions et licences. Des outils comme CycloneDX ou SPDX automatisent ce processus.<\/p>\n 5. Mettre en \u0153uvre un cycle de d\u00e9veloppement s\u00e9curis\u00e9 (Secure Development Lifecycle).<\/strong> Le principe \u00ab Security by Design \u00bb doit \u00eatre int\u00e9gr\u00e9 au processus de d\u00e9veloppement. Cela comprend la mod\u00e9lisation des menaces, les revues de code, les tests d’intrusion (penetration tests) et des m\u00e9canismes de mise \u00e0 jour s\u00e9curis\u00e9s.<\/p>\n Un fabricant de capteurs bas\u00e9 en Souabe, comptant 80 employ\u00e9s, produit des capteurs de temp\u00e9rature et d’humidit\u00e9 destin\u00e9s \u00e0 l’industrie agroalimentaire. Ces capteurs disposent d’une connexion Wi-Fi, transmettent les donn\u00e9es de mesure \u00e0 une plateforme cloud et re\u00e7oivent des mises \u00e0 jour du firmware par voie a\u00e9rienne (over-the-air). Jusqu’\u00e0 pr\u00e9sent, il n’existait ni processus structur\u00e9 de gestion des vuln\u00e9rabilit\u00e9s, ni SBOM.<\/p>\n \u00c9tape 1 : inventaire des produits. L’entreprise identifie trois gammes de produits comportant des \u00e9l\u00e9ments num\u00e9riques, toutes class\u00e9es \u00e0 risque standard (auto-\u00e9valuation possible).<\/p>\n \u00c9tape 2 : cr\u00e9ation de la SBOM. Un prestataire externe analyse le code du firmware et \u00e9tablit une SBOM au format CycloneDX. R\u00e9sultat : 47 composants logiciels, dont 12 biblioth\u00e8ques open source, dont trois n’ayant pas \u00e9t\u00e9 mises \u00e0 jour depuis plus d’un an. Ces trois composants doivent \u00eatre remplac\u00e9s ou corrig\u00e9s en interne.<\/p>\n \u00c9tape 3 : mise en place du PSIRT. Le responsable du d\u00e9veloppement logiciel assume la fonction de responsable s\u00e9curit\u00e9. Un processus simple est d\u00e9fini : surveillance des vuln\u00e9rabilit\u00e9s via la National Vulnerability Database (NVD), \u00e9valuation dans les 48 heures, d\u00e9claration \u00e0 l’ENISA dans les 24 heures en cas d’exploitation active.<\/p>\n \u00c9tape 4 : documentation. Analyse des risques, architecture de s\u00e9curit\u00e9 et rapports de tests sont r\u00e9dig\u00e9s. Charge de travail totale : environ 35 000 euros et une dur\u00e9e de projet de trois mois.<\/p>\n Le R\u00e8glement sur la cyberr\u00e9silience transformera durablement le d\u00e9veloppement de produits en Europe. Pour les entreprises industrielles du moyen secteur, il ne s’agit pas d’une recommandation facultative, mais d’une condition obligatoire d’acc\u00e8s au march\u00e9. Celui qui souhaite vendre des produits connect\u00e9s dans l’UE doit \u00eatre conforme au CRA \u00e0 compter de d\u00e9cembre 2027.<\/p>\n Mais la premi\u00e8re \u00e9ch\u00e9ance contraignante n’est pas d\u00e9cembre 2027, mais septembre 2026 : \u00e0 compter de cette date, les vuln\u00e9rabilit\u00e9s doivent \u00eatre d\u00e9clar\u00e9es. Six mois ne constituent pas beaucoup de temps pour mettre en place un processus PSIRT, si aucun n’existe encore. Celui qui commence d\u00e8s maintenant y parviendra. Celui qui attend aura \u00e0 rattraper son retard sous pression temporelle. L’investissement dans la conformit\u00e9 au CRA n’est pas une simple charge. C’est un investissement dans la qualit\u00e9 des produits, la s\u00e9curit\u00e9 des clients et l’acc\u00e8s durable au march\u00e9 europ\u00e9en, o\u00f9 la cybers\u00e9curit\u00e9 devient une condition fondamentale.<\/p>\n Oui, si votre logiciel est commercialis\u00e9 \u00e0 des fins commerciales. Le CRA s’applique \u00e0 tous les produits comportant des \u00e9l\u00e9ments num\u00e9riques, y compris les logiciels purs. Seuls les logiciels open source non commerciaux sont exclus.<\/p>\n<\/details>\n Une Software Bill of Materials est une liste exhaustive de tous les composants logiciels d’un produit, y compris les biblioth\u00e8ques open source, leurs versions et leurs licences. Le CRA exige une SBOM dans le cadre de la documentation technique.<\/p>\n<\/details>\n Au minimum pendant cinq ans apr\u00e8s la mise sur le march\u00e9, ou pendant la dur\u00e9e de vie pr\u00e9vue du produit, selon la p\u00e9riode la plus courte. Les mises \u00e0 jour doivent \u00eatre fournies gratuitement et dans les meilleurs d\u00e9lais.<\/p>\n<\/details>\n Uniquement pour les produits de cat\u00e9gorie II (critiques), tels que les passerelles de compteurs intelligents ou les syst\u00e8mes de commande industrielle. Les produits standard (environ 90 %) peuvent faire l’objet d’une auto-\u00e9valuation par le fabricant.<\/p>\n<\/details>\n Des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial. En outre, les autorit\u00e9s peuvent refuser l’acc\u00e8s au march\u00e9 : les produits non conformes ne pourront plus \u00eatre vendus dans l’UE.<\/p>\n<\/details>\n Le NIS2 r\u00e9glemente les op\u00e9rateurs d’infrastructures et de services, tandis que le CRA r\u00e9glemente les fabricants de produits. Si votre entreprise fabrique des produits connect\u00e9s, vous devez respecter le CRA. Si vous utilisez ces produits, les obligations du NIS2 s’appliquent \u00e0 vous.<\/p>\n<\/details>\n Le R\u00e8glement IA \u00e0 compter d’ao\u00fbt 2026 : l’IA \u00e0 haut risque dans le moyen secteur<\/a><\/p>\nL’essentiel en bref<\/h2>\n
\n
Ce que le CRA r\u00e9glemente et qui il concerne<\/h2>\n
\n– Commission europ\u00e9enne, communiqu\u00e9 de presse sur le CRA, septembre 2022<\/cite>\n<\/p><\/blockquote>\nLes trois \u00e9ch\u00e9ances : ce qui entre en vigueur et quand<\/h2>\n
Cat\u00e9gories de produits : standard, important, critique<\/h2>\n
Ce que les fabricants doivent concr\u00e8tement mettre en \u0153uvre<\/h2>\n
SBOM : pourquoi la liste des composants logiciels devient un facteur d\u00e9cisif<\/h2>\n
Co\u00fbt concret du CRA pour le moyen secteur<\/h2>\n
CRA, NIS2 et R\u00e8glement IA : la triade r\u00e9glementaire<\/h2>\n
Check-liste : cinq \u00e9tapes vers la conformit\u00e9 au CRA<\/h2>\n
Exemple pratique : un acteur du moyen secteur sur la voie de la conformit\u00e9 au CRA<\/h2>\n
Conclusion<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
En tant que d\u00e9veloppeur de logiciels, suis-je concern\u00e9 par le CRA ?<\/strong><\/summary>\n
Qu’est-ce qu’une SBOM ?<\/strong><\/summary>\n
Pendant combien de temps dois-je fournir des mises \u00e0 jour de s\u00e9curit\u00e9 ?<\/strong><\/summary>\n
Ai-je besoin d’un organisme tiers pour l’\u00e9valuation ?<\/strong><\/summary>\n
Que se passe-t-il en cas de non-conformit\u00e9 ?<\/strong><\/summary>\n
En quoi le CRA se distingue-t-il du NIS2 ?<\/strong><\/summary>\n
Lectures recommand\u00e9es par la r\u00e9daction<\/h2>\n
\n
Plus encore du r\u00e9seau MBF Media<\/h2>\n
\n
Lectures compl\u00e9mentaires<\/h2>\n