Résidence des données e-mail : région, juridiction, et la différence

La résidence des données est un engagement sur l’endroit où les octets de votre courrier reposent physiquement — quel pays détient les corps de message, les pièces jointes et leurs sauvegardes quand personne ne les regarde. La juridiction est une autre propriété : elle suit celui qui contrôle ce stockage, et elle peut pointer ailleurs. Un bucket à Francfort exploité par une société de droit américain a une résidence européenne et une juridiction américaine simultanément, et les deux affirmations sont vraies en même temps.

Tenir ces deux notions séparées, c’est toute la discipline. Presque toutes les conversations d’achat décevantes que j’ai vues au sujet de la messagerie venaient d’une exigence qui spécifiait l’une en croyant avoir acheté l’autre.

Qu’est-ce que la résidence des données, et en quoi diffère-t-elle de la juridiction ?

La résidence est géographique. La juridiction est capitalistique. La région est une propriété du disque ; la juridiction est une propriété de la société qui détient les identifiants pour y accéder.

Elles divergent parce que la portée du droit s’attache aux personnes morales. Un prestataire américain capable de produire techniquement une copie de votre boîte est réputé la contrôler où que se trouve le disque — c’est le principe de fonctionnement du 18 U.S.C. § 2713, ajouté par le CLOUD Act en 2018. Symétriquement, un prestataire immatriculé uniquement dans l’Union échappe à ce texte, y compris pour des données qu’il garderait sur du matériel en Virginie.

Une déclaration de résidence sérieuse a donc deux paramètres, et non un : la région qu’occupent les octets, et la société — immatriculée où — qui détient la capacité de les lire. Les fournisseurs citent le premier parce que c’est un menu déroulant. Le second est un fait de structure les concernant, et ce n’est pas quelque chose qu’ils peuvent changer pour vous.

Qu’exigent réellement les obligations de résidence des données ?

Rarement une simple région. Quand je lis les exigences réelles derrière une ligne « résidence des données dans l’UE », elles regroupent le plus souvent quatre choses : la localisation du stockage, une liste nominative des sous-traitants ultérieurs avec leurs implantations, des limites à l’accès du support à distance depuis des pays tiers, et une réponse documentée à la question des transferts.

Elles viennent d’endroits précis. La commande publique en est la principale source — administrations d’État et collectivités travaillant sous des règles antérieures au cloud, rédigées en supposant des locaux. Les secteurs régulés ajoutent leurs couches : l’attestation allemande BSI C5 pour les services cloud, la certification française HDS pour tout ce qui touche aux données de santé, les orientations de l’Autorité bancaire européenne sur l’externalisation, qui imposent aux banques de tenir un registre des lieux d’exécution de chaque fonction et de préserver leurs droits d’audit.

Le cas intéressant est le SecNumCloud français, dont la révision 3.2 a dépassé la géographie pour entrer dans la structure des sociétés : siège dans l’Union, limites au contrôle capitalistique extra-européen, immunité aux lois extra-européennes comme critère explicite. Quoi que l’on pense de cette politique, c’est le référentiel qui nomme la vraie variable. La localisation est un indicateur indirect ; le contrôle est la chose achetée.

Ce qui n’apparaît presque jamais dans ces exigences, c’est le RGPD lui-même. Le règlement autorise les transferts hors de l’EEE au titre du chapitre V, avec les bonnes garanties. « UE uniquement » est un choix de politique ajouté par-dessus, généralement parce que ces garanties sont devenues difficiles à défendre après 2020.

Pourquoi les cases « région UE » déçoivent-elles si souvent ?

Parce que la garantie est limitée à une tranche des données, et que la messagerie en produit beaucoup qui tombe en dehors de cette tranche.

Lisez les mentions détaillées de n’importe quel engagement de région d’un grand acteur et vous trouverez une catégorie définie — « contenu client » ou « données primaires au repos » — s’appliquant à une liste énumérée de services couverts. Ce qui reste dehors est prévisible : index de recherche, télémétrie du spam et des menaces, journaux de remise et d’authentification, signaux d’abus, données d’annuaire et d’identité, pièces de facturation, et chaque ticket de support où un ingénieur a collé un jeu d’en-têtes. Microsoft a passé les années 2023 à 2025 à étendre par phases sa frontière européenne des données, précisément parce que les données personnelles pseudonymisées et les données de support n’étaient pas couvertes par la première phase.

Trois autres écarts reviennent. Le choix de la région est fréquemment une option payante plutôt qu’un réglage par défaut. Les métadonnées d’administration et de locataire n’ont souvent aucune option de région. Et le support suit le soleil : une boîte à la résidence irréprochable se fait couramment dépanner depuis un fuseau horaire que l’annexe n’a jamais mentionné.

Rien de tout cela n’est une tromperie. C’est simplement une promesse plus étroite que ce que l’acheteur a entendu.

Quelles parties d’un e-mail peuvent avoir une région, et lesquelles non ?

Le stockage peut. Le transport ne peut pas. La ligne mérite d’être tracée tôt, parce qu’elle décide de ce que la résidence est même capable de protéger.

L’archive au repos — corps, pièces jointes, sauvegardes, et généralement l’index de recherche — se place réellement. Tout le reste du courrier y résiste. Le SMTP entrant traverse les réseaux qui se trouvent entre l’hôte expéditeur et votre MX, en négociant un TLS opportuniste sans que vous maîtrisiez la route. Le filtrage du spam doit lire le message : la mémoire du filtre contient donc du texte en clair quelque part. Vos correspondants gardent leurs propres copies sous leurs propres lois, et ce sera toujours le cas.

Ce n’est pas une raison de renoncer à la résidence. C’est une raison d’en parler avec précision : la résidence est une propriété de votre archive, pas de vos conversations.

Comment la garde au niveau du stockage transforme-t-elle la résidence en réglage ?

En déplaçant l’archive dans un stockage qui vous appartient — la résidence cesse alors d’être une promesse de fournisseur et devient un paramètre que vous fixez à la création du bucket.

Le stockage objet expose la région comme un choix de premier ordre : vous la choisissez, vous la voyez, vous la vérifiez par un appel d’API. La juridiction devient un second choix, indépendant : l’opérateur avec qui vous contractez et le pays où cette société est immatriculée. Même région, autre opérateur, et l’exposition juridique change complètement. Les deux molettes cessent d’être soudées l’une à l’autre.

La preuve change de nature aussi. À la place d’une assurance contractuelle affirmant que les données résident dans une région, vous avez un bucket sur votre propre compte dont vous pouvez inspecter directement le contenu, la région et les journaux d’accès. Pour un contrôleur du secteur public, c’est une autre catégorie d’élément de preuve, parce qu’elle ne dépend pas de la confiance accordée à la partie contrôlée.

Deux réserves honnêtes. La garde déplace les obligations en même temps que le contrôle : une politique de bucket permissive devient votre incident, et une sauvegarde jamais testée votre problème. Et la résidence n’est pas la confidentialité — du courrier posé dans un bucket qui vous appartient a quand même été lu par le service de routage qui l’a filtré puis écrit. Demandez où reposent les octets, puis demandez qui détient les clés. Ce sont deux questions différentes, et les réponses peuvent différer.