Qu'est-ce que le Cyber Resilience Act ?
Le CRA (règlement (UE) 2024/2847) est un texte horizontal qui couvre tous les produits comportant des éléments numériques mis à disposition sur le marché de l'Union et destinés à se connecter, directement ou indirectement, à un appareil ou à un réseau : produits physiques (routeurs, caméras IP, thermostats connectés) comme logiciels purs (applications mobiles, plugins, bibliothèques, systèmes d'exploitation). C'est la première réglementation européenne qui s'applique à la sécurité du code pendant tout le cycle de vie d'un produit.
Ce n'est pas une directive que chaque État transpose à sa manière : c'est un règlement, d'application directe et uniforme dans les 27 États membres. Il est applicable à partir du 11 décembre 2027, avec deux marches anticipées : les dispositions sur les organismes d'évaluation de la conformité (chapitre IV) depuis le 11 juin 2026, et l'obligation de signalement de l'article 14 depuis le 11 septembre 2026.
Trois niveaux de produits, trois niveaux d'évaluation :
- Produits par défaut : la grande majorité des logiciels et objets connectés. Le fabricant démontre la conformité par contrôle interne (module A, auto-évaluation).
- Produits importants (annexe III), en deux classes. Classe I : systèmes de gestion des identités, navigateurs, gestionnaires de mots de passe, antimalwares, produits VPN, SIEM, gestionnaires de démarrage, systèmes d'exploitation, routeurs et commutateurs, entre autres. L'auto-évaluation n'y reste possible que si le fabricant applique intégralement une norme harmonisée, une spécification commune ou un schéma de certification ; sinon, un organisme notifié intervient. Classe II : hyperviseurs et environnements d'exécution de conteneurs, pare-feux et systèmes de détection ou de prévention d'intrusion, microprocesseurs et microcontrôleurs résistants aux manipulations. L'intervention d'un organisme notifié (examen UE de type ou assurance qualité complète) ou une certification européenne y est obligatoire.
- Produits critiques (annexe IV) : boîtiers matériels de sécurité, passerelles de compteurs intelligents, cartes à puce et éléments sécurisés. Ils relèvent d'un schéma européen de certification de cybersécurité lorsqu'il est imposé, à défaut des procédures de la classe II.
Ce que le CRA oblige concrètement
- Conception sécurisée dès l'origine (security by design) : les risques de cybersécurité sont évalués dès la conception et documentés, pas traités en correctif après le lancement.
- Configuration sécurisée par défaut : le produit est livré dans un état sûr, sans identifiants par défaut laissés en place, avec la possibilité de revenir à l'état d'origine. Pour un produit sur mesure, le fabricant et son client professionnel peuvent convenir d'une autre configuration.
- Absence de vulnérabilité exploitable connue à la mise sur le marché : les dépendances sont à jour, auditées et corrigeables par des mises à jour de sécurité.
- Gestion des vulnérabilités pendant la période d'assistance, d'au moins cinq ans sauf durée d'utilisation prévue plus courte : correctifs diffusés sans retard et gratuitement, publiés si possible séparément des nouvelles fonctionnalités, et chaque mise à jour de sécurité reste disponible au moins dix ans.
- Nomenclature logicielle (SBOM) pour tous les produits, dans un format courant et lisible par machine, couvrant au moins les dépendances de premier niveau. Elle figure dans la documentation technique ; le règlement n'impose pas de la publier.
- Politique de divulgation coordonnée des vulnérabilités, avec une adresse de contact pour les signalements de tiers, et une information des utilisateurs sur les failles corrigées.
- Signalement de toute vulnérabilité activement exploitée et de tout incident grave, via la plateforme unique de signalement, sous 24 heures (alerte précoce) puis 72 heures (notification), depuis le 11 septembre 2026.
- Marquage CE : à partir du 11 décembre 2027, les produits couverts portent le marquage CE au titre du CRA, accompagné d'une déclaration UE de conformité.
Votre agence est-elle concernée ?
Le CRA s'applique si vous mettez un produit à disposition sur le marché de l'UE dans le cadre d'une activité commerciale — ce qui couvre bien plus que la vente directe :
- Vous éditez un logiciel commercial (application mobile, logiciel installable, application de bureau) distribué à des entreprises ou des particuliers européens : oui, vous êtes fabricant.
- Vous distribuez des plugins ou extensions sur des places de marché (WordPress.org, Shopify App Store, extensions Chrome/Firefox) et vous les monétisez : oui.
- Vous développez sur commande un produit que votre client mettra sur le marché sous sa marque : c'est votre client qui est fabricant. Il doit faire preuve de diligence raisonnable sur les composants tiers qu'il intègre (article 13, paragraphe 5), et il vous demandera donc des garanties : SBOM, correctifs, politique de divulgation. Si vous vendez vous-même un composant logiciel en tant que produit distinct, ce composant est un produit au sens du CRA et vous en êtes le fabricant.
- Vous intégrez des bibliothèques open source : vous restez responsable de la sécurité de l'ensemble. Lorsque vous découvrez une faille dans un composant, vous devez la signaler à son mainteneur et y remédier dans votre produit.
- Vous exploitez un SaaS ou un site web : le CRA ne couvre un service en ligne que s'il constitue la solution de traitement de données à distance d'un produit (par exemple l'application en nuage qui pilote un objet connecté). Un site ou un SaaS autonome relève plutôt de NIS2 et du RGPD.
- Vous faites de la R&D, des prototypes non distribués ou du conseil pur : hors champ direct du CRA.
Les logiciels libres et ouverts qui ne sont pas monétisés par leur fabricant ne sont pas considérés comme fournis dans le cadre d'une activité commerciale et sortent du champ. Les fondations et entités qui soutiennent durablement un projet open source destiné à un usage commercial relèvent d'un régime allégé, celui des intendants de logiciels ouverts (article 24), dont les obligations de signalement ne s'appliquent qu'à partir du 11 décembre 2027. Attention : dès que votre agence monétise un plugin open source qu'elle publie, le raisonnement change, et la question se tranche au cas par cas.
Les sanctions et leur logique
L'article 64 du CRA fixe trois plafonds d'amende administrative, le montant le plus élevé des deux étant retenu :
1. Non-respect des exigences essentielles de l'annexe I et des obligations des articles 13 et 14 (conception sécurisée, gestion des vulnérabilités, signalement) : jusqu'à 15 000 000 € ou 2,5 % du chiffre d'affaires annuel mondial.
2. Non-respect des autres obligations des opérateurs (importateurs, distributeurs, mandataires, marquage CE, déclaration de conformité, procédures d'évaluation) : jusqu'à 10 000 000 € ou 2 %.
3. Informations inexactes, incomplètes ou trompeuses fournies aux organismes notifiés ou aux autorités de surveillance du marché : jusqu'à 5 000 000 € ou 1 %.
Un retard ou une omission de signalement tombe donc dans le palier le plus élevé, pas dans le deuxième. Deux exceptions sont prévues : les micro et petites entreprises ne sont pas sanctionnées pour le seul dépassement du délai de 24 heures de l'alerte précoce, et les intendants de logiciels ouverts échappent aux amendes.
Les sanctions sont prononcées par les autorités de surveillance du marché que chaque État membre désigne, qui tiennent compte de la nature et de la durée de l'infraction comme de la taille de l'entreprise. Les CSIRT nationaux et l'ENISA reçoivent les signalements. Le cadre ressemble à celui du RGPD : l'autorité module la sanction, mais la non-conformité constatée suffit à la rendre possible.
Signaler une vulnérabilité exploitée : ce qui s'applique depuis le 11 septembre 2026
L'article 14 est la première obligation opérationnelle du CRA, et elle vise aussi les produits déjà sur le marché avant le 11 décembre 2027 (article 69, paragraphe 3). Dès que vous avez connaissance d'une vulnérabilité activement exploitée dans un de vos produits, vous la notifiez simultanément au CSIRT coordinateur de l'État membre de votre établissement principal et à l'ENISA, via la plateforme unique de signalement mise en place par l'ENISA et opérationnelle depuis le 11 septembre 2026. Un seul dépôt suffit : le CSIRT transmet ensuite aux CSIRT des autres pays où le produit est distribué.
Le signalement se fait en trois temps :
- Alerte précoce sous 24 heures, en indiquant si possible les États membres où le produit est distribué. Elle part même si aucun correctif n'existe encore.
- Notification sous 72 heures : informations générales sur le produit, nature de l'exploitation et de la faille, mesures correctives déjà prises et mesures que les utilisateurs peuvent appliquer, degré de sensibilité des informations.
- Rapport final au plus tard 14 jours après la mise à disposition d'un correctif : description et gravité de la faille, informations sur l'acteur malveillant le cas échéant, détail de la mise à jour de sécurité.
Un incident grave affectant la sécurité du produit suit le même schéma 24 h / 72 h, avec un rapport final dans le mois qui suit la notification. Le CSIRT peut aussi demander un rapport intermédiaire. Dans tous les cas, vous informez les utilisateurs touchés et les mesures qu'ils peuvent prendre, si possible dans un format structuré et lisible par machine.
Pour la mise en pratique, la Commission européenne a publié le 27 juillet 2026 des orientations sur l'application du CRA, et elle tient une page dédiée aux obligations de signalement. Lisez-les avant de rédiger vos propres modèles.
Préparer votre agence avant décembre 2027
Étape 1 — Cartographier vos produits et leur classification
Dressez l'inventaire de tous les produits que vous mettez sur le marché de l'UE (applications, plugins, composants vendus à des tiers) et, séparément, de ceux que vous développez pour des clients qui les commercialisent. Pour chacun, déterminez :
- Produit par défaut, produit important de classe I ou II, ou produit critique ?
- Qui est le fabricant au sens du CRA : vous, ou votre client ?
- Modèle de distribution : vente directe, place de marché, open source monétisé ou non ?
- Durée d'utilisation prévue, qui fixe votre période d'assistance (au moins cinq ans dans la plupart des cas).La classification détermine la procédure d'évaluation : contrôle interne ou organisme notifié.
Étape 2 — Générer et maintenir une SBOM
La SBOM (Software Bill of Materials) recense les composants logiciels du produit : bibliothèques tierces, dépendances directes et transitives, versions et licences. Le CRA l'exige pour tous les produits, au moins pour les dépendances de premier niveau, dans un format lisible par machine comme SPDX ou CycloneDX. Générez-la à chaque build plutôt qu'une fois par an.
# Syft — génère une SBOM CycloneDX ou SPDX à partir d'un dossier ou d'une image curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin syft dir:/chemin/vers/votre/projet -o cyclonedx-json > sbom.json # Trivy — recherche des vulnérabilités connues à partir de la SBOM trivy sbom sbom.json # cdxgen — SBOM pour projets Node.js, Python, PHP, Go cdxgen -t php -o sbom-php.json /chemin/vers/projetÉtape 3 — Mettre en place la gestion des vulnérabilités
Le CRA impose un processus actif pendant toute la période d'assistance. Concrètement :
1. Surveillance des CVE : alertes sur vos dépendances (GitHub Dependabot, npm audit, Composer audit, Trivy en CI/CD), complétées par les flux NVD et CERT-EU et par les avis de sécurité des éditeurs que vous intégrez.
2. Politique de divulgation coordonnée : publiez un fichiersecurity.txtà la racine devotre-domaine.comet unSECURITY.mddans chaque dépôt, avec une adresse de contact et un engagement de délai de traitement.
3. Processus de correction : définissez un SLA interne (par exemple : vulnérabilité CVSS ≥ 9 → correctif sous 7 jours) et publiez les correctifs de sécurité à part des nouvelles fonctionnalités quand c'est possible.
4. Information des utilisateurs : à chaque correctif, un avis décrit la faille corrigée, sa gravité et les versions concernées.Étape 4 — Organiser le circuit de signalement et préparer les modèles
Le délai de 24 heures ne laisse pas le temps de découvrir la procédure. Désignez qui qualifie une vulnérabilité comme « activement exploitée », qui valide l'envoi, qui rédige et qui dépose sur la plateforme unique de signalement, avec un suppléant pour chaque rôle.
Préparez à l'avance un modèle par étape : alerte précoce (produit, versions, pays de distribution, premiers éléments), notification à 72 heures (nature de l'exploitation, mesures d'atténuation pour les utilisateurs) et rapport final (gravité, cause, correctif). Faites-les relire par votre conseil juridique, puis testez le circuit par un exercice à blanc.
Étape 5 — Documenter la conformité
La documentation technique comprend :
- La description du produit et de son architecture de sécurité.
- L'évaluation des risques de cybersécurité (threat modeling).
- Les mesures de sécurité implémentées et les tests réalisés.
- La politique de gestion et de divulgation des vulnérabilités.
- La SBOM.
- Les instructions d'utilisation sécurisée et la durée de la période d'assistance.Elle est conservée, avec la déclaration UE de conformité, au moins dix ans après la mise sur le marché du produit, ou pendant toute la période d'assistance si celle-ci est plus longue.
Étape 6 — Revoir les contrats et la documentation livrée
Pour chaque client, écrivez noir sur blanc qui est fabricant au sens du CRA et qui assure quoi pendant la période d'assistance : veille sur les dépendances, délais de correction, transmission de la SBOM, participation au signalement. Un contrat de maintenance muet sur ces points laisse votre client seul face à l'article 14, et vous exposé à ses recours.
La documentation livrée doit inclure un guide de configuration sécurisée, la procédure de signalement destinée aux utilisateurs et la date de fin de la période d'assistance.
Étape 7 — Évaluer la nécessité d'un audit tiers
Pour les produits de classe II et pour les produits de classe I évalués sans norme harmonisée appliquée intégralement, un organisme notifié est obligatoire. Les règles de notification de ces organismes s'appliquent depuis le 11 juin 2026 : identifiez tôt ceux qui couvrent votre catégorie, car leur capacité sera demandée à l'approche de 2027.
Pour les produits par défaut, l'auto-évaluation suffit, à condition de conserver un dossier technique complet. Un audit volontaire peut renforcer votre crédibilité commerciale auprès des grandes entreprises clientes, qui exigeront une preuve de conformité CRA avant de signer.
L'impact sur votre infrastructure d'hébergement
Le CRA ne vise pas les services d'hébergement eux-mêmes : un service en nuage qui n'est pas conçu sous la responsabilité du fabricant d'un produit sort de son champ, et l'hébergement relève de NIS2 (voir ce que NIS2 impose à vos clients hébergés). Les deux textes se cumulent sans se confondre : autorités, délais et périmètres diffèrent, et une mesure prise pour l'un ne vaut pas automatiquement pour l'autre. Votre infrastructure reste pourtant impliquée dans votre conformité CRA sur quatre points :
1. Les composants que vous exploitez font partie du produit. Si votre application embarque PostgreSQL, Redis ou Nginx dans son image, ces composants entrent dans la surface d'attaque à documenter dans la SBOM et à surveiller pour les CVE.
2. Le pipeline CI/CD porte les contrôles. Vos workflows GitHub Actions, GitLab CI ou autres lancent systématiquement les scans de dépendances (npm audit, Composer audit, Trivy) et bloquent un déploiement en cas de vulnérabilité critique non résolue.
3. Détecter une exploitation suppose de surveiller. Le délai de 24 heures court à partir du moment où vous avez connaissance de l'exploitation : sans alertes sur les comportements anormaux et sur les CVE des composants en production, vous l'apprenez trop tard. Un outil comme CrowdSec sur vos serveurs y contribue.
4. La gestion des incidents exige de la traçabilité. Vos journaux doivent être assez détaillés et conservés assez longtemps pour établir quand et comment une faille a été exploitée : ce sont les éléments des notifications à 72 heures et du rapport final. Un serveur dont vous détenez l'accès root, où vous choisissez vos outils de journalisation et de détection, facilite cette collecte bien plus qu'un environnement mutualisé fermé.
CRA vs NIS2 vs RGPD — les trois réglementations clés
Faites défiler le tableau
| Texte | Périmètre | Qui est visé | Date d'application | Amende maximale |
|---|---|---|---|---|
| **CRA** (règlement 2024/2847) | Produits comportant des éléments numériques mis sur le marché de l'UE | Fabricants, importateurs et distributeurs de produits logiciels et matériels | 11 sept. 2026 (signalement) / 11 déc. 2027 (ensemble des exigences) | 15 M€ ou 2,5 % du CA mondial |
| **NIS2** (directive 2022/2555) | Entités des 18 secteurs des annexes I et II (énergie, santé, infrastructures numériques, cloud, hébergement…) | Entités essentielles et importantes, dont fournisseurs de cloud, de centres de données, de CDN, DNS et services gérés | 18 oct. 2024, via les lois nationales de transposition | Au moins 10 M€ ou 2 % (essentielles), 7 M€ ou 1,4 % (importantes) |
| **RGPD** (règlement 2016/679) | Traitement de données personnelles de personnes dans l'UE | Tout responsable de traitement ou sous-traitant | 25 mai 2018 | 20 M€ ou 4 % du CA mondial |
Outils SBOM gratuits à intégrer dans votre CI/CD
Générer automatiquement la SBOM à chaque build est la mesure la plus rentable pour préparer le CRA : elle sert à la fois la documentation technique et la veille sur les vulnérabilités. Trois outils open source à intégrer dès maintenant :
Syft (Anchore) — génère des SBOM aux formats SPDX et CycloneDX à partir d'un répertoire ou d'une image Docker :
# Installer
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
# Générer la SBOM du dépôt courant
syft dir:. -o cyclonedx-json > sbom.jsonTrivy (Aqua Security) — produit une SBOM CycloneDX d'une image Docker, puis y recherche les vulnérabilités :
trivy image --format cyclonedx --output sbom.cdx.json mon-app:latest
trivy sbom sbom.cdx.jsoncdxgen (projet CycloneDX) — spécialisé pour les projets Node.js, Python, PHP, Go, Java, Ruby :
npx @cyclonedx/cdxgen -t php -o sbom-php.json /mon-projetArchivez la SBOM avec l'artefact de chaque version livrée : en cas de faille, c'est elle qui dit en quelques minutes quelles versions de quel produit sont touchées.
Calendrier des obligations — la première marche est déjà franchie
Le CRA s'applique par étapes. Deux échéances intermédiaires précèdent le 11 décembre 2027, et la plus lourde pour une équipe technique, le signalement, court depuis le 11 septembre 2026.
L'erreur à ne pas commettre : considérer que rien ne presse avant 2027. Si une vulnérabilité de votre produit est exploitée aujourd'hui et que vous ne la signalez pas dans les délais, vous êtes déjà en infraction — y compris pour un produit mis sur le marché avant l'entrée en application des autres exigences.
Les échéances du CRA
Faites défiler le tableau
| Échéance | Ce qui s'applique | Ce que vous devez avoir |
|---|---|---|
| **10 déc. 2024** | Entrée en vigueur du règlement | Une première cartographie de vos produits |
| **11 juin 2026** | Règles sur les organismes d'évaluation de la conformité (chapitre IV) | Les organismes notifiés pertinents identifiés, pour les produits importants |
| **11 sept. 2026** | Signalement des vulnérabilités activement exploitées et des incidents graves (article 14), y compris pour les produits déjà sur le marché | Un circuit de signalement opérationnel et testé |
| **11 déc. 2027** | Pleine application : exigences essentielles, évaluation de la conformité, marquage CE | Dossier technique, SBOM, déclaration UE de conformité |
| **10 ans après la mise sur le marché**, ou fin de la période d'assistance si plus tardive | Conservation de la documentation technique et de la déclaration de conformité | Un archivage daté, par version de produit |
ServOrbit et votre conformité CRA
Nous proposons des VPS et des services d'hébergement qui constituent l'infrastructure sur laquelle vos produits tournent. Notre rôle dans votre conformité CRA est indirect mais concret :
- Isolation des environnements : nos VPS vous permettent de déployer des environnements séparés par client et par criticité, limitant la surface d'impact en cas de compromission.
- Sauvegardes : les snapshots à la demande de nos offres vous donnent une base de restauration documentable en cas d'incident, information utile pour les rapports de signalement. Pour une politique complète, combinez-les avec des sauvegardes Restic externalisées.
- Accès aux journaux : vous disposez d'un accès complet à votre VPS et configurez la journalisation au niveau de votre application, ce dont dépend la traçabilité des incidents.
- Localisation des données : nos VPS sont hébergés dans des centres de données en Europe, ce qui vous aide à documenter la localisation de votre infrastructure dans votre dossier de conformité.
Prochaines étapes
Le signalement est obligatoire depuis le 11 septembre 2026, et la pleine conformité est attendue le 11 décembre 2027. C'est court pour une agence qui n'a jamais formalisé ses pratiques de sécurité.
Dans les 30 jours :
1. Cartographier vos produits sur le marché de l'UE, identifier leur classification et qui en est fabricant.
2. Désigner les responsables du signalement, préparer les modèles et vous familiariser avec la plateforme unique de signalement.
3. Vérifier que vos dépôts ont un SECURITY.md, votre site un security.txt, et installer Syft ou Trivy dans votre pipeline CI/CD.
Dans les 6 mois :
4. Générer une SBOM pour chaque produit et chaque version livrée.
5. Formaliser votre processus de gestion des vulnérabilités (responsable, SLA, information des utilisateurs) et mettre à jour vos contrats de maintenance.
6. Pour les produits importants : contacter un organisme notifié pour planifier l'évaluation.
Avant le 11 décembre 2027 :
7. Finaliser le dossier technique, la déclaration UE de conformité et le marquage CE de chaque produit couvert.
