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
La plupart des grandes plateformes font tourner leurs moteurs d'appariement dans une poignée de régions cloud en Asie. Binance, Gate.io, KuCoin, Bitget, HTX et CoinEx répondent le plus vite depuis AWS Tokyo (ap-northeast-1) ; MEXC et Hyperliquid y seraient également hébergés.
Bybit et Phemex sont hébergés à Singapour (ap-southeast-1). OKX et BitMart sont les plus proches de Hong Kong (ap-east-1).
Les vétérans des dérivés vivent en Europe : le moteur de Deribit est à Londres, BitMEX tourne sur AWS Dublin, et Poloniex répond lui aussi le plus vite depuis l'Europe. La carte ci-dessous montre les quatre hubs d'hébergement.
Où vivent les moteurs d'appariement
Les grands exchanges crypto se regroupent dans quatre hubs d'hébergement
Binance
Bitget
Gate.io
KuCoin
HTX
CoinEx
MEXC
Hyperliquid
Bybit
Phemex
OKX
BitMart
Deribit
BitMEX
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.
Comment 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 + BitMEX — la paire inverse classique — 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.
L'emplacement du serveur sur Arbitron
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 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.
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.











































