Shadow AI en entreprise : détecter et cadrer les usages IA non autorisés (checklist RSSI Lyon)

Shadow AI : le vrai problème, c’est pas l’IA. C’est l’ombre.

Vous pensez déployer l’IA « proprement ». Un copilote validé. Deux POC cadrés. Un budget API. Et pendant ce temps, des équipes utilisent déjà des IA externes sans vous prévenir. Avec des comptes perso. Depuis un navigateur. En copiant-collant des infos internes. C’est ça, le Shadow AI.

Le sujet n’est pas anecdotique. Microsoft et LinkedIn mesurent que 75% des knowledge workers utilisent l’IA au travail (Work Trend Index, enquête menée du 15 février au 28 mars 2024, n=31 000). Netskope estime que 72% des usages d’applications de GenAI en entreprise relèvent du shadow IT (Netskope Threat Labs, 2025). Et Cisco note que 60% des équipes IT ne savent pas avec quels outils GenAI les employés interagissent, tandis que 22% des organisations laisseraient un accès sans restriction à des outils publics (Cisco Cybersecurity Readiness Index 2025).

À Lyon, c’est pareil qu’ailleurs. Beaucoup de boîtes sont outillées en Microsoft 365, Google Workspace, des stacks SaaS, parfois un SOC externalisé. Et les métiers vont plus vite que les cycles DSI. Donc l’ombre se crée. Votre job, DSI/RSSI, c’est de passer de « on suppose » à « on sait », puis à « on cadre », sans tuer l’usage.

Définition opérationnelle : ce que vous devez mesurer

Oubliez les définitions marketing. Shadow AI = tout usage d’IA (SaaS, extension navigateur, appli mobile, API, agent, modèle local) hors inventaire, hors contrat, hors validation sécurité/juridique, et souvent hors comptes managés (comptes personnels, OAuth non contrôlé). Ce dernier point est clé, parce que c’est un marqueur détectable dans vos logs proxy/SSE/CASB.

Pourquoi ça explose : 4 risques, dans l’ordre

Les risques ne sont pas théoriques. Cisco indique que 48% des répondants admettent avoir saisi des informations internes non publiques dans des outils GenAI (Cisco Data Privacy Benchmark Study 2024).

• Fuite de données : copier-coller, upload de fichiers, capture d’écran, code source, secrets, données RH, données clients.
• Non-conformité : RGPD selon les cas, secret des affaires, clauses contractuelles clients, conservation côté fournisseur, transferts hors UE.
• Risque fournisseur : conditions d’usage, sous-traitants, localisation, logs, réutilisation potentielle des données selon les offres.
• Sécurité applicative : prompt injection, exfiltration indirecte via connecteurs, actions agentiques non maîtrisées. L’ENISA documente ces familles de menaces dans ses analyses récentes.

Point important : il n’y a pas de contrôle magique. AWS le rappelle sur un sujet précis mais révélateur : la fuite de « system prompt » n’a pas de remède parfait, donc on doit raisonner en contrôles de sécurité classiques (journalisation, segmentation, moindre privilège, DLP, etc.).

Méthode en 3 volets pour cadrer le Shadow AI (sans théâtre)

Volet 1 : détection (réseau, SaaS, postes). Objectif : inventaire réel.

Votre première victoire, c’est la visibilité. Pas la répression. Tant que vous n’avez pas une liste d’usages, vous pilotez au ressenti.

1) Détection réseau et SaaS (le plus rapide)

• Classifier les apps GenAI dans votre catalogue (SSE/CASB/proxy) et sortir un top domaines et apps (chatbots, générateurs d’images, transcription, agents).
• Distinguer comptes managés vs personnels (SSO, OAuth entreprise, ou au contraire login Gmail/outlook perso). C’est un signal fort de Shadow AI.
• Repérer les uploads (POST, pièces jointes) vers des domaines GenAI. Pas juste les visites.
• Mettre une DLP ciblée sur quelques patterns simples et efficaces : clés API, secrets, IBAN, pièces d’identité, exports CRM, termes RH, code interne.

2) Détection poste (indispensable, sinon vous ratez la moitié)

• Inventaire des extensions navigateur : assistants IA, résumeurs, « copilots » non officiels, outils de réunion.
• Inventaire des apps desktop : clients IA, outils de transcription, plug-ins de visio, outils PDF « IA ».
• IDE et dev tools : extensions de code, agents, accès à des API via tokens personnels.
• Signal modèles locaux : runtimes et UIs locales selon votre contexte (surtout dans les équipes techniques). Ça réduit le risque d’exfiltration vers le cloud, mais ça crée un autre sujet : données en local, modèles non patchés, absence de logs, et parfois contournement des contrôles réseau.

3) Détection “nouvelle vague” : agents, MCP, automatisations

Les rapports récents élargissent le périmètre au-delà des chatbots : agents IA, serveurs MCP, infrastructures locales. C’est logique : dès qu’un outil peut agir (lire un drive, envoyer un mail, appeler une API), le Shadow AI devient un Shadow Ops.

Si vous débutez, cadrez d’abord les usages GenAI SaaS. Mais gardez un œil sur ce qui s’intègre à vos outils (mail, CRM, drive, ticketing). Pour le contexte agents et MCP, vous pouvez aussi lire : https://lyon-ia.com/blog/mcp-protocole-explique

Volet 2 : politique d’usage + alternatives internes. Objectif : couper l’envie de contourner.

Si votre réponse c’est « interdit », vous perdez. Les métiers iront juste ailleurs, plus discrètement. Une politique d’usage IA marche seulement si elle propose une voie praticable.

1) Écrire une politique courte, avec 3 niveaux de données

• Public : autorisé dans des IA externes, avec prudence.
• Interne : autorisé seulement dans des outils approuvés, comptes managés, logs activés.
• Sensible/réglementé : interdit dans des IA externes publiques. Usage possible uniquement via solution entreprise cadrée (contrat, DPA, paramétrage, DLP, chiffrement, accès).

Faites simple. Si la règle tient sur un écran, elle sera lue. Besoin d’un support charte : https://lyon-ia.com/blog/charte-usage-ia-entreprise

2) Proposer des alternatives internes qui couvrent 80% des cas

• Un assistant texte « corporate » (compte entreprise, conditions claires, désactivation de l’entraînement si disponible, rétention maîtrisée).
• Un outil de transcription/résumé validé pour les réunions, plutôt que 10 extensions différentes.
• Une solution pour analyser des documents internes (RAG) avec contrôle d’accès et logs, plutôt que des uploads sauvages. Voir : https://lyon-ia.com/blog/rag-ia-documents-entreprise

Le message à marteler en interne : « On ne bloque pas l’IA. On bloque l’IA non maîtrisée. »

3) S’appuyer sur des références françaises

• ANSSI : recommandations de sécurité pour systèmes d’IA générative (29 avril 2024). Base solide pour architecture, journalisation, cloisonnement, gestion des accès.
• CNIL : ressources pratiques sur l’usage de l’IA générative en organisation, et rappel des obligations RGPD selon les cas.

Vous n’avez pas besoin d’être parfait dès J1. Vous avez besoin d’être défendable, documenté, et d’améliorer par itérations.

Volet 3 : processus de demande et d’exception. Objectif : canaliser, pas subir.

Le Shadow AI naît quand le chemin « officiel » est trop lent. Donc créez un chemin rapide.

1) Un formulaire unique “Demande d’outil IA”

• Cas d’usage, équipe, volumétrie.
• Type de données manipulées (public, interne, sensible).
• Mode d’accès (web, extension, API, agent).
• Connecteurs demandés (Drive, SharePoint, CRM, messagerie).
• Contraintes (hébergement, rétention, audit, SSO).

2) Un SLA clair

• Accusé réception sous 48 h.
• Décision « go/pas go/go avec garde-fous » sous 10 jours ouvrés.
• Voie express pour un test encadré de 2 semaines, avec données non sensibles.

3) Une vraie gestion des exceptions

• Exception = durée limitée + périmètre + données autorisées + responsable nommé.
• Revues mensuelles des exceptions (on coupe ce qui ne sert plus).
• Traçabilité minimale : qui, quoi, quand, avec quelles données.

Si vous devez documenter les usages, l’AI Act pousse aussi vers des registres et preuves. Pour un support concret : https://lyon-ia.com/blog/ai-act-documenter-vos-usages-dia-en-entreprise-registre-pret-a-copier-exemple-pme-lyon

Checklist d’implémentation réaliste pour une DSI/RSSI à Lyon (priorités, métriques, com)

Objectif : obtenir des résultats en 30 jours, puis industrialiser en 90 jours. Pas un programme sur 18 mois.

Semaine 1 : mettre la base (visibilité et règles minimales)

• Nommer un pilote côté DSI et un côté sécurité (même si c’est la même personne au début).
• Définir “IA approuvée” vs “IA non approuvée” (liste courte, même provisoire).
• Activer la détection dans proxy/SSE/CASB : catégorie GenAI, top domaines, top utilisateurs, volumes.
• Lancer un inventaire poste sur un échantillon : extensions navigateur, apps IA, plugins IDE.
• Écrire une règle simple : pas de données sensibles dans des IA publiques. Point.

Semaine 2 : mesurer, segmenter, comprendre les vrais usages

• Sortir un rapport Shadow AI interne : top 20 outils, % comptes personnels, volumes d’upload.
• Classifier par risque : données manipulées, présence de connecteurs, usage API.
• Identifier 3 parcours métiers à forte valeur (ex : support, commerce, RH) et documenter pourquoi ils contournent.
• Mettre une DLP “lite” : détection de secrets et blocage sur upload vers domaines GenAI non approuvés.

Semaine 3-4 : cadrer sans bloquer (politique + alternatives + canal)

• Publier une politique d’usage IA en 1 page, avec 3 niveaux de données et 5 exemples concrets.
• Ouvrir une alternative approuvée pour les besoins génériques (assistant texte) avec comptes managés.
• Créer le processus de demande + SLA + voie express “test 2 semaines”.
• Former les managers en 30 minutes : ce qui est ok, ce qui ne l’est pas, et quoi faire si une équipe a besoin.

Jour 45-90 : industrialiser (gouvernance IA entreprise)

• Mettre à jour l’inventaire des outils IA approuvés avec propriétaire, contrat, DPA, rétention, localisation, logs.
• Brancher IAM/SSO partout où c’est possible. Réduire les comptes perso.
• Durcir par étapes : blocage progressif des apps à haut risque, pas un big bang.
• Audit des connecteurs et des droits : les agents et plugins ont tendance à demander trop d’accès.
• Plan de réponse incident spécifique fuite via IA (preuves, logs, communication). Utile en local, parce que le jour où ça arrive, tout le monde se connaît. Voir : https://lyon-ia.com/blog/fuite-de-donnees-kit-de-reponse-en-24-h-a-lyon-rgpd-preuves-com-m365

Métriques à suivre (sinon vous pilotez à l’opinion)

• % d’usages GenAI via comptes personnels (objectif : baisse continue).
• Nombre d’apps GenAI uniques détectées par mois (au début ça monte, puis ça se stabilise).
• Volume d’uploads vers GenAI non approuvées (objectif : baisse forte).
• Nombre de demandes “outil IA” via le canal officiel (objectif : ça monte, signe que le chemin marche).
• Délai moyen de décision (objectif : tenir le SLA, sinon retour du Shadow AI).
• Incidents évités : événements DLP, secrets détectés, blocages justifiés.

Communication interne : 6 messages qui marchent (et évitent la guerre DSI vs métiers)

• On n’interdit pas l’IA. On encadre les données et les accès.
• Ce qui est interdit : données clients, RH, financières, code, secrets dans des IA publiques.
• Ce qui est autorisé : usages sur données publiques, reformulation, idéation, si outil approuvé.
• Ce qui est attendu : déclarer ses outils, passer par le formulaire si besoin.
• Ce qu’on fournit : une alternative interne + une voie express test 2 semaines.
• Ce qu’on mesure : pas les individus pour les punir, mais les flux pour réduire le risque.

Cas typiques vus en entreprise lyonnaise (et comment les cadrer vite)

1) Marketing qui upload des briefs et des présentations

• Risque : fuite d’infos produit, de données partenaires.
• Réponse : outil approuvé + formation courte + exemples « données ok / pas ok ».

2) RH qui résume des CV, lettres, évaluations

• Risque : données personnelles sensibles, RGPD.
• Réponse : interdire IA publique, proposer workflow interne, anonymisation si nécessaire. Voir : https://lyon-ia.com/blog/anonymiser-donnees-avant-ia

3) Dev qui colle du code et des secrets dans un chatbot

• Risque : exfiltration code, clés, vulnérabilités.
• Réponse : DLP secrets + assistant code approuvé + règles repo (pas de secrets), et revue des extensions IDE.

4) Équipes qui branchent des agents sur Drive/SharePoint/CRM

• Risque : exfiltration indirecte, actions non voulues, effacement de traces si agent mal conçu.
• Réponse : moindre privilège, logs, validation connecteurs, et garde-fous agents. Référence utile : https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions

Plan d’action immédiat (si vous êtes RSSI/DSI à Lyon)

Si vous ne faites qu’une chose cette semaine : mesurez. Sortez la liste des outils GenAI réellement utilisés, et le ratio comptes managés vs comptes perso. C’est votre point zéro.

Puis faites simple :

• Bloquez les uploads vers 5 à 10 outils à haut risque, mais ouvrez une alternative.
• Publiez une politique d’usage courte, orientée données.
• Créez un canal de demande avec un SLA tenable.

Vous voulez creuser le cadrage côté Shadow AI et questions à poser en local : https://lyon-ia.com/blog/security-ai-a-lyon-ats26-0311-12-questions-pour-cadrer-le-shadow-ai

Sources

• Microsoft Work Trend Index 2024 (Microsoft et LinkedIn), « AI at work is here. Now comes the hard part », enquête du 15 février au 28 mars 2024, n=31 000 : https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part?trk=public_post_comment-text&utm_source=openai
• Netskope Threat Labs, Cloud and Threat Report: Generative AI 2025 : https://threatlabs.netskope.com/reports/2025/cloud-and-threat-report-generative-ai-2025/?utm_source=openai
• Cisco, Cybersecurity Readiness Index 2025 (PDF) : https://investor.cisco.com/files/doc_news/Cisco-Study-Reveals-Alarming-Deficiencies-in-Security-Readiness-2025.pdf?utm_source=openai
• Cisco, Data Privacy Benchmark Study 2024 (communiqué) : https://investor.cisco.com/news/news-details/2024/More-than-1-in-4-Organizations-Banned-Use-of-GenAI-Over-Privacy-and-Data-Security-Risks---New-Cisco-Study/default.aspx
• ANSSI, Recommandations de sécurité pour un système d’IA générative (29 avril 2024) : https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative
• CNIL, « Utiliser l’IA générative dans les TPE et PME » : https://www.cnil.fr/fr/utiliser-lia-generative-dans-les-tpe-et-pme
• AWS Security Blog (2026), « Designing for the inevitable system prompt leakage… » : https://aws.amazon.com/blogs/security/designing-for-the-inevitable-system-prompt-leakage-and-mitigations-in-generative-ai-applications/
• ENISA Threat Landscape 2024 (PDF) : https://www.enisa.europa.eu/sites/default/files/2024-11/ENISA%20Threat%20Landscape%202024_0.pdf
• Netskope AI Report 2026 : https://threatlabs.netskope.com/reports/2026/netskope-ai-report-2026