Data residency et transferts transfrontaliers dans les applications multi-tenant

Un mail des achats arrive un mardi : « Nos données doivent rester dans l'UE en permanence, backups compris. » L'architecture du vendeur SaaS, un unique cluster Postgres hébergé aux États-Unis qui sert tous les tenants, sauvegardé chaque nuit en Virginie, ne peut pas honorer cette phrase telle qu'elle est écrite. Les sales veulent signer. L'engineering doit déterminer ce que « dans l'UE » signifie réellement pour le sharding, les backups, les logs et chaque subprocessor qui touche ces données. C'est le problème de la residency, et il frappe toutes les entreprises SaaS multi-tenant dès qu'elles décrochent leur premier vrai logo enterprise européen (ou indien, ou saoudien, ou brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ésilien).

Ce que « data residencydata residencyL'exigence de stocker et traiter les données physiquement dans un pays ou une région précise, souvent pour des raisons légales ou contractuelles.Voir la définition complète → » veut vraiment dire

La data residency est une exigence (contractuelle, parfois légale) selon laquelle les données appartenant à un client restent stockées à l'intérieur d'une frontière géographique ou juridictionnelle donnée.

La data sovereignty est une idée voisine, plus forte : les données sont soumises aux lois du pays où elles se trouvent, quel que soit le siège de l'entreprise qui les détient. Les données d'un hôpital français stockées sur un serveur cloud détenu par une société américaine, même physiquement situé à Francfort, peuvent en théorie être atteintes par les autorités américaines au titre du CLOUD Act (2018), qui leur permet de contraindre les fournisseurs basés aux États-Unis à livrer les données qu'ils contrôlent, où qu'elles soient stockées. C'est précisément pour cela que les régulateurs européens ont poussé les offres de « cloud souverain ».

Le transfert transfrontalier de données est l'acte de déplacer des données personnelles d'une juridiction à une autre, distinct de la residency mais étroitement lié, puisqu'une promesse de residency est en réalité une promesse de contrôler les transferts.

Ces trois termes sont utilisés indifféremment dans les conversations commerciales. Ce ne sont pas la même chose, et c'est en les confondant que les équipes d'engineering en font trop ou pas assez.

Les ancrages réglementaires

Le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données, UE, applicable depuis 2018) est la référence. Il n'exige pas que les données européennes restent physiquement dans l'UE. Son chapitre V restreint en revanche les *transferts* de données personnelles vers des pays hors UE/EEE, sauf si l'un de ces cas s'applique :

• Une décision d'adéquation : la Commission européenne a estimé que les lois du pays de destination offrent une protection comparable (exemples : Royaume-Uni, Japon, Corée du Sud et, depuis 2023, les États-Unis via l'EU-US Data Privacy Framework).
• Les clauses contractuelles types (SCC) : des modèles de contrat pré-approuvés entre exportateur et importateur, le mécanisme le plus courant pour les vendeurs SaaS basés aux États-Unis.
• Les règles d'entreprise contraignantes (BCR) : des règles internes applicables à l'ensemble d'un groupe pour les transferts multinationaux.

Le framework UE-États-Unis compte parce qu'il a remplacé deux dispositifs antérieurs invalidés par la Cour de justice de l'Union européenne : le Safe Harbor (invalidé en 2015) et le Privacy Shield (invalidé en 2020, l'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt « Schrems II », après que l'activiste autrichien Max Schrems a contesté le mécanisme de transfert de Facebook). Chaque invalidation a forcé des milliers de vendeurs SaaS à trouver une nouvelle couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → juridique presque du jour au lendemain. Cet historique explique que les acheteurs enterprise interrogent aujourd'hui explicitement les mécanismes de transfert dans les questionnaires de sécurité, et pas seulement comme une case à cocher.

Autres régimes à connaître par leur nom :

• La PIPL chinoise (Personal Information Protection Law, 2021) impose des évaluations de sécurité pour les transferts transfrontaliers de « données importantes » et un stockage local pour certains opérateurs.
• Le DPDP Act indien (Digital Personal Data Protection Act, 2023) permet au gouvernement de restreindre les transferts vers des pays désignés selon une logique de liste noire.
• Schrems II n'a pas interdit les transferts, mais il a imposé aux exportateurs d'évaluer, au cas par cas, si les lois de surveillance du pays de destination fragilisent les protections des SCC, une étape appelée Transfer Impact Assessment (TIA).

Pour le texte de référence, les orientations de l'EDPB (Comité européen de la protection des données) sur les outils de transfert constituent la source gratuite et autoritaire, plutôt que le blog d'un vendeur.

Ce que cela change dans le produit, pas seulement dans le contrat

Les sales peuvent promettre la residency ; seule l'architecture peut la livrer. Quatre changements concrets traversent la stack.

1. Sharding par région. Les applications SaaS multi-tenant stockent généralement tous les tenants sur une infrastructure partagée, par souci de coût. La residency exige des shards par région : un shard UE (par exemple AWS eu-central-1, Francfort) qui ne contient que les données des tenants européens, avec une logique applicative qui route les lectures et écritures de chaque tenant vers le bon shard. C'est un vrai projet d'engineering, pas un flag de configuration, surtout pour une application bâtie dès le premier jour sur une base de données globale unique.

2. Backups et reprise d'activité. Un backup répliqué entre régions pour la résilience devient une violation de conformité s'il atterrit hors de la frontière promise. Les vendeurs doivent soit limiter la réplication des backups à des installations in-region (en acceptant une reprise d'activité moins robuste), soit recourir à des schémas de chiffrement où seules des clés in-region peuvent déchiffrer, ce qui démontre aux auditeurs que les données sont *effectivement* inaccessibles ailleurs, même si des octets franchissent transitoirement une frontière.

3. Logs, métriques et outillage de support. C'est là que les équipes se font prendre. Les logs applicatifs, les traces d'erreur (Sentry par exemple), les tickets de support client (Zendesk par exemple) et les pipelines analytics envoient souvent, discrètement, des données clients vers des outils SaaS américains. Un engagement de residency qui n'audite pas ces flux secondaires n'est pas un vrai engagement.

4. Contrats de subprocessors. Au sens du RGPD, un subprocessor est tout tiers auquel le vendeur (le « sous-traitant ») recourt pour traiter des données personnelles pour le compte du client (le « responsable de traitement »). Les hébergeurs cloud, les services d'envoi d'emails, les plateformes de support client, et même les APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → de modèles d'IA, sont des subprocessors. L'article 28 du RGPD oblige les sous-traitants à répercuter des obligations de protection des données équivalentes sur chaque subprocessor, et à communiquer la liste des subprocessors aux clients. Les contrats enterprise incluent désormais couramment un droit d'objection aux nouveaux subprocessors et un délai de préavis obligatoire (typiquement 30 jours, en estimation de la pratique courante du marché) avant d'en ajouter un.

Une illustration concrète de la chaîne : un vendeur SaaS intègre l'API d'OpenAI pour une fonctionnalité d'IA. OpenAI devient un subprocessor. Si le traitement des données par OpenAI se fait sur une infrastructure américaine, chaque contrat client européen promettant une residency 100 % UE est techniquement rompu, sauf si le vendeur utilise les options de data residency UE d'OpenAI ou un modèle alternatif hébergé dans l'UE.

Une illustration technique minimale

Un routage région-aware commence en général par une table de correspondance tenant-région, consultée avant toute requête touchant des données clients :

-- tenant_region_map : une ligne par tenant, définie à l'inscription
SELECT region_endpoint
FROM tenant_region_map
WHERE tenant_id = :current_tenant;

-- la couche applicative se connecte ensuite au
-- cluster de base de données spécifique à la région, par ex. :
-- eu-central-1.db.internal  OU  us-east-1.db.internal

La difficulté n'est jamais ce lookup. Elle consiste à s'assurer que *chaque* service (index de recherche, cache, file de messages, log shipper) respecte la même décision de routage.

Vérifications et audits à mener

Pour une équipe de gouvernance qui évalue des affirmations de residency (celles de sa propre entreprise ou celles d'un vendeur), une checklist opérationnelle :

• Cartographie des flux de données : documenter chaque système qui stocke ou fait transiter des données personnelles, y compris le logging, l'analytics et l'outillage IA, pas seulement la base de données principale. C'est une pratique standard au titre de l'obligation de registre des traitements de l'article 30 du RGPD.
• Revue du registre des subprocessors : vérifier la liste publiée des subprocessors du vendeur (la plupart des vendeurs SaaS en publient une, par exemple via leur Trust Center) pour la région d'hébergement et le mécanisme de transfert.
• Transfer Impact Assessment au dossier : pour tout transfert fondé sur les SCC, existe-t-il un TIA documenté traitant du risque de surveillance dans le pays de destination ?
• Vérification des régions de backup et de DR : demander précisément, pas seulement « les données sont-elles chiffrées » mais « où sont stockés les backups et qui détient les clés de déchiffrement ».
• Les certifications comme signal, pas comme preuve : SOC 2 Type II (un standard d'audit américain sur les contrôles de sécurité) et ISO 27001 (une norme internationale de management de la sécurité de l'information) indiquent une maturité de processus mais ne disent rien de spécifique sur la residency. Ne les acceptez pas en substitut d'une réponse région par région.
• Droits d'audit contractuels : confirmer que le contrat client inclut le droit de demander des éléments de preuve (rapports d'audit, listes de subprocessors) plutôt que de s'appuyer sur des affirmations marketing.

🎬 [VIDEO: « GDPR Data Transfers Explained » - youtube.com - un parcours des SCC, des décisions d'adéquation et de l'après-Schrems II, destiné aux praticiens, pas aux juristes]

Points clés

• Data residency, sovereignty et transfert transfrontalier sont des concepts liés mais distincts ; les contrats les confondent souvent, alors que les décisions d'architecture exigent de la précision.
• Le RGPD n'interdit pas les transferts internationaux, il exige un mécanisme valide (décision d'adéquation, SCC ou BCR), et Schrems II a ajouté l'obligation d'évaluer au cas par cas le risque de surveillance dans le pays de destination.
• Tenir une promesse de residency touche le sharding, les backups, les logs, l'analytics et l'outillage de support, pas seulement la base de données principale ; le maillon faible est en général un système secondaire oublié.
• Tout service tiers qui touche des données clients, API d'IA incluses, est un subprocessor au sens du RGPD et doit être déclaré et lié contractuellement.
• SOC 2 et ISO 27001 sont des signaux utiles de maturité en sécurité mais ne répondent pas à la question de la residency ; demandez toujours la région précise et le mécanisme de transfert.