Qu'est-ce qu'un AI-BOM ? La nomenclature IA que l'AI Act européen suppose que vous avez déjà

Qu'est-ce qu'un AI-BOM ?

Un AI-BOM, ou AI Bill of Materials, est un inventaire lisible par machine de tous les composants d'intelligence artificielle que contient un système logiciel, accompagné des faits de provenance et de gouvernance relatifs à chacun. Là où un SBOM liste des paquets, des versions et des licences, un AI-BOM liste des modèles, des jeux de données, des prompts, des agents, des outils et des garde-fous, et consigne d'où vient chacun, ce qu'il a le droit de faire, et dans quelle classe de risque réglementaire il tombe.

L'idée descend directement de la nomenclature logicielle. Le décret présidentiel américain 14028 a fait du SBOM une condition des achats logiciels fédéraux en 2021, et la pratique a survécu aux aléas politiques de ce décret parce qu'elle s'est révélée la seule réponse exploitable à la question « qu'est-ce qui tourne réellement ici ». Les systèmes d'IA posent la même question sur une surface plus large. Une dépendance a une version et une licence. Un modèle a une version, une licence, un fournisseur, des poids qui peuvent être locaux ou distants, un corpus d'entraînement que vous ne maîtrisez peut-être pas, un historique de fine-tuning, une configuration d'inférence, un dossier d'évaluation et une enveloppe de capacités. Rien de tout cela ne tient dans un package.json.

AI-BOM et SBOM : quelle différence ?

Ils répondent à deux questions différentes sur le même dépôt, et la différence n'est pas cosmétique. Un SBOM est une liste de choses que vous avez installées. Un AI-BOM est une liste de choses qui prennent des décisions.

La dernière ligne est celle où la plupart des outils s'arrêtent. Une dépendance se déclare dans un lockfile. Un modèle, non. openai/gpt-4o-mini apparaît sous forme de chaîne littérale dans un fichier de service. Un modèle local apparaît comme un chemin .gguf dans une config. Un serveur MCP apparaît comme une URL dans .mcp.json. Un prompt apparaît comme un fichier markdown que personne n'a déclaré nulle part. Il n'y a pas de manifeste à parser, donc un inventaire IA doit être dérivé en lisant le code lui-même.

Qu'exige réellement l'AI Act européen ?

L'article 11 impose aux fournisseurs de systèmes d'IA à haut risque d'établir une documentation technique avant la mise sur le marché ou la mise en service, et de la tenir à jour. L'annexe IV en fixe le contenu minimal. L'article 18 impose au fournisseur de conserver cette documentation, avec les enregistrements du système de management de la qualité et la déclaration UE de conformité, pendant dix ans après la mise sur le marché.

Lisez l'annexe IV comme un questionnaire et sa forme devient évidente. Ce sont neuf sections, et la majorité d'entre elles posent des questions sur ce dont le système est fait et d'où viennent ces morceaux.

Point par point, la correspondance est assez étroite pour que la tâche documentaire devienne un problème d'export pour l'essentiel du dossier, et un vrai travail d'analyse pour le reste.

Deux sections de ce tableau sont marquées comme non couvertes nativement par aucun format de nomenclature, et ce sont les deux qui consomment le plus de temps d'audit en pratique : l'exactitude par sous-groupe (§3) et la conception de la supervision humaine (§2(e)). Aucun standard de BOM n'a de champ pour « qui peut annuler cette décision, via quelle interface, avec quelle formation ». Un AI-BOM vous donne la composition. Il ne vous donne pas l'évaluation. Quiconque vous vend le contraire vous vend un tableur sous un nom neuf.

Ce qui a changé en 2026, et ce qui n'a pas bougé

L'AI Omnibus est entré en vigueur le 27 juillet 2026, après son adoption par le Parlement européen le 16 juin et par le Conseil le 29 juin. C'est une simplification ciblée de l'AI Act plutôt qu'une réécriture, et le titre en est un report.

L'Omnibus a aussi créé une catégorie « petites entreprises de taille intermédiaire », définie par moins de 750 salariés et un chiffre d'affaires inférieur ou égal à 150 millions d'euros, et lui a étendu les modèles simplifiés de documentation technique ainsi que les exigences proportionnées de management de la qualité jusqu'ici réservés aux PME. Il n'a pas touché au contenu de l'annexe IV. La liste des choses que vous devez pouvoir dire de votre système est la même qu'en 2024.

Deux autres changements de l'Omnibus comptent spécifiquement pour le travail documentaire. L'article 10(5) fournit désormais une base juridique plus claire pour traiter des données personnelles de catégorie particulière lorsque c'est strictement nécessaire pour détecter et atténuer les biais, sous réserve de garanties, ce qui lève un vrai cercle vicieux : les équipes ne pouvaient pas mesurer l'exactitude par sous-groupe parce qu'elles n'avaient pas le droit de collecter l'attribut qui leur permettrait de la mesurer. Et l'article 40(2) oblige la Commission à demander des normes unifiées couvrant conjointement l'AI Act et la législation d'harmonisation existante, pour qu'un même produit n'ait pas à satisfaire deux régimes documentaires parallèles.

Pourquoi l'inventaire est-il la partie qui échoue ?

Parce que les composants IA entrent dans un dépôt par des canaux qui n'ont pas été conçus pour être inventoriés, et qu'ils y entrent désormais plus vite que n'importe quelle cadence de revue.

La version mesurée est brutale. Le Cost of a Data Breach Report 2026 d'IBM, conduit par le Ponemon Institute auprès de 602 organisations compromises entre mars 2025 et février 2026, constate que la part des incidents de sécurité impliquant du shadow AI a plus que doublé d'une année sur l'autre.

Le shadow AI est le plus souvent présenté comme un problème d'employés : quelqu'un colle des données clients dans un chatbot grand public. Ce cadrage le sous-estime lourdement. La version la plus vaste et la plus silencieuse, c'est le shadow AI dans le dépôt. Une chaîne de modèle ajoutée à un service. Un jeu de données HuggingFace tiré dans un notebook. Un serveur MCP pointé sur une base de production le temps d'un débogage et jamais retiré. Un fichier de prompt modifié pour relâcher une contrainte. Chacun est un changement d'une ligne. Chacun modifie ce qu'est le système, et donc ce que sa documentation annexe IV devrait dire. Aucun ne s'annonce.

C'est la troisième étape qui a changé depuis la rédaction de l'AI Act. Quand un ingénieur humain choisissait un modèle, il y avait une décision, généralement une conversation, parfois un document de conception. Quand un agent de code IA écrit l'intégration, il sélectionne un modèle, une bibliothèque cliente et une configuration par défaut en une seule édition, et la trace de cette décision est un diff que personne ne lit ligne à ligne. Nous avons décrit la forme générale de ce problème dans pourquoi la plupart des findings SAST sont du bruit et dans les failles de logique métier dans le code généré par IA ; le cas de l'AI-BOM est la version gouvernance du même décalage de cadence.

“

Un inventaire tenu sous forme de document décrit le jour où il a été écrit. Un inventaire dérivé du code décrit aujourd'hui. Un seul des deux survit à un audit qui arrive dix-huit mois après la dernière réunion de revue.

Que doit attraper un inventaire IA ?

Six catégories, et chacune est un endroit où se décide la composition du système. Manquez-en une et le dossier annexe IV comporte un trou qu'un auditeur trouvera en lisant le code que vous avez vous-même fourni comme preuve.

Quel format d'AI-BOM choisir ?

CycloneDX est le choix par défaut le plus pragmatique. Il prend en charge les modèles d'apprentissage automatique depuis la version 1.5 en 2023, la spécification courante est la 1.7 (publiée le 21 octobre 2025) et elle est normalisée sous ECMA-424, donc c'est un vrai standard et non un schéma propriétaire. SPDX 3.0 propose une alternative alignée ISO via son AI Profile. Les deux sont sérialisables en JSON, les deux s'insèrent dans les pipelines SBOM existants, et les deux sont pris en charge par des outils ouverts.

Un composant ML-BOM CycloneDX minimal ressemble à ceci.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
      "name": "support-triage-v4",
      "version": "2026-06-11",
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
          "datasets": [
            { "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
          ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "accuracy", "value": "0.881", "slice": "all locales" }
          ]
        },
        "considerations": {
          "useCases": ["tier-1 support triage"],
          "technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
        }
      }
    }
  ]
}

Cela couvre l'annexe IV §1, §2(b), §2(c), §2(d) et une partie du §2(g) en un seul objet. Ce que cela ne couvre pas, et que vous porterez donc en propriétés personnalisées ou en documents séparés, se range en trois catégories.

À côté du format se trouve la couche de reporting. Le NIST AI Risk Management Framework (AI 100-1) organise le travail de risque IA en Govern, Map, Measure et Manage, et sa fonction Map est proche d'une définition de la tâche d'inventaire : documenter le contexte, les composants, les capacités et les limites du système. L'ISO/IEC 42001 exige un système de management de l'IA dont l'inventaire IA et l'évaluation des risques forment le cœur. Aucun des deux n'est un format. Les deux consomment les mêmes faits sous-jacents, ce qui est l'argument pratique pour produire ces faits une fois, mécaniquement, et les projeter ensuite dans le référentiel que parle tel auditeur ou tel questionnaire de sécurité client.

Comment construire un AI-BOM qui reste juste ?

Le mode d'échec de tout inventaire de gouvernance est identique, et n'a rien à voir avec l'effort initial. Quelqu'un lance un exercice de découverte, interroge les équipes, remplit un tableur, et l'artefact est exact pendant une semaine environ. Ce qui suit n'est pas de la paresse ; c'est de l'arithmétique. Les composants changent plus vite que les cycles de revue.

La contrainte de conception vient donc d'abord, et les étapes en découlent.

1. Dérivez l'inventaire du code, jamais d'un questionnaire. Un questionnaire capture ce dont les gens se souviennent. Un scan capture ce qui a été livré. Les deux divergent immédiatement, et un seul des deux est ce que l'auditeur lira.

2. Rattachez chaque composant à un fichier et une ligne. Une entrée d'inventaire sans localisation source est une affirmation. Une entrée avec src/lib/triage.ts:23 à côté est une preuve, et c'est aussi ce qui rend la remédiation assignable à une équipe plutôt qu'à un comité.

3. Classifiez au niveau du composant, pas du système. Les articles 5, 6 et 50 s'appliquent à ce que fait un composant. Un même dépôt contient couramment un assistant de chat à risque minimal, un assistant client à risque limité et un modèle de scoring réellement à haut risque. Une étiquette unique au niveau système masque précisément le composant qui compte.

4. Signalez un statut, pas seulement une présence. Gouverné, shadow, dérivé, manquant. Un composant avec une model card et une licence est un objet différent du même composant sans ni l'une ni l'autre, et toute la valeur d'un premier scan tient dans le ratio entre ces deux piles.

5. Régénérez à chaque push et faites-en le diff. L'annexe IV §6 demande les changements apportés au système au fil de sa vie. Si l'inventaire est régénéré à chaque commit, cette section s'écrit toute seule ; le diff est le journal des changements. S'il est régénéré chaque trimestre, quelqu'un devra le reconstituer de mémoire.

6. Bloquez le pipeline sur tout nouveau composant non gouverné. Un build qui échoue quand un composant interdit ou à haut risque arrive sans documentation est le seul contrôle qui empêche le ratio de l'étape 4 de dériver. Tout ce qui est plus mou qu'un blocage dégénère en tableau de bord que personne n'ouvre.

7. Contractualisez ce que vous ne pouvez pas scanner. Votre scan voit ce que contient votre dépôt. Il ne voit pas le corpus d'entraînement d'un fournisseur. Les articles 25(2) et 25(4) placent l'obligation de coopération sur le fournisseur amont, alors inscrivez-la aussi au contrat : model cards, résumés des données d'entraînement, et notification quand une version de modèle change sous vos pieds.

8. Conservez-le dix ans. L'article 18 est explicite, et dix ans, c'est plus long que la plupart des politiques de rétention d'artefacts, plus long que la rétention par défaut de la plupart des fournisseurs de CI, et considérablement plus long que l'ancienneté moyenne de l'ingénieur qui a construit le système. Exportez le dossier vers un support durable.

Comment CybeDefend génère l'AI-BOM

Tout ce qui précède est le cas général. Voici notre mise en œuvre, parce que la contrainte de conception de la section précédente est exactement celle pour laquelle nous avons construit.

Le scanner AI-BOM de CybeDefend parcourt un dépôt et catalogue les six catégories directement depuis le code : modèles (chaînes hébergées, identifiants HuggingFace, poids locaux .gguf et .onnx), jeux de données référencés dans le code ou la config, prompts versionnés, frameworks d'agents et d'orchestration, serveurs MCP consommés par vos agents, et bibliothèques de garde-fous en usage. Chaque élément atterrit avec son fichier source et sa ligne, sa version épinglée, et un statut : gouverné, shadow, dérive ou manquant. Pas de questionnaire, pas de tournée d'entretiens.

Un scan émet ensuite trois artefacts dans ./.ai-bom/, et c'est la partie qui compte pour le travail décrit plus haut.

Le premier est un rapport de conformité AI Act aligné sur le règlement (UE) 2024/1689, où chaque composant est rangé en risque interdit, élevé, limité ou minimal au titre des articles 5, 6 et 50, les composants GPAI comptés séparément, et les composants à risque systémique signalés. Le deuxième est une cartographie de couverture NIST AI RMF sur Govern, Map, Measure et Manage, avec les manques nommés plutôt que noyés dans une moyenne. Le troisième est l'AI-BOM CycloneDX lisible par machine, pour que l'inventaire s'insère dans l'outillage SBOM que vous utilisez déjà.

Il tourne là où vous livrez. Ajoutez la cybedefend-action à un workflow GitHub, ou appelez la CLI CybeDefend depuis GitLab CI, un Jenkinsfile ou Tekton, et le scan s'exécute à chaque push avec le rapport publié comme artefact de build.

- name: CybeDefend Security Scan
  uses: CybeDefend/cybedefend-action@v2
  with:
    pat: ${{ secrets.CYBEDEFEND_PAT }}
    project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
    branch: ${{ github.ref_name }}
    break_on_severity: high

Ce sont les étapes 5 et 6 de la liste ci-dessus, implémentées : l'inventaire se régénère à chaque commit, donc l'annexe IV §6 devient un diff, et le build sort en erreur quand un nouveau composant interdit ou à haut risque arrive sans documentation de gouvernance. Le scan lit votre dépôt et produit un inventaire structuré ; le code source ne quitte pas votre environnement, et le tableau de bord ne reçoit que des métadonnées de composants, jamais de code brut ni de contenu de prompt.

L'AI-BOM se place à côté du reste de la plateforme plutôt que dans la boucle de l'agent. C'est un scanner de dépôt et de pipeline, ce qui est le bon endroit pour un inventaire : il lui faut l'arbre entier, pas l'édition en cours. Ce qui tourne dans la boucle de l'agent, c'est VibeDefend, qui charge vos règles métier et de sécurité dans l'agent avant qu'il écrive, intercepte les actions dangereuses, et maintient les findings SAST, SCA, secrets, IaC et CI/CD vivants dans le contexte de l'agent. Les deux sont complémentaires. VibeDefend gouverne ce que fait l'agent pendant qu'il écrit ; l'AI-BOM enregistre ce que le dépôt est devenu.

Questions fréquentes

Qu'est-ce qu'un AI-BOM ?

Un AI-BOM, ou AI Bill of Materials, est un inventaire lisible par machine de tous les composants IA d'un système : modèles, jeux de données, prompts, agents et frameworks d'orchestration, outils et serveurs MCP que ces agents appellent, et garde-fous qui leur sont appliqués. Chaque entrée porte des faits de provenance et de gouvernance : fournisseur, version, licence, origine des données, périmètre de capacités, classification de risque. Il étend le concept de SBOM des paquets logiciels aux actifs IA, et c'est la matière première de la documentation technique de l'article 11 et de l'annexe IV de l'AI Act, du reporting NIST AI RMF et des inventaires IA de l'ISO/IEC 42001.

Quelle est la différence entre un AI-BOM et un SBOM ?

Un SBOM liste des composants logiciels (paquets, versions, licences) et sert surtout à repérer des vulnérabilités connues. Un AI-BOM liste des composants IA et leurs dimensions de gouvernance propres à l'IA : origine des données d'entraînement, lignage de fine-tuning, versions de prompts, périmètre de capacités des agents, couverture des garde-fous et risque résiduel. Ils sont complémentaires plutôt que concurrents, et CycloneDX sait exprimer les deux, donc un AI-BOM peut être produit dans le même format et le même pipeline que votre SBOM existant.

L'AI Act européen impose-t-il un AI-BOM ?

Pas sous ce nom. L'AI Act n'emploie jamais ce terme. L'article 11 impose aux fournisseurs de systèmes d'IA à haut risque d'établir une documentation technique avant la mise sur le marché et de la tenir à jour, et l'annexe IV en fixe le contenu minimal : description générale, spécifications de conception, architecture, exigences et provenance des données, supervision humaine, validation et tests, cybersécurité, capacités et limites, gestion des risques, changements du cycle de vie et surveillance après commercialisation. Un AI-BOM est le moyen pratique de produire mécaniquement l'essentiel de ce dossier. L'article 18 impose ensuite de conserver la documentation pendant dix ans après la mise sur le marché.

L'AI Omnibus a-t-il supprimé l'obligation de documentation technique ?

Non. L'AI Omnibus est entré en vigueur le 27 juillet 2026 et a reporté les obligations haut risque des systèmes autonomes de l'annexe III du 2 août 2026 au 2 décembre 2027, et celles de l'IA à haut risque intégrée à des produits réglementés du 2 août 2027 au 2 août 2028. Il a aussi créé une catégorie de « petites entreprises de taille intermédiaire » (moins de 750 salariés, chiffre d'affaires inférieur ou égal à 150 millions d'euros) qui peuvent utiliser des modèles simplifiés de documentation technique. Le contenu de l'annexe IV n'a pas changé, les obligations de transparence de l'article 50 sont restées à leur date initiale, et les obligations GPAI s'appliquent depuis le 2 août 2025, les pouvoirs d'exécution de la Commission étant actifs depuis le 2 août 2026.

Quel format choisir pour un AI-BOM, CycloneDX ou SPDX ?

CycloneDX est le choix pragmatique par défaut. Il prend en charge les modèles d'apprentissage automatique depuis la version 1.5 (2023), la spécification courante est la 1.7 (octobre 2025), et elle est normalisée sous ECMA-424, avec les champs modelCard, modelParameters, les références de jeux de données et quantitativeAnalysis qui couvrent l'essentiel des faits de composition. L'AI Profile de SPDX 3.0 est l'alternative alignée ISO, raisonnable si votre organisation standardise déjà sur SPDX. Aucun des deux n'a de champ natif pour la méthodologie d'évaluation des biais ni pour la conception de la supervision humaine, qui se portent donc en propriétés personnalisées ou en documents liés dans les deux cas.

Suis-je le fournisseur si je me suis contenté de fine-tuner le modèle d'un autre ?

En général oui. L'article 25(1) considère une partie comme le fournisseur d'un système d'IA à haut risque si elle le met sur le marché sous son propre nom ou sa marque, si elle le modifie substantiellement, ou si elle en change la finalité de sorte qu'il devienne à haut risque. Fine-tuner un modèle existant sur ses propres données et le livrer sous son nom de produit déclenche typiquement les trois. La model card du laboratoire d'origine ne documente que le modèle de base ; l'obligation documentaire de l'article 11 pour votre système vous incombe, et les articles 25(2) et 25(4) obligent le fournisseur amont à coopérer et à fournir des informations, pas à rédiger votre dossier.

Comment trouver le shadow AI dans un dépôt ?

En scannant le code plutôt qu'en interrogeant les équipes. Les composants IA se déclarent rarement dans un manifeste : un modèle hébergé apparaît comme une chaîne littérale, un modèle local comme un chemin de poids dans une config, un jeu de données comme une URI dans un notebook, un serveur MCP comme une URL dans une config d'agent, un prompt comme un fichier markdown non suivi. Un scan de dépôt résout chacun d'eux en un composant avec un fichier et une ligne, puis signale ceux qui n'ont ni model card, ni licence, ni version épinglée, ni propriétaire enregistré. Le Cost of a Data Breach Report 2026 d'IBM a relevé du shadow AI dans 43 % des incidents de sécurité et plus de deux tiers d'organisations sans processus de gouvernance pour le limiter, donc l'attente raisonnable pour un premier scan est que la pile shadow soit plus grosse que la pile gouvernée.

À quelle fréquence régénérer un AI-BOM ?

À chaque push. L'annexe IV §6 demande les changements apportés au système au fil de sa vie, et un inventaire par commit transforme cette section en diff au lieu d'un exercice de reconstitution. Un inventaire trimestriel est périmé en quelques jours dans tout dépôt où des agents de code IA écrivent les intégrations, parce qu'un changement de modèle, un nouvel accès outil ou une modification de prompt est un commit d'une ligne. Régénérer dans la CI et faire échouer le build quand un nouveau composant à haut risque ou interdit arrive sans documentation, c'est ce qui maintient l'artefact et le dépôt en accord.