Documentation technique CRA : préparation et suivi

La documentation technique CRA n’est pas un document ponctuel préparé pour un audit. L’article 31 impose de l’établir avant la mise sur le marché du produit comportant des éléments numériques et de la mettre à jour lorsque cela est nécessaire, au moins pendant la période d’assistance.

Si l’architecture, les décisions et les résultats des tests doivent être reconstitués à partir d’e-mails, de tickets et de la mémoire de l’équipe, le problème n’est pas l’absence d’un modèle de document. C’est l’absence d’un modèle maintenu du produit et de ses preuves.

Ce que couvre l’annexe VII

Le contenu exact dépend du produit, mais l’annexe VII définit au moins les catégories d’informations suivantes.

1. Description générale du produit

Elle comprend la destination, les versions logicielles influant sur la conformité aux exigences essentielles de cybersécurité, ainsi que les informations et instructions fournies aux utilisateurs.

2. Conception, développement, production et traitement des vulnérabilités

La documentation doit contenir suffisamment d’informations pour comprendre la conception et l’architecture, les liens entre composants et les processus de traitement des vulnérabilités du fabricant.

Le CRA mentionne explicitement ici la SBOM, la politique de divulgation coordonnée des vulnérabilités, la preuve de l’existence d’une adresse de contact pour leur signalement et les solutions techniques utilisées pour distribuer les mises à jour de manière sécurisée.

3. Évaluation des risques de cybersécurité

La fiche doit montrer les risques pris en compte dans la conception, le développement, la production, la fourniture et la maintenance du produit, ainsi que l’application des exigences de l’annexe I.

4. Fondement de la période d’assistance

La documentation ne peut pas se limiter à une date de fin. Elle doit conserver les informations utilisées par le fabricant pour déterminer cette période.

5. Normes et solutions techniques utilisées

Lorsque des normes harmonisées, des spécifications communes ou des schémas de certification de cybersécurité pertinents sont utilisés, la documentation les identifie et précise les parties appliquées. Dans le cas contraire, le fabricant doit documenter les solutions adoptées pour satisfaire aux exigences applicables.

6. Rapports de test

Preuves des tests réalisés pour vérifier le produit et les processus de traitement des vulnérabilités au regard des exigences applicables.

7. Déclaration UE de conformité

Une copie de la déclaration pour le produit.

8. SBOM demandée par une autorité de surveillance du marché

L’annexe VII prévoit la mise à disposition de la SBOM pertinente à la suite d’une demande motivée, lorsque cela est nécessaire pour permettre à l’autorité de vérifier la conformité.

Utilisez un index plutôt qu’un immense PDF

Un modèle pratique consiste à créer un index de documentation rattaché à une version du produit.

Domaine	Document source	Responsable	Version / date	Preuve de revue
Destination	Fiche produit	Responsable produit	v3.4	Approbation
Architecture	Schéma + description	Ingénierie	v3.4	Revue
Évaluation des risques	Registre des risques	Sécurité / produit	v3.4	Décisions
SBOM	Fichier de compilation / de version	Ingénierie	Version 3.4.2	Empreinte / journal
Tests	Rapports	Qualité / sécurité	Version 3.4.2	Résultat
CVD	Politique	Sécurité	Rév. 5	Approbation
Période d’assistance	Fiche de décision	Produit / direction	2026-09	Justification

La documentation technique peut comprendre de nombreux documents et fichiers. L’essentiel est de pouvoir identifier quel élément s’applique à quelle version et qui a confirmé qu’il était à jour.

Quatre habitudes qui créent des coûts inutiles

« Nous avons une politique, donc le sujet est couvert »

Une politique décrit la manière dont l’organisation prévoit de travailler. Elle ne prouve pas qu’une version précise du produit a été évaluée et testée.

« L’architecture est dans le dépôt, tout le monde sait où »

Après un changement d’équipe ou dix-huit mois, « tout le monde sait » cesse d’être une source de preuve exploitable.

« La SBOM est générée dans la chaîne de compilation »

C’est utile, mais la documentation doit encore relier ce fichier au produit, à la version publiée et au processus de traitement des vulnérabilités.

« Nous exporterons tout avant l’audit »

Si les fiches sources sont incohérentes, un export ne fait que révéler cette incohérence plus rapidement.

Comment Pulsar organise la traçabilité documentaire

Les documents, preuves, risques, contrôles et rapports dans Pulsar conservent le contexte des évaluations. La documentation peut ainsi fonctionner comme un ensemble de fiches liées, plutôt que comme un dossier contenant uniquement les fichiers finaux.

La fiche cible doit répondre aux questions suivantes :

à quel produit et à quelle version appartient le document ou fichier ;
quelle exigence ou quel risque il étaye ;
qui l’a créé et approuvé ;
à quel moment il était à jour ;
quelle action ou décision il prouve ;
ce qui a changé depuis la revue précédente.

Pulsar ne fournit pas le contenu protégé des normes et ne remplace pas la documentation technique produite par le fabricant. Il aide à maintenir la structure, les responsabilités et la traçabilité.

Découvrez les documents et preuves dans Pulsar GRC

Guides associés

Préparer un index stable avant d’accumuler les fichiers

L’index doit répondre à une question simple : quelle pièce permet de comprendre ce produit, dans cette version, et la décision prise à son sujet ? Commencez par les informations du produit, son architecture et les exigences examinées. Reliez ensuite les risques, les mesures, les essais et les décisions. Un classement par type de fichier peut aider au rangement, mais il ne montre pas nécessairement ces relations. Le lecteur doit pouvoir suivre l’analyse sans reconstituer son histoire orale.

Pour chaque pièce, indiquez le propriétaire, la version, la date et le périmètre. La documentation d’un composant partagé peut être référencée dans plusieurs dossiers, à condition que la relation avec chaque produit soit expliquée. Ne supposez pas qu’un rapport générique couvre toutes les configurations. Si une variante n’a pas été examinée, rendez cette limite visible et attribuez la tâche qui permettra de la traiter.

Distinguer la règle, l’exécution et la décision

Une procédure décrit ce qui devrait être fait. Un résultat de test montre ce qui a été observé dans un contexte précis. Une approbation explique pourquoi une personne accepte ce résultat. Ces éléments se complètent, mais ne se substituent pas les uns aux autres. Un dossier contenant uniquement des procédures laisse ouverte la question de leur mise en pratique. Un dossier contenant uniquement des résultats reste difficile à interpréter sans critères.

Cette distinction vaut également pour l’évaluation des risques. Conservez la méthode utilisée et les faits qui ont motivé l’analyse, puis la décision de traitement. Une valeur numérique sans explication n’aide pas à comprendre la conception du produit. Si l’acceptation repose sur une limite d’usage ou une configuration spécifique, reliez cette condition aux informations destinées aux utilisateurs et aux essais qui la vérifient.

Exemple proposé : une mise à jour d’authentification

Dans un scénario hypothétique, une nouvelle version modifie la manière dont les utilisateurs se connectent au produit. Le dossier doit montrer le motif du changement, les fonctions concernées, les risques examinés et la mesure retenue. L’équipe ajoute le résultat des essais et les limites connues. Le responsable de la publication examine ces éléments avant de décider. Une note disant seulement « sécurité améliorée » ne permet pas de vérifier ce parcours.

Si la mise à jour modifie l’usage d’un composant ou d’un service à distance, reliez aussi la documentation de ce lien. Vérifiez l’effet sur les versions encore prises en charge et les instructions de mise à jour. Les informations pertinentes peuvent rester dans les outils métier, si leur accès et leur version sont contrôlés. La documentation technique doit les rendre identifiables, plutôt que produire des copies dont personne ne sait laquelle est actuelle.

Garder la documentation alignée sur les publications

Définissez un point de revue dans le processus de publication. Le responsable vérifie que le dossier correspond à la version effectivement distribuée, avec ses composants et sa configuration. Le code, les essais et les documents peuvent évoluer à des rythmes différents. Une revue explicite permet de repérer une description d’architecture ancienne ou un test réalisé sur une version qui n’est pas celle mise à disposition.

Après publication, une information nouvelle peut imposer un complément. Un avis de vulnérabilité, une erreur de documentation ou un changement de fournisseur doit être relié à la décision précédente et à son traitement. Conservez le contexte ancien au lieu de le réécrire comme si la nouvelle information avait toujours été connue. La documentation doit permettre de comprendre les faits disponibles à chaque étape et la manière dont l’organisation a réagi.

Organiser les accès selon le besoin de revue

Les auteurs, les personnes qui approuvent et les destinataires externes n’ont pas nécessairement besoin du même accès. Vérifiez le périmètre avant un partage : données personnelles, secrets de conception, engagements de confidentialité et éléments fournis par un tiers. Le besoin de démonstration doit être concilié avec les règles applicables. Un accès large ne rend pas le dossier plus fiable ; il peut simplement communiquer des informations qui n’étaient pas nécessaires.

Testez le parcours avec un compte autorisé représentant le lecteur prévu. Un index correct pour son auteur peut contenir des liens que le destinataire ne peut pas ouvrir. Corrigez ces obstacles et conservez la version de la sélection partagée. Si un export est préparé, vérifiez qu’il garde le contexte des pièces : produit, version, dates et décisions. Les formats proposés par le logiciel doivent être examinés selon le besoin réel.

Définir une revue indépendante de lisibilité

Choisissez quelques décisions et demandez à une personne autorisée qui ne les a pas préparées de retrouver leur base. Elle doit pouvoir identifier le produit, le risque, le test et l’approbation correspondants. Notez les ambiguïtés au lieu de les résoudre uniquement pendant la réunion. Une explication orale peut aider sur le moment, mais la prochaine revue aura besoin de la même information si elle n’a pas été conservée.

Ce contrôle est une méthode proposée de préparation documentaire, pas une procédure officielle de certification. Il complète les revues techniques et juridiques nécessaires sans les remplacer. La qualité du dossier dépend de la pertinence des preuves et des compétences des personnes qui les examinent. Un index complet et un grand volume de fichiers ne donnent pas à eux seuls une conclusion de conformité.

Maintenir les responsabilités sur la durée

Le propriétaire du dossier doit savoir ce qu’il vérifie et quand une nouvelle revue est nécessaire. Prévoyez également la continuité lors d’un départ ou d’un changement d’équipe. Les droits d’accès, les documents personnels et les liens dépendant d’un compte individuel doivent être examinés. L’organisation doit pouvoir reprendre le dossier sans dépendre de la mémoire du seul ingénieur qui avait préparé la première version.

Pulsar GRC peut relier les documents aux exigences, risques, actions et décisions. L’IA peut préparer un résumé à vérifier ; elle ne crée pas une documentation technique valide par sa seule génération. Votre organisation conserve les sources, fournit les normes sous licence lorsqu’elles sont utilisées et approuve les conclusions. Testez d’abord un dossier limité avec des données non confidentielles, puis évaluez la lisibilité du résultat et les informations qui restent à compléter.

Sources

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.

Pulsar GRC — accès, isolation des données et export (polonais)