"Nos données restent au Brésil" est l'une des phrases les plus répétées dans les contrats technologiques et la plus rarement vérifiée dans la pratique. La déclaration semble objective : soit les serveurs sont ici, soit ils sont ailleurs. Mais le concept de résidence des données est techniquement plus complexe que l'emplacement physique d'un centre de données, et la différence entre ce que les contrats garantissent et ce qui se passe dans l'infrastructure est là où se posent la plupart des problèmes de conformité.
Ce que signifie réellement la résidence des données sur le plan technique
La résidence des données comporte trois dimensions distinctes qui sont rarement traitées séparément. Le premier est l’endroit où les données sont stockées au repos, c’est-à-dire l’endroit où résident physiquement les fichiers, les enregistrements de base de données et les objets de stockage. Le deuxième est l'endroit où les données sont traitées : les serveurs d'applications qui exécutent des requêtes, des transformations et des analyses peuvent se trouver à un emplacement différent de celui des données qu'ils manipulent. Le troisième, souvent négligé, concerne l'endroit où se trouvent les métadonnées : index, journaux d'accès, données de configuration et journaux d'audit qui décrivent les données de base.
La plupart des accords de résidence de données ne couvrent que la première dimension. Une entreprise peut stocker des données de production dans la région sud du Brésil d'un fournisseur de cloud et, en même temps, faire envoyer automatiquement les journaux d'accès à ces données à une région des États-Unis, lire des répliques pour les performances créées dans d'autres régions ou des pipelines d'analyse qui déplacent les données pour les traiter dans une infrastructure mondiale.
Le traitement des données est particulièrement problématique. Lorsqu'un utilisateur au Brésil effectue une recherche et que la requête est envoyée à un moteur de recherche mondial distribué, où ce traitement a-t-il lieu ? Lorsqu'un modèle d'apprentissage automatique formé aux États-Unis fait des déductions à partir de données brésiliennes, où se trouvent les données à ce moment-là ? Les réponses dépendent de l’architecture spécifique de chaque système et sont rarement précisées dans les contrats de service standards.
Comment les grands fournisseurs de cloud abordent le sujet
AWS propose la région sa-east-1 à São Paulo depuis 2011, avec un large catalogue de services disponibles localement. La promesse de résidence des données d'AWS est que les données stockées dans une région ne sont pas déplacées en dehors de celle-ci sans action explicite du client. Cela couvre le stockage principal, la base de données gérée et le calcul. Ce qui n'est pas automatiquement inclus : les journaux AWS CloudTrail peuvent être configurés pour être envoyés à différentes régions, le support technique AWS peut être fourni par des ingénieurs d'autres régions ayant accès aux environnements clients, et les services mondiaux tels qu'AWS IAM et Route 53 disposent d'une infrastructure de contrôle qui n'est pas régionale.
Microsoft avec Azure Brazil South à São Paulo offre des garanties similaires pour les services de base, mais avec un catalogue plus petit que celui des régions plus anciennes : certains services disponibles aux États-Unis ou en Europe ne sont pas disponibles dans la région brésilienne, ce qui peut obliger à des architectures hybrides qui contredisent les exigences de résidence. Oracle Cloud avec une région à Vinhedo, São Paulo, est une option pertinente, en particulier pour les charges de travail Oracle Database soumises à des exigences réglementaires.
Ce que tous les fournisseurs ont en commun : les sauvegardes géographiques sont une fonctionnalité qui nécessite souvent une configuration explicite pour rester dans le pays. La réplication automatique pour garantir la durabilité des données peut par défaut distribuer des copies entre les régions de différents pays. La vérification de la configuration de réplication par défaut avant de supposer que les données sont contenues relève de la responsabilité du client.
Les exceptions que les contrats mentionnent rarement
L’accès au support est l’exception la plus significative. Lorsqu'une entreprise ouvre un ticket d'assistance technique avec AWS, Azure ou Google Cloud, l'ingénieur qui répond peut se trouver n'importe où dans le monde et peut avoir besoin d'accéder à l'environnement du client pour diagnostiquer le problème. Les fournisseurs disposent de contrôles pour limiter cet accès, mais la valeur par défaut n'est pas un accès nul. Le système AWS Nitro et Azure Customer Lockbox sont des exemples de mécanismes qui permettent aux clients de contrôler quand et par qui leur environnement est accessible, mais ils doivent être activés et compris.
Les journaux de conformité et d’audit constituent un autre angle mort fréquent. Les outils SIEM (Security Information and Event Management) et les plateformes de surveillance qui regroupent les journaux de plusieurs régions ont souvent leur infrastructure de stockage dans des régions où le service est moins cher ou a plus de capacité. Le client configure l'agent de collecte dans la région brésilienne, mais les données du journal finissent par être stockées dans un autre pays.
Les services CDN et edge computing, par définition, distribuent des données à proximité des utilisateurs dans le monde entier. Si une entreprise utilise CloudFront, Azure CDN ou Fastly pour distribuer du contenu, des parties de ce contenu (y compris potentiellement les données utilisateur mises en cache) peuvent exister temporairement sur des serveurs dans d'autres pays. Pour la plupart des types de données, cela est acceptable, mais pour les données personnelles sensibles, cela nécessite une analyse spécifique.
Que demander aux fournisseurs avant de signer
La diligence raisonnable concernant la résidence des données auprès des fournisseurs commence par des questions spécifiques, et non par la confirmation que « les données restent au Brésil ». Les questions importantes sont les suivantes : où sont stockées les sauvegardes et les répliques par défaut, et peuvent-elles être configurées pour rester au Brésil ? Quelles régions sont utilisées pour le traitement des données d’analyse et d’apprentissage automatique ? Quels employés ont un accès technique à l’environnement et d’où opèrent-ils ? Où sont stockés les journaux d’audit ? Existe-t-il des services d'assistance, des outils de diagnostic ou des pipelines de télémétrie qui envoient des données à des infrastructures en dehors du Brésil ?
Les fournisseurs qui ne peuvent pas répondre à ces questions avec précision n'ont pas de véritable résidence de données : ils ont un marketing de résidence de données. La distinction est importante car elle impacte directement la capacité à démontrer la conformité en cas d'inspection par l'ANPD ou par les clients qui exigent une preuve.
Une stratégie pratique pour ceux qui ont besoin d'obtenir une véritable résidence
La première étape est un inventaire des flux de données : une cartographie de la destination de chaque catégorie de données après son entrée dans l'environnement. Pas seulement là où ils sont initialement stockés, mais aussi là où ils circulent via les intégrations, les réplications, les pipelines d’analyse et les outils tiers. Ce mappage révèle souvent des points de sortie de données qui n'étaient pas pris en compte dans l'architecture d'origine.
La deuxième étape consiste à revoir les paramètres par défaut de chaque service utilisé. Les fournisseurs de cloud vous permettent souvent de configurer la résidence des données de manière granulaire, mais les paramètres par défaut sont optimisés pour une disponibilité mondiale et non pour une conformité locale. La différence entre ce que le service peut faire et ce pour quoi il est configuré est le point où la plupart des projets de résidence de données échouent.
La troisième étape, et la plus souvent ignorée, consiste à créer un processus de vérification continue. Les environnements cloud changent. De nouveaux services sont ajoutés, les intégrations sont configurées par différentes équipes et les paramètres de résidence des données peuvent être accidentellement modifiés. La surveillance automatique des politiques d'emplacement des données, disponible via les outils AWS Config, Azure Policy ou CSPM, transforme la résidence des données d'un instantané en une assurance durable.
A lire aussi
- LGPD deux ans après : ce qui a vraiment changé dans les entreprises brésiliennes
- Souveraineté numérique : quand le lieu où vivent vos données devient une décision stratégique
- LGPD en 2026 : ce qui a changé, ce qui n'est pas encore respecté et ce qui s'en vient
- Conformité numérique : comparaison en pratique
- LGPD dans les startups : stratégies de conformité et de protection des données
- Conformité numérique : Guide de conformité pour les produits numériques