Security & AI à Lyon (ATS26, 03/11) : 12 questions pour cadrer le Shadow AI

Le Shadow AI ne “commence” pas dans l’IT. Il finit chez toi quand ça pète.

Dans beaucoup de boîtes lyonnaises, l’IA est déjà partout. Pas via un programme DSI nickel. Via des comptes perso, des extensions navigateur, des fonctions IA planquées dans des SaaS, des API branchées vite fait dans un script, et maintenant des agents et des intégrations qui enchaînent les appels tout seuls.

C’est ça, le Shadow AI : des usages d’outils IA non autorisés ou non encadrés, qui traitent parfois des données de l’entreprise, sans validation IT, sécurité, achats, ni gouvernance. IBM pose une définition opérationnelle claire, exploitable pour un inventaire et des contrôles. Source : IBM, “Shadow AI”.

Le souci n’est pas “les gens utilisent ChatGPT”. Le souci, c’est le triptyque données, accès, preuves. Sans inventaire, règles et traces, tu ne peux pas prouver qui a envoyé quoi, vers quel fournisseur, avec quelles garanties. Et tu réagis trop lentement le jour où une donnée sort.

Pourquoi ATS26 Lyon tombe au bon moment

ATS26 Lyon annonce une matinée “IA & cyber” pensée pour repartir avec des décisions et une trame d’action, pas une veille passive : démo de hacking éthique, défi “Security & AI”, table ronde, sessions interactives. C’est exactement le bon format si ton objectif est de cadrer vite un risque diffus comme le Shadow AI.

Infos pratiques : mardi 3 novembre 2026, 9h00-14h00, La Bulle Workplace, 3 rue Fénelon, 69006 Lyon (Lyon 6e). Source : Lyon IA, article ATS26. https://lyon-ia.com/blog/ats26-lyon-0311-prepare-ta-matinee-ia-cyber-et-repars-avec-un-plan-pas-des-slides

Le Shadow AI en 2026 : ce qui a changé (et ce que tu rates si tu restes sur “un chatbot”)

En 2025-2026, le Shadow AI ne se limite plus à une page web où quelqu’un colle un texte. La surface s’étend avec :

• Agents qui enchaînent des actions et des accès (calendrier, messagerie, CRM, ticketing, drive, Git, etc.).
• Plugins, connecteurs, MCP servers et automatisations qui multiplient les flux de données et les identités machine.
• Fonctions IA “natives” activées dans des SaaS, parfois sans décision centrale.

Résultat : les contrôles “humain-centric” (un utilisateur, une appli, un log) deviennent insuffisants si tu ne modélises pas aussi les identités non humaines et les chaînes d’appels. Source : TechRadar, analyses sur l’agentique et l’attestation des contrôles.

Ce n’est pas marginal : quelques chiffres à garder en tête

• BYOAI : 78% des utilisateurs d’IA disent apporter leurs propres outils au travail (Microsoft/LinkedIn, Work Trend Index 2024).
• Comptes personnels et données sensibles : 68% accèdent à la GenAI via des comptes perso, 57% disent y avoir entré des infos sensibles (Menlo Security, 2025).
• Cohabitation : 30% n’utilisent que des apps personnelles, 56% uniquement des apps gérées, 14% les deux (Netskope, AI Report 2026).
• Coût : un niveau élevé de Shadow AI est associé à un surcoût moyen d’environ 670 000 USD sur le coût d’une violation (IBM, Cost of a Data Breach 2025).

Traduction terrain à Lyon : dans une ETI, un siège régional, un groupe multi-sites, tu as déjà des usages “hors radar” dans le support, le commerce, les RH, les devs, la data. Et personne ne veut être celui qui “interdit”. Donc ça avance en douce.

À qui ça sert, côté IT et cyber (profils qui doivent venir)

Si tu coches une de ces cases, le sujet est pour toi.

• RSSI / CISO : tu veux des preuves de contrôle et une posture défendable, pas une charte PDF.
• DSI / IT manager : tu dois arbitrer “on autorise quoi” et “qui opère”, sans exploser le support.
• SOC / Blue team : tu veux détecter, journaliser, corréler, et éviter l’angle mort IA.
• IAM / AD / SSO : tu vois arriver les tokens, les apps OAuth, les identités machine.
• Réseau / proxy / DNS : tu peux donner de la visibilité rapide sur les usages réels.
• Juridique / achats IT : tu dois cadrer les fournisseurs IA et les clauses qui vont avec.
• DPO / data governance : tu veux savoir quelles données partent, où, et pourquoi.

Viens avec une cartographie minimale. Sinon tu repartiras avec des intentions.

Objectif : arriver à ATS26 avec un inventaire “premier jet” des usages IA. Pas parfait. Juste assez concret pour décider et prioriser.

Le template simple (1 page)

• Outils : liste des apps IA vues ou suspectées (web, extensions, SaaS avec IA, API, assistants de code, transcription, etc.).
• Données : quelles catégories entrent dans ces outils (public, interne, confidentiel, données perso, secrets, code, tickets support, contrats).
• Accès : comment on se connecte (compte perso, SSO, OAuth, clé API, token), et depuis où (poste géré, BYOD, mobile).
• Flux : “ça part où” (domaines, fournisseurs), et “ça revient où” (mail, drive, CRM, Git).
• Traces : logs disponibles ou pas (proxy, DNS, CASB, SIEM, audit SaaS).

Si tu n’as pas ça, tu vas débattre de principes. Avec ça, tu peux sortir une politique et 5 contrôles concrets dès le lendemain.

Les 12 questions à traiter avant que le Shadow AI devienne un incident

1) C’est quoi ton périmètre “IA” exactement ?

Tu couvres seulement les chatbots web ? Ou aussi :

• les assistants intégrés (suite bureautique, CRM, ticketing),
• les API de modèles,
• les extensions navigateur,
• les assistants de code,
• les agents et automatisations multi-outils.

Si tu ne définis pas le périmètre, tu fais un inventaire qui rate 50% du risque.

2) Quels usages tu tolères, lesquels tu interdis, lesquels tu encadres ?

Trois bacs. Simple. Lisible.

• Autorisé : ex. reformulation de texte non sensible, brainstorming, traduction de contenus publics.
• Autorisé sous conditions : ex. support client avec base interne, code, contrats, données perso, uniquement via outils approuvés et logs.
• Interdit : ex. secrets, identifiants, données de santé, dossiers RH nominatif, data client non anonymisée, via comptes perso ou outils non contractés.

3) Quelles données sortent déjà, en vrai ?

Ne pars pas d’un sondage. Pars des signaux techniques. Menlo Security rappelle un point dur : une majorité d’utilisateurs passent par des comptes personnels et une part significative entre des infos sensibles. Tu dois assumer que “ça arrive déjà”.

4) Tu as une liste des outils vus dans tes logs réseau ?

Premier niveau, rapide : DNS et proxy.

• Top domaines IA (chatbots, API, transcription, génération d’images, etc.).
• Catégorisation web (si ton proxy le permet).
• Évolution hebdo (ça monte, ça baisse, qui consomme).

Ce n’est pas parfait. C’est une base factuelle.

5) Tu sais distinguer “outil approuvé” vs “outil perso” ?

Les rapports type Netskope montrent une cohabitation massive. Ton enjeu : rendre visible le statut.

• SSO activé ou pas.
• Comptes corporate ou mails perso.
• Clients lourds/agents installés vs simple web.

6) Qui a le droit d’utiliser des API IA, et comment tu le prouves ?

Les API, c’est là où l’industrialisation “hors cadre” démarre. Et c’est là où tu perds la traçabilité si tu laisses des clés tourner dans des scripts.

• Clés API par équipe ou par produit, jamais “partagées”.
• Rotation, scopes, quotas, séparation dev/test/prod.
• Revue périodique des clés et des intégrations.

7) Tu as un modèle IAM pour les agents et identités non humaines ?

Si un agent a accès à ta messagerie, ton drive, ton CRM ou ton ticketing, il devient un super-utilisateur potentiel. Et pas toujours bien loggé.

Pour creuser le sujet côté accès et logs, tu peux t’appuyer sur cet article Lyon IA : https://lyon-ia.com/blog/agents-ia-et-cybersecurite-effacement-de-traces-audit-des-logs-et-acces-avant-dautomatiser

8) Quelles preuves tu peux produire en cas d’alerte ou de contrôle ?

Le Shadow AI est un problème de preuves. CSA insiste sur ce point : sans traces, tu ne peux pas démontrer les flux et la maîtrise.

• Qui a utilisé quoi.
• Quels prompts et quels documents ont été envoyés (quand c’est possible).
• Quel fournisseur, quelles garanties.
• Quels contrôles actifs (blocage, DLP, restrictions).

9) Tu as un “chemin officiel” qui marche, ou tu pousses les gens à contourner ?

La gouvernance ne doit pas démarrer par “interdire”, sinon tu fabriques du Shadow AI. Cadre CSA : proposer des alternatives approuvées, accessibles, rapides, réduit la tentation de contourner.

Concrètement : un outil approuvé, des cas d’usage autorisés, un process de demande simple, un délai de réponse court.

10) Tes fournisseurs IA sont cadrés contractuellement ?

Achats et juridique doivent être dans la boucle. Sinon tu as des outils utilisés avec des conditions par défaut, pas alignées sur tes exigences.

Pour les clauses, Lyon IA a un guide utile : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses

11) Tu as une politique d’usage interne lisible et applicable ?

Pas un roman. Une page, des exemples, et des sanctions réalistes. Et surtout des consignes actionnables : quoi faire, quoi ne pas faire, et quoi faire quand tu doutes.

Si tu pars de zéro, base de départ : https://lyon-ia.com/blog/charte-usage-ia-entreprise

12) Tu as un plan 30 jours : inventaire, contrôles, communication, boucle de revue ?

Si tu ne mets pas une cadence, ça finit en “à faire”. Pour une logique plan court, ce contenu peut servir de structure : https://lyon-ia.com/blog/ai-act-a-lyon-ce-qui-sapplique-deja-et-ton-plan-30-jours-usages-contrats-preuves

Mémo “premier niveau” : contrôles concrets à poser dès maintenant

Tu veux sortir d’ATS26 avec des décisions actionnables. Voici une liste courte, orientée “réduction du risque sans tuer l’usage”.

Contrôles DNS et proxy (visibilité rapide)

• Découverte : top domaines IA, top volumes, tendances.
• Catégorisation : distinguer apps IA, stockage, dev tools, etc.
• Blocage ciblé : bloquer certaines catégories ou domaines à haut risque, pas “tout l’IA”.
• Exceptions : process simple pour demander une ouverture, traçable.

Journalisation et preuves (SIEM-ready)

• Centralise les logs proxy/DNS et les logs SaaS quand dispo.
• Garde une rétention cohérente avec ton risque et tes obligations.
• Tagge ce qui est “IA” pour la corrélation incident.

Gestion des accès (humains + non humains)

• SSO obligatoire pour les outils approuvés.
• MFA systématique.
• OAuth sous contrôle : inventaire des apps connectées, revue régulière.
• Clés API : rotation, scopes, quotas, séparation environnements.
• Agents : comptes de service dédiés, droits minimum, logs activés.

Clauses fournisseurs (achats et juridique)

• Données : usage pour entraînement, conservation, localisation, sous-traitants.
• Sécurité : chiffrement, audits, notification d’incident, tests.
• Sortie : réversibilité, suppression, export des logs si possible.
• Conformité : alignement RGPD et exigences sectorielles.

Règles d’usage internes (pour réduire le Shadow AI)

• Un “oui” clair sur des usages simples, sinon tu crées du contournement.
• Un “non” clair sur données sensibles et comptes perso.
• Une alternative officielle qui marche (compte entreprise, outil approuvé, support).
• Un circuit court pour valider un nouvel outil ou un nouveau cas.

Ce que tu dois préparer la veille (checklist 45 minutes)

• Liste de 10 outils IA “suspects” vus dans l’entreprise (même si c’est approximatif).
• 3 catégories de données que tu refuses de voir sortir, et pourquoi.
• État des lieux accès : SSO possible ou pas, MFA, OAuth sous contrôle ou non.
• Ce que tu logs déjà (proxy, DNS, SaaS) et ce que tu ne logs pas.
• 1 incident plausible : “un commercial a collé une liste clients”, “un dev a mis du code propriétaire”, “un agent a eu accès au drive”.

Avec ça, la matinée devient un atelier. Sans ça, tu écoutes et tu retournes au bureau avec des idées.

Ce que tu peux viser en sortie : une politique simple + 5 contrôles “jour 1”

Objectif réaliste après ATS26 : un socle de gouvernance IA entreprise version pragmatique.

• Une page de règles (autorisé, sous conditions, interdit).
• Un registre d’usages minimal (outil, données, accès, logs, owner).
• Un contrôle réseau de base (DNS/proxy) + un plan d’amélioration.
• Un standard IAM pour outils IA (SSO, MFA, OAuth, API keys).
• Un pack clauses pour tout nouveau fournisseur IA.

Sources et renvois utiles (pour cadrer sans blabla)

• ATS26 Lyon, infos et format : https://lyon-ia.com/blog/ats26-lyon-0311-prepare-ta-matinee-ia-cyber-et-repars-avec-un-plan-pas-des-slides
• Shadow AI (cadre de base côté Lyon IA) : https://lyon-ia.com/blog/shadow-ai-en-entreprise
• Agents, logs, accès : https://lyon-ia.com/blog/agents-ia-et-cybersecurite-effacement-de-traces-audit-des-logs-et-acces-avant-dautomatiser
• Clauses fournisseur IA : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses
• Charte d’usage IA : https://lyon-ia.com/blog/charte-usage-ia-entreprise
• Plan 30 jours (usages, contrats, preuves) : https://lyon-ia.com/blog/ai-act-a-lyon-ce-qui-sapplique-deja-et-ton-plan-30-jours-usages-contrats-preuves

À faire maintenant (si tu veux que ATS26 te serve vraiment)

Tu veux cadrer le Shadow AI avant l’incident. Donc tu fais simple.

• 1) Tu arrives avec une carto 1 page : outils, données, accès, traces.
• 2) Tu choisis 3 décisions à trancher pendant la matinée : outil approuvé, règle de données, standard SSO/OAuth.
• 3) Tu repars avec un plan 30 jours : inventaire, contrôles DNS/proxy, logs, IAM, clauses fournisseurs, règle interne.

Et tu lances la boucle de revue mensuelle. Parce que le Shadow AI n’est pas un projet. C’est un flux.