Pourquoi le CLOUD Act change le choix de votre BaaS

Le CLOUD Act — Clarifying Lawful Overseas Use of Data Act — a été promulgué en mars 2018 aux États-Unis. Il autorise les autorités fédérales à contraindre tout fournisseur ayant une présence légale sur le sol américain à produire les données qu’il détient, même stockées à l’étranger (18 U.S.C. § 2713). Le texte répond directement à un litige où Microsoft refusait de transmettre au FBI des données stockées sur un serveur à Dublin. Le Congrès a tranché par la loi plutôt que d’attendre la décision de la Cour suprême, alors saisie de l’affaire.

Cette question n’apparaît sur presque aucune grille de comparaison publique, y compris sur des sites tiers dédiés au BaaS. La raison est structurelle : un site de comparatif liste des fonctionnalités qu’on peut cocher — présence d’un SDK, quota gratuit, support GraphQL. La juridiction d’une société n’est pas une fonctionnalité activable dans un panneau d’administration, donc elle ne rentre pas dans le format tableau habituel. Cela ne la rend pas moins déterminante pour autant.

Le détail du texte, son articulation avec le RGPD et une checklist de vérification fournisseur complète sont couverts dans notre guide Backend conforme RGPD et souverain UE. Cette section se limite à ce qui change concrètement dans un comparatif BaaS.

Supabase, Inc. est l’entité identifiée comme responsable du traitement dans sa propre politique de confidentialité, avec des sites hébergés en priorité depuis les États-Unis. Firebase est un produit de Google LLC, filiale d’Alphabet Inc., société de droit américain. AWS Amplify est contractuellement rattaché par défaut à Amazon Web Services, Inc., domiciliée dans l’État de Washington. Les trois proposent une région d’hébergement UE. Les trois restent, en tant qu’entité contractante, des sociétés de droit américain.

Ce n’est pas un jugement sur leur qualité technique — c’est une observation sur la structure juridique de l’entité qui signe le contrat avec vous. Un produit excellent peut rester juridiquement exposé ; les deux évaluations sont indépendantes l’une de l’autre.

Le CLOUD Act ne mérite pas le même poids dans tous les projets. Un MVP solo, sans utilisateur européen identifié et sans donnée de santé ni RH, peut raisonnablement traiter ce critère comme secondaire face au prix et à la vélocité de développement.

La bascule se produit dès qu’un signal apparaît : un DPO ou un juriste impliqué dans la décision, une donnée sensible au sens de l’article 9 du RGPD — santé, biométrie, opinions. Elle se confirme avec un client du secteur public, ou un marché public UE qui exige une garantie de souveraineté explicite. À ce stade, le critère juridique doit être vérifié avant de comparer les prix — pas après avoir déjà choisi un favori technique.

C’est le point de bascule typique d’un CTO de PME-ETI qui arbitre entre build interne, Supabase Cloud, AWS Amplify et une solution souveraine. Le déclencheur n’est pas la taille de l’entreprise, mais la nature des données traitées et l’existence d’un interlocuteur qui devra en répondre devant un client ou un régulateur.

Concrètement, le critère se vérifie à trois moments distincts d’un cycle d’achat BaaS. Avant la shortlist, il sert de filtre binaire pour les projets déjà identifiés comme sensibles. Pendant la due diligence technique, il se vérifie document par document, aux côtés du DPA et de la politique de sécurité. Avant la signature, il devient une clause contractuelle — pas seulement une réponse orale d’un commercial en démo.

Une clause utile à négocier à ce stade : le droit de résilier sans pénalité si la structure actionnariale du fournisseur change. Un rachat par une société américaine change la réponse à la question juridique, même si l’infrastructure reste techniquement identique le lendemain.

Ajoutez cette grille comme une colonne de plus dans votre tableur de comparaison existant, pas comme un document séparé. Elle doit rester visible au moment où vous arbitrez entre deux favoris techniquement proches.

Une première vérification ne demande pas d’avis juridique. Deux documents publics suffisent pour situer n’importe quel fournisseur candidat : sa politique de confidentialité et les conditions générales attachées au contrat.

1. Cherchez la mention « data controller » ou « responsable du traitement » dans la politique de confidentialité — c’est l’entité juridique réelle, pas le nom de marque affiché sur le site.
2. Repérez la clause de droit applicable (« governing law ») dans les conditions générales — elle indique la juridiction sous laquelle le contrat, et souvent l’entité, opèrent.
3. Vérifiez si une entité UE distincte existe pour votre région (filiale irlandaise, par exemple) — et si elle change la réponse à la question précédente, ou seulement l’adresse de facturation.

C’est la méthode utilisée pour vérifier les faits cités dans cet article : politique de confidentialité de Supabase, Inc., conditions générales AWS, politique de confidentialité de Google. Trois documents publics, aucun n’exige de compte commercial pour être consulté.

Il y a aussi un argument de timing propre au choix d’un BaaS : plus une équipe intègre profondément un fournisseur — schéma, policies, Edge Functions, webhooks —, plus une migration ultérieure coûte cher. Un critère juridique découvert après six mois de production se traite dans l’urgence et avec un rapport de force défavorable. Le même critère évalué avant la signature ne coûte que le temps de lire deux documents publics.