Documentation technique CRA : dossier et preuves

Votre dossier CRA doit permettre à un évaluateur de comprendre le produit, les risques et les preuves de conformité. Une collection de politiques génériques ne suffit pas. Le bon point de départ est un index reliant chaque exigence aux versions, décisions et documents qui la démontrent.

Ce que demandent l’article 31 et l’annexe VII

L’Art. 31 du règlement (UE) 2024/2847 exige une documentation avant mise sur le marché, avec des mises à jour régulières lorsque nécessaire, au moins pendant la période d’assistance. Elle couvre le produit et les processus du fabricant.

L’annexe VII précise le contenu minimal selon le produit concerné :

La nature et la précision des preuves dépendent du produit et des risques. Une catégorie dite « par défaut » ne dispense pas d’une analyse réelle ; un classement important n’impose pas mécaniquement une liste universelle de techniques d’essai.

Construire la matrice de preuves

Pour chaque exigence de l’annexe I, ouvrez une ligne comportant : applicabilité motivée, mesure choisie, document, version, responsable et date de vérification. Une exigence déclarée non applicable doit être justifiée ; une case vide ne vaut pas justification.

Exemple hypothétique : pour la distribution sécurisée des mises à jour, le dossier relie l’architecture du mécanisme, les contrôles d’authenticité et d’intégrité, les résultats de vérification et les instructions données aux utilisateurs. La description technique seule ne prouve pas que le mécanisme fonctionne sur la version commercialisée.

Le guide d’évaluation de conformité CRA permet d’adapter les pièces à la voie retenue. Un organisme notifié peut demander des éléments complémentaires dans le cadre de sa mission ; ces échanges doivent rester rattachés au même périmètre.

SBOM : préciser le contenu et les limites

L’annexe VII, point 2(b), vise les informations nécessaires sur le processus de vulnérabilités, dont la nomenclature. L’annexe I, partie II, point 1 demande un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur.

Ne présentez pas licence, CVE ou toutes les dépendances indirectes comme une liste de champs imposée mot pour mot par cette disposition. Le guide SBOM distingue le minimum légal des informations utiles au suivi. Conservez la relation avec les artefacts effectivement livrés et les limites de détection.

Conservation : corriger le point de départ

L’Art. 13(13) fixe une durée d’au moins dix ans après la mise sur le marché, ou pendant la période d’assistance si elle est plus longue. Il ne prévoit pas ici un redémarrage automatique de dix ans à chaque correctif.

Il faut distinguer cette conservation de la disponibilité des mises à jour déjà émises, régie par l’Art. 13(9), et du travail de gestion des vulnérabilités pendant l’assistance. La durée du support CRA doit être documentée dans le dossier, avec ses motifs.

Accès, confidentialité et langue

L’Art. 31(4) prévoit, pour la documentation et les échanges d’évaluation, une langue officielle de l’État où l’organisme notifié est établi ou une langue acceptée par lui. L’Art. 53 encadre l’accès motivé de l’autorité aux données nécessaires à l’évaluation ; l’Art. 63 protège notamment la confidentialité et les secrets d’affaires dans les conditions du texte.

Cela n’impose pas une publication générale de tout dossier ou de tout SBOM. Il existe toutefois une condition de documentation publique pour la voie particulière de certains logiciels libres et ouverts de l’Art. 32(5). Une demande d’un client doit être examinée selon son fondement contractuel ou légal, sans inventer une obligation générale de remettre l’intégralité du dossier à tout acheteur.

Organiser la tenue à jour

Attribuez un responsable à chaque pièce et déclenchez une revue lors d’un changement de version, d’architecture, de risque, de référence applicable ou de politique de support. Reliez le journal de gestion des vulnérabilités au dossier sans effacer les décisions antérieures.

Ces exigences relèvent de l’application générale du 11 décembre 2027, avec les transitions pertinentes. Le calendrier CRA distingue cette échéance des signalements déjà applicables.

Délimiter une version que le dossier permet de retrouver

Commencez par une page d’identification : produit, utilisation prévue, versions concernées, composants matériels éventuels et traitement distant associé. Le dossier doit permettre de rapprocher ces références de ce qui est effectivement livré. Un nom de gamme commun à plusieurs appareils ne suffit pas à expliquer quels rapports couvrent quelle configuration.

Cette identification sert aussi à contrôler les pièces reçues d’un prestataire. Un rapport sans référence de version, sans description de l’environnement ou sans périmètre des vérifications ne permet pas d’établir seul ce qu’il démontre. Demandez les précisions utiles avant de l’utiliser comme preuve. Conservez ses limites plutôt que les remplacer par une formule générale de validation.

Voici une structure de travail proposée pour l’index documentaire :

Le format peut rester simple. L’essentiel est que les renvois soient exploitables par une personne qui n’a pas participé au développement. Un lien vers un dossier partagé dont les documents sont remplacés sans historique ne garantit pas cette traçabilité.

Traiter les écarts sans confondre projet et preuve

Distinguez une mesure envisagée, une mesure implémentée et une mesure dont le fonctionnement a été vérifié. Un ticket de développement clôturé n’est pas nécessairement un rapport d’essai. Une procédure de gestion des vulnérabilités peut décrire une organisation prévue sans démontrer que les contacts, responsabilités et circuits annoncés sont opérationnels.

Exemple entièrement fictif : le dossier du logiciel Mélèze contient un rapport sur la version 2.0, tandis que la version 2.1 modifie le mécanisme de téléchargement des correctifs. Le rapport ancien reste une pièce historique. L’équipe doit déterminer les effets du changement et les éléments à produire ou à reprendre pour la version 2.1 ; on ne peut pas supposer ici que les conclusions antérieures la couvrent.

La fiche de changement peut indiquer le mécanisme modifié, les exigences concernées, les preuves encore pertinentes et celles dont la portée doit être réexaminée. Si une vérification manque, mentionnez-la comme action ouverte. Aucun essai n’est réalisé ni présumé concluant dans cet exemple. La présentation soignée d’un dossier incomplet ne remplace pas la démonstration requise.

Demander les bons éléments aux fournisseurs

Avant de dépendre d’un composant ou d’un développement externe, identifiez les informations nécessaires à votre propre dossier : référence exacte, conditions d’intégration, mises à jour de sécurité, durée de support et modalités de signalement. Organisez leur obtention dans les échanges et contrats pertinents. Une clause peut prévoir une coopération ; elle ne prouve pas que les documents ont été reçus et examinés.

Si le fournisseur limite la diffusion de ses pièces, clarifiez les destinataires autorisés et les modalités d’accès. Une présentation commerciale ou un certificat portant sur un autre périmètre ne comble pas automatiquement cette limite. Notez l’information indisponible et son incidence sur votre capacité à justifier les choix de sécurité.

L’objectif n’est pas de collecter sans discernement tous les documents internes du fournisseur. Demandez ce qui permet de comprendre l’intégration et de soutenir votre évaluation. Maintenez le lien entre la version du composant, celle du produit livré et les pièces qui les concernent, notamment lors d’un remplacement de dépendance.

Préparer une transmission maîtrisée et une conservation lisible

À réception d’une demande, identifiez son auteur, son fondement, son objet et la période ou version visée. Une demande d’autorité, une mission d’organisme notifié et une consultation commerciale ne suivent pas nécessairement le même cadre. Appliquez les obligations correspondantes sans traiter une mention de confidentialité comme un refus automatique de communiquer.

Préparez un bordereau des pièces remises, avec leurs références, leurs limites et les compléments annoncés. Conservez la demande et la version transmise. Cette méthode proposée permet d’éviter qu’un document de travail soit présenté comme final ou qu’une mise à jour ultérieure rende impossible la compréhension d’une réponse ancienne.

Enfin, attribuez la responsabilité de l’archivage et vérifiez que les pièces restent consultables malgré un changement d’outil, de prestataire ou d’équipe. Pour chaque famille de produits, rattachez le calendrier de conservation au point de départ juridique et à la période d’assistance applicable. Une migration documentaire doit préserver les références et l’historique nécessaires, pas seulement déplacer des fichiers portant le même nom.

Ce qu’il faut retenir

• Le dossier doit être spécifique au produit, à ses versions et aux processus du fabricant.
• Chaque exigence doit renvoyer à une preuve et à un responsable.
• Conservation et mise à jour suivent des règles distinctes.
• La confidentialité n’empêche pas les accès légalement prévus ; la publication générale n’est pas la règle.

FAQ

Une petite entreprise est-elle dispensée de documentation ?

Non. L’Art. 33(5) prévoit la possibilité d’un format simplifié défini par acte d’exécution pour les microentreprises et petites entreprises. Ce mécanisme n’efface pas les éléments requis de l’annexe VII.

Chaque correctif relance-t-il dix ans de conservation ?

Pas au titre de l’Art. 13(13), qui prend pour référence la mise sur le marché et la période d’assistance. Les mises à jour déjà émises ont par ailleurs leur propre règle de disponibilité.

Faut-il publier tout le dossier sur internet ?

Non, il n’existe pas d’obligation générale en ce sens. La voie spéciale de l’Art. 32(5) pour certains logiciels libres et ouverts comporte toutefois une condition de publication de la documentation technique.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.