Le signal était juste. Notre backtest d’options a acheté la mauvaise échéance.

À 10:07 un mardi, notre agent de recherche a détecté une configuration haussière à court terme sur un ETF indiciel. Le signal sous-jacent était classique : le cours avait repassé sa moyenne sur 20 barres, la volatilité réalisée diminuait et une publication macroéconomique était prévue à la prochaine séance. La stratégie proposée était un call spread arrivant à échéance dans environ deux semaines.

Le backtest l’a validé. La stratégie papier ne l’a pas exécuté. En comparant les ordres, nous avons constaté que les horodatages des signaux correspondaient et que les cours du sous-jacent ne différaient que de quelques centimes. Les contrats, eux, étaient différents : le backtest avait acheté l’échéance du vendredi qui semblait la plus intéressante dans la chaîne historique ; le processus papier avait retenu la prochaine échéance cotée, une semaine plus tard.

L’écart venait d’une jointure de calendrier. Nous avions traité le « nombre de jours avant l’échéance » comme une propriété de la date, puis sélectionné le contrat dont l’échéance était la plus proche de la cible. Dans les données historiques, le calendrier comprenait une échéance hebdomadaire ajoutée après la date étudiée. Le backtest avait utilisé un contrat futur, ce qui semblait être une simple commodité.

Nous avons d’abord soupçonné un problème de fuseau horaire. Les dates d’échéance des options sont particulièrement propices à ce genre d’erreur : la séance se termine à New York, les horodatages des marchés peuvent être stockés en UTC et une date à minuit peut changer lorsqu’un pipeline la convertit sans précaution. Nous avons vérifié : les horodatages étaient corrects. Le contrat n’existait tout simplement pas dans l’univers historique ce mardi-là.

Première leçon : une chaîne d’options historique doit refléter l’univers des contrats cotés à chaque instant. La date d’échéance d’un contrat indique quand il prend fin. Elle ne dit ni quand il a été coté, ni quand il est devenu négociable, ni si votre système aurait pu le sélectionner à ce moment-là.

Nous avons reconstruit l’étape de sélection à partir des informations disponibles à l’horodatage de la décision. Pour chaque contrat candidat, nous avons exigé un horodatage de cotation antérieur ou égal à la décision, une cotation valide datant de moins que notre seuil de fraîcheur et une séance de marché pendant laquelle la stratégie pouvait transmettre un ordre. Nous avons aussi enregistré l’ensemble des candidats avant de les classer. Ce dernier point était essentiel : l’ancien backtest ne conservait que le gagnant, et nous ne pouvions pas savoir s’il avait comparé cinq contrats admissibles ou choisi discrètement dans un calendrier encore inexistant.

Nous avons ensuite examiné la cotation utilisée pour évaluer le spread. Le backtest avait échantillonné séparément la dernière cotation de chaque jambe. L’ask du call datait de 10:06:58 ; le bid du call vendu, de 10:04:11. Les deux étaient techniquement assez récents selon la politique générale sur les données, mais le marché avait évolué entre les deux. Un prix moyen du spread calculé à partir de jambes désynchronisées peut décrire un marché qui n’a jamais existé.

Nous avons modifié la règle de cotation pour exiger que les horodatages des deux jambes soient espacés de 2 secondes au maximum et pour rejeter les marchés croisés ou sans volume affiché. Le nombre d’observations historiques utilisables a diminué. Les prix restants étaient toutefois plus crédibles. En l’absence de cotation synchronisée, nous déclarions le candidat indisponible au lieu de combler le manque par un prix périmé.

Restait la règle de classement. L’agent avait choisi l’échéance dont le coût coté du spread était le plus bas. Cela semble logique, jusqu’à ce que le spread ne porte que sur un contrat et que la cotation soit périmée. Nous avons explicité l’objectif : maximiser le rendement attendu par unité de risque défini parmi les contrats qui satisfont aux exigences minimales de taille affichée, de fraîcheur et de cotation. Dans cet exemple, l’échéance admissible la plus proche avait une largeur cotée de 0,42 $ sur les deux jambes, contre 0,31 $ pour l’échéance suivante. Le choix qui semblait moins cher n’affichait qu’un seul contrat sur la jambe courte.

Nous avons rejoué l’incident avec ces règles. Le backtest a alors choisi la même échéance que la stratégie papier et enregistré les raisons du rejet des autres contrats. Le prix d’entrée du spread était moins favorable de 0,11 $ que le prix d’exécution historique initial. Cela ne signifiait pas que la stratégie était sans valeur ; cela signifiait que l’ancien résultat incluait une sélection de transaction que le processus réel ne pouvait pas reproduire.

Un petit casse-tête : les formats de symboles des marchés font passer les erreurs d’échéance pour des problèmes de qualité des données. Nous avons trouvé un code hebdomadaire chez un fournisseur qui différait du code mensuel d’un seul caractère. Je conserve toujours le symbole brut à côté de la clé de contrat normalisée dans les journaux d’audit. Ce n’est pas très élégant, mais cela nous évite de faire trop vite confiance à une jointure bien propre.

Si vous construisez un backtest d’options, enregistrez l’ensemble complet des candidats à chaque décision, avec le statut de cotation de chaque contrat, les horodatages et tailles des cotations, ainsi que le motif de rejet. Faites ensuite de la sélection des contrats une fonction déterministe de cet instantané. Le choix de l’échéance fait partie de la stratégie. Si le backtest voit un contrat inaccessible à la stratégie papier, la comparaison des signaux commence après que le résultat a déjà changé.