EcoLLM
Shadow AI : quand l’adoption de l’IA devance les organisations
Pour la première fois depuis le début de l’informatique professionnelle, les outils auxquels vos agents ont accès à titre personnel sont souvent plus puissants et plus simples que ceux que vous mettez à leur disposition. L’IA générative est déjà dans la maison, mais rarement là où l’organisation l’avait prévue.
C’est ce qu’on appelle le Shadow AI. On le traite en général comme un problème de discipline, à régler par une interdiction ou par une liste d’outils autorisés. C’est une erreur de diagnostic, et les deux réponses produisent le même résultat : elles l’aggravent.
EcoLLM est une assistance à maîtrise d’ouvrage sur tout système d’IA générative. Nous évaluons toutes les solutions du marché, de Claude à Dict.ai en passant par Mistral, ChatGPT, Copilot, DelibIA, Delos ou Linagora, et nous n’en portons que certaines à prix coûtant.
Cet article ne recommande aucune solution et n’en écarte aucune. Les outils y sont cités comme exemples de ce qu’une organisation rencontre aujourd’hui.
L’IA s’adopte plus vite que les organisations
Le décalage n’est pas un défaut de culture numérique. C’est un écart d’outillage.
Les organisations n’ont jamais autant parlé d’intelligence artificielle. Les preuves de concept se multiplient, les feuilles de route se structurent, les budgets apparaissent. Et pendant ce temps, l’adoption réelle se fait ailleurs : là où les agents trouvent une valeur immédiate, avec les outils auxquels ils ont accès sans demander la permission.
Le phénomène a un nom, le BYOAI, apporte ton IA. Il prolonge le BYOD des smartphones personnels, mais il porte bien plus loin : les smartphones posaient une question de sécurité du poste, les assistants d’IA touchent aux données métier, aux processus de décision et à la production elle-même.
Les agents ne cherchent pas à contourner les règles : ils cherchent à tenir leur charge de travail. Ils utilisent l’outil le plus efficace auquel ils ont accès, ce qui est exactement ce qu’on attend d’un professionnel. Le problème n’est pas leur comportement, c’est que l’organisation n’a rien mis en face.
Le Shadow AI fait porter la décision par l’agent
Le risque pour l’organisation est connu ; la charge imposée aux personnes l’est beaucoup moins.
Du côté de l’organisation, l’inventaire est vite fait : des usages non référencés, des données potentiellement exposées, des décisions préparées avec des outils que personne n’a validés, une dépendance implicite à des services externes. C’est le versant que les directions générales voient en premier.
L’autre versant est invisible et pèse sur les agents. À chaque usage, ils tranchent seuls des questions qui dépassent leur périmètre : quelle IA pour cette tâche, puis-je y déposer ce fichier, ce courriel, ces données, comment protéger un secret d’affaires ou une donnée personnelle, où placer le curseur entre efficacité et risque. Ces arbitrages ne sont ni formalisés ni outillés.
Le paradoxe est là. L’IA promet du temps gagné, l’absence de cadre en reprend une partie : temps passé à hésiter sur l’outil, à reformuler ou anonymiser un contenu par précaution, à renoncer à l’IA sur une tâche pourtant pertinente. À l’échelle d’une personne, ces frictions semblent marginales ; à l’échelle d’une organisation, elles érodent le gain attendu et produisent une adoption inégale, parfois anxiogène.
Interdire ne marche pas, présélectionner non plus
Deux réponses opposées en apparence, un même effet : l’écart se creuse.
La première réponse est l’interdiction. Elle échoue pour une raison simple : elle ne supprime pas le besoin qui a produit l’usage. La demande se déplace vers des comptes personnels, sur des postes et des téléphones que l’organisation ne voit pas, et le Shadow AI devient invisible au lieu de disparaître.
La seconde réponse est plus subtile et beaucoup plus répandue : présélectionner. On établit une liste d’outils autorisés en écartant d’emblée une partie du marché, parce que telle solution serait insuffisamment souveraine, telle autre pas assez frugale, telle autre encore non conforme — le plus souvent avant même d’avoir décrit ce qu’on comptait en faire. La démarche paraît responsable. Elle produit pourtant le même résultat que l’interdiction.
Un catalogue filtré en amont crée un écart entre ce que l’agent peut faire chez lui et ce que l’organisation lui propose au bureau. Tant que cet écart existe, il est comblé en dehors du cadre. Le Shadow AI n’est alors plus un accident : il devient structurel, et il est entretenu par la politique censée l’empêcher.
Il y a une raison plus fondamentale de se méfier du filtre a priori : à ce stade, personne ne sait encore de quoi on parle. La conformité n’est pas une propriété d’un logiciel dans l’absolu, c’est une propriété de la rencontre entre un traitement, des données et un contexte. Écarter une solution avant d’avoir décrit l’usage, c’est répondre à une question qui n’a pas été posée.
Ce que fait une AMO IA, et ce qu’elle ne fait pas
La neutralité n’est pas une posture commerciale : c’est la condition pour voir les usages tels qu’ils sont.
Une assistance à maîtrise d’ouvrage ne recommande pas une solution plutôt qu’une autre. Elle n’écarte pas non plus une solution au motif qu’elle ne serait pas conforme, pas frugale ou pas souveraine. Ces deux gestes, la recommandation et l’éviction, supposent une réponse avant d’avoir instruit la question, et ils transforment l’AMO en prescripteur — c’est-à-dire en quelque chose de très proche d’un revendeur.
Le métier est ailleurs. Il consiste à identifier les cas d’usage avec les directions, à évaluer leur potentiel, à les faire expérimenter vite, puis à les faire progresser vers des solutions qui embarquent le bon niveau de conformité.
Identifier et évaluer
Quels gestes métier valent d’être outillés, pour combien d’agents, avec quelles données en jeu et quel gain attendu. C’est ici que les usages informels sont recensés plutôt que sanctionnés.
Expérimenter vite
Sur l’outil le plus demandé, avec une charte de départ et des référents, dès les premières semaines. Un cas d’usage ne s’évalue pas sur le papier.
Faire progresser vers la conformité
Une fois l’usage qualifié et son gain mesuré, on détermine le niveau d’exigence qu’il appelle réellement, et on fait converger le cas d’usage vers une solution qui le porte.
Cet ordre n’est pas un détail de méthode, c’est tout le raisonnement. Un cas d’usage instruit peut être confronté à des exigences précises ; un catalogue filtré à l’avance ne peut être confronté à rien. La conformité est une destination, pas un filtre d’entrée.
Cela vaut aussi pour la frugalité, qui est notre métier d’origine. Elle n’est pas un motif d’exclusion. C’est une grille de lecture : prioriser les usages à forte valeur plutôt que multiplier les solutions, arbitrer explicitement entre performance, coût, risque et impact, et dimensionner chaque solution au besoin réel. Une IA frugale n’est pas une IA au rabais, c’est une IA pensée pour l’usage réel et explicite sur ce qu’elle coûte.
Le bon niveau de conformité se définit par cas d’usage
Toutes les tâches n’appellent pas les mêmes garanties, et c’est une bonne nouvelle.
Reformuler une note de synthèse à partir d’un document déjà public, préparer un compte rendu de réunion interne, instruire un dossier contenant des données personnelles de citoyens : trois usages, trois niveaux d’exigence. Les traiter avec la même règle conduit soit à surprotéger les usages anodins — et à pousser les agents vers leurs comptes personnels — soit à sous-protéger les usages sensibles.
Décrire l’usage avant de choisir change aussi la conversation avec le délégué à la protection des données. Un DPO à qui l’on soumet une marque commerciale n’a d’autre choix prudent que de refuser. Le même DPO, saisi d’un traitement décrit — quelles données, quelle finalité, quelle base légale, quelle durée, quel hébergement, qui accède aux conversations — peut instruire et arbitrer. C’est la différence entre un blocage de principe et une décision.
La souveraineté et l’impact environnemental suivent la même logique. Ils n’ont pas à filtrer le marché en amont ; ils s’expriment comme des exigences sur un besoin qualifié, et deviennent, quand un marché doit être passé, des critères écrits dans les pièces — les bonnes pratiques du référentiel général pour l’IA frugale de l’AFNOR s’y prêtent directement. Une exigence portée par un cas d’usage documenté pèse bien plus lourd qu’un principe général.
Reste la question du canal d’achat, qui bloque souvent plus que la conformité elle-même : une solution jugée acceptable mais impossible à acheter dans le cadre existant produit exactement le même Shadow AI qu’une solution interdite. Nous vous aidons à identifier le canal d’achat adapté à votre situation ; la page Claude pour les collectivités détaille ce point sur un cas concret.
Sortir du Shadow AI : par quoi commencer
Deux situations, deux premiers gestes.
Vous découvrez l’ampleur des usages
Ne commencez pas par une interdiction, qui rendrait le reste de la démarche impossible : plus personne ne vous dira ce qu’il utilise. Recensez les usages réels en annonçant qu’ils ne seront pas sanctionnés, posez une charte courte et applicable, et ouvrez une expérimentation officielle sur l’outil le plus demandé.
Vous avez déjà une charte et un outil
Vérifiez que l’outil officiel tient la comparaison avec ce que les agents utilisent par ailleurs — c’est la seule mesure qui compte. Là où il ne la tient pas, l’usage informel persistera : instruisez ces cas d’usage en particulier, avec leurs données et leurs exigences propres.
Dans les deux cas, trois éléments font la différence : des référents par direction, à qui les agents peuvent poser leurs questions sans passer par une procédure ; une formation qui traite explicitement des données, parce que c’est là que se prennent les décisions risquées ; et une mesure du temps gagné sur deux ou trois cas d’usage, qui donnera à la direction générale de quoi arbitrer un budget.
Le Shadow AI n’est pas un accident, c’est un signal : il indique que l’IA est déjà entrée dans les pratiques. La bonne question n’est pas comment l’empêcher, mais comment instruire ce qu’il révèle. Une assistance à maîtrise d’ouvrage n’est pas là pour vous vendre la solution qui fera disparaître le problème : elle est là pour transformer des usages subis en cas d’usage instruits, et pour les amener au niveau d’exigence qu’ils méritent.
Questions fréquentes
Faut-il interdire ChatGPT et les assistants grand public aux agents ?
L’interdiction ne supprime pas le besoin, elle le rend invisible : l’usage se déplace vers des comptes personnels, sur des matériels que l’organisation ne voit pas. Il est plus efficace d’encadrer — charte, référents, formation sur les données — et d’ouvrir rapidement une expérimentation officielle sur l’outil le plus demandé, de façon que l’offre interne soutienne la comparaison.
Une AMO IA ne doit-elle pas recommander la solution la plus souveraine ?
Elle doit permettre d’instruire l’exigence de souveraineté, pas la trancher à l’avance. Écarter des solutions avant d’avoir décrit l’usage revient à répondre à une question qui n’a pas été posée, et prive l’organisation d’un point de comparaison. La souveraineté s’exprime ensuite comme une exigence portée par un cas d’usage qualifié, et comme un critère dans les pièces de marché.
Comment savoir quel niveau de conformité exiger pour un usage donné ?
En décrivant le traitement plutôt que l’outil : quelles données, quelle finalité, quelle base légale, quelle durée de conservation, quel hébergement, qui a accès aux conversations. Une note de synthèse à partir de documents publics et l’instruction d’un dossier contenant des données personnelles n’appellent pas les mêmes garanties, et le DPO peut arbitrer sur cette base.
Par quoi commencer quand on découvre l’étendue du Shadow AI ?
Par un recensement annoncé comme non sanctionnant. Les agents décrivent ce qu’ils utilisent et pourquoi, ce qui donne la liste des cas d’usage à instruire en priorité. Une charte courte et une expérimentation encadrée peuvent suivre en quelques semaines ; la cartographie complète peut attendre.
La frugalité ne conduit-elle pas, elle aussi, à écarter des solutions ?
Non, elle sert à arbitrer une fois le besoin connu : dimensionner la solution au besoin réel, éliminer les licences payées et dormantes, remplacer une solution quand une autre fait aussi bien pour moins cher ou moins consommateur. C’est une grille de décision appliquée à un programme, pas un critère d’exclusion appliqué à un catalogue.
Cadrer votre expérimentation
Trente minutes suffisent pour faire le point sur les usages déjà présents chez vous, les cas d’usage à instruire en premier et le niveau d’exigence que chacun appelle réellement.
30 min pour cadrer votre expérimentation IA