Résidence des Données & IA Souveraine : Déploiement LLM Entreprise RGPD/UE (2026)

« Souveraineté des données » est souvent utilisé de façon vague, mais pour un déploiement IA d'entreprise cela se résume à trois questions concrètes : où les données sont-elles physiquement traitées et stockées, quels sous-traitants les touchent en chemin, et quel gouvernement peut légalement en exiger l'accès, quel que soit l'emplacement des serveurs.

La résidence des données répond uniquement à la première question — une affirmation sur l'emplacement physique ou logique (« ces données sont stockées à Francfort »). La souveraineté des données répond à la troisième — une affirmation sur la juridiction légale et son opposabilité (« quel pays, avec ses tribunaux et ses lois d'accès au renseignement, atteint ces données et ce fournisseur »). Un fournisseur cloud domicilié aux États-Unis peut offrir une résidence des données UE complète (centres de données UE, support UE, entité UE comme partie contractante) tout en restant structurellement accessible au droit américain, car la société mère elle-même reste une « US person » au sens du droit américain, quel que soit l'emplacement physique d'un rack de serveurs donné.

Pour l'inférence IA spécifiquement, cela compte car les « données » concernées ne sont pas seulement les données d'entraînement — ce sont chaque prompt, chaque document récupéré dans un pipeline RAG, chaque sortie du modèle et chaque entrée de journal capturée par votre pile d'observabilité. Une analyse du lieu de traitement doit tracer toute la chaîne : le point de terminaison d'inférence, le service d'embedding/base vectorielle si vous utilisez du RAG, le fournisseur de journalisation/observabilité, et tout service tiers de fine-tuning ou d'évaluation. Chacun est un sous-traitant potentiel avec sa propre juridiction, et l'article 28 du RGPD exige un contrat de sous-traitance pour chacun.

Les entreprises évaluant la préparation SOC 2 et ISO 27001 pour les déploiements LLM auto-hébergés reconnaîtront ce schéma — la préparation aux audits et l'analyse de souveraineté des données partent toutes deux de la même cartographie des sous-traitants, appliquée à des questions réglementaires différentes.

L'arrêt Schrems II de 2020 de la Cour de justice de l'Union européenne a invalidé le cadre EU-US Privacy Shield, jugeant que le droit de surveillance américain (principalement la Section 702 FISA et la portée du CLOUD Act) n'offre pas de protections « substantiellement équivalentes » au droit de l'UE pour les données personnelles accessibles aux autorités américaines. La conséquence pratique pour les acheteurs IA d'entreprise : recourir à un fournisseur IA domicilié aux États-Unis — même avec un point de terminaison hébergé dans l'UE — ne résout pas automatiquement l'exposition à l'accès légal identifiée par l'arrêt. Les clauses contractuelles types (CCT) restent un mécanisme de transfert valide après Schrems II, mais la CJUE exige des mesures techniques et organisationnelles supplémentaires lorsque le droit du pays de destination pourrait autrement contourner les protections des CCT, ainsi qu'une analyse d'impact du transfert (TIA) documentée évaluant ce risque.

Les articles 44 à 49 du RGPD sont les règles opérationnelles : l'article 44 pose le principe général selon lequel tout transfert de données personnelles vers un pays tiers doit respecter les conditions du chapitre. L'article 45 couvre les décisions d'adéquation (l'UE a jugé certains pays offrant une protection adéquate — les États-Unis ne disposent actuellement d'aucune décision d'adéquation générale, après l'invalidation du Safe Harbor puis du Privacy Shield). L'article 46 couvre les transferts soumis à des garanties appropriées, principalement les CCT. Les articles 47 à 49 couvrent les règles d'entreprise contraignantes et des dérogations étroites pour des situations spécifiques.

Ce que les acheteurs IA d'entreprise manquent le plus souvent : ces règles s'appliquent à *tout* transfert de données personnelles hors de l'UE/EEE, pas seulement aux exports en masse. Un simple appel API envoyant le ticket support d'un client UE vers un point de terminaison d'inférence hébergé aux États-Unis constitue un transfert relevant des articles 44-49, même si la réponse revient en millisecondes et que rien n'est « stocké » au sens traditionnel. Il en va de même pour la télémétrie, les journaux d'erreur et les événements analytiques qui incluent des données personnelles et sont envoyés vers une plateforme d'observabilité hors UE.

Pour comparer des fournisseurs de modèles spécifiques sur exactement ce profil de risque, voir la comparaison des risques RGPD entre Qwen, DeepSeek, Llama et Claude — cet article évalue des choix de modèles/API individuels ; celui-ci se concentre sur la question architecturale de déploiement qui les précède.

Trois schémas d'architecture couvrent la plupart des options d'entreprise. Aucun n'est automatiquement « conforme » — chacun modifie les sous-traitants et juridictions concernés, ce que votre DPO doit précisément évaluer.

Une multinationale déployant l'IA d'entreprise fait face à un choix structurel qui n'a rien à voir avec la qualité du modèle : les données personnelles de chaque région sont-elles traitées par un cluster d'inférence physiquement et légalement situé dans cette région, ou tout est-il acheminé vers un cluster centralisé unique (généralement là où se trouve l'équipe plateforme IA de l'entreprise) ?

Un cluster centralisé est opérationnellement plus simple — un déploiement à maintenir, une version de modèle, une pile d'observabilité. Mais les données personnelles de chaque région franchissent une frontière dès qu'elles atteignent l'API, ce qui place directement les données originaires de l'UE circulant vers un cluster hors UE sous les articles 44-49 du RGPD, et sous des régimes équivalents ailleurs (LGPD au Brésil, PDPL en Arabie saoudite et aux Émirats arabes unis). Chacun de ces flux transfrontaliers nécessite son propre mécanisme de transfert validé et sa propre TIA — et ce mécanisme doit tenir si le statut d'adéquation d'une juridiction ou le paysage législatif de surveillance change, ce qui s'est déjà produit une fois avec le Privacy Shield.

Une architecture par région — un cluster UE pour les données personnelles UE, un cluster US pour les données US, etc. — échange la simplicité opérationnelle contre une empreinte transfrontalière nettement réduite : seuls les cas d'usage véritablement transrégionaux (un ticket support mondial impliquant plusieurs équipes régionales, par exemple) nécessitent un mécanisme de transfert, pas le flux par défaut de chaque requête. Pour la plupart des multinationales traitant une catégorie de données significativement réglementée (données personnelles clients, données employés, données de santé ou financières), c'est l'option par défaut la plus sûre, même si elle coûte plus cher en infrastructure et en exploitation.

Les entreprises exploitant déjà des déploiements régionaux pour d'autres juridictions reconnaîtront la même logique dans les analyses PDPL équivalentes pour l'Arabie saoudite et les Émirats arabes unis, ou le guide LGPD brésilien — le cas UE/RGPD dispose simplement du corpus de jurisprudence et d'application le plus dense (Schrems I et II).

Suivez ces étapes dans l'ordre — chacune réduit les options de déploiement viables avant même d'arriver à la sélection du fournisseur.

Si héberger son propre matériel représente plus de charge opérationnelle que votre équipe ne souhaite en assumer, plusieurs fournisseurs domiciliés dans l'UE proposent une infrastructure GPU managée sous juridiction UE avec un DPA de droit UE par défaut. Ceci n'est pas une évaluation exhaustive des fournisseurs — vérifiez directement les tarifs actuels, certifications et conditions du DPA avant de vous engager, et consultez la comparaison complète des GPU cloud UE pour un détail approfondi des prix et fonctionnalités de sept fournisseurs.

Cet article explique des concepts généraux de souveraineté des données et de transfert transfrontalier RGPD à des fins de planification du déploiement IA. Ce n'est pas une évaluation de conformité pour votre organisation, et aucun modèle de déploiement décrit ici — auto-hébergé, cloud région UE ou cloud souverain UE — n'est « conforme au RGPD » de façon générale. La conformité dépend de vos activités de traitement précises, de votre base légale, de votre chaîne de sous-traitants, de votre AIPD et de votre évaluation des risques, que seul votre délégué à la protection des données ou un conseil juridique qualifié peut évaluer pour votre organisation. Consultez-les avant de prendre des décisions de déploiement fondées sur ce contenu.