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 sur le marché de l'Union européenne, qu'ils soient physiques (routeurs, caméras IP, thermostats connectés) ou purement logiciels (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 tout au long du cycle de vie d'un produit.
Il ne s'agit pas d'une directive que chaque État transpose à sa manière : c'est un règlement, d'application directe et uniforme dans les 27 États membres. La date de pleine application est le 11 décembre 2027 — mais la première obligation critique, le signalement des vulnérabilités exploitées activement (à l'ENISA), s'applique dès le 11 septembre 2026.
Trois catégories de produits :
- Classe 1 (critique) : produits dont le compromis peut avoir un impact grave et étendu — systèmes d'exploitation, hyperviseurs, gestionnaires de mots de passe, navigateurs, pare-feux, VPN, SIEM, infrastructures cloud, logiciels industriels. Ils font l'objet d'un audit de conformité obligatoire par un organisme notifié.
- Classe 2 (très critique) : systèmes d'exploitation industriels, puces de sécurité, HSM, cartes à puce, lecteurs biométriques. Audit de certification obligatoire par un LSTI agréé.
- Par défaut : tout le reste. Conformité par auto-évaluation.
Ce que le CRA oblige concrètement
- Conception sécurisée dès l'origine (security by design) : prise en compte des risques de sécurité dès la phase de conception, pas en correctif post-lancement.
- Absence de vulnérabilités connues exploitables à la mise sur le marché : les dépendances doivent être à jour et auditées.
- Gestion des vulnérabilités tout au long du cycle de vie (minimum 5 ans) : publier des mises à jour de sécurité, les distribuer gratuitement, informer les utilisateurs.
- Signalement des incidents : une vulnérabilité activement exploitée doit être notifiée à l'ENISA dans les 24 heures (alerte précoce) et dans les 72 heures (rapport complet), à partir du 11 septembre 2026.
- Documentation technique : fournir des instructions d'utilisation sécurisée, une politique de divulgation des vulnérabilités et, pour les produits Classe 1/2, une SBOM (Software Bill of Materials — liste exhaustive des composants logiciels).
- Marquage CE : à partir de 2027, les produits couverts doivent porter le marquage CE de conformité CRA, démontrant l'auto-évaluation ou la certification tierce effectuée.
Votre agence est-elle concernée ?
Le CRA s'applique si vous mettez un produit à disposition sur le marché de l'UE — ce qui couvre bien plus que la simple vente directe :
- Vous développez des applications commerciales (SaaS, app mobile, logiciel en boîte) distribuées à des entreprises ou particuliers européens : oui.
- Vous distribuez des plugins ou extensions sur des marketplaces (WordPress.org, Shopify App Store, extensions Chrome/Firefox) : oui.
- Vous développez sur commande (sur mesure, sous marque blanche) un produit que votre client vendra : le fabricant (votre client) est responsable, mais vous êtes son fournisseur de composants — et le CRA impose des obligations aux fournisseurs de composants intégrés dans des produits couverts.
- Vous utilisez des bibliothèques open source dans votre produit : les composants intégrés dans un produit commercial doivent satisfaire aux exigences du CRA, même si la bibliothèque elle-même est gratuite.
- Vous faites de la R&D, des prototypes non distribués ou du conseil pur : hors champ direct du CRA.
Les logiciels distribués sous licence open source et sans modèle économique (sans support commercial, sans garantie) bénéficient d'une exemption explicite dans le règlement — mais attention : dès qu'une organisation livre un plugin open source et facture du support ou de l'intégration, l'exemption peut ne plus s'appliquer.
Les pénalités et leur logique
Le CRA introduit un régime de sanctions en trois paliers :
1. Infraction aux exigences essentielles (conception sécurisée, gestion des vulnérabilités) : jusqu'à 15 000 000 € ou 2,5 % du CA mondial annuel, le montant le plus élevé.
2. Infraction aux obligations de signalement (retard ou omission de notification à l'ENISA) : jusqu'à 10 000 000 € ou 2 % du CA mondial.
3. Fourniture d'informations inexactes ou trompeuses aux autorités : jusqu'à 5 000 000 € ou 1 % du CA mondial.
Les pénalités sont imposées par les autorités nationales de surveillance du marché (en France : l'ANSSI pour la cybersécurité, la DGCCRF pour la conformité marché). L'ENISA coordonne au niveau européen. Ce régime est similaire à celui du RGPD — les autorités peuvent décider du degré d'application, mais le cadre légal rend la sanction possible dès la non-conformité constatée.
Préparer votre agence avant décembre 2027
Étape 1 — Cartographier vos produits et leur classification
Dressez un inventaire de tous les produits que vous mettez sur le marché de l'UE (applications, plugins, composants livrés à des tiers). Pour chacun, déterminez :
- Classe par défaut, Classe 1 ou Classe 2 ?
- Audience : exclusivement professionnelle (B2B) ou grand public (B2C) ?
- Modèle de distribution : vente directe, marketplace, open source + support ?
La classification détermine le niveau d'audit requis (auto-évaluation vs organisme notifié).
Étape 2 — Générer et maintenir une SBOM
La SBOM (Software Bill of Materials) est la liste exhaustive de tous les composants logiciels — bibliothèques tierces, dépendances directes et transitives, licences. Pour les produits Classe 1/2, elle est obligatoire. Pour les produits par défaut, elle est fortement recommandée comme preuve de diligence.
Outils open source pour générer une SBOM :
# Syft — génère SBOM au format SPDX ou CycloneDX
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
synth packages /chemin/vers/votre/projet -o cyclonedx-json > sbom.json
# Trivy — audit des vulnérabilités à partir de la SBOM
trivy sbom sbom.json
# cdxgen — SBOM pour projets Node.js, Python, PHP, Go
cdxgen -t php /chemin/vers/projet -o sbom-php.jsonÉtape 3 — Mettre en place un processus de gestion des vulnérabilités
Le CRA impose de maintenir un processus actif pendant toute la durée de vie commerciale du produit (minimum 5 ans). Concrètement :
1. Surveillance des CVE : abonnez-vous aux alertes MITRE/NVD pour vos dépendances (GitHub Dependabot, npm audit, Composer audit, Trivy en CI/CD).
2. Politique de divulgation : publiez une page security.txt et un SECURITY.md dans chaque dépôt, avec un contact de signalement et un délai de traitement.
3. Processus de correction : définissez un SLA interne (ex. : vulnérabilité CVSS ≥ 9 → correctif sous 7 jours).
4. Canal de notification à l'ENISA : à partir du 11 septembre 2026, les vulnérabilités activement exploitées doivent être signalées via le portail ENISA dans les 24 h puis 72 h.
Étape 4 — Documenter la conformité
Le dossier technique de conformité doit comprendre :
- La description du produit et de son architecture de sécurité.
- L'analyse 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 des vulnérabilités.
- La SBOM (pour Classe 1/2, obligatoire).
- Les instructions d'utilisation sécurisée.
Ce dossier doit être conservé 10 ans après la mise sur le marché.
Étape 5 — Évaluer la nécessité d'un audit tiers
Pour les produits Classe 1 : audit obligatoire par un organisme notifié (liste sur le site de la Commission européenne une fois les accréditations établies).
Pour les produits par défaut : auto-évaluation suffisante, mais conservez le dossier technique complet. Un audit volontaire peut renforcer la crédibilité commerciale, notamment vis-à-vis de grandes entreprises clientes qui exigeront une preuve de conformité CRA avant 2027.
L'impact sur votre infrastructure d'hébergement
Le CRA ne s'applique pas directement aux services cloud qui hébergent vos applications (l'hébergement pur est couvert par NIS2, pas par le CRA). Cependant, votre infrastructure d'hébergement est directement impliquée dans votre conformité CRA sur trois points :
1. Les composants logiciels que vous hébergez font partie du produit. Si votre application utilise PostgreSQL, Redis ou Nginx, ces composants font partie de la surface d'attaque à documenter dans la SBOM et à surveiller pour les CVE.
2. Le pipeline CI/CD doit intégrer les audits de sécurité. Vos workflows GitHub Actions, GitLab CI ou autres doivent systématiquement lancer des scans de dépendances (npm audit, Composer audit, Trivy) et bloquer les déploiements en cas de vulnérabilités critiques non résolues.
3. La gestion des incidents nécessite une traçabilité. Votre infrastructure doit produire des logs suffisamment détaillés pour identifier qu'une vulnérabilité a été exploitée et dans quel délai elle a été détectée — information requise pour le rapport à l'ENISA.
CRA vs NIS2 vs RGPD — les trois réglementations clés
| Règlement | Périmètre | Qui est visé | Date d'application | Sanction max |
|---|---|---|---|---|
| **CRA** (2024/2847) | Produits à éléments numériques mis sur le marché UE | Fabricants, importateurs, distributeurs de produits logiciels/matériels | 11 déc. 2027 (obligations sécurité) / 11 sept. 2026 (signalement) | 15 M€ ou 2,5% CA |
| **NIS2** (2022/2555) | Services essentiels et importants (cloud, hébergement, énergie, finance, santé…) | Opérateurs essentiels et importants, fournisseurs de cloud/CDN/DNS | Oct. 2024 (en transposition dans les États membres) | 10 M€ ou 2% CA |
| **RGPD** (2016/679) | Traitement de données personnelles de personnes dans l'UE | Tout responsable de traitement ou sous-traitant | Mai 2018 | 20 M€ ou 4% CA |
Outils SBOM gratuits à intégrer dans votre CI/CD
La génération automatique de SBOM à chaque build est la mesure la plus rentable pour préparer le CRA. Trois outils open source à intégrer dès maintenant :
Syft (Anchore) — génère des SBOM aux formats SPDX 2.3 et CycloneDX 1.5 à partir de n'importe quel répertoire ou image Docker :
# Installer
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# Générer la SBOM
synth packages . -o cyclonedx-json > sbom.jsonTrivy (Aqua Security) — scanne les vulnérabilités à partir d'une SBOM CycloneDX ou d'une image Docker :
trivy image --format cyclonedx mon-app:latest | trivy sbom /dev/stdincdxgen — spécialisé pour les projets Node.js, Python, PHP, Go, Java, Ruby :
npx @cyclonedx/cdxgen -t php /mon-projet -o sbom-php.jsonCalendrier des obligations — ne ratez pas les deux premières marches
Le CRA a publié un calendrier progressif avec deux échéances intermédiaires importantes avant le 11 décembre 2027 :
| Échéance | Obligation |
|---|---|
| 10 déc. 2024 | Entrée en vigueur du règlement |
| 11 sept. 2026 | Obligation de signalement des vulnérabilités exploitées activement à l'ENISA (24h/72h) |
| 11 déc. 2027 | Pleine application : toutes les exigences essentielles, marquage CE, documentation |
| Jusqu'à 11 déc. 2035 | Dossier technique à conserver (10 ans après mise sur le marché) |
L'erreur à ne pas commettre : traiter la date du 11 septembre 2026 comme mineure. Si une vulnérabilité dans votre produit est exploitée activement après cette date et que vous ne l'avez pas signalée à l'ENISA dans les délais, vous êtes déjà en infraction — plus d'un an avant la pleine application du CRA.
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 automatisées : les snapshots quotidiens inclus dans nos offres vous fournissent une base de restauration documentable en cas d'incident, information utile pour les rapports ENISA.
- Accès aux logs : vous avez un accès complet à votre VPS et pouvez configurer la journalisation au niveau de votre application — une exigence implicite du CRA pour la traçabilité des incidents.
- Localisation des données : nos VPS sont localisés en Europe, ce qui vous aide à documenter la localisation de votre infrastructure dans votre dossier de conformité.
Prochaines étapes
Le CRA s'applique dans 16 mois pour les obligations de signalement et dans un peu plus de 28 mois pour la pleine conformité. C'est court pour une agence qui n'a jamais formalisé ses pratiques de sécurité.
À faire dans les 30 jours :
1. Cartographier vos produits sur le marché UE et identifier leur classification.
2. Vérifier que vos dépôts ont un SECURITY.md et une politique de divulgation.
3. Installer Syft ou Trivy dans votre pipeline CI/CD.
Dans les 6 mois :
4. Générer une SBOM initiale pour chaque produit.
5. Formaliser votre processus de gestion des vulnérabilités (responsable, SLA, canal de signalement).
6. Pour les produits Classe 1 : prendre contact avec un organisme notifié pour planifier l'audit.
Avant le 11 septembre 2026 :
7. Disposer d'un processus opérationnel de signalement à l'ENISA et l'avoir testé.
