Résidence des données et résidence de l’inférence : stocker n’est pas calculer
La résidence des données désigne la région dans laquelle le contenu client couvert est stocké au repos. La résidence de l’inférence désigne la région dans laquelle s’exécute le modèle sur ce contenu, c’est-à-dire le calcul GPU. Ce ne sont pas deux formulations de la même garantie.
La distinction est devenue assez structurante pour que les fournisseurs la formalisent. OpenAI la documente explicitement et réserve la résidence de l’inférence aux clients éligibles de ses offres entreprise et éducation ayant déjà activé la résidence des données, dans les régions qui la prennent en charge. Une donnée peut donc être stockée dans une région déterminée pendant que certaines opérations nécessaires au service suivent d’autres règles.
Ce n’est pas un défaut de conception, et encore moins un manquement de la part des fournisseurs. C’est la conséquence du fait qu’une application d’IA est une chaîne de traitements, pas un entrepôt.
Cartographier le parcours, pas seulement le point de stockage
Prenons un assistant interne branché sur la documentation de l’entreprise. L’utilisateur pose une question. L’application identifie les documents pertinents, en extrait des passages, construit un contexte, appelle le modèle, obtient une réponse, appelle éventuellement un service externe, puis conserve certaines informations d’exploitation.
Chacune de ces étapes peut relever de règles différentes. Comprendre où se trouvent réellement les données suppose donc de suivre la chaîne entière :
stockage → indexation → récupération → contexte → inférence → outils externes → traces
Deux étapes de cette chaîne échappent souvent à l’inventaire. L’indexation d’abord : pour être retrouvés, les documents internes sont découpés puis convertis en vecteurs, et ces embeddings sont conservés dans une base vectorielle. Cette base est une copie dérivée du corpus de l’entreprise, et elle réside là où elle est déployée, chez un éditeur et dans une région qui ne sont pas nécessairement ceux du modèle appelé. Les traces ensuite : prompts, réponses, appels d’outils et journaux d’exploitation sont des données au même titre que les documents d’origine, et rien ne garantit qu’ils soient conservés au même endroit ni pendant la même durée.
C’est précisément ce qui rend la question plus difficile qu’un choix de région dans une console d’administration, et ce qui la rattache directement aux décisions de construction du contexte : chaque information ajoutée au contexte est une information qui voyage.
Vos données servent-elles à entraîner le modèle ?
C’est la première question posée, et la réponse se donne par produit, pas par fournisseur. La documentation d’OpenAI destinée aux développeurs indique que, depuis le 1er mars 2023, les données envoyées à son API ne sont pas utilisées pour entraîner ou améliorer ses modèles, sauf si le client choisit explicitement de les partager. Cet engagement porte sur ce service précis : il ne se transpose ni aux autres offres du même fournisseur ni aux autres fournisseurs.
Une seconde question suit immédiatement, et elle est indépendante de la première : combien de temps ce qui a été envoyé est-il conservé ? Ne pas entraîner sur une donnée et ne pas la conserver sont deux engagements distincts, et le premier n’implique pas le second. La même documentation indique que des journaux de surveillance des abus sont générés par défaut pour l’ensemble des usages de l’API et conservés jusqu’à trente jours, sauf obligation légale de conservation plus longue, et qu’une option de rétention nulle (zero data retention) exclut le contenu client de ces journaux.
Ce qu’il faut retenir n’est pas le chiffre, qui appartient à un fournisseur et à un moment donné, mais la façon de poser la question. Un engagement peut parfaitement garantir l’absence d’entraînement sans rien dire de la durée de rétention, du périmètre couvert ni du sort des traces techniques.
Un connecteur externe peut faire sortir vos données du périmètre garanti
C’est le point le plus souvent négligé. OpenAI indique que les données envoyées à des services tiers, qu’il s’agisse d’applications, de serveurs MCP, de fournisseurs de navigation web ou d’autres outils externes, relèvent des conditions de résidence, de sécurité et de conformité du fournisseur concerné. Sa documentation destinée aux développeurs le formule sans ambiguïté pour le protocole MCP : une organisation disposant de la résidence des données en Europe voit l’inférence et le stockage de son contenu client limités à l’Europe jusqu’au point où la communication est envoyée au serveur MCP, et il lui revient de vérifier que ce serveur respecte ses propres exigences de résidence ou de non-rétention.
Autrement dit, activer une garantie de résidence sur la plateforme principale ne dit rien de ce qui se passe au-delà de la frontière du service. Dès qu’un agent appelle un tiers, il faut examiner ce qui lui est transmis et selon quelles règles il le traite, ce qui relève pleinement de la gouvernance des agents. La question est d’autant plus sensible dans les architectures agentiques, où les appels d’outils se multiplient par conception.
Le raisonnement vaut aussi en amont du contrat. Un périmètre garanti ne protège que les usages qui passent par lui : dès qu’une équipe travaille avec des outils IA que personne n’a référencés, le parcours de la donnée échappe entièrement à l’entreprise, et aucune clause négociée ailleurs ne s’y applique.
« Inférence en Europe » ne veut pas dire « tout en Europe »
La nuance mérite d’être lue avec attention. OpenAI indique que son option de résidence de l’inférence garantit l’exécution GPU sur le contenu client couvert dans la région choisie, pour les charges de travail prises en charge, mais qu’elle ne s’étend ni à l’ensemble des traitements CPU ni aux données système : l’authentification, le routage, l’indexation ou la journalisation sans contenu peuvent avoir lieu en dehors de cette région. La documentation de l’API ajoute que toutes les régions proposées ne prennent pas en charge le traitement en région ; lorsque ce n’est pas le cas, le contenu client peut être traité et stocké temporairement hors de la région pour délivrer le service.
La conclusion à en tirer n’est pas que ces solutions ne tiennent pas leurs engagements. C’est l’inverse : elles les décrivent précisément, et c’est cette précision qu’il faut lire. « Hébergé en Europe », « données au repos en Europe », « traitement en Europe » et « inférence GPU en Europe » ne désignent pas la même chose, et un contrat qui promet l’un ne promet pas les autres.
Les questions à poser à un fournisseur d’IA avant de s’engager
« Où sont vos serveurs ? » ne suffit plus à instruire le sujet. Les questions utiles portent sur le détail du service réellement utilisé.
| Question | Ce qu’elle permet d’établir |
|---|---|
| Les données servent-elles à entraîner ou améliorer le modèle ? | Un engagement de non-entraînement ne dit rien de la durée de conservation. |
| Quelles catégories de données sont couvertes ? | Prompts, documents, sorties du modèle et traces ne relèvent pas forcément du même engagement. |
| Quelles opérations peuvent avoir lieu hors région ? | L’exécution GPU du modèle et les traitements techniques qui l’entourent peuvent être couverts séparément. |
| Que se passe-t-il avec un connecteur externe ? | Un appel d’outil peut faire sortir la donnée du périmètre garanti. |
| Quelles traces sont conservées, où et combien de temps ? | La journalisation est une donnée comme une autre. |
| L’engagement porte-t-il sur ce produit précis ? | Offre grand public, offre entreprise et API peuvent différer chez un même fournisseur. |
Ces réponses ne servent pas seulement à rassurer une direction. La cartographie des flux, la liste des sous-traitants sollicités et les durées de conservation sont exactement les pièces qu’un délégué à la protection des données (DPO) doit pouvoir documenter. Un fournisseur d’IA s’instruit donc comme n’importe quel sous-traitant : par le détail du service effectivement souscrit, pas par la réputation de la marque.
La souveraineté est une décision d’architecture
Le sujet ne se traite pas uniquement au moment du contrat, parce que c’est l’architecture qui détermine le parcours des données. Un système reposant sur un modèle et une base documentaire interne n’a pas le même profil qu’un agent mobilisant plusieurs modèles, trois serveurs MCP, un moteur de recherche externe et diverses API. Chaque composant ajouté crée potentiellement un flux supplémentaire.
La souveraineté entre donc dans la conception au même titre que la performance, le coût ou la sécurité, et elle se vérifie avant la mise en service comme les autres propriétés du système. C’est, très concrètement, l’un des écarts qui séparent un POC réussi d’une mise en production : une démonstration se contente d’un accès qui fonctionne, un système en service doit savoir dire par où passe chaque donnée qu’il manipule.
À retenir
La question du lieu de stockage reste pertinente, mais elle ne referme plus le sujet. La formulation complète est plus exigeante :
Où nos données sont-elles stockées, traitées, enrichies, transmises et éventuellement journalisées pendant l’intégralité du workflow ?
C’est en suivant ce parcours de bout en bout, et non en lisant une seule ligne de contrat, qu’une entreprise mesure réellement son exposition.
