Pourquoi les millisecondes comptent dans le trading crypto
Un carnet d'ordres perpétuel liquide change des centaines de fois par seconde. Chaque prix que vous voyez est déjà de l'histoire — la seule question est de savoir à quel point il est périmé. Cette obsolescence, c'est la latence : le temps d'aller-retour entre votre serveur de trading et le moteur d'appariement de l'exchange.
En arbitrage, les enjeux sont concrets. Une fenêtre de spread ne vit souvent que quelques centaines de millisecondes. Si votre ordre met 300 ms à atteindre l'exchange, le carnet a bougé au moment où il arrive — vous êtes exécuté à un moins bon prix, et le slippage grignote discrètement la marge que vous tentiez de capter.
La latence relève de la physique, pas du logiciel. Un signal en fibre de Francfort à Tokyo et retour prend environ un quart de seconde, quelle que soit l'optimisation de votre code. Le seul vrai remède est de rapprocher le serveur de l'exchange.
Où les exchanges crypto hébergent-ils réellement leurs serveurs
AWS Tokyo
La plupart des plateformes que nous couvrons font tourner leurs moteurs d'appariement dans une poignée de régions cloud en Asie. Binance, Gate.io, KuCoin, Bitget et HTX répondent le plus vite depuis AWS Tokyo (ap-northeast-1) ; MEXC et Hyperliquid y seraient également hébergés.
Singapore · Hong Kong
Bybit et Phemex sont hébergés à Singapour (ap-southeast-1). OKX et LBank sont les plus proches de Hong Kong (ap-east-1) : toutes deux répondent en moins de 40 ms depuis cette région.
Europe
L'Europe en héberge trois. Le moteur de Deribit est à Londres, WhiteBIT répond le plus vite depuis Francfort, et Poloniex répond lui aussi le plus vite depuis l'Europe. WhiteBIT paie la pénalité régionale la plus lourde du tableau : 46 ms depuis Francfort contre 300 à 500 ms depuis l'Asie.
Kraken
Kraken fait exception. Il répond en 18 à 64 ms depuis les huit régions mesurées : il n'y a donc aucun moteur d'appariement à côté duquel se placer. À lire comme une infrastructure rapprochée du client plutôt que comme un moteur unique dans une seule ville. La carte ci-dessous montre les quatre hubs d'hébergement.
Où vivent les matching engines
Les grands exchanges crypto se regroupent dans quatre hubs d'hébergement
Binance
Bitget
Gate.io
KuCoin
HTX
MEXC
Hyperliquid
Bybit
Phemex
OKX
Deribit
PoloniexLes hubs sont déduits de nos mesures de latence multi-régions ; les emplacements de MEXC et Hyperliquid sont des localisations publiquement rapportées.
La latence en chiffres
Nous avons mesuré le temps d'aller-retour d'un appel REST ticker vers chaque exchange depuis plusieurs régions AWS. Le constat est net : la même requête qui prend 10 à 35 ms depuis la région voisine du moteur d'appariement prend 200 à 500+ ms depuis le mauvais continent — un écart de 10 à 20×.
Considérez ces chiffres comme des allers-retours indicatifs pour comparer les régions, pas comme des garanties : les flux WebSocket sont plus rapides que REST en valeur absolue, mais les proportions régionales restent les mêmes.
Latence aller-retour : co-localisé vs mauvais continent
Appel REST ticker, mesuré depuis huit régions AWS
| Exchange | Le plus rapide depuis | Meilleure région | Pire région |
|---|---|---|---|
 Upbit |
Séoul ap-northeast-2 | ~10 ms | ~360 ms |
| DeribitArbitron |
Londres eu-west-1 | ~10 ms | ~464 ms |
 Bitvavo |
Francfort eu-central-1 | ~15 ms | ~996 ms |
| BybitArbitron |
Singapour ap-southeast-1 | ~16 ms | ~304 ms |
| Gate.ioArbitron |
Tokyo ap-northeast-1 | ~16 ms | ~381 ms |
 Kraken |
Francfort eu-central-1 | ~18 ms | ~64 ms |
 LBank |
Hong Kong ap-east-1 | ~18 ms | ~372 ms |
 Coinbase |
Singapour ap-southeast-1 | ~19 ms | ~84 ms |
| KuCoinArbitron |
Tokyo ap-northeast-1 | ~19 ms | ~509 ms |
 Bitstamp |
Francfort eu-central-1 | ~20 ms | ~337 ms |
 Bitfinex |
Francfort eu-central-1 | ~22 ms | ~118 ms |
 Okcoin |
Hong Kong ap-east-1 | ~22 ms | ~318 ms |
 Coincheck |
Tokyo ap-northeast-1 | ~23 ms | ~696 ms |
| BinanceArbitron |
Tokyo ap-northeast-1 | ~23 ms | ~424 ms |
 Coinone |
Séoul ap-northeast-2 | ~24 ms | ~367 ms |
| BitgetArbitron |
Tokyo ap-northeast-1 | ~24 ms | ~495 ms |
 EXMO |
Francfort eu-central-1 | ~24 ms | ~479 ms |
| PhemexArbitron |
Singapour ap-southeast-1 | ~25 ms | ~369 ms |
 ALP.COM |
Francfort eu-central-1 | ~25 ms | ~793 ms |
 Zaif |
Tokyo ap-northeast-1 | ~26 ms | ~400 ms |
 BitMEX |
Londres eu-west-1 | ~26 ms | ~362 ms |
 Bithumb |
Séoul ap-northeast-2 | ~27 ms | ~304 ms |
 LATOKEN |
Francfort eu-central-1 | ~28 ms | ~762 ms |
 Bitbank |
Tokyo ap-northeast-1 | ~31 ms | ~739 ms |
 HitBTC |
Francfort eu-central-1 | ~32 ms | ~517 ms |
 BTCBOX |
Tokyo ap-northeast-1 | ~34 ms | ~559 ms |
| OKXArbitron |
Hong Kong ap-east-1 | ~35 ms | ~440 ms |
 AscendEX |
Tokyo ap-northeast-1 | ~40 ms | ~498 ms |
 bitFlyer |
Tokyo ap-northeast-1 | ~44 ms | ~391 ms |
 Indodax |
Singapour ap-southeast-1 | ~46 ms | ~1180 ms |
 BigONE |
Hong Kong ap-east-1 | ~46 ms | ~338 ms |
 WhiteBIT |
Francfort eu-central-1 | ~46 ms | ~496 ms |
 CoinEx |
Tokyo ap-northeast-1 | ~47 ms | ~462 ms |
 CEX.IO |
Francfort eu-central-1 | ~49 ms | ~861 ms |
 BEQUANT |
Londres eu-west-1 | ~54 ms | ~855 ms |
 zondacrypto |
Francfort eu-central-1 | ~56 ms | ~1035 ms |
 ProBit Global |
Tokyo ap-northeast-1 | ~58 ms | ~491 ms |
 NovaDAX |
Londres eu-west-1 | ~58 ms | ~370 ms |
 Mercado Bitcoin |
N. Virginie us-east-1 | ~61 ms | ~277 ms |
 YoBit |
Francfort eu-central-1 | ~62 ms | ~439 ms |
 Foxbit |
N. Virginie us-east-1 | ~62 ms | ~388 ms |
 DigiFinex |
Hong Kong ap-east-1 | ~66 ms | ~460 ms |
| HTXArbitron |
Tokyo ap-northeast-1 | ~70 ms | ~392 ms |
 One Trading (Bitpanda Pro) |
Londres eu-west-1 | ~70 ms | ~1064 ms |
 Coinmate |
Londres eu-west-1 | ~72 ms | ~860 ms |
 Luno |
Londres eu-west-1 | ~77 ms | ~1285 ms |
 Binance.US |
N. Virginie us-east-1 | ~78 ms | ~383 ms |
| PoloniexArbitron |
Londres eu-west-1 | ~85 ms | ~437 ms |
 Bit2C |
Francfort eu-central-1 | ~104 ms | ~979 ms |
 Gemini |
Londres eu-west-1 | ~116 ms | ~338 ms |
 Bitso |
N. Virginie us-east-1 | ~121 ms | ~519 ms |
 OceanEx |
Hong Kong ap-east-1 | ~121 ms | ~385 ms |
 Independent Reserve |
Singapour ap-southeast-1 | ~159 ms | ~444 ms |
 BTC Markets |
Tokyo ap-northeast-1 | ~283 ms | ~450 ms |
 Paymium |
Francfort eu-central-1 | ~349 ms | ~1685 ms |
 BL3P |
Francfort eu-central-1 | ~468 ms | ~680 ms |
| MEXC *Arbitron |
Tokyo ap-northeast-1 | — | — |
| Hyperliquid *Arbitron |
Tokyo ap-northeast-1 | — | — |
* Localisation publiquement rapportée, non mesurée. Les chiffres sont des allers-retours REST indicatifs issus de nos mesures multi-régions — la plus rapide et la plus lente de huit régions AWS par exchange, pour comparer les régions, pas des SLA. Les exchanges disparus sont exclus.
Emplacement des serveurs par exchange
ALP.COM
AscendEX
BEQUANT
BigONE
Binance
Binance.US
Bit2C
Bitbank
Bitfinex
bitFlyer
Bitget
Bithumb
BitMart
BitMEX
Bitso
Bitstamp
Bitvavo
BL3P
BTC Markets
BTCBOX
Bybit
CEX.IO
Coinbase
Coincheck
CoinEx
Coinmate
Coinone
Deribit
DigiFinex
EXMO
Foxbit
Gate.io
Gemini
HitBTC
HTX
Independent Reserve
Indodax
Kraken
KuCoin
LATOKEN
LBank
Luno
Mercado Bitcoin
NovaDAX
OceanEx
Okcoin
OKX
One Trading (Bitpanda Pro)
Paymium
Phemex
Poloniex
ProBit Global
Upbit
WhiteBIT
YoBit
Zaif
zondacryptoComment la latence se transforme en slippage
La vie d'un ordre au marché : votre serveur voit un prix, décide, envoie l'ordre, et l'exchange l'apparie avec l'état du carnet au moment où il arrive. La latence taxe chaque étape. En 300 ms, un carnet de perpétuel liquide peut se renouveler entièrement — le prix sur lequel vous avez agi n'existe tout simplement plus.
Les dégâts ne sont pas théoriques. Dans nos mesures en production, une seule exécution sur des données périmées a coûté un jour près de 0,8 % de slippage — plusieurs fois un spread d'arbitrage typique. Un serveur bien placé en fait une erreur d'arrondi.
La distance dégrade aussi ce que vous voyez, pas seulement ce que vous envoyez : un serveur éloigné reçoit chaque mise à jour du carnet en retard, si bien que chaque décision est prise sur un carnet ancien. La co-location corrige les deux directions à la fois.
Choisir l'emplacement du serveur pour l'arbitrage à deux legs
Trader sur une seule plateforme est simple : placez le serveur dans la région voisine. L'arbitrage à deux legs est plus subtil, car les deux exchanges peuvent vivre dans des régions différentes — et les deux legs doivent être exécutés.
La bonne règle est de minimiser le pire leg, pas le meilleur. Un emplacement qui vous donne 16 ms vers un exchange et 200 ms vers l'autre est pire qu'un emplacement qui vous donne 25 à 90 ms vers les deux : le leg lent détermine votre vraie qualité d'exécution.
Exemples tirés du tableau ci-dessus : pour Binance + Bybit, Tokyo (≈23 / 91 ms) bat Singapour (≈206 / 16 ms). Pour OKX + Binance, Hong Kong équilibre les deux. Pour Deribit + Poloniex — tous deux hébergés en Europe — Londres est la seule réponse sensée.
Règle empirique : les deux plateformes à Tokyo → Tokyo. Plateformes asiatiques mixtes → Tokyo ou Hong Kong. Plateformes de dérivés européennes → Londres. En cas de doute, Tokyo couvre la plus grande part des grands exchanges. Vous pouvez voir quelles paires de plateformes affichent actuellement des spreads exploitables dans le scanner d'arbitrage en direct.
L'emplacement du serveur sur Arbitron
Votre propre serveur
Chaque compte Arbitron tourne sur son propre serveur de trading dédié avec sa propre adresse IP, placé dans les régions cloud où vivent les exchanges eux-mêmes — pas sur une infrastructure partagée à l'autre bout de la planète.
Vous choisissez la région
Vous pouvez choisir la région où votre serveur est déployé — Tokyo, Singapour, Hong Kong ou l'Europe — pour que les plateformes que vous tradez réellement soient à quelques millisecondes, et non à des continents de distance.
Aucun saut supplémentaire
Les données de marché et l'exécution des ordres circulent directement entre votre serveur et les API des exchanges, sans saut supplémentaire. Consultez comment fonctionne Arbitron pour l'architecture complète.
Comment ces chiffres ont été mesurés
Chaque valeur est la latence aller-retour d'un appel REST fetch_ticker(), moyennée sur 10 itérations sérielles, depuis la région AWS indiquée. Les chiffres incluent la négociation TLS et le traitement côté exchange, ils sont donc supérieurs au RTT réseau brut — ce qui compte est l'ordre entre régions, pas les millisecondes absolues.
Huit régions AWS ont été utilisées : Virginie du Nord, Californie du Nord, Francfort, Irlande, Hong Kong, Séoul, Singapour et Tokyo. À noter : eu-west-1 est l'Irlande, pas Londres — Londres est eu-west-2.
Comment citer
Arbitron. "Exchange Server Locations & Latency". 2026-09-22. https://arbitron.app/learn/crypto-exchange-server-locations
Réutilisable librement sous licence CC BY 4.0. Merci de créditer Arbitron avec un lien.