DOSSIER TECHNIQUE CRA

Dossier technique CRA : préparer la documentation de vos produits

Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, prévoit une documentation technique permettant d'expliquer comment un produit comportant des éléments numériques répond aux exigences de cybersécurité applicables. L'article 31 renvoie à l'annexe VII, organisée en huit points. Le dossier doit être adapté au produit, à ses risques, à sa conception et aux mesures effectivement mises en œuvre.

Constituer ce dossier ne consiste pas à remplir une formalité une seule fois : il faut réunir les éléments, vérifier leur pertinence, documenter les décisions et les actualiser lorsque le produit évolue.

Navigation utile : Comprendre le CRA · Découvrir CRA Manager · Guide Cyber Resilience Act · Notification ENISA CRA

Qu'est-ce que la documentation technique exigée par le CRA ?

La documentation technique réunit les informations sur le produit et les moyens utilisés par le fabricant pour répondre aux exigences essentielles de cybersécurité de l'annexe I. Elle doit être établie avant la mise sur le marché du produit concerné, puis mise à jour régulièrement lorsque cela est nécessaire, au moins pendant la période d'assistance applicable (article 31).

La portée exacte des pièces dépend du produit, de son usage, des exigences applicables et de l'évaluation des risques. Le dossier ne vaut pas, à lui seul, déclaration UE de conformité ou droit d'apposer le marquage CE : ces étapes relèvent du dispositif réglementaire et de la procédure d'évaluation appropriée.

Que contient l'annexe VII du Cyber Resilience Act ?

Les huit points de l'annexe VII fournissent le cadre de référence du dossier :

Que contient l'annexe VII du Cyber Resilience Act ?
PointContenu à documenterExemples de pièces à examiner
1. Description générale du produitDestination, versions logicielles pertinentes, informations utilisateur ; éléments matériels le cas échéant.Fiche produit, version, documentation utilisateur, vues techniques.
2. Conception, développement, fabrication et gestion des vulnérabilitésDescription des méthodes, de l'architecture, des composants et des processus de gestion des vulnérabilités.Architecture, politique de divulgation, procédure de correction, description du cycle de développement.
3. Évaluation des risques de cybersécuritéRisques pris en compte dans la conception, le développement, la livraison et la maintenance ; justification des exigences applicables.Analyse des risques, décisions de traitement, actions et preuves.
4. Période d'assistanceInformations utilisées pour déterminer la durée de support conformément à l'article 13, paragraphe 8.Justification de durée, politique de support, informations de fin de support.
5. Normes, spécifications et solutions retenuesNormes harmonisées ou solutions techniques utilisées pour répondre aux exigences, selon le cas.Référentiel de normes, matrices de correspondance, justifications techniques.
6. Rapports d'essaisVérifications portant sur le produit et les processus de gestion des vulnérabilités.Résultats de tests, rapports de sécurité, comptes rendus de vérification.
7. Déclaration UE de conformitéCopie de la déclaration correspondante.Déclaration UE finalisée et versionnée, lorsque requise.
8. Nomenclature des logiciels (SBOM)Le cas échéant, nomenclature fournie à la suite d'une demande motivée de l'autorité de surveillance du marché, dans les conditions prévues.SBOM et éléments permettant de relier ses composants au produit concerné.

Ce tableau est une aide de lecture, non une liste de documents uniformément obligatoires pour tous les fabricants ou tous les produits. Le texte de l'annexe VII fait foi.

Comment construire un dossier technique CRA exploitable ?

1. Délimiter le produit et ses versions

Identifier le produit soumis à évaluation, son usage prévu, ses fonctionnalités et les versions concernées. La qualification du périmètre CRA, notamment en présence de services distants, doit être documentée et validée par les personnes compétentes.

2. Relier les risques aux décisions techniques

Conserver l'analyse des risques de cybersécurité, puis établir le lien avec les mesures de conception, les tests, les actions et les justificatifs. Une preuve est utile si elle montre ce qui a été décidé, pour quel périmètre, par qui et sur quelle version.

3. Documenter les composants et les vulnérabilités

Mettre en relation l'inventaire des composants, les SBOM disponibles, les signaux de sécurité, les vulnérabilités formellement qualifiées et les corrections réalisées. Un signal externe ou une CVE ne constitue pas automatiquement une vulnérabilité affectant le produit.

4. Organiser la revue et l'actualisation

Définir les responsables de chaque partie, les preuves attendues, la fréquence de révision et les déclencheurs de mise à jour : nouvelle version, modification majeure, évolution des risques ou nouvelle mesure corrective.

5. Préparer le processus d'évaluation de conformité

Le dossier technique alimente l'évaluation de conformité, dont la procédure dépend des caractéristiques et de la catégorie du produit. Il ne remplace ni l'évaluation ni la déclaration UE de conformité ; le fabricant reste responsable des décisions et des obligations applicables.

Quelle est la différence entre un SBOM et le dossier technique CRA ?

Le SBOM décrit des composants logiciels et leurs relations dans un périmètre donné. Le dossier technique couvre un ensemble beaucoup plus large : produit, conception, risques, processus de vulnérabilités, support, essais, normes et déclaration UE, selon les cas.

La réglementation ne fait pas du SBOM un document à publier systématiquement sur internet. Le fabricant doit examiner les exigences de tenue, de conservation et de communication applicables à son produit, notamment celles de l'annexe I, partie II, et de l'annexe VII.

Comment CRA Manager aide-t-il à préparer ce dossier ?

CRA Manager permet de structurer un dossier documentaire par produit, de relier les informations issues du pilotage CRA (produit, risques, composants, vulnérabilités, actions et justificatifs) et de suivre la préparation des rubriques.

Le dossier utilise 13 rubriques internes dans CRA Manager, qui servent à organiser le travail autour des huit points réglementaires de l'annexe VII. Il ne faut pas confondre ces 13 rubriques logicielles avec 13 obligations autonomes issues du règlement.

Un export Word de travail peut être utilisé pour la revue documentaire. Cet export est un brouillon révisable : il ne constitue ni une attestation de conformité ni la preuve que toutes les exigences sont satisfaites. La disponibilité exacte des fonctions dépend de l'édition, des droits et de la configuration.

FAQ — Dossier technique CRA

Le dossier technique CRA est-il obligatoire pour chaque produit ?

L'article 31 encadre la documentation technique pour les produits qui relèvent des obligations applicables du CRA. Il faut d'abord qualifier le produit, l'opérateur concerné, les éventuelles exclusions et les dispositions transitoires.

L'annexe VII comporte-t-elle 8 ou 13 sections ?

Le règlement comporte huit points à l'annexe VII. CRA Manager peut proposer une organisation interne en 13 rubriques, sans modifier le nombre de points du texte réglementaire.

Un fichier Word suffit-il pour être conforme au CRA ?

Non. Un document Word est un support de travail ; son contenu, ses preuves et la conformité du produit et des processus doivent être établis et évalués selon le cadre applicable.

Le SBOM doit-il être public ?

Non, le CRA n'instaure pas une obligation générale de publication publique de tous les SBOM. Les obligations de constitution et de communication sont à lire dans leurs conditions précises.

Quand faut-il constituer la documentation technique ?

L'article 31 prévoit sa préparation avant la mise sur le marché et des mises à jour régulières si nécessaire, au moins durant la période d'assistance applicable. Le régime général du CRA s'applique à partir du 11 décembre 2027, sous réserve des dispositions transitoires et particulières.

Sources officielles

Rédaction : équipe Hoctave. Le présent contenu est informatif et ne remplace pas la qualification du cas particulier.