La localisation des données en 2026 : ce que les régulateurs attendent désormais de ton cloud, et comment le prouver

Demande à une équipe de conformité où se trouvent les données de leurs clients de l’UE, et la plupart te montreront avec assurance un tableau de bord indiquant la région de Francfort ou de Dublin. Demande à leur conseiller juridique si ces données sont hors de portée d’une demande d’un gouvernement étranger, et leur assurance s’effrite généralement. 

Ce sont deux questions différentes. Depuis le 12 septembre 2025, il existe une obligation européenne qui porte sur la seconde question plutôt que sur la première.

Pourquoi la résidence et la souveraineté ne font plus partie du même débat

Point clé : la résidence des données signifie que tes données sont stockées dans une zone géographique définie. La souveraineté des données signifie que ces données sont soumises aux lois du lieu où elles se trouvent, y compris en ce qui concerne les personnes légalement habilitées à en exiger l’accès. Une organisation peut satisfaire pleinement à la première exigence tout en restant exposée sur la seconde.

Cette distinction est importante, car c’est précisément là-dessus que se concentrent de plus en plus les audits et les contrôles réglementaires. Comme l’article 18 U.S.C. 2713, ajouté par le CLOUD Act américain, supprime l’exception d’extraterritorialité face aux procédures judiciaires américaines, un fournisseur de services de communication électronique ou d’informatique à distance soumis à la juridiction américaine doit répondre des données en sa possession, sous sa garde ou sous son contrôle, quel que soit l’emplacement des serveurs ; héberger des données dans une région de l’UE ne le protège donc pas automatiquement des demandes judiciaires américaines. 

Les régulateurs de plusieurs autorités de protection des données de l’UE ont déjà constaté que certains accords américains relatifs au cloud étaient en contradiction avec le RGPD précisément pour cette raison : l’autorité autrichienne de protection des données a estimé, dans une décision partielle rendue en décembre 2021 et publiée le mois suivant, que l’utilisation continue d’un outil d’analyse hébergé aux États-Unis enfreignait les exigences du RGPD en matière d’exportation de données, et la CNIL française est parvenue à la même conclusion le mois d’après ; ces deux décisions faisaient suite aux 101 plaintes déposées par noyb dans toute l’UE et l’EEE en août 2020, quelques semaines après que l’arrêt Schrems II eut invalidé l’ancien cadre de transfert UE-États-Unis. 

Ces deux décisions sont antérieures à la décision d’adéquation relative au cadre de protection des données UE-États-Unis de juillet 2023, qui est en vigueur et modifie considérablement l’analyse lorsque l’importateur est certifié DPF. Le Tribunal a rejeté le recours de Latombe en septembre 2025, et un appel est en cours ; le cadre reste donc en vigueur pour l’instant sans être définitivement tranché.

Il ne s’agit pas d’une préoccupation hypothétique à laquelle les régulateurs pourraient finir par s’attaquer. C’est une distinction bien réelle qui donne naissance à de nouvelles catégories de produits (les régions de cloud souverain proposées par les grands fournisseurs), à de nouveaux programmes nationaux (le dispositif de qualification « SecNumCloud » de l’ANSSI en France, les accords sur le cloud pour le secteur public en Allemagne) et à une évolution mesurable des dépenses des entreprises. 

Lis bien ça : plusieurs d’entre elles sont des entités européennes exploitant la technologie de fournisseurs américains sous supervision nationale, ce qui améliore le contrôle opérationnel sans pour autant lever la question de la juridiction. 

Selon Gartner, les dépenses mondiales en IaaS de cloud souverain devraient atteindre 80 milliards de dollars en 2026, soit une hausse de 35,6 % par rapport à 2025, les secteurs réglementés et les organismes gérant des infrastructures critiques figurant parmi les principaux acheteurs, juste derrière les pouvoirs publics eux-mêmes. En Europe plus précisément, les dépenses en IaaS de cloud souverain devraient passer de 6,9 milliards de dollars en 2025 à 12,6 milliards en 2026, pour atteindre 23,1 milliards d’ici 2027. 

Ce n’est pas juste un poste de budget de conformité de niche. C’est une réaffectation structurelle des dépenses d’infrastructure des entreprises, motivée précisément par ce fossé entre « résidence » et « souveraineté » que la plupart des programmes de conformité n’ont pas encore comblé.

Ce qui a réellement changé dans les attentes réglementaires

Point clé : trois axes réglementaires distincts – la protection des données, la résilience opérationnelle et la cybersécurité – ont convergé vers la même exigence fondamentale : prouver que ta gouvernance des données résiste à un examen minutieux, et pas seulement la décrire dans un document de politique.

• L’application du RGPD s’est renforcée en matière de transparence et de transferts transfrontaliers, et ne se limite plus au simple lieu de stockage. Le règlement reste la référence en matière de protection des données dans l’UE, mais depuis l’arrêt Schrems II, la question pratique de la conformité n’est plus seulement liée à la localisation géographique : il s’agit désormais d’évaluer quelle autorité juridique régit le prestataire et de vérifier si des mesures de protection techniques empêchent l’accès des gouvernements étrangers tout au long du cycle de vie des données. Les clauses contractuelles types ne sont plus considérées comme suffisantes à elles seules si le cadre juridique du pays d’origine du prestataire autorise un accès qui l’emporte sur ces engagements contractuels.
• La loi européenne sur les données ajoute une exigence spécifique et applicable à une catégorie bien définie de données. À partir de septembre 2025, le chapitre VII de la loi européenne sur les données exigera des prestataires de services de traitement de données, quel que soit leur lieu d’établissement, dès lors qu’ils fournissent des services à des clients dans l’Union, qu’ils prennent toutes les mesures techniques, organisationnelles et juridiques adéquates, y compris par voie contractuelle, pour empêcher l’accès et le transfert par des gouvernements de pays tiers de données non personnelles détenues dans l’Union lorsque cet accès serait contraire au droit de l’UE ou des États membres — une protection qui vient s’ajouter à, et est conçue différemment de celle déjà prévue par l’article 48 du RGPD pour les données à caractère personnel. Ça transforme une préoccupation de souveraineté, auparavant abstraite, en une obligation concrète pour les prestataires, même si les organisations doivent classer correctement leurs données comme personnelles ou non personnelles pour savoir quelle protection s’applique réellement.
• La directive NIS2 étend ces exigences au-delà de la protection des données pour englober la cybersécurité opérationnelle. La date limite de transposition était le 17 octobre 2024, mais la transposition n’est pas encore achevée : en juillet 2026, la Commission a saisi la Cour de justice contre l’Irlande, l’Espagne, la France et les Pays-Bas pour ne pas avoir notifié leurs mesures nationales. Là où elle a été transposée, la directive NIS2 impose des mesures de gestion des risques liés à la cybersécurité, donne aux autorités compétentes le pouvoir d’exiger des audits de sécurité indépendants auprès des entités essentielles, et impose un système de signalement des incidents en plusieurs étapes : une alerte précoce dans les 24 heures suivant la prise de connaissance d’un incident significatif, une notification plus complète dans les 72 heures, et un rapport final dans le mois suivant cette notification. C’est un levier réglementaire différent de celui du RGPD, mais qui va dans le même sens : un contrôle démontrable et vérifiable de ton infrastructure et de la façon dont elle réagit aux incidents.
• La loi DORA (Digital Operational Resilience Act de l’UE) ajoute un niveau de résilience et d’audit spécifique aux entités financières. En vigueur depuis janvier 2025, elle oblige les entités financières à disposer de droits contractuels d’audit et d’accès sur leurs fournisseurs de TIC et confère aux autorités européennes de surveillance des pouvoirs d’inspection directs sur les fournisseurs qu’elles désignent comme critiques, au nombre de 19 en novembre 2025. L’article 30 impose également des clauses contractuelles obligatoires aux prestataires TIC de tous les secteurs dès qu’une entité financière devient cliente.
• Le Royaume-Uni suit la même voie de son côté, et avance rapidement. Le projet de loi sur la cybersécurité et la résilience a été adopté par la Chambre des communes en juin 2026 et est actuellement examiné par la Chambre des lords ; la sanction royale est attendue plus tard cette année et sa mise en œuvre progressive s’étalera jusqu’en 2028. Il étend les obligations de type NIS aux fournisseurs de services gérés, aux centres de données et aux fournisseurs critiques, ce qui signifie que le niveau d’exigence réglementaire au Royaume-Uni augmente même en dehors des cadres spécifiques de l’UE.

Prises individuellement, il s’agit de voies réglementaires distinctes avec des champs d’application différents. Mais ensemble, elles aboutissent à la même exigence organisationnelle : la capacité de démontrer, et pas seulement d’affirmer, où se trouvent les données, qui peut y accéder et en vertu de quelle autorité légale.

Pourquoi le choix de la région relève désormais d’une décision de gouvernance

Point clé : avant, choisir où exécuter une charge de travail, c’était surtout une question de latence et de coût. Aujourd’hui, c’est une décision de conformité qui doit s’accompagner d’une justification solide.

Pendant la majeure partie de la dernière décennie, le choix de la région relevait de considérations opérationnelles : on choisissait la région la plus proche de ses utilisateurs, ou celle proposant les meilleurs tarifs pour sa charge de travail. Ce calcul n’a pas disparu, mais il ne suffit plus à lui seul. 

Un régulateur ou un auditeur qui s’enquiert des données d’un client spécifique s’attend désormais à une réponse précise et justifiable : quelle région, sous la juridiction de quel fournisseur, et quelles mesures de protection sont en place en cas de transfert transfrontalier de données lors du traitement, de la sauvegarde ou de l’accès à l’assistance.

C’est plus compliqué qu’il n’y paraît pour la plupart des entreprises utilisant plusieurs clouds et plusieurs fournisseurs, car le choix de la région se fait souvent au niveau de l’infrastructure : il est décidé une fois pour toutes par la personne qui a mis en place un service donné, et rarement revu à moins d’un dysfonctionnement. 

La question de la conformité, en revanche, nécessite une réponse valable pour chaque charge de travail, chaque segment de clientèle et chaque réglementation applicable, ce qui représente un niveau de granularité fondamentalement différent de celui pour lequel la plupart des décisions d’infrastructure ont été conçues.

Ce qu’il faut vraiment pour le prouver

Point clé : Démontrer la conformité aux exigences de résidence et de souveraineté, c’est pouvoir montrer, à la demande, où se trouvent les données d’une charge de travail donnée, quel cadre réglementaire s’applique et quels contrôles de gouvernance garantissent ce placement, et pas seulement décrire la politique censée le faire.

Les organisations capables de répondre rapidement à une question de résidence ou de souveraineté partagent une caractéristique spécifique : leur choix de région est accessible et vérifiable dans l’état de déploiement, avec une période de conservation couvrant la fenêtre d’audit, et n’est pas conservé sous la forme d’un document de politique séparé qu’il faut comparer à la réalité quand quelqu’un pose la question. 

Quand la région d’une charge de travail est accessible à partir de l’état de déploiement via une API plutôt que déclarée dans un document de politique, la réponse à la question « où se trouvent ces données ? » est une requête sur l’état de déploiement réel, et non un document dont quelqu’un doit vérifier l’exactitude.

C’est de plus en plus important, en particulier pour les organisations multi-régions et multi-cloud. Déployer sur des régions AWS, Azure, Google Cloud, IBM ou OVHcloud pour répondre à l’exigence de résidence d’un client spécifique ne constitue une réponse de gouvernance valable que si l’attribution des régions est cohérente, vérifiable et ne dérive pas silencieusement lorsque l’infrastructure change. 

Une organisation capable de démontrer cela, région par région, charge de travail par charge de travail, répond à une question fondamentalement différente (et bien plus solide) que celle qui se contente de renvoyer à une politique générale de résidence des données en espérant que l’infrastructure sous-jacente y corresponde toujours.

Une première étape utile : prends la charge de travail contenant tes données les plus réglementées et essaie d’en fournir quatre éléments. Où elle est déployée, en te basant sur l’état de déploiement plutôt que sur un document, et conservée pendant une période couvrant ta fenêtre d’audit. Qui l’a modifiée et quand. Quels sous-traitants traitent ces données, y compris les sauvegardes, les journaux, les outils d’assistance et tout point de terminaison d’inférence. Et si ces données sont à caractère personnel ou non. Tout ce que tu ne peux pas fournir constitue une anomalie.

Lance l'évaluation de la conformité au cloud 

Foire aux questions (FAQ)

Quelle est la différence concrète entre la résidence des données et la souveraineté des données ? La résidence des 
données signifie que tes données sont physiquement stockées dans une zone géographique définie, comme l’UE. La souveraineté des données signifie que les données sont soumises à l’autorité juridique de cette juridiction tout au long de leur cycle de vie, y compris en ce qui concerne les personnes autorisées à en exiger l’accès. Une organisation peut atteindre une résidence totale (données stockées à Francfort) tout en restant exposée en matière de souveraineté si le fournisseur de services est soumis à la juridiction américaine et à la norme de « possession, garde ou contrôle » du CLOUD Act américain. Pour combler ce déficit de souveraineté, il faut généralement un fournisseur opérationnellement indépendant et non contrôlé par les États-Unis, ou des contrôles architecturaux tels que des clés de chiffrement gérées par le client. Note bien la limite de cette deuxième option : la garde des clés est utile pour les données au repos et en transit, mais ne sert à rien lorsque la plateforme a besoin des données en clair pour faire fonctionner ton application, ce qui est le cas pour la plupart des plateformes d’applications.

Le fait de choisir une région de l’UE garantit-il automatiquement le respect du RGPD ? 
Ça répond à l’exigence de résidence, mais la conformité au RGPD va au-delà du simple lieu de stockage. Elle nécessite un mécanisme juridique de transfert pour toutes les données qui franchissent les frontières (comme les clauses contractuelles types ou une décision d’adéquation), des garanties techniques appropriées et des registres précis des activités de traitement, y compris les flux de données de support et de télémétrie qui sont souvent négligés dans une évaluation axée uniquement sur la résidence.

La directive DORA s’applique-t-elle en dehors du secteur financier ? 
Oui, si tu fournis ces services. La directive DORA s’applique aux entités financières opérant dans l’UE et à leurs fournisseurs de TIC critiques, et l’article 30 impose des clauses contractuelles obligatoires aux fournisseurs de TIC de tous les secteurs dès qu’une entité financière devient cliente, couvrant les droits d’audit, les plans de sortie, la sous-traitance et le signalement des incidents. L’inspection directe par les autorités de surveillance ne s’applique qu’aux fournisseurs désignés comme critiques par les autorités européennes de surveillance. Cependant, son exigence fondamentale – une résilience opérationnelle démontrable et l’accès des régulateurs aux systèmes concernés – est un modèle qui s’étend à d’autres cadres réglementaires comme la directive NIS2 et le projet de loi britannique sur la cybersécurité et la résilience. Les organisations hors du secteur des services financiers devraient considérer les exigences de la DORA comme un indicateur de l’orientation que prennent les attentes réglementaires plus larges.

Comment le déploiement multicloud ou multirégional affecte-t-il la conformité en matière de résidence des données ? 
Ça peut aider ou nuire, selon que l’affectation des régions est appliquée de manière cohérente. Le déploiement multirégional permet à une organisation de répondre à différentes exigences de résidence pour différents segments de clientèle ou juridictions, ce qui est un véritable avantage. Mais cela ne constitue une solution de conformité que si l’affectation régionale de chaque charge de travail est documentée, vérifiable et qu’il n’y a pas de décalage entre ce qui est déclaré et ce qui est réellement déployé. Sans cette cohérence, le déploiement multirégional ajoute de la complexité sans combler le déficit de conformité.

La loi européenne sur les données protège-t-elle aussi les données à caractère personnel contre l’accès des gouvernements étrangers ? 
Le chapitre VII de la loi sur les données traite spécifiquement des données non personnelles. Les données à caractère personnel sont régies par une disposition différente de l’article 48 du RGPD, qui limite la reconnaissance des décisions de tribunaux ou d’autorités étrangères exigeant le transfert de données à caractère personnel en l’absence d’un accord international valide. Le CEPD a clairement indiqué dans ses lignes directrices 02/2024 que l’article 48 ne constitue pas en soi un motif de transfert, et cet article se termine par les mots «sans préjudice des autres motifs de transfert prévus au chapitre V» ; il ne fait donc pas office de disposition bloquante. Il traite également des assignations signifiées à l’entité de l’UE, mais n’apporte guère de réponse lorsque la contrainte s’exerce à l’encontre d’une société mère située en dehors de l’UE. En pratique, ça veut dire que les organisations doivent classer correctement un ensemble de données donné comme « personnel » ou « non personnel » pour savoir quelle protection contre la contrainte s’applique réellement à celui-ci. Cette distinction est importante, car les deux régimes se recoupent plutôt que de s’exclure mutuellement. Lorsque les données personnelles et non personnelles sont indissociables, le RGPD régit l’ensemble des données, tandis que l’article 32 continue d’imposer des obligations à ton fournisseur pour la partie non personnelle.

Que doit donc vérifier en premier lieu un responsable informatique ? 
Commence par vérifier si l’affectation régionale de chaque charge de travail est déclarée de manière à pouvoir être interrogée et vérifiée, plutôt que d’être définie une fois pour toutes et considérée comme toujours exacte. À partir de là, identifie quels cadres réglementaires s’appliquent réellement à quelles charges de travail et à quels segments de clientèle, car le RGPD, la DORA et la directive NIS2 ont des champs d’application différents et des exigences spécifiques différentes. L’écart entre la conformité supposée et la conformité démontrable se trouve généralement dans cet exercice de cartographie, et non dans l’infrastructure sous-jacente elle-même.