Shadow AI : cartographier les usages invisibles avant qu’ils deviennent un risque

Le shadow AI apparaît lorsqu’un collaborateur utilise un outil d’IA sans validation formelle. Il peut s’agir d’un service grand public, d’une extension de navigateur, d’un module SaaS ou d’un automatisme intégré dans un logiciel métier.

Le réflexe de tout interdire paraît simple, mais il rate le signal principal : les équipes cherchent à gagner du temps, à comprendre plus vite ou à produire mieux. La bonne réponse consiste à identifier ces usages, puis à décider lesquels peuvent être encadrés.

Le risque quand le sujet reste implicite

Le risque vient de l’invisibilité. Une donnée confidentielle peut sortir du périmètre de contrôle, une clause client peut être copiée dans un outil non prévu, une décision peut s’appuyer sur un résultat non vérifié. Tant que personne ne sait où l’IA est utilisée, personne ne peut vraiment la gouverner.

Un dirigeant n’a pas besoin de tout transformer en dossier technique. Il doit en revanche obtenir une lecture partageable : impact métier, niveau d’urgence, dépendances, coût de l’inaction, responsabilité de décision et preuve attendue. Lorsque cette lecture manque, le comité de direction arbitre souvent sur des impressions, des irritants ou des urgences visibles, alors que les vrais points faibles restent hors champ.

Ce qu’il faut rendre visible

Avant de lancer un plan, il faut rendre le terrain lisible. La cartographie utile n’est pas celle qui remplit un classeur, mais celle qui aide à trancher.

• les outils utilisés hors contrat officiel
• les extensions et assistants activés dans les suites SaaS
• les données envoyées dans les prompts
• les équipes qui utilisent l’IA pour décider ou prioriser
• les fournisseurs qui introduisent de l’IA dans leurs propres services

Cette mise à plat permet de distinguer trois réalités : ce qui est déjà maîtrisé, ce qui repose sur une habitude fragile, et ce qui dépend d’un acteur ou d’un outil que personne ne pilote vraiment. C’est souvent dans cette troisième zone que se cachent les risques les plus coûteux.

Elle donne aussi une base de dialogue plus saine avec les équipes. Le métier peut expliquer ce qui bloque réellement l’activité, l’IT peut montrer les dépendances et la sécurité peut préciser les limites à ne pas franchir. Le sujet cesse alors d’être une opposition entre prudence et vitesse. Il devient une discussion sur le niveau de maîtrise attendu.

Cette étape doit rester courte. On ne cherche pas la perfection documentaire : on cherche les dix informations qui changent une décision. Si une information n’aide ni à prioriser, ni à réduire un risque, ni à attribuer une responsabilité, elle peut attendre la revue suivante.

Les décisions qui doivent être écrites

Une décision numérique doit laisser une trace courte. Pas pour créer de la paperasse, mais pour éviter que la même discussion revienne toutes les deux semaines avec des mots différents.

• ouvrir un canal de déclaration sans sanction immédiate
• classer les usages selon le risque et la valeur
• autoriser rapidement les usages faibles risques
• bloquer les usages impliquant données sensibles sans cadre
• prévoir une solution validée pour les besoins récurrents

La cartographie doit rassurer les équipes : l’objectif n’est pas de punir, mais d’éviter que les meilleurs gains de productivité reposent sur des pratiques fragiles.

La trace peut tenir en quelques lignes : décision prise, option refusée, raison de l’arbitrage, personne responsable, échéance, indicateur de suivi et risque résiduel. Ce format simple protège l’organisation contre deux dérives fréquentes : la décision orale que chacun interprète différemment, et la recommandation qui reste suspendue parce que personne ne veut porter l’arbitrage.

Il faut aussi accepter d’écrire les renoncements. Tout ne peut pas être traité dans le même mois. Nommer ce qui est différé évite que l’équipe confonde absence d’action et oubli. Cela permet de revenir plus tard sur le sujet avec une mémoire claire.

Les erreurs fréquentes

Les échecs viennent rarement d’un manque d’intelligence collective. Ils viennent plutôt d’un cadrage trop tardif, d’un vocabulaire flou ou d’une confusion entre action visible et progrès réel.

• lancer une chasse aux outils qui pousse les usages sous terre
• confondre outil gratuit et absence de risque
• ignorer les fonctionnalités IA ajoutées par les éditeurs
• ne pas vérifier les conditions de réutilisation des données
• oublier les prestataires externes

Le bon réflexe consiste à transformer chaque erreur potentielle en point de contrôle. Si le contrôle est impossible, trop coûteux ou non attribué, le sujet n’est pas prêt pour une généralisation.

La pédagogie compte autant que la méthode. Les équipes acceptent mieux un cadrage lorsqu’elles comprennent le risque évité et le bénéfice recherché. À l’inverse, une règle imposée sans explication sera vécue comme une contrainte administrative, puis contournée dès que la pression du quotidien reviendra.

Un bon cadrage doit donc donner de l’air : ce qui est autorisé, ce qui est interdit, ce qui demande validation, et ce qui peut être expérimenté dans un périmètre limité. Cette clarté accélère souvent les usages au lieu de les ralentir.

Une méthode sur trente jours

Semaine 1 : diffuser un questionnaire court et non accusatoire

Semaine 2 : regrouper les usages par données, métiers et fournisseurs

Semaine 3 : valider une liste blanche provisoire

Semaine 4 : mettre en place une revue mensuelle des nouveaux usages

À la fin du mois, l’objectif n’est pas d’avoir tout réglé. L’objectif est plus utile : disposer d’un périmètre clair, d’une liste de décisions, d’un responsable par action, d’un risque résiduel accepté ou refusé, et d’une prochaine revue datée.

Ce livrable doit être utilisable par une personne qui n’a pas assisté aux ateliers. S’il faut réexpliquer tout le contexte pour le comprendre, il n’est pas encore assez mûr. Une feuille de route fiable indique ce qui change dès maintenant, ce qui sera vérifié plus tard et ce qui nécessite un arbitrage budgétaire ou contractuel.

La direction peut ensuite choisir son rythme : correction immédiate d’un risque, pilote limité, audit ciblé, négociation fournisseur, refonte de processus ou mission courte de transition. L’important est de ne pas laisser le sujet retourner dans l’invisible.

Le test simple à mener

Demandez à chaque équipe de citer trois tâches où l’IA lui fait déjà gagner du temps. Ajoutez seulement deux questions : quelles données sont utilisées et qui vérifie la sortie ? Vous obtiendrez une première carte exploitable.

Ce test doit être court. S’il nécessite trois réunions préparatoires, c’est que le sujet n’est pas encore assez clair. Un bon test révèle rapidement une dépendance, une donnée manquante, un accès mal géré, une responsabilité ambiguë ou une hypothèse de valeur trop optimiste.

Le résultat doit être formulé sans jargon. Exemple : nous savons le faire, nous ne savons pas encore le faire, nous savons le faire mais trop lentement, ou nous savons le faire seulement grâce à une personne ou un fournisseur unique. Ces quatre réponses valent mieux qu’un long commentaire technique, car elles conduisent naturellement à une décision.

Il faut conserver la preuve du test : date, périmètre, participants, résultat, blocages et décision suivante. Cette preuve devient très utile lors d’un audit, d’un incident, d’un changement d’équipe ou d’une négociation avec un prestataire.

Le point de vue GDLTC

Révolution Numérique ! éclaire la partie gouvernance et transformation numérique : https://amzn.eu/d/04bEf6v3. Pour la dimension protection, CyberDéfense et Résilience apporte un complément naturel : https://amzn.eu/d/0dR24Rnw. Les deux lectures ramènent les usages IA invisibles à une question simple : qui décide, avec quelles preuves et quelle capacité de reprise ?

Besoin d’un cadrage fiable ?

GDL T&C accompagne les dirigeants, DSI, managers de transition et équipes métiers pour transformer les usages IA invisibles en diagnostic, arbitrages et feuille de route exploitable.

Pour transformer le shadow AI en portefeuille d’usages maîtrisés : https://gdltc.fr