An Inventaire de l'IA est un catalogue mis à jour en continu de tous les actifs d'IA exécutés au sein de votre organisation — modèles, points de terminaison alimentés par l'IA, ensembles de données, assistants de codage IA, serveurs MCP et dépendances IA — ainsi que les relations, les risques et les propriétaires qui les relient. Dans un contexte de sécurité, cela n'a rien à voir avec la gestion des entrepôts ou des stocks ; ici, « Inventaire IA » Cela signifie tout simplement savoir exactement quelle IA vous utilisez, où elle se trouve et ce qu'elle peut atteindre.
L'IA se répand à toutes les étapes du développement logiciel, de la génération de code dans l'IDE aux agents autonomes agissant au sein des systèmes. CI/CD pipelineDésormais, la question n'est plus de savoir si l'IA est présente dans votre environnement. Tout dépend de si vous pouvez le voir. Ce guide explique ce qu'est un inventaire IA et comment il est lié à un Nomenclature AI-BOM et le SBOM, Pourquoi IA de l'ombre est devenu un problème de sécurité, et la manière dont cette pratique se traduit en Loi de l'UE sur l'IA, NIST IA RMF et ISO / IEC 42001.
Points clés à retenir
- Un inventaire d'IA répertorie chaque modèle, ensemble de données, agent, serveur MCP et outil de codage d'IA tout au long du cycle de vie de vos logiciels, et pas seulement ceux approuvés par le service informatique.
- IA de l'OmbreL’IA adoptée sans gouvernance est désormais la norme, et non plus l’exception : selon une enquête menée en 2026 auprès de responsables de la sécurité, seuls 19 % des organisations ont déclaré avoir une visibilité complète sur l'utilisation de l'IA, notamment sur les lieux et les modalités de son utilisation..
- An AI-BOM (Nomenclature des matériaux IA) est le résultat prêt à être audité d'un inventaire d'IA : le successeur à l'ère de l'IA de SBOM.
- La réglementation arrive. La loi européenne sur l'IA, le cadre de référence NIST pour l'IA et la norme ISO/IEC 42001 exigent tous, de fait, que vous sachiez quel type d'IA vous utilisez.
- Un inventaire n'est que le point de départ ; la valeur provient de l'évaluation des risques et de la prise en compte du petit nombre d'actifs qui comptent réellement.
Qu'est-ce qu'un inventaire IA ?
Un inventaire d'IA consiste à recenser, cataloguer et surveiller en continu chaque ressource d'IA utilisée tout au long du cycle de vie du développement logiciel, ainsi que les risques associés à chacune. Un inventaire complet répond à trois questions pour chaque ressource : de quoi s'agit-il, où est-elle exécutée et à quoi peut-elle accéder ?
Cette portée est plus large que ce que la plupart des équipes anticipent. Un inventaire IA pertinent devrait couvrir :
- Modèles: tous les grands modèles de langage et modèles de base utilisés en développement et en production, avec leur version, leur emplacement et leur niveau de confiance dans la détection.
- Jeux de données: données d'entraînement, ensembles de données de récupération et stockage de vecteurs, y compris l'exposition à un contexte empoisonné et aux fuites de données.
- Agents: des systèmes autonomes qui agissent dans votre environnement, comme par exemple ouvrir pull requests, en installant des dépendances ou en modifiant l'infrastructure.
- serveurs MCP: Protocole de contexte modèle Des serveurs qui connectent les assistants IA aux outils externes, aux API et aux sources de données.
- Outils et assistants de codage IA: copilotes et intégrations IDE qui génèrent du code, suggérer des dépendances et interagir avec les dépôts.
- Cadres IALangChain, LangGraph, les serveurs d'agents et autres couches d'orchestration qui relient les modèles aux outils et aux données.
- Relations entre les actifsLes liens entre les modèles, les agents, les serveurs, les ensembles de données et les secrets qui leur sont associés. Un graphe de relations permet de visualiser le risque dans son contexte, et non sous forme de simple liste.
Inventaire IA vs inventaire des actifs IA vs nomenclature IA : différences avec un SBOM
Ces termes sont utilisés de manière imprécise, il est donc utile d'être pré-réglé.cise. « Inventaire d'IA » et « inventaire des actifs d'IA » désignent la même chose.: le catalogue vivant des actifs d'IA et de leurs risques. AI-BOM est l'artefact exportable produit par l'inventaire.: une nomenclature lisible par machine que vous pouvez remettre à un auditeur ou à un enterprise acheteur.
La manière la plus simple de comprendre l'AI-BOM est par analogie avec la SBOM:
À mesure que l'IA s'intègre dans tous les aspects de la vie SDLC, la nomenclature IA devient aussi fondamentale que SBOMet les responsables de la sécurité reçoivent de plus en plus de demandes de la part des auditeurs et enterprise Des équipes d'approvisionnement précisément pour cet artefact.
Pourquoi l'inventaire IA est important maintenant
Trois forces ont transformé l'inventaire d'IA d'un atout appréciable en une priorité.
- Premièrement, l'IA écrit du code non sécurisé à grande échelle. Des recherches indépendantes montrent systématiquement qu'une grande partie du code généré par l'IA comporte des vulnérabilités. L'étude initiale NYU/Copilot de Pearce et al. a révélé qu'environ 40 % des programmes générés présentaient des failles de sécurité.et des tests à grande échelle plus récents vont dans le même sens : l’analyse de Veracode en 2025 portant sur plus de 100 modèles n’a révélé que 55 % du code généré par l'IA était sécuriséSi vous ne savez pas quels assistants génèrent du code dans votre pipelines, vous ne pouvez pas maîtriser ce risque.
- Deuxièmement, la chaîne d'approvisionnement logicielle est devenue une surface d'attaque pour l'IA. En Septembre 2025, Shai Hulud, le premier ver npm auto-réplicatif, a transformé les machines des développeurs en un mécanisme de distribution, se propageant à travers des centaines de paquets. En mars 2026, des attaquants ont compromis axios, un paquet contenant environ 100 millions de téléchargements hebdomadairesIls ont publié des versions infectées qui déposaient un cheval de Troie d'accès à distance. Ce type d'attaques cible précisément la couche intermédiaire entre la sécurité applicative traditionnelle et les outils de sécurité des terminaux : celle qu'un inventaire IA est conçu pour mettre en lumière.
- Troisièmement, des secrets et des identifiants fuitent via l'IA. Le rapport « State of Secrets Sprawl 2026 » de GitGuardian indique que Les fuites de secrets liés aux services d'IA ont augmenté de 81 % d'une année sur l'autre.et que l'IA commits leak secretLe taux est environ deux fois supérieur au taux de base. Chaque modèle, agent ou serveur MCP non documenté représente une voie potentielle d'obtention d'identifiants.
Les solutions AppSec traditionnelles s'arrêtent au référentiel et ne prennent pas en compte la notion de modèle. Les outils de sécurité des terminaux surveillent le système d'exploitation, mais ignorent tout des packages, des serveurs MCP et des assistants IA. C'est dans cet écart que s'accumulent les risques liés à l'IA, et un inventaire est la première étape pour les combler.
Où se cache l'IA : L'IA fantôme à travers le monde SDLC
IA de l'Ombre Tout système d'IA adopté sans approbation ni gouvernance formelles – le copilote activé par un développeur la semaine dernière, le serveur MCP fonctionnant sur un ordinateur portable, le modèle directement extrait d'une plateforme publique pour un projet parallèle – est concerné. Il ne s'agit pas d'un cas isolé. Dans une enquête menée en 2026 auprès de plus de 400 responsables de la sécurité, seuls 19 % ont déclaré avoir une visibilité complète sur les lieux et les modalités d'utilisation de l'IA au sein de leur organisation, alors que l'immense majorité utilisait déjà ou testait des assistants de codage IA.
L'IA fantôme la plus difficile à détecter est celle qui se trouve à l'intérieur du cycle de vie du logiciel, car elle apparaît rarement dans une console cloud :
- Modèles et bibliothèques d'IA intégrés aux référentiels en tant que dépendances.
- Assistants de codage IA configurés par développeur, par IDE.
- Serveurs MCP et fichiers de règles exécutés localement sur les points de terminaison des développeurs.
- Les flux de travail agentiques s'ouvrent discrètement pull requests ou en installant des paquets.
C’est pourquoi la découverte exclusive dans le cloud ne suffit pas. Un inventaire IA véritablement complet doit s’étendre au code et aux environnements de compilation (l’ordinateur portable du développeur, le dépôt, etc.). pipeline), et pas seulement le cloud de production.
Éléments à inclure dans une nomenclature AI-BOM
Une nomenclature IA conforme aux exigences d'audit transforme votre inventaire en un document justifiable. Elle doit au minimum inclure :
- Tous les éléments d'IA : modèles, ensembles de données, agents, serveurs MCP, outils de codage IA.
- Type d'actif, emplacement et niveau de confiance de détection pour chacun.
- Provenance et dépendances (d'où provient le modèle ou le composant).
- Un niveau de risque par actif, basé sur les vecteurs d'attaque spécifiques à l'IA.
- Correspondance réglementaire avec la loi européenne sur l'IA, le NIST AI RMF et la norme ISO/IEC 42001.
- Un format exportable et lisible par machine pour les auditeurs et les clients.
Les organisations capables de générer une nomenclature IA à la demande bénéficieront d'un réel avantage en matière de conformité et de confiance à mesure que les obligations d'audit IA évolueront.
Inventaire et conformité en matière d'IA : loi européenne sur l'IA, NIST AI RMF et ISO/IEC 42001
Aucun des principaux cadres de référence n'intègre explicitement l'« inventaire de l'IA » dans ses exigences, or il est pratiquement impossible de s'en satisfaire sans cet élément. On ne peut documenter, classifier ni gouverner des systèmes d'IA que l'on ne peut visualiser.
Note concernant le calendrier : le déploiement de la loi européenne sur l’IA a été revu par l’accord « Digital Omnibus » de mai 2026, qui a reporté la plupart des obligations à haut risque à décembre 2027, tout en maintenant plusieurs échéances du 2 août 2026 (obligations de transparence, pouvoirs de sanction du GPAI). Il convient de considérer les dates exactes comme évolutives et de les vérifier auprès des sources primaires de l’UE. Toutefois, la direction à suivre est claire et l’inventaire est indispensable à sa mise en œuvre.
Comment construire et maintenir un inventaire d'IA
Constituer un inventaire ne consiste pas tant à réaliser un audit ponctuel qu'à établir un processus continu, car les actifs d'IA évoluent constamment : nouveaux modèles adoptés, nouveaux agents déployés, nouveaux serveurs MCP configurés, souvent sans approbation.
Une approche pratique :
- Découverte automatique à travers le code, la compilation et le cloud. Les feuilles de calcul manuelles deviennent obsolètes en quelques jours. Discovery doit fonctionner en continu et explorer les données. SDLC, et pas seulement en termes de temps d'exécution.
- Classer et cartographier les relations. Type d'enregistrement, emplacement, provenance et, surtout, comment chaque document est lié aux autres et aux secrets.
- Évaluer le risque dans son contexte. Une liste plate de centaines de résultats n'aide personne ; priorisez en fonction de ce qui est réellement accessible, exploitable et essentiel à l'activité.
- Attribuer la propriété. Chaque actif a besoin d'un propriétaire responsable.
- Maintenez-le en ligne et exportable. Maintenez-le comme un inventaire continu capable de produire une nomenclature IA à la demande.
Critères de choix d'un logiciel d'inventaire IA
Si vous évaluez des outils, voici les fonctionnalités qui distinguent un véritable logiciel d'inventaire IA d'une simple liste statique :
- Comprend les types d'actifs spécifiques à l'IA (modèles, agents, serveurs MCP, ensembles de données), et pas seulement des packages et des bibliothèques.
- S'étend dans le SDLC, en découvrant l'IA dans le code et sur les terminaux des développeurs, et pas seulement dans le cloud.
- Relations cartographiques, et pas seulement les actifs individuels, le risque est donc visible dans son contexte.
- Évalue les risques liés aux vecteurs d'attaque spécifiques à l'IA (injection rapide, MCP non sécurisé, autorité excessive), et pas seulement la gravité de l'ECV.
- Fonctionne en continu, en capturant les nouvelles IA dès leur apparition.
- Génère une nomenclature IA prête pour l'audit qui satisfait à la fois les auditeurs et enterprise approvisionnement.
- Relie l'inventaire à l'application de la loi, afin que vous puissiez agir en fonction de ce que vous trouvez.
De l'inventaire à l'action : sécuriser ce que vous trouvez
La découverte est la première étape ; la seconde consiste à identifier les actifs présentant un risque réel, car la plupart n’en présentent pas. L’objectif est de passer de milliers d’éléments bruts à la poignée d’éléments susceptibles de compromettre réellement les systèmes, les données ou les opérations : ceux qui sont activement utilisés, acceptent des entrées non fiables, sont exploitables de manière réaliste, détiennent des accès sensibles et affectent la production ou les actifs réglementés.
C'est là qu'intervient la gestion de la posture de sécurité par IA (IA-SPMLe processus comprend l'inventaire des risques, l'évaluation de ces risques tout au long du parcours d'attaque de l'IA, leur mise en correspondance avec la réglementation et la production de la nomenclature des vulnérabilités liées à l'IA (AI-BOM). C'est également à ce stade que l'inventaire rencontre l'application de la loi : blocage des dépendances malveillantes avant leur installation, rejet des serveurs et modèles MCP non approuvés et confinement des terminaux compromis avant la propagation d'un incident.
At Xygéni, voici le modèle que nous cherchons à mettre en place : un inventaire IA continu et une nomenclature IA via une gestion des programmes IA (AI-SPM), une détection de logiciels malveillants qui repère les paquets malveillants avant même qu’une signature n’existe (MEW, alerte précoce aux logiciels malveillants), et l'application des politiques au niveau du poste de développement via Xygeni Shield. La détection est conforme aux 10 principales vulnérabilités OWASP pour les applications LLM, les applications agentiques et les applications MCP. Quel que soit votre choix, le principe reste le même : On ne peut sécuriser ce qu'on ne voit pas, et l'inventaire basé sur l'IA est le point de départ de la visibilité.
FAQ
En quoi une nomenclature AI-BOM diffère-t-elle d'une nomenclature AI-BOM ? SBOM?
An SBOM Les catalogues recensent les dépendances logicielles open source et tierces, classées selon leur gravité CVE. Une nomenclature d'IA (AI-BOM) répertorie les ressources spécifiques à l'IA (modèles, agents, serveurs MCP, jeux de données) avec une évaluation des risques et une cartographie réglementaire spécifiques à l'IA. À mesure que l'IA se répand dans le monde entier, SDLC, la nomenclature IA devient aussi fondamentale que SBOM.
Qu’est-ce que l’intelligence artificielle de l’ombre et comment la découvrir ?
L'IA fantôme désigne toute IA adoptée sans approbation ni gouvernance formelle : un copilote activé, un serveur MCP local, un modèle extrait d'une plateforme publique. Sa détection s'effectue par un inventaire automatisé continu qui explore le code source et les différentes versions de la plateforme. pipelineet les points de terminaison des développeurs, et pas seulement le cloud de production où la plupart des IA fantômes n'apparaissent jamais.
La loi européenne sur l'IA exige-t-elle un inventaire des systèmes d'IA ?
La loi européenne sur l'IA ne mentionne pas explicitement l'« inventaire de l'IA », mais ses obligations de documentation, de classification et d'enregistrement des systèmes à haut risque sont impossibles à satisfaire sans un tel inventaire. Il en va de même pour le cadre de gestion des risques liés à l'IA du NIST (fonction Map, Govern 1.6) et la norme ISO/IEC 42001, qui exigent la tenue d'un inventaire des systèmes d'IA.
Qu'est-ce que l'AI-SPM ?
La gestion de la posture de sécurité de l'IA (AI-SPM) consiste à découvrir en continu les actifs d'IA, à évaluer leur risque tout au long du parcours d'attaque, à les mettre en correspondance avec la réglementation et à produire une nomenclature de sécurité de l'IA (AI-BOM). Elle étend les principes de gestion de la posture (connus grâce à CSPM et DSPM) aux actifs et vecteurs d'attaque spécifiques à l'IA.
À quelle fréquence un inventaire d'IA doit-il être mis à jour ?
En continu, les ressources d'IA évoluent quotidiennement : les équipes adoptent de nouveaux modèles, déploient de nouveaux agents et configurent de nouveaux serveurs MCP, généralement sans validation formelle. Une analyse ponctuelle devient obsolète en quelques jours ; un logiciel d'inventaire d'IA efficace fonctionne donc comme un processus continu et non comme un audit unique.
Comment recenser l'IA utilisée dans le code source ?
L'inventaire de l'IA dans le code implique la détection des modèles et bibliothèques d'IA intégrés comme dépendances, des assistants de codage IA configurés pour chaque développeur, ainsi que des serveurs MCP ou des fichiers de règles exécutés localement. Cela nécessite une découverte opérant au sein du système. SDLC (dépôts, construction) pipeline(et les points de terminaison pour développeurs) plutôt que uniquement dans les consoles cloud.
