Comment maîtriser le shadow IA avec l’ITAM ?

L’intelligence artificielle s’est installée dans les entreprises à une vitesse qui dépasse souvent celle des processus de gouvernance. ChatGPT, Gemini, Claude, Copilot et une multitude d’outils spécialisés sont désormais utilisés quotidiennement par les collaborateurs, parfois sans validation de la DSI, de la sécurité ou des achats. Ce phénomène, appelé Shadow AI, constitue une nouvelle déclinaison du Shadow IT… mais avec des enjeux potentiellement beaucoup plus sensibles.

Selon IBM, le Shadow AI correspond à l’utilisation d’outils d’intelligence artificielle sans approbation ou supervision formelle de l’IT. IBM souligne notamment que 38 % des salariés interrogés déclarent avoir partagé des informations professionnelles sensibles avec des outils d’IA sans autorisation de leur employeur.[1]

Face à cette prolifération, l’IT Asset Management (ITAM) peut jouer un rôle central. L’enjeu n’est cependant pas de simplement « interdire l’IA », mais de rendre visible, qualifier et gouverner un nouvel actif logiciel particulièrement dynamique.

Le Shadow AI : un nouvel angle mort pour l’entreprise

Le Shadow AI peut prendre des formes très différentes. Un collaborateur peut utiliser un chatbot public pour reformuler un contrat, analyser un fichier Excel ou préparer une présentation. Un développeur peut intégrer une API d’IA dans une application sans passer par les processus d’architecture ou d’achat. Une équipe peut également activer une fonctionnalité d’IA directement incluse dans une solution SaaS déjà référencée.

Cette dernière situation est particulièrement intéressante pour l’ITAM : le risque ne provient pas nécessairement d’un nouveau logiciel. Il peut apparaître à l’intérieur d’un logiciel déjà présent dans le parc.

CrowdStrike souligne ainsi que les plateformes SaaS ajoutent désormais des fonctionnalités d’IA susceptibles de traiter des données professionnelles, parfois avant même que les équipes de sécurité aient pu en évaluer les implications.[2]

Le Shadow AI élargit donc considérablement le périmètre traditionnel du Software Asset Management : il ne s’agit plus seulement de savoir quel logiciel est installé, par qui et avec quelle licence, mais également quelles capacités d’IA sont utilisées, par quels utilisateurs, avec quelles données et dans quelles conditions contractuelles.

Première étape : découvrir avant de contrôler

La première contribution de l’ITAM est sa capacité à établir une vision fiable du patrimoine logiciel.

Pour identifier le Shadow AI, il faut croiser plusieurs sources : inventaires logiciels, données de dépenses et d’achats, contrats SaaS, annuaires SSO, données d’usage, navigation web ou encore informations issues des équipes métiers.

USU recommande notamment de ne pas limiter la découverte aux logiciels officiellement déployés par l’IT, mais d'examiner également les journaux SSO, les données financières et les outils accessibles directement depuis les navigateurs.[3]

Cette approche permet de constituer un inventaire des usages IA et de distinguer trois catégories : les solutions approuvées, les solutions tolérées sous conditions et les solutions inconnues ou interdites.

L’objectif n’est pas de créer un énième inventaire isolé, mais d’intégrer les actifs et services d’IA au référentiel ITAM existant.

Deuxième étape : qualifier le risque

Découvrir un outil ne suffit pas. Tous les usages de l’IA ne présentent pas le même niveau de risque.

L’ITAM peut contribuer à construire une grille de qualification prenant en compte plusieurs critères : nature des données traitées, localisation des données, fournisseur, modèle utilisé, conditions contractuelles, conservation des prompts et des résultats, intégration avec le système d’information ou encore criticité du processus métier concerné.

Snyk distingue ainsi le Shadow AI du Shadow IT traditionnel par la nature même des risques : les systèmes d’IA peuvent traiter des données d’entraînement, des prompts et des informations issues de l’inférence, tandis que certaines implémentations peuvent également utiliser des API, des modèles hébergés dans le cloud ou des composants développés localement.[4]

L’ITAM devient alors un point de convergence entre logiciel, fournisseur, contrat, utilisateur et usage.

Troisième étape : passer d’une logique d’interdiction à une gouvernance par le risque

Une politique consistant à simplement bloquer tous les outils d’IA risque de conduire les utilisateurs à contourner les contrôles.

La réponse consiste plutôt à définir un catalogue de solutions autorisées, accompagné de règles claires : quelles données peuvent être transmises ? Pour quels usages ? Avec quelles garanties contractuelles ? Quelles solutions nécessitent une validation préalable ?

L’ITAM peut ici contribuer à identifier les solutions déjà couvertes par les contrats existants et à éviter la multiplication de solutions similaires. Une entreprise peut par exemple déjà disposer de capacités d’IA dans ses contrats Microsoft, Adobe, Salesforce ou ServiceNow sans avoir besoin d’acheter séparément plusieurs outils équivalents.

Cette démarche permet également de rapprocher gestion des licences, optimisation des coûts et gouvernance de l’IA.

Quatrième étape : intégrer l’IA au cycle de vie ITAM

Le véritable enjeu est d’éviter que le Shadow AI ne soit traité comme un projet ponctuel.

Chaque nouvelle solution d’IA devrait pouvoir suivre un cycle comparable à celui d’un logiciel classique : demande, évaluation, validation, contractualisation, déploiement, suivi de l’utilisation, revue des risques et renouvellement.

Cela permet notamment d’intégrer les questions relatives à l’IA dans les processus existants de Software Asset Management et de Vendor Management.

L’ITAM Review observe d’ailleurs que les professionnels de l’ITAM sont désormais confrontés directement à l’intégration de l’IA dans les logiciels d’entreprise et aux conséquences que celle-ci peut avoir sur les renouvellements et les relations avec les éditeurs.[5]

Vers un « AI Asset Management » ?

Le Shadow AI révèle finalement une évolution du rôle de l’ITAM.

Hier, le SAM cherchait principalement à répondre à trois questions : quels logiciels avons-nous ? Combien de licences possédons-nous ? Sommes-nous en conformité ?

Demain, il faudra également répondre à : quelles capacités d’IA utilisons-nous ? Qui les utilise ? Sur quelles données ? Avec quels fournisseurs ? À quelles conditions ? Et pour quels usages métier ?

La Cloud Security Alliance souligne que les nouveaux agents et applications d’IA peuvent aller au-delà du simple traitement de données : certains sont capables d’initier des connexions vers des services externes, d’exécuter du code ou de conserver des informations d’authentification.[6]

L’ITAM a donc une carte importante à jouer dans cette transformation. En apportant visibilité, qualification, maîtrise contractuelle, optimisation et suivi du cycle de vie, il peut devenir l’un des piliers de la gouvernance du Shadow AI.

La question n’est finalement plus de savoir comment empêcher les collaborateurs d’utiliser l’IA. Il s’agit de construire un environnement dans lequel l’usage de l’IA est visible, maîtrisé et aligné avec les intérêts de l’entreprise.

Rédigé par Eric De Meckenheim,

Senior Project Manager

Notes et sources

[1] IBM, Qu’est-ce que le Shadow AI ?, 25 octobre 2024. Source : IBM Think.

[2] CrowdStrike, Shadow AI: The Hidden Risk Expanding Across the Enterprise, 29 mai 2026. Source : CrowdStrike.

[3] USU, Comment gérer le shadow AI en entreprise ?, 15 avril 2026. Source : USU / IT Asset Management.

[4] Snyk, Shadow AI: Unmasking the Hidden Risks in Your Enterprise. Source : Snyk.

[5] ITAM Review, ITAM News & Analysis, notamment les analyses consacrées à l’évolution des logiciels d’entreprise et à l’IA, 2026.

[6] Cloud Security Alliance, The Shadow AI Blind Spot: Ownership Fragmentation as Enterprise Attack Surface, 8 mai 2026, et Shadow AI Applications in the Enterprise, mai 2026.