Chaîne d'approvisionnement IA : auditer la provenance de vos modèles avec un AI-BOM

Un modèle d'IA récupéré sur une place de marché ou un dépôt public peut embarquer une porte dérobée, un jeu de données empoisonné ou une licence qui vous interdit l'usage que vous en faites, sans qu'aucun scanner de sécurité classique ne le voie. La parade tient en un document vivant, l'AI-BOM, qui trace la provenance de chaque composant avant que le modèle n'entre chez vous. Dans cet article, je vous explique pourquoi la chaîne d'approvisionnement des modèles est un angle mort de la cybersécurité, puis la méthode en quatre étapes pour tracer cette provenance et qualifier le risque fournisseur avant d'intégrer quoi que ce soit.

Le problème : vous héritez d'un modèle dont vous ne savez presque rien

Personne n'entraîne aujourd'hui ses modèles à partir de zéro. On télécharge un modèle de base sur un dépôt public, on récupère des poids pré-entraînés, on ajoute quelques librairies, on branche un jeu de données d'affinage, et l'assemblage part en production. Chaque maillon de cette chaîne vient de l'extérieur, et chaque maillon peut être compromis. C'est le risque que l'OWASP classe en troisième position de son panorama des menaces propres aux IA, la vulnérabilité de la chaîne d'approvisionnement.

Le danger est qu'il reste invisible. Un modèle malveillant se comporte normalement à l'usage courant, puis déclenche un comportement caché sur un mot-clé précis. Un jeu de données d'entraînement peut avoir été pollué en amont pour biaiser durablement les réponses. Une dépendance anodine peut exfiltrer des données au chargement du modèle. Ces menaces ne se lisent ni dans le code de votre application, ni dans un scanner d'antivirus classique.

Pourquoi le SBOM classique ne suffit pas

Beaucoup d'entreprises pensent être couvertes parce qu'elles produisent déjà un SBOM, la nomenclature logicielle qui liste les composants d'une application. Le problème est qu'un modèle d'IA n'est pas seulement du logiciel. C'est un assemblage de trois natures différentes qui échappent largement au SBOM traditionnel.

C'est précisément ce vide que comble l'AI-BOM, ou nomenclature des composants d'un système d'IA. Là où le SBOM répond à « de quel logiciel suis-je fait », l'AI-BOM répond à « de quel modèle, de quelles données et de quelle provenance suis-je fait ». Voici ce qu'il recense.

La méthode en 4 étapes pour tracer la provenance

Construire un AI-BOM n'est pas un projet de recherche. C'est une discipline d'inventaire que vous appliquez à chaque modèle avant sa mise en production, puis à chaque mise à jour. Voici les quatre étapes, dans l'ordre.

Étape 1 : recenser tous les composants

Vous ne pouvez pas tracer ce que vous n'avez pas listé. La première étape consiste à ouvrir la boîte et à inscrire, pour chaque modèle candidat, ses cinq couches : le modèle de base et sa version exacte, les poids téléchargés, les jeux de données d'entraînement et d'affinage, les librairies et frameworks embarqués, enfin la licence et ses conditions. Un modèle sans version identifiable ou sans licence lisible est déjà un signal d'alerte. Ce recensement rejoint la logique d'inventaire de tout audit de sécurité d'une application IA, dont l'AI-BOM est le volet chaîne d'approvisionnement.

Étape 2 : vérifier la provenance et l'intégrité

Recenser ne suffit pas, il faut prouver. Pour chaque composant, vous cherchez à répondre à deux questions : qui l'a produit vraiment, et est-il arrivé chez vous sans altération. Concrètement, vous vérifiez l'empreinte cryptographique des poids téléchargés contre celle publiée par l'éditeur, vous confirmez l'identité du dépôt d'origine plutôt que celle d'un miroir douteux, et vous exigez une signature du fournisseur quand elle existe. Le format des poids compte aussi : préférez les formats qui ne permettent pas l'exécution de code arbitraire au chargement, car c'est une porte d'entrée classique.

Étape 3 : qualifier le risque de chaque composant et du fournisseur

Une fois la provenance établie, vous attribuez à chaque composant un niveau de risque, puis au fournisseur dans son ensemble. Trois axes suffisent pour trancher sans se noyer : la criticité de l'usage auquel le modèle est destiné, la transparence du fournisseur sur ses données et son entraînement, et la sensibilité des données auxquelles le modèle aura accès une fois branché. Un modèle opaque destiné à une décision qui engage un client se situe en haut de la pile ; un modèle documenté cantonné à une tâche interne à faible enjeu peut être accepté avec des contrôles allégés.

Étape 4 : décider, puis surveiller dans la durée

L'AI-BOM n'est pas un document que l'on classe. À l'issue de la qualification, vous prenez une décision explicite pour chaque modèle : l'intégrer, l'intégrer sous conditions, ou le refuser. Puis vous versionnez cet inventaire et vous le rejouez à chaque mise à jour du modèle, car une nouvelle version change la chaîne d'approvisionnement. Un modèle sûr aujourd'hui peut devenir un risque à la prochaine mise à jour de ses poids ou d'une de ses dépendances. Cette provenance tracée est aussi ce qui vous permet, le jour d'un incident, de savoir instantanément quels systèmes reposent sur le composant fautif.

Le résultat : une provenance opposable et une décision défendable

Au bout de cette méthode, vous ne dépendez plus d'une note ni d'un logo. Pour chaque modèle en production, vous savez d'où il vient, sur quoi il a été entraîné, ce dont il dépend, et pourquoi vous avez décidé de l'intégrer. Cette traçabilité sert deux fois : elle réduit votre surface d'attaque en amont, et elle constitue une preuve exploitable quand un régulateur ou un client vous demande de justifier vos choix. L'AI-BOM devient ainsi un maillon de la chaîne qui relie le test technique à la preuve réglementaire, un fil que je détaille dans mon article sur la chaîne qui relie le test à la preuve.

Ce risque de chaîne d'approvisionnement n'est qu'un des dangers propres aux modèles de langage. Pour le situer dans le tableau d'ensemble, je passe en revue les dix risques majeurs dans mon guide sur l'OWASP LLM Top 10 expliqué pour décider.

Questions fréquentes

Un AI-BOM, est-ce réservé aux entreprises qui entraînent leurs propres modèles ?

Non, c'est même l'inverse. Plus vous dépendez de modèles tiers récupérés à l'extérieur, plus l'AI-BOM est utile, car c'est précisément le cas où vous ne maîtrisez ni l'entraînement ni les données d'origine. Une entreprise qui n'assemble que des briques externes en a plus besoin qu'un laboratoire qui contrôle sa chaîne de bout en bout.

Comment détecter une porte dérobée dans un modèle si elle est invisible ?

Vous ne la détectez pas en lisant les poids, ce serait illusoire. Vous réduisez le risque en amont par la provenance vérifiée, puis en aval en éprouvant le modèle par des tests offensifs ciblés. C'est le rôle du red teaming d'un LLM, qui cherche activement les comportements cachés que l'inventaire seul ne révèle pas.

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

Le SBOM liste les composants logiciels d'une application. L'AI-BOM ajoute ce qui est propre à l'IA et que le SBOM ignore : la provenance du modèle, ses données d'entraînement, ses poids et leur intégrité. L'un ne remplace pas l'autre, l'AI-BOM prolonge le SBOM sur le terrain des modèles.

Par où commencer si nous utilisons déjà des modèles sans les avoir tracés ?

Par le recensement de l'existant. Listez les modèles déjà en production, appliquez-leur les quatre étapes a posteriori, et traitez en priorité ceux qui touchent des données sensibles ou des décisions engageantes. C'est exactement le point de départ d'un audit de la chaîne d'approvisionnement de vos IA.

Cartographier la provenance de vos modèles et qualifier le risque de vos fournisseurs, c'est l'un des volets de mon audit Sécurité & Conformité IA. En quelques jours, vous savez quels modèles vous exposent et par quoi commencer, avant toute mise en production.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.