Tu demandes à l'équipe plateforme où tourne le modèle, on te répond par une région : « Francfort ». Tu respires. Le soir même, pour traiter le dossier d'un client, l'agent interroge un CRM hébergé chez un tiers, appelle un outil de recherche externe, fait passer le texte par un serveur MCP installé en mars par quelqu'un, et, quand le fournisseur principal sature, retente sur un autre modèle dans une autre région. Francfort, c'était un maillon sur cinq.
La thèse en une ligne : la souveraineté des données d'un agent ne se décide pas là où tourne le modèle ; elle se décide à chaque maillon de la chaîne que l'agent parcourt pour faire son travail. Un périmètre qui ne regarde que le modèle, c'est un cadenas sur une porte entourée de quatre fenêtres ouvertes.
Souveraineté des données avec les agents IA : chaque appel en décide, pas le modèle
Un chatbot classique avait une frontière facile à tracer : l'utilisateur écrit, le modèle répond, la donnée fait l'aller-retour par un seul endroit. Un agent casse cette géométrie parce qu'il agit : il lit dans un système, écrit dans un autre, demande de l'aide à un outil, garde une mémoire. Chacune de ces actions est un appel réseau, et chaque appel réseau est une décision sur la destination de la donnée, sur qui la traite et sur combien de temps elle est conservée. « Où vit notre agent ? » n'a pas de réponse utile. Celle qui en a une, c'est : « où va chaque octet de cette exécution ? »
Si l'exécution contient des données personnelles, chaque destination est, en protection des données, un traitement avec son fournisseur, son contrat de sous-traitance et, si elle quitte l'Espace économique européen, sa base de transfert. Un agent ne change pas les règles : il multiplie les endroits où les appliquer. On a déjà expliqué dans IA générative et RGPD : ce que ton fournisseur ne te dit pas pourquoi le label « enterprise » n'est pas une garantie ; avec les agents, le problème n'est plus un contrat, c'est un parcours.
Les cinq maillons d'une chaîne d'agent et ce qui sort à chacun
| Maillon | Ce qui peut sortir | La question qui tranche |
|---|---|---|
| Modèle principal | Le prompt complet : consignes, contexte récupéré et données du dossier | Dans quelle région est-il traité et conservé, et sous quel contrat ? |
| Outils et API | Les paramètres de chaque appel : noms, montants, identifiants | Quels champs l'outil reçoit-il vraiment, et les lui faut-il tous ? |
| Serveurs MCP et connecteurs | Ce que le serveur demande et ce que l'agent lui remet, parfois à un tiers | Qui l'exploite, où tourne-t-il et qui l'a validé ? |
| Modèle de secours | La même requête renvoyée à un autre fournisseur ou une autre région quand le principal tombe | Ta politique autorise-t-elle ce secours, ou se déclenche-t-il tout seul ? |
| Mémoire, traces et embeddings | Des copies de la donnée dans les vecteurs, les journaux et les outils d'observabilité | Qui voit les traces, combien de temps sont-elles gardées et où vivent-elles ? |
MCP mérite une ligne à part. C'est le standard qui relie un agent à des outils et à des données via des serveurs, et ces serveurs peuvent être les tiens, ceux d'un fournisseur ou ceux d'un tiers installés par commodité (on explique ce qu'est MCP et pourquoi il change les agents d'entreprise). Un serveur distant reçoit tout ce que l'agent lui envoie. Le traiter comme « un plugin », c'est traiter un sous-traitant ultérieur comme une extension de navigateur.
Les deux maillons qui fuient le plus sont le quatrième et le cinquième, pour la même raison : ils marchent quand on ne les voit pas. Le modèle de secours est un filet utile : le principal renvoie une erreur, le routeur retente sur le suivant de la liste et l'utilisateur ne remarque rien. Ta politique de données non plus, elle qui disait « région UE uniquement » et vient d'envoyer le même prompt ailleurs. Les traces sont tout aussi silencieuses : l'outil qui t'aide à déboguer garde, sauf configuration volontaire, une copie littérale de chaque conversation.
Et le cadre juridique des transferts ? Lui non plus n'est pas une constante
Une partie de la réponse à « puis-je envoyer ça à un fournisseur américain ? » repose sur le Data Privacy Framework UE-États-Unis. Le Tribunal de l'UE en a confirmé la validité le 3 septembre 2025, en rejetant le recours de Philippe Latombe, et Latombe a formé un pourvoi devant la Cour de justice le 31 octobre 2025 (source : WilmerHale, décembre 2025). Périmètre : droit de l'UE ; cela concerne les données personnelles qui quittent l'EEE vers des entreprises américaines certifiées, et ne s'extrapole pas à d'autres régimes.
Comment auditer la souveraineté d'un agent sans équipe plateforme
Pas besoin d'un projet de six mois. Il faut une exécution réelle et une heure :
- Prends une requête réelle, de celles qui portent des données client, et lance-la avec le journal réseau ou les traces de l'agent activés.
- Note chaque destination vers laquelle le trafic sort : domaine, fournisseur et région si tu la connais. En général, il y en a plus que prévu.
- Repère celles qui portent des données personnelles ou confidentielles et, pour chacune, écris trois choses : contrat, région et durée de conservation. Là où tu ne sais pas remplir une case, c'est ta trouvaille.
- Décide maillon par maillon : couper, minimiser (n'envoyer que les champs nécessaires), pseudonymiser avant la sortie ou changer de fournisseur.
- Garde le résultat comme une carte vivante : une page avec les destinations validées. Tout nouveau maillon — un outil, un serveur MCP, un secours — entre dans la carte avant d'entrer en production.
Deux éléments rendent la chose plus simple qu'elle n'en a l'air. Le premier, ce sont les permissions d'un agent IA : un agent avec sa propre identité et un périmètre par tâche limite déjà les données qui arrivent à chaque outil. Le second, c'est de choisir quel modèle utiliser dans un agent avec la région et le contrat sur la table, pas seulement la précision. Et si ta réponse à « on l'héberge nous-mêmes ? » est oui, lis d'abord quand l'auto-hébergement vaut le coup et ce qu'il règle vraiment : héberger le moteur ne ferme pas les quatre autres maillons.
Quand la carte compte plus de destinations que ton équipe ne peut en relire, c'est un travail de gouvernance des données, et ce qui prouve ce qui s'est passé à chaque exécution, c'est la traçabilité des décisions de l'IA.
Quand tout ça n'est pas nécessaire
Si ton agent ne touche que de l'information publique ou non personnelle — un agent qui résume de la documentation ouverte, par exemple — et n'écrit dans aucun système, la carte à cinq maillons est excessive : savoir quel fournisseur l'exécute suffit. Et tout héberger chez soi n'est pas une solution automatique : un modèle sur ta propre infrastructure qui remet la donnée complète à un outil externe fuit toujours ; il a juste changé de maillon. Tout cela relève du jugement opérationnel, pas du conseil juridique : la base légale de chaque transfert se valide avec ton DPO ou ton conseil.
La phrase à retenir : ne demande pas où tourne le modèle, demande où va chaque appel. La première question a une réponse confortable. La seconde a une liste, et c'est cette liste que tu dois pouvoir montrer.