Notre backtest a comptabilisé 91 exécutions sur 100 ordres soumis. En paper trading, la même stratégie en a obtenu 63. Le délai médian entre le signal et l’accusé de réception de l’ordre était de 84 millisecondes, et 12 des ordres paper non exécutés étaient des limites que le backtest supposait exécutées dès que le prix les touchait.
Cet écart de 28 points semblait révéler un problème de stratégie, jusqu’à ce que nous distinguions les décisions de passer un ordre des décisions d’exécution. Dans les deux simulations, la stratégie choisissait presque toujours le même sens, la même taille et le même prix. C’est le parcours d’exécution qui différait : certains ordres arrivaient en retard, d’autres restaient ouverts et d’autres encore rencontraient un marché qui avait déjà évolué.
Que signifie la parité des ordres entre backtest et paper trading ?
La parité signifie que le backtest et le système paper prennent des décisions comparables à partir des mêmes informations disponibles, puis tiennent explicitement compte de leurs modèles d’exécution différents. Cela ne signifie pas que chaque exécution simulée doit correspondre à une exécution paper. Les bougies historiques ne permettent pas de reconstituer la position dans la file d’attente, et une plateforme paper peut utiliser un modèle d’appariement différent de celui d’une plateforme d’échange en production.
La question utile est plus ciblée : pour chaque ordre que la stratégie voulait passer, pouvez-vous expliquer ce qui s’est produit ensuite ? Le nombre de trades et le rendement final masquent trop de choses. Conservez un enregistrement regroupant chaque décision, avec un identifiant de décision de stratégie stable transmis aux événements de signal, d’ordre, d’accusé de réception, d’annulation et d’exécution.
| Comparaison | Ce qu’elle permet de repérer | Exemple |
|---|---|---|
| Heure et sens de la décision | Différences d’entrées ou de planification | Le signal paper se déclenche une bougie plus tard |
| Taille et prix demandés | Arrondis, règles de risque ou règles de la plateforme | Le backtest soumet 0.013 BTC ; paper arrondit à 0.01 |
| Transitions d’état de l’ordre | Écarts de soumission, rejet et annulation | Le backtest considère une demande d’annulation comme terminée |
| Quantité et prix d’exécution | Optimisme du modèle d’exécution ou mouvement du marché | Une limite touchée est entièrement exécutée dans le backtest, mais pas dans paper |
Pourquoi les limites touchées représentaient-elles autant d’ordres manqués ?
Notre backtest utilisait des bougies d’une minute. Si le prix limite se situait dans la fourchette entre le plus haut et le plus bas d’une bougie, il considérait l’ordre comme exécuté. Cette règle indique si le marché a atteint ce prix à un moment donné pendant la minute. Elle ne dit pas si notre ordre était alors actif, s’il était en tête de la file d’attente ni si un volume suffisant a été échangé après son arrivée.
Les journaux paper ont révélé le problème de timing. La stratégie a calculé un signal à 12:03:00.000, mais l’événement de données de marché est parvenu au processus d’ordres 31 millisecondes plus tard. Les contrôles de risque ont pris 22 millisecondes de plus, puis le simulateur de la plateforme a accusé réception de l’ordre 31 millisecondes après cela. Lors d’un mouvement rapide, une bougie historique peut laisser penser qu’un prix était atteignable alors que la limite est arrivée après que le marché l’a dépassé.
Un autre détail compliquait les choses : douze ordres paper étaient toujours ouverts alors que le backtest était déjà passé à la suite. Le simulateur acceptait une demande d’annulation comme si l’ordre avait disparu immédiatement. Dans le système paper, l’accusé de réception de l’annulation arrivait plus tard ; trois ordres ont été exécutés pendant cet intervalle. La position prise en compte par le signal suivant s’en est trouvée modifiée.
Comment mesurer l’écart sans se raconter d’histoires ?
Commencez par un petit rapport de rapprochement regroupé par intention d’ordre. Gardez le dénominateur visible. Le « taux d’exécution » peut désigner le nombre d’exécutions par ordre soumis, la quantité exécutée divisée par la quantité demandée ou le nombre d’ordres exécutés divisé par le nombre d’ordres parvenus à la plateforme. Ces mesures répondent à des questions différentes.
- Reliez les événements à l’aide d’un identifiant de décision ou d’ordre client, et non d’un horodatage deviné après coup.
- Comparez d’abord les décisions : heure du signal, sens, quantité demandée, type d’ordre et prix limite.
- Pour les décisions correspondantes, comparez le délai d’accusé de réception, les rejets, la durée d’ouverture, l’heure d’annulation, la quantité exécutée et le prix moyen d’exécution pondéré par le volume.
- Présentez les taux par type d’ordre et par condition de marché. Un taux d’exécution global de 63 % peut masquer un taux de 90 % pour les ordres au marché et de 35 % pour les limites passives.
Distinguez clairement les catégories. Un ordre rejeté n’est pas un ordre non exécuté ; un ordre partiellement exécuté n’est pas une exécution complète ; et un ordre annulé après une exécution partielle a tout de même modifié la position. Comptez les ordres et les quantités demandées pour éviter qu’un amas de petits ordres ne donne un résultat plus flatteur qu’il ne l’est.
Que faut-il changer dans le backtest ?
Utilisez une règle d’exécution adaptée à la résolution des données et au comportement attendu de l’ordre. Avec des bougies, une limite touchée indique qu’une exécution est possible, pas qu’elle a eu lieu. Vous pouvez modéliser les exécutions partielles de façon prudente, exiger que le prix dépasse la limite ou exclure les ordres passifs dont la position dans la file d’attente ne peut pas être estimée. Chaque choix répond à une question différente ; documentez-le et comparez le résultat avec plusieurs règles plausibles.
Modélisez également l’état des ordres. Un ordre reste actif jusqu’à ce que le système reçoive un événement terminal, et une demande d’annulation n’efface pas l’exposition. Si la stratégie peut soumettre un deuxième ordre alors que le premier est en attente, son backtest doit représenter cette course ou l’empêcher par conception.
Un modèle d’exécution affirme ce que votre ordre aurait pu faire. Définissez une règle que vous pouvez expliquer, puis vérifiez-la à l’aide des journaux paper.
Dans notre écart de 28 points, le plus surprenant n’était pas qu’un backtest fondé sur des bougies d’une minute surestime les exécutions passives. C’était que la position de la stratégie divergeait avant sa décision suivante parce que le timing des annulations avait été omis. Après avoir corrigé le modèle d’état des ordres et cessé de traiter chaque limite touchée comme exécutée, la comparaison paper est devenue moins flatteuse et plus utile.
Voilà le critère pratique de parité : chaque différence notable entre le comportement simulé et paper a une cause consignée, et le backtest ne prétend pas à une certitude que ses données ne peuvent fournir.
← Tous les articles
