La région que vous choisissez détermine où Bird stocke et traite les données de votre organisation. Elle conditionne aussi les règles de confidentialité transfrontalières applicables.
Où vivent mes données ?
Dans une seule région, choisie à la création de l'organisation.
Chaque organisation Bird se voit attribuer une région à l'inscription. us1 correspond aux États-Unis et eu1 à l'Union européenne, et la documentation des régions précise ce que cette attribution couvre :
Every organization is assigned a region at signup. The region is detected from your location, can be changed before you confirm, and is immutable in v1. The workspace, API keys, messages, recipient data, and event logs remain in that region. They are never replicated across regions.
L'expression à retenir est "never replicated". Un engagement de résidence qui autoriserait une copie ailleurs à des fins de redondance ou d'analyse n'en serait pas un. Ici le plan de données est réellement séparé par région, ce qui explique aussi pourquoi le choix est immuable : déplacer une organisation entre régions n'est pas un paramètre, c'est une migration que la version actuelle de API ne propose pas.
Comment est-ce appliqué ?
Dans l'identifiant et dans le routage, de sorte qu'une erreur échoue de façon visible.
Il n'existe pas de point d'entrée global unique pour le plan de données. Chaque région possède son propre hôte, et une clé API indique sa région dans son préfixe : une clé bk_eu1_ appartient à eu1. Les SDK et le CLI lisent le préfixe et choisissent l'hôte sans configuration.
Ce qui se passe quand une requête atteint le mauvais endroit est la partie intéressante :
A request that reaches the wrong region is rejected with
421 Misdirected Requestinstead of being forwarded. The error message names the correct host
Refuser plutôt que rediriger est le choix de conception qui rend la résidence vérifiable. Une plateforme qui relaierait silencieusement une requête mal adressée serait pratique, mais signifierait aussi qu'une requête contenant des données personnelles aurait franchi une frontière sans que personne ne s'en aperçoive. Ici c'est impossible : la requête échoue, et l'erreur indique l'hôte à utiliser.
Chaque réponse contient aussi un en-tête X-Bird-Region indiquant la région qui l'a servie, ce qui vous permet de vérifier où un appel a réellement abouti au lieu de faire confiance à la configuration.
Qu'est-ce qui n'est pas lié à une région ?
L'authentification et l'administration de compte, et la documentation le dit explicitement plutôt que de le laisser implicite :
Only authentication and account administration (
/v1/auth,/v1/admin) operate on globally replicated data, which is why they are served from the non-region hostplatform.bird.com.
Cela vaut la peine d'être su plutôt qu'éludé. La connexion et la gestion d'un compte touchent des données d'identité qui doivent fonctionner depuis n'importe où ; ces deux surfaces sont donc globales par conception, tandis que tout ce qui concerne les messages et les destinataires ne l'est pas. Si vous documentez vos propres flux de données, cette séparation est la frontière à tracer.
La résidence décide-t-elle de la destination de mes messages ?
Non, et confondre les deux mène à une conclusion erronée dans les deux sens.
La résidence concerne le lieu de stockage et de traitement de vos données. La livraison concerne le lieu où se trouvent vos destinataires, ce qui dépend de la couverture, des règles locales et des sanctions. Une organisation eu1 peut envoyer à des destinataires partout où Bird livre, et une organisation us1 peut envoyer à des destinataires européens. Pays pris en charge et restrictions couvre le volet livraison.
Ce que la résidence décide, c'est où vit l'enregistrement de ce message après coup : le message lui-même, les données du destinataire, le journal d'événements. C'est généralement cet enregistrement qui est au cœur d'une question de protection des données.
Que faut-il décider dès le départ ?
La région, parce que c'est la seule partie que vous ne pouvez pas reprendre.
L'attribution étant immuable une fois confirmée, le choix de la région doit faire partie du processus de création de votre organisation de production, avec tout ce qui se décide une seule fois. Une organisation de test créée dans la mauvaise région est un désagrément mineur ; une organisation de production, c'est une migration.
Deux éléments connexes à régler en même temps, car ils vont de pair dans la plupart des revues : l'accord de traitement des données qui régit la relation, et l'endroit où le fournisseur publie sa liste de sous-traitants, car un sous-traitant dans une autre juridiction est une question de transfert à laquelle la résidence seule ne répond pas.
En bref
La résidence est une propriété de l'organisation, pas d'une requête.
La région est attribuée à l'inscription, peut être modifiée avant confirmation, et devient immuable ensuite dans la version actuelle de API.
Rien n'est répliqué entre les régions.
Espaces de travail, clés, messages, données de destinataires et journaux d'événements restent dans une seule région, ce qui donne son sens à un engagement de résidence.
La clé API porte sa région, et un hôte incorrect est refusé.
Une requête qui atteint la mauvaise région reçoit une réponse
421 Misdirected Requestindiquant le bon hôte, au lieu d'être redirigée silencieusement.Deux surfaces sont volontairement globales.
L'authentification et l'administration de compte reposent sur des données répliquées, ce qui explique qu'elles répondent sur un hôte indépendant de la région.