Backend conforme RGPD et souverain UE : le guide complet
Cocher une région d’hébergement UE dans un panneau d’administration ne suffit pas à rendre un backend conforme au RGPD ou immunisé contre le CLOUD Act. La nationalité de la société qui exploite le service compte tout autant que la géographie des serveurs. Ce guide détaille pourquoi, et ce qu’il faut vérifier avant de choisir.
Deux conditions cumulatives déterminent l’exposition réelle d’un backend : la localisation de l’hébergement ET la juridiction de la société qui l’exploite. Un hyperscaler américain en région eu-west-1 reste soumis au CLOUD Act. Aurabase documente les deux : infrastructure de production vérifiée en Allemagne et en Finlande, exploitée par Aurabase SAS, société de droit français.
RGPD et CLOUD Act : ne pas confondre les deux régimes
Le RGPD (Règlement UE 2016/679) encadre le traitement des données personnelles, quel que soit le fournisseur. Le CLOUD Act est une loi américaine qui autorise les autorités fédérales US à requérir des données détenues par une société de droit américain — même si ces données sont physiquement stockées en Europe. Ce sont deux régimes juridiques distincts, et confondre l’un avec l’autre est l’erreur la plus coûteuse qu’un CTO puisse commettre en évaluant un fournisseur.
Un fournisseur peut être parfaitement conforme au RGPD sur le papier (DPA signé, registre des traitements à jour) tout en restant exposé au CLOUD Act si sa société mère est américaine. Cocher une région « EU » dans un panneau d’hébergement ne règle que la moitié du problème.
Ce que le RGPD exige réellement d’un backend
Au-delà du principe général, quatre obligations concrètes s’appliquent directement à l’architecture technique d’un backend : une base légale de traitement, la minimisation des données collectées, le droit à l’effacement (Art. 17) et le droit à la portabilité (Art. 20).
Sur un backend Postgres, ces obligations se traduisent en capacités techniques vérifiables : la Row Level Security permet de restreindre l’accès aux données au strict périmètre nécessaire (minimisation appliquée au niveau ligne), et un export pg_dump standard couvre la portabilité — un format SQL ouvert, pas un export propriétaire à reconstruire.
Le rôle du DPA dans la chaîne
Le Data Processing Agreement (DPA) est le contrat qui encadre juridiquement votre fournisseur comme sous-traitant de données personnelles au sens de l’Art. 28 RGPD. Il doit exister, être daté, et lister les sous-traitants ultérieurs du fournisseur lui-même — sans DPA à jour, votre propre registre des traitements (Art. 30) reste incomplet. Voir la page DPA Aurabase et la page RGPD Aurabase.
Ce que coûte une non-conformité
L’Art. 83 RGPD prévoit deux paliers d’amende administrative : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial pour les manquements les moins graves (registre absent, DPA manquant), et jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial — le montant le plus élevé étant retenu — pour les violations des principes fondamentaux du traitement. Ce risque contractuel pèse sur le responsable de traitement, pas seulement sur son sous-traitant : choisir un fournisseur backend mal documenté reste votre exposition, pas la sienne.
CLOUD Act : ce qu’il autorise, et qui il concerne
Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) autorise les autorités judiciaires américaines à contraindre une société de droit américain à fournir des données qu’elle détient ou contrôle — où que ces données soient physiquement hébergées dans le monde. La portée est extraterritoriale par construction : c’est la nationalité de l’entreprise qui déclenche l’obligation, pas la localisation du datacenter.
Certaines de ces requêtes s’accompagnent d’une clause de confidentialité (gag order) qui empêche l’entreprise concernée d’informer le client final. C’est ce point précis — l’absence de recours ou de notification côté client européen — qui distingue le risque CLOUD Act d’une simple question de localisation serveur. Pour la grille de décision complète appliquée au choix d’un BaaS, voir notre article dédié : pourquoi le CLOUD Act change le choix de votre BaaS.
AWS, GCP, Azure en région UE : une garantie incomplète
Choisir une région eu-west-1 (AWS), europe-west1 (GCP) ou une région Azure européenne réduit la latence et répond à des exigences de résidence des données — mais ne change pas la nationalité de la société qui exploite ces plateformes. AWS, Google Cloud et Microsoft Azure restent des sociétés de droit américain, soumises au CLOUD Act indépendamment de la région choisie par leurs clients.
Le Data Privacy Framework UE-USA encadre les transferts de données vers des entreprises américaines certifiées, en substitution du Privacy Shield invalidé par la Cour de justice de l’Union européenne (arrêt Schrems II, 2020). Ce cadre traite la question du transfert de données vers les États-Unis — il n’élimine pas l’exposition CLOUD Act d’une société américaine hébergeant des données en UE, qui reste un sujet juridictionnel distinct.
Ce qu’Aurabase vérifie et documente
L’infrastructure de production d’Aurabase est vérifiée en Allemagne (Nuremberg, Falkenstein) et en Finlande (Helsinki), chez Hetzner — aucune autre localisation n’est confirmée à ce jour. Aurabase SAS, la société qui l’exploite, est une société de droit français basée à Paris.
Un environnement de déploiement dédié chez Scaleway (région Paris) existe dans le dépôt d’infrastructure d’Aurabase, prêt à être appliqué — mais ce n’est pas, à ce jour, un déploiement de production actif. Pour rester honnête sur ce point : n’attendez pas d’Aurabase l’affirmation « hébergement France » tant que ce déploiement n’est pas confirmé en production ; la formulation correcte reste « souveraineté UE », avec l’option Scaleway Paris disponible sur demande.
Checklist avant de signer avec un fournisseur backend
Cette checklist s’applique à n’importe quel fournisseur backend, Aurabase inclus — vérifiez chaque réponse sur la page de conformité publique du fournisseur plutôt que sur la promesse commerciale d’un email de vente.
Pour approfondir la posture de sécurité technique associée, voir la page Sécurité Aurabase.
Auto-hébergement vs BaaS souverain UE : quelle option choisir ?
Une PME soumise au RGPD arbitre en général entre trois options : construire et héberger son propre backend, utiliser un BaaS américain avec option région UE, ou choisir un BaaS souverain UE de bout en bout. L’auto-hébergement donne le contrôle juridique maximal mais transfère toute la charge opérationnelle (patchs de sécurité, sauvegardes, disponibilité) à une équipe interne qui doit déjà exister.
Un BaaS souverain UE — infrastructure et société mère toutes deux en UE — déplace cette charge opérationnelle vers le fournisseur sans réintroduire l’exposition CLOUD Act d’un hyperscaler américain en région EU. C’est un compromis pertinent pour une équipe qui n’a pas la capacité de maintenir son infrastructure elle-même, sans pour autant vouloir arbitrer sa conformité contre sa vélocité produit.