Le calcul de latence : ce que la physique impose
La lumière dans le vide voyage à 299 792 km/s. Dans la fibre optique, elle voyage à environ 2/3 de cette vitesse — soit autour de 200 000 km/s, ou ~5 ms par 1 000 km en aller simple. Le RTT (temps d'aller-retour) est le double : ~10 ms par 1 000 km de fibre. Les chemins fibre réels font généralement 1,3 à 2 fois la distance grand cercle, prévoyez donc une latence supplémentaire pour les réalités de routage.
La lumière ralentit dans le verre à cause de l'indice de réfraction. L'indice de réfraction de la fibre monomode est d'environ 1,467, donc la vitesse de la lumière dans la fibre est c/1,467 ≈ 204 300 km/s. Cela donne une latence aller simple d'environ 4,9 ms par 1 000 km de fibre et un RTT d'environ 9,8 ms. C'est un plancher physique strict — aucune ingénierie ne peut battre la vitesse de la lumière. Une règle plus utile pour la planification : prévoyez 1 ms par 100 km en aller simple, plus 1 à 2 ms de surcoût de commutation et de routage par saut réseau. Les câbles sous-marins long-courrier sont bien conçus et approchent du minimum théorique (Londres-New York fait environ 70 ms RTT, près de la limite grand cercle de 5 500 km). Le dernier kilomètre et les chemins intra-ville font souvent 5 à 15 ms à cause des sauts de routeurs et de la géométrie de peering des FAI plutôt que de la distance.
Estimations RTT réelles entre grandes villes
Temps d'aller-retour (RTT complet) approximatifs entre grands hubs d'hébergement en 2026 : Londres-Amsterdam ~10 ms, Londres-Frankfurt ~15 ms, Londres-New York ~70 ms, New York-San Francisco ~70 ms, Frankfurt-Singapour ~160 ms, Londres-Sydney ~250 ms, Tokyo-San Francisco ~100 ms. Ce sont des valeurs typiques mesurées TCP-à-TCP entre pairs en datacenter dans le meilleur des cas fibre.
Ces chiffres proviennent des données de peering publiques publiées par les principaux IXP (LINX, AMS-IX, DE-CIX, KINX) et des grands atlas de latence (RIPE Atlas, WonderNetwork, Cloudping). Votre RTT réel variera de 10 à 30 % selon l'heure, les relations de peering entre votre fournisseur et le FAI de l'utilisateur, et le chemin de câble sous-marin emprunté. Les chiffres ci-dessus sont typiques, non garantis, et supposent les deux extrémités dans des datacenters avec un transit multi-Tbps. Les connexions résidentielles du dernier kilomètre ajoutent encore 5 à 30 ms au-dessus du plancher datacenter-à-datacenter.
| De | Vers | Distance (grand cercle) | RTT typique |
|---|---|---|---|
| Londres | Amsterdam | 360 km | ~10 ms |
| Londres | Francfort | 640 km | ~15 ms |
| Londres | Paris | 340 km | ~10 ms |
| Francfort | Varsovie | 900 km | ~20 ms |
| Londres | New York | 5 570 km | ~70 ms |
| New York | Miami | 1 760 km | ~30 ms |
| New York | San Francisco | 4 140 km | ~70 ms |
| San Francisco | Tokyo | 8 280 km | ~100 ms |
| Francfort | Singapour | 10 290 km | ~160 ms |
| Londres | Sydney | 16 990 km | ~250 ms |
| Francfort | Mumbai | 6 580 km | ~110 ms |
| São Paulo | Miami | 6 580 km | ~120 ms |
Résidence des données : RGPD, CLOUD Act et le reste
Les données personnelles UE/EEE relèvent du RGPD (Règlement (UE) 2016/679), qui restreint les transferts hors EEE sans garanties spécifiques. Le US CLOUD Act (2018) autorise les autorités américaines à contraindre les fournisseurs basés aux États-Unis à divulguer des données, peu importe où elles sont physiquement stockées. La Russie et la Chine ont leurs propres régimes de localisation. Choisissez une région de datacenter qui correspond à la fois aux juridictions de vos utilisateurs et à vos obligations contractuelles.
Le RGPD (en vigueur depuis mai 2018) considère toute donnée personnelle de résidents UE ou EEE — nom, e-mail, adresse IP, données comportementales — comme régulée, peu importe le lieu de siège du responsable de traitement. Les transferts transfrontaliers exigent une décision d'adéquation, des clauses contractuelles types ou des règles d'entreprise contraignantes. Les dérogations de l'article 49 sont étroites. L'arrêt Schrems II (Cour de justice de l'Union européenne, juillet 2020) a invalidé Privacy Shield et resserré considérablement les garanties de transfert. Le US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) permet aux autorités fédérales américaines d'obliger tout fournisseur basé aux États-Unis à produire des données stockées, même si elles sont sur un serveur à Francfort. Cela crée une tension pour les clients européens utilisant des hébergeurs basés aux États-Unis, peu importe où leurs données vivent physiquement. La loi fédérale russe n° 242-FZ exige que les données personnelles des citoyens russes soient initialement traitées sur des serveurs physiquement en Russie. La PIPL chinoise (Personal Information Protection Law, en vigueur depuis novembre 2021) exige la localisation pour les opérateurs d'infrastructures d'information critiques et pour les responsables de traitement à fort volume. Aucun de ces régimes ne se soucie du lieu où tournent vos serveurs applicatifs ; tous se soucient du lieu où les données personnelles sont stockées et traitées.
Quand le multi-région a du sens
Le multi-région se justifie lorsque vous avez des utilisateurs géographiquement répartis avec des exigences de latence sous 100 ms, lorsque vous avez des obligations de résidence des données dans plusieurs juridictions, ou lorsque le risque d'indisponibilité mono-région est inacceptable. Il se justifie rarement pour des projets de loisirs, des SaaS à faible trafic avec utilisateurs dans une seule région, ou des charges où la complexité d'ingénierie l'emporte sur les gains de latence.
Le multi-région ajoute trois coûts concrets. D'abord, la complexité d'ingénierie : la réplication des données (cohérence éventuelle ou synchronisée mondialement), la logique de routage (geo-DNS, anycast, basculement régional) et l'observabilité multi-région multiplient toutes la surface opérationnelle. Ensuite, le coût d'infrastructure : au moins le double du compute et du stockage, plus des frais de transit inter-régions facturés au Go par les fournisseurs cloud. Enfin, les compromis de cohérence : les écritures synchrones à l'échelle mondiale sont physiquement limitées par le calcul de latence de la section précédente, donc la plupart des conceptions multi-régions acceptent une forme de cohérence éventuelle. Justifications qui valent le coût : utilisateurs réels répartis sur plusieurs continents où une latence de 200+ ms massacre la conversion ; exigences de RTO inférieures à la seconde pour la reprise ; obligations réglementaires de garder simultanément les données UE en UE et US aux US ; ou exigences de haute disponibilité actif-actif où toute panne d'un datacenter doit rester invisible. La plupart des charges en production n'en ont pas besoin ; beaucoup de conceptions surenchérissent dans cette direction.
Arbre de décision : comment choisir une région
Étape 1 : identifiez où vivent 80 % de vos utilisateurs (analytics, journaux CDN, marché cible attendu). Étape 2 : choisissez la région d'hébergement la plus proche. Étape 3 : vérifiez que la juridiction correspond à vos obligations de résidence des données. Étape 4 : ajoutez une seconde région uniquement si l'étape 1 révèle un second cluster d'utilisateurs à plus de 100 ms RTT du premier, ou si les exigences HA/PRA l'imposent.
Parcourez l'arbre honnêtement. Pour un SaaS européen typique avec utilisateurs principalement en Allemagne, France, Royaume-Uni et Pays-Bas, un seul datacenter en Europe occidentale (Francfort, Amsterdam ou Londres) maintient chaque utilisateur sous 30 ms RTT et satisfait proprement le RGPD. Pour un produit B2B américain avec utilisateurs de Boston à Los Angeles, un seul datacenter US East (Ashburn, NYC) maintient les utilisateurs côte Est sous 20 ms et la côte Ouest sous 80 ms — mauvais pour le gaming, suffisant pour la plupart des SaaS. Pour des produits réellement mondiaux (applications web avec utilisateurs sur tous les continents), une région principale plus un CDN à présence mondiale bat habituellement un actif-actif sur trois datacenters. Pour des produits avec exigences strictes de résidence dans plusieurs juridictions (un plan de données strictement UE et un strictement US), le multi-région devient obligatoire indépendamment de la latence.
Raccourcis de conformité : certifications qui veulent vraiment dire quelque chose
Cherchez ISO/IEC 27001 (système de management de la sécurité de l'information), SOC 2 Type II (contrôles opérationnels audités dans le temps, pas à un instant donné) et PCI DSS niveau 1 (données de paiement) lorsque c'est applicable. Pour les clients UE, exigez explicitement un avenant de traitement des données (DPA) RGPD et une liste claire de sous-traitants. Le marketing générique « sécurité de classe entreprise » sans certifications nommées est essentiellement vide.
Trois certifications portent un vrai poids. ISO/IEC 27001:2022 est la norme internationale pour les systèmes de management de la sécurité de l'information et exige un audit indépendant et des audits de surveillance continus. SOC 2 Type II audite les contrôles d'une organisation sur une fenêtre d'observation de 6 à 12 mois, ce qui le distingue du Type I (instantané). PCI DSS s'applique si vous traitez des cartes de paiement ; le niveau 1 concerne les organisations traitant 6+ millions de transactions/an. Pour les clients européens, le DPA RGPD (avenant de traitement des données) est contractuellement contraignant et liste précisément ce que le fournisseur peut et ne peut pas faire avec vos données. Au-delà, cherchez les rapports de transparence (à quelle fréquence le fournisseur reçoit-il des demandes des autorités ?), une liste publiée de sous-traitants (tiers touchant vos données) et des garanties claires de suppression à l'issue du contrat. Des formules génériques comme « sécurité de niveau bancaire » ou « chiffrement de niveau militaire » ne disent rien — l'algorithme AES-256 sous-jacent est partout le même.