BJF TRADING GROUP · SHARPTRADER OPTIMIZER
La plupart des backtests d’arbitrage de latence publiés sont spectaculaires sur le papier et s’effondrent dès leur mise en production. La raison n’est pas une mauvaise logique de stratégie — c’est que les backtesters grand public standards supposent implicitement des exécutions à latence nulle. Ce guide explique précisément comment un temps d’exécution de l’ordre de la milliseconde change les calculs, et ce que votre backtest doit modéliser pour produire des résultats réellement exploitables en trading.
La rentabilité de l’arbitrage de latence se joue dans une fenêtre de 50 à 200 millisecondes. C’est la durée pendant laquelle l’écart de prix entre un flux rapide et un courtier lent reste généralement ouvert avant que la cotation du courtier lent ne se mette à jour. Si votre temps d’exécution aller-retour réel — de la détection du signal à la confirmation de l’exécution — consomme l’essentiel de cette fenêtre, il ne vous reste presque aucune marge. Les backtesters grand public standards supposent que les ordres sont exécutés instantanément au prix affiché, ce qui supprime entièrement ce problème de la simulation. Résultat : un backtest qui ressemble à une planche à billets et un déploiement réel qui perd sur chaque trade une fois le spread déduit.
Cet article quantifie cet écart, détaille où passent réellement les millisecondes et explique comment modéliser le temps d’exécution dans un backtest afin que les chiffres que vous obtenez correspondent à ceux que vous verrez sur un compte réel.
Vidéo : comment le temps d’exécution modifie un backtest d’arbitrage de latence — la même stratégie avec une latence d’exécution de 0 ms, 50 ms et 150 ms, analysée tick par tick.
Dans un système d’arbitrage de latence, la stratégie compare deux flux de cotations — un flux rapide (généralement un agrégateur tier-1 ou le flux d’un LP) et un flux lent (le courtier contre lequel vous tradez). Lorsque le flux rapide devance le flux lent de plus que le spread plus un seuil configuré, la stratégie envoie un ordre du côté lent, en anticipant la convergence du prix lent.
L’opportunité n’existe que tant que les deux prix sont désalignés. Dès que le moteur de cotation du courtier rattrape son retard — généralement en 50 à 200 millisecondes — l’avantage disparaît. Votre ordre doit être sur le marché avant que cela ne se produise.
Dans ce contexte, le « temps d’exécution » n’est pas un chiffre unique. C’est un empilement de latences, chacune ajoutant quelques millisecondes :
Pour une stratégie fonctionnant sur un VPS standard dans un autre centre de données que celui du courtier, l’aller-retour réaliste descend rarement sous 80–100ms. Pour une stratégie en colocation avec le courtier via un cross-connect, il peut tomber à 1–5ms. Cette différence d’un ordre de grandeur décide de tout.
Imaginez un signal net : le flux rapide bondit de 1,5 pip. Le courtier lent ne s’est pas encore mis à jour. Vous disposez en moyenne de 80 à 150 millisecondes avant que le moteur de cotation du courtier lent ne reflète le nouveau prix. Dans cette fenêtre, deux choses se produisent simultanément :
Si votre aller-retour consomme 50ms, vous arrivez alors que l’écart est encore intact à ~70 % et vous en capturez l’essentiel. S’il consomme 150ms, vous arrivez alors que l’écart s’est déjà réduit à ~10 % — et après spread + slippage, vous êtes probablement perdant.
La relation entre la latence aller-retour et le PnL de l’arbitrage n’est pas linéaire. En deçà de la fenêtre d’exécution, la rentabilité est élevée et stable. Au-delà, elle s’effondre à zéro ou devient négative. La plupart des traders particuliers se trouvent du mauvais côté de cette falaise sans le savoir, car leur backtest la masque.
Voici le même signal théorique d’arbitrage de latence avec un avantage de 1,5 pip, simulé avec quatre latences d’exécution aller-retour différentes. Les chiffres ci-dessous sont typiques de ce que vous observerez sur EUR/USD pendant la session de Londres, avec une liquidité normale et un spread de 0,6–0,9 pip.
| Exécution aller-retour | Avantage capturé | Slippage à l’entrée | PnL net par trade | Verdict |
|---|---|---|---|---|
| ~5ms (colocation) | ~95 % du signal | 0,0–0,2 pip | +0,6 à +1,0 pip | Rentable |
| ~50ms (VPS proche) | ~70 % du signal | 0,2–0,5 pip | +0,2 à +0,6 pip | Rentable, marge plus faible |
| ~120ms (distance moyenne) | ~30 % du signal | 0,5–1,0 pip | −0,3 à +0,1 pip | Marginal / perdant |
| ~200ms (longue distance) | ~10 % du signal | 1,0–1,8 pip | −1,0 à −0,5 pip | Perd sur chaque trade |
Observez la tendance : de 5ms à 50ms, la rentabilité baisse modérément. De 50ms à 120ms, elle s’effondre. Au-delà de 150ms, la stratégie devient un pile ou face à espérance négative une fois les frais déduits. Cette falaise est invisible pour un backtester qui suppose des exécutions instantanées.
Les backtesters grand public standards ont été conçus pour les systèmes de suivi de tendance et à base d’indicateurs — des stratégies dont les durées de détention vont de quelques minutes à plusieurs jours, et pour lesquelles quelques secondes de slippage d’exécution relèvent de l’erreur d’arrondi. Leur architecture le reflète :
Pour une stratégie qui conserve ses positions pendant des heures, cela ne pose pas de problème — le coût de ces simplifications reste bien inférieur à 1 % du PnL. Pour une stratégie d’arbitrage de latence qui gagne 1–3 pips par trade et dont le sort se joue dans une fenêtre de 100ms, chacune de ces simplifications est fatale :
Un écart de prix de 100ms est invisible à l’intérieur d’une barre M1 — la barre affiche l’OHLC, pas le flux de ticks intra-barre. Les backtesters à relecture en barres ne peuvent même pas détecter correctement les signaux d’arbitrage de latence.
Si les ordres sont exécutés au prix affiché au moment même de leur envoi, toute la fenêtre d’exécution de 50–200ms se réduit à zéro. Le backtest capture 100 % de chaque signal, à chaque fois. En réalité, on en capture 30 % à 95 % selon l’infrastructure.
Les véritables opportunités d’arbitrage se concentrent autour des annonces, du rollover et des périodes de faible liquidité — précisément lorsque le spread s’élargit de 3 à 5 fois. Les backtests à spread fixe comptabilisent des profits qui n’existeraient pas en conditions réelles.
L’arbitrage de latence clôture les positions aussi vite qu’il les ouvre. Les backtesters standards ignorent totalement le slippage à la clôture ou appliquent le même spread fixe, doublant ainsi l’optimisme irréaliste.
Pour produire un backtest qui résiste au contact d’un courtier réel, le simulateur doit modéliser explicitement chaque étape de l’aller-retour. Voici la décomposition dont un backtest sérieux d’arbitrage de latence a besoin :
| Composante | Plage typique | Ce qu’elle représente |
|---|---|---|
| 1. Latence signal-envoi | 0,5–20 ms | Temps entre la réception du tick déclencheur et l’émission d’un ordre. Dépend du langage, du chemin de code et du CPU. C++ compilé <1ms ; scripts de haut niveau 5–20ms. |
| 2. Aller-retour réseau (aller) | 1–80 ms | Temps de transmission entre votre serveur de trading et le courtier. Colocation = 1–3ms ; même zone métropolitaine = 5–15ms ; inter-régions = 30–80ms. |
| 3. Latence d’appariement du courtier | 3–100 ms | Temps passé dans le moteur de gestion et d’appariement des ordres du courtier. Courtiers ECN tier-1 : 3–15ms. Courtiers grand public standards : 30–100ms. Courtiers STP avec traitement manuel : 100ms+. |
| 4. Aller-retour de confirmation (retour) | 1–80 ms | Symétrique de la partie réseau aller. Tant que vous n’avez pas reçu la confirmation d’exécution, vous ne connaissez pas votre prix d’exécution — un point important pour la gestion du risque et le timing de la clôture. |
Pour un déploiement typique d’arbitrage de latence grand public, depuis un VPS générique et via un courtier grand public standard, les quatre composantes totalisent environ 80–180ms — en plein dans la zone de danger où la capture du signal tombe sous 50 %. Pour un déploiement en colocation via un courtier ECN rapide, les mêmes composantes totalisent 5–20ms — bien en deçà de la falaise.
Tout backtest honnête d’une stratégie d’arbitrage de latence devrait permettre au trader de configurer ces latences et d’en voir l’impact. SharpTrader Optimizer modélise la latence d’exécution sous la forme d’un paramètre configurable unique (en millisecondes), appliqué à chaque ordre lors de la simulation, sur la base de données de ticks historiques réelles.
Trois éléments doivent être réunis. Chacun est nécessaire ; aucun n’est suffisant à lui seul.
Les backtesters grand public standards génèrent des données « tick » en interpolant entre les valeurs OHLC des barres. Les ticks synthétiques ainsi produits atteignent le plus haut et le plus bas de la barre à des moments aléatoires, en évoluant de façon lissée entre l’ouverture et la clôture. Les marchés réels ne bougent pas ainsi — ils font des sauts. Le signal d’arbitrage de latence de 1,5 pip que vous cherchez à capter est un saut que les données de ticks interpolées lissent jusqu’à le faire disparaître.
Un backtest sérieux rejoue les ticks bid/ask réellement enregistrés depuis le moteur d’appariement du courtier (ou un flux de référence propre, comme des données institutionnelles provenant de Londres). Chaque tick possède un horodatage, un bid et un ask. La stratégie les voit dans le même ordre et avec le même timing qu’un déploiement réel.
Le trader configure le temps d’exécution aller-retour T (en millisecondes) qu’il s’attend à observer en réel. Lorsque la stratégie émet un ordre, le simulateur avance l’horloge de la partie correspondant à la requête — généralement T/2, car seul le temps entre le signal et l’appariement côté courtier influe sur le prix d’exécution (la partie réponse ne fait qu’informer la stratégie de ce qui s’est déjà produit). Si T = 80ms, le simulateur consulte le flux de ticks 40ms après le signal et utilise le bid/ask de ce tick — et non celui du tick ayant déclenché le signal — comme prix d’exécution.
Ce seul changement — avancer l’horloge entre le signal et l’exécution — reproduit la falaise à des latences réalistes. Il rend également le backtest déterministe : la même stratégie à T = 50ms et à T = 150ms sur le même flux de ticks produit des résultats sensiblement différents, et le trader peut voir exactement où la stratégie cesse de fonctionner.
Le slippage réalisé sur chaque exécution correspond à ce que produit le parcours des ticks — c’est un résultat de la simulation, et non un chiffre que le trader doit deviner. Certaines exécutions sont favorables (slippage positif), d’autres défavorables (négatif), et leur ampleur suit la volatilité réelle des ticks pendant ces millisecondes. C’est cette distribution réaliste qui manque à tous les backtesters grand public standards.
L’arbitrage de latence clôture aussi vite qu’il ouvre. La sortie intervient 200–800ms après l’entrée, sur un prix en convergence. Si le simulateur applique le même spread fixe à l’entrée et à la sortie, il manque deux choses : (1) le slippage d’entrée dû à la fenêtre de latence et (2) le slippage de sortie dû au retour du prix pendant l’aller-retour de clôture. Un vrai modèle vous permet de configurer le temps d’exécution indépendamment à l’ouverture et à la clôture — reflétant le comportement réel des courtiers, chez qui les sorties passent souvent par un circuit de routage plus lent — et calcule automatiquement le slippage de chaque jambe à partir du flux de ticks.
Voici un résultat représentatif d’une stratégie d’arbitrage de latence SharpTrader backtestée sur 30 jours de données de ticks EUR/USD, avec les mêmes paramètres mais trois configurations différentes de latence d’exécution. Les chiffres sont typiques de ce que nous observons dans les backtests BJF Feed (Londres / Tokyo / NY).
| Indicateur | 0ms (fictif) | 50ms (VPS proche) | 150ms (longue distance) |
|---|---|---|---|
| Signaux déclenchés | 2,847 | 2,847 | 2,847 |
| Signaux exécutés avec avantage | 2,847 (100%) | 1,983 (70%) | 854 (30%) |
| Pips capturés en moyenne | 1.42 | 0.98 | 0.21 |
| Slippage réalisé à l’entrée (résultat du parcours des ticks) | 0,0 pip | 0,3 pip | 0,9 pip |
| PnL net par trade | +0,82 pip | +0,48 pip | −0,31 pip |
| Rendement mensuel (1 lot) | +233% | +137% | −88% |
La colonne 0ms correspond au « fantasme de backtest » que produisent les outils standards. La colonne 50ms montre à quoi ressemble réellement une stratégie d’arbitrage de latence bien déployée. La colonne 150ms correspond à ce que la plupart des traders particuliers exécutent sans le savoir lorsqu’ils lancent une stratégie sur un VPS générique et tradent via un courtier standard sans réaliser où se situe leur aller-retour par rapport à la falaise.
La même stratégie peut être extrêmement rentable, à peine rentable ou systématiquement perdante — en fonction uniquement d’un chiffre qu’aucun backtester standard ne modélise.
La latence d’exécution est la variable la moins bien modélisée dans les backtests d’arbitrage de latence grand public, mais ce n’est pas la seule. Un backtest fiable combine trois éléments, chacun renforçant les autres :
Révèle la falaise. Vous indique l’infrastructure dont la stratégie a réellement besoin pour être rentable, et le point à partir duquel votre avantage disparaît.
Tient compte du fait que les opportunités d’arbitrage apparaissent précisément lorsque le spread s’élargit. Un backtest à spread fixe comptabilise des profits qui ne peuvent physiquement pas exister à ces moments-là.
Détecte les stratégies qui paraissent bonnes sur l’échantillon d’apprentissage parce que l’optimiseur a trouvé un jeu de paramètres collant au bruit de cette période. Sans walk-forward, votre backtest n’est qu’un CV tourné vers le passé.
Un trade d’arbitrage de latence comporte deux événements de slippage — à l’ouverture et à la clôture. La plupart des backtests n’en modélisent qu’un (voire aucun) et doublent l’optimisme.
Lorsque ces quatre éléments sont réunis, le backtest cesse d’être un outil marketing pour devenir un outil de prévision. Les chiffres qu’il produit cessent de s’écarter de 50–200 % des résultats réels et commencent à s’en approcher à 10–20 % près — suffisamment pour que les décisions de dimensionnement du risque, d’allocation du capital et de choix du courtier puissent réellement être prises sur la base du backtest.
Règle empirique du secteur : attendez-vous à un drawdown réel de 1,5 à 2 fois le drawdown du backtest. Pour les stratégies d’arbitrage de latence testées sur des backtesters standards, ce ratio est plutôt de 5 à 10 fois — car le backtest n’a modélisé ni la latence d’exécution, ni le spread variable, ni le slippage sur les deux jambes. Une fois ces éléments intégrés, la règle du 1,5–2x s’applique ; avant cela, le backtest n’a aucune valeur prédictive.
Lancez l’optimisation sur au moins trois configurations de latence : 10ms (meilleur cas, en colocation), 50ms (VPS proche) et 150ms (VPS générique, courtier éloigné). Si la stratégie n’est rentable qu’à 10ms, vous avez un problème de déploiement — il vous faut un plan de colocation avant de pouvoir la trader. Si elle est rentable à 50ms mais pas à 150ms, le choix du VPS et du courtier devient l’enjeu principal.
Trois niveaux : (1) faites un ping du point d’entrée des ordres de votre courtier depuis votre serveur de trading — vous obtenez l’aller-retour réseau brut ; (2) envoyez un petit ordre de test pendant une période calme et horodatez l’émission du signal et la confirmation d’exécution — la différence inclut la latence d’appariement du courtier ; (3) répétez sur plusieurs sessions — la latence varie selon la charge du courtier, l’heure de la journée et le routage. Le chiffre réaliste pour votre déploiement est la médiane d’un grand nombre de mesures, pas le meilleur ping.
Oui — avec des fenêtres encore plus étroites. Les fenêtres de trading sur annonces peuvent ne durer que 10–50ms. Le problème de l’écart de temps d’exécution est identique, simplement comprimé dans une fenêtre plus courte. La même infrastructure de backtest (ticks réels, latence d’exécution configurable, spread variable) est nécessaire, et la tolérance à la latence est encore plus faible.
Les deux phénomènes ont la même cause : les fournisseurs de liquidité deviennent incertains quant au prix et retirent leurs cotations. Lorsque le flux rapide bondit, les LP qui alimentent le courtier lent élargissent brièvement leurs cotations pour éviter d’être pris à contre-pied. Ainsi, le moment où l’écart apparaît est aussi celui où le spread à franchir pour le capter s’élargit. Un backtest à spread fixe ne le voit pas et surestime l’avantage net de 30–50 %.
Pour un arbitrage de latence de type institutionnel face à des courtiers ECN tier-1, oui — la compétition se joue désormais sous les 5ms d’aller-retour, ce qui exige un cross-connect ou un hébergement de proximité. Pour un arbitrage de latence de type grand public face à des courtiers plus lents, non — des allers-retours de 30–80ms peuvent encore produire un avantage, car la fenêtre du courtier lent est plus large. La bonne question n’est pas « la colocation est-elle nécessaire » mais « mon aller-retour tient-il dans la fenêtre du courtier contre lequel je trade ». C’est exactement la question à laquelle répond un backtest tenant compte de la latence d’exécution.
Pour les stratégies de suivi de tendance qui conservent leurs positions pendant des heures ou des jours, quelques centaines de millisecondes de latence d’exécution relèvent de l’erreur d’arrondi. Pour l’arbitrage de latence, ces mêmes millisecondes sont le signal tout entier. L’infrastructure de backtesting Forex classique est conçue pour le premier cas et produira silencieusement des résultats inutilisables pour le second. C’est pourquoi les outils de backtesting dédiés à l’arbitrage constituent une catégorie à part.
Ils changent la stratégie optimale, pas l’analyse. Les courtiers qui utilisent des plugins anti-arbitrage (exécution retardée, last-look, requote en cas de profit, rétention puis exécution) introduisent en pratique une latence d’exécution artificielle qui s’ajoute à la latence naturelle. Un backtest avec latence d’exécution configurable vous permet de simuler le comportement anti-arbitrage du courtier et de déterminer si la stratégie reste viable face à ce courtier — ou s’il vous faut changer de plateforme.
Pour une stratégie d’arbitrage de latence comportant 5–8 paramètres, une grille typique compte 30 000–100 000 combinaisons — dont 3–5 réglages de temps d’exécution comme l’une des dimensions balayées. L’objectif est de trouver des zones de rentabilité — des plages où la stratégie est rentable sur de nombreuses valeurs de paramètres, et non des pics isolés « chanceux ». Les pics isolés relèvent du surajustement ; les zones traduisent la robustesse. À titre de référence réaliste sur une station de travail grand public typique, une grille de 30 000 combinaisons sur 1 semaine de données de ticks XAUUSD avec un CPU 4 cœurs s’exécute en environ 12 heures ; la même grille prend environ 3 heures sur 16 cœurs. SharpTrader Optimizer traite plus de 100 000 combinaisons par exécution sur du matériel multi-cœur.
Il s’agit d’une observation empirique dans le trading algorithmique institutionnel : même un backtest bien modélisé sous-estime le drawdown réel d’environ 50–100 %, car certaines frictions du monde réel (rejets du courtier, gaps du week-end, changements de régime) ne peuvent pas être modélisées proprement. La règle suppose que le backtest intègre déjà une latence d’exécution réaliste, un spread variable et le slippage sur les deux jambes. Si ces éléments manquent, le multiplicateur est bien plus élevé — de 5 à 10 fois pour l’arbitrage de latence en particulier.
Conceptuellement, c’est identique. La fenêtre de temps d’exécution en arbitrage crypto inter-exchanges est généralement de 200ms–2s (plus lente que sur le Forex, car les exchanges sont plus éloignés et leurs carnets d’ordres sont plus profonds mais se mettent à jour plus lentement). Les trois mêmes ingrédients — relecture des ticks, latence d’exécution configurable, spread variable — produisent des backtests honnêtes. Les outils d’arbitrage crypto de BJF utilisent la même architecture, adaptée aux API des exchanges et à la profondeur des carnets d’ordres.
SharpTrader Optimizer est le seul backtester accessible aux particuliers qui modélise un temps d’exécution configurable, la relecture de ticks réels, un spread variable par tick et un slippage résolu au tick sur les deux jambes — les quatre variables qui déterminent si une stratégie d’arbitrage de latence est réelle ou fictive. L’optimisation en grille multi-cœur sur plus de 100 000 combinaisons de paramètres s’exécute en quelques heures, et non en plusieurs jours.