Latence cloud depuis 33 villes : 42 régions mesurées
42 régions cloud de Hetzner, OVHcloud, Vultr, Akamai et AWS mesurées depuis 33 villes : combien en faut-il, laquelle sert où, et pourquoi la route compte.
Où installer un serveur quand ses utilisateurs sont partout ? Les hébergeurs répondent avec la carte de leurs régions. Nous avons mesuré depuis l'autre bout : 33 villes sur six continents, vers 42 régions de 5 hébergeurs (Hetzner, OVHcloud, Vultr, Akamai Linode et AWS), deux fois dans la même journée. Chaque chiffre ci-dessous vient de ces mesures, et les données brutes sont libres de réutilisation.
Données brutes : cloud-latency-2026-09.csv (CC BY 4.0). Pour mesurer votre propre latence vers les mêmes hébergeurs depuis votre navigateur, utilisez notre test de latence cloud.
Ce qu'il faut retenir
- Aucune région ne sert le monde entier. La meilleure, Francfort, atteint 14 des 33 villes en moins de 100 ms, avec une médiane de 130 ms.
- Une deuxième région change tout. Francfort et Singapour : 27 villes sur 33 sous 100 ms, médiane 39 ms.
- Trois régions suffisent à un produit mondial. Francfort, Est des États-Unis et Singapour : 28 villes sur 33 sous 100 ms, et 9 villes sur 10 sous 114 ms.
- 7 lieux, un par grande région du monde, placent les 33 villes sous 67 ms.
- L'Amérique latine a besoin de sa propre région. Depuis nos villes d'Amérique latine, São Paulo répond en 31 ms ; le lieu suivant, Est des États-Unis, en 110 ms.
- Aucun hébergeur n'est le plus rapide partout. Mesuré par la même sonde aux deux passages, AWS Singapour a pris 239–321 ms depuis Paris, Stockholm et Istanbul, contre 156–201 ms pour l'hébergeur le plus rapide à Singapour. Depuis Berlin, AWS était le plus rapide.
- Les routes bougent dans la journée. Entre nos deux passages, Akamai Singapour est devenu plus rapide de 81 à 84 ms depuis 4 villes européennes à la fois, mesuré par les mêmes sondes.
- La distance n'explique pas tout. Johannesburg vers São Paulo a pris 351 ms au mieux, alors que la lumière dans la fibre n'a besoin que de 74 ms pour cette distance : les paquets passaient par l'Europe.
Où héberger, selon où sont vos utilisateurs
Pour chaque grande région du monde, la latence médiane depuis ses villes vers le meilleur lieu, puis vers le suivant. Chaque lieu retient le meilleur des hébergeurs présents : le tableau dit où héberger, pas chez qui.
| Où sont vos utilisateurs | Meilleur lieu (ms) | Ensuite (ms) |
|---|---|---|
| Europe Amsterdam, Berlin, Istanbul, Londres, Madrid, Milan, Paris, Stockholm, Varsovie | Francfort 14 | Paris / Roubaix 18 |
| Amérique du Nord Buffalo, Los Angeles, Toronto | Montréal / Toronto 12 | Est des États-Unis 15 |
| Amérique latine Buenos Aires, Mexico, São Paulo | São Paulo 31 | Est des États-Unis 110 |
| Afrique Fès, Johannesburg, Lagos, Nairobi, Tunis | Afrique du Sud 62 | Londres 104 |
| Moyen-Orient et Inde Delhi, Dubaï | Bombay 26 | Singapour 75 |
| Asie de l'Est et du Sud-Est Bangkok, Denpasar, Hô Chi Minh-Ville, Hong Kong, Jakarta, Manille, Séoul, Singapour, Taipei, Tokyo | Singapour 36 | Tokyo 64 |
| Océanie Sydney | Sydney 1 | Singapour 97 |
Combien de régions faut-il ?
Chaque ville est servie par le lieu le plus proche de l'ensemble. La médiane dit ce qu'obtient une ville typique ; la colonne « 9 villes sur 10 » dit jusqu'où cela se dégrade pour les moins bien servies, et c'est en général de cela que les utilisateurs se plaignent. Une réserve : nos 33 villes ne sont pondérées ni par la population ni par le trafic, donc l'ensemble qui gagne ici n'est pas forcément le meilleur pour votre public. C'est le tableau par région, plus haut, qui sert à décider.
| Lieux d'hébergement | Médiane (ms) | 9 villes sur 10 sous (ms) | Villes sous 100 ms |
|---|---|---|---|
| Francfort | 130 | 218 | 14 / 33 |
| Francfort + Singapour | 39 | 154 | 27 / 33 |
| Francfort + Singapour + Afrique du Sud | 38 | 97 | 30 / 33 |
| Francfort + Est des États-Unis + Singapour | 38 | 114 | 28 / 33 |
| Francfort + Montréal / Toronto + São Paulo + Afrique du Sud + Bombay + Singapour + Sydney | 27 | 60 | 33 / 33 |
Même ville, autre route
Comparer les hébergeurs ville par ville n'a de sens que si une même sonde les a tous mesurés, ce que Globalping ne garantit pas. Le tableau ne garde que les villes européennes où c'était le cas aux deux passages, avec le réseau de la sonde sous la ville. Chaque case donne le premier passage, puis le second.
| Depuis | AWS | Hetzner | Akamai (Linode) | OVHcloud | Vultr |
|---|---|---|---|---|---|
| Paris SCALEWAY | 239 / 254 | 165 / 165 | 239 / 156 | 163 / 163 | 156 / 168 |
| Stockholm Hollander & Jacobsen | 271 / 292 | 168 / 168 | 342 / 258 | 187 / 180 | 180 / 179 |
| Istanbul 2E TELEKOMUNIKASYON | 285 / 321 | 220 / 209 | 281 / 197 | 210 / 210 | 201 / 182 |
| Berlin IONOS | 171 / 168 | 182 / 185 | 185 / 187 | 186 / 188 | 180 / 190 |
| Varsovie OVH | 176 / 207 | 209 / 209 | 276 / 195 | – | 173 / 173 |
Les traceroutes pris pendant le second passage expliquent les cases lentes d'AWS. Depuis Paris, le chemin passait par NTT jusqu'à Ashburn et San José, aux États-Unis, puis Osaka, puis Singapour : 237 ms, presque le tour du monde. Depuis Stockholm et Istanbul, il passait par Tata Communications via Londres, New York et Tokyo. Les trois mêmes sondes atteignaient Vultr Singapour par Marseille puis directement Singapour, en 147–185 ms. La région AWS est la même pour toutes les villes ; ce qui change, c'est le chemin que prend le trafic de chaque départ. Un traceroute pris plus tôt depuis Berlin, lui aussi par NTT, partait vers l'est par Milan jusqu'à Singapour, et Berlin a obtenu le meilleur temps vers AWS.
Les routes bougent aussi. Depuis Paris, Akamai Singapour a répondu en 239 ms à 12 h 30 UTC et en 156 ms à 18 h 10 UTC, et un traceroute pris peu après montrait un chemin direct par le réseau de Telstra (156 ms). La même baisse est apparue depuis 4 villes européennes à la fois : le changement s'est donc très probablement produit du côté d'Akamai, plutôt que chez l'un des départs. Aucune page d'état ne l'a annoncé. C'est pour cela qu'une carte de latence d'hébergeur ne tranche pas la question, et qu'une route mérite d'être surveillée.
La distance n'explique pas tout
Johannesburg et São Paulo sont à 7 429 km l'une de l'autre, et des câbles sous-marins traversent directement l'Atlantique Sud (SACS relie l'Angola au Brésil). Le meilleur aller-retour mesuré a pourtant été de 351 ms, là où la lumière dans la fibre aurait besoin de 74 ms. Un traceroute de Johannesburg vers Vultr São Paulo passait par Le Cap, Londres et Newark avant d'atteindre le Brésil.
La région la plus rapide depuis chaque ville
La région la plus rapide mesurée depuis chaque ville, puis la suivante. Une valeur sous 2 ms signifie que la sonde de mesure se trouve dans le même centre de données que la région : elle ne dit rien des utilisateurs de la ville.
| Depuis | Région la plus rapide | ms | Deuxième (ms) |
|---|---|---|---|
| Amsterdam | OVHcloud Roubaix | 6 | Akamai (Linode) Francfort 7 |
| Berlin | Akamai (Linode) Francfort | 10 | AWS Frankfurt 11 |
| Istanbul | Vultr Francfort | 39 | AWS Frankfurt 45 |
| Londres | Akamai (Linode) Londres | 2 | Vultr Paris 8 |
| Madrid | AWS Paris | 18 | OVHcloud Roubaix 20 |
| Milan | Vultr Francfort | 10 | Akamai (Linode) Francfort 10 |
| Paris | Akamai (Linode) Paris | 1 | Vultr Paris 1 |
| Stockholm | Hetzner Helsinki | 7 | OVHcloud Roubaix 22 |
| Varsovie | Vultr Francfort | 20 | Akamai (Linode) Francfort 21 |
| Buffalo | Akamai (Linode) Toronto | 12 | OVHcloud Beauharnois 12 |
| Los Angeles | AWS us-west-1 | 11 | Akamai (Linode) Fremont 12 |
| Toronto | Akamai (Linode) Toronto | 1 | OVHcloud Beauharnois 8 |
| Buenos Aires | Vultr São Paulo | 31 | AWS São Paulo 33 |
| Mexico | Hetzner Ashburn | 56 | Akamai (Linode) Toronto 60 |
| São Paulo | Vultr São Paulo | 1 | AWS São Paulo 2 |
| Fès | Vultr Paris | 30 | Akamai (Linode) Paris 31 |
| Johannesburg | Vultr Johannesburg | 1 | AWS Cape Town 35 |
| Lagos | AWS Cape Town | 56 | Vultr Johannesburg 73 |
| Nairobi | Vultr Johannesburg | 62 | AWS Cape Town 73 |
| Tunis | AWS Paris | 27 | Akamai (Linode) Paris 32 |
| Delhi | Akamai (Linode) Bombay | 22 | AWS Mumbai 24 |
| Dubaï | AWS UAE | 11 | AWS Mumbai 30 |
| Bangkok | Akamai (Linode) Singapour | 27 | Hetzner Singapour 32 |
| Denpasar | Akamai (Linode) Singapour | 27 | Hetzner Singapour 29 |
| Hô Chi Minh-Ville | Akamai (Linode) Singapour | 37 | Vultr Singapour 42 |
| Hong Kong | AWS Singapore | 35 | Hetzner Singapour 35 |
| Jakarta | OVHcloud Singapour | 14 | Hetzner Singapour 14 |
| Manille | Vultr Singapour | 39 | Hetzner Singapour 39 |
| Séoul | Akamai (Linode) Tokyo | 31 | AWS Tokyo 34 |
| Singapour | Akamai (Linode) Singapour | 0 | Vultr Singapour 1 |
| Taipei | Vultr Tokyo | 33 | Akamai (Linode) Tokyo 36 |
| Tokyo | Akamai (Linode) Tokyo | 1 | Vultr Tokyo 2 |
| Sydney | Akamai (Linode) Sydney | 1 | Vultr Sydney 1 |
Mesurez-le depuis chez vos utilisateurs
Ces chiffres ont été mesurés depuis des serveurs. Pour voir ce qu'obtient votre propre connexion, lancez notre test de latence cloud dans votre navigateur : il chronomètre des requêtes vers 36 régions des mêmes hébergeurs. Pour voir le chemin, et pas seulement le délai, tracez la route depuis nos serveurs ou depuis 35 points de mesure dans 31 pays, et comparez.
Comment nous avons mesuré
- Sondes : une sonde Globalping par ville pour chaque mesure (Globalping peut choisir une autre sonde de la même ville d'une mesure à l'autre), le réseau que TraceMapper utilise pour ses 35 points de mesure. Notre point « New York » est une sonde située à Buffalo, dans l'État de New York, et s'appelle Buffalo ici.
- Cibles : les points de test publics que publie chaque hébergeur (42 régions). AWS bloque l'ICMP : AWS a donc été mesuré par des connexions TCP vers le port 443 de ses points d'accès DynamoDB régionaux ; toutes les autres cibles par ping ICMP.
- Échantillons : 4 paquets par couple. Un SYN TCP perdu est renvoyé au bout d'une seconde : les échantillons plus lents de 900 ms que le plus rapide ont été écartés, et la valeur est la médiane du reste. Deux passages le 26 septembre 2026 (vers 12 h 30 et 18 h 10 UTC) ; la valeur d'un couple est la médiane de ses passages.
- Contrôles : 2 726 mesures valides sur 2 772. Chaque valeur a été comparée au minimum dont la lumière a besoin dans la fibre sur la distance ; 2 répondaient plus vite et ont été exclues, car la réponse venait d'un équipement plus proche que le serveur (Los Angeles → Akamai (Linode) Paris; Los Angeles → Vultr Frankfurt). Chaque traceroute cité a été confronté au ping mesuré pour le même couple. Les mesures prises par une sonde située dans le réseau même de l'hébergeur visé ont aussi été exclues (39) : elles mesurent la dorsale de cet hébergeur, pas un chemin sur Internet. 124 des 1 375 couples ville et région ont varié de plus de 25 % entre les deux passages, surtout parce que Globalping a choisi une autre sonde dans la même ville ; le CSV contient les deux valeurs.
Limites
- De serveur à serveur. Les sondes Globalping sont surtout hébergées dans des réseaux d'hébergement. Un utilisateur sur une connexion résidentielle ou mobile ajoute son propre réseau d'accès.
- Une sonde par ville. Un autre réseau de la même ville peut prendre une autre route. Les constats de routage ci-dessus sont seulement ceux qui se sont vérifiés à chaque passage.
- Un instantané. Les routes changent d'une heure à l'autre ; deux passages dans une journée montrent la part stable, pas chaque variation.
- Pas un classement des hébergeurs. Un hébergeur plus lent depuis une ville est souvent plus rapide depuis une autre ; le tableau par région est la comparaison équitable.
Données
Les 2 772 mesures, y compris celles écartées avec leur motif, sont dans cloud-latency-2026-09.csv, sous licence CC BY 4.0. Réutilisez-les librement avec un lien vers cette page : « TraceMapper, Latence cloud depuis 33 villes (septembre 2026) ».