Votre backtest a un problème d’horloge, même si chaque horodatage est exact

Le bug de timing le plus dangereux d’un backtest peut passer inaperçu même après un audit parfait des horodatages. Deux événements peuvent tous deux indiquer 10:00:00.000 et pourtant s’être produits dans un ordre que votre simulateur a deviné.

C’est important dès qu’une stratégie réagit à autre chose qu’à des bougies clôturées : une mise à jour de cotation, une transaction, une annonce de financement, un changement de statut d’une plateforme ou l’accusé de réception de son propre ordre. Un horodatage indique quand un événement est daté. Il ne dit pas nécessairement quand votre stratégie pouvait agir.

Qu’est-ce que l’ordre des événements change ?

Imaginons une stratégie qui achète lorsque la meilleure offre de vente passe sous 100,00 $. Au cours de la même milliseconde, le flux enregistre une mise à jour de l’offre à 99,99 $ et une transaction à 99,99 $. Si votre backtest traite d’abord la transaction, puis la cotation, la stratégie voit la nouvelle offre et passe un ordre. Traiter d’abord la cotation peut aussi convenir, à condition que l’événement ait réellement été disponible. Mais si la transaction a consommé la liquidité affichée avant l’arrivée de l’ordre, une exécution à 99,99 $ est fictive.

Trier les lignes uniquement par horodatage laisse le simulateur choisir une séquence pour les événements simultanés. L’ordre du fichier, celui des symboles ou le plan d’exécution d’une requête de base de données peuvent devenir une règle d’exécution accidentelle. La courbe de capital peut changer alors que les données sous-jacentes restent identiques.

Voici une bonne façon de voir à quel point cela peut être arbitraire : triez les événements de même heure par nom de symbole au lieu de les trier selon leur ordre d’arrivée. Une stratégie multi-actifs peut alors se comporter différemment simplement parce qu’un ticker vient avant un autre dans le tri.

Quelles horloges un backtest doit-il conserver ?

Les données de marché et le traitement des ordres font souvent intervenir plusieurs heures distinctes. Conservez les champs fournis par votre source et nommez précisément leur signification. Pour de nombreux flux, l’horodatage de la plateforme et l’heure de réception locale sont tous deux utiles ; aucun ne représente une vérité universelle sur ce que chaque participant a vu.

Pour les données historiques sans heure de réception, indiquez vos hypothèses. Un backtest peut traiter les événements de la plateforme selon leur séquence et imposer un délai fixe de 5 ms entre la décision et l’arrivée de l’ordre. C’est un modèle, pas une reconstitution de l’historique. Si vous n’avez pas de numéros de séquence pour les événements portant le même horodatage, votre règle de départage est elle aussi une hypothèse.

Comment modéliser les événements simultanés ?

D’abord, conservez les numéros de séquence de la source lorsqu’ils existent. Un numéro de séquence définit un ordre plus fiable au sein de son flux qu’un horodatage, même si les espaces de séquence peuvent être distincts selon les canaux ou les produits.

Ensuite, explicitez la règle de traitement du simulateur. Pour chaque événement, déterminez s’il peut mettre à jour les informations de la stratégie, modifier la liquidité disponible, déclencher un ordre ou en accuser réception. Ce sont des actions différentes ; les réduire à « traiter la ligne » est la façon dont des exécutions impossibles se glissent dans le backtest.

1. N’appliquez que les informations de marché arrivées avant l’heure de décision de la stratégie.
2. Générez l’ordre, puis faites avancer le temps jusqu’à son heure d’arrivée modélisée sur la plateforme.
3. N’autorisez l’exécution que contre la liquidité admissible après l’arrivée, selon les hypothèses d’exécution propres à ce type d’ordre.
4. Consignez les entrées, l’ordre des événements et le délai utilisés pour chaque exécution simulée.

Pour une stratégie fondée sur des bougies, tout cela peut être plus complexe que nécessaire. Si le signal utilise des bougies 1-minute clôturées et que les ordres sont exécutés à l’ouverture de la bougie suivante avec un modèle de coûts prudent, l’ordre des événements à la sous-milliseconde ne changera probablement pas la conclusion de la recherche. L’essentiel est d’adapter le niveau de détail temporel à ce qu’affirme le backtest.

Puis-je me fier à un backtest sans données sur l’heure d’arrivée ?

Vous pouvez tout de même l’utiliser, mais gardez ses limites bien visibles. Si la stratégie intervient lentement et prévoit des limites de risque larges, quelques millisecondes peuvent être négligeables. Si elle réagit à des cotations éphémères, se dispute une position dans la file d’attente ou dépend d’un signal d’avance-retard entre plateformes, l’absence des heures d’arrivée peut être déterminante pour le résultat.

Les critiques ont raison : une précision temporelle poussée peut donner une fausse impression de précision. Les flux historiques sont incomplets, les horloges dérivent et les horodatages des plateformes ne révèlent pas chaque saut réseau. Un simulateur doté de champs à la nanoseconde peut tout de même reposer sur une hypothèse d’exécution grossière.

Testez donc la sensibilité au lieu de prétendre à la certitude : rejouez avec des règles plausibles de départage des événements et des délais d’ordre, puis comparez le nombre de transactions, le prix d’exécution et les signaux qui résistent. Si le résultat dépend d’une séquence que les données ne permettent pas d’établir, cette dépendance doit figurer dans le rapport de recherche. Un backtest peut être utile même avec une horloge imparfaite. Il doit simplement reconnaître ce qu’il sait réellement de l’heure.