Il y a une question que tout backtest esquive : le même code, alimenté par le même marché en direct, aurait-il fait la même chose ? Impossible d'y répondre en backtestant davantage. La seule façon d'y répondre, c'est de faire tourner la stratégie sur des données en direct avec une vraie sémantique d'exécution, puis de vérifier — transaction par transaction — que les deux mondes concordent. Nous faisons cette vérification tous les jours, automatiquement, et c'est de loin le chasseur de bugs le plus productif de la plateforme.
Jour un : construire le miroir
Chaque stratégie promue tourne dans son propre nœud live isolé, alimenté par les vrais flux de l'exchange : cotations en direct pour les exécutions, spreads réels, horaires de séance réels. Aucun état partagé entre stratégies (nous l'avons appris à nos dépens — avec un nœud partagé, les requêtes de position d'une stratégie débordaient sur celles d'une autre). Chaque exécution est enregistrée avec la valeur du signal qui l'a produite.
Chaque matin : rejeu et comparaison
Un job quotidien reprend la fenêtre de paper trading de chaque stratégie, fait passer le code identique dans le moteur de backtest sur la même période à partir des données du catalogue, puis apparie les exécutions une à une : même sens, même tolérance d'horodatage, même taille. Le résultat n'est ni une corrélation ni une impression. C'est un tableau : appariées, paper uniquement, rejeu uniquement. Une stratégie en bonne santé affiche 54 appariées sur 55. Une stratégie malade vous dit exactement quelle transaction a divergé, et à quel moment.
Ce qui a cassé, dans l'ordre où ça a cassé
- Exécutions pendant le warmup. Le nœud live injectait de l'historique pour amorcer les indicateurs — et les stratégies dotées de gestionnaires de barres personnalisés tradaient joyeusement dessus. Les backtests n'ont jamais vu ces entrées fantômes. Le correctif s'est fait au niveau de la couche de soumission, pas dans la stratégie, car sinon chaque stratégie hérite du bug.
- Warmup séquentiel multi-jambes. Une stratégie cross-sectionnelle amorçait un instrument à la fois ; chaque jambe voyait ses jumelles vides et l'ancre n'était jamais initialisée. En live, elle ne tradait rien ; en rejeu, elle tradait très bien. Zéro transaction appariée — mais seule la comparaison l'a dit tout haut.
- Boucles de crash sur la précision des ticks. Les ticks aggTrade en direct arrivent avec une précision différente de celle attendue par l'instrument du sandbox. Le nœud partait en boucle de crash sur une assertion que le backtest ne pouvait jamais déclencher, puisque les barres du catalogue sont déjà normalisées.
- Amnésie au redémarrage. Les redémarrages de processus relançaient la logique d'entrée sur des positions déjà ouvertes — pour une stratégie de rééquilibrage, un redémarrage devenait discrètement un rééquilibrage. En trading réel, ce n'est pas une note de bas de page sur la parité : c'est un signal d'alarme avec de l'argent en jeu.
Notez le motif : aucun de ces bugs n'est un bug de signal. Ce sont tous des bugs de frontière d'exécution — warmup, état, précision, redémarrages. C'est exactement la classe de défaillance à laquelle les backtests sont structurellement aveugles, puisque dans un backtest le moteur est la frontière d'exécution.
Les asymétries que nous conservons volontairement
Les deux mondes ne sont délibérément pas identiques. Le backtest facture un demi-spread modélisé plus un impact en racine carrée à l'intérieur du PnL ; le paper paie le spread réel dans le prix d'exécution, sans modèle d'impact. Ajouter le spread modélisé au paper (ou le spread réel aux backtests) reviendrait à le compter deux fois. La parité signifie mêmes décisions, mêmes exécutions à la tolérance près — pas un PnL identique au bit près. Savoir quelles différences relèvent du principe et lesquelles sont des bugs, c'est l'essentiel de la discipline.
Un backtest est une hypothèse. Le paper trading est l'expérience. La parité de rejeu, c'est le cahier de laboratoire qui vous surprend en train de vous mentir à vous-même.
Si vous faites tourner des stratégies sans comparer régulièrement le comportement en direct au comportement rejoué, il existe toute une catégorie de bugs que vous n'avez jamais vus. Nous en trouvons un toutes les deux semaines environ, et chacun d'eux était invisible depuis l'intérieur du backtest.
← Tous les articles