Votre SBOM manque la moitié de l'image. Bienvenue à l'ère des AI-BOM.
Depuis une décennie, les SBOM, listes des composants logiciels, sont la référence en matière de sécurité logicielle en entreprise. Après une série d'attaques majeures sur la chaîne d'approvisionnement (SolarWinds étant l'exemple canonique), maintenir un inventaire complet de chaque composant logiciel dans votre environnement est passé de « bonne pratique » à une exigence réglementaire dans de nombreux secteurs.
Aujourd'hui, un nouveau terme doit être ajouté au vocabulaire des équipes de sécurité : AI-BOM. Ce n'est pas qu'un simple changement de nom. Cela marque un changement fondamental dans ce que la sécurité d'entreprise doit réellement suivre.
L'informatique fantôme a mûri
Revenez en 2015. Le problème de l'informatique fantôme était que les employés utilisaient Dropbox au lieu du partage de fichiers d'entreprise. L'informatique le bloquait au proxy. Les employés passaient à Google Drive. Un jeu du chat et de la souris, généralement sans enjeux majeurs.
L'IA fantôme opère à un tout autre niveau de menace. Lorsqu'un employé utilise un outil IA non sanctionné aujourd'hui, il ne stocke pas seulement un fichier au mauvais endroit, il alimente potentiellement des données clients, du code source interne, des prévisions financières ou des dossiers RH dans un modèle tiers qu'il ne connaît pas. Les données entrent. Que ces données y restent, soient utilisées pour l'entraînement ou deviennent accessibles à d'autres est largement déterminé par les conditions d'utilisation que la plupart des employés ne lisent jamais.
Selon un reportage cette semaine dans The Register, les AI Bills of Materials gagnent une traction sérieuse auprès des équipes de sécurité d'entreprise, et pour de bonnes raisons. Un SBOM traditionnel couvre les paquets logiciels et leurs dépendances. Mais la pile IA dans une entreprise moyenne en 2026 ne ressemble en rien à un environnement logiciel traditionnel.
Ce qui doit réellement figurer dans un inventaire IA
Voici où la complexité vous surprend. Quand les équipes de sécurité pensent au risque IA, elles imaginent souvent les outils grand public évidents, ChatGPT, Copilot, Gemini. Ceux qui déclenchent les alertes DLP. Mais la surface réelle de l'IA dans une entreprise moyenne en 2026 ressemble plutôt à ceci :
- Des dizaines d'applications SaaS avec des fonctionnalités IA intégrées, Notion IA, Salesforce Einstein, les agents IA de Zendesk, les outils de contenu HubSpot, souvent activés par défaut sans implication de l'informatique
- Des outils développeurs comme Cursor, GitHub Copilot et des agents de codage de plus en plus autonomes ayant un accès lecture/écriture aux bases de code de production
- Des outils internes construits directement sur des API de modèles, les scripts discrets que personne n'a annoncés à la sécurité car « c'est juste un script interne »
- Des serveurs MCP connectant des agents IA à des systèmes de production en direct avec des identifiants réels
- Des workflows agentiques enchaînant plusieurs modèles, passant le contexte (et potentiellement des données sensibles) entre eux
- Des modèles affinés ou déployés localement qui ont pu être entraînés sur des données d'entreprise
Un AI-BOM tente de capturer tout cela : les modèles, les jeux de données, les bibliothèques SDK, les compétences agentiques, les intégrations MCP, les prompts utilisés à l'inférence et surtout, comment tous ces composants interagissent entre eux et se connectent aux workflows métier.
C'est cette dernière partie que la plupart des équipes sous-estiment. Il ne s'agit pas seulement des outils IA existants. C'est la façon dont ils sont interconnectés. Un agent de codage IA avec accès lecture à votre base de code et accès écriture à votre pipeline CI/CD présente un profil de risque fondamentalement différent de ChatGPT utilisé pour rédiger des réponses e-mail.
« Si vous n'avez pas de visibilité, vous ne pouvez pas comprendre ce qu'il faut protéger »
Cette citation vient de chercheurs travaillant sur des cadres AI-BOM cette semaine, elle est directe mais juste. C'est le même argument qui a poussé l'adoption des SBOM après Log4Shell fin 2021 : les organisations ne pouvaient pas patcher ce qu'elles ne pouvaient pas trouver. Les équipes ont passé des semaines à essayer de déterminer quels systèmes utilisaient la bibliothèque vulnérable.
Le parallèle avec l’IA est suffisamment proche pour être inconfortable. Lorsqu’une vulnérabilité dans un modèle ou un cadre d’agent IA est découverte, ou lorsqu’un incident d’exposition de données survient, les organisations qui auront le plus de difficultés sont celles qui n’ont pas une vision claire de ce qui est déployé.
Et il y a beaucoup de ces organisations en ce moment. ServiceNow a annoncé cette semaine une tour de contrôle IA incluant des interrupteurs d’arrêt d’agent - essentiellement des disjoncteurs pour quand un workflow IA déraille. Les agences de renseignement des Five Eyes (États-Unis, Royaume-Uni, Canada, Australie, Nouvelle-Zélande) ont publié un avis conjoint avertissant que les déploiements rapides d’IA agentique créent des risques de sécurité pour lesquels les organisations ne sont pas préparées.
Ces signaux convergent. Le déploiement de l’IA dépasse largement la gouvernance.
Pourquoi construire cet inventaire est plus difficile qu’il n’y paraît
Le défi des AI-BOM n’est pas le concept, mais l’exécution. Les outils IA entrent dans l’entreprise par plusieurs vecteurs simultanément, et chaque vecteur nécessite une approche de découverte différente.
Les outils officiellement approuvés sont la catégorie facile. Le service IT les a validés, le service juridique a examiné l’accord de traitement des données, la sécurité a donné son accord. Ils devraient déjà figurer dans votre inventaire. Ils ne sont souvent pas très bien documentés, mais au moins quelqu’un sait qu’ils existent.
Les outils IA fantômes sont le problème plus complexe. Ils arrivent via des extensions de navigateur installées sur des comptes personnels, des fonctionnalités IA intégrées dans des outils SaaS (souvent activées par défaut lors d’une mise à jour produit), et un accès API direct par des développeurs qui contournent complètement les achats car générer une clé API prend cinq minutes.
Les pipelines construits par agents sont la catégorie la plus difficile. Quand un développeur utilise un agent IA de codage pour créer une automatisation interne connectée à votre CRM ou entrepôt de données, qui en fait la revue ? Le développeur ne considérait presque certainement pas cela comme un « déploiement d’infrastructure IA ». Il finissait juste un ticket plus vite. Mais cette intégration construite par agent peut maintenant tourner en production avec des identifiants, un accès aux données et des appels à des modèles externes que personne n’a cartographiés, documentés ou évalués.
C’est le cœur du problème AI-BOM : l’inventaire ne doit pas seulement inclure les outils achetés par votre entreprise. Il doit inclure les résultats assistés par IA qui fonctionnent désormais dans votre environnement.
À quoi ressemble une gouvernance IA mature
La bonne nouvelle est que des cadres pratiques émergent rapidement. L’approche s’inspire largement de la sécurité de la chaîne d’approvisionnement : découverte continue plutôt qu’audits ponctuels, classification des risques basée sur l’accès aux données et le rayon d’impact, et application des politiques au niveau de l’intégration.
Pour la plupart des entreprises, un point de départ opérationnel couvre trois couches :
Découverte - Savoir ce qui tourne. Cela signifie surveiller le comportement des extensions de navigateur, les appels API vers des fournisseurs IA connus, les autorisations OAuth SaaS et le trafic réseau vers les points de terminaison des modèles. Cette couche capture la majorité des activités IA fantômes, y compris les outils qui n’ont pas suivi de processus d’achat.
Classification - Tous les outils IA ne présentent pas le même niveau de risque. Un correcteur grammatical présente un profil de menace très différent d’un agent de codage avec accès à une base de données de production. La hiérarchisation des risques permet aux équipes de sécurité de concentrer leurs efforts de gouvernance là où l’exposition est réelle, plutôt que de traiter chaque outil IA comme également dangereux (ce qui mène soit à la paralysie, soit au blocage systématique, aucune des deux approches ne fonctionne).
Surveillance continue - Les outils d’IA évoluent constamment. Les modèles sont mis à jour, de nouvelles intégrations sont ajoutées, les permissions dérivent au fil du temps à mesure que les employés ajoutent des fonctionnalités. Un inventaire statique que vous compilez une fois et mettez à jour annuellement est presque inutile. L’objectif est une image vivante de ce qui se trouve dans votre environnement, mise à jour en continu.
La trajectoire est claire
La gouvernance du Shadow IT a mis environ une décennie à mûrir après le début de l’ère cloud. Les organisations sont passées du blocage réflexe à « comprendre, évaluer, puis approuver » - et ce changement les a rendues à la fois plus productives et plus sécurisées.
La gouvernance IA suit la même trajectoire, mais compressée dans un délai beaucoup plus court. Les organisations qui construisent la couche de visibilité maintenant - avant d’en avoir besoin - seront fondamentalement mieux placées que celles qui s’efforcent de reconstituer leur exposition IA après un incident.
Un AI-BOM n’est pas la ligne d’arrivée. C’est la fondation. Vous ne pouvez pas gouverner ce que vous ne voyez pas, et en ce moment, la plupart des entreprises sont partiellement aveugles à une partie de leur stack IA.
C’est le problème qu’il faut résoudre en priorité.
---
Aona offre aux équipes de sécurité une visibilité continue sur toute utilisation d’outils IA - sanctionnés et fantômes - avec une hiérarchisation automatique des risques et l’application des politiques. [Réservez une démo](/book-demo) pour voir comment cela fonctionne dans votre environnement.
