Infrastructure EU-first
Si tes utilisateurs sont dans l'UE, tes données doivent y être aussi. Ça sonne idéologique jusqu'au moment où tu vois ce qui arrive quand ce n'est pas le cas : audits GDPR, questions DPA auxquelles tu ne peux pas répondre, risque lié au CLOUD Act que tu ne peux pas atténuer, acheteurs européens qui demandent « où est-ce hébergé » et qui s'en vont quand la réponse est us-east-1.
L'EU-first n'est pas du marketing — c'est un choix d'architecture que tu fais au moment du setup. Le rajouter après coup coûte 10x plus cher que de le faire bien dès le départ.

Croquis whiteboard · la stack UE
La stack minimale
Pour un produit SaaS ou un backend d'application mobile, la stack EU-first pratique sans auto-hébergement :
| Couche | Choix | Région |
|---|---|---|
| Base de données + auth | Supabase | EU-Frankfurt |
| Monitoring / suivi d'erreurs | Sentry | EU-Frankfurt |
| Stockage d'objets | Cloudflare R2 | (compatible S3, data residency dans la config) |
| Resend | instance UE | |
| Paiement | Stripe / Mollie | Stripe garde des PII côté US ; Mollie est NL-native |
| Hébergement (web) | Vercel | régions UE disponibles, vérifie aussi les function regions |
Chacun propose des options de région UE explicites. Choisis l'option UE au setup ; jamais « upgrader plus tard ». Les migrations de région sont coûteuses et risquées.
Ce que ça t'apporte
Data residency. Les PII clients (emails, noms, données de paiement, contenu applicatif) restent dans l'UE. Les transferts vers des parties US-controlled n'ont lieu que sous des DPA explicites ou des fallbacks SCC. C'est ce que les régulateurs veulent voir.
Clarté des DPA. Chaque processor (les services ci-dessus) fournit un DPA que tu peux signer. Garde-les dans un registre processor-service-DPA — un tableur suffit, l'essentiel est de l'avoir. Quand un client demande « as-tu un DPA avec Supabase », tu dis oui et tu le livres dans la journée.
Registre GDPR Art. 30. Un registre des traitements où tu listes chaque type de donnée personnelle que tu traites : finalité, base légale, avec qui tu partages, durée de conservation. Template boilerplate, remplis tes données spécifiques, mets-le à jour quand quelque chose change. Pas optionnel ; il n'est audité que lorsque quelque chose tourne mal.
Parcours de suppression utilisateur. Le droit à l'effacement du GDPR
n'est pas difficile quand tes données se trouvent au même endroit. Construis
l'endpoint /account/delete dès le premier jour. Teste-le. La première fois
qu'un utilisateur le demande, tu ne veux pas être en train de concevoir
sous pression.
Considérations CLOUD Act
Même si ton stockage est dans l'UE : si l'opérateur est une entreprise américaine, le CLOUD Act autorise formellement les autorités US à exiger tes données. Pour certains secteurs (legal, health, defense) c'est réel. Pour la plupart des produits grand public c'est académique — mais le positionnement compte vis-à-vis des acheteurs européens.
Les atténuations :
- Choisis si possible des services EU-headquartered (Mollie plutôt que Stripe, Hetzner plutôt qu'AWS, OVHcloud plutôt qu'Azure)
- Signe des DPA avec des clauses SCC qui couvrent les scénarios d'accès gouvernemental
- Documente publiquement ta liste de sous-traitants — la transparence est un signal de confiance vis-à-vis des acheteurs
Tu n'as pas besoin d'être 100% pure-UE (l'API Anthropic Claude est par exemple US-only). En revanche, tu dois être transparent sur quels services sont quoi.
Ce que ça ne signifie pas
EU-first ne veut pas dire EU-only. Ça veut dire UE par défaut avec des exceptions explicites. L'inférence AI peut tourner contre un endpoint US. Un CDN peut servir depuis n'importe où. Certains outils d'analytics n'ont pas d'instance UE. Documente les exceptions, garde-les petites et assure-toi qu'elles ne touchent jamais de PII non chiffrées.
Quand faire ce choix
Au setup. Le premier jour. Choisir Supabase EU vs Supabase US au premier clic
create project est une décision de 5 secondes qui t'épargne une migration
de 5 mois plus loin.
Déjà dans une région US et tu veux basculer ? Prévois un trimestre, pense le cutover de bout en bout, accepte de perdre quelques relations de données ou environnements de test pendant la bascule. Faisable, pas agréable.
Ce que l'EU-first signale aux acheteurs
Deux choses, selon le type d'acheteur :
-
Entreprise UE / secteur public : obligé par son propre framework de conformité d'acheter de l'hébergé-UE. Sans EU-first, tu n'es même pas sur la shortlist.
-
Consommateurs / créateurs soucieux de la vie privée : choisissent activement des services UE après les histoires de BandLab / Endlesss / effondrement de cloud. La vie privée devient une feature, pas seulement de la conformité.
Aucun des deux groupes n'est la majorité du marché. Les deux paient une prime pour la discipline. C'est pour ça que l'EU-first fonctionne comme une niche plutôt que comme une contrainte.
Ce que ça te coûte
Un peu plus de friction côté fournisseurs (pour certains outils la région UE est le second choix). Une sélection de processors un peu plus soigneuse. Un registre des traitements que tu tiens à jour. Environ 4 à 8 heures de setup ponctuel.
En retour : une position défendable, une vraie réponse quand les acheteurs européens posent la question, zéro dette de migration, et la possibilité de revendiquer « EU-first » sans mentir. Ça vaut la peine.