La stratégie a passé ses tests. Puis la plateforme a changé son pas de cotation.

À 08:00 UTC un mardi, une plateforme crypto a modifié le pas de cotation d’un contrat perpétuel à prix moyen. Notre stratégie de base ne s’en est pas aperçue. Son signal voyait toujours le même écart entre le spot et les contrats à terme, ses limites de risque n’avaient pas changé et son backtest affichait toujours les mêmes résultats.

Le trading simulé, lui, l’a remarqué. L’adaptateur d’ordres a arrondi un ordre d’achat à cours limité vers le bas, au prix autorisé le plus proche. L’ordre se retrouvait ainsi un pas de cotation en dessous du niveau modélisé par le backtest. Le marché a touché l’ancien prix, l’ordre simulé a été exécuté, tandis que l’ordre en trading simulé est resté en attente. À l’heure du déjeuner, l’inventaire de la stratégie était déséquilibré.

L’incident semblait relever d’un petit problème d’arrondi. En réalité, il venait d’une frontière entre modèles : la stratégie connaissait les prix, mais le backtest ignorait la grille de prix de la plateforme.

Nous négociions un simple signal de base : acheter au comptant et vendre un contrat perpétuel lorsque la prime des contrats à terme dépassait un seuil. Les ordres étaient passifs, car l’avantage attendu sur la base était faible. Quelques pas de cotation pouvaient déterminer si l’entrée rapporterait assez pour couvrir les frais et la sortie ultérieure.

Qu’est-ce qui a changé avec le pas de cotation ?

Avant la mise à jour, le contrat perpétuel acceptait des prix par incréments de 0.01. Après, il acceptait des incréments de 0.05 dans la bande de prix concernée. Le signal calculait un prix cible de vente de 42,318.03, valide selon l’ancienne règle. Avec la nouvelle, ce prix était invalide.

La plateforme rejetait les prix invalides, mais notre adaptateur disposait d’une solution de repli : il arrondissait la vente à 42,318.00. Ce prix était toujours invalide. Une deuxième solution de repli arrondissait de nouveau, cette fois à 42,318.05, un prix valide mais moins avantageux pour le vendeur. L’ordre ne pouvait plus être vendu au prix modélisé. Ce chemin d’exécution avait été écrit pour un autre marché et transformait discrètement un rejet en ordre repricé.

Cet ordre soulevait deux questions distinctes. Premièrement, quel prix la plateforme peut-elle accepter ? Deuxièmement, comment une stratégie doit-elle réagir lorsque le prix souhaité ne figure pas sur la grille ? La plateforme répond à la première question. La stratégie ou la politique d’exécution doit répondre à la seconde.

Il n’existe pas de règle d’arrondi universellement correcte. Arrondir un achat vers le bas préserve la contrainte de prix de l’acheteur, mais peut réduire les chances d’exécution. Arrondir vers le haut peut rendre l’ordre immédiatement exécutable, ce qui modifie les frais et l’impact sur le marché. Pour notre entrée passive sur la base, déplacer silencieusement l’ordre était le mauvais comportement. La stratégie avait choisi un objectif ; l’adaptateur en a changé les conditions économiques.

Pourquoi le backtest semblait-il toujours prometteur ?

Notre simulateur historique d’ordres traitait les prix limites comme des nombres continus. Si le plus bas de la bougie atteignait le prix d’achat, ou si son plus haut atteignait le prix de vente, il comptait une exécution. C’est déjà une approximation généreuse pour un ordre passif, car un échange au prix limite ne dit rien sur la position dans la file d’attente. Mais le changement de pas de cotation a révélé un problème plus fondamental : l’ordre n’aurait pas pu exister à ce prix.

Nous avons rejoué les mêmes décisions en appliquant la nouvelle grille à partir de sa date d’entrée en vigueur. Plusieurs exécutions ont disparu. Quelques ordres ont été arrondis à des prix qui croisaient le spread et entraînaient des frais taker au lieu de frais maker. Le parcours de position qui en a résulté a divergé, modifiant aussi les couvertures et les sorties ultérieures. Une règle qui semblait relever des métadonnées avait changé toute la séquence des transactions.

Et cette mise à jour n’était pas une surprise cachée dans un graphique. La plateforme avait publié une modification des règles de l’instrument, avec un horodatage d’entrée en vigueur. Nous conservions soigneusement les données de marché, mais les métadonnées des instruments se trouvaient dans un cache actualisé au démarrage. Le backtest utilisait les règles du jour pour toutes les dates historiques ; le trading simulé, lui, utilisait des règles obsolètes jusqu’au redémarrage du processus. Aucun des deux environnements ne représentait ce que la plateforme autorisait à chaque instant.

Comment un backtest doit-il modéliser les changements de pas de cotation ?

Versionnez les règles des instruments avec des intervalles de validité, comme les autres données disponibles à un instant donné. À tout le moins, conservez l’heure d’entrée en vigueur et les valeurs nécessaires pour valider un ordre : le pas de cotation, le pas de quantité, la quantité minimale et les éventuelles bandes de prix. Le simulateur doit charger l’ensemble de règles disponible au moment de la décision simulée.

Rendez ensuite le traitement des ordres explicite. Si un prix cible est invalide, rejetez-le, arrondissez-le selon une politique documentée ou recalculez le prix cible sur la grille. Consignez la décision prise. Un backtest qui corrige automatiquement chaque ordre peut être utile pour estimer une politique d’exécution particulière, mais il ne doit pas faire passer cette politique pour une exécution sur la plateforme.

Nous avons ajouté deux contrôles. Le premier vérifie chaque ordre généré selon les règles de l’instrument en vigueur au moment considéré et signale clairement les prix ou quantités invalides. Le second compare l’ordre final normalisé par l’adaptateur du backtest et celui du trading simulé : sens, prix, quantité, durée de validité et intention concernant les frais. En cas de désaccord, les résultats ne sont pas considérés comme comparables.

Nous avons ensuite rejoué le changement du mardi. Le backtest ne revendiquait plus d’exécution à 42,318.03 après la mise à jour de la grille. Le trading simulé et la simulation prenaient la même décision pour chaque cible invalide, même lorsque cette décision consistait à ne pas envoyer l’ordre.

Le signal n’avait pas déraillé. Ses hypothèses sur l’instrument qu’il pouvait négocier étaient devenues obsolètes. Une stratégie peut s’adapter à un nouveau pas de cotation, à condition que le système de recherche traite les règles de la plateforme comme une composante du marché qu’il simule.