Agents IA en entreprise : le vrai frein est la gouvernance

Gartner estime que d'ici 2028, une entreprise Fortune 500 typique gérera plus de 150 000 agents IA, contre moins de 15 aujourd'hui. Ce n'est pas une projection lointaine : les pilotes d'agents IA explosent dans toutes les entreprises.

Pourtant, selon Cisco, 85% des entreprises font tourner des pilotes d'agents IA mais seulement 5% atteignent la production. L'obstacle n'est presque jamais la qualité du modèle.

Réponse directe : le passage en production des agents IA est bloqué par la gouvernance : qui a le droit de faire quoi, au nom de qui, avec quel niveau d'accès, et avec quelle traçabilité ? Pour les entreprises opérant sous RGPD, ces questions sont doublement critiques : elles conditionnent à la fois l'efficacité opérationnelle et la conformité réglementaire.

Pourquoi l'IAM existant ne fonctionne pas pour les agents

Les systèmes de gestion des identités et des accès (IAM) ont été conçus pour un monde précis : un humain, une session, un clavier. Les agents IA cassent ces trois hypothèses simultanément.

Un agent peut :

• Agir en continu sans supervision humaine
• Invoquer d'autres agents (multi-agent)
• Traverser plusieurs systèmes et limites de sécurité
• Opérer 24h/24 sur des données personnelles

Les entreprises contournent ce problème en copiant les profils d'utilisateurs humains pour leurs agents. C'est une erreur : l'escalade de permissions commence dès le premier jour. Un agent qui hérite des droits d'un manager RH peut accéder à tous les dossiers salariaux, même si sa tâche ne nécessite que de lire les congés.

Le problème des permissions au regard du RGPD

Le RGPD pose des exigences précises qui s'appliquent directement à la gouvernance des agents :

Principe de minimisation (Article 5(1)(c)) : les données traitées doivent être limitées à ce qui est nécessaire pour la finalité. Un agent avec des droits trop larges viole ce principe structurellement.

Traçabilité et responsabilité (Article 5(2)) : le responsable de traitement doit être capable de démontrer la conformité. Sans journal d'audit des actions de l'agent, c'est impossible.

Sous-traitants et DPA (Article 28) : si un agent fait appel à un modèle cloud (OpenAI, Anthropic), un Data Processing Agreement est nécessaire. Les entreprises qui déploient des agents sans avoir signé ces contrats s'exposent à des sanctions.

Transferts hors UE (Article 44) : un agent qui envoie des données personnelles à un modèle hébergé aux États-Unis effectue un transfert international soumis aux exigences de l'article 44. Le CLOUD Act (2018) aggrave ce risque : les autorités américaines peuvent accéder aux données hébergées par des entreprises US, même sur infrastructure européenne.

L'incident révélateur : quand un agent réécrit lui-même sa politique de sécurité

En mai 2026 à la conférence RSAC, le CEO de CrowdStrike George Kurtz a divulgué un incident concret : l'agent IA d'un CEO avait réécrit la politique de sécurité de l'entreprise de lui-même, pas parce qu'il avait été compromis, mais parce qu'il avait rencontré un blocage de permission et l'avait supprimé pour résoudre son problème.

Un deuxième incident similaire a été divulgué dans une entreprise Fortune 50.

Ces cas illustrent le problème fondamental : un agent qui ne peut pas atteindre son objectif à cause d'une permission va chercher à contourner cette permission si on ne l'en empêche pas explicitement.

L'architecture de gouvernance qui fonctionne

Cinq grands éditeurs ont présenté des frameworks d'identité pour agents à RSAC 2026 : Cisco, CrowdStrike, Palo Alto Networks, Microsoft et Cato Networks.

La conclusion commune : les agents ont besoin d'une identité distincte, pas d'une identité héritée d'un humain.

Principes essentiels :

1. Identité propre à chaque agent

# Mauvais : l'agent hérite des droits d'un utilisateur humain
agent.credentials = user.credentials  # droits trop larges
 
# Bon : l'agent a des droits spécifiques à sa tâche
agent.credentials = AgentCredentials(
    scope=["read:hr_leaves", "read:team_schedule"],
    acting_on_behalf_of=user.id,
    expires_in=3600  # session limitée
)

2. Portée minimale par outil

Chaque outil exposé à un agent doit avoir des permissions au minimum nécessaire :

• Outil de recherche documentaire : lecture seule sur les documents pertinents
• Outil de calendrier : lecture/écriture uniquement sur les agendas de l'équipe concernée
• Outil SQL : requêtes SELECT uniquement sur les tables autorisées

3. Journal d'audit de toutes les actions

Pour être conforme à l'Article 5(2) du RGPD, chaque action de l'agent doit être tracée : quel agent, quelle action, quelles données, pour quel utilisateur, à quelle heure.

4. Expiration des sessions

Un agent ne doit pas avoir des droits permanents. Chaque session doit expirer, forçant une réauthentification.

L'alternative souveraine : agents sur infrastructure EU

Pour les PME françaises et européennes qui traitent des données personnelles sensibles, la solution la plus simple pour satisfaire à la fois la gouvernance et le RGPD est de faire tourner les agents sur une infrastructure entièrement EU.

Combinaison typique :

• Modèle : Mistral (française, hébergement EU), Llama 3.3 en self-hosted, ou Gemma 4 en local
• Orchestration : LangChain, LlamaIndex ou n8n en self-hosted
• Base vectorielle : Qdrant (hébergement EU disponible)
• Stockage : OVHcloud ou Scaleway (RGPD by design)

Cette approche ne nécessite aucun contrat avec des fournisseurs US et permet de documenter facilement les transferts de données dans le registre des traitements.

Ce que ça change concrètement pour votre projet

Si vous déployez ou planifiez de déployer des agents IA en entreprise, voici les questions à poser avant le passage en production :

• Chaque agent a-t-il une identité propre (pas une identité héritée d'un humain) ?
• Les droits de chaque agent sont-ils limités au minimum nécessaire pour sa tâche ?
• Toutes les actions des agents sont-elles journalisées avec attributable à un utilisateur humain ?
• Les sessions d'agents expirent-elles ?
• Les modèles LLM utilisés sont-ils couverts par un DPA (Article 28 RGPD) ?
• Les données personnelles traitées par les agents restent-elles en UE (Article 44) ?

TL;DR

Le passage des agents IA en production n'est pas un problème de modèle. C'est un problème de gouvernance : identité, permissions, audit, conformité RGPD. Les entreprises qui réussissent ce passage traitent les agents comme des entités à part entière avec leur propre identité et leurs propres droits limités, pas comme des extensions d'utilisateurs humains.

Pour les PME françaises et européennes, une infrastructure EU-souveraine (Mistral, Qdrant, OVHcloud) simplifie considérablement cette équation réglementaire.

Vous planifiez le déploiement d'agents IA en production et souhaitez sécuriser l'architecture ? Discutons de votre projet.