L’IA invisible est déjà dans l’entreprise : le prochain chantier du DSI sera d’en dresser l’inventaire

Pendant des années, les entreprises ont cherché à savoir quels logiciels tournaient dans leur système d’information. Elles ont construit des inventaires, des CMDB, des catalogues d’applications et, plus récemment, des SBOM capables de détailler les composants intégrés dans un logiciel. Avec l’intelligence artificielle, cette discipline doit désormais changer d’échelle.

Car une application d’IA n’est pas seulement constituée d’un programme. Elle peut associer un modèle téléchargé sur une plateforme publique, une base vectorielle, plusieurs jeux de données, un moteur d’inférence, des bibliothèques open source, des API externes, des agents autonomes, des outils métiers et des règles de sécurité ajoutées parfois à la dernière minute.

Dans de nombreuses entreprises, personne ne possède aujourd’hui une vision complète de cet assemblage.

Le 13 juillet 2026, Google Cloud a ouvert le code de k8s-aibom, un contrôleur Kubernetes conçu pour détecter automatiquement les charges d’intelligence artificielle réellement exécutées dans un environnement. L’outil identifie notamment des moteurs comme vLLM, Triton, TGI ou Ollama, mais aussi des frameworks agentiques tels que LangChain, AutoGen et CrewAI, ainsi que certaines bases vectorielles. Il produit ensuite un inventaire exploitable au format CycloneDX ML-BOM. 

Derrière ce lancement technique se cache un sujet de gouvernance majeur : les entreprises commencent à déployer davantage d’IA qu’elles ne sont capables d’en administrer.

Après le Shadow IT, voici le Shadow AI

Le Shadow IT désignait les logiciels, services cloud et équipements installés en dehors des processus officiels de la DSI. Le Shadow AI va beaucoup plus loin.

Un collaborateur peut utiliser discrètement un assistant public avec des documents confidentiels. Un développeur peut télécharger un modèle open source et le déployer dans un conteneur. Une équipe métier peut connecter un agent à Salesforce, SharePoint ou un ERP. Une filiale peut acheter un service d’IA sans vérifier l’hébergement des données. Un prestataire peut intégrer un modèle tiers dans une application sans le mentionner clairement dans sa documentation.

Chacune de ces initiatives peut être utile. Ensemble, elles créent une zone aveugle.

Le problème n’est donc plus seulement de savoir si l’entreprise utilise ChatGPT, Gemini, Claude ou un modèle local. Il faut savoir quel modèle est utilisé, dans quelle version, avec quelles données, par quel processus, pour quels utilisateurs et avec quelles autorisations.

Le NIST recommande depuis plusieurs années de tenir un inventaire des systèmes d’IA comprenant leur documentation, leurs responsables, leurs données, leurs plans de réponse aux incidents et les informations nécessaires à leur maintenance. Cet inventaire doit permettre de répondre rapidement à des questions simples : combien de modèles sont déployés, quand ont-ils été mis à jour et quels utilisateurs sont affectés par leur fonctionnement ? 

Or beaucoup d’organisations seraient aujourd’hui incapables de répondre précisément.

L’AIBOM devient la fiche d’identité de l’intelligence artificielle

Un AIBOM, ou AI Bill of Materials, peut être compris comme la liste des ingrédients d’un système d’IA. Il étend la logique du SBOM traditionnel aux modèles, aux données, aux frameworks, aux services, aux agents et aux mécanismes de contrôle.

Le standard CycloneDX définit ainsi le ML-BOM comme un document décrivant les composants, configurations et processus intervenant dans le développement, l’entraînement, le déploiement et l’hébergement d’un modèle. Il peut également relier cet inventaire aux composants logiciels, matériels, cryptographiques et aux services utilisés par le système. 

Concrètement, un AIBOM sérieux devrait permettre d’identifier :

le modèle utilisé et sa version ;

son origine et sa licence ;

les données ayant servi à son adaptation ;

les bibliothèques et moteurs nécessaires à son exécution ;

les bases vectorielles et sources documentaires interrogées ;

les API et outils auxquels les agents ont accès ;

les mécanismes de filtrage et de supervision ;

les responsables techniques et métiers du système.

Cette transparence change la gestion des incidents.

Supposons qu’une vulnérabilité soit découverte dans une version précise d’un moteur d’inférence. Sans inventaire, les équipes devront interroger les développeurs, fouiller les clusters et espérer que personne n’a oublié un prototype devenu critique. Avec un AIBOM actualisé, elles peuvent identifier immédiatement les applications concernées.

Même logique lorsqu’un modèle est retiré pour une licence ambiguë, lorsqu’un jeu de données est suspecté d’avoir été empoisonné ou lorsqu’un composant transmet des informations à un service externe.

La CISA considère déjà le SBOM comme un élément essentiel de la gestion des risques liés à la chaîne d’approvisionnement logicielle. L’OWASP applique maintenant cette logique aux systèmes d’IA et propose des outils open source pour produire des inventaires structurés et lisibles par les machines. 

Une opportunité pour industrialiser, pas une nouvelle bureaucratie

Certains verront dans l’AIBOM un document supplémentaire demandé par la sécurité ou la conformité. Ce serait une erreur.

Un inventaire correctement automatisé peut au contraire accélérer les projets. Il évite aux équipes de reconstituer laborieusement l’architecture avant chaque audit, revue cyber ou passage en production. Il facilite les changements de modèle, les comparaisons de coûts et l’identification des dépendances envers un fournisseur.

Il peut aussi devenir un outil de pilotage financier. Une entreprise découvrira peut-être qu’elle paie cinq API différentes pour des usages similaires, qu’un modèle gigantesque traite des tâches simples ou que des infrastructures GPU restent actives pour des projets abandonnés.

Pour le DSI, l’AIBOM constitue donc un pont entre quatre préoccupations longtemps séparées : la sécurité, l’architecture, la conformité et la maîtrise des coûts.

Mais l’inventaire doit être généré au plus près de la réalité opérationnelle. Google insiste justement sur la détection des charges réellement exécutées, y compris lorsqu’elles n’ont pas été enregistrées dans un processus officiel. Son contrôleur fonctionne sans privilèges élevés, sans modifier les applications et sans ajouter de composant dans chaque conteneur, afin de limiter les perturbations pour les développeurs et les exploitants. 

Cette approche est importante : un inventaire purement déclaratif finit presque toujours par devenir incomplet.

L’inventaire ne suffira pourtant pas

Un AIBOM n’est pas une protection magique. Il peut indiquer qu’un modèle, un agent ou une base vectorielle existe, sans prouver que son comportement est sûr.

Un agent peut disposer de permissions excessives. Un modèle peut produire des réponses erronées. Une base documentaire peut contenir des informations confidentielles. Une API peut modifier ses conditions d’utilisation. Un fournisseur peut mettre à jour silencieusement son modèle. Une chaîne RAG peut être manipulée par des documents malveillants.

L’inventaire est une carte, pas un bouclier.

Il doit être associé à des contrôles d’accès, à une journalisation des actions, à des évaluations régulières, à une surveillance des usages et à des procédures de retrait rapide. L’OWASP rappelle d’ailleurs que les risques de chaîne d’approvisionnement concernent aussi les modèles, les données, les packages et les services externes, et recommande de maintenir un inventaire exact et actualisé des composants. 

La seconde limite concerne les services SaaS. Il est relativement facile d’observer un modèle déployé dans son propre cluster Kubernetes. Il est beaucoup plus difficile de détecter les assistants intégrés dans des applications cloud, les extensions installées par les utilisateurs ou les agents créés directement dans des plateformes métiers.

L’AIBOM devra donc rejoindre les inventaires IAM, SaaS, API et données. L’entreprise ne peut plus administrer séparément ses logiciels, ses identités, ses données et ses intelligences artificielles.

Ce que les DSI devraient décider maintenant

La première décision consiste à établir un inventaire initial, même imparfait, des usages d’IA : API externes, modèles locaux, fonctions intégrées dans les SaaS, assistants personnels, agents, bases vectorielles et projets expérimentaux.

La deuxième consiste à définir un propriétaire pour chaque système. Une IA sans responsable métier, technique et sécurité identifié ne devrait jamais accéder à une donnée sensible ou déclencher une action opérationnelle.

La troisième consiste à intégrer la production d’un AIBOM dans les chaînes de développement et de déploiement, plutôt que de demander aux équipes de remplir manuellement un fichier destiné à devenir obsolète.

Enfin, il faut accepter une réalité : l’intelligence artificielle est en train de devenir une nouvelle couche du système d’information. Elle doit donc être inventoriée, gouvernée et auditée avec le même sérieux que les applications, les infrastructures et les identités.

Le prochain scandale technologique ne viendra peut-être pas d’un modèle devenu incontrôlable. Il viendra plus simplement d’une entreprise découvrant, trop tard, qu’elle ignorait totalement où ce modèle était utilisé, quelles données il manipulait et ce qu’elle lui avait permis de faire.

Avant de promettre une entreprise augmentée par l’IA, commençons donc par répondre à une question élémentaire : savons-nous réellement quelles intelligences artificielles travaillent déjà chez nous ?

#IntelligenceArtificielle #AIBOM #DSI #Cybersécurité #ShadowAI #GouvernanceIA #TransformationNumérique #IAAgentique #Cloud #Kubernetes #SupplyChainSecurity #GestionDesRisques #ArchitectureSI #DataGovernance #Innovation #SouverainetéNumérique