Un backtest peut indiquer une exécution à un prix que le marché n’a jamais affiché. En général, le simulateur a déduit une exécution plausible en apparence à partir de données incomplètes : le plus haut et le plus bas d’une barre, un cours moyen ou un prix limite touché par une seule transaction. Le journal des transactions peut alors sembler précis tout en masquant ce que le marché proposait réellement.
Commencez par vous demander à quel prix votre ordre aurait pu être exécuté. Une barre de dernières transactions indique les prix auxquels des échanges ont eu lieu pendant un intervalle. Elle ne précise pas le bid et l’ask au moment où votre ordre est arrivé, la quantité disponible à ces prix ni si votre ordre aurait pu passer en tête de la file d’attente.
Pourquoi mon backtest affiche-t-il une exécution à un prix hors marché ?
Commençons par préciser ce que signifie « hors marché ». Une exécution à l’achat sous le plus bas de la barre ou à la vente au-dessus de son plus haut révèle une erreur évidente de comptabilisation ou de chronologie. Même une exécution située entre le plus haut et le plus bas peut être fictive : le prix a pu être négocié avant que l’ordre existe, de l’autre côté du spread ou pour une quantité trop faible pour exécuter votre ordre.
Prenons une barre d’une minute avec une ouverture à 100.00, un plus bas à 99.80 et une clôture à 100.10. Votre stratégie observe la barre terminée, passe un ordre d’achat et le simulateur l’exécute à 99.80. Ce plus bas a pu être atteint au début de la minute, cinquante secondes avant le signal. La barre ne prouve pas que le prix de 99.80 était disponible après la décision.
| Données disponibles | Ce qu’elles établissent | Ce qu’elles ne permettent pas d’établir |
|---|---|---|
| Barre OHLCV | Fourchette des prix observés et volume sur un intervalle | Séquence des prix, bid et ask, ou disponibilité à l’arrivée de l’ordre |
| Transactions enregistrées | Exécutions déclarées, avec horodatages et prix | Liquidité présente dans le carnet ou votre position dans la file d’attente |
| Cotations du meilleur niveau | Meilleur bid et ask affichés aux heures d’échantillonnage | Profondeur au-delà du meilleur niveau ou persistance d’une cotation entre deux échantillons |
| Événements du carnet d’ordres | Variations de la profondeur affichée et événements dans la file d’attente, selon la couverture du flux | Liquidité cachée, accès à la plateforme ou priorité garantie |
Une autre cause fréquente consiste à confondre cours moyen et prix exécutables. Si la cotation est de 99.99 au bid et de 100.01 à l’ask, un achat au cours moyen de 100.00 paraît propre dans un rapport. Un achat au marché paie généralement l’ask, auquel s’ajoute l’impact éventuel de sa taille. Présenter le cours moyen comme prix d’exécution fait discrètement disparaître la moitié du spread.
Un ordre limite peut-il être exécuté simplement parce que le marché a touché son prix ?
Un contact avec le prix limite prouve qu’une transaction a été enregistrée à ce prix. Cela ne prouve pas que votre ordre au carnet aurait été exécuté. Si d’autres ordres étaient devant le vôtre, le volume échangé à ce prix était peut-être insuffisant pour atteindre votre position dans la file. La transaction a aussi pu avoir lieu sur une autre plateforme, alors que votre ordre attendait ailleurs.
Supposons que votre ordre limite d’achat soit à 50.00 et que le marché échange 200 actions à ce prix après que vous l’avez passé. Un simulateur fondé sur le simple contact exécute les 500 actions. Un modèle plus prudent examine le volume échangé à 50.00 ou à un prix plus avantageux après l’arrivée de l’ordre, puis tient compte de la file d’attente estimée devant lui. Sans données du carnet au niveau des ordres, cette file est une hypothèse. Elle doit apparaître dans les résultats, et non être présentée comme une certitude.
Pour un petit système de recherche, je préfère expliciter cette hypothèse et tester plusieurs valeurs plutôt que de prétendre que les données de chandeliers révèlent la priorité dans la file. La fourchette pertinente dépend de la plateforme, de la taille de l’ordre et de la fréquence des transactions de la stratégie. Une action peu échangée à l’ouverture et un contrat crypto peu liquide à 03:00 UTC posent des problèmes d’exécution différents.
Comment choisir un modèle d’exécution pour des données en barres ?
Adaptez le modèle aux données et à ce que la stratégie prétend démontrer. Un backtest basé sur des barres peut rester utile pour les stratégies lentes, mais ses exécutions doivent respecter ce que les barres permettent réellement d’établir.
- Définissez les heures de décision et d’arrivée. Si un signal utilise la clôture d’une barre, passez l’ordre après cette clôture. Simulez l’exécution à partir de l’intervalle ou de la cotation disponible suivant, et non à partir d’un plus bas antérieur de la barre terminée.
- Utilisez le bon côté du spread. Pour les achats exécutables au marché, partez de l’ask ; pour les ventes, du bid. Si vous ne disposez que de barres de transactions, estimez le spread à partir d’une source distincte ou indiquez que le modèle ne le prend pas en compte.
- Limitez les exécutions à une liquidité plausible. Appliquez un taux de participation au volume observé et incluez les frais et l’impact de marché. Le volume total d’une barre ne signifie pas que toute cette quantité était disponible au prix choisi.
- Mettez les hypothèses à l’épreuve. Comparez les exécutions à l’ouverture suivante avec un slippage prudent et vérifiez si le résultat résiste à des conditions d’exécution moins favorables. N’ajustez pas le modèle d’exécution jusqu’à ce que la stratégie soit gagnante.
Ce sont des choix de modélisation, pas une méthode pour retrouver l’unique prix d’exécution réel à partir de données incomplètes. Si la stratégie dépend de la capture de quelques points de base, les données en barres ne suffisent peut-être pas à étayer cette affirmation.
Comment retrouver l’origine de l’exécution impossible dans le backtest ?
Suivez une transaction suspecte du signal au grand livre. Conservez dans des champs distincts l’horodatage de la décision, celui de l’envoi de l’ordre, son arrivée simulée, l’observation de marché retenue, le prix d’exécution, la quantité exécutée et les frais. Vérifiez ensuite, dans l’ordre :
- La caractéristique a-t-elle été calculée à partir de données d’une barre qui n’était pas terminée au moment de la décision ?
- L’exécution a-t-elle utilisé le plus haut, le plus bas ou la clôture de la barre alors que ce prix avait été atteint avant l’arrivée de l’ordre ?
- Un achat a-t-il été associé au bid, ou une vente à l’ask ?
- La quantité simulée dépassait-elle la taille de cotation disponible ou le plafond de participation du modèle ?
- L’arrondi du prix, le pas de cotation du contrat et les frais ont-ils été appliqués après le choix du prix d’exécution ?
Si le relevé des transactions ne vous permet pas de répondre à ces questions, il manque au backtest des éléments sur l’exécution. Ajoutez les champs nécessaires, rejouez à la main quelques transactions à partir des données brutes et vérifiez que le prix indiqué aurait été possible avec le modèle prévu. Une courbe de capital régulière ne détectera pas un prix qui n’existait que dans le simulateur.
← Tous les articles


