Shadow AI : l'IA non autorisée en entreprise, et
comment l'inventorier

Il n'y a rien à installer, et c'est tout le problème. Le shadow AI, ces outils d'intelligence artificielle employés sans que la DSI ni la sécurité en aient connaissance ou les aient validés, ne pose aucun logiciel sur un poste et ne déclenche aucun ticket. Le ressort social, lui, est celui du shadow IT quinze ans plus tôt : quelqu'un a un besoin, l'outil officiel n'existe pas ou frustre, un service en ligne règle l'affaire en trente secondes. Personne ne demande d'autorisation, parce que personne n'a l'impression d'installer quoi que ce soit.

Ce qui a changé, en revanche, c'est l'endroit où la donnée sort. Le shadow IT produit un actif durable : un sous-domaine, un bucket, une instance qui reste allumée et qu'on finit par retrouver en scannant depuis l'extérieur. On en a détaillé la traque dans trouver les actifs exposés que personne ne gère, et cette méthode reste valable telle quelle. Elle ne trouvera simplement pas le shadow AI. Un collaborateur colle un contrat, un extrait de code ou un export client dans une fenêtre de chat, la réponse arrive, l'onglet se ferme. Rien n'a été déployé, rien n'écoute sur un port, et l'information est pourtant chez un tiers, dans une juridiction que personne n'a vérifiée, conservée selon des conditions que personne n'a lues.

Ce que le shadow AI change par rapport au shadow IT

La différence tient en une phrase : la donnée sort à l'usage, pas au stockage. Un bucket mal configuré fuit parce qu'il existe et qu'il est mal fermé ; un prompt fuit parce qu'on s'en sert, une fois, et il ne reste ensuite qu'une ligne dans un journal de proxy, si tant est qu'on ait un proxy et qu'on lise ses journaux.

Deuxième écart, moins commenté et plus sérieux : une partie du shadow AI ne se contente pas de recopier de la donnée, elle obtient un accès délégué. Un assistant qui lit vos courriels pour les résumer, un agent qui range votre stockage en ligne, un connecteur branché sur l'outil de tickets : tous demandent un jeton OAuth, et l'utilisateur clique sur Autoriser sans lire la liste des permissions. Ce n'est plus une copie de donnée à un instant T, c'est une porte ouverte dans la durée. Un assistant qui lit du contenu pour le résumer hérite d'ailleurs d'une classe de faille qui lui est propre, la prompt injection : la page ou le courriel qu'il ingère peut lui donner des ordres, et il les suivra avec les droits que vous lui avez accordés.

Les formes que ça prend

Le terme sert de fourre-tout dans les brochures. En pratique, on rencontre cinq objets bien distincts, qui ne se détectent pas au même endroit et ne coûtent pas la même chose :

• Le prompt : le cas le plus fréquent et le plus banal. Un contrat commercial collé pour en obtenir un résumé, un extrait de base de données collé pour qu'on l'explique, un bout de code propriétaire collé pour le déboguer. Le préjudice ne se voit jamais tout de suite, ce qui explique qu'il ne remonte jamais.
• L'extension de navigateur : un assistant installé en deux clics réclame en général la permission <all_urls>, présentée à l'utilisateur comme "lire et modifier toutes vos données sur tous les sites". Un résumeur de page qui a ce droit lit aussi le webmail, le CRM et l'outil de tickets. Et une extension se met à jour toute seule : celle que vous avez regardée en janvier n'est pas celle qui tourne en juin, ce qui la range dans la même famille de problèmes qu'une attaque sur la chaîne d'approvisionnement logicielle.
• Le connecteur et l'agent : la catégorie qui surprend le plus au premier inventaire. Chaque bouton "Se connecter avec Google" ou "Se connecter avec Microsoft" laisse derrière lui une application enregistrée dans l'annuaire et un octroi de permissions. Le jeton de rafraîchissement associé survit au changement de mot de passe de l'utilisateur, et souvent à son départ si le compte n'a pas été désactivé proprement.
• La clé d'API de modèle de langage : préfixée sk-, sk-ant-, AIza ou hf_ selon le fournisseur, posée dans un script pour un essai, poussée dans un dépôt, oubliée. Elle ne déverrouille pas vos données, elle déverrouille votre facture. Le sujet rejoint celui de la fuite de secrets dans le code, à ceci près que la revente d'accès à des modèles payants est devenue une activité en soi : les équipes de recherche de Sysdig ont documenté ce détournement sous le nom de LLMjacking dès mai 2024.
• Le code généré : produit vite, relu peu, poussé en production. J'ai démonté une application entière construite comme ça dans vibe coding et sécurité : front impeccable, autorisations inexistantes.

Inventorier le shadow AI sans interroger personne

Le questionnaire interne est le pire outil pour ce travail. Il mesure ce que les gens acceptent de déclarer, c'est-à-dire ce qu'ils pensent avoir le droit de faire. Quatre sources techniques donnent une image nettement plus fidèle, et aucune ne demande la coopération de l'utilisateur.

Les journaux du proxy sortant et du DNS

C'est la source la plus rapide à exploiter, parce qu'elle existe déjà. Un agrégat par domaine sur trente jours suffit à dresser la carte des fournisseurs contactés :

# accès sortants agrégés par domaine (journal de proxy au format courant)
cut -d' ' -f7 /var/log/squid/access.log \
  | sed 's|^[a-z]*://||; s|[/:].*||' \
  | grep -Ei 'openai|chatgpt|anthropic|claude\.ai|generativelanguage|gemini|mistral|perplexity|deepseek|huggingface|copilot\.microsoft' \
  | sort | uniq -c | sort -rn

Deux signaux différents sortent de cette commande, et il faut les séparer. Un flux régulier vers api.openai.com depuis une adresse IP de serveur, c'est une intégration que quelqu'un a mise en production sans le dire. Des connexions irrégulières vers une interface de chat depuis des postes de travail, c'est un usage humain. Le premier cas relève de la revue d'architecture, le second de la politique interne ; les traiter avec la même réponse garantit de rater les deux.

Les consentements OAuth accordés sur votre tenant

Sur Microsoft Entra ID comme sur Google Workspace, une application tierce qui a obtenu un accès laisse une trace durable et interrogeable. Côté Microsoft, chaque autorisation crée un service principal et un octroi de permissions :

# applications tierces ayant obtenu un consentement, et sur quelles permissions
Connect-MgGraph -Scopes "Directory.Read.All"

Get-MgOauth2PermissionGrant -All |
  Select-Object ClientId, ConsentType, Scope |
  Sort-Object ConsentType

# ConsentType = AllPrincipals -> un administrateur a validé pour toute l'organisation
# ConsentType = Principal    -> un utilisateur a validé pour lui-meme, en libre-service

La colonne Scope est celle qui compte. Une permission de lecture de profil est anodine ; un Mail.Read ou un Files.Read.All accordé à une application dont personne dans l'organisation ne connaît l'éditeur mérite une conversation le jour même. Côté Google, la même information vit dans la console d'administration, sous Sécurité puis Contrôles des API, avec le détail des applications tierces ayant accès et un journal dédié aux jetons OAuth.

Les extensions installées dans les navigateurs

L'inventaire des extensions se récupère par la gestion de flotte du navigateur, ou à défaut poste par poste. Le tri se fait sur la permission demandée plutôt que sur le nom, qui ne dit rien : accès à toutes les URL, injection de scripts, lecture des cookies. Une extension de traduction et un assistant d'écriture peuvent réclamer exactement les mêmes droits que ce qu'on appellerait, sur un autre poste, un enregistreur de frappe. La différence est une question d'intention de l'éditeur, et l'intention ne se contrôle pas à distance.

Ce qui a déjà fuité côté externe

Dernière source, la seule qui se regarde depuis l'extérieur du périmètre : les dépôts publics, les archives de code, les fichiers de configuration oubliés sur un hébergement. Les clés de fournisseurs d'IA ont l'avantage d'être fortement préfixées, donc faciles à repérer par motif :

# historique complet d'un depot, y compris les commits ou la cle a ete "retiree"
gitleaks detect --source . --log-opts="--all" --redact

# le motif compte plus que l'outil : la plupart des cles portent un prefixe stable
grep -rInE 'sk-[A-Za-z0-9]{20,}|sk-ant-[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35}|hf_[A-Za-z0-9]{30,}' .

Une clé retirée du dernier commit reste dans l'historique, et un dépôt passé de public à privé a pu être cloné entre-temps. La bonne question après une découverte n'est donc pas "est-elle révoquée ?" mais "qu'a-t-elle consommé entre le commit et la révocation ?". Ce balayage externe est exactement le travail d'une plateforme d'External Attack Surface Management, dont la détection de fuites et de secrets tourne en continu plutôt qu'une fois par audit. Pour la partie cartographie des actifs, la méthode complète est décrite dans la découverte d'actifs exposés.

L'AI Act, au ras du texte

Le règlement européen sur l'intelligence artificielle, formellement le règlement (UE) 2024/1689, est entré en vigueur le 1er août 2024 et s'applique par paliers. Depuis le 2 février 2025 s'appliquent les pratiques interdites de l'article 5 et l'obligation de littératie en IA de l'article 4, qui vise les fournisseurs comme les déployeurs. Depuis le 2 août 2025 s'appliquent les règles relatives aux modèles d'IA à usage général, ainsi que le volet gouvernance et sanctions. Le gros du texte devient applicable le 2 août 2026, et les systèmes à haut risque relevant de l'article 6, paragraphe 1, suivent le 2 août 2027.

Aucun de ces articles n'énonce, pour toute organisation, une obligation générale de tenir un registre des IA employées. Ce que fait le règlement, c'est conditionner les obligations à deux paramètres qui se déterminent système par système : le rôle que vous tenez, celui de fournisseur ou celui de déployeur, et la classification de risque du système en question. Le recensement est donc le préalable sans lequel aucune obligation n'est démontrable. Une entité qui ignore quels outils tournent réellement chez elle ne peut ni établir si elle déploie un système à haut risque, ni prouver qu'elle a formé les bonnes personnes au titre de l'article 4.

Le shadow AI a en plus une propriété désagréable au regard de ce texte : il fabrique des déployeurs de fait. Quand un collaborateur branche seul un outil d'IA sur un processus métier, c'est l'organisation, personne morale, qui endosse le rôle réglementaire, sans l'avoir choisi et sans le savoir.

Interdire fabrique du contournement

Un blocage sec au proxy a un effet parfaitement mesurable : le trafic vers les domaines concernés tombe à zéro dans vos journaux. Ce qui n'apparaît nulle part, c'est le téléphone personnel posé à côté du clavier, le compte perso ouvert sur l'ordinateur perso le soir, ou le passage par une messagerie web pour sortir le document avant de le traiter ailleurs. L'interdiction ne supprime pas le besoin, elle supprime votre visibilité sur la façon dont il est satisfait.

Il y a pire que l'angle mort. Une personne qui a contourné une règle pour faire son travail ne signalera pas l'incident le jour où elle colle la mauvaise pièce jointe, parce que le signalement commencerait par l'aveu de la transgression. L'interdiction généralisée se paie donc deux fois : en donnée partie ailleurs, et en remontées qui auraient permis de réagir.

La dernière couche est celle qu'on abandonne en premier, et c'est une erreur : une voie autorisée sans surveillance devient une autorisation implicite de tout faire. Côté code, la même logique s'applique à ce que les assistants produisent : la revue automatisée attrape les défauts connus, l'humain tranche le reste, et la frontière entre les deux est décrite dans le comparatif SAST, DAST et IAST à l'heure de l'IA.

À retenir

• Le shadow AI est la suite logique du shadow IT, avec un déplacement du point de fuite : la donnée sort à l'usage, dans un flux, et non au stockage, dans un actif qu'on peut scanner.
• Cinq objets à distinguer parce qu'ils ne se détectent pas au même endroit : le prompt, l'extension de navigateur, le connecteur détenteur d'un jeton OAuth, la clé d'API de modèle laissée dans un dépôt, et le code généré parti en production sans revue.
• L'inventaire se fait sur quatre sources techniques, jamais sur un questionnaire : journaux de proxy et DNS, consentements OAuth du tenant, extensions triées par permission, et recherche de clés exposées côté externe.
• L'AI Act n'impose pas un registre universel, mais fait dépendre chaque obligation du rôle tenu et de la classification du système. Sans recensement, rien n'est démontrable, et le RGPD s'applique déjà sans attendre le calendrier de 2026.
• Le blocage généralisé déplace l'usage hors de vue et tue les remontées d'incident. Une voie autorisée, rapide et journalisée, surveillée en continu, obtient ce que l'interdiction promet sans jamais le tenir.

Si vous voulez commencer par le bout le plus concret, prenez la face externe : les clés qui traînent dans un dépôt public et les actifs montés pour un essai d'IA se voient de l'extérieur, et ils se voient par n'importe qui. C'est ce que surveille en continu la plateforme EASM d'own2pwn. Pour le reste, l'inventaire interne et les arbitrages qui vont avec, le plus simple est d'en parler de vive voix via la page contact.

Questions fréquentes sur le shadow AI