TL;DR. L'échéance de recensement 2028 du NCSC précède toute échéance de migration. Les banques ne peuvent la tenir : le registre DORA ignore la cryptographie.

Points clés

L'échéance que personne n'a chiffrée. Lisez attentivement les calendriers de migration publiés : le séquencement ne prête à aucune ambiguïté.
Votre registre DORA consigne tout, sauf la cryptographie. Voici la partie qui surprend.
Ce que contient réellement un CBOM. Un Cryptography Bill of Materials est un inventaire formel des actifs cryptographiques d'un système — les algorithmes, les clés, les certificats et les protocoles, ainsi que leurs relations avec les composants…
Le recensement, ce sont quatre problèmes, pas un. Traiter le recensement comme un chantier unique est la façon la plus courante de faire échouer ces programmes.

On ne migre pas ce que l'on ne sait pas énumérer : le Cryptographic Bill of Materials que les banques n'ont toujours pas

Toute feuille de route post-quantique bancaire présuppose un inventaire qui n'existe pas. Les plans sont rédigés, les comités de pilotage se réunissent, les tableaux de bord sont à l'orange. Sous tout cela repose l'hypothèse que quelqu'un, quelque part, saurait produire la liste de chaque endroit où la banque exécute une opération cryptographique — quel algorithme, quelle longueur de clé, quelle bibliothèque, quel certificat, expirant quand. Presque aucun établissement n'en est capable. Le premier jalon du NCSC n'est pas un jalon de migration : c'est un jalon de recensement, fixé à 2028, et c'est celui que personne n'a chiffré.

Synthèse pour les dirigeants

La séquence est : recensement, puis agilité, puis migration. Les orientations du NCSC fixent un jalon de recensement défini en 2028, la migration prioritaire en 2031 et l'achèvement d'ici 2035. Un établissement qui commence à migrer avant d'avoir énuméré migrera les systèmes qu'il connaît par hasard.

Le registre dont vous disposez ne répond pas à la question qui se pose aujourd'hui. L'article 8 de DORA impose aux entités financières d'identifier, de classer et de documenter les actifs TIC et de cartographier leurs interdépendances. Il n'exige aucune propriété cryptographique : un registre conforme à l'article 8 peut donc être complet et rester inutile pour planifier l'agilité cryptographique.

La norme existe déjà. Les actifs cryptographiques — algorithmes avec taille de clé, mode et courbe ; clés ; certificats ; protocoles — se représentent dans CycloneDX, publié sous ECMA-424. C'est une question de schéma, pas une question d'achat.

Le quart le plus difficile n'est pas le vôtre à scanner. Les modules matériels de sécurité, les équipements de paiement, les bibliothèques embarquées par les fournisseurs et les prestataires SaaS ne s'énumèrent pas en braquant un scanner sur eux. Cette part de l'inventaire se construit par attestation contractuelle, et la clause doit exister avant que la feuille de route ne le puisse.

L'échéance que personne n'a chiffrée

Lisez attentivement les calendriers de migration publiés : le séquencement ne prête à aucune ambiguïté. La feuille de route du National Cyber Security Centre place le recensement — une vue complète des systèmes et services qui dépendent de la cryptographie — en 2028, les travaux de migration les plus prioritaires en 2031, et l'achèvement sur l'ensemble des systèmes, services et produits en 2035. Le rapport de transition du NIST, IR 8547, suit une trajectoire compatible : les algorithmes à clé publique vulnérables au quantique, dont RSA et ECC, sont dépréciés après 2030 et interdits après 2035.

La plupart des programmes bancaires ont retenu 2035 comme la date. C'est le mauvais bout du calendrier pour planifier.

Deux dates comptent bien davantage. La première est 2028, parce que le recensement est l'entrée de tout ce qui vient ensuite : on ne peut ni cadrer, ni chiffrer, ni séquencer une migration sur un dénominateur inconnu. La seconde est 2030, parce que « déprécié » n'est pas un mot tendre dans un établissement régulé : c'est le moment où continuer à s'appuyer sur un algorithme devient une décision que quelqu'un doit signer.

D'ici 2028, il reste moins de trente mois. Soit un, peut-être deux cycles budgétaires pour bâtir une capacité que la plupart des établissements n'ont pas entamée.

Votre registre DORA consigne tout, sauf la cryptographie

Voici la partie qui surprend. La plupart des grandes banques européennes tiennent déjà un inventaire détaillé et régulièrement revu de leurs actifs TIC, parce que DORA les y oblige.

L'article 8 du règlement (UE) 2022/2554 impose aux entités financières d'identifier, de classer et de documenter de manière adéquate toutes les fonctions métier soutenues par les TIC, les informations et actifs TIC qui les supportent, ainsi que leurs rôles et dépendances au regard du risque TIC — et de cartographier la configuration de ces actifs et les liens entre eux, le tout tenu à jour.

C'est un inventaire sérieux. C'est aussi le mauvais format pour ce problème.

Tableau 1 : le registre dont vous disposez, et celui qu'exige le jalon 2028

Question	Registre des actifs TIC (article 8 de DORA)	Inventaire cryptographique (CBOM)
Quel est cet actif et qui en est propriétaire ?	Oui — c'est le cœur du registre	Ce n'est pas son objet
Quelle est sa criticité, et de quoi dépend-il ?	Oui — classification et cartographie des interdépendances	Hérité du registre des actifs
Quels algorithmes utilise-t-il, et où ?	Non	Oui — par composant, avec taille de clé, mode et courbe
Quelle bibliothèque les met en œuvre, dans quelle version ?	Partiellement, via le SBOM s'il existe	Oui, comme relation explicite
Quels certificats présente-t-il, expirant quand ?	Rarement, et généralement dans un outil PKI distinct	Oui
Où résident les clés, et comment sont-elles protégées ?	Non	Oui — y compris la présence d'un HSM sur le chemin
Cet actif est-il vulnérable au quantique ?	Non déductible	Réponse directe

La dernière ligne résume tout l'argument. Un établissement peut être pleinement conforme à l'article 8, passer son examen, et rester incapable de répondre à « combien de nos systèmes casseront en 2030 » sans lancer un projet de recensement en partant de zéro.

Ce n'est pas une critique de DORA. L'article 8 a été écrit pour répondre à des questions de résilience et de concentration, et il y répond bien. Il n'a simplement pas été écrit pour répondre à une question d'agilité cryptographique, et les deux registres doivent être joints plutôt que tenus comme deux tableurs séparés appartenant à deux équipes séparées.

Ce que contient réellement un CBOM

Un Cryptography Bill of Materials est un inventaire formel des actifs cryptographiques d'un système — les algorithmes, les clés, les certificats et les protocoles, ainsi que leurs relations avec les composants logiciels qui les utilisent.

Le point structurel important, c'est qu'il ne s'agit pas d'un nouveau format de fichier. La prise en charge des actifs cryptographiques a été versée dans CycloneDX, la spécification de nomenclature portée par l'OWASP, publiée comme norme Ecma International, ECMA-424. Un CBOM est donc un document CycloneDX dont les champs cryptographiques sont renseignés. Il se valide avec le même schéma, transite par les mêmes chaînes de construction et atterrit dans le même registre d'artefacts que les SBOM qu'un établissement produit déjà pour sa chaîne d'approvisionnement.

Cela pèse plus lourd qu'il n'y paraît. Ce qui sépare une norme qui s'installe d'une norme qui s'enlise, c'est en général la nécessité ou non de nouvelle plomberie. Celle-ci n'en demande pas.

Tableau 2 : classes d'actifs du CBOM et question de migration à laquelle chacune répond

Classe d'actif	Ce qui est consigné	La question à laquelle elle répond
Algorithme	Primitive, taille de clé, mode, courbe, remplissage, et la fonction assurée	Lesquelles de nos opérations sont vulnérables au quantique, et à quelle force de paramètres ?
Clé	Type, taille, format, état, et lieu de résidence du matériel cryptographique	Quelles clés sont protégées par un HSM et lesquelles séjournent en mémoire applicative ?
Certificat	Sujet, émetteur, algorithme de signature, fenêtre de validité	Qu'est-ce qui expire avant la fenêtre de migration, et qu'est-ce qui est signé avec un algorithme déprécié ?
Protocole	Protocole et version, avec les suites de chiffrement proposées	Qu'est-ce qui est réellement négocié sur le lien, par opposition à ce qu'affirme le fichier de configuration ?
Composant associé	La bibliothèque, la version et l'emplacement de code qui mettent en œuvre ce qui précède	Si cette bibliothèque est remplacée, qu'est-ce qui bouge avec elle ?

La dernière ligne est celle qui transforme un inventaire en plan. Une liste d'algorithmes vous donne la taille du problème. Une liste d'algorithmes jointe aux composants qui les implémentent vous donne la forme du travail — et c'est de cela qu'une séquence de migration est faite.

Le recensement, ce sont quatre problèmes, pas un

Traiter le recensement comme un chantier unique est la façon la plus courante de faire échouer ces programmes. Ce sont quatre problèmes distincts, avec quatre outillages, quatre responsables et des niveaux de confiance très différents.

1. Le code source — ce que le code demande. L'analyse statique de vos propres dépôts repère les appels cryptographiques, les paramètres codés en dur et les bibliothèques invoquées. L'outillage ouvert existe : le projet CBOMkit et son greffon SonarQube détectent les actifs cryptographiques dans le source et produisent du CycloneDX. Confiance maximale, couverture la plus étroite — il ne voit que le code que vous avez écrit et que vous compilez encore.

2. Les binaires et les conteneurs — ce qui part réellement en production. L'analyse du source rate tout ce qui arrive en dépendance compilée ou cuit dans une image de base. Le balayage des conteneurs et des systèmes de fichiers comble une partie de l'écart. Attendez-vous à ce que les deux vues divergent ; la divergence est elle-même un constat.

3. Le réseau — ce qui est véritablement négocié. La configuration est une intention, pas une observation. L'observation passive des négociations TLS réelles sur le parc est le seul moyen d'apprendre qu'un service qui documente TLS 1.3 accepte encore quelque chose de plus ancien avec une contrepartie interne qui n'a jamais été mise à niveau. Dans un parc de paiement, c'est souvent cette contrepartie-là qui compte.

4. Le parc fournisseurs et matériel — ce que vous ne pouvez pas scanner du tout. Modules matériels de sécurité, terminaux de paiement, équipements réseau, sous-systèmes mainframe, et chaque prestataire SaaS de la chaîne. Aucun scanner n'y accède. Ce quart s'énumère en demandant, sous contrat, et c'est là que se concentre l'exposition véritable de la banque de gros, parce que les systèmes qui compensent et règlent sont fournis de façon disproportionnée par des tiers.

Le quatrième est celui par lequel commencer maintenant, parce qu'il a le délai d'obtention le plus long et qu'il ne s'agit pas d'une tâche d'ingénierie. C'est une tâche d'achats : faire entrer une clause de divulgation cryptographique et d'agilité cryptographique dans le contrat, et dans le modèle de renouvellement, pour qu'en 2028 la réponse arrive comme une obligation du fournisseur et non comme une faveur. Chaque trimestre où cette clause n'est pas dans le modèle est un trimestre de renouvellements qu'il faudra rouvrir plus tard.

En faire un contrôle plutôt qu'un projet

Le mode de défaillance sur lequel je parierais n'est pas que les banques sautent l'inventaire. C'est qu'elles le commandent en une fois, livrent en 2028 un instantané défendable, et le laissent se dégrader — parce qu'il aura été financé comme un livrable de projet post-quantique au lieu d'être bâti comme un contrôle entretenu.

Un inventaire cryptographique se dégrade plus vite qu'un registre des actifs. Les certificats tournent. Les bibliothèques sont relevées par l'automatisation des dépendances. Une image de base change et tout un service acquiert silencieusement une pile TLS différente. Un instantané pris en 2028 sera substantiellement faux dès 2029, c'est-à-dire précisément au moment où les travaux de priorisation pour 2031 en dépendront.

Trois engagements l'évitent.

Le produire dans la chaîne de construction, pas dans une enquête. Un CBOM doit être émis par le build, aux côtés du SBOM, et stocké comme artefact versionné rattaché à la livraison. Un inventaire assemblé en envoyant un questionnaire aux propriétaires d'applications est périmé à l'arrivée et ne peut pas être comparé d'une version à l'autre.

Le comparer, et alerter sur l'écart. Le signal utile n'est pas l'inventaire ; c'est sa variation. Un service qui a acquis une nouvelle dépendance cryptographique, un certificat dont la durée s'est raccourcie, un algorithme apparu là où il n'était pas — voilà les événements qui méritent un contrôle. C'est le même raisonnement qui rend la comparaison de SBOM plus utile que leur archivage.

Le joindre au registre que vous tenez déjà. Le CBOM répond à « quelle cryptographie » ; le registre de l'article 8 répond à « quelle criticité, à qui, et qu'est-ce qui en dépend ». Ni l'un ni l'autre ne constitue une priorisation à lui seul. Joints, ils produisent le seul classement qui compte : les opérations vulnérables au quantique, triées par la criticité de la fonction métier qui repose dessus. Cette jointure est le vrai livrable d'un programme de recensement, et il vaut la peine de la nommer comme telle dans le plan.

Le manuel opérationnel

Reformulez le jalon 2028 en capacité, pas en rapport. Le livrable est un inventaire entretenu, exploitable par machine, qui se régénère seul, et non un document produit une fois pour un superviseur.
Émettez des CBOM depuis le build dès maintenant, sur les nouveaux services d'abord. Ne tentez pas le parc en une passe. Câblez-le dans la chaîne de construction pour tout ce qui est bâti ou substantiellement modifié cette année, afin que la couverture s'accumule au lieu d'exiger une campagne.
Mettez la clause contractuelle dans le modèle de renouvellement ce trimestre. Divulgation cryptographique et engagement d'agilité cryptographique. C'est le point de la liste au délai le plus long, et il ne dépend d'aucune décision d'outillage.
Lancez l'observation réseau sur les chaînes de paiement et de règlement d'abord. C'est là que l'écart entre configuration et réalité fait le plus de dégâts et que les contreparties héritées se concentrent.
Joignez le CBOM au registre de l'article 8 et classez sur la jointure. Publiez la liste ordonnée. C'est l'artefact qui convertit un inventaire d'ingénierie en conversation de conseil d'administration sur le séquencement et l'argent.
Comparez chaque régénération et alertez sur les nouvelles dépendances vulnérables au quantique. Un inventaire sans comparaison est une archive.

Les établissements qui aborderont 2031 sereinement ne sont pas ceux qui ont la vision la plus avancée de ML-KEM. Ce sont ceux qui savent répondre, n'importe quel matin et sans lancer de projet, à la question de savoir où se trouve réellement leur cryptographie.

Foire aux questions

Un CBOM est-il autre chose qu'un SBOM ?
C'est le même type de document, avec d'autres champs renseignés. La prise en charge des actifs cryptographiques a été versée dans CycloneDX, publié sous ECMA-424 : un CBOM se valide donc contre le même schéma et transite par le même outillage qu'un SBOM. Les établissements qui produisent déjà des SBOM en sont plus proches qu'ils ne le supposent.

DORA impose-t-il un inventaire cryptographique ?
Pas en ces termes. L'article 8 du règlement (UE) 2022/2554 impose l'identification, la classification et la documentation des actifs TIC ainsi que la cartographie de leur configuration et de leurs interdépendances. Les propriétés cryptographiques ne figurent pas parmi les attributs qu'il oblige à consigner, ce qui explique qu'un registre conforme à l'article 8 ne puisse répondre à une question de vulnérabilité au quantique sans être étendu.

Pourquoi le recensement doit-il s'achever aussi longtemps avant la migration ?
Parce qu'il est l'entrée de la priorisation. Les orientations du NCSC fixent le recensement à 2028 et la migration prioritaire à 2031 précisément pour ménager un intervalle défini dans lequel classer le parc et séquencer les travaux. Comprimer les deux revient à migrer ce qui est le mieux compris plutôt que ce qui compte le plus.

Comment inventorier la cryptographie logée dans le matériel fournisseur et le SaaS ?
On ne la scanne pas ; on en exige la divulgation. Les modules matériels de sécurité, les équipements de paiement et les prestataires de services doivent être couverts par une obligation contractuelle de divulgation cryptographique et d'agilité cryptographique. Comme cela dépend des cycles de renouvellement plutôt que de l'effort d'ingénierie, c'est le délai le plus long de tout le programme et cela doit commencer en premier.

Faut-il attendre que l'outillage mûrisse avant de commencer ?
Non, et l'argument de l'outillage sert généralement de paravent à l'argument budgétaire. Des implémentations ouvertes produisent déjà des inventaires cryptographiques CycloneDX depuis le source et depuis les images de conteneurs, et la spécification est une norme ratifiée. La contrainte sur le jalon 2028, c'est la couverture et la portée contractuelle, pas la disponibilité des outils.

Références

Parlement européen et Conseil de l'Union européenne, 2022. Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA). Bruxelles : Journal officiel de l'Union européenne. Disponible sur : Parlement européen et Conseil de l'Union européenne, 2022..
National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. Londres : NCSC. Disponible sur : National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Gaithersburg : U.S. Department of Commerce. Disponible sur : National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg : U.S. Department of Commerce. Disponible sur : National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield : OWASP Foundation. Disponible sur : OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield : OWASP Foundation. Disponible sur : OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk : IBM. Disponible sur : IBM Research, 2026..

Dernière révision 2026-08-05.

Republier cet article

On ne migre pas ce que l'on ne sait pas énumérer : le CBOM manquant — Sebastien Rousseau

L'échéance de recensement 2028 du NCSC précède toute échéance de migration. Les banques ne peuvent la tenir : le registre DORA ignore la cryptographie.

Cet article est sous licence Creative Commons Attribution 4.0 International. La republication nécessite l'attribution à l'URL canonique.

On ne migre pas ce que l'on ne sait pas énumérer : le CBOM manquant — Sebastien Rousseau

L'échéance de recensement 2028 du NCSC précède toute échéance de migration. Les banques ne peuvent la tenir : le registre DORA ignore la cryptographie.

Originally published at https://sebastienrousseau.com/fr/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banques-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FONDATEUR · INGÉNIEUR