AI-BOM : sauriez-vous retrouver tous les systèmes exposés si un composant IA devenait vulnérable ?

Quand une vulnérabilité affecte une bibliothèque logicielle, un SBOM classique peut aider à identifier les applications qui l’utilisent.

Avec l’intelligence artificielle, la question devient plus complexe.

Un système d’IA ne dépend pas seulement de bibliothèques logicielles. Il peut aussi s’appuyer sur plusieurs modèles, jeux de données, frameworks, services externes, composants d’infrastructure et API. Certains sont développés en interne. D’autres proviennent de fournisseurs ou de projets open source. Certains peuvent encore évoluer après leur mise en production.

En mai 2026, le groupe de travail cybersécurité du G7 a publié des éléments minimums pour un SBOM adapté à l’IA. L’ANSSI présente ce dispositif comme une cartographie de la chaîne d’approvisionnement de l’IA, des composants déployés et de leurs dépendances. L’objectif est notamment d’améliorer la traçabilité et de réduire le temps de réaction face aux vulnérabilités et aux failles de sécurité.1

L’enjeu opérationnel peut donc se résumer ainsi :

si un modèle, un dataset, une bibliothèque ou un service externe devient compromis demain matin, combien de temps faudra-t-il pour identifier tous les systèmes réellement concernés ?

Un SBOM logiciel ne décrit qu’une partie d’un système d’IA

Les principes du SBOM restent valables pour l’IA.

Un système d’IA est aussi un système logiciel : il utilise des packages, des versions, des composants tiers et des relations de dépendance. Le travail international conduit par l’ANSSI et dix-neuf autres autorités en 2025 rappelle justement que le SBOM permet d’identifier les composants logiciels et d’agir plus rapidement lorsqu’une vulnérabilité apparaît.2

Mais ces informations ne suffisent pas toujours pour comprendre un système d’IA.

Prenons un assistant interne de type RAG.

L’application peut utiliser :

• un front-end et une API métier ;
• plusieurs bibliothèques Python ;
• un modèle de langage ;
• un modèle d’embedding ;
• une base vectorielle ;
• des documents internes ;
• une API externe ;
• une infrastructure GPU ou cloud ;
• différents mécanismes de sécurité.

Un inventaire limité aux dépendances logicielles peut correctement identifier la version d’une bibliothèque Python tout en restant incapable de répondre à une question essentielle :

quelles applications utilisent le même modèle ou le même jeu de données ?

C’est précisément l’une des différences entre un SBOM traditionnel et un SBOM enrichi pour l’IA.

Le G7 propose sept familles d’informations

Le document publié en 2026 ne remplace pas les informations d’un SBOM logiciel classique. Il les complète avec des éléments propres aux systèmes d’IA.

Les éléments sont organisés autour de plusieurs familles : métadonnées du SBOM, propriétés du système, modèles, datasets, infrastructure, propriétés de sécurité et indicateurs de performance.1

Cela change fortement l’unité que l’on cherche à documenter.

On ne s’intéresse plus uniquement à un composant logiciel et à sa version, mais à l’ensemble d’une chaîne technique.

| Domaine | Exemple de ce qu’il devient utile de connaître | |---|---| | Système | composants constituant le système et relations entre eux | | Flux de données | origine, destination et usage des données | | Modèles | modèle utilisé, version, provenance et propriétés | | Datasets | identité, provenance, usage et sensibilité | | Logiciels | packages, versions et dépendances | | Infrastructure | ressources nécessaires au fonctionnement | | Sécurité | mécanismes de protection et vulnérabilités connues | | Services externes | API et dépendances hors du contrôle direct de l’organisation |

Le principe est moins de produire une liste exhaustive que de rendre visibles les relations nécessaires pour évaluer un impact.

Le véritable objet à cartographier est la chaîne de dépendances

Une CMDB peut indiquer qu’une application possède un composant « IA ».

Un catalogue de modèles peut indiquer qu’un modèle précis est utilisé dans l’entreprise.

Un registre de données peut répertorier certains jeux de données.

Un gestionnaire de dépendances peut connaître les packages installés.

Pris séparément, chacun de ces inventaires peut être juste.

Le problème apparaît lorsqu’il faut les relier.

Pour traiter une alerte de sécurité, une représentation utile pourrait suivre une chaîne de ce type :

service métier → application → système IA → modèle → dataset → logiciel → infrastructure → service externe → fournisseur

Cette représentation n’est pas une structure réglementaire imposée par le G7. C’est une traduction opérationnelle de l’objectif de traçabilité décrit par les travaux sur le SBOM pour l’IA.

Elle permet surtout d’effectuer une analyse dans les deux sens.

À partir d’une application, on peut déterminer ses dépendances.

Mais à partir d’un composant vulnérable, il faut également pouvoir remonter vers toutes les applications qui en dépendent.

C’est cette seconde capacité qui devient déterminante lors d’un incident.

Cas construit : une bibliothèque vulnérable utilisée par trois assistants IA

Prenons une entreprise fictive qui a développé trois systèmes d’IA.

Le premier est un assistant destiné au support client.

Le deuxième aide les équipes juridiques à rechercher des clauses contractuelles.

Le troisième résume automatiquement des documents techniques.

Les trois applications sont gérées par des équipes différentes.

Elles utilisent pourtant le même framework open source pour orchestrer leurs appels aux modèles.

Une vulnérabilité critique est publiée sur ce framework.

Avec un inventaire logiciel correctement maintenu, l’entreprise peut probablement identifier rapidement les applications utilisant le package vulnérable.

Mais imaginons maintenant que le problème ne concerne pas le framework.

Il concerne un modèle d’embedding fourni par un tiers.

Ce modèle est directement déclaré dans l’assistant juridique. Dans l’application support, il est appelé indirectement via un service interne. Dans le troisième système, il est inclus dans une plateforme mutualisée administrée par l’équipe Data.

Trois architectures différentes dépendent donc du même composant.

Un inventaire organisé uniquement par application risque de masquer cette dépendance commune.

Une AI-BOM exploitable doit permettre l’opération inverse :

composant affecté → systèmes utilisant ce composant → applications → processus métier → responsables

La rapidité de cette remontée détermine une partie du temps nécessaire pour mesurer l’exposition réelle.

Les modèles eux-mêmes doivent devenir des objets versionnés

Dans beaucoup d’organisations, une application possède une version explicite alors que le modèle qu’elle utilise est parfois décrit uniquement par son nom commercial.

C’est insuffisant pour une véritable traçabilité.

Deux versions d’un même modèle peuvent présenter des comportements, dépendances ou caractéristiques de sécurité différents.

Le document G7 prévoit donc des informations permettant notamment d’identifier le modèle, son producteur, sa version et certaines propriétés relatives à sa création et à son utilisation.1

Cette logique doit également être appliquée aux modèles consommés via API.

Si un fournisseur change silencieusement le modèle situé derrière un alias générique, la composition réelle du système peut évoluer alors même qu’aucun déploiement applicatif n’a eu lieu.

Une organisation doit donc pouvoir distinguer au minimum :

le service demandé, le modèle réellement utilisé et la version ou l’état de ce modèle à un instant donné.

Sinon, l’inventaire décrit une architecture théorique plutôt que celle qui fonctionne réellement.

La provenance des datasets devient une information de sécurité

Un logiciel peut être reproduit à partir de son code source et de ses dépendances.

Pour un modèle d’IA, le jeu de données fait partie de son histoire.

Le travail G7 demande ainsi de documenter des informations relatives aux datasets utilisés au cours du cycle de vie, notamment leur identité, leur provenance et leur usage.1

Cette information n’est pas seulement utile pour les équipes Data ou juridiques.

Elle peut devenir une donnée de cybersécurité.

Prenons un dataset fourni par un prestataire externe et réutilisé pour entraîner quatre modèles internes.

Si sa provenance est remise en cause ou si l’on découvre qu’il a été compromis, le problème ne concerne pas uniquement le dataset.

Il faut retrouver :

dataset → entraînements concernés → modèles produits → systèmes utilisant ces modèles → services métier exposés

Sans relation entre ces objets, la réponse implique souvent des recherches manuelles auprès de plusieurs équipes.

L’AI-BOM transforme cette succession de recherches en une chaîne qui peut être interrogée.

Les API externes font partie de la surface de dépendance

Un système d’IA contemporain peut dépendre de services qui ne sont jamais installés dans le SI.

API de modèles, moteur de recherche, service de vectorisation, base hébergée ou outil de modération peuvent se trouver entièrement chez un fournisseur.

Ils n’apparaîtront donc pas nécessairement dans un inventaire logiciel local.

Pourtant, ils participent directement au fonctionnement du système.

Le document G7 intègre cette dimension en s’intéressant aux flux du système et à ses interactions avec des services externes.1

Cette dépendance est particulièrement importante lorsque plusieurs applications utilisent le même service.

Une panne, une modification de comportement, une vulnérabilité ou une compromission du fournisseur peut alors produire un effet transversal invisible si les dépendances sont documentées uniquement projet par projet.

L’AI-BOM ne doit pas devenir un fichier statique produit une fois par an

Un autre piège serait de considérer la nomenclature comme un document de conformité.

Les systèmes d’IA peuvent changer rapidement.

Une bibliothèque est mise à jour. Un dataset est enrichi. Un modèle est remplacé. Une nouvelle API est ajoutée. Un pipeline est modifié.

Le document G7 indique que le SBOM pour l’IA devra pouvoir évoluer pour tenir compte des changements rapides du domaine. Les travaux internationaux sur le SBOM soulignent également l’intérêt d’informations structurées permettant d’améliorer la gestion des vulnérabilités.12

La bonne question n’est donc pas seulement :

« avons-nous une AI-BOM ? »

Mais plutôt :

« notre AI-BOM décrit-elle encore le système qui fonctionne aujourd’hui ? »

Un inventaire parfaitement documenté mais vieux de six mois peut être moins utile qu’un inventaire plus limité mais actualisé à chaque modification significative.

Il faut distinguer composition et criticité

La nomenclature décrit ce qui compose le système.

Elle ne dit pas nécessairement ce qui est le plus important pour l’entreprise.

Pour être véritablement exploitable en cybersécurité, elle doit donc pouvoir être reliée à d’autres informations :

• propriétaire technique ;
• responsable métier ;
• criticité du service ;
• données manipulées ;
• environnement ;
• exposition Internet ;
• fournisseurs concernés ;
• processus de réponse à incident.

Cette distinction est importante.

Une AI-BOM peut indiquer que quarante systèmes utilisent un même package.

Une cartographie plus large permet d’identifier que trois d’entre eux soutiennent des processus critiques et doivent être traités en priorité.

La nomenclature fournit donc la composition.

La cartographie du SI fournit le contexte d’impact.

Les deux informations deviennent particulièrement puissantes lorsqu’elles peuvent être rapprochées.

L’objectif est de réduire le temps entre l’alerte et la connaissance de l’impact

La Commission européenne considère elle aussi que l’IA modifie profondément le paysage cyber : elle peut renforcer la défense mais également accélérer et automatiser certaines attaques. Son plan d’action publié en juillet 2026 vise à structurer la réponse européenne aux risques et opportunités que les modèles avancés d’IA créent pour la cybersécurité.3

Dans ce contexte, la qualité d’un inventaire ne devrait pas être mesurée uniquement au nombre de champs renseignés.

Un test plus utile consiste à simuler une alerte.

Choisir au hasard :

• un modèle ;
• un dataset ;
• une bibliothèque ;
• une API externe.

Puis demander :

Quels systèmes l’utilisent ?

Quelles versions ?

Dans quels environnements ?

Quels services métier dépendent de ces systèmes ?

Qui doit être contacté ?

Si ces réponses peuvent être obtenues en quelques minutes, l’organisation possède déjà une traçabilité exploitable.

Si elles nécessitent de contacter successivement les équipes Data, DevOps, Cloud et métier, le problème n’est probablement pas l’absence d’un nouvel outil de sécurité.

Il est d’abord l’absence d’une vue cohérente des dépendances de l’IA.

Et c’est précisément le problème qu’une AI-BOM bien construite doit commencer à résoudre.