RGPD et hébergement cloud : pourquoi cocher une région UE ne suffit pas
Cocher une région d’hébergement UE dans la console d’un fournisseur cloud ne garantit pas, à elle seule, la conformité RGPD de votre backend. Ce réglage configure en général l’emplacement de la base de données primaire, rien de plus. Il ne dit rien des sauvegardes, des journaux techniques, des sous-traitants tiers, ni de la nationalité de la société qui exploite le service.
Ce guide détaille les angles morts que la case région laisse ouverts, avec une méthode concrète pour les vérifier vous-même, fournisseur par fournisseur. Pour le cadre RGPD et CLOUD Act complet, voir notre guide Backend conforme RGPD et souverain UE. Ici, l’angle reste pratique : qu’est-ce qui échappe réellement au sélecteur de région, et comment le vérifier en moins d’une heure.
Le sélecteur de région d’un fournisseur cloud configure en général la base primaire, pas les quatre autres couches qui déterminent l’exposition réelle : les sauvegardes et le plan de reprise, les journaux et la télémétrie, les sous-traitants tiers (support, emailing, analytics) et la nationalité de la société exploitante. Une checklist en six étapes permet de vérifier ces points à partir de documents publics : DPA, politique de confidentialité, documentation technique. Vérifié dans le dépôt de déploiement d’Aurabase : les sauvegardes de production pointent vers l’object storage Hetzner de Falkenstein, pas vers un bucket tiers situé hors UE.
Ce que la case région configure réellement
Le sélecteur de région d’un fournisseur cloud change en général une chose précise : la zone géographique où la base de données primaire stocke ses fichiers. AWS RDS en eu-west-1, Cloud SQL en europe-west1, ou l’équivalent chez un BaaS : ce réglage détermine le datacenter qui héberge les tables et les index en fonctionnement normal. C’est une information réelle et vérifiable, mais elle ne couvre qu’une fraction de la chaîne de traitement d’une donnée personnelle.
Un projet Postgres produit des données ailleurs que dans ses tables principales : journaux de requêtes, métriques de monitoring, traces de débogage, caches applicatifs, sauvegardes. Chacun de ces flux peut suivre une politique de localisation distincte de la base primaire, configurée séparément, parfois même par défaut sans écran dédié dans la console. Le réglage région ne les couvre pas automatiquement.
Une bonne pratique consiste à demander au fournisseur un schéma exact de son architecture de données, pas seulement le nom de la région affichée dans le tableau de bord. Un fournisseur sérieux documente cette architecture. Un fournisseur qui répond uniquement « nous sommes conformes RGPD », sans détail technique vérifiable, laisse un signal à interroger.
La nationalité de la société pèse autant que la géographie du serveur
Même avec une base de données et des sauvegardes physiquement en UE, un fournisseur reste soumis au CLOUD Act américain dès que la société qui l’exploite a une présence légale aux États-Unis. La loi vise l’entité juridique, pas le datacenter : c’est la nationalité de la société qui déclenche l’obligation, pas l’emplacement du disque dur.
Ce mécanisme est détaillé dans notre analyse pourquoi le CLOUD Act change le choix de votre BaaS et dans notre article dédié à la nationalité du fournisseur. Cette section se limite à la méthode de vérification rapide.
Pour vérifier ce point sans avis juridique préalable, cherchez la mention « data controller » ou « responsable du traitement » dans la politique de confidentialité du fournisseur, et la clause de droit applicable dans ses conditions générales. Ces deux lignes suffisent en général à identifier l’entité contractante réelle, indépendamment du nom de marque affiché sur le site.
Sauvegardes et reprise après sinistre : un deuxième réglage, souvent caché
Une base de données Postgres managée réplique en général ses sauvegardes vers un stockage objet distinct de la machine primaire, pour des raisons de durabilité et de plan de reprise après sinistre. Ce stockage suit sa propre configuration réseau (endpoint, bucket, parfois région), qui n’est pas automatiquement celle affichée dans le sélecteur principal de la console.
Vérifié dans le dépôt de déploiement d’Aurabase (values.hetzner.yaml) : la variable qui pointe les sauvegardes CloudNativePG vers l’object storage lit fsn1.your-objectstorage.com, l’endpoint Hetzner de Falkenstein, dans le même périmètre allemand que le cluster primaire, pas un bucket tiers situé ailleurs. C’est exactement le type de ligne de configuration à demander à n’importe quel fournisseur avant de signer : pas « vos sauvegardes sont-elles sécurisées », mais « à quelle URL d’endpoint pointent-elles ».
Si un fournisseur ne peut pas répondre à cette question précise, ou renvoie uniquement vers une page marketing générale, traitez la réponse comme non vérifiée plutôt que comme rassurante.
Sous-traitants ultérieurs : support, emailing, analytics
Un backend n’est presque jamais un service isolé. Il s’appuie sur des sous-traitants ultérieurs : un outil de support client, un service d’envoi d’emails transactionnels, une plateforme d’analytics ou de suivi d’erreurs. Chacun de ces outils peut traiter, même brièvement, des données qui transitent par votre application, avec sa propre localisation, indépendante de la région choisie pour la base de données.
Le RGPD impose au responsable de traitement de connaître cette chaîne (Art. 28 et 30). Un fournisseur sérieux publie la liste de ses propres sous-traitants ultérieurs, avec leur rôle et leur localisation. Une liste absente ou obsolète est un signal à interroger avant de signer, pas après un audit de conformité imposé par un client. Voir la page DPA Aurabase pour un exemple de ce type de document.
La checklist en six étapes pour vérifier au-delà de la case région
Voici la méthode utilisée pour vérifier les faits cités dans ce guide, applicable à n’importe quel fournisseur cloud ou BaaS en moins d’une heure, sans avis juridique préalable.
Ces six réponses tiennent en général sur une seule page, une fois rassemblées. Conservez-les : elles servent aussi de preuve lors d’un audit de conformité ou d’une revue par un DPO.
Ce que ça change pour votre registre Art. 30 et une DPIA
Le registre des activités de traitement (Art. 30 RGPD) exige de documenter, pour chaque sous-traitant, sa localisation et les garanties de transfert applicables. Une case région cochée sans le détail des sauvegardes, journaux et sous-traitants ultérieurs laisse ce registre incomplet, un point que relève en général la première visite d’un auditeur ou d’un DPO externe.
Pour un traitement à risque, données de santé, biométrie, profilage à grande échelle, une analyse d’impact relative à la protection des données (DPIA, Art. 35) devient obligatoire. Les six réponses de la checklist précédente constituent une base directe pour cette analyse : elles répondent à sa question centrale, où vont réellement les données, et sous quelle autorité.
Pour le cadre RGPD complet et l’arbitrage auto-hébergement vs BaaS souverain, voir notre guide Backend conforme RGPD et souverain UE. Pour la documentation de conformité d’Aurabase, consultez la page RGPD.
FAQ
Une case région cochée n’est pas une preuve de conformité RGPD. C’est un point de départ, pas une conclusion. La vérification complète porte sur cinq couches distinctes : la base primaire, les sauvegardes, les journaux, les sous-traitants et la société exploitante.
La méthode décrite ici prend moins d’une heure et s’appuie uniquement sur des documents publics. Appliquez-la avant de signer, pas après un audit imposé par un client ou un régulateur.