---
name: "Auto-évaluation de conformité CRA"
version: "1.0"
updated: "2026-07-27"
source: "https://www.orbiqhq.com/fr/modeles/modele-auto-evaluation-conformite-cra"
license: "Utilisation et adaptation libres pour votre organisation. Attribution appréciée, non requise. Fourni en l'état, sans garantie ; ne constitue pas un conseil juridique."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2024/2847/oj"            # Cyber Resilience Act — art. 13, 14, 32, annexes I, III, IV, VII, VIII
  - "https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj"       # RE (UE) 2025/2392 — descriptions techniques des catégories de produits importants/critiques
---

# Auto-évaluation de conformité CRA (lisible par machine)

Objet : mener une évaluation de préparation au Cyber Resilience Act pour un produit comportant
des éléments numériques — champ d'application, classification (par défaut / important classe I /
important classe II / critique), la voie de conformité licite de l'article 32, les vérifications
exigence par exigence de l'annexe I, et la préparation de la documentation et de la notification
de l'article 14. Ce fichier est autonome : un agent peut classer un produit, dériver les voies de
conformité licites, générer les deux checklists de l'annexe I avec suivi de statut et produire un
rapport d'écarts à partir des définitions ci-dessous.

L'horloge du CRA (règlement (UE) 2024/2847) :
- `2024-12-10` — en vigueur.
- `2026-06-11` — le chapitre IV s'applique (les organismes notifiés peuvent être désignés).
- `2026-09-11` — les obligations de notification de l'article 14 s'appliquent, y compris pour les
  produits déjà mis sur le marché (plateforme unique de notification ; 24 h / 72 h / 14 j pour les
  vulnérabilités activement exploitées, 24 h / 72 h / 1 mois pour les incidents graves).
- `2027-12-11` — application intégrale : exigences essentielles de l'annexe I, documentation
  technique de l'annexe VII, déclaration UE de conformité, marquage CE.

Règles structurelles :
1. La classification précède tout : les voies de conformité licites sont une FONCTION de
   (classification, harmonised_standards_fully_applied, is_foss). Ne choisissez jamais un module
   en premier.
2. La classification suit la fonctionnalité PRINCIPALE (RE (UE) 2025/2392, adopté le 2025-11-28) :
   un produit intégrant un composant d'une catégorie des annexes III/IV n'est PAS classé par ce
   composant, sauf si la catégorie correspond au produit dans son ensemble. Consignez le
   raisonnement.
3. Chaque statut `not_applicable` sur une exigence du point (2) de l'annexe I partie I DOIT citer
   l'évaluation des risques de cybersécurité de l'article 13(2) comme justification — le point (2)
   s'applique « le cas échéant » sur la base de cette évaluation, pas par commodité.
4. Sanctions (art. 64) : violations de l'annexe I / art. 13 / art. 14 — jusqu'à 15 000 000 EUR ou
   2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu.

Notes juridictionnelles : Royaume-Uni — pas d'équivalent du CRA ; le régime PSTI (en vigueur le
2024-04-29) couvre les produits connectables grand public avec un socle plus étroit. Norvège/EEE —
le CRA est pertinent pour l'EEE et devrait être incorporé dans l'accord sur l'EEE ; les produits
mis sur le marché de l'UE sont dans le champ quel que soit le lieu d'établissement du fabricant.
France — l'ANFR est l'autorité de surveillance du marché pour le CRA, en coopération avec
l'ANSSI ; le CERT-FR (rattaché à l'ANSSI) reçoit les notifications de l'article 14 à partir du
2026-09-11. La loi française d'application est encore en projet en juillet 2026 ; le règlement
s'applique directement.

---

## 1. Test du champ d'application — les trois conditions doivent tenir, aucune exclusion

| # | Champ | Type | Règle |
|---|---|---|---|
| 1 | `is_product_with_digital_elements` | bool | Produit logiciel ou matériel et ses solutions de traitement de données à distance, avec une connexion de données directe ou indirecte prévue ou raisonnablement prévisible (art. 3(1)) |
| 2 | `placed_on_eu_market` | bool | Mis à disposition dans le cadre d'une activité commerciale — les produits gratuits monétisés autrement comptent |
| 3 | `sectoral_exclusion` | enum | `none` / `medical_devices_mdr_ivdr` / `civil_aviation` / `motor_vehicles` / `marine_equipment` / `national_security_defence` — toute valeur autre que `none` fait sortir du champ du CRA |
| 4 | `saas_note` | info | Le pur SaaS est hors champ, sauf s'il constitue une solution de traitement de données à distance d'un produit comportant des éléments numériques |

## 2. Classification

| Champ | Type | Règle |
|---|---|---|
| `class1_categories` | liste fixe (19) | identity_mgmt_and_pam, browsers, password_managers, malware_detection, vpn_products, network_management, siem, boot_managers, pki_certificate_issuance, network_interfaces, operating_systems, routers_modems_switches, microprocessors_security_functions, microcontrollers_security_functions, asics_fpgas_security_functions, smart_home_virtual_assistants, smart_home_security_devices, internet_connected_toys, personal_wearables_health |
| `class2_categories` | liste fixe (4) | hypervisors_container_runtimes, firewalls_ids_ips, tamper_resistant_microprocessors, tamper_resistant_microcontrollers |
| `critical_categories` | liste fixe (3) | hardware_security_boxes (HSM, terminaux de paiement), smart_meter_gateways, smartcards_secure_elements |
| `core_functionality_match` | texte | La catégorie retenue SI le produit DANS SON ENSEMBLE correspond à sa description technique du RE (UE) 2025/2392 ; les composants intégrés/accessoires ne classent pas le produit |
| `classification` | enum | `default` / `important_class_1` / `important_class_2` / `critical` — `default` en l'absence de correspondance de fonctionnalité principale |

## 3. Dérivation de la voie de conformité (art. 32)

```
inputs: classification, standards_fully_applied (bool), is_foss (bool)

default            -> [module_a, module_b_c, module_h, eucc]           # au choix du fabricant
important_class_1  -> standards_fully_applied or is_foss(public docs)
                      ? [module_a, module_b_c, module_h, eucc_substantial]
                      : [module_b_c, module_h, eucc_substantial]
important_class_2  -> is_foss(public docs)
                      ? [module_a, module_b_c, module_h, eucc_substantial]
                      : [module_b_c, module_h, eucc_substantial]
critical           -> schéma EUCC lorsqu'un acte délégué le rend obligatoire, sinon les voies de classe 2

notified_body_required = chosen_route in [module_b_c, module_h]
```

Mise en garde mi-2026 : les normes harmonisées CRA sont encore en développement (demande de
normalisation M/606, 41 normes, acceptée par le CEN/CENELEC/ETSI le 2025-04-03 ; projets
horizontaux prEN 40000-1-2 / -1-3 / -1-4). `standards_fully_applied = true` exige des citations au
JOUE — vérifiez avant de vous appuyer sur la voie d'auto-évaluation de la classe I.

## 4. Checklist annexe I partie I — 14 enregistrements

Champs par enregistrement : `ref`, `requirement`, `status` (enum : `compliant` / `partial` /
`gap` / `not_applicable`), `evidence`, `owner`, `notes` (justification REQUISE lorsque
`not_applicable`).

| ref | exigence (résumé) |
|---|---|
| 1 | Niveau de cybersécurité approprié au regard des risques (ancré dans l'évaluation des risques de l'art. 13(2)/(3)) |
| 2a | Aucune vulnérabilité exploitable connue au moment de la mise sur le marché |
| 2b | Configuration sécurisée par défaut, avec réinitialisation à l'état d'origine |
| 2c | Vulnérabilités corrigeables par mises à jour de sécurité ; mises à jour de sécurité automatiques avec option de désactivation par défaut, le cas échéant |
| 2d | Protection contre l'accès non autorisé (authentification, gestion des identités et des accès) ; signaler tout accès non autorisé possible |
| 2e | Confidentialité des données stockées/transmises/traitées (chiffrement à l'état de l'art au repos et en transit) |
| 2f | Intégrité des données, commandes, programmes, configuration contre toute manipulation non autorisée ; signaler les corruptions |
| 2g | Minimisation des données — seules les données adéquates, pertinentes et nécessaires sont traitées |
| 2h | Disponibilité des fonctions essentielles et de base, y compris résilience et atténuation face aux attaques par déni de service |
| 2i | Minimiser l'impact négatif sur la disponibilité des services d'autres appareils ou réseaux |
| 2j | Limiter les surfaces d'attaque, y compris les interfaces externes |
| 2k | Réduire l'impact des incidents par des mécanismes d'atténuation de l'exploitation |
| 2l | Informations liées à la sécurité par enregistrement/supervision de l'activité interne, avec option de désactivation pour l'utilisateur |
| 2m | Suppression sécurisée, facile et permanente de toutes les données et de tous les paramètres ; transfert sécurisé vers un autre produit le cas échéant |

## 5. Checklist annexe I partie II — 8 enregistrements

Mêmes champs que la partie I. `not_applicable` est rarement défendable en partie II (obligations
de processus).

| ref | exigence (résumé) |
|---|---|
| 1 | Identifier et documenter les vulnérabilités et les composants ; SBOM dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau |
| 2 | Traiter et corriger les vulnérabilités sans retard ; mises à jour de sécurité séparées des mises à jour fonctionnelles lorsque c'est techniquement faisable |
| 3 | Tests et revues de sécurité efficaces et réguliers |
| 4 | Divulgation publique des vulnérabilités corrigées dès que la mise à jour est disponible (description, impacts, gravité, informations de remédiation) |
| 5 | Politique de divulgation coordonnée des vulnérabilités (CVD) en place et appliquée |
| 6 | Faciliter le partage d'informations sur les vulnérabilités ; fournir une adresse de contact pour les signalements |
| 7 | Mécanismes de distribution sécurisée des mises à jour |
| 8 | Correctifs de sécurité diffusés sans retard et gratuitement, accompagnés de messages d'avis |

## 6. Préparation documentation et notification

| # | élément | règle |
|---|---|---|
| 1 | `technical_documentation` | Annexe VII : description du produit, informations de conception/développement/gestion des vulnérabilités, évaluation des risques, détermination de la période de support, normes appliquées, rapports de tests, déclaration UE de conformité (annexe V). Conserver ≥10 ans ou la période de support si elle est plus longue |
| 2 | `support_period` | Art. 13(8) : reflète la durée d'utilisation prévue, MINIMUM 5 ans sauf durée d'utilisation prévue plus courte ; date de fin annoncée à l'achat |
| 3 | `srp_access` | Enregistrement sur la plateforme unique de notification de l'ENISA + responsable interne avant le 2026-09-11 |
| 4 | `art14_process_vulns` | Alerte précoce sous 24 h / notification sous 72 h / rapport final sous 14 j pour les vulnérabilités activement exploitées |
| 5 | `art14_process_incidents` | 24 h / 72 h / 1 mois pour les incidents graves |
| 6 | `user_information` | Art. 14(8) : informer les utilisateurs impactés, le cas échéant dans un format structuré et lisible par machine — voir cra-vulnerability-advisory-template.md |
| 7 | `ce_marking` | Apposé conformément à l'art. 30 une fois la voie de conformité achevée ; obligatoire pour la mise sur le marché à partir du 2027-12-11 |

## Indications de workflow pour agents

- RAPPORT D'ÉCARTS : lister les enregistrements avec `status` dans {`gap`, `partial`}, triés par
  (partie I avant partie II, puis ref) ; joindre les attentes de `evidence` tirées du texte de
  l'exigence.
- VÉRIFICATION DE VOIE : recalculer la section 3 à chaque changement de `classification`,
  `standards_fully_applied` ou `is_foss` ; signaler si la voie choisie n'est plus licite.
- AUDIT DES N/A : tout `not_applicable` en partie I sans citation de l'évaluation des risques dans
  `notes` est un constat, pas un blanc-seing.
- ALERTES CALENDRIER : avertir lorsque la mise sur le marché visée est ≥ 2027-12-11 et qu'un `gap`
  subsiste ; avertir lorsque `srp_access` n'est pas renseigné après le 2026-09-11.