Le Cyber Resilience Act (CRA) est probablement le règlement européen le plus impactant pour les éditeurs de logiciels en 2026-2027. Son périmètre est large : tout produit comportant des éléments numériques mis sur le marché européen. Les sanctions à l'arrivée sont sévères : plus de marquage CE = plus de mise sur le marché, ce qui inclut les mises à jour des produits déjà déployés.
Voici la roadmap pratique pour aborder les deux jalons clés.
Êtes-vous concerné ?
Très probablement oui, sauf exceptions très spécifiques :
- Inclus : SaaS B2B, applications mobiles commerciales, IoT, firmware, librairies redistribuées, drivers, plugins commerciaux.
- Exclus partiels : open source non commercialisé (mais attention aux nouvelles obligations spécifiques aux contributeurs payés et aux "open source stewards").
- Exclus : services purs sans composant logiciel embarqué (ce qui est rare).
Si vous facturez un logiciel directement ou indirectement, vous êtes très probablement dans le périmètre.
Jalon 1 — 11 septembre 2026 : signalement actif
À cette date, vous devez être capables de :
Signalement à l'ENISA et au CSIRT national
- Vulnérabilités activement exploitées : signalement à l'ENISA dans les 24 heures de la connaissance.
- Incidents critiques : signalement dans les 24 heures (early warning) puis 72 heures (notification complète) puis 14 jours (rapport final).
Capacité opérationnelle requise
- Un canal de réception des signalements de vulnérabilités (security@yourdomain, ou mieux : security.txt sur votre site).
- Un processus de triage avec SLO documenté : combien de temps entre réception et triage ? entre triage et patch ?
- Un canal de communication d'urgence avec l'ENISA et votre CSIRT national (en France : CERT-FR / ANSSI).
- Un plan de communication client en cas d'incident critique.
Ce qu'il faut avoir en place avant septembre 2026
- Inventaire complet de vos produits dans le périmètre CRA.
- Process de gestion de vulnérabilité documenté, avec rôles et responsabilités.
- Bug bounty ou VDP (Vulnerability Disclosure Program) — au minimum un canal de réception.
- Runbook d'incident intégrant les délais ENISA. Voir Gérer un incident cyber en 7 étapes.
- Templates de communication pré-rédigés (clients, autorités, médias).
Jalon 2 — 11 décembre 2027 : application complète
À cette date, plus de marquage CE conforme = plus de mise sur le marché européen, y compris pour les mises à jour de produits déjà déployés. C'est le verrou commercial.
Exigences techniques essentielles (Annexe I, partie 1)
Le produit doit être conçu de manière à :
- Avoir une protection appropriée au risque (par défaut sécurisé, configuration par défaut sécurisée).
- Protéger contre les accès non autorisés.
- Protéger la confidentialité des données traitées.
- Protéger l'intégrité du code, configurations, données.
- Limiter les surfaces d'attaque (interfaces, services, ports).
- Permettre l'observabilité (logs).
- Permettre les correctifs sécurité en temps voulu.
Obligations sur le cycle de vie (Annexe I, partie 2)
- Identifier et documenter les vulnérabilités sur la durée de vie du produit (au moins 5 ans).
- Maintenir un SBOM (Software Bill of Materials).
- Fournir des correctifs gratuits et en temps voulu.
- Information transparente sur les vulnérabilités traitées.
Documentation technique
Dossier complet pour démontrer la conformité :
- Description du produit, périmètre, classes de risque.
- Cybersécurité by design, choix d'architecture, contrôles.
- SBOM à jour.
- Procédures de gestion des vulnérabilités.
- Tests effectués, résultats.
- Marquage CE et déclaration de conformité UE.
La feuille de route réaliste sur 18 mois
Mai-Juin 2026 : Diagnostic
- Cartographie des produits dans le périmètre CRA.
- Audit sécurité existant : où sont les écarts ?
- SBOM initial sur le produit principal.
- Désignation d'un référent CRA en interne.
Juillet-Août 2026 : Outillage
- Mise en place du canal de signalement (security.txt + email + bug bounty).
- Process incident enrichi pour les délais ENISA.
- Templates de communication.
Septembre 2026 — DEADLINE 1
- Capacité de signalement opérationnelle.
- Premier exercice de table-top avec scenario CRA.
Octobre 2026 — Mars 2027 : Industrialisation
- Sécurisation pipeline CI/CD (DevSecOps quality gates).
- SBOM automatisé sur toutes les builds.
- Réduction du MTTR vulnérabilités (objectif Critical < 7 jours).
- Documentation technique complète.
Avril 2027 — Septembre 2027 : Pre-audit
- Pre-audit interne ou externe pour vérifier la conformité.
- Closing des gaps identifiés.
- Formation des équipes.
Octobre 2027 — Novembre 2027 : Audit officiel
- Pour les produits "important" et "critical" classes : audit par organisme notifié.
- Pour les autres : auto-évaluation documentée.
Décembre 2027 — DEADLINE 2
- Marquage CE en place sur les produits.
- Documentation auditable maintenue à jour.
Les pièges à éviter
"On verra ça plus tard"
12 mois pour bâtir l'opérationnel, ce n'est pas long. Les organismes notifiés vont être saturés en 2027.
"On délègue à un cabinet juridique"
Le CRA est techniquement contraignant. Un cabinet juridique seul ne peut pas vous mettre en conformité. Il faut un duo juridique + technique. Pour la partie technique opérationnelle, c'est très précisément le périmètre des offres WeeSec.
"On a déjà ISO 27001, c'est pareil"
ISO 27001 est un système de management de la sécurité de l'information. CRA porte sur les caractéristiques techniques du produit lui-même. Complémentaire mais différent. Une ISO 27001 vous facilite le CRA d'environ 30-40%, pas plus.
"Le SBOM, on a un script"
Un SBOM CRA-compliant doit être : automatique, à jour à chaque build, exportable au format SPDX ou CycloneDX, traçable sur la chaîne de production. Un script bash qui liste vos node_modules ne suffit pas.
Recoupement avec l'AI Act et NIS2
Pour les produits IA, le CRA s'ajoute à l'AI Act. Pour les services entrant dans NIS2, double-conformité aussi. Une approche commune (système de management de la sécurité) couvre 70-80% des deux. Les 20-30% restants sont spécifiques.
