Lyon et AURA : sécuriser vos agents IA avant qu’ils ne deviennent des agents fantômes

Les “agents fantômes” arrivent plus vite que ta gouvernance

Tu crois déployer “un assistant” pour aider les équipes. En pratique, tu laisses parfois entrer un agent IA qui peut lire, écrire, déclencher, acheter, supprimer. Et surtout, le faire sans propriétaire clair, sans logs, sans validation DSI, RSSI, DPO, ni achats. C’est ça, la shadow AI entreprise. Et quand ça devient “agentique”, l’ombre est plus dangereuse, parce que l’IA ne fait pas que répondre. Elle agit.

Le terrain est parfait pour que ça explose dans les PME et ETI de Lyon et d’Auvergne-Rhône-Alpes : filières industrie, services, santé, retail, logistique. Beaucoup d’équipes testent, bricolent, connectent des outils. Souvent avec de bonnes intentions. Mais un jour, tu te retrouves avec un “agent” branché au Drive, au CRM ou à la boîte mail, créé avec un compte perso, payé sur une carte corporate, et invisible pour la sécu. Un agent fantôme.

Définition opérationnelle : shadow AI et “agents IA” côté sécurité

Shadow AI en entreprise : l’IA hors radar

La shadow AI, c’est l’usage d’outils d’IA (SaaS, extensions navigateur, API, notebooks, agents) sans validation par la DSI, la sécurité (RSSI), la conformité (DPO) et les achats. Gartner parle explicitement de “shadow AI” comme d’un sujet à “mettre en lumière” côté sécurité.

Un agent IA, ce n’est pas un chatbot

Dans un cadre sécurité, un agent IA est un système piloté par LLM capable de planifier, utiliser des outils, conserver une mémoire et exécuter des actions. L’OWASP insiste sur le fait que cette autonomie augmente mécaniquement le risque si l’agent est déployé en dehors des radars, sans journalisation, contrôle d’accès, owner, ni procédure d’arrêt.

Traduction simple : un chatbot te répond. Un agent peut faire à ta place. Et c’est exactement ce que veulent les métiers. Donc ils y vont, parfois sans attendre.

Pourquoi ça apparaît maintenant (et pourquoi ça t’échappe)

1 550 apps genAI, et ça bouge toutes les semaines

Netskope indique suivre plus de 1 550 applications SaaS genAI. Ce volume rend le contrôle “outil par outil” intenable si tu n’as pas une approche catalogue + règles. Résultat : les équipes trouvent un outil, l’essayent, le gardent, le connectent. La DSI apprend l’existence du truc au moment d’un incident.

L’usage accélère, donc le “shadow” devient la norme

Netskope Threat Labs rapporte un pic de +50 % d’usage des plateformes genAI sur trois mois (période se terminant en mai 2025). Quand l’adoption monte aussi vite, la gouvernance classique se fait doubler. Ce n’est pas un problème de “mauvaise volonté” interne. C’est un problème de vitesse.

Les agents sont déjà là, en quantité

Microsoft (Cyber Pulse, 24/02/2026) signale que les agents sont déjà très présents dans les organisations, via télémétrie et enquête. Un article reprenant ces résultats cite environ 37 agents en moyenne en entreprise, et plus de la moitié fonctionneraient sans supervision sécurité ni journalisation (chiffres attribués au Cyber Pulse de février 2026).

Le point qui fait mal : tu ne vois pas la différence entre “pro” et “perso”

Le rapport 2026 “AI Risk and Readiness” (Netskope x Cybersecurity Insiders) insiste sur un piège concret : si l’équipe sécurité ne distingue pas usage “tenant entreprise” vs comptes personnels, alors DLP, contrôles d’accès et audit trail deviennent peu fiables. Et c’est exactement ce qui se passe dans beaucoup de PME : on laisse les gens tester “avec leur compte”, et ensuite on ne sait plus où passent les données.

Ce qui change avec des agents : le risque devient transactionnel

Un agent branché à des outils, c’est une chaîne d’actions. Exemple classique dans une PME lyonnaise :

• l’agent lit un mail client,
• récupère une pièce jointe,
• résume,
• crée un ticket support,
• met à jour le CRM,
• et répond au client.

À ce stade, tu n’es plus sur “un outil de productivité”. Tu es sur une automatisation qui manipule des données et qui peut faire des dégâts. OWASP parle notamment d’excessive agency (autonomie excessive) et rappelle qu’il faut contrôler la couche outils et actions, pas seulement les prompts.

Risques concrets pour une PME ou ETI de Lyon et d’AURA (SI, gouvernance, achats)

1) Exfiltration de données par appels outils, API, sorties

OWASP liste explicitement le risque d’exfiltration via appels outils/API/sorties dans sa “AI Agent Security Cheat Sheet”. Un agent qui a accès à un Drive, un ERP ou un outil de ticketing peut “aspirer” beaucoup plus que prévu, puis renvoyer des extraits dans une réponse, dans un log tiers, ou vers un connecteur externe.

2) Angles morts d’audit : pas de logs, pas de traçabilité, pas d’owner

Quand un agent est créé via une plateforme SaaS “no code” et déployé par une équipe métier, tu perds vite :

• la trace de qui a créé l’agent,
• la trace de ce qu’il a fait,
• la possibilité de rejouer ou expliquer une action,
• la procédure pour l’arrêter proprement.

3) Dérive des droits : tokens partagés, connecteurs non maîtrisés

Le grand classique : une clé API partagée dans un tableur, un compte “service” avec trop de droits, un connecteur “Google Drive” autorisé trop largement, puis réutilisé ailleurs. L’agent est peut-être “petit” au départ. Les permissions, elles, deviennent énormes.

4) Risque conformité : AI Act, transparence, documentation

En UE, des obligations de transparence du AI Act s’appliquent à partir du 2 août 2026 (Article 50, obligations de transparence pour certains systèmes, avec précisions de la Commission). Si tu ne sais même pas quels agents tournent, où, et pour quoi faire, tu ne documentes rien. Donc tu subis.

Si tu veux un point d’entrée très concret côté entreprise, tu peux t’appuyer sur ce registre prêt à copier publié sur Lyon IA : AI Act : documenter vos usages d’IA en entreprise (registre prêt à copier + exemple PME Lyon).

5) Risque cyber : pas besoin d’un film de science-fiction pour se faire mal

L’ANSSI (04/02/2026) indique qu’aucun système d’IA générative n’a, à ce stade, mené de manière autonome toutes les étapes d’une attaque. Mais l’IA générative pèse déjà sur les modes opératoires et la menace. Message utile : pas de panique, mais pas d’aveuglement. Un agent mal cadré suffit à créer une fuite, une erreur de manipulation, un accès indû.

Réduire la shadow AI sans tuer l’usage : un cadre léger mais concret

Objectif réaliste pour une PME/ETI : rendre l’usage visible, réduire les risques majeurs, garder la vitesse. Pas une usine à gaz ISO. Juste les garde-fous qui évitent les agents fantômes.

1) Un catalogue d’outils autorisés, plus une porte d’entrée rapide

Tu ne peux pas empêcher les équipes d’utiliser des agents si tu n’offres rien. Donc tu fais deux choses :

• Catalogue : 5 à 15 outils autorisés (agents, chat, intégrations, stockage, transcription, etc.).
• Fast lane : un formulaire simple pour demander l’ajout d’un outil ou d’un connecteur, avec réponse en 5 jours ouvrés.

Le catalogue doit dire clairement : cas d’usage, données autorisées, données interdites, mode d’authentification, logs, propriétaire.

2) Des règles de données simples, écrites, comprises

Pas besoin de 40 pages. Il te faut une règle lisible :

• données publiques ok,
• données internes ok selon outil,
• données client, RH, santé, finance, secrets industriels : conditions strictes,
• comptes perso interdits pour usage pro,
• pas de copier-coller brut de fichiers sensibles dans un outil non approuvé.

Pour cadrer ça, tu peux t’appuyer sur une charte d’usage : Rédiger une charte d'usage de l'IA pour ses équipes.

3) Validation sécurité et achats : courte, mais systématique

Le duo qui manque le plus souvent : RSSI et achats. Or, les agents IA touchent aux deux :

• Sécurité : SSO, MFA, gestion des accès, isolation des environnements, chiffrement, logs, rétention.
• Achats : clauses contractuelles, localisation, sous-traitants, usage des données, conditions de sortie.

Pour la partie fournisseur, garde une grille de lecture contractuelle : Contrat avec un fournisseur d'IA : les clauses à lire deux fois.

4) Journalisation et traçabilité : obligatoire dès que ça agit

Règle simple : si l’agent peut faire une action (écrire dans un outil, envoyer un mail, créer une commande), alors :

• il doit produire des logs exploitables,
• tu dois pouvoir relier une action à un owner,
• tu dois avoir un kill switch (désactivation rapide),
• tu dois pouvoir auditer : entrées, sorties, outils appelés, erreurs.

Pour cadrer la traçabilité côté entreprise : Tracer les décisions prises avec l'aide d'une IA.

5) Budget et pilotage : sinon tu payes deux fois

Le shadow AI, ce n’est pas seulement la sécurité. C’est aussi la facture : abonnements doublons, API facturées en douce, coûts tokens qui dérivent. Mets un minimum de pilotage :

• un centre de coûts “IA” (même petit),
• une règle : pas d’abonnement IA sans owner et sans usage déclaré,
• un suivi mensuel des 10 plus gros coûts.

Pour structurer ce pilotage : Un quart des budgets IA gâché : comment piloter vos dépenses IA.

6) Formation courte : agents, données, connecteurs, réflexes

Tu n’as pas besoin de transformer tout le monde en expert LLM. Tu veux 3 réflexes :

• je sais ce que je peux mettre ou non dans l’outil,
• je sais reconnaître un agent “qui agit” et donc plus risqué,
• je sais comment déclarer un usage et demander un connecteur.

Tu peux partir d’un programme minimum : Former ses équipes à l'IA : le programme minimum qui fonctionne.

Le “pack de contrôles” minimum pour des agents IA (pratique, pas théorique)

Si tu dois standardiser une check-list, vise ces 10 points. Ils couvrent agents IA gouvernance, sécurité, achats, et SI.

• Owner nommé (métier) + référent DSI/RSSI.
• Cas d’usage écrit en 10 lignes, avec bénéfice attendu.
• Données manipulées listées (catégories) + classification.
• Outils connectés listés (mail, drive, CRM, ERP, etc.).
• Auth entreprise (SSO si possible), pas de compte perso.
• Permissions minimales sur les connecteurs (least privilege).
• Logs activés, centralisés, durée de rétention définie.
• Budget plafonné, alertes de consommation.
• Procédure d’arrêt : kill switch + rollback si écriture.
• Test sur un jeu de cas (erreurs, données sensibles, injection de prompt).

Si tu veux aller plus loin côté sécurité agentique, sans t’éparpiller, tu peux t’appuyer sur les garde-fous déjà posés sur Lyon IA : Agents IA en production : les cinq garde-fous à poser et Sécuriser un agent IA qui a accès à vos outils.

Process en 30 jours pour une PME/ETI lyonnaise : rendre visible, cadrer, sécuriser

Objectif : en 30 jours, tu passes de “on ne sait pas” à “on sait ce qui tourne, qui paie, qui est responsable, et on a un cadre pour dire oui vite”. C’est une version réaliste de gouvernance IA PME.

Semaine 1 (jours 1 à 7) : découverte et gel intelligent

• Message interne (DG ou DSI) : déclaration obligatoire des outils IA et agents utilisés. Ton simple. Pas accusateur. Deadline 7 jours.
• Inventaire : liste des outils, extensions, plateformes d’agents, API, notebooks, automatisations “avec IA”.
• Tri rapide : classer en 3 catégories :
  • catégorie A : chat/assistants sans données sensibles,
  • catégorie B : agents avec données internes,
  • catégorie C : agents qui agissent (écriture, envoi, commandes) ou données sensibles.
• Gel ciblé : catégorie C, stop temporaire ou passage en mode lecture seule tant que pas de contrôle.

Astuce terrain : à Lyon, beaucoup d’usages émergent via marketing, sales, support, RH, et parfois via des équipes techniques qui testent MCP, connecteurs, ou iPaaS. Ne te limite pas à “les métiers”. Cherche aussi dans l’IT et la data.

Semaine 2 (jours 8 à 14) : règles données + catalogue v0

• Règles données 1 page : ce qui est autorisé, ce qui est interdit, et comment demander une exception.
• Catalogue v0 : 5 à 10 outils autorisés, avec conditions (compte pro, SSO, logs, etc.).
• Modèle de fiche agent (une page) : owner, cas d’usage, données, connecteurs, budget, logs, kill switch.

Tu veux un cadre simple pour organiser “qui décide quoi” dans une petite structure : Gouvernance de l'IA : qui décide quoi dans une entreprise de cinquante personnes.

Semaine 3 (jours 15 à 21) : sécurité SI et achats, sans blocage

• SSO et comptes : imposer le tenant entreprise quand il existe. Interdire les comptes perso pour usage pro sur les outils du catalogue.
• Connecteurs : revoir les permissions, supprimer les clés partagées, créer des comptes de service cadrés si nécessaire.
• Logs : activer et centraliser au minimum les journaux d’exécution des agents critiques.
• Achats : revue des abonnements IA existants. Identifier doublons, conditions de données, sous-traitants, clauses de réversibilité.

Pour rester pragmatique sur l’architecture et les mesures, l’ANSSI a publié des recommandations de sécurité pour un système d’IA générative (29/04/2024). C’est une bonne base pour “ne pas oublier l’évidence”, même en PME.

Semaine 4 (jours 22 à 30) : mise en production contrôlée + formation flash

• Revalidation des agents catégorie B et C via la fiche agent (owner, logs, permissions, budget).
• Kill switch opérationnel : procédure claire, contact, délai, qui décide.
• Formation 60 minutes pour managers et référents : règles données, comment déclarer, comment demander un connecteur, quoi faire en cas d’incident.
• Rythme mensuel : comité léger 30 minutes, revue des nouveaux agents, incidents, coûts, demandes d’outils.

Le trio gouvernance, SI, achats : qui fait quoi (sans comité interminable)

• Métiers : owner des agents, description du besoin, validation que l’agent “fait le job”, et qu’on peut arrêter si ça dérape.
• DSI/RSSI : contrôle des accès, logs, segmentation, validation des connecteurs, et règles de déploiement. C’est là que se joue la sécurité données agents IA.
• Achats : contrats, sous-traitants, conditions de données, réversibilité, coût total. C’est là que se joue le “shadow spend”.
• DPO (si données perso) : base légale, minimisation, conservation, sous-traitance, information si nécessaire.

Tu veux éviter les tunnels. Donc tu fixes une règle de délai : si c’est dans le catalogue, validation en 48 h. Si c’est hors catalogue, réponse en 5 jours ouvrés avec oui, non, ou oui sous conditions.

Signaux d’alerte : tu as déjà des agents fantômes si tu vois ça

• Des abonnements IA payés en carte, sans bon de commande ni owner.
• Des connecteurs “Google Drive full access” ou “Gmail read/write” posés par défaut.
• Des clés API qui circulent sur Slack, Notion ou Excel.
• Des agents qui tournent “la nuit” et personne ne sait pourquoi.
• Un agent “support” qui envoie des mails en ton nom, sans relecture.
• Un outil IA utilisé via un compte personnel, parce que “c’était plus rapide”.

Actions à lancer demain matin (si tu veux réduire la shadow AI entreprise)

• Déclare : inventaire express des agents et outils IA en circulation.
• Classe : qui lit, qui écrit, qui agit. Tout ce qui agit passe en contrôle renforcé.
• Catalogue : une liste courte d’outils approuvés, avec des règles simples de données.
• Logs + owner : pas de logs, pas de prod. Pas d’owner, pas d’agent.
• Achats : audit des abonnements et clauses de données, stop aux doublons.
• Formation flash : 1 heure, trois réflexes, et un canal pour demander vite.

Si tu fais ça, tu ne “tues” pas les agents. Tu les rends gouvernables. Et c’est exactement le but : garder la vitesse des équipes de Lyon et d’AURA, sans fabriquer une armée d’agents fantômes impossibles à auditer.