CRA et nomenclatures des logiciels : ce qu’exige le règlement et ce qu’il n’exige pas

Les énoncés juridiques ci-dessous ont été vérifiés le 21 octobre 2026 au regard du texte du Journal officiel du règlement (UE) 2024/2847 et de ses rectificatifs ; aucun rectificatif ne modifie sur le fond le texte français des dispositions citées ici. Cette page fournit des informations et ne constitue pas un conseil juridique.

Un fichier de nomenclature des logiciels est un début. Que vous apprend-il réellement ?

Les fabricants « recensent et documentent les vulnérabilités et les composants des produits, notamment par l’établissement d’une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits » (annexe I, partie II, point 1). L’article 13, paragraphe 8, exige que les vulnérabilités soient traitées conformément à l’annexe I, partie II, lorsque le produit est mis sur le marché et pendant la période d’assistance.

Le règlement définit la nomenclature des logiciels comme « un document officiel contenant les détails et les relations avec la chaîne d’approvisionnement des différents composants utilisés dans la fabrication d’un produit comportant des éléments numériques » (article 3, point 39). Une nomenclature des logiciels est donc plus qu’une liste de noms de bibliothèques. La définition comprend les relations avec la chaîne d’approvisionnement entre les composants.

Un fichier rempli de noms de composants peut sembler rassurant. Mais que doit produire le fabricant, et où cet élément doit-il figurer dans la documentation technique ? Qui peut avoir besoin d’y accéder ? Ce sont des questions distinctes, avec des références juridiques différentes.

La lecture retenue dans ce guide est qu’un inventaire utile ne montre pas, à lui seul, que toutes les exigences de cybersécurité de l’annexe I sont respectées. L’article 31, paragraphe 1, demande que la documentation technique les couvre toutes.

Une exigence de format sans format nommé

Le règlement fixe bien des caractéristiques du format de la nomenclature des logiciels : celui-ci doit être couramment utilisé et lisible par machine (annexe I, partie II, point 1). Il serait donc inexact d’affirmer qu’il n’existe « aucune exigence de format ».

Le règlement ne nomme aucune norme, aucun schéma ni aucune version de schéma obligatoires pour la nomenclature des logiciels. Il ne dit pas qu’un format nommé particulier satisfait à toutes les exigences du CRA. L’absence de format nommé ne doit pas non plus être interprétée comme une autorisation d’utiliser un document que les machines ne peuvent pas traiter.

L’article 13, paragraphe 24, permet à la Commission de préciser le format et les éléments de la nomenclature des logiciels par voie d’actes d’exécution, en tenant compte des normes et bonnes pratiques européennes ou internationales. La vérification juridique effectuée pour ce guide n’a trouvé aucun acte d’exécution de ce type au Journal officiel le 21 octobre 2026. Vérifiez à nouveau avant de choisir un format.

Pour le processus de travail, choisissez un format que vos outils d’ingénierie peuvent générer et que votre équipe de sécurité peut examiner. Exportez un fichier et essayez-le dans les outils qui le recevront. Notez les champs manquants et les relations non prises en charge. La réussite de l’exportation ne vous dit pas ce qui a été omis.

Ce que signifie « au moins les dépendances de niveau supérieur »

Le texte légal fixe un minimum : « au moins les dépendances de niveau supérieur » (annexe I, partie II, point 1). Ce point ne doit pas être réécrit comme une exigence expresse d’énumérer toute dépendance indirecte à une profondeur illimitée.

Ce minimum ne dispense pas non plus des autres obligations relatives au traitement des vulnérabilités. L’annexe I, partie II, points 2 à 8, couvre la remédiation, les essais, la divulgation des vulnérabilités corrigées, la divulgation coordonnée des vulnérabilités, le partage d’informations et la distribution des mises à jour.

Pour commencer de manière pratique, prenez les composants directement inclus dans le produit. Cherchez ensuite les lacunes. Les logiciels intégrés sont-ils couverts ? Qu’en est-il des composants groupés, des artefacts générés et des paquets de tiers ? Notez pourquoi chaque composant est inclus ou exclu. Allez au-delà du minimum lorsque cela aide l’équipe à examiner les risques réels du produit.

Utilisez un identifiant concret du produit ou de la compilation dans vos enregistrements internes. Conservez avec le fichier l’entrée, la date de génération et les limites de couverture connues. Ce sont des recommandations de processus, et non l’affirmation que le règlement impose exactement cet ensemble de champs.

La nomenclature des logiciels dans la documentation technique

Avant la mise sur le marché du produit, les fabricants doivent établir la documentation technique visée à l’article 31 et appliquer la procédure d’évaluation de la conformité choisie (article 13, paragraphe 12). L’article 31, paragraphe 1, exige que cette documentation contienne toutes les données ou précisions pertinentes sur les moyens utilisés pour assurer le respect de l’annexe I par le produit et les processus du fabricant. Elle doit au moins comprendre les éléments énoncés à l’annexe VII.

L’annexe VII, point 2), b), mentionne expressément la nomenclature des logiciels. La documentation technique doit contenir « les informations et spécifications nécessaires concernant le processus de gestion des vulnérabilités mis en place par le fabricant, en ce compris la nomenclature des logiciels », ainsi que la politique coordonnée de divulgation des vulnérabilités, la preuve de la fourniture d’une adresse de contact pour le signalement des vulnérabilités et une description des solutions techniques choisies pour la distribution sécurisée des mises à jour.

L’annexe VII, point 8), mentionne séparément la nomenclature des logiciels « le cas échéant » dans le cadre d’une demande motivée d’une autorité de surveillance du marché (voir ci-dessous). L’annexe VII ne prescrit pas la présentation du fichier. La documentation technique doit être tenue à la disposition des autorités de surveillance du marché pendant au moins dix ans après la mise sur le marché du produit ou pendant la période d’assistance, la période la plus longue étant retenue (article 13, paragraphe 13).

Rendez l’inventaire traçable à partir de la documentation. Décrivez comment il est généré et examiné, et comment l’équipe l’utilise lors du traitement des vulnérabilités. Il s’agit d’une recommandation de processus. Un fichier placé dans un dossier est difficile à utiliser si personne ne peut dire quel produit il décrit.

Aucune obligation générale de publication au public

La vérification juridique effectuée pour ce guide n’a trouvé aucune disposition exigeant que la nomenclature des logiciels soit publiée pour que chacun puisse la télécharger. L’annexe II, point 9), couvre le cas où « le fabricant décide de mettre à la disposition de l’utilisateur la nomenclature des logiciels » : les informations destinées aux utilisateurs doivent alors indiquer où elle est accessible.

Ne confondez pas cela avec une obligation distincte. Dès qu’une mise à jour de sécurité est disponible, les fabricants doivent partager et divulguer publiquement les informations sur les vulnérabilités corrigées, sous réserve d’un éventuel report dans des cas dûment justifiés (annexe I, partie II, point 4).

La disponibilité publique et l’accès par une autorité sont deux questions différentes :

• Sur demande motivée, les fabricants doivent fournir à une autorité de surveillance du marché toutes les informations et la documentation nécessaires pour démontrer le respect de l’annexe I (article 13, paragraphe 22).
• L’annexe VII, point 8), vise la nomenclature des logiciels « à la suite d’une demande motivée d’une autorité de surveillance du marché, pour autant que celle-ci soit nécessaire pour permettre à cette autorité de vérifier le bon respect des exigences essentielles de cybersécurité énoncées à l’annexe I ».
• Pour une évaluation des dépendances à l’échelle de l’Union décidée par l’ADCO, les autorités de surveillance du marché peuvent demander aux fabricants de catégories de produits déterminées de fournir les nomenclatures des logiciels pertinentes (article 13, paragraphe 25).

Conserver une nomenclature des logiciels privée ne supprime pas ces obligations envers les autorités. De même, la publier ne remplace ni la documentation technique plus large ni les exigences relatives au traitement des vulnérabilités.

Mythes courants

Utilisez l’inventaire lorsqu’une notification de vulnérabilité arrive

La question utile est de savoir ce que l’inventaire permet à l’équipe d’examiner. Comme recommandation de processus, considérez la nomenclature des logiciels comme une entrée de cette analyse. Lorsqu’une notification de vulnérabilité arrive, identifiez le composant concerné. Comparez-le avec l’inventaire du produit livré. Vérifiez si le composant touché est présent et si le problème signalé concerne son utilisation dans ce produit. Consignez les preuves et la décision.

La correspondance avec un composant donne à l’équipe un élément à examiner. Il est trop tôt pour tirer une conclusion finale. Consignez ce qui est connu et ce qui reste incertain. Attribuez l’action suivante à une personne responsable et reliez l’évaluation à toute correction, mesure d’atténuation et communication aux utilisateurs. Il s’agit d’un processus suggéré ; les critères juridiques doivent toujours être appliqués.

Une nomenclature des logiciels ne détermine pas elle-même si le signalement prévu à l’article 14 est déclenché. L’article 14 couvre les vulnérabilités activement exploitées (article 14, paragraphe 1 ; article 3, point 42)) et les incidents graves ayant des répercussions sur la sécurité du produit (article 14, paragraphes 3 et 5), chacun avec ses propres délais. Voir le guide sur le signalement au titre de l’article 14 et l’entrée du glossaire consacrée à la nomenclature des logiciels.

Sources

• Règlement (UE) 2024/2847 (s’ouvre dans un nouvel onglet), texte du Journal officiel (Office des publications) : article 3, points 39) et 42) ; article 13, paragraphes 8, 12, 13, 22, 24 et 25 ; article 14, paragraphes 1, 3 et 5 ; article 31, paragraphe 1 ; annexe I, partie II, points 1 à 8 ; annexe II, point 9) ; annexe VII, points 2), b), et 8).
• Rectificatif JO L 2025/90555 (s’ouvre dans un nouvel onglet) du 2 juillet 2025 : dans la version française, il rectifie l’article 64, paragraphe 10, et l’article 69, paragraphe 3 ; il ne modifie pas les dispositions citées ci-dessus. Il en va de même pour le JO L 2025/90768 (annexe I, partie I, correction grammaticale), le JO L 2025/90828 (article 67) et le JO L 2026/90243 (annexe III).
• Commission européenne : Cyber Resilience Act, obligations de signalement (s’ouvre dans un nouvel onglet) (consulté le 21 octobre 2026) : contexte pour l’analyse distincte du signalement.

Pour la question distincte des délais, utilisez le calculateur de délais de signalement crAcken.