Nomenclature des composants d’IA (AIBOM) : guide complet

Une nomenclature des composants d’IA (AIBOM) est un inventaire structuré des jeux de données, des modèles et des dépendances d’un système d’IA, apportant de la transparence à la chaîne d’approvisionnement de l’IA.

Qu’est-ce qu’une nomenclature des composants IA (AIBOM) ?

En mai 2026, un dépôt Hugging Face malveillant se faisant passer pour une version officielle d’OpenAI a atteint la première place des tendances de la plateforme avant d’être signalé et supprimé. Ayant copié la véritable fiche du modèle presque ligne par ligne, l’annonce paraissait légitime, et toute personne l’ayant déjà récupérée n’avait aucun moyen de le savoir, car une analyse des dépendances logicielles inspecte les bibliothèques et les packages tandis que la compromission se trouvait dans le modèle lui-même.

Une nomenclature des composants IA (AIBOM) vous apporte ce que cette analyse ne pouvait pas fournir : un moyen de savoir si un modèle compromis ou un jeu de données empoisonné se trouve déjà dans votre environnement.

Une AIBOM est un inventaire structuré des jeux de données, modèles, frameworks et dépendances qui composent un système d’IA, avec la provenance de chaque composant consignée. Elle couvre les actifs dont l’origine n’est autrement pas documentée : données tierces, modèles préentraînés et bibliothèques open source.

Comment une AIBOM se rapporte à une nomenclature logicielle

Une nomenclature logicielle répertorie les composants logiciels et les dépendances d’une application : bibliothèques, packages, identifiants de version et licences. Une AIBOM étend cette pratique d’inventaire aux actifs spécifiques à l’IA, notamment les données d’entraînement, les poids de modèle, la provenance du modèle et les références de performance. CycloneDX, la norme BOM de l’OWASP, met cela en œuvre en définissant SBOM et AI/ML-BOM comme des types de BOM interopérables.

Composants principaux d’une AIBOM

Une AIBOM consigne l’ensemble complet des composants qui définissent la composition, l’origine et le profil opérationnel d’un système d’IA. Les recommandations de mai 2026 du groupe de travail G7 sur la cybersécurité, publiées sous la forme des éléments minimaux AI SBOM de la CISA, organisent ces composants en sept groupes.

Groupe de composants	Ce qu’il capture	Pourquoi il est nécessaire
Métadonnées	Auteur de l’AIBOM, date de création, version du schéma, identifiant du document	Établit la chaîne de conservation de l’artefact d’inventaire
Propriétés au niveau système	Dépendances logicielles, frameworks, environnements d’exécution, logique de traitement des données	Correspond au contenu traditionnel d’un SBOM ; permet le suivi des CVE
Modèles	Identité du modèle, architecture, mode de production des poids (entraîné, affiné ou distillé), limites documentées	Les poids de modèle n’ont pas d’équivalent de gestionnaire de packages ; la provenance permet d’identifier les altérations
Propriétés des jeux de données	Identité, provenance, licence, méthodologie de collecte et prétraitement appliqué aux jeux de données d’entraînement, de validation et de test	L’empoisonnement des données est indétectable par l’analyse logicielle ; les enregistrements de provenance permettent de retracer si les données d’entraînement ont été altérées
Indicateurs clés de performance	Références d’exactitude, d’équité et de résilience face aux attaques enregistrées au déploiement	Établit des références comportementales ; une dégradation peut indiquer une manipulation adverse
Infrastructure	Infrastructure physique et virtuelle, liens vers une nomenclature matérielle pour le matériel IA spécialisé (GPU, TPU)	Documente l’environnement de calcul qui a produit et exécute le modèle
Structure du document et cadence de mise à jour	Gestion des versions du format AIBOM, déclencheurs de mise à jour, enregistrements des transitions du cycle de vie	Définit quand et comment l’inventaire est mis à jour ; relie chaque transition du cycle de vie aux modifications requises dans les groupes concernés

Ces sept groupes décrivent ce que contient une AIBOM. Le moment où vous renseignez chacun d’eux dépend du cycle de vie du modèle : l’enregistrement se construit par étapes, et non en un seul passage.

Comment une AIBOM est générée et maintenue tout au long du cycle de vie du modèle

Un enregistrement AIBOM prend forme au fil de quatre étapes du cycle de vie, chaque étape alimentant des groupes spécifiques de la taxonomie des composants ci-dessus.

1. Approvisionnement et préparation des données. L’AIBOM commence ici avec les propriétés des jeux de données : vous capturez l’identité, la provenance, la licence et l’intégrité de chaque jeu de données d’entraînement, de validation et de test avant le début de l’entraînement du modèle. Mettez à jour ce groupe lors de la collecte initiale et à chaque événement de réentraînement ou d’affinage.
2. Entraînement et affinage du modèle. Lors de l’entraînement, vous enregistrez le lien entre les jeux de données d’entrée, le code d’entraînement, les configurations d’hyperparamètres et les poids de modèle résultants. Les événements d’affinage nécessitent des mises à jour à la fois du groupe des modèles et du groupe des jeux de données.
3. Build et déploiement. Au déploiement, vous renseignez entièrement le groupe Propriétés au niveau système avec les dépendances logicielles, les frameworks et les détails de l’environnement d’exécution. Les valeurs de référence KPI sont enregistrées. Les composants d’infrastructure sont documentés ou liés via un HBOM.
4. Surveillance et maintenance continues. La maintenance de l’AIBOM est pilotée par les événements. Les changements apportés à tout composant dans les sept groupes déclenchent des mises à jour, y compris les modèles réentraînés, les dépendances corrigées, les versions de jeux de données et les changements d’infrastructure. Les outils de découverte autonome et les formats lisibles par machine maintiennent l’exactitude de l’enregistrement en le mettant à jour lorsque des changements surviennent.

Au cours de ces quatre étapes, une AIBOM ne reste fiable que si son format et ses règles de mise à jour sont fixés à l’avance, ce que précisent les normes actuelles.

Normes et cadres AIBOM

Quatre normes interconnectées constituent la base faisant actuellement autorité pour la mise en œuvre d’une AIBOM. Chacune traite une couche différente de la pile de gouvernance.

1. NIST AI Risk Management Framework. Le Risk Management Framework de l’IA du NIST établit la traçabilité et la responsabilité comme propriétés fondamentales d’une IA digne de confiance. Sa première version, AI RMF 1.0, a défini cette base en janvier 2023, et le Generative AI Profile l’a étendue aux systèmes génératifs en juillet 2024. Le rapport d’avril 2025 du NIST AI 100-5e2025 relie explicitement les chaînes d’approvisionnement IA aux mécanismes SBOM, en citant les fiches de modèle et de données aux côtés des nomenclatures logicielles comme instruments de transparence.
2. OWASP CycloneDX ML-BOM. La capacité ML-BOM, introduite dans CycloneDX v1.5 et étendue dans les versions ultérieures, représente les jeux de données, les modèles et les configurations des systèmes IA/ML, y compris la documentation de provenance et les considérations éthiques relatives aux jeux de données.
3. SPDX 3.0 AI and Dataset Profiles. SPDX, une norme ISO/IEC, a ajouté des profils IA et jeux de données dans la version 3.0. Ces profils documentent les modèles d’IA, les données d’entraînement, les modèles de prompts, les agents IA et les licences.
4. Éléments minimaux CISA et G7. La CISA a publié les éléments minimaux de SBOM couvrant les logiciels d’IA en août 2025. En mai 2026, les agences de cybersécurité de tous les États membres du G7 ainsi que de l’UE ont publié des recommandations conjointes définissant sept groupes d’éléments potentiels pour les AI SBOM, présentés dans les recommandations conjointes du G7.

L’adoption des AIBOM en est encore à ses débuts, et les mises en œuvre actuelles sont souvent incomplètes ou inexactes. Mais les normes vous donnent une base sur laquelle vous appuyer.

Pourquoi une AIBOM est importante pour la sécurité, la conformité et l’auditabilité

Pour la sécurité, une AIBOM enregistre la provenance des jeux de données et les sommes de contrôle des poids de modèle afin que les équipes puissent déterminer si des modèles ont été entraînés sur des données altérées. Lorsque des vulnérabilités ou des composants compromis affectent l’infrastructure IA, l’AIBOM vous indique quels systèmes sont concernés.

Pour la conformité, l’EU AI Act comprend des obligations de transparence et de documentation pour certains systèmes et modèles d’IA, notamment la documentation technique et les résumés du contenu d’entraînement. Une AIBOM soutient ces obligations en créant un enregistrement structuré de la composition.

Pour l’auditabilité, l’AIBOM donne aux auditeurs et aux équipes de réponse aux incidents une réponse traçable et versionnée lorsqu’ils demandent à partir de quoi un système d’IA spécifique a été construit. L’enregistrement montre quels jeux de données l’ont entraîné, quels poids de modèle sont déployés et quels frameworks et dépendances le prennent en charge. Sans cet enregistrement, votre réponse à toute question d’audit sur la composition de l’IA n’est, au mieux, qu’un effort de reconstitution.

Chacun de ces résultats suppose que l’enregistrement est exact et à jour. Atteindre cet état à l’échelle de l’entreprise se heurte à des contraintes structurelles que les seuls efforts ne suffisent pas à éliminer.

Défis liés à la mise en œuvre d’une AIBOM

Les contraintes structurelles rendent la mise en œuvre d’une AIBOM difficile, quel que soit le niveau de maturité ou les ressources de l’organisation.

• Immaturité des normes et des outils. CycloneDX ML-BOM, les profils IA de SPDX 3.0 et les recommandations du G7 sont tous arrivés récemment, de sorte que les pratiques et les outils sont encore en cours de stabilisation.
• Modèles tiers opaques. Les modèles fondamentaux propriétaires accessibles via des API d’inférence révèlent peu de choses sur leurs composants internes. Vous pouvez enregistrer le nom, la version, le point de terminaison, les contrôles d’accès et les attestations du fournisseur, mais la composition complète des modèles fermés reste hors de portée.
• Provenance des données d’entraînement. Pour les modèles entraînés en externe, la provenance peut ne jamais être divulguée. Pour les modèles internes, vous devez la capturer pendant l’entraînement, car une reconstitution a posteriori n’est pas fiable.
• Versionnage rapide des modèles. Chaque réentraînement ou changement de paramètre crée une nouvelle version effective avec son propre profil de risque, produisant une prolifération des versions qu’aucun processus manuel ne peut suivre à grande échelle.
• Environnements hétérogènes. L’IA d’entreprise couvre les fournisseurs cloud, l’infrastructure sur site, les outils d’IA SaaS, l’IA intégrée dans des applications tierces, les systèmes agentiques et les bases de données vectorielles.

Ces contraintes sont externes, donc le mieux que vous puissiez faire est de concevoir autour d’elles. Les échecs de la section suivante sont l’inverse, et il vous appartient de les prévenir.

Erreurs courantes de mise en œuvre d’une AIBOM

Erreur	Conséquence
Traiter l’AIBOM comme un document ponctuel produit pour un audit	La réponse aux incidents prend des décisions à partir d’un enregistrement qui ne reflète plus la production
Maintenir l’inventaire manuellement	Le rythme des changements de modèles, de jeux de données et d’API dépasse tout processus opéré par des humains, de sorte que l’enregistrement devient obsolète
Enregistrer les noms et versions des modèles sans provenance	L’empoisonnement des données et des modèles reste impossible à identifier, car l’identification dépend de la lignée d’entraînement, des sommes de contrôle des poids et des métadonnées d’exécution qui ne peuvent pas être reconstruites après coup
Exploiter l’AIBOM comme un fichier de conformité autonome déconnecté des outils d’ingénierie	Deux inventaires se forment et divergent ; les recommandations SBOM de la CISA définissent la nomenclature comme un inventaire imbriqué pour le risque de la chaîne d’approvisionnement, et exécuter l’AIBOM en dehors de la chaîne d’outils SBOM rompt ce lien
Limiter le périmètre de l’inventaire à l’IA approuvée par l’IT et omettre l’ IA fantôme	Un angle mort systématique demeure dans l’enregistrement

Chaque erreur ci-dessus est un choix de processus, donc chacune a une correction de processus. Les pratiques ci-dessous transforment l’inventaire d’un fichier statique en un contrôle opérationnel.

Bonnes pratiques AIBOM

Les actions suivantes font évoluer votre programme AIBOM d’une documentation statique vers un instrument de gouvernance opérationnel.

• Déployez la découverte et la génération autonomes. Intégrez-les aux registres de modèles, aux passerelles API et aux inventaires des services cloud d’IA.
• Standardisez sur un format lisible par machine. Produisez CycloneDX ML-BOM ou les profils IA de SPDX 3.0. Les feuilles de calcul lisibles par l’humain ne peuvent pas alimenter les workflows qui opérationnalisent la valeur de sécurité de l’inventaire.
• Capturez la provenance à la source. Enregistrez les identifiants des jeux de données d’entraînement et d’affinage, les sommes de contrôle des poids de modèle, les métadonnées des exécutions d’entraînement et les versions figées des API d’inférence. Pour les modèles internes, instrumentez le suivi de provenance dans le pipeline ML au moment de l’entraînement.
• Conditionnez le CI/CD à l’AIBOM. Générez l’AIBOM lors de la création des artefacts d’entraînement, des événements de push vers le registre et des changements de configuration de déploiement, et considérez une AIBOM manquante ou obsolète comme un échec du pipeline qui bloque la promotion vers l’environnement suivant.
• Surveillez en continu la dérive. Comparez les hachages des artefacts de modèle déployés aux hachages enregistrés dans l’AIBOM à chaque événement de déploiement. Une cadence pilotée par les événements est ce qui distingue un enregistrement de gouvernance d’un document obsolète.
• Détectez l’IA fantôme par découverte active. Identifiez les connexions vers des points de terminaison d’inférence IA connus et ajoutez les actifs découverts à l’AIBOM avec une classification explicite de risque non gouverné.

Ces pratiques transforment votre AIBOM d’un artefact d’audit en un enregistrement vivant. Leur exécution à l’échelle du cloud nécessite des outils, et c’est là qu’intervient l’AI Security Posture Management de SentinelOne.

Améliorez la gouvernance AIBOM avec SentinelOne

Une AIBOM n’est valable que si la découverte qui l’alimente l’est aussi. Singularity Cloud Security, la Cloud-Native Application Protection Platform de SentinelOne, construit et maintient une AIBOM dans les environnements cloud grâce à sa capacité AI Security Posture Management (AI-SPM), avec Data Security Posture Management (DSPM) intégré pour la couche de données.

• Une découverte qui alimente l’inventaire. AI-SPM détecte les pipelines IA, les modèles ML et les dépendances exécutés dans votre environnement, y compris les tâches sur des services comme Amazon SageMaker. Comme il couvre à la fois l’IA approuvée et l’IA fantôme, chaque composant qu’il énumère devient une entrée AIBOM potentielle sans angle mort silencieux.
• Contexte de risque au-dessus de l’enregistrement. Les contrôles de configuration et Verified Exploit Paths montrent quels composants catalogués sont mal configurés ou exploitables, et DSPM empêche les données à haut risque d’entrer dans les pipelines IA grâce à une barrière safe-to-train. Prompt Security inspecte les prompts et les réponses et gouverne l’IA agentique, étendant votre gouvernance AIBOM à la couche d’exécution.
• Validation sur l’ensemble de la plateforme. La Singularity Platform unifie la télémétrie des endpoints, du cloud et des identités dans un seul lac de données, afin que vous puissiez confirmer que l’environnement déployé correspond toujours à votre AIBOM. En cas de dérive, Purple AI intervient, un analyste en langage naturel qui enquête de manière autonome sur ces mêmes données. Selon IDC, les clients de Purple AI ont constaté une identification des menaces 63 % plus rapide et une réduction de 55 % du délai moyen de réponse (MTTR). 

Réservez une démo SentinelOne pour évaluer le risque de votre chaîne d’approvisionnement IA et construire un programme de gouvernance IA défendable dans vos environnements cloud.

Points clés à retenir

Une AIBOM inventorie les jeux de données, modèles, frameworks et dépendances derrière un système d’IA et consigne l’origine de chaque composant. Elle étend la pratique établie du SBOM aux actifs spécifiques à l’IA tels que les données d’entraînement, les poids de modèle et la provenance du modèle. 

Les normes du NIST, d’OWASP CycloneDX, de SPDX et du G7 définissent ce qu’une AIBOM enregistre. L’inventaire est important pour la sécurité, la conformité et l’auditabilité, mais nécessite une découverte autonome, des formats lisibles par machine, la capture de la provenance et une intégration CI/CD pour rester exact à mesure que les modèles évoluent. Correctement mise en œuvre, l’AIBOM cesse d’être de la paperasse et devient un contrôle exploitable.

FAQ

Qu’est-ce qu’une nomenclature des composants d’IA ?

Une nomenclature d’IA, ou AIBOM, est un inventaire lisible par machine des composants d’un système d’IA : ses jeux de données, modèles, frameworks, dépendances logicielles et métadonnées telles que la provenance et les licences. Son objectif est opérationnel.

Lorsqu’un modèle s’avère compromis ou qu’un jeu de données se révèle empoisonné, l’AIBOM est ce qui vous permet de déterminer, preuves à l’appui, lesquels de vos systèmes contiennent ce composant et à quel moment il y est entré. Sans cela, cette réponse devient un effort de reconstitution sous contrainte de temps.

Pouvez-vous créer une AIBOM pour un modèle fermé ou tiers ?

Partiellement. Pour un modèle de fondation fermé accessible via une API d’inférence, vous ne pouvez pas enregistrer la composition interne complète, car le fournisseur ne divulgue ni ses données d’entraînement ni ses poids. Vous pouvez néanmoins capturer et figer ce qui est connaissable : nom du modèle, version, point de terminaison de l’API, contrôles d’accès, et toute attestation du fournisseur. 

Enregistrez-les comme une entrée AIBOM de premier ordre et marquez explicitement les champs non divulgués, afin que l’inventaire montre où la transparence s’arrête et ne laisse aucun vide implicite.

Que doit inclure une AIBOM ?

Les directives de mai 2026 du G7 organisent le contenu de l’AIBOM en sept catégories : métadonnées, propriétés logicielles au niveau du système, identité du modèle et provenance des poids, propriétés du jeu de données, indicateurs clés de performance, documentation de l’infrastructure et structure du document avec enregistrements de la cadence de mise à jour. 

Ensemble, ces catégories documentent la manière dont un système d’IA a été construit, sur quoi il s’exécute et comment l’inventaire évolue tout au long du cycle de vie.

Quelles normes s’appliquent aux AIBOM ?

Quatre normes et cadres structurent les pratiques actuelles de l’AIBOM. Le cadre de gestion des risques liés à l’IA du NIST définit les attentes en matière de gouvernance et de traçabilité. OWASP CycloneDX ML-BOM et les profils IA de SPDX 3.0, une norme ISO/IEC, fournissent des spécifications de format lisibles par machine pour les modèles et les jeux de données. 

Les éléments minimaux du SBOM du CISA et les orientations en sept groupes du G7 définissent ce que la transparence des systèmes d’IA doit couvrir. Ensemble, ils étendent les approches SBOM établies aux modèles d’inventaire de l’IA.

Comment maintenir une AIBOM à jour à mesure que les modèles évoluent ?

Traitez l’AIBOM comme un enregistrement piloté par les événements lié à votre pipeline ML. Déclenchez des mises à jour lors de la création d’artefacts d’entraînement de modèle, des événements de push vers le registre, du réentraînement, du fine-tuning et des modifications de configuration de déploiement. Comparez les hachages des modèles déployés aux hachages enregistrés et générez une alerte sur les nouveaux endpoints d’inférence ou les entrées de registre sans enregistrement AIBOM correspondant.

Les outils de gestion de la posture de sécurité de l’IA peuvent exécuter ces contrôles en continu et signaler la dérive au moment où elle se produit. Lorsque la génération est une étape CI/CD requise, des inventaires obsolètes empêchent la promotion avant qu’un modèle non gouverné n’atteigne la production.