Si vous fabriquez un produit qui se connecte à Internet — un thermostat connecté, une application mobile, un capteur industriel, même un logiciel — le Cyber Resilience Act (CRA) de l'UE s'applique probablement à vous. Et si vous êtes une petite ou moyenne entreprise, cela peut sembler intimidant.
Bonne nouvelle : vous avez du temps, et une marche à suivre claire.
Le CRA est la réglementation de sécurité des produits la plus importante de l'histoire de l'UE. Mais il reste étonnamment praticable pour une PME une fois que vous comprenez ce qu'il demande, quand il le demande, et comment intégrer la conformité dans votre développement produit plutôt que de l'ajouter en fin de course.
Ce guide décompose le Cyber Resilience Act (Règlement (UE) 2024/2847) pour les petites entreprises — fabricants, importateurs, distributeurs et équipes logicielles qui ont besoin de clarté sans le brouillard juridique.
Qu'est-ce que le Cyber Resilience Act ?
Le CRA est un règlement de l'UE — pas une directive, il s'applique donc directement dans chaque État membre sans transposition nationale — qui fixe des exigences horizontales de cybersécurité pour les produits avec éléments numériques mis sur le marché de l'UE.
Dates clés :
- Adopté : 23 octobre 2024
- Entré en vigueur : 10 décembre 2024
- Obligations de notification (article 14) : 11 septembre 2026
- Application complète : 11 décembre 2027
Le principe fondamental du CRA est le « sécurisé par conception et par défaut ». Il déplace la responsabilité de la cybersécurité du produit de l'utilisateur vers le fabricant. Avant le CRA, si votre serrure connectée avait une vulnérabilité, c'était le problème de l'acheteur. Après décembre 2027, c'est le vôtre — et une erreur peut coûter jusqu'à 15 millions d'euros.
Le CRA s'applique-t-il à votre PME ?
Trois questions tranchent. Si la réponse aux trois est oui, vous êtes concerné.
Question 1 : fabriquez-vous ou vendez-vous un « produit avec éléments numériques » ?
Le CRA le définit largement : tout produit logiciel ou matériel pouvant se connecter à un autre appareil ou réseau, directement ou indirectement.
Concernés :
- Appareils connectés maison (thermostats, caméras, serrures)
- Équipements réseau (routeurs, pare-feu, switches)
- Applications mobiles et logiciels
- Systèmes de contrôle industriel et capteurs IoT
- Ordinateurs portables, smartphones, objets connectés
- Logiciels et firmware embarqués
- Solutions de traitement de données à distance
Non concernés (déjà réglementés ailleurs) : dispositifs médicaux (MDR/IVDR), composants automobiles (UNECE), équipements marins et certains systèmes aéronautiques.
Point critique : le CRA s'applique selon l'endroit où le produit est mis sur le marché, pas où il est fabriqué. Une entreprise SaaS américaine qui vend à des clients européens est concernée. Un fabricant chinois vendant via Amazon UE est concerné.
Question 2 : êtes-vous un « opérateur économique » ?
Le CRA impose des obligations à quatre rôles :
| Rôle | Définition | Obligations principales |
|---|---|---|
| Fabricant | Conçoit, développe ou met le produit sur le marché sous son nom | Évaluation des risques, conformité, marquage CE, gestion des vulnérabilités, notification |
| Importateur | Introduit des produits non-UE sur le marché UE | Vérifier le marquage CE, conserver la documentation, coopérer avec les autorités |
| Distributeur | Met des produits à disposition sur le marché UE (ni fabricant ni importateur) | Vérifier le marquage CE, éviter les produits non conformes, coopérer avec la surveillance |
| Steward open source | Soutient un logiciel open source dans un écosystème commercial | Obligations spécifiques de gestion des vulnérabilités et de documentation |
Pour les PME, le rôle de fabricant est le plus lourd. Si vous concevez, commercialisez ou vendez un produit numérique, vous êtes le fabricant — même en équipe de 10 personnes.
Question 3 : votre produit est-il commercial ?
Un logiciel open source développé sans activité commerciale est généralement exempté. Mais si vous le monétisez (abonnements, support, hébergement), l'intégrez dans un produit commercial ou le fournissez en tant que service (SaaS), le CRA s'applique probablement.
Les trois classes de produits
Tous les produits ne sont pas traités de la même manière. Le CRA fait monter les exigences sur trois niveaux :
| Classe | Exemples | Évaluation de la conformité |
|---|---|---|
| Produits standard | Logiciels généraux, matériel non critique | Auto-évaluation |
| Importants — Classe I | Navigateurs, gestionnaires de mots de passe, VPN, systèmes d'exploitation, outils de gestion réseau | Auto-évaluation |
| Importants — Classe II | Hyperviseurs, pare-feu, surveillance industrielle, composants de compteurs intelligents, lecteurs de cartes à puce | Évaluation par un tiers |
| Produits critiques | Cartes à puce, éléments sécurisés, systèmes de sécurité industrielle | Certificat européen de cybersécurité ou évaluation par un tiers |
Ce que cela signifie pour les PME : la plupart des petits éditeurs de logiciels et fabricants d'IoT relèvent des « Standard » ou « Importants Classe I » — vous pouvez donc vous auto-évaluer. Seuls les pare-feu, systèmes de contrôle industriel et matériels de sécurité exigent une certification par un tiers. L'outil CRA Fast Check détermine votre classe en une minute environ.
Obligations principales des fabricants
L'article 13 énumère les devoirs du fabricant. Voici ceux qui comptent le plus pour les PME, traduits du jargon juridique en français clair.
1. Sécurisé par conception et par défaut (Annexe I, Partie I)
Avant la livraison, un produit doit être fourni avec des configurations sécurisées par défaut (pas de mots de passe par défaut, moindre privilège), protéger contre les accès non autorisés par conception, assurer la confidentialité et l'intégrité des données, protéger la disponibilité des fonctions essentielles et minimiser l'impact sur d'autres systèmes.
Traduction PME : ne livrez pas avec des identifiants « admin/admin », n'obligez pas les utilisateurs à désactiver la sécurité pour que le produit fonctionne, et ne transformez pas votre appareil IoT en botnet en puissance.
2. Gestion des vulnérabilités (Annexe I, Partie II)
Il vous faut un processus documenté pour identifier et documenter les vulnérabilités, publier rapidement des mises à jour de sécurité, les maintenir disponibles pendant la période de support (minimum 5 ans), tenir une politique de divulgation coordonnée des vulnérabilités (CVD) et partager les correctifs avec les mainteneurs amont le cas échéant.
Traduction PME : il vous faut une adresse security@, un délai de réponse
raisonnable aux signalements, des correctifs rapides pour les bugs critiques, et
la discipline de continuer pendant au moins 5 ans après l'arrêt de la vente.
3. Évaluation des risques de cybersécurité
Avant de mettre un produit sur le marché, vous devez mener — et documenter — une évaluation des risques qui guide votre conception sécurité. Conservez-la au moins 10 ans.
Traduction PME : consignez ce qui pourrait mal tourner, ce que vous avez fait pour l'empêcher, et pourquoi c'est suffisant. Un document de 5 pages suffit pour un produit simple.
4. Documentation technique
Maintenez une documentation couvrant la description du produit et son usage prévu, l'évaluation des risques, la manière dont vous avez respecté les exigences essentielles, vos procédures de gestion des vulnérabilités et les preuves de test.
Traduction PME : gardez un dossier (numérique) avec votre évaluation des risques, les schémas d'architecture, les résultats de tests de sécurité et les journaux de mises à jour. Les autorités de surveillance du marché peuvent le demander à tout moment pendant 10 ans.
5. Déclaration UE de conformité et marquage CE
Une fois l'auto-évaluation (ou la certification) effectuée, rédigez une Déclaration UE de conformité, apposez le marquage CE et incluez l'identification du fabricant ainsi que la date de fin de support.
Traduction PME : le marquage CE signifie désormais aussi « ce produit respecte les exigences de cybersécurité ». Vous ne pouvez pas l'apposer sans avoir fait le travail.
6. Période de support et disponibilité des mises à jour
La période de support minimale est de 5 ans (ou la durée de vie prévue du produit si elle est plus courte). Les mises à jour de sécurité doivent rester disponibles pendant au moins 10 ans après leur publication, et la date de fin de support doit être communiquée aux acheteurs au moment de l'achat.
Le calendrier de notification : 24h / 72h / 14 jours
L'article 14 introduit une notification stricte pour les vulnérabilités activement exploitées et les incidents graves. Il s'applique dès le 11 septembre 2026 — avant les obligations principales.
| Étape | Délai | Quoi signaler |
|---|---|---|
| Alerte précoce | Sous 24 heures | Vulnérabilité activement exploitée ou incident grave détecté |
| Notification | Sous 72 heures | Évaluation détaillée, impact, indicateurs de compromission |
| Rapport final | 14 jours (vulnérabilités) / 1 mois (incidents) | Cause racine, mesures correctives, impact transfrontalier |
Les rapports vont au CSIRT de votre État membre d'établissement principal et à l'ENISA via la Plateforme unique de signalement du CRA.
Vérification de réalité PME : une équipe de 15 personnes a besoin d'un chemin d'escalade 24/7 pour les incidents de sécurité. Cela ne veut pas dire un SOC — cela veut dire un processus documenté pour savoir qui appeler quand une vulnérabilité critique tombe un vendredi soir.
Importateurs, distributeurs et chaîne d'approvisionnement
Si vous n'êtes pas le fabricant mais que vous importez ou distribuez des produits, vous avez vos propres devoirs.
Les importateurs doivent vérifier le marquage CE, confirmer l'existence de la documentation technique et de la Déclaration de conformité, s'assurer que les instructions utilisateur sont dans une langue compréhensible, conserver la documentation 10 ans et coopérer avec les autorités.
Les distributeurs doivent vérifier le marquage CE et la documentation requise, refuser de mettre des produits non conformes sur le marché, coopérer avec les enquêtes et prendre des mesures correctives lorsqu'un produit présente un risque de cybersécurité.
Traduction PME : si vous importez des appareils connectés et les revendez sur Amazon UE, c'est vous qui êtes responsable de vérifier la conformité au CRA. Vous ne pouvez pas blâmer le fabricant s'il est en défaut.
Open source : l'exception du steward
Le CRA a inquiété la communauté open source. Le texte final y répond avec le concept de « steward de logiciel open source » :
| Scénario | Applicabilité du CRA |
|---|---|
| Projet open source non commercial (pas de monétisation) | Exempté |
| Composant open source intégré dans un produit commercial | Le fabricant du produit commercial est responsable |
| Entité commerciale soutenant un écosystème open source (steward) | Le steward a des obligations spécifiques de gestion des vulnérabilités et de documentation |
| SaaS construit sur une stack open source | Le fournisseur SaaS est le fabricant et doit se conformer |
Ce que cela signifie pour les PME : si vous construisez un produit commercial sur des composants open source (la plupart le font), vous êtes responsable de la sécurité du produit entier — parties open source comprises. Faites preuve de due diligence en intégrant des composants tiers et signalez les vulnérabilités aux mainteneurs amont.
Astuce pratique : maintenez un Software Bill of Materials (SBOM) pour chaque version. Des outils comme Syft, CycloneDX ou SPDX peuvent l'automatiser.
Feuille de route de conformité 24 mois pour les PME
Avec l'application complète le 11 décembre 2027, les PME disposent d'environ 24 mois à partir de mi-2026 pour se préparer. Une approche par phases réaliste :
Phase 1 : cadrage et évaluation (mois 1–3)
- Confirmer votre classe de produit avec le CRA Fast Check
- Cartographier votre portefeuille : quels produits concernés, lesquels exemptés
- Identifier votre rôle : fabricant, importateur, distributeur ou steward
- Mener une analyse d'écart par rapport aux exigences essentielles de l'Annexe I
- Créer des SBOMs initiaux pour chaque produit
Phase 2 : construction des fondations (mois 4–9)
- Établir un cycle de développement sécurisé : modélisation des menaces, revue de code, tests de sécurité
- Mettre en place la gestion des vulnérabilités : politique CVD, canal de signalement, SLA de triage
- Rédiger un modèle de documentation technique
- Définir les périodes de support (minimum 5 ans par produit)
- Construire la capacité de réponse aux incidents : escalade 24/7, modèles de signalement
- Rédiger la documentation sécurité utilisateur
Phase 3 : conformité et documentation (mois 10–18)
- Compléter les évaluations des risques pour tous les produits concernés
- Mener l'auto-évaluation de conformité interne (Standard / Classe I)
- Préparer la Déclaration UE de conformité pour chaque produit
- Apposer le marquage CE (peut être numérique pour les logiciels)
- Publier les instructions utilisateur avec la date de fin de support
- Mettre en place un mécanisme de livraison des mises à jour (OTA, dépôt de patchs)
Phase 4 : préparation au signalement (mois 19–22)
- S'inscrire sur la Plateforme unique de signalement du CRA (via l'ENISA)
- Tester le workflow de signalement avec un exercice de crise
- Former l'équipe aux délais 24h/72h/14 jours
- Établir une relation avec votre CSIRT national
- Documenter votre processus de conservation des preuves sur 10 ans
Phase 5 : mise en production et amélioration continue (mois 23–24+)
- Confirmer que tout produit mis sur le marché après le 11 déc. 2027 est conforme
- Surveiller les normes harmonisées et les actes délégués
- Mener une revue annuelle des évaluations des risques et de la documentation
- Postuler au financement SECURE UE si éligible (jusqu'à 30 000 € pour les micro-PME)
Sanctions et application
Les sanctions du CRA sont à deux niveaux :
| Violation | Amende maximale |
|---|---|
| Non-conformité aux exigences essentielles ou aux articles 13 et 14 | 15 millions d'euros OU 2,5 % du chiffre d'affaires mondial annuel |
| Autres infractions | 10 millions d'euros OU 1,5 % du chiffre d'affaires mondial annuel |
Les autorités peuvent aussi retirer ou rappeler des produits, interdire la vente, émettre des injonctions de mise en conformité et dénoncer publiquement les entreprises non conformes.
L'angle PME : pour une PME de 5 M€ de CA, une sanction de 2,5 % représente 125 000 € ; pour une PME de 50 M€, c'est 1,25 M€. Des montants réels qui peuvent tuer une entreprise — et entièrement évitables avec de la préparation.
CRA vs NIS2 : comment ils interagissent
Beaucoup de PME seront soumises aux deux. Voici comment ils diffèrent et se chevauchent :
| Aspect | CRA | NIS2 |
|---|---|---|
| Type | Règlement (directement applicable) | Directive (transposition nationale) |
| Focus | Sécurité des produits | Sécurité organisationnelle |
| Cible | Fabricants, importateurs, distributeurs de produits numériques | Entités essentielles et importantes |
| Obligation clé | Sécurisé par conception, marquage CE, notification de vulnérabilités | Gestion des risques, notification d'incidents, sécurité de la chaîne d'approvisionnement |
| Calendrier | Application complète déc. 2027 | Déjà transposé dans la plupart des États membres |
| Sanctions | Jusqu'à 15 M€ ou 2,5 % du CA | Jusqu'à 10 M€ ou 2 % du CA |
Le chevauchement : si vous êtes un fabricant de logiciels également « Entité importante » sous NIS2, vous avez une double obligation — mais la documentation technique, l'évaluation des risques et la gestion des vulnérabilités du CRA s'alignent étroitement sur les mesures de l'article 21 de NIS2. Un programme de sécurité bien structuré sert les deux. Pour le volet organisationnel, voyez notre guide NIS2 pour les PME.
Comment Komplyo vous aide à être prêt pour le CRA
Les devoirs de sécurité produit du CRA — évaluation des risques, gestion des vulnérabilités, configuration sécurisée par défaut et documentation technique — reposent sur une base de sécurité organisationnelle. C'est précisément cette base que Komplyo vous aide à construire et à prouver.
- On évalue une fois, on lit partout. Vous répondez une fois sur le NIST CSF 2.0 et Komplyo projette votre posture sur NIS2, le RGPD, ISO 27001 et SOC 2 — les mêmes contrôles qui sous- tendent la gestion des vulnérabilités et l'évaluation des risques du CRA. Découvrez la méthodologie.
- Commencez gratuitement. Le diagnostic gratuit vous donne un score de maturité par fonction CSF en quelques minutes — un moyen rapide de repérer les lacunes que la conformité CRA fera ressortir.
- Des écarts aux preuves. Les lacunes identifiées alimentent une feuille de route priorisée et des politiques générées — la documentation que réclament les auditeurs et les clients grands comptes. Découvrez le produit.
Foire aux questions
Le Cyber Resilience Act s'applique-t-il aux logiciels ou seulement au matériel ?
Aux deux. Le CRA couvre tout « produit avec éléments numériques » pouvant se connecter à un appareil ou un réseau — y compris les logiciels autonomes, les applications mobiles, les firmware et le SaaS avec composants de traitement de données à distance.
À partir de quand le CRA s'applique-t-il vraiment ?
Les obligations de notification de l'article 14 s'appliquent dès le 11 septembre 2026, et l'ensemble des obligations dès le 11 décembre 2027. Les produits mis sur le marché après cette date doivent être conformes.
Les petites entreprises doivent-elles payer une certification par un tiers ?
En général non. La plupart des logiciels et produits IoT des PME relèvent des classes « Standard » ou « Importants Classe I », qui autorisent l'auto-évaluation. Seuls les produits de Classe II et critiques (pare-feu, systèmes de contrôle industriel, matériel de sécurité) exigent une évaluation par un tiers ou un certificat européen de cybersécurité.
Quels sont les délais de notification du CRA ?
Pour les vulnérabilités activement exploitées et les incidents graves : une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous 14 jours (vulnérabilités) ou 1 mois (incidents), adressés à votre CSIRT national et à l'ENISA.
Combien de temps dois-je supporter un produit sous le CRA ?
Au minimum 5 ans (ou la durée de vie prévue du produit si elle est plus courte). Les mises à jour de sécurité doivent rester disponibles pendant au moins 10 ans après leur publication, et la date de fin de support doit être communiquée aux acheteurs lors de l'achat.
Ressources et outils gratuits
| Ressource | Source | Ce qu'elle fournit |
|---|---|---|
| Texte complet du CRA (Journal officiel UE) | Journal officiel de l'UE | Le texte juridique du Règlement (UE) 2024/2847 |
| CRA Fast Check auto-évaluation | Ressource indépendante CRA | Assistant de 3 questions pour le périmètre et la classe de produit |
| Résumé du CRA par la Commission européenne | Commission européenne | Résumé officiel du texte législatif |
| Matériaux CRA de l'ENISA | ENISA | Guide, mapping des standards, support de mise en œuvre |
| Projet SECURE UE | Projet financé par l'UE | Formations gratuites et financement en cascade (jusqu'à 30 000 €) pour les micro-PME |
| Standard SBOM CycloneDX | OWASP | Format et outils SBOM gratuits |
| Standard SBOM SPDX | Linux Foundation | Standard SBOM alternatif, très utilisé dans l'open source |
En résumé : commencez maintenant, à un rythme posé
Le CRA change fondamentalement la façon dont les produits numériques sont conçus, vendus et supportés dans l'UE. Pour les PME, il crée à la fois risque et opportunité.
Le risque est clair : la non-conformité signifie amendes, exclusion du marché et dommages réputationnels. L'opportunité est plus discrète mais tout aussi réelle — les PME qui construisent des produits conformes au CRA en avance peuvent faire de la sécurité un avantage concurrentiel. Quand une équipe d'achat compare deux fournisseurs IoT, l'un avec un cycle de vie sécurité documenté et l'autre sans, le choix se fait tout seul.
Commencez par trois questions :
- Nos produits sont-ils concernés ? (connectivité + marché UE + commercial)
- Quelle est notre classe de produit ? (Standard, Important I/II ou Critique)
- Qui est responsable de la conformité ? (quelqu'un doit coordonner l'ingénierie, le juridique et les opérations)
Des cadres comme le NIST CSF 2.0, l'ISO 27001 et NIS2 fournissent la structure. Le CRA fournit l'urgence spécifique aux produits. Votre connaissance de l'ingénierie fournit le contexte. Combinez les trois, et la conformité devient une fonctionnalité produit, pas un fardeau.