Beaucoup de CTO et de CISO ont aujourd’hui la même réaction face au Cyber Resilience Act :
"Très bien, mais qu’est-ce qu’on doit documenter concrètement ?"
C’est une très bonne question, et c’est souvent là que le sujet se complique. Non pas parce que les équipes ne font rien, mais parce que la documentation existe rarement sous une forme cohérente. Une partie est dans les tickets, une autre dans le dépôt Git, une autre dans les politiques SSI, une autre chez le DevOps, une autre encore dans des fichiers d’audit ou des documents commerciaux.
Le CRA change justement cela. La Commission européenne rappelle que les fabricants doivent réaliser une évaluation de conformité, établir une documentation technique, rédiger une déclaration UE de conformité, indiquer la période de support et fournir des informations et instructions à l’utilisateur. Elle précise aussi que l’analyse de risque cybersécurité et les moyens choisis pour mettre en œuvre les exigences essentielles doivent être intégrés dans la documentation technique, tenue à disposition des autorités de surveillance du marché.
La bonne lecture est donc simple :
le CRA ne demande pas seulement d’avoir de la documentation. Il demande d’avoir une documentation structurée, reliée au produit, au cycle de développement, à la gestion des vulnérabilités et à la preuve de conformité.
Dans beaucoup d’équipes, la documentation sécurité est dispersée entre :
Le problème n’est donc pas toujours l’absence totale de contenu. Le problème est plus souvent l’absence de chaîne documentaire cohérente.
Or le CRA ne raisonne pas en documents isolés. Il raisonne en démonstration de conformité produit. La Commission précise que, avant la mise sur le marché, le fabricant doit établir la documentation technique, effectuer la procédure d’évaluation de conformité, puis rédiger la déclaration UE de conformité et apposer le marquage CE.
Autrement dit, la documentation ne doit pas seulement “exister quelque part”. Elle doit permettre de répondre clairement à ces questions :
C’est le socle principal.
La Commission rappelle que le contenu minimal de cette documentation est prévu par l’annexe VII du règlement, et qu’elle doit être établie avant la mise sur le marché puis conservée à disposition des autorités. Elle précise aussi que l’analyse de risque cybersécurité ainsi que les moyens choisis pour satisfaire aux exigences essentielles doivent y figurer.
En pratique, cette documentation doit permettre de comprendre :
C’est un point non négociable.
La Commission indique explicitement que le fabricant doit effectuer une cybersecurity risk assessment et que cette analyse doit informer la planification, la conception, le développement, la production, la livraison et la maintenance du produit. Elle doit aussi être incluse dans la documentation technique.
C’est probablement le document qui change le plus la logique produit. Il ne s’agit pas seulement d’un exercice GRC séparé. Il s’agit d’une analyse qui doit expliquer pourquoi certaines décisions de sécurité ont été prises.
Ce document ne doit pas vivre seul. Il doit être relié :
Le CRA impose aussi une logique documentaire après la mise sur le marché.
La Commission rappelle que les fabricants doivent gérer les vulnérabilités pendant la support period, et notifier les vulnérabilités activement exploitées ainsi que les incidents sévères affectant la sécurité du produit. Elle précise aussi les délais de notification et l’usage de la plateforme de reporting CRA gérée par ENISA.
Cela veut dire qu’il faut documenter non seulement les contrôles initiaux, mais aussi le processus de vulnérabilité sur le cycle de vie.
Ce point est renforcé par l’advisory ENISA 2026 sur l’usage sécurisé des package managers, qui insiste sur la sélection, l’intégration, la surveillance et le traitement des vulnérabilités liées aux dépendances tierces.
C’est souvent sous-estimé, alors que c’est explicitement prévu par le CRA.
La Commission rappelle que le produit doit être accompagné des information and instructions to the user prévues par l’annexe II, dans une langue compréhensible, claire, intelligible et lisible, afin de permettre une installation, une utilisation et un fonctionnement sûrs. Elle rappelle aussi que la fin de la période de support doit être indiquée.
Beaucoup d’éditeurs ont une documentation produit fonctionnelle, mais pas une documentation utilisateur réellement orientée sécurité. Le CRA rend ce point beaucoup plus important.
Quand la conformité a été démontrée via la procédure applicable, le fabricant doit établir une EU declaration of conformity. La Commission rappelle que les annexes V et VI donnent la structure du modèle, y compris une version simplifiée.
Ce n’est pas un document “technique” au sens engineering, mais c’est une pièce essentielle du dispositif.
Le CRA oblige le fabricant à indiquer la support period, c’est-à-dire combien de temps le produit sera pris en charge, et à traiter les vulnérabilités pendant cette période. La date de fin de support doit être clairement indiquée au moment de l’achat.
Cela implique que la maintenance sécurité du produit ne peut plus rester implicite.
Les CTO et CISO pensent souvent d’abord à :
Mais pour être réellement prêts, il faut aussi documenter des éléments plus transverses.
C’est souvent le plus gros manque.
Il faut pouvoir montrer, exigence par exigence, ce qui répond à quoi.
Le CRA pousse à une vraie diligence sur les composants tiers. La Commission précise que si le fabricant intègre des composants tiers, il doit exercer une due diligence pour qu’ils ne compromettent pas la cybersécurité du produit.
Pourquoi tel choix d’authentification ? Pourquoi telle configuration par défaut ? Pourquoi tel mécanisme de mise à jour ? Sans trace de décision, la documentation devient faible.
Une procédure seule ne suffit pas toujours. Il faut aussi pouvoir rattacher des preuves ou traces d’exécution quand c’est pertinent.
La manière la plus robuste d’aborder le CRA n’est pas de créer 15 documents isolés. C’est de structurer une chaîne documentaire cohérente.
Cette logique est d’ailleurs cohérente avec le travail ENISA/JRC de mapping entre exigences CRA et standards, qui vise précisément à aider les fabricants à traduire les exigences en pratiques plus opérationnelles.
Non. Le CRA demande une documentation reliée au produit.
Les tickets sont utiles comme preuves ou traces, mais pas comme structure documentaire de conformité.
Si chaque équipe garde “sa part” sans gouvernance commune, la démonstration CRA devient très difficile.
Les instructions et informations de sécurité destinées à l’utilisateur font partie du dispositif, ce n’est pas un détail.
Le CRA couvre le cycle de vie, pas seulement la sortie initiale du produit.
Le meilleur point de départ n’est pas de rédiger immédiatement tous les documents finaux. C’est de faire un gap assessment documentaire.
Il faut répondre à cinq questions :
Ensuite, il faut centraliser la structure autour de quelques blocs :
Pour être conforme au CRA, il ne suffit pas de documenter “la sécurité” en général.
Il faut au minimum structurer :
Le vrai enjeu n’est pas le volume de documentation.
Le vrai enjeu est sa cohérence, sa traçabilité et son lien direct avec le produit.
Oui. La Commission précise que le fabricant doit établir une documentation technique contenant au minimum les éléments prévus à l’annexe VII, et la conserver à disposition des autorités.
Oui. L’analyse de risque cybersécurité fait explicitement partie de ce qui doit informer la conception et être inclus dans la documentation technique.
Oui. Les informations et instructions à l’utilisateur prévues par l’annexe II doivent accompagner le produit et permettre une installation, une utilisation et un fonctionnement sûrs.
Oui. Le CRA impose le traitement des vulnérabilités pendant la période de support, ainsi que l’indication claire de cette période.
