La Documentation Technique CRA : Ce Que Contient Chaque Section (Détail de l'Annexe VII)

La documentation technique est votre dossier de preuves pour la conformité CRA. Les autorités de surveillance du marché la demanderont. Les Organismes Notifiés l'examineront. Sans documentation technique complète, vous ne pouvez pas légalement mettre votre produit sur le marché de l'UE.

Ce guide détaille l'Annexe VII section par section, expliquant ce que chacune exige et comment la préparer.

Qu'est-ce que la Documentation Technique ?

La documentation technique (aussi appelée "dossier technique") est le dossier complet de preuves démontrant que votre produit est conforme aux exigences du CRA.

Ce n'est pas :

• De la documentation marketing
• Uniquement des manuels utilisateur
• Un exercice de cases à cocher

C'est :

• Des preuves techniques complètes
• Une documentation vivante (mise à jour tout au long de la vie du produit)
• Votre défense dans les enquêtes de surveillance du marché
• Requis pour l'évaluation de conformité

Important : La documentation technique doit etre preparee AVANT la mise sur le marche et conservee pendant 10 ans apres la derniere unite mise sur le marche. Les autorites peuvent la demander a tout moment.

Aperçu de la Structure de l'Annexe VII

L'Annexe VII du CRA spécifie les exigences de documentation technique :

STRUCTURE DOCUMENTATION TECHNIQUE (Annexe VII)

1. DESCRIPTION GÉNÉRALE
   └── Identification du produit et usage prévu

2. CONCEPTION ET DÉVELOPPEMENT
   └── Comment la sécurité a été intégrée

3. ÉVALUATION DES RISQUES CYBERSÉCURITÉ
   └── Risques identifiés et traités

4. EXIGENCES ESSENTIELLES
   └── Comment les exigences de l'Annexe I sont satisfaites

5. NORMES APPLIQUÉES
   └── Normes utilisées et déviations

6. NOMENCLATURE DES COMPOSANTS LOGICIELS
   └── Composants et dépendances

7. RÉSULTATS DES TESTS
   └── Preuves de vérification

8. DÉCLARATION UE DE CONFORMITÉ
   └── Ou copie de celle-ci

9. GESTION DES VULNÉRABILITÉS
   └── Processus de sécurité post-marché

Section 1 : Description Générale

Objectif : Établir ce qu'est le produit et à quoi il sert.

Contenu Requis

LISTE DE CONTRÔLE DESCRIPTION GÉNÉRALE

Identification du Produit :
[ ] Nom et numéro de modèle du produit
[ ] Version(s) matérielle(s)
[ ] Version(s) logicielle/firmware
[ ] Format ou plage de numéros de série
[ ] Identifiant unique du produit

Usage Prévu :
[ ] Description de la fonction principale
[ ] Utilisateurs/environnement cibles
[ ] Cas d'usage prévus
[ ] Usages non prévus (exclusions)

Catégorie du Produit :
[ ] Classification CRA (Par défaut/Important/Critique)
[ ] Justification de la classification
[ ] Réglementations produit connexes (le cas échéant)

Informations Marché :
[ ] Date de première mise sur le marché UE
[ ] États membres cibles
[ ] Canaux de distribution

Exemple

DESCRIPTION GÉNÉRALE

Nom du Produit : SmartSense Pro Capteur Industriel
Numéro de Modèle : SSP-3000
Version Matérielle : Rév C (PCB v3.2)
Version Firmware : 2.4.1

USAGE PRÉVU :
Le SmartSense Pro est un capteur environnemental industriel
conçu pour la surveillance des installations de fabrication.
Il mesure la température, l'humidité et la qualité de l'air,
transmettant les données via WiFi vers le cloud ou des serveurs locaux.

UTILISATEURS CIBLES :
- Responsables d'installations
- Intégrateurs d'automatisation industrielle
- Responsables conformité environnementale

ENVIRONNEMENT PRÉVU :
- Installations industrielles intérieures
- Température de fonctionnement : -10°C à +60°C
- Réseau : WiFi 802.11 b/g/n

NON PRÉVU POUR :
- Applications médicales ou de sécurité des personnes
- Installation extérieure
- Atmosphères explosives
- Usage consommateur/résidentiel

CLASSIFICATION CRA :
Produit par défaut. Non listé dans l'Annexe III ou IV.
Justification : Capteur à usage général sans fonctions
de sécurité ni application d'infrastructure critique.

MISE SUR LE MARCHÉ UE :
Première mise sur le marché : 15 mars 2027
Marchés cibles : Tous les États membres de l'UE
Distribution : Ventes directes et distributeurs autorisés

Section 2 : Conception et Développement

Objectif : Documenter comment la sécurité a été intégrée dans la conception du produit.

Contenu Requis

LISTE DE CONTRÔLE DOCUMENTATION CONCEPTION

Architecture :
[ ] Diagramme d'architecture système
[ ] Diagramme d'interaction des composants
[ ] Diagramme de flux de données
[ ] Frontières de confiance identifiées

Conception Sécurité :
[ ] Description de l'architecture de sécurité
[ ] Implémentations cryptographiques
[ ] Mécanismes d'authentification
[ ] Modèle d'autorisation
[ ] Protocoles de communication sécurisée
[ ] Mesures de protection des données

Processus de Développement :
[ ] Description du cycle de développement sécurisé
[ ] Traçabilité des exigences de sécurité
[ ] Procédures de revue de code
[ ] Tests de sécurité en développement
[ ] Gestion de configuration

Gestion des Changements :
[ ] Procédures de contrôle de version
[ ] Évaluation d'impact des changements
[ ] Revue de sécurité pour les changements

Section 3 : Évaluation des Risques Cybersécurité

Objectif : Documenter les risques identifiés et comment ils sont traités.

Format d'Évaluation des Risques

ÉVALUATION DES RISQUES CYBERSÉCURITÉ

Produit : SmartSense Pro (SSP-3000)
Version : 2.4.1
Date d'Évaluation : Janvier 2027
Évaluateur : [Nom, Équipe Sécurité]

MÉTHODOLOGIE :
Basée sur ISO 27005 adaptée pour la sécurité produit.
Risque = Probabilité × Impact
Échelle : Faible (1-4), Moyen (5-9), Élevé (10-16), Critique (17-25)

─────────────────────────────────────────────────────────────
ID RISQUE : R-001
MENACE : Modification non autorisée du firmware
VULNÉRABILITÉ : Un firmware non signé pourrait être installé
IMPACT : Élevé (5) - Compromission appareil, fuite de données
PROBABILITÉ : Moyenne (3) - Nécessite accès physique
RISQUE INHÉRENT : 15 (Élevé)

CONTRÔLE : Vérification de signature du firmware
IMPLÉMENTATION : Signature ECDSA P-256 vérifiée avant installation
RISQUE RÉSIDUEL : 3 (Faible) - Attaque cryptographique improbable

STATUT : Atténué
─────────────────────────────────────────────────────────────

RÉSUMÉ DES RISQUES :
Total risques identifiés : 23
Critique : 0
Élevé : 3 (tous atténués à Faible/Moyen)
Moyen : 8 (tous atténués à Faible)
Faible : 12 (acceptés ou atténués)

ACCEPTATION DU RISQUE RÉSIDUEL :
Tous les risques résiduels sont dans la tolérance acceptable.
Signé : [Responsable Sécurité], [Date]

Section 4 : Cartographie des Exigences Essentielles

Objectif : Démontrer comment chaque exigence de l'Annexe I est satisfaite.

Exigences Annexe I, Partie I

MATRICE DE CONFORMITÉ EXIGENCES ESSENTIELLES

ANNEXE I, PARTIE I - EXIGENCES DE SÉCURITÉ
═══════════════════════════════════════════════════════════

1. CONÇU SANS VULNÉRABILITÉS EXPLOITABLES CONNUES
   Statut : CONFORME
   Preuves :
   - Rapport de scan de vulnérabilités (Trivy) : 0 critique/élevé
   - Analyse des dépendances : Tous les composants aux dernières versions sécurisées
   - Rapport de test de pénétration : Aucune vulnérabilité exploitable trouvée
   Référence : Rapport de Test TR-2027-001, pages 15-23

2. CONFIGURATION SÉCURISÉE PAR DÉFAUT
   Statut : CONFORME
   Preuves :
   - Document de revue de configuration par défaut
   - Pas de mots de passe par défaut (identifiants uniques requis à l'installation)
   - Services non nécessaires désactivés par défaut
   - Protocoles sécurisés activés par défaut (TLS, pas HTTP)
   Référence : Document de Conception DD-004, Section 3.2

[Continuer pour toutes les exigences Annexe I...]

Section 5 : Normes Appliquées

Objectif : Documenter quelles normes ont été utilisées et comment.

Format Documentation des Normes

NORMES APPLIQUÉES

NORMES HARMONISÉES (présomption de conformité) :
─────────────────────────────────────────────────────────────
Norme : EN 303 645 (quand harmonisée pour le CRA)
Titre : Cybersécurité pour l'IoT Grand Public
Statut : Appliquée intégralement
Publication : JOUE [référence quand publiée]
Preuves : Rapport de Conformité aux Normes SCR-001
─────────────────────────────────────────────────────────────

AUTRES NORMES APPLIQUÉES :
─────────────────────────────────────────────────────────────
Norme : IEC 62443-4-1:2018
Titre : Sécurité pour l'Automatisation Industrielle - Développement Sécurisé
Statut : Appliquée (exigences sélectionnées)
Articles Appliqués : 5, 6, 7, 8, 10
Preuves : Documentation SDL SLD-001
─────────────────────────────────────────────────────────────

DÉVIATIONS :
─────────────────────────────────────────────────────────────
Norme : EN 303 645
Article : 5.3-2 (Identifiants uniques par appareil)
Déviation : Identifiants uniques par appareil mais non pré-provisionnés
Justification : L'appareil nécessite une configuration utilisateur ;
               identifiants créés lors de la première configuration
Mesure Alternative : Exigences de mot de passe fort appliquées,
                    verrouillage du compte après échecs de tentatives
Évaluation du Risque : Risque résiduel acceptable (voir R-015)
─────────────────────────────────────────────────────────────

Conseil : Automatisez la generation de votre SBOM dans CI/CD. La creation manuelle de SBOM est sujette aux erreurs et ne passe pas a l'echelle sur les versions du produit.

Section 6 : Nomenclature des Composants Logiciels

Objectif : Fournir la transparence sur les composants pour le suivi des vulnérabilités.

Documentation SBOM

NOMENCLATURE DES COMPOSANTS LOGICIELS

Produit : SmartSense Pro (SSP-3000)
Version Firmware : 2.4.1
Format SBOM : CycloneDX 1.5
Généré : 2027-01-15
Outil : Trivy + syft

FICHIER SBOM :
sbom-ssp3000-v2.4.1.json (joint)

RÉSUMÉ DES COMPOSANTS :
─────────────────────────────────────────────────────────────
Total Composants : 127
  Dépendances Directes : 23
  Dépendances Transitives : 104

Par Type :
  Bibliothèques : 98
  Frameworks : 12
  Système d'Exploitation : 1 (FreeRTOS)
  Modules Firmware : 16

Par Licence :
  MIT : 45
  Apache 2.0 : 38
  BSD : 15
  LGPL : 8
  Propriétaire : 21 (composants internes)
─────────────────────────────────────────────────────────────

STATUT DES VULNÉRABILITÉS À L'ÉVALUATION :
─────────────────────────────────────────────────────────────
Date du Scan : 2027-01-15
Scanner : Trivy v0.48.0

Critique : 0
Élevé : 0
Moyen : 2 (acceptés - voir ci-dessous)
Faible : 5 (acceptés)

VULNÉRABILITÉS ACCEPTÉES :
CVE-2026-XXXXX (Moyen) : Composant xyz v1.2.3
  Statut : Non exploitable dans notre configuration
  Justification : Fonctionnalité non activée, chemin de code non accessible
  Date de Revue : 2027-04-15
─────────────────────────────────────────────────────────────

ENGAGEMENT MISE À JOUR SBOM :
Le SBOM sera mis à jour avec chaque version du firmware et mis
à disposition des clients sur demande.

Section 7 : Résultats des Tests

Objectif : Fournir la preuve que les exigences sont effectivement satisfaites.

Format des Résultats de Tests

RÉSUMÉ DES RÉSULTATS DE TESTS

Produit : SmartSense Pro (SSP-3000) v2.4.1
Période de Test : Décembre 2026 - Janvier 2027
Responsable de Test : [Nom]

═══════════════════════════════════════════════════════════
CAMPAGNE DE TEST : TC-2027-001
═══════════════════════════════════════════════════════════

1. TESTS FONCTIONNELS DE SÉCURITÉ
   Périmètre : Authentification, autorisation, chiffrement, démarrage sécurisé
   Cas de Test : 85
   Réussis : 85
   Échoués : 0
   Référence : Rapport de Test TR-FUNC-001

2. SCAN DE VULNÉRABILITÉS
   Outil : Trivy v0.48.0 + Nessus Professional
   Périmètre : Firmware, services réseau, interface web
   Résultats :
     Critique : 0
     Élevé : 0
     Moyen : 2 (acceptés avec justification)
     Faible : 5 (acceptés)
   Référence : Rapport de Scan SR-VULN-001

3. TEST DE PÉNÉTRATION
   Prestataire : [Nom de la société tierce]
   Périmètre : Test en boîte noire de l'appareil déployé
   Durée : 5 jours
   Résultats :
     Critique : 0
     Élevé : 0
     Moyen : 1 (remédié avant publication)
     Faible : 3 (acceptés)
   Référence : Rapport Pentest PT-2027-001

═══════════════════════════════════════════════════════════
ÉVALUATION GLOBALE : RÉUSSI
Tous les résultats critiques et élevés remédiés.
Résultats Moyen/Faible acceptés avec justification documentée.
═══════════════════════════════════════════════════════════

Section 9 : Procédures de Gestion des Vulnérabilités

Objectif : Documenter les processus de sécurité post-marché.

Documentation Gestion des Vulnérabilités

PROCÉDURES DE GESTION DES VULNÉRABILITÉS

1. MÉTHODES DE CONTACT
   Principal : security@entreprise.com
   Formulaire Web : https://entreprise.com/securite/signaler
   security.txt : https://entreprise.com/.well-known/security.txt
   Politique CVD : https://entreprise.com/securite/politique-divulgation

2. ENGAGEMENTS DE RÉPONSE
   Accusé de réception : Sous 3 jours ouvrés
   Évaluation Initiale : Sous 10 jours ouvrés
   Mises à jour de statut : Tous les 14 jours
   Objectif de Résolution : 90 jours (critique : 7 jours)

3. REPORTING ENISA
   Déclencheur : Exploitation active détectée
   Délai : Alerte précoce 24h, rapport détaillé 72h
   Responsable : Responsable Équipe Sécurité
   Processus : Voir PD-ENISA-001

4. HISTORIQUE
   Vulnérabilités traitées (24 derniers mois) : 3
   Temps de résolution moyen : 45 jours
   Rapports ENISA déposés : 0

Remarque : "10 ans apres la derniere unite mise sur le marche" signifie que si vous vendez des produits jusqu'en 2030, la conservation s'etend jusqu'en 2040. Planifiez votre stockage de documents en consequence.

Erreurs Courantes

Avertissement : Une documentation technique qui ne decrit que la version 1.0 alors que votre produit est en version 2.3 est consideree comme non conforme. Mettez a jour la documentation a chaque version.

Évaluation des Risques Incomplète

Problème : Évaluation des risques qui ne couvre pas toutes les menaces ou manque de détails sur le traitement.

Correction : Utiliser une méthodologie structurée. Mapper chaque risque identifié à un contrôle ou une décision d'acceptation.

SBOM Manquant

Problème : Pas de SBOM ou SBOM qui n'inclut pas les dépendances transitives.

Correction : Générer le SBOM avec des outils appropriés. Inclure l'arbre de dépendances complet.

Documentation Obsolète

Problème : La documentation technique décrit la version 1.0 mais le produit est en version 2.3.

Correction : Mettre à jour la documentation à chaque version. Suivre les versions explicitement.

Pas de Traçabilité des Exigences

Problème : Prétend la conformité mais ne montre pas comment chaque exigence est satisfaite.

Correction : Créer une cartographie explicite de chaque exigence de l'Annexe I vers les preuves.

Comment CRA Evidence Aide

CRA Evidence simplifie la création de documentation technique :

• Modèles structurés : Constructeur de documentation technique section par section
• Cartographie des exigences : Suivre les preuves de conformité Annexe I
• Gestion SBOM : Stocker, analyser et mettre à jour les SBOM
• Dépôt de documents : Stockage centralisé de toutes les preuves
• Suivi des versions : Maintenir la documentation à travers les versions produit
• Capacité d'export : Générer des bundles de documentation technique complets

Construisez votre documentation technique sur app.craevidence.com.

Guides Associes

SBOM : Approfondissez les exigences SBOM dans notre guide SBOM.

Evaluation : Choisissez votre voie d'evaluation de conformite avec notre guide de decision des modules.

Declaration : Apprenez a preparer votre Declaration UE de Conformite.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.