Une ligne de données de marché peut être parfaitement exacte et pourtant ne pas constituer un élément probant exploitable pour un backtest. La transaction a bien eu lieu, le prix est correct et l’horodatage est valide ; mais le flux a peut-être transmis l’information en retard, un fournisseur l’a peut-être corrigée après coup, ou le marché coté n’était peut-être pas accessible à votre stratégie.
Pour savoir si des données historiques étaient négociables, ne vérifiez pas seulement leur horodatage d’événement. Vous devez savoir ce que décrit la ligne, quand elle est devenue disponible pour le système, quelle plateforme ou quel instrument elle représente, et si la cotation ou la transaction pouvait raisonnablement servir à exécuter votre ordre.
Un prix historique exact suffit-il pour un backtest ?
Non. L’exactitude répond à la question : « Quel prix la source a-t-elle fini par enregistrer ? » Un backtest doit aussi répondre à celles-ci : « Qu’est-ce que ma stratégie pouvait savoir au moment de sa décision ? » et « Qu’est-ce qu’elle pouvait exécuter ? » Ce sont des questions distinctes.
Imaginez qu’une transaction crypto soit enregistrée à 12:00:00.120, mais que le flux de votre fournisseur de données ne la transmette à votre processus qu’à 12:00:00.480. Une stratégie qui prend une décision à .200 ne peut pas utiliser cette transaction, même si son horodatage d’événement précède la décision. Si le fichier historique ne conserve que l’heure de l’événement, le backtest peut attribuer discrètement à la stratégie une information que son processus en production n’aurait pas encore reçue.
| Heure ou champ | Ce que cela indique | Échec du backtest en cas d’absence |
|---|---|---|
| Heure de l’événement | Quand la plateforme indique que l’événement s’est produit | Confondre l’heure du marché et la disponibilité pour la stratégie |
| Heure de réception | Quand votre collecteur a reçu le message | Utiliser des données retardées comme si elles étaient arrivées instantanément |
| Séquence ou identifiant de mise à jour | La place de l’événement dans l’ordre du flux | Appliquer les mises à jour dans le désordre ou en omettre certaines sans le voir |
| Heure de révision | Quand une valeur historique corrigée est devenue connue | Effectuer le backtest avec une valeur absente du flux d’origine |
Si vos archives ne contiennent pas les heures de réception, reconnaissez cette lacune. Vous pouvez tester une hypothèse de latence ou limiter vos conclusions à une étude fondée sur l’heure des événements. Vous ne pouvez pas reconstituer exactement l’ensemble d’informations disponible à partir d’horodatages qui n’ont jamais été enregistrés.
Comment savoir si une cotation était exécutable ?
Commencez par le marché auquel votre ordre aurait été envoyé. La meilleure offre à l’achat et à la vente consolidée peut résumer plusieurs plateformes ; cela ne prouve pas que votre compte avait accès à la quantité affichée, que la cotation était toujours présente à l’arrivée de votre ordre, ni que la plateforme aurait accepté votre type d’ordre.
Pour un ordre au marché, un prix moyen d’exécution tient généralement de la fiction. Une estimation plus utile consiste à parcourir le carnet visible en fonction de la taille de l’ordre, puis à ajouter les frais et une hypothèse de latence ou d’impact. Si vous ne disposez que des données du meilleur niveau, limitez la portée de votre conclusion : vous pouvez estimer le premier niveau, mais pas déduire une profondeur qui n’a jamais été enregistrée.
Pour un ordre à cours limité, le fait que le prix soit touché ne signifie pas que l’ordre a été exécuté. Les ordres placés avant le vôtre peuvent d’abord absorber la quantité disponible. La position dans la file d’attente est généralement impossible à connaître à partir de snapshots ordinaires ; une règle d’exécution fondée sur le simple contact du prix doit donc être considérée comme un scénario optimiste, et non comme la preuve de ce qui s’est passé.
Une bougie de 1 minute peut vous indiquer que le plus bas a franchi votre limite. Elle ne vous dit pas si votre ordre en attente est arrivé sur la plateforme avant que le plus bas soit atteint, quelle quantité y a été échangée, ni quelle taille de file d’attente se trouvait devant vous.
Que dois-je vérifier avant de me fier à une archive de données de marché ?
Je commence par vérifier les propriétés les plus élémentaires. Elles révèlent davantage de recherches défectueuses qu’un modèle d’exécution sophistiqué ajouté à un flux défaillant.
- Couverture : Y a-t-il des intervalles manquants, des événements en double, des ruptures de séquence ou des pics inexpliqués de volume nul ?
- Identité du marché : Le symbole correspond-il toujours à la même plateforme, au même contrat, à la même devise de cotation et aux mêmes spécifications d’instrument au fil du temps ?
- Disponibilité : Les heures des événements et de réception sont-elles toutes deux conservées ? Sinon, quelle hypothèse de délai permet d’encadrer le résultat ?
- Corrections : Pouvez-vous distinguer le message d’origine des données ajoutées ou révisées ultérieurement par le fournisseur ?
- Unités : Les prix, les quantités, les multiplicateurs de contrat et les horodatages sont-ils interprétés de façon cohérente ?
Cette dernière vérification semble presque trop élémentaire. J’ai un jour passé une matinée à chercher une apparente évolution du régime de volatilité, qui s’est révélée due à un changement d’unité dans un champ de quantité après la migration d’un flux. Le graphique était magnifique ; l’unité, elle, était incorrecte.
Comment vérifier si la disponibilité des données change le résultat ?
Effectuez un petit test de sensibilité autour du seuil de décision de la stratégie. Décalez les données exploitables selon des délais réalistes, écartez les mises à jour dont la continuité de séquence est rompue, et comparez les exécutions en vous appuyant sur le carnet de la plateforme concernée lorsque vous en disposez. Présentez le résultat initial et le résultat dégradé. Si un léger délai suffit à effacer l’effet, la stratégie dépend peut-être d’un avantage informationnel que votre dispositif de collecte ne peut pas fournir de manière fiable.
Prenons un exemple concret : supposons qu’un signal se déclenche lorsque la meilleure offre à l’achat augmente d’un tick. Rejouez-le une fois avec l’heure de l’événement de la plateforme et une fois avec l’heure de réception du collecteur. Si la version fondée sur l’heure de l’événement génère 40 transactions, contre 27 pour celle fondée sur l’heure de réception, cet écart fait partie des éléments probants de la stratégie. La performance obtenue avec chaque rejeu en fait aussi partie. Ne dissimulez pas le rejeu le moins favorable sous prétexte que ses données sont moins élégantes.
Le trading simulé est une étape de vérification utile, car il révèle les retards de flux, les cotations périmées, les erreurs de correspondance des symboles et les filtres des plateformes dans le même circuit opérationnel que celui de votre système de recherche. Il ne reproduira toujours pas toutes les files d’attente ni tous les impacts sur le marché. Gardez cette limite à l’esprit.
Que signifie « données négociables » en pratique ?
Cela signifie que le backtest peut expliquer quand une observation s’est produite, quand la stratégie a pu l’utiliser, de quel marché elle provenait et quels éléments d’exécution étayent l’hypothèse de remplissage. Une série de prix propre constitue un point de départ. La recherche devient crédible lorsque ses hypothèses de temporalité, d’accès et d’exécution résistent à l’examen, et que le résultat reste cohérent même après les avoir rendues moins favorables.
← Tous les articles
