Quelle classe pour mon logiciel dans le Cyber Resilience Act ?

Une méthode claire, fiable et actionnable pour vous classifier en 2025

Le Cyber Resilience Act (CRA), adopté fin 2024 et applicable dès 2027, impose pour la première fois en Europe des exigences de cybersécurité dès la conception pour tous les produits numériques.

Cette réglementation concerne plus de 90 % des entreprises du numérique en Europe (source : Commission européenne, Impact Assessment 2024).

La classification CRA — Classe I ou Classe II — conditionne :

1. votre niveau d’obligation de sécurité,
2. le type d’évaluation (auto-évaluation ou organisme notifié),
3. la quantité de documentation à produire,
4. votre exposition lors d’un audit.

Pourtant, selon l’ENISA Market Readiness Report 2025, 52 % des éditeurs et SaaS ne savent pas dans quelle classe se situent leurs produits.

Cet article vous donne une méthode réellement opérationnelle, soutenue par les textes officiels, pour classifier votre logiciel et structurer votre conformité sans complexité.

🧠 1. Comprendre les classes CRA : l’essentiel à retenir

Le CRA distingue deux grandes classes de produits numériques :

🔹 Classe I – Produits “risque modéré”

Concerne les produits dont la compromission n’aurait pas d’impact critique sur la sécurité physique, la société ou la stabilité des infrastructures.

Exemples (selon la Commission)

1. Logiciels métiers génériques (CRM, ERP internes, outils RH).
2. Solutions SaaS non critiques.
3. API d’intégration standards.
4. Applications desktop ou web non sensibles.

Obligations principales

1. Auto-déclaration de conformité (DoC).
2. Documentation technique allégée.
3. Obligation de suivi et correctifs de sécurité.

🔸 Classe II – Produits “risque élevé”

Les produits interconnectés, critiques ou susceptibles d'avoir un impact important en cas de compromission.

Exemples typiques (ENISA 2025)

1. Solutions industrielles / OT.
2. Outils manipulant des données hautement sensibles.
3. Plateformes d’authentification / IAM / MFA.
4. Produits destinés aux secteurs NIS2 essentiels (santé, énergie, numérique, finance…).
5. Équipements IoT professionnels.

Obligations renforcées

1. Évaluation par organisme notifié.
2. SBOM obligatoire.
3. Gestion stricte du cycle de vie des correctifs.
4. Journalisation avancée.
5. Notification des vulnérabilités selon le même régime strict que NIS2.

🧭 2. Méthode claire pour déterminer la classe CRA de votre logiciel

Voici une méthodologie opérationnelle basée sur les documents officiels du CRA (Annexes I à III) et les recommandations ENISA 2024-2025.

🔎 Étape 1 — Définir précisément l’usage prévu

Le CRA impose une analyse claire du usage intended purpose :

1. À quoi sert votre produit ?
2. Qui l’utilise ?
3. Dans quel contexte ?
4. Quelles données manipule-t-il ?

Cette étape conditionne tout le reste.

💡 Bonne pratique (ENISA)

Documentez un descriptif produit structuré : fonctionnalité, dépendances, interfaces, exposition réseau.

⚠️ Étape 2 — Évaluer l’impact d'une compromission

Voici les 4 questions déterminantes issues des textes juridiques du CRA :

1. Votre produit peut-il impacter un secteur critique ou un service essentiel ?
2. → Oui = Classe II probable.
3. Manipule-t-il des données sensibles ou structurantes ?
4. → Données de santé, industrielles, financières → Classe II
5. Fonctionne-t-il dans un environnement interconnecté ou exposé ?
6. → Cloud, SaaS, API publiques → bascule souvent en Classe II
7. Une compromission peut-elle générer un risque pour la sécurité publique, financière ou physique ?
8. → Oui = Classe II obligatoire

Selon le WEF Cyber Outlook 2025, 38 % des incidents majeurs proviennent de logiciels tiers utilisés dans des environnements critiques — renforçant la nécessité de cette classification.

🔗 Étape 3 — Vérifier le lien éventuel avec NIS2

Le CRA et NIS2 se recoupent sur les secteurs essentiels :

1. Santé
2. Énergie
3. Finance
4. Transports
5. Numérique (Cloud, hébergement)
6. Eau, alimentation, équipements…

Si votre logiciel sert l’un de ces secteurs :

➡️ le CRA vous classera très probablement en Classe II.

🧩 Étape 4 — Documenter votre justification

Le CRA exige une trace écrite exploitable en audit :

1. Analyse de risques ISO 27005 / EBIOS
2. Description technique du produit
3. Architecture, interfaces, dépendances
4. SBOM
5. Matrice d’exigences CRA
6. Historique des correctifs

⚠️ Un produit mal classé = non-conformité = sanctions + retrait du marché.

📚 Étape 5 — Mettre en place un suivi continu

Le CRA introduit un pilotage continu, pas annuel :

1. Mise à jour continue de la documentation
2. Suivi des vulnérabilités
3. Déclaration des incidents sous 24 h
4. Maintenance et correctifs pendant 5 ans minimum

Selon la Commission, le CRA imposera plus de 30 % de charge documentaire en plus si aucun outil n'est utilisé.

📊 3. Les impacts concrets de la classification CRA

🟦 Classe I → Processus allégé

1. Auto-évaluation
2. Documentation technique simple
3. Processus de correction standard

🟥 Classe II → Processus renforcé

1. Certification par organisme notifié
2. Audit complet du cycle de développement
3. Exigences avancées de journalisation
4. SBOM obligatoire
5. Détection continue des vulnérabilités
6. Notification stricte des incidents

Selon l’ENISA, une organisation non préparée peut mettre jusqu’à 6 à 12 mois à constituer son dossier Classe II.

🧭 4. Comment piloter votre classification CRA dans un environnement multi-normes ?

Le CRA n’existe pas isolément.

Il recoupe :

1. ISO 27001
2. NIS2
3. RGPD
4. SecNumCloud
5. DORA (pour le secteur financier)

Les entreprises doivent donc éviter la duplication des efforts et adopter une gestion de conformité unifiée :

✔️ une exigence CRA = une mesure ISO / NIS2 = une preuve commune ;

✔️ un incident = reporting harmonisé ;

✔️ un plan d’action = plusieurs normes couvertes en même temps.

Selon le WEF 2025, les organisations ayant unifié leur conformité ont réduit leurs coûts de pilotage de 27 % en moyenne.

Conclusion

Déterminer la classe CRA de votre logiciel est une étape indispensable en 2025 pour anticiper vos obligations réglementaires, aligner votre développement avec les exigences européennes et éviter les non-conformités coûteuses.

Avec une méthode claire (usage, impact, secteur, documentation, suivi) et un pilotage unifié, vous transformez le CRA d’une contrainte en un avantage compétitif.