CLOUD Act : pourquoi la nationalité de votre fournisseur backend compte plus que la région serveur
Deux fournisseurs backend peuvent afficher la même case « région UE » dans leur documentation et rester dans des situations juridiques totalement différentes face au CLOUD Act. La loi américaine ne s’intéresse pas à l’endroit où vos données sont stockées la nuit. Elle s’attache à qui les possède, les garde ou les contrôle au sens du droit : une entité identifiable, pas un datacenter. Notre article pourquoi le CLOUD Act change le choix de votre BaaS a déjà situé ce critère dans une grille de décision complète, avec le poids à lui accorder selon votre projet. Celui-ci va plus loin sur un point précis, souvent mal compris : ce qui fait, juridiquement, la nationalité d’un fournisseur, et pourquoi elle pèse davantage que la géographie de ses serveurs.
Le CLOUD Act (18 U.S.C. § 2713) attache l’obligation de transmettre des données à la possession, la garde ou le contrôle exercés par une entité, pas à la localisation d’un serveur. Une société de droit américain reste soumise à la loi même si ses données résident physiquement en Europe. Cocher une région UE dans un panneau d’administration ne change rien à cette obligation si la société qui exploite le service reste américaine, ou reste contrôlée par une entité américaine. La vérification utile ne porte donc pas sur une carte de datacenters, mais sur la chaîne de propriété réelle du fournisseur.
Le test juridique réel : possession, garde ou contrôle
Le texte du CLOUD Act ne mentionne à aucun moment la localisation physique d’un serveur. L’article 18 U.S.C. § 2713 impose à tout fournisseur de services électroniques de produire les données qu’il détient « en sa possession, garde ou contrôle », qu’elles soient stockées aux États-Unis ou à l’étranger. C’est cette formulation, et non une carte d’hébergement, qui définit le périmètre réel de la loi.
Cette affaire trouve son origine dans un litige entre Microsoft et le gouvernement américain, déjà détaillé dans notre article sur le choix d’un BaaS. Le Congrès a tranché par la loi plutôt que d’attendre une décision de la Cour suprême. Le résultat pratique reste identique aujourd’hui : la nationalité de l’entité qui contrôle la donnée compte davantage que le pays où cette donnée est physiquement hébergée.
Une conséquence directe découle de cette formulation. Un fournisseur peut être une société de droit américain et rester soumis au CLOUD Act même s’il loue des serveurs à un hébergeur européen pour desservir ses clients UE. Le contrat d’hébergement ne change ni la nationalité de la société qui signe votre contrat de service, ni son obligation légale envers les autorités fédérales américaines.
Le CLOUD Act n’est pas non plus le seul levier de ce type. La section 702 du Foreign Intelligence Surveillance Act (FISA) autorise une surveillance ciblée de communications électroniques par les services de renseignement américains. Son régime reste distinct, orienté sécurité nationale plutôt que procédure judiciaire ordinaire. Les deux textes partagent un point commun utile à retenir. C’est la qualification juridique du fournisseur, société américaine ou soumise à la juridiction américaine, qui déclenche l’obligation, pas la géographie de son infrastructure.
Pourquoi une filiale européenne ne suffit pas toujours à sortir du périmètre
Une société mère américaine qui possède une filiale européenne ne sort pas automatiquement du périmètre du CLOUD Act au seul motif que la filiale est immatriculée en UE. Le test légal porte sur qui, dans la chaîne, détient réellement la possession, la garde ou le contrôle de la donnée, pas sur le nom inscrit au registre du commerce local.
Prenons un cas concret. Une société holding américaine possède 100 % d’une filiale allemande qui héberge et exploite techniquement le service pour ses clients européens. Si les équipes de la société mère américaine disposent d’un accès administrateur à la base de données de production, même à des fins de support technique, cet accès peut suffire. Il peut caractériser un contrôle au sens de la loi, et la nationalité de la filiale locale ne le neutralise pas.
En pratique, la plupart des groupes technologiques centralisent leur infrastructure : accès administrateur, sauvegardes, systèmes d’authentification internes. Vérifier la seule immatriculation d’une entité ne répond donc qu’à une partie de la question. Il faut remonter la chaîne complète : qui détient le capital de cette filiale, qui contrôle son conseil d’administration, qui conserve un accès technique réel aux données une fois le contrat signé.
C’est la même logique que la vérification du bénéficiaire effectif ultime, appliquée en conformité anti-blanchiment. Transposée au choix d’un fournisseur backend, elle change la question posée. Ce n’est pas le nom de la marque commerciale ou de l’entité de facturation qui compte, mais l’entité qui exerce le contrôle final sur les données.
La matrice à deux axes : région d’hébergement et nationalité de la société
Deux axes indépendants déterminent l’exposition réelle d’un backend au CLOUD Act : où sont hébergées les données, et quelle société, avec quelle nationalité, contrôle ce service. Croiser ces deux axes donne une matrice à quatre cases, plus utile qu’une case « région UE » cochée seule dans un comparatif. Nous détaillons pourquoi une région UE seule reste insuffisante dans notre article dédié, région UE et conformité, ce qu’une case cochée ne garantit pas.
Un comparatif BaaS qui ne remplit qu’une seule colonne de cette matrice, le plus souvent celle de la région serveur, laisse la moitié du risque juridique hors champ. C’est l’angle mort traité en détail dans notre guide complet backend conforme RGPD et souverain UE. Nous l’approfondissons spécifiquement pour les hyperscalers américains dans notre analyse dédiée aux hyperscalers en région UE.
La nationalité peut basculer sans qu’aucun serveur ne bouge
Un fournisseur peut passer d’une case à l’autre de cette matrice du jour au lendemain, sans qu’aucune infrastructure ne change. Un rachat par une société américaine suffit à modifier la nationalité effective d’une société, même si ses serveurs restent physiquement au même endroit. Une prise de contrôle capitalistique lors d’un tour de financement, ou une restructuration de holding, produisent le même effet.
Ce risque ne se limite pas à un rachat total. Un tour de financement qui donne à des investisseurs américains une majorité au conseil d’administration produit le même effet. Un accord de licence technologique qui transfère le contrôle opérationnel vers une entité américaine aboutit à la même situation, sans passer par une acquisition classique. La structure juridique visible au moment de la signature du contrat n’est pas une garantie figée dans le temps.
Le décalage entre un changement de contrôle et sa détection côté client aggrave ce risque. Un changement d’actionnaire n’est pas toujours annoncé publiquement au moment où il se produit, surtout pour une société non cotée. Le temps qu’une clause de notification contractuelle se déclenche, plusieurs mois de traitement de données ont pu s’écouler sous la nouvelle structure sans que le client en soit informé.
La grille de décision de notre article sur le choix d’un BaaS suggère déjà d’exiger un droit de résiliation sans pénalité en cas de changement de structure actionnariale. Cette clause mérite d’être précisée. Elle doit couvrir tout changement de contrôle capitalistique, pas seulement un changement de raison sociale. Elle doit aussi prévoir un délai de notification contractuel, pas une simple mention en petits caractères dans une mise à jour de conditions générales.
Notre article sur le choix d’un BaaS détaille déjà comment lire la politique de confidentialité et la clause de droit applicable d’un fournisseur. Cette méthode reste la première étape, elle ne suffit pas seule à retracer une chaîne de propriété qui peut compter plusieurs sociétés holding.
- Consultez le registre du commerce du pays d’immatriculation : Infogreffe en France, Handelsregister en Allemagne, Companies House au Royaume-Uni, SEC EDGAR pour une société américaine cotée ou financée en capital-risque. Objectif : identifier la société mère ultime déclarée.
- Cherchez une mention de la structure du groupe, ou d’un engagement de notification en cas de changement de contrôle, dans un rapport SOC 2 Type II ou une déclaration d’applicabilité ISO 27001. Ce document n’existe pas toujours, mais vaut la peine d’être demandé quand le fournisseur en publie un.
- Vérifiez la composition du tour de financement le plus récent via les annonces publiques : une majorité d’investisseurs américains au capital est un signal à questionner, même pour une société immatriculée en UE.
- Demandez explicitement, dans la négociation du DPA, un engagement écrit de notification en cas de changement de contrôle capitalistique.
- Si le fournisseur communique déjà sur son indépendance capitalistique, demandez une confirmation écrite et datée. Une déclaration orale en démo commerciale n’a pas la même valeur qu’un engagement contractuel.
Aucune de ces vérifications ne remplace un avis juridique pour un projet à enjeu élevé. Elles suffisent en revanche à repérer, en une heure, un fournisseur dont la structure de propriété mérite une question directe avant signature.
La région d’un serveur reste une information utile. Elle ne répond à aucune des deux questions qui comptent réellement : qui contrôle légalement cette donnée aujourd’hui, et qui pourrait la contrôler demain si la structure de propriété du fournisseur change.
Ajoutez la nationalité de la société, pas seulement celle du datacenter, à votre grille de vérification fournisseur. Pour la grille de décision complète sur le poids de ce critère selon votre projet, consultez pourquoi le CLOUD Act change le choix de votre BaaS.
Pour le cadre RGPD complet, les exigences légales détaillées et une checklist de conformité fournisseur, consultez notre guide backend conforme RGPD et souverain UE.
Comment retracer la chaîne de contrôle réelle d’un fournisseur