Le shadow AI, ou IA fantôme, c'est l'usage d'outils d'intelligence artificielle par des collaborateurs sans que la DSI l'ait validé ni même repéré. Un commercial qui fait résumer un contrat par un assistant grand public, un développeur qui colle un extrait de code pour le déboguer : l'intention est bonne, mais ce qui est saisi part chez un fournisseur que l'entreprise n'a pas évalué. Cet article définit le phénomène, explique pourquoi il se développe, détaille les risques concrets et propose une démarche pour la DSI.

Shadow AI : définition

Le shadow AI reprend le principe du shadow IT (tout logiciel ou service utilisé hors du cadre fixé par la DSI) en l'appliquant aux outils d'IA : assistants de conversation, copilotes intégrés à un navigateur, extensions, outils de traduction ou de transcription, agents branchés sur la messagerie ou sur des documents. On parle aussi d'IA fantôme ou d'IA non autorisée.

La différence avec un tableur installé sans autorisation tient à la nature de l'outil. Un assistant d'IA générative reçoit du texte libre, souvent des morceaux entiers de dossiers, et le transmet à un modèle exploité par un tiers. Il n'y a pas de fichier à retrouver sur un serveur de l'entreprise : l'information a simplement quitté le périmètre, dans une fenêtre de navigateur.

Pourquoi les collaborateurs y recourent

Le shadow AI n'est presque jamais de la malveillance. Les employés cherchent un gain de productivité réel et immédiat, et l'adoption se fait par le bouche-à-oreille : résumer un rapport, reformuler un courriel, traduire un contrat, structurer des notes de réunion. Quatre causes reviennent.

Les risques concrets du shadow AI

Fuite de données

Le premier risque est la fuite de données : noms de clients, coordonnées, numéros de dossier, pièces comptables, code source, hypothèses stratégiques. Une fois le texte envoyé, l'entreprise ne maîtrise plus ni la durée de conservation, ni l'usage que le fournisseur en fait, ni le pays où il est traité, et rien n'est tracé de son côté. L'épisode de 2023 chez Samsung, où des ingénieurs avaient transmis du code interne à un assistant public, est resté le cas d'école. Pour les données personnelles, le DPO doit en outre pouvoir démontrer la base légale et les garanties du traitement, ce que personne ne peut faire pour un usage qu'il ne connaît pas. Sur ce point, la CNIL publie ses recommandations sur l'IA, et le RGPD (article 9) encadre plus strictement les catégories particulières de données, comme la santé.

Secret professionnel et secret des affaires

Pour les professions réglementées, le sujet est pénal. L'article 226-13 du code pénal sanctionne la révélation d'une information couverte par le secret professionnel. Les textes propres à chaque profession s'y ajoutent : l'article 66-5 de la loi du 31 décembre 1971 pour l'avocat, qui couvre aussi les notes d'entretien et les pièces du dossier, et l'article L1110-4 du code de la santé publique pour le secret médical. Dans une entreprise ordinaire, le secret des affaires (article L151-1 du code de commerce) suppose notamment que l'entreprise ait pris des mesures raisonnables pour garder l'information secrète : laisser circuler des documents confidentiels vers des outils non maîtrisés fragilise cette protection. Nous détaillons le cas des métiers concernés dans IA et secret professionnel : avocats, notaires, médecins face aux LLM.

Injection de prompt via les documents

Le risque n'est pas qu'à l'envoi. Un collaborateur qui demande à un assistant de résumer un PDF, un email ou une page web reçu de l'extérieur expose le modèle à une injection de prompt indirecte : une instruction cachée dans le document (texte blanc sur fond blanc, métadonnées, commentaire) peut détourner la réponse ou pousser le modèle à renvoyer des données de la conversation. L'OWASP place l'injection de prompt en tête de son classement des risques des applications LLM. Avec un outil non validé, personne n'analyse le document avant le modèle, et personne ne le saura après. Le sujet est traité en détail dans l'injection de prompt dans les documents professionnels.

Agents et extensions installés sans revue

Le shadow AI ne se limite plus à une fenêtre de conversation. Les équipes techniques branchent des serveurs MCP (le Model Context Protocol), des skills ou des extensions à leurs assistants de code : ces composants s'exécutent avec les droits de l'utilisateur et lisent des fichiers, des secrets, parfois des bases. Une commande téléchargée puis exécutée, un secret en clair dans une configuration ou un paquet sans version fixée suffisent à créer une porte d'entrée. Le sujet est abordé dans la sécurité du MCP.

Aucune trace

Enfin, l'absence de journal. En cas d'incident, de litige client ou de demande d'une personne concernée, la DSI ne peut ni établir qui a envoyé quoi, ni à quel modèle, ni quand. Ce défaut de traçabilité aggrave tous les autres risques.

Pourquoi interdire ne suffit pas

La réaction la plus courante est de bloquer les sites d'IA. Elle est légitime pour exclure un service précis, par exemple un fournisseur que l'entreprise juge inacceptable. Mais comme réponse unique, elle échoue pour trois raisons.

Le filtrage web garde son rôle, mais il doit s'accompagner d'une alternative qui répond au même besoin. C'est la condition pour que l'usage revienne dans le périmètre.

Démarche de la DSI en cinq étapes

1. Faire l'inventaire des usages réels

On ne gouverne pas ce que l'on ne voit pas. Recoupez les journaux du proxy ou du pare-feu (domaines d'IA les plus consultés), les extensions installées dans les navigateurs, les abonnements et notes de frais, puis complétez par une enquête courte et non punitive auprès des équipes : quels outils, pour quelles tâches, avec quels types de contenus. L'objectif est une cartographie des usages, pas une liste de coupables.

2. Classer les données et écrire la règle d'usage

Une règle d'usage tient sur une page. Elle distingue ce qui peut être saisi librement (texte public, brouillon sans donnée personnelle), ce qui ne peut l'être qu'avec l'outil validé (dossiers clients, pièces RH, contrats) et ce qui ne doit jamais sortir (secrets de fabrication, données de santé hors cadre prévu). Elle nomme l'outil autorisé et la personne à contacter. Le DPO et le service juridique la relisent, notamment pour les métiers soumis au secret.

3. Mettre à disposition un outil validé, au poste de travail

Le levier le plus efficace est de rendre la voie sûre aussi simple que la voie sauvage. L'outil validé doit s'ouvrir là où les collaborateurs travaillent déjà, couvrir les cas d'usage courants et protéger les données sans leur demander d'y penser. Dans le cas contraire, la règle n'est pas appliquée.

4. Garder un journal des échanges

Qui a utilisé quel modèle, quand, et si une menace a été repérée : ce journal permet de répondre à un audit, à un litige ou à une demande d'une personne concernée. Sa durée de conservation doit être décidée avec le DPO, car le journal contient lui aussi des informations à protéger.

5. Former et revoir régulièrement

Une demi-heure de démonstration sur des cas réels (un contrat, un fichier client, un PDF piégé) vaut mieux qu'une charte envoyée par courriel. Revoyez l'inventaire chaque trimestre : les usages évoluent vite, et la règle doit suivre.

Quel outillage pour encadrer l'usage

Trois familles d'outils se complètent. Le filtrage web et la prévention des fuites de données (DLP), déjà en place dans beaucoup d'entreprises, permettent de bloquer des services ou de surveiller des transferts. Ils ne protègent pas le contenu d'une conversation autorisée. Les offres d'IA d'éditeurs intégrées à l'environnement de travail couvrent une partie des besoins, avec les garanties contractuelles de l'éditeur. Enfin, une passerelle d'IA se place entre le collaborateur et le modèle pour protéger ce qui est envoyé, et garder la trace de chaque échange. Le fonctionnement est détaillé dans notre guide de la passerelle LLM.

Côté routtx, le principe est le suivant. Les données repérées (noms, emails, téléphones, adresses, IBAN, numéros de sécurité sociale, SIRET, références cadastrales, numéros de minute pour les notaires, et des motifs propres à votre compte) sont remplacées par des jetons du type [PERSON_1] ou [EMAIL_1] avant l'envoi au modèle, puis les vraies valeurs sont remises dans la réponse. La table de correspondance n'est jamais transmise au fournisseur du modèle. Il s'agit d'une pseudonymisation : l'entreprise conserve la correspondance. Ce qui n'est pas repéré part tel quel, et un détail du récit peut encore identifier quelqu'un : la relecture humaine reste utile. Les protections de sécurité couvrent aussi les documents (PDF, Word, emails) et les pages web, analysés à la recherche d'instructions cachées avant d'atteindre le modèle, selon 396 motifs d'attaque répartis en 23 familles, sans garantie à 100 %.

Pour le poste de travail, l'extension de navigateur routtx Shield s'ouvre sur claude.ai, ChatGPT, Gemini, Mistral et copilot.microsoft.com (pas dans Microsoft 365 Copilot sous Word, Outlook ou Teams). Elle ne bloque pas les autres sites, ce qui relève du filtrage web : elle enregistre un rapport quand un document est anonymisé, elle ne conserve pas les conversations, et le responsable d'un compte Business ou Enterprise voit les rapports de son équipe. Les équipes techniques disposent d'une API compatible OpenAI et Anthropic, d'un connecteur Claude et d'extensions pour Claude Code. Le suivi des usages de l'IA repose sur le journal : chaque échange consigne qui, quel modèle, quand et la menace éventuellement repérée.

Questions fréquentes

Qu'est-ce que le shadow AI ?

Le shadow AI, ou IA fantôme, désigne l'usage d'outils d'intelligence artificielle par des collaborateurs sans que la DSI, le DPO ou le service juridique l'aient validé ni même connu. L'exemple type : un salarié qui colle un contrat dans la version grand public d'un assistant d'IA générative pour le résumer.

Quelle différence entre shadow IT et shadow AI ?

Le shadow IT recouvre tout logiciel ou service utilisé sans l'accord de la DSI. Le shadow AI en est une forme particulière : le contenu saisi part chez un fournisseur de modèle, il est rédigé en langage libre (donc difficile à filtrer par mots-clés) et la réponse obtenue peut elle-même être manipulée, par exemple par une instruction cachée dans un document.

Faut-il interdire l'IA générative en entreprise ?

Une interdiction seule déplace l'usage vers les téléphones et les comptes personnels, où l'entreprise ne voit plus rien. Mieux vaut fixer une règle d'usage claire, mettre à disposition un outil validé qui protège les données avant l'envoi et garder un journal des échanges, tout en bloquant au niveau du réseau les services que l'entreprise a décidé d'exclure.

Comment détecter le shadow AI dans une entreprise ?

On recoupe plusieurs sources : les journaux du proxy ou du pare-feu pour repérer les domaines d'IA les plus visités, les extensions de navigateur installées, les notes de frais et abonnements, et une enquête simple auprès des équipes. Le but est d'établir un inventaire des usages réels, pas de sanctionner.

routtx empêche-t-il l'accès aux sites d'IA non autorisés ?

Non. Bloquer l'accès à des sites relève du filtrage web, que la DSI garde en place. routtx fournit l'outil validé : il masque les données repérées avant l'envoi au modèle, analyse les documents à la recherche d'instructions cachées et consigne chaque échange dans un journal.

Voyez l'outil validé en situation

En une démonstration, nous passons un document réel dans routtx : données masquées avant l'envoi au modèle, instructions cachées repérées, échange consigné au journal.

Réserver une démo Suivre les usages de l'IA