Je connais déjà l’objection, parce que je me la fais à moi-même chaque fois que j’entends le mot inventaire. Encore un registre. Encore un document que quelqu’un remplit avec diligence en janvier et qui, en mars, relève déjà de l’archéologie, parce qu’entre-temps l’équipe a changé deux dépendances, un fournisseur a mis à jour ses conditions contractuelles et quelqu’un a mis en production un modèle qui n’existe pas dans le registre. Si c’est ça la promesse, l’inventaire n’est que la bureaucratie de toujours avec un nom plus technique, et celui qui le propose vend le problème déguisé en solution.
L’objection est juste. Et c’est exactement la raison pour laquelle ce texte vaut la peine d’être écrit, parce qu’elle décrit à la perfection une certaine manière de faire l’inventaire, celle qui se remplit à la main, et qui est morte d’avance. Mais confondre cette manière avec l’idée même d’inventaire, c’est ne pas voir ce qui se passe dans la régulation européenne, où cinq textes différents, écrits par des directions générales différentes, pour des secteurs différents, convergent vers la même exigence sans s’être concertés.
Cinq textes, une seule phrase
L’AI Act demande un registre des systèmes, une classification du risque, une traçabilité des données d’entraînement et des décisions. Le Cyber Resilience Act demande une nomenclature du logiciel, la fameuse SBOM, et la capacité de dire rapidement quels produits contiennent un composant vulnérable. NIS2 demande de connaître sa chaîne d’approvisionnement et de gouverner les incidents avec des délais de notification qui supposent de savoir déjà où regarder. DORA, qui parle au monde financier mais confirme le motif, demande un registre des dépendances envers les fournisseurs ICT critiques. La directive sur la responsabilité du fait des produits, dans sa nouvelle version, déplace la charge de la preuve de telle sorte que le producteur incapable de reconstituer ce qu’il y avait dans son logiciel à une date donnée part déjà perdant. Comment nous en sommes arrivés là, en partant d’une bouteille de ginger beer de 1932, je l’ai raconté dans La dernière bouteille de Mrs Donoghue.
Ce sont des langues différentes. Registre, SBOM, cartographie, dossier technique. Mais la phrase sous-jacente est unique : prouve que tu sais ce que tu as chez toi. Quels modèles, quels composants, quels fournisseurs, quelles données, quelles responsabilités, quels changements.
Non conforme ou ingouvernable
Et voici le point qui, à mon avis, est systématiquement mal compris. Une organisation qui ne sait pas répondre à ces questions n’est pas une organisation non conforme. Non conforme, c’est celui qui connaît son système et a choisi de ne pas le mettre en règle, une position qui peut se défendre, se négocier, se régulariser. Celui qui ne connaît pas son système est dans une condition différente et pire : il est ingouvernable. Il ne peut pas décider de se conformer, même en le voulant, parce qu’il ne sait pas à quoi appliquer la décision.
La stratégie de l’attente
Pendant ce temps, la stratégie la plus répandue que je rencontre est l’attente. Nous nous mettrons en règle quand la ligne directrice définitive sortira, quand l’autorité nationale clarifiera, quand le standard harmonisé arrivera, quand le Digital Omnibus stabilisera le calendrier. J’en ai parlé il y a quelques semaines : le report des échéances n’est pas une amnistie, et celui qui le lit ainsi prend un délai pour une absolution. Mais il y a une erreur plus profonde dans l’attente, et c’est l’idée que la conformité serait un contenu que quelqu’un finira par nous dicter, et que notre tâche se limiterait à le transcrire. Les lignes directrices diront comment décrire le système. Elles ne pourront jamais le décrire à notre place. Et la partie difficile, celle qui prend des mois et traverse les frontières entre les équipes, n’est pas la transcription. C’est savoir quoi écrire.
La carte qui n’existe pas
Je le vois dans le travail de tous les jours. Quand nous entrons dans un projet dans le domaine de la santé ou dans l’administration publique, la première question que nous posons ne concerne jamais la norme. Elle concerne la carte. Quelles applications sont en production, qui en est responsable, de quelles bibliothèques elles dépendent, où résident les données, quels traitements ont été évalués, quels contrats couvrent quels fournisseurs, ce qui a changé au cours des six derniers mois. La réponse honnête, presque partout, est que la carte n’existe pas. Il existe des fragments : un tableur de l’IT mis à jour il y a un an, un registre des traitements figé à la version remise au consultant, la mémoire de deux personnes qui, si elles changent de travail demain, emportent la moitié de l’architecture. Aucun de ces fragments ne parle aux autres, et aucun n’est mis à jour par les événements qui devraient l’alimenter.
Le registre mort et l’inventaire vivant
Ici revient l’objection initiale, et ici elle se dissout. Le registre qui vieillit dans un tiroir et la carte dont la compliance européenne a besoin ne sont pas la même chose faite avec plus ou moins de diligence. Ce sont deux objets de nature différente. Le premier est un document, le second est un sous-produit des processus. Une SBOM ne se remplit pas : elle se génère depuis la pipeline de build, à chaque build, et si la pipeline ne la génère pas, le problème est la pipeline, pas la volonté des gens. Un registre des systèmes d’IA ne se met pas à jour de mémoire : il se met à jour parce que le processus de mise en production d’un modèle passe par lui, et un modèle qui n’est pas dans le registre n’arrive tout simplement pas en production. Un change log n’est pas un rite : c’est la trace qui permet, quand arrive le signalement d’une vulnérabilité ou la demande d’une autorité, de reconstituer ce qu’il y avait et quand. L’inventaire vivant ne demande pas aux gens de penser à documenter. Il demande à l’architecture des processus de produire de la documentation comme effet secondaire du travail normal. C’est une différence d’ingénierie, pas de discipline, et c’est la même idée que j’ai appelée un jour la compliance comme architecture.
La fonction qui n’a pas de nom
Il y a pourtant un problème que l’ingénierie seule ne résout pas, et c’est que cette carte traverse des territoires qui, dans les organisations, ont des propriétaires différents. La SBOM vit avec ceux qui font du DevOps. Le registre des traitements vit avec le DPO. Les contrats avec les fournisseurs vivent avec les achats ou avec la direction. Les incidents vivent avec ceux qui font de la sécurité, quand il existe quelqu’un qui fait de la sécurité. Le registre IA, là où il existe, vit avec celui qui a eu le malheur de lever la main dans la mauvaise réunion. Chacune de ces pièces a un propriétaire, mais la cohérence entre les pièces n’en a aucun. Ce n’est pas un poste à recruter, et je me méfie de qui la présente comme l’énième rôle à acronyme à ajouter à l’organigramme. C’est une fonction qui aujourd’hui n’a pas de nom et qui tombe dans les creux entre le DPO, qui regarde les données personnelles, le CISO, qui regarde les menaces, et le CTO, qui regarde le produit. Quelqu’un doit tenir ensemble la nomenclature du logiciel, le registre des systèmes d’IA, les analyses d’impact, les contrats, le change log et l’historique des incidents, non pas pour les remplir mais pour garantir qu’ils racontent le même système. Dans les petites organisations, ce sera une casquette de plus sur une tête qui en porte déjà d’autres. Dans les grandes, cela deviendra un métier, dont j’ai déjà décrit l’ascension. Dans les deux cas, celui qui le fera bien tiendra entre ses mains quelque chose qui vaut plus que la conformité : la description opérationnelle de l’entreprise.
La spécification de l’organisation
Et ici je boucle la boucle avec quelque chose que j’ai écrit à propos du développement logiciel. Dans le développement guidé par les spécifications, le code devient un dérivé et la spécification devient l’actif : c’est elle qu’on maintient, qu’on versionne, qu’on discute, pendant que le code se régénère. La régulation européenne, sans le savoir, dit la même chose un niveau plus haut. Le classeur est le dérivé. L’inventaire vivant est la spécification de l’organisation, la description maintenue et versionnée à partir de laquelle les documents de conformité peuvent se régénérer chaque fois qu’une norme, une autorité ou un client les demande dans un format nouveau. Celui qui a la spécification produit le classeur en quelques jours. Celui qui n’a que des classeurs n’arrive même pas à produire la spécification, et accumule sans le voir une dette de spécification à l’échelle de l’entreprise.
Ce que 2026 récompensera
C’est pour cela que je crois que 2026 ne récompensera pas ceux qui remplissent le mieux. Les échéances se déplacent, les lignes directrices arrivent en retard, les standards harmonisés sont encore en grande partie sur le papier, et tout ce bruit de calendrier cache la véritable sélection en cours. 2026 récompensera ceux qui savent décrire leur système mieux que les autres ne décrivent le leur, aux clients qui le demandent dans les cahiers des charges, aux autorités qui le demanderont dans les inspections, et avant cela à eux-mêmes, quand il faudra décider vite quoi changer. La compliance n’est que le nom bureaucratique de cette capacité. L’inventaire est son instrument. Et aucun report n’a jamais rendu gouvernable un système que son propriétaire ne sait pas raconter.
Ce qu'il faut retenir
Cinq réglementations européennes, écrites par des directions générales différentes pour des secteurs différents, convergent vers la même exigence sans s’être concertées : l’AI Act, le CRA, NIS2, DORA et la PLD demandent toutes, avec des mots différents, de prouver que tu sais ce que tu as chez toi.
Non conforme, c’est l’organisation qui connaît son système et a choisi de ne pas le mettre en règle : une position qui peut se défendre, se négocier, se régulariser. L’organisation qui ne connaît pas son système est ingouvernable, ce qui est pire : elle ne peut pas décider de se conformer, même en le voulant.
Attendre les lignes directrices et les standards harmonisés, c’est prendre la conformité pour un contenu à transcrire. Les lignes directrices diront comment décrire le système, elles ne le décriront jamais à notre place. La partie difficile n’est pas la transcription, c’est savoir quoi écrire.
Le registre qui vieillit dans un tiroir et l’inventaire vivant sont des objets de nature différente : le premier est un document, le second un sous-produit des processus. Une SBOM ne se remplit pas, elle se génère depuis la pipeline à chaque build. C’est une différence d’ingénierie, pas de discipline.
La cohérence entre la SBOM, le registre IA, les analyses d’impact, les contrats et le change log n’a pas de propriétaire : elle tombe dans les creux entre le DPO, le CISO et le CTO. Celui qui prendra en charge cette fonction tiendra quelque chose qui vaut plus que la conformité : la description opérationnelle de l’entreprise.
Questions & réponses
Pourquoi la compliance européenne exige-t-elle un inventaire ?
Parce que cinq textes différents convergent vers la même exigence. L’AI Act demande un registre des systèmes, une classification du risque et la traçabilité des données d’entraînement. Le Cyber Resilience Act demande la SBOM et la capacité de dire rapidement quels produits contiennent un composant vulnérable. NIS2 demande de connaître sa chaîne d’approvisionnement et de notifier les incidents dans des délais qui supposent de savoir déjà où regarder. DORA demande un registre des dépendances envers les fournisseurs ICT critiques. La PLD révisée déplace la charge de la preuve de telle sorte que le producteur incapable de reconstituer ce qu’il y avait dans son logiciel à une date donnée part déjà perdant. Ce sont des langues différentes, mais la phrase sous-jacente est unique : prouve que tu sais ce que tu as chez toi.
Quelle différence entre être non conforme et être ingouvernable ?
Non conforme, c’est l’organisation qui connaît son système et a choisi de ne pas le mettre en règle : une position qui peut se défendre, se négocier, se régulariser. L’organisation qui ne connaît pas son système est dans une condition différente et pire : elle est ingouvernable. Elle ne peut pas décider de se conformer, même en le voulant, parce qu’elle ne sait pas à quoi appliquer la décision. La distinction compte, parce que la plupart des organisations qui se croient en retard sur la compliance ne sont pas en retard sur une obligation : il leur manque la carte sur laquelle toute obligation devrait s’appliquer.
Qu'est-ce qu'un inventaire vivant, et en quoi diffère-t-il d'un registre traditionnel ?
Ce sont des objets de nature différente, pas le même objet fait avec plus ou moins de diligence. Le registre traditionnel est un document : quelqu’un le remplit, puis le système change et le document vieillit. L’inventaire vivant est un sous-produit des processus : la SBOM se génère depuis la pipeline de build à chaque build, le registre des systèmes d’IA se met à jour parce que la mise en production d’un modèle passe par lui, le change log est la trace qui permet de reconstituer ce qu’il y avait et quand. Il ne demande pas aux gens de penser à documenter : il demande à l’architecture des processus de produire de la documentation comme effet secondaire du travail normal.
Qui devrait être responsable de l'inventaire dans l'entreprise ?
Chaque pièce a déjà un propriétaire : la SBOM vit avec ceux qui font du DevOps, le registre des traitements avec le DPO, les contrats avec les achats, les incidents avec ceux qui font de la sécurité. Ce qui n’a pas de propriétaire, c’est la cohérence entre les pièces, c’est-à-dire la garantie qu’elles racontent toutes le même système. Ce n’est pas forcément un poste à recruter : dans les petites organisations, ce sera une casquette de plus sur une tête qui en porte déjà d’autres, dans les grandes, cela deviendra un métier. C’est une fonction qui tombe aujourd’hui dans les creux entre le DPO, qui regarde les données personnelles, le CISO, qui regarde les menaces, et le CTO, qui regarde le produit.
Vaut-il mieux attendre les lignes directrices définitives avant de se mettre en règle ?
Non, pour deux raisons. La première, c’est que le report des échéances n’est pas une amnistie : le Digital Omnibus a déplacé quelques dates et confirmé tout le reste. La seconde est plus profonde : attendre suppose que la conformité soit un contenu que quelqu’un finira par nous dicter, et que notre tâche se limite à le transcrire. Les lignes directrices diront comment décrire le système, elles ne le décriront jamais à notre place. La partie qui prend des mois et traverse les frontières entre les équipes n’est pas la transcription : c’est savoir quoi écrire. Et cette partie n’a pas d’échéance, ne se reporte pas et ne devient pas plus facile avec le temps.
L'auteur
