De la SBOM à l’AI-BOM : repenser la visibilité dans les systèmes natifs de l’IA

Depuis des années, la nomenclature logicielle constitue un socle fiable pour la gouvernance. Elle permet aux équipes de comprendre les composants d’une application, d’évaluer les risques et de répondre à des exigences de conformité toujours plus nombreuses. Mais à mesure que le développement logiciel s’oriente vers des systèmes natifs de l’IA, ce socle commence à se fissurer.

Voici la nomenclature de l’IA. Une AI-BOM cartographie les composants natifs de l’IA qui façonnent désormais les applications modernes, des dépôts aux pipelines en passant par les systèmes en production. Modèles, agents, prompts, jeux de données et services associés font tous partie du tableau. Là où la SBOM constitue le socle de la gouvernance logicielle, l’AI-BOM s’impose comme la colonne vertébrale de la sécurité des systèmes natifs de l’IA.

Ce guide explique pourquoi la logique des SBOM n’est plus adaptée à un écosystème piloté par l’IA, où les composants changent fréquemment et où le comportement se façonne à l’exécution plutôt qu’au moment de la compilation. Il montre pourquoi les organisations font de l’AI-BOM une capacité fondamentale et pourquoi la visibilité est la priorité la plus urgente. Dans un monde où les outils évoluent rapidement et où l’IA fantôme se généralise, savoir ce qui existe est le point de départ de tout le reste.

Pourquoi la logique des SBOM échoue à l’ère de l’IA

Pour comprendre pourquoi l’AI-BOM est devenue essentielle, commençons par ce qui ne fonctionne plus. Les hypothèses à l’origine des SBOM reposaient sur un univers logiciel où les composants étaient délimités, les dépendances connues et les changements progressifs. Les systèmes natifs de l’IA évoluent dans un tout autre contexte. Avant d’examiner comment les organisations s’adaptent, il convient de voir pourquoi les hypothèses familières de l’ère des SBOM ne tiennent plus à l’ère de l’IA.

Les composants d’IA changent constamment

Les systèmes natifs de l’IA se caractérisent par des changements constants. Leurs composants évoluent trop vite pour être traités comme des dépendances traditionnelles : cette volatilité est désormais la norme, et non l’exception.

Les modèles sont mis à jour chaque semaine, parfois plus souvent, au fil de la publication de nouvelles fonctionnalités et optimisations. Les frameworks d’agents évoluent tout aussi vite, tandis que de nouvelles abstractions, de nouveaux outils et modes d’exécution apparaissent dans les dépôts publics. Des serveurs MCP sont déployés pour proposer de nouveaux outils ou workflows, souvent en réponse à des besoins immédiats de développement plutôt qu’à des projets de long terme. Les prompts, qui font de plus en plus office de logique exécutable, sont modifiés et affinés en continu. Les jeux de données évoluent à mesure que des données sont ajoutées, filtrées ou remplacées, ce qui modifie le comportement des modèles sans que le code environnant change.

Ces composants ne sont pas figés sur une version comme le sont les bibliothèques. Ils ne sont pas centralisés dans un dépôt unique. Et chaque développeur peut les introduire facilement. Les traiter comme des dépendances statiques crée presque immédiatement des angles morts.

Dans un environnement natif de l’IA, la gouvernance doit tenir compte de composants fluides, décentralisés et en constante évolution.

Le problème fondamental : la visibilité

Pour la plupart des responsables de la sécurité, le défi ne consiste pas à comprendre chaque décision qu’un système d’IA pourrait prendre. Les RSSI ne cherchent pas à analyser le comportement des agents au niveau de chaque prompt ou résultat. Ce dont ils ont d’abord besoin est bien plus élémentaire : savoir ce qui existe.

Ils veulent savoir quels agents, modèles et serveurs MCP sont réellement utilisés dans l’organisation. Ils veulent comprendre quels outils ou workflows ces composants exposent et à quels systèmes externes ils peuvent accéder. Ils doivent connaître les jeux de données et les prompts qui façonnent le comportement, car ces entrées comptent souvent autant que le code lui-même.

Sans cette visibilité, il devient impossible d’évaluer les risques, de définir des politiques ou de réagir efficacement en cas de problème. Les SBOM traditionnelles n’ont jamais été conçues pour fournir ce niveau de visibilité. Elles recensent les dépendances statiques à un instant donné, et non les composants actifs et évolutifs qui définissent les systèmes natifs de l’IA. Les équipes de sécurité ne disposent donc pas de la visibilité nécessaire pour gouverner efficacement l’IA.

Ce que nous disent les responsables de la sécurité

Le manque de visibilité n’est plus théorique. Il revient régulièrement dans les échanges avec des responsables de la sécurité qui tentent d’appliquer les contrôles existants à un paysage de l’IA en pleine évolution.

La prolifération des frameworks

Pour de nombreuses grandes organisations, le défi commence par le volume. Une entreprise nous a décrit l’afflux constant de nouveaux frameworks d’agents, d’outils d’orchestration, de packages de modèles et de serveurs MCP au sein de ses équipes de développement. Les développeurs les adoptaient rapidement pour accélérer leur travail. Les équipes de gouvernance ne parvenaient pas à suivre.

Les efforts de sécurité et de conformité sont devenus réactifs. Le temps qu’un framework soit examiné, un autre était déjà apparu. Le problème n’était pas un rejet de l’innovation, mais l’absence de visibilité claire sur les composants utilisés.

Pour cette organisation, l’AI-BOM est devenue essentielle. Elle a fourni un moyen fiable de suivre les composants d’IA dans les dépôts et d’établir la base nécessaire à la gouvernance, malgré l’évolution continue de l’écosystème.

L’AI-BOM semble encore récente, mais elle est essentielle.

Une autre organisation a décrit son approche avec plus de prudence, mais tout autant d’urgence. Elle reconnaît que l’AI-BOM en est encore à ses débuts. Les normes émergent. Les bonnes pratiques ne sont pas encore établies. Elle la juge néanmoins incontournable.

Les composants d’IA ne sont plus de simples outils expérimentaux : ils sont devenus des dépendances majeures. Les modèles, les agents et les services associés influent désormais directement sur le comportement des applications et le traitement des données. Parallèlement, les autorités de régulation commencent à exprimer leurs attentes en matière de transparence, de provenance et de responsabilité dans la chaîne d’approvisionnement en IA.

Attendre des recommandations parfaites ne semble plus être une option viable. Pour cette organisation, adopter une AI-BOM relève moins de la maturité que de la préparation. Établir une visibilité dès maintenant permet de créer un socle que l’organisation pourra faire évoluer au gré des exigences, plutôt que de devoir rattraper son retard une fois celles-ci formalisées.

Nous attendons de nos outils qu’ils suivent les nouveautés.

Un troisième thème revient tout aussi régulièrement dans ces échanges : les organisations ne s’attendent plus à suivre elles-mêmes l’écosystème de l’IA. Les équipes de sécurité savent à quelle vitesse apparaissent de nouveaux frameworks d’agents, serveurs MCP, packages de modèles, prompts et jeux de données. Le temps de définir un processus d’examen manuel, le paysage a déjà changé. Maintenir un inventaire faisant autorité uniquement grâce à l’effort humain n’est plus réaliste.

Les organisations attendent donc de Snyk qu’elle assure cette veille pour elles. Elles s’appuient sur la découverte automatisée pour détecter les nouveaux composants dès leur apparition et conserver une visibilité à jour sans intervention constante. Dans un écosystème qui évolue aussi vite, l’automatisation n’est pas un simple confort : c’est le seul moyen de suivre le rythme.

La nouvelle surface d’attaque de l’IA : la visibilité d’abord, le reste ensuite

Une fois que les organisations comprennent à quelle vitesse les composants d’IA prolifèrent et combien le suivi manuel est limité, leur attention passe des choix d’outils à l’exposition aux risques.

L’explosion de l’IA fantôme

À mesure que l’adoption de l’IA s’accélère, une nouvelle catégorie d’exposition aux risques apparaît. L’IA fantôme dépasse largement les expériences isolées et les outils ponctuels. Elle englobe désormais un ensemble croissant de composants qui façonnent discrètement le comportement des applications sans jamais faire l’objet d’un examen formel.

Des agents non approuvés sont déployés pour automatiser des tâches ou orchestrer des workflows. Des serveurs MCP non documentés exposent de nouveaux outils et de nouvelles fonctionnalités sans responsable clairement désigné. Des wrappers créés à la volée relient des modèles à des systèmes internes, souvent pour résoudre un problème immédiat, puis restent en place. Des appels à des LLM dissimulés s’intègrent à la logique des applications, tandis que des chaînes de prompts deviennent des parcours décisionnels fonctionnels plutôt que de simples entrées.

Pris séparément, nombre de ces éléments semblent inoffensifs. Ensemble, ils créent une surface d’attaque liée à l’IA difficile à cartographier et facile à négliger. L’IA fantôme se définit non par l’intention ou la sophistication, mais par son invisibilité. Lorsque des composants échappent aux processus habituels de découverte et de gouvernance, ils introduisent des risques simplement parce qu’ils sont inconnus.

Des lacunes de visibilité bien réelles

Ces lacunes se manifestent dans des environnements réels. Dans un cas, une entreprise a découvert un serveur MCP actif lors d’une démonstration de routine. L’équipe AppSec n’en avait jamais entendu parler. Rien n’était mal configuré. Rien n’avait été exploité. Le serveur échappait tout simplement aux contrôles sur lesquels l’équipe comptait. Dans les organisations, le constat est le même : des composants d’IA qui influent réellement sur le comportement échappent aux processus formels de découverte, non par négligence, mais parce que les contrôles existants n’ont jamais été conçus pour les détecter.

L’AI-BOM : la nouvelle source de référence

Ensemble, ces lacunes montrent qu’une nouvelle source de référence est nécessaire. L’AI-BOM répond à ce besoin en offrant la visibilité que les SBOM n’ont jamais été conçues pour fournir dans un environnement natif de l’IA.

Une AI-BOM répertorie les composants qui définissent le fonctionnement des systèmes d’IA. Elle suit les modèles utilisés, les agents qui s’appuient sur eux, ainsi que les outils et les chaînes qu’ils invoquent. Elle recense les serveurs MCP et les fonctionnalités qu’ils exposent, ainsi que les prompts et les jeux de données qui façonnent le comportement. Elle prend également en compte les API d’IA externes qui étendent les fonctionnalités au-delà des limites de l’application.

Cette visibilité constitue un socle pour agir. La gouvernance s’appuie sur la réalité plutôt que sur des suppositions. La surveillance peut se concentrer sur les composants réellement utilisés. Les exercices de red team peuvent cibler des configurations réelles plutôt que des workflows hypothétiques. L’AI-BOM passe du simple inventaire à la colonne vertébrale opérationnelle.

Pourquoi AI-BOM ≠ SBOM

Malgré la familiarité du terme, une AI-BOM est fondamentalement différente d’une SBOM traditionnelle. Les SBOM ont été conçues pour des systèmes logiciels aux composants stables, aux mises à jour prévisibles et aux arborescences de dépendances clairement définies. Les systèmes natifs de l’IA évoluent dans un tout autre contexte.

Ces différences ont des conséquences concrètes sur la gouvernance, la surveillance et la gestion de la posture de sécurité.

Pourquoi l’automatisation est essentielle et pourquoi Snyk est leader

L’ampleur et la vitesse des changements dans l’écosystème de l’IA sont sans équivoque : le suivi manuel ne peut pas suivre le rythme. À cette échelle, l’examen humain atteint ses limites. Lorsqu’un nouveau composant est identifié, il est peut-être déjà utilisé par plusieurs équipes ou dans plusieurs workflows.

C’est là que l’automatisation devient essentielle. La découverte et la classification continues sont les seuls moyens pratiques de conserver une vue précise des composants d’IA à mesure qu’ils apparaissent et évoluent. Snyk fait figure de leader dans ce domaine en associant détection automatisée et recherche continue, afin d’identifier les nouveaux frameworks, serveurs MCP, modèles de modèles et jeux de données dès leur apparition.

L’avantage de Snyk en matière de recherche

L’automatisation ne suffit pas sans les connaissances nécessaires pour la guider. Savoir quoi analyser est tout aussi important que de le faire en continu.

L’équipe de recherche de Snyk dédiée à la chaîne d’approvisionnement en IA étudie l’évolution de l’écosystème en temps réel. Elle suit l’apparition de nouveaux frameworks d’agents, analyse les nouveaux modèles et usages de MCP et étudie les nouvelles formes d’attaque contre l’IA au fur et à mesure de leur découverte sur le terrain. Elle suit également l’expansion rapide des familles de modèles et des types de jeux de données, et repère les nouvelles dépendances et formes de risques qu’entraînent ces évolutions.

Ces recherches permettent de maintenir l’AI-BOM à jour. Les clients n’ont pas besoin de surveiller chaque nouvelle version, chaque framework ou chaque modèle. Snyk s’en charge pour eux et traduit les évolutions de l’écosystème en détections et en informations contextuelles fiables. C’est là toute la valeur d’une AI-BOM alimentée par la recherche : une visibilité qui évolue aussi vite que la chaîne d’approvisionnement en IA elle-même.

Les AI-BOM comme fondement de la gouvernance de l’IA et de l’AI-SPM

À mesure que les systèmes d’IA passent de l’expérimentation aux processus métier essentiels, il devient incontournable de disposer d’une base fiable. Tout comme les SBOM sont passés du statut de bonne pratique à celui d’exigence en matière de gouvernance logicielle, les AI-BOM suivent une trajectoire similaire dans les environnements natifs de l’IA.

Ils offrent la visibilité nécessaire pour éclairer les décisions de gouvernance, protéger les données, orienter les exercices de red team, surveiller l’activité des agents et anticiper les contrôles réglementaires. Les signaux envoyés par les autorités de régulation vont déjà dans ce sens.

Mais la visibilité ne suffit pas. À mesure que les environnements d’IA se développent, les organisations doivent pouvoir comprendre en continu leur niveau de sécurité pour des centaines de modèles, d’agents, de jeux de données et de connecteurs, non pas sous la forme d’inventaires statiques, mais comme des systèmes vivants qui évoluent au quotidien. C’est là que les AI-BOM deviennent une donnée fondamentale pour la gestion de la posture de sécurité de l’IA (AI-SPM).

Les chaînes d’approvisionnement de l’IA évoluent trop vite pour que l’on s’en tienne à la logique de l’ère des SBOM. L’IA fantôme continue de se développer. La surveillance se renforce. Dans ce contexte, l’AI-BOM devient la source de référence indispensable des systèmes natifs de l’IA.

Si les SBOM ont façonné la sécurité logicielle de la dernière décennie, les AI-BOM façonneront celle de la prochaine. Snyk bâtit une base fondée sur la recherche qui permettra aux AI-BOM d’évoluer vers une gestion complète de la posture de sécurité de l’IA (AI-SPM), en transformant un inventaire brut en informations de sécurité exploitables et continues.

Découvrez comment Snyk Evo enrichit la visibilité offerte par les AI-BOM, révèle les rouages des systèmes d’IA et pose les bases d’une nouvelle approche de la posture de sécurité de l’IA. Voyez concrètement à quoi ressemble une sécurité de l’IA fondée sur la recherche.