Livrez une région de données UE en 90 jours : le playbook du CTO après le virage de Fastmail

Votre prochain deal enterprise peut se jouer à une seule question : « Où sont hébergées les données ? » Fastmail vient d’annoncer une région de données UE. Ce n’est pas pour le plaisir : c’est une réponse aux demandes clients. Si vous vendez en Europe et tournez encore sur une seule région US, vous laissez de l’argent sur la table et vous offrez des RFP à des concurrents capables de répondre « Frankfurt ».

Ce post vous donne un playbook sur 90 jours pour mettre en place une région de données UE sans réécriture complète. C’est une approche opiniâtre, vérifiable, pensée pour une équipe scale‑up de 8–20 ingénieurs backend. Vous séparerez plan de contrôle et plan de données, assignerez les tenants à des régions, garderez les clés de chiffrement régionales et prouverez (pas seulement promettrez) que la PII ne quitte jamais l’UE.

Ce que « résidence des données » signifie réellement (choisissez votre niveau)

Avant de provisionner quoi que ce soit, définissez le périmètre de résidence. Votre équipe juridique vous remerciera, et votre architecture restera cohérente.

• Résidence du stockage : PII client au repos stockée uniquement dans la région (BD, stockage d’objets, sauvegardes).
• Résidence du traitement : Les calculs qui touchent à la PII s’exécutent dans la région (API, jobs, outils de support).
• Résidence des accès : L’accès humain à la PII est restreint au personnel avec un contexte régional approuvé et des contrôles auditables.
• Résidence des dépendances : Les sous‑traitants utilisés avec de la PII sont liés à la région et divulgués dans votre DPA.

La plupart des clients qui demandent une « résidence des données UE » visent au minimum stockage et traitement. Beaucoup accepteront des sauvegardes inter‑régions chiffrées si les clés de chiffrement ne quittent jamais l’UE. Quelques‑uns exigent une isolation stricte (aucun flux inter‑régions, même chiffré). Décidez de votre cible et consignez‑la.

Une classification simple des données qui ne s’effondrera pas en charge

• P0 (PII/secrets critiques) : noms, e‑mails, numéros de téléphone, adresses postales, pièces d’identité, jetons d’accès, contenu brut téléversé par les utilisateurs.
• P1 (PII « douce »/données métier) : métadonnées de ressources, compteurs d’usage, état de workflow qui n’est pas directement identifiant mais devient sensible lorsqu’il est joint avec du P0.
• P2 (télémétrie opérationnelle) : logs, métriques, traces, agrégats de facturation, analytics produit avec P0 supprimé ou salé de manière irréversible.

Politique : P0 et P1 ne franchissent jamais la frontière régionale. P2 peut être exporté tant que les transformations irréversibles se produisent avant toute sortie, dans la région.

Stratégie de multi‑tenancy : commencez simple, évitez de le regretter plus tard

Vous avez trois options. Une seule se livre en 90 jours sans vous enfermer dans une impasse.

• Tenancy assigné à l’organisation (recommandé) : Chaque organisation cliente choisit une région à l’inscription ou lors d’une migration. Tout son P0/P1 vit et est traité dans cette région. Le plus propre pour le B2B. Facile à raisonner, auditer et vendre.
• Tenancy assigné à l’utilisateur : Résidence par utilisateur au sein d’une organisation globale. Séduisant pour les équipes « hybrides », mais complexité qui explose côté auth, collaboration et reporting. Ne commencez pas ici.
• Tenancy assigné à l’objet : Chaque contenu choisit une région. Très bien pour des réseaux grand public de contenu ; désastreux pour l’audit enterprise. À éviter sauf si votre produit est intrinsèquement de distribution globale de contenu.

Choisissez l’assignation par organisation et passez à la suite. Vous pourrez ajouter des exceptions par utilisateur plus tard si un très gros client vous y oblige.

Plan de contrôle vs plan de données : la seule frontière qui passe à l’échelle

Votre architecture actuelle mélange probablement les deux. Démêlez‑les :

• Plan de contrôle global : annuaire des tenants, métadonnées d’offres/facturation, feature flags, table de routage (org → région), et aucun P0. Il orchestre, il ne stocke jamais de PII.
• Plans de données régionaux (UE, US, …) : frontends API, bases, stockage d’objets, recherche, files, batch jobs — tout ce qui touche P0/P1. Ils ne se parlent qu’au travers de canaux bien définis et audités pour les exports P2 ou une éventuelle DR chiffrée.

C’est le modèle vers lequel convergent Fastmail et les SaaS matures car il aligne les incitations : les auditeurs inspectent les data planes ; le control plane reste simple et global.

Le chantier en 90 jours : un blueprint concret

Jours 0–15 : inventaire, politique et hooks de schéma

• Inventoriez les sous‑traitants : Listez tous les vendors qui voient de la PII aujourd’hui (e‑mail, support, analytics, APM, suivi d’erreurs). Codez par couleur selon leur capacité UE.
• Choisissez votre région UE : AWS eu‑central‑1 (Frankfurt) ou eu‑west‑1 (Irlande) sont courants. Latence ~20–40 ms depuis les grands hubs européens. N’y passez pas trop de temps.
• Ajoutez la région au schéma de tenancy : La table des organisations reçoit un region_code (p. ex., EU, US). Imposez des clés étrangères depuis toutes les tables P0/P1 vers org. Si vous êtes multi‑tenant, ajoutez des contraintes de type CHECK (region_code = current_setting('app.region')) par schéma ou utilisez la Row Level Security (RLS) liée à app.region. Rendez impossible toute écriture inter‑régions par accident.
• Décidez de votre posture DR maintenant : Option A (stricte) : aucune copie inter‑régions ; DR uniquement régionale. Option B (équilibrée) : répliquer des sauvegardes chiffrées entre régions avec des clés qui ne quittent jamais la région source. Inscrivez‑le dans votre DPA et vos runbooks.

Jours 16–35 : mettre en place la stack UE (parité, pas perfection)

• Base de données : Un cluster Postgres ou MySQL séparé en UE. Aucune réplication logique depuis les US. Même schémas, mêmes extensions. Ciblez des latences de lecture API p95 ≤ 50 ms dans la région.
• Stockage d’objets : Buckets régionaux (S3 eu‑central‑1/eu‑west‑1, GCS europe‑west). Utilisez Object Lock et des règles de cycle de vie. Ne répliquez pas les objets bruts hors de la région sauf si la politique DR le permet et si les clés restent liées à l’UE.
• KMS/clés : Clés KMS par région. N’exportez pas les clés. Si vous faites de la DR chiffrée inter‑régions, copiez le chiffré avec des clés non exportables liées à l’UE. SLA de rotation des clés : 90 jours ; rotation d’urgence : 24 h.
• Files/jobs : SQS/PubSub régionaux et workers régionaux. Aucune file globale pour du travail P0/P1. Tagguez les jobs avec org_id et vérifiez la région à la consommation.
• Recherche : Exécutez un index régional (OpenSearch/Elasticsearch) alimenté par la BD UE. Pas de recherche globale pour les tenants UE. Si vous devez unifier, faites‑le avec des résumés P2.
• Feature flags : Choisissez un fournisseur avec résidence des données UE ou auto‑hébergez un service de flags simple (OpenFeature + Redis) par région. Les flags sont au pire du P1 ; gardez‑les là où résident les tenants.

Jours 36–60 : trafic, identité et observabilité sans fuite

• Routage : Sous‑domaines régionaux explicites : eu.yourapp.com et us.yourapp.com. À la connexion, résolvez org → région dans le control plane et faites un 302 vers le bon sous‑domaine. Évitez le GeoIP. Rendez‑le déterministe et auditable.
• Auth/SSO : Jetons émis et vérifiés dans la région. Clés (JWKS) hébergées par région. Le control plane peut fédérer l’identité sans voir de P0 si vous ne stockez que l’émetteur au niveau de l’org et des IDs utilisateur opaques pour le control plane.
• Logs/métriques/traces : Ingestion et stockage dans la région. Éliminez le P0 à la source. Pour des exports vers un SIEM global, pré‑hashez les e‑mails (sel régional) et caviardez chemins/requêtes contenant du P0. Mettez en place des tests d’exfiltration qui font échouer les builds si un nouveau champ de log contient du P0.
• Analytics : Exécutez un entrepôt dans la région (dataset BigQuery UE, Snowflake UE ou ClickHouse UE) alimenté par des jobs de dépiautage de PII. N’exportez que des P2 agrégés avec des seuils de k‑anonymity (p. ex., supprimez les cohortes avec n<10). Aucun export d’événements bruts vers des endpoints globaux.
• E‑mail/SMS : Utilisez des endpoints compatibles UE (SES eu‑west‑1, fournisseurs basés dans l’UE). Assurez‑vous que les templates sont rendus dans la région et que seuls des P2 sortent (statuts de livraison). Mettez à jour votre liste de sous‑traitants.

Jours 61–90 : migration, DR et preuves

• Engagement des tenants : Les nouveaux prospects UE vont par défaut en région UE. Les migrations des clients UE existants se font par lots : export chiffré depuis les US, import dans l’UE, bascule DNS/routage applicatif, puis suppression définitive de l’ancien P0 après validation client. Une organisation moyenne (10–50 Go de P0/P1) se migre sur un week‑end de maintenance.
• DR et sauvegardes : Prouvez votre posture annoncée. Si stricte, exécutez des drills de sauvegarde/restauration trimestriels dans l’UE. Si équilibrée, répliquez des snapshots chiffrés vers une seconde région UE (pas US) et testez que les clés ne quittent jamais les coffres UE. Documentez les cibles RPO/RTO (p. ex., RPO ≤ 15 min, RTO ≤ 2 h).
• Accès support : Accès JIT avec approbation. Les tenants UE déclenchent par défaut des pools support UE‑only. Les outils d’enregistrement de sessions tournent dans la région ; nettoyez le P0. Tous les accès sont loggés vers le SIEM UE. Le break‑glass requiert l’approbation d’un VP et est auto‑notifié au client sous 24 h.
• Vérification : Générez de la PII canari (p. ex., des e‑mails du type eu‑leak‑probe+GUID@yourapp.test) en staging et en prod. Les honeytokens alertent s’ils apparaissent dans un système non‑UE. Ajoutez des alertes eBPF/VPC Flow Logs pour toute sortie inattendue vers des plages IP non‑UE depuis les VPC UE.

Coûts et effectifs : ce que cela implique vraiment

• Multiplicateur infra : Attendez‑vous à +25–40 % de dépenses infra pour faire tourner une seconde région à parité (BD, stockage d’objets, recherche, files, observabilité). Vous pouvez garder un control plane global partagé minimal.
• Équipe : 2–3 mois FTE d’ingénieurs backend seniors pour accueillir les premiers tenants UE, plus 0,5 FTE SRE/Plateforme en continu pour maintenir la parité. Avec une équipe plateforme solide, vous pouvez compresser la phase initiale.
• Performance : Les tenants UE verront un gain de 100–200 ms de latence bout‑en‑bout vs un aller‑retour US. Vos tenants US ne remarqueront pas l’ouverture de l’UE si vous isolez correctement les parcours.

En échange, votre équipe Sales arrêtera d’esquiver les questionnaires sur Schrems II et vos cycles de procurement se raccourciront. D’expérience, la résidence débloque des pilotes enterprise à 6–7 chiffres avec un amortissement du CAC sur un an.

Modes d’échec courants (et comment les prévenir)

• Cron jobs « globaux » : Des batchs qui itèrent sur toutes les orgs franchiront la frontière par accident. Corrigez en shardant les ordonnanceurs par région et en pilotant les batchs via des files régionales.
• Redis partagé : Ne pointez pas des workers UE vers un Redis US sous prétexte que « ce n’est qu’un cache ». Les caches fuient du P0 et deviennent de l’état. Exécutez un Redis/Valkey régional et fixez des TTLs agressifs.
• Portes dérobées admin : Des interfaces internes qui lisent au travers des régions « pour la commodité » sont des moteurs de découverte pour les auditeurs. Obligez les admins à choisir explicitement une portée régionale et appliquez‑la à la couche requêtes.
• Logger tout : Si vos logs contiennent des e‑mails bruts ou des corps de requêtes, vous n’avez pas de résidence — vous avez des fuites. Soignez l’hygiène des logs avant de scaler le trafic UE.
• Prolifération de tiers : Le plugin navigateur de votre vendor sécurité, l’uploader de screenshots de votre outil QA, votre pixel marketing — ce sont des sous‑traitants. Inventoriez‑les et mettez‑les sous contrôle.

Comment en parler en revue de sécurité

Les auditeurs ne veulent pas de poésie ; ils veulent de l’architecture et des preuves. Mettez ceci dans une annexe de 2 pages partageable sous NDA :

• Un diagramme : Un plan de contrôle (global, sans P0) et deux plans de données (UE, US) avec des flèches montrant uniquement l’égresse P2.
• Un tableau : Pour chaque système (BD, stockage d’objets, recherche, logs, analytics, e‑mail, support), listez région, workloads et si P0/P1/P2 y est traité ou stocké.
• Une politique : P0/P1 ne quitte jamais la région. Égresse P2 uniquement après transformations irréversibles. Les clés sont régionales et non exportables.
• Un test : PII canari et surveillance des sorties qui s’exécutent quotidiennement avec alertes vers security@.
• Un SLA : RPO/RTO par région et posture DR (stricte ou équilibrée) et la cadence des drills de restauration.

En avez‑vous vraiment besoin maintenant ?

Si l’un de ces points est vrai, oui :

• Vous avez perdu ≥1 deal enterprise sur les deux derniers trimestres à cause de la résidence.
• ≥10 % de votre pipeline contient des prospects UE qui ont demandé où résident les données.

Si aucun n’est vrai, préparez quand même les hooks : ajoutez region_code aux orgs, nettoyez le P0 de vos logs, arrêtez d’utiliser des files globales et séparez bien plan de contrôle et plan de données. Ces changements vous renforcent même si vous n’ouvrez jamais Frankfurt.

Pourquoi un pod nearshore aide

Ce chantier est transverse : schéma de BD, systèmes de jobs, observabilité, sécurité et juridique. Il entre en compétition avec la roadmap produit. Un pod nearshore — 6–8 heures de recouvrement avec votre core team US — peut exécuter le blueprint sans perturber vos feature teams. Les déploiements les plus rapides que nous avons vus associent un lead plateforme côté US à une équipe backend/SRE au Brazil qui livre en parallèle les clones régionaux, la politique KMS et les tests de vérification.

Ce que le choix de Fastmail signifie

L’e‑mail est la classe de PII la plus difficile — identité, contenu et traitement continu. Si un fournisseur de messagerie peut offrir une région de données UE avec des frontières propres, votre outil de workflow B2B, votre plateforme d’analytics ou votre app de collaboration n’a aucune excuse. Les clients traitent désormais la résidence comme le SSO : une case attendue. Soit vous la construisez maintenant à vos conditions, soit vous la bâtissez plus tard dans la panique après avoir perdu un logo que vous vouliez sur votre homepage.

Points clés à retenir

• Définissez tôt le périmètre de la résidence : stockage, traitement, accès et dépendances. Écrivez‑le.
• Adoptez un tenancy par organisation et un plan de contrôle global avec des plans de données régionaux. Gardez P0/P1 régionaux, toujours.
• Utilisez des clés KMS par région, des BD/stockage/recherche/files régionales et des sous‑domaines explicites par région pour le routage.
• Sécurisez la télémétrie : supprimez le P0 dans la région, exportez uniquement des agrégats P2 avec k‑anonymity.
• Choisissez une posture DR que vous pouvez prouver. Testez les restaurations trimestriellement, documentez RPO/RTO et gardez les clés régionales.
• Prévoyez +25–40 % d’uplift infra et 2–3 mois FTE pour atteindre les premiers tenants UE. Le surcroît de ventes rembourse souvent en un an.
• Construisez la vérification : PII canari, moniteurs d’égresse et cadrage admin. En audit, la preuve bat la promesse.