« On met les serveurs en Europe et c'est réglé. » Si ton produit vit sur un seul continent, oui. Le mien sert des utilisateurs de santé des deux côtés de l'Atlantique.
TL;DR : je travaille sur une architecture SSO multi-région EU/US, avec fallback, pour une plateforme santé de plus de 25 millions d'utilisateurs. La règle qui tient tout : les données de santé restent dans leur région, l'authentification fonctionne partout. Ce pattern a un nom, la résidence sélective. Voici comment le construire, et où il pique.
Cet article est pour les équipes qui doivent servir l'UE et les US avec des contraintes de résidence : santé, finance, secteur public.
Le contexte
Une plateforme d'authentification pour la santé. Plus de 25 millions d'utilisateurs, plus de 1 000 sites intégrés, deux régions : Europe et États-Unis.
Les données de santé ont des règles de résidence strictes. La résidence des données, c'est l'obligation de stocker et traiter une donnée dans une zone géographique définie.
Et pourtant, le SSO doit rester un seul système. Un SSO, single sign-on, permet de se connecter une fois pour accéder à plusieurs services.
Toute la tension est là. Un service global, posé au-dessus de données qui n'ont pas le droit de bouger.
La mauvaise question : « où héberger ? »
Le réflexe habituel : choisir une région et tout y mettre. Pour un produit international, cette question n'a pas de bonne réponse.
La bonne question : qu'est-ce qui a le droit de traverser ?
Réponds-y donnée par donnée, pas serveur par serveur. C'est un exercice de classification, pas d'hébergement.
Classe tes données avant de dessiner l'architecture
Trois piles suffisent.
Première pile : les données métier sensibles. Chez moi, la santé. Elles ne traversent pas. Jamais.
Deuxième pile : l'identité minimale. Ce qu'il faut pour authentifier quelqu'un : identifiant, secrets, méthodes de connexion. C'est petit, et c'est ce qui doit marcher partout.
Troisième pile : tout le reste. Logs, métriques, télémétrie. C'est la pile qu'on oublie, et la PII adore s'y cacher. La PII, ce sont les informations qui identifient une personne.
La frontière ne passe pas entre les serveurs. Elle passe dans l'utilisateur : son dossier reste, son identité voyage.
La résidence sélective : le pattern que les grands assument
Regarde comment Slack documente sa résidence de données. Les messages et fichiers sont stockés dans la région choisie, Francfort par exemple. Et la doc dit noir sur blanc : les demandes de connexion passent par les États-Unis.
Le contenu reste local, l'authentification est globale. C'est un choix d'ingénierie assumé, pas un secret honteux.
La logique est saine. L'authentification est un flux pauvre en données et exigeant en disponibilité. Le dossier médical, c'est l'exact inverse.
Le RGPD n'interdit pas ce flux. Il l'encadre : un transfert reste un transfert, chapitre V. Minimise ce qui traverse, chiffre-le, documente-le.
Le fallback : une région qui tombe ne doit pas déconnecter le monde
Dans une plateforme multi-région, l'authentification est le pire endroit pour une panne. Si l'auth d'une région tombe, des millions de personnes ne se connectent plus.
D'où le fallback inter-région, pour l'authentification seulement.
Trois conditions le rendent possible. Les jetons doivent être vérifiables partout : les clés publiques de signature se répliquent sans risque. L'état strictement nécessaire au login doit rester minimal et disponible. Et le fallback ne doit jamais entraîner les données métier avec lui.
La règle tient en une ligne : réplique les clés, pas les dossiers.
Et un fallback jamais déclenché n'existe pas. Il se teste comme un scénario réel, pas comme une case dans un document.
Les pièges qui n'apparaissent qu'en prod
Premier piège : savoir à quelle région appartient un utilisateur. La question a l'air triviale. Elle décide du routage, de la latence et de la conformité. Réponds-y par une règle explicite : par organisation, par site, ou par choix à l'inscription. Jamais par déduction fragile.
Deuxième piège : la latence des redirections. Un login OIDC enchaîne plusieurs allers-retours entre services. Place le point d'entrée près de l'utilisateur, sinon le login le plus banal devient pénible.
Troisième piège : les traitements asynchrones. Un worker global qui lit une base régionale fait un transfert que personne n'a signé. Les jobs ont une région, comme les données.
Dernier piège : l'humain. Un support qui ouvre un compte de l'autre région depuis son écran fait traverser des données. Les outils d'admin ont une résidence, eux aussi.
L'horizon : l'identité santé devient une infrastructure publique
L'Europe standardise exactement ce terrain. L'EHDS, l'espace européen des données de santé, est entré en vigueur en mars 2025. Son application arrive par paliers à partir de 2027.
Le portefeuille d'identité européen, l'EUDI wallet, doit être proposé par chaque État membre fin 2026. Le secteur santé y aura des attestations dédiées pour ses professionnels.
Traduction pour ton backend : l'identité transfrontière du secteur santé ne restera pas un bricolage privé. Construis ton SSO pour parler à ces briques, pas contre elles.
La checklist avant ton architecture multi-région
Avant de dessiner le moindre schéma, passe par ces questions.
- Classe chaque donnée : régionale stricte, identité mobile, ou télémétrie à auditer
- Écris la liste exacte de ce qui traverse les régions, et pourquoi
- Vérifie que la PII ne fuit pas par les logs et métriques globales
- Rends les jetons vérifiables partout : réplique les clés, pas les dossiers
- Construis le fallback d'auth inter-région, et teste-le comme un vrai scénario
- Donne une région explicite à chaque utilisateur et à chaque job asynchrone
- Traite les outils d'admin et de support comme des flux transfrontières
Ce qu'il faut retenir
Un SSO multi-région tient sur une phrase : les données restent, l'auth voyage.
Le reste est de la discipline. Classification des données, minimisation de ce qui traverse, fallback testé, et de la méfiance pour les flux invisibles : logs, jobs, admin.
Les standards européens poussent dans la même direction. Autant construire dans le sens du courant.
Tu dois faire tenir un SSO au-dessus de contraintes de résidence ? Parlons-en.