01Pourquoi les SBOM classiques ne suffisent pas pour l'IA
Une SBOM classique inventorie les composants logiciels et leurs dépendances – bibliothèques, versions, licences. Or, le comportement d'un système d'IA est largement déterminé par des artefacts qui échappent à cette grille : le modèle lui-même, ses poids, les jeux de données d'entraînement et d'évaluation, ainsi que leur provenance et leur prétraitement. Un modèle peut changer fondamentalement à la suite d'un réentraînement ou d'un fine-tuning sans qu'une seule ligne de code ou version de paquet ne bouge. Une AI-SBOM étend donc l'inventaire à ces composants précis – condition préalable pour pouvoir évaluer la provenance, l'intégrité et les risques d'un système d'IA.
02CycloneDX ML-BOM : les modèles et les données comme composants
CycloneDX prend en charge la ML-BOM depuis la version 1.5 (juin 2023) : les types de composants « machine-learning-model » et « data » placent les modèles et les jeux de données sur un pied d'égalité avec les bibliothèques logicielles. Un objet « modelCard » documente la finalité d'utilisation, les limites, les biais, les paramètres d'entraînement, les jeux de données utilisés, les métriques de performance et les considérations éthiques ; les composants de données recensent notamment les contenus, la classification, les données sensibles et la gouvernance. La spécification a été publiée pour la première fois en juin 2024 comme norme internationale ECMA-424 ; la 2e édition actuelle (décembre 2025) correspond à CycloneDX 1.7 (octobre 2025).
03SPDX 3.0 : profils AI et Dataset
SPDX, le second grand format de SBOM, est structuré de manière modulaire en profils depuis la version 3.0 (avril 2024, actuellement 3.0.1 de décembre 2024) – dont un profil AI et un profil Dataset dédiés. Le profil AI décrit les paquets d'IA (« AIPackage ») avec des propriétés telles que le type de modèle, les informations d'entraînement, la consommation d'énergie et une évaluation du risque de sécurité ; le profil Dataset documente les jeux de données (« DatasetPackage ») avec leur taille, leur type, leur disponibilité, leur prétraitement, les informations sensibles qu'ils contiennent et les biais connus. Une version 3.1 n'existe pour l'instant que sous forme de release candidate, c'est-à-dire encore au stade de projet.
04Model cards : une documentation structurée des modèles
Les model cards remontent à l'article « Model Cards for Model Reporting » (Mitchell et al., conférence FAT* 2019) : une documentation courte et standardisée par modèle, couvrant la finalité d'utilisation, les résultats d'évaluation dans différentes conditions – par exemple selon les groupes démographiques – ainsi que les limites connues. Elles sont aujourd'hui une pratique courante sur les hubs de modèles, mais le plus souvent sous forme de texte libre sans schéma contraignant. Avec le champ « modelCard », CycloneDX transpose ce concept dans un format lisible par machine et le rend ainsi exploitable pour les contrôles automatisés, les décisions d'achat et les évaluations de risques.
05Attaques contre la chaîne d'approvisionnement IA
Les risques sont documentés : en février 2024, JFrog a identifié une centaine de modèles malveillants sur Hugging Face dont le code malveillant s'exécute au chargement – rendu possible par le format pickle, qui peut exécuter du code Python arbitraire lors de la désérialisation et a longtemps été le format par défaut des poids PyTorch ; safetensors, l'analyse des imports et les artefacts signés sont considérés comme des contre-mesures. Le niveau des frameworks est également touché : par dependency confusion, le paquet « torchtriton » a été placé sur PyPI en décembre 2022 et a exfiltré, entre autres, des clés SSH et des données système depuis des installations PyTorch nightly. L'OWASP classe donc la chaîne d'approvisionnement IA comme un risque à part entière de son Top 10 (LLM03:2025 Supply Chain) et recommande explicitement un inventaire des composants à jour via SBOM ou AI-BOM.
06Obligations de documentation issues du CRA et de l'AI Act
Le Cyber Resilience Act (règlement (UE) 2024/2847) oblige les fabricants de produits comportant des éléments numériques à identifier et documenter les vulnérabilités et les composants – y compris une SBOM « dans un format couramment utilisé et lisible par machine » couvrant au minimum les niveaux supérieurs de dépendances (annexe I, partie II, point 1) ; les obligations de notification s'appliquent à partir du 11.09.2026, les obligations principales à partir du 11.12.2027. L'AI Act (règlement (UE) 2024/1689) exige pour les systèmes d'IA à haut risque une documentation technique conformément à l'art. 11 et à l'annexe IV, portant notamment sur les jeux de données (provenance, étendue, caractéristiques principales) et sur le recours à des systèmes pré-entraînés ou à des outils de tiers. En vertu de l'art. 53, les fournisseurs de modèles GPAI doivent, depuis le 02.08.2025, mettre à disposition une documentation technique (annexe XI), des informations pour les fournisseurs en aval (annexe XII) et un résumé suffisamment détaillé des contenus d'entraînement ; pour l'essentiel, le règlement s'applique à partir du 02.08.2026. Une AI-SBOM bien tenue fournit la base de données pour ces deux actes législatifs.
