Combien de temps faut-il pour se mettre en conformité CRA ?

Plan réaliste 2025–2027 pour éditeurs, SaaS et fabricants

Le Cyber Resilience Act (CRA), adopté fin 2024, impose une transformation profonde aux éditeurs de logiciels, fabricants d’équipements numériques et fournisseurs SaaS.

Avec une entrée en application progressive jusqu’à décembre 2027, le CRA n’est pas un texte “administratif” : c’est un choc structurel pour tout le secteur numérique.

Mais la question que toutes les entreprises posent aujourd’hui est simple :

👉 Combien de temps faut-il réellement pour devenir conforme CRA ?

👉 Et comment planifier un projet sans bloquer le développement produit ?

Les premiers retours d’experts européens (ENISA, Commission UE, cabinets GRC en 2024-2025) convergent :

une mise en conformité CRA réaliste demande 12 à 24 mois, selon la taille du produit, la maturité sécurité et le modèle organisationnel.

Voici le plan 2025–2027 le plus pragmatique pour réussir votre conformité CRA à temps — sans arrêter votre roadmap produit.

🔍 Pourquoi le CRA demande du temps ?

Selon la Commission européenne, les obligations du CRA incluent :

1. ✔️ la gestion continue des vulnérabilités,
2. ✔️ le “security-by-design” & “secure-by-default”,
3. ✔️ la documentation technique complète,
4. ✔️ des preuves d’essais de sécurité,
5. ✔️ des déclarations de conformité,
6. ✔️ une organisation interne capable de gérer incidents et mises à jour sur tout le cycle de vie.

C’est plus proche d’une certification produit que d’un simple audit.

D’où l’importance d’une roadmap sur plusieurs trimestres, et non d’un projet ponctuel.

📅 Roadmap CRA réaliste 2025–2027

🟦 Phase 1 — 0 à 3 mois : cadrage & diagnostic

Objectif : savoir où vous en êtes et quel niveau d’obligation s’applique.

🎯 Actions clés :

1. Identifier la classe du produit (I ou II) selon la typologie CRA.
2. 👉 Les produits Classe II nécessitent des tests plus poussés + surveillance renforcée.
3. Réaliser un gap analysis CRA (technique, documentation, organisation).
4. Cartographier les composants logiciels, dépendances et chaînes de sous-traitance.
5. Évaluer les pratiques actuelles : dev, CI/CD, sécurité, patching, reporting vulnérabilités.

⏱️ Durée : 4 à 8 semaines.

💡 80 % des éditeurs découvrent, à ce stade, que leur documentation produit n’est pas suffisante pour CRA. (Source : analyses préliminaires CRA, 2024)

🟩 Phase 2 — 3 à 9 mois : mise à niveau sécurité & documentation

Objectif : aligner le produit avec les exigences CRA.

🎯 Axes de travail :

1. Implémenter ou renforcer le secure-by-design (revue d’architecture, menaces, durcissement).
2. Mettre en place une gestion de vulnérabilités CRA-compliant :
3. surveillance,
4. analyse de criticité,
5. correctifs dans les délais imposés,
6. communication aux clients.
7. Construire ou mettre à jour :
8. le SBOM (Software Bill of Materials),
9. le Technical Documentation Package,
10. les procédures internes (Alerting, Patching, Secure Dev, Incident CRA).

⏱️ Durée : 6 mois en moyenne.

💡 ENISA rappelle que 44 % des logiciels étudiés en 2024 incluaient des composants tiers non inventoriés, incompatible avec CRA.

🟧 Phase 3 — 9 à 15 mois : tests de sécurité & preuves

Objectif : valider et prouver la robustesse du produit.

🎯 Obligations principales :

1. Réaliser des tests de sécurité documentés (pentest, fuzzing, tests fonctionnels sécurité).
2. Vérifier la conformité des dépendances open-source (licence + vulnérabilités).
3. Générer les preuves officielles CRA :
4. résultats de tests,
5. logs d’exploitation,
6. preuves de correction,
7. traçabilité des mises à jour.

⏱️ Durée : 3 à 6 mois.

💡 Les pénalités CRA peuvent atteindre 15 millions € pour les produits non conformes.

(Source : Règlement Cyber Resilience Act, 2024)

🟥 Phase 4 — 15 à 24 mois : gouvernance continue & conformité opérationnelle

Objectif : passer d’un projet ponctuel à un système de gestion durable.

🎯 À industrialiser :

1. Mise à jour continue de la documentation CRA.
2. Surveillance vulnérabilités (CVE, KEV, SBOM).
3. Maintenance de sécurité et “lifetime security support”.
4. Processus d’alerting et reporting incident (y compris notification aux autorités).

⏱️ Durée : continue — cadence trimestrielle conseillée.

💡 Le CRA impose une notification sous 24h des vulnérabilités activement exploitées.

🧩 Pourquoi viser 12–24 mois ?

Les retours d’expérience montrent qu’un projet CRA touche :

1. le code,
2. l’architecture,
3. les dépendances,
4. la chaîne de build,
5. les process internes,
6. la documentation,
7. et la gouvernance.

Une PME éditeur de SaaS avec 1 à 2 produits met en moyenne :

1. 12–15 mois si elle est déjà mature (ISO 27001, DevSecOps)
2. 18–24 mois sinon

Dans tous les cas, démarrer en 2025 permet d’être prêt avant les audits 2027-2028.

🏁 Conclusion : la conformité CRA se prépare dès maintenant

Le CRA n’est pas un texte à “appliquer en 3 mois”. C’est une transformation structurelle du cycle de vie de vos logiciels.

Un plan réaliste demande :

1. 3 mois pour diagnostiquer,
2. 6 à 9 mois pour aligner design + sécurité + doc,
3. 3 à 6 mois de tests,
4. puis un pilotage continu.

Le plus grand risque en 2025 n’est pas la non-conformité…

👉 c’est de commencer trop tard.