Backtesting vs journal de trading : pourquoi les deux sont nécessaires

En bref. Le backtesting simule une stratégie sur des données de prix historiques avant qu'aucun capital réel ne soit engagé ; un journal de trading enregistre ce qui s'est réellement passé une fois que des ordres réels ont été passés. Ils répondent à des questions différentes, et aucun ne remplace l'autre : un backtest peut montrer si un ensemble de règles avait du mérite historiquement, mais seul un journal montre si un trader peut réellement l'exécuter, avec du vrai slippage, de vrais frais et une vraie psychologie en travers du chemin.

Les traders ont tendance à s'appuyer sur l'un et à négliger l'autre. Quelqu'un teste une stratégie en backtest, voit une courbe de capital propre et commence à la trader en réel en supposant que le backtest a déjà prouvé le concept. Quelqu'un d'autre journalise scrupuleusement chaque trade réel, mais n'a jamais vérifié, sur des données historiques, si l'idée sous-jacente a la moindre valeur statistique. Ces deux habitudes créent chacune un angle mort que l'autre pratique aurait détecté.

Ce que le backtesting teste réellement

Un backtest applique un ensemble fixe de règles d'entrée et de sortie à des données de prix historiques et mesure ce qui se serait passé : profit ou perte net, win rate, drawdown et autres statistiques de performance, calculés sans risquer le moindre centime (Corporate Finance Institute, "Backtesting"). Cela le rend peu coûteux à exécuter et rapide à itérer : une idée de règles peut être testée sur des années d'historique de prix, ajustée, puis retestée, tout cela avant qu'un seul ordre réel ne parte. Des plateformes grand public comme le Strategy Tester de MetaTrader existent précisément pour cela : elles simulent l'exécution d'une stratégie automatisée sur des données de prix historiques stockées, afin que la logique puisse être vérifiée avant de toucher un compte réel ou démo (MetaQuotes, documentation MQL5, "Testing Trading Strategies").

La valeur d'un backtest est étroite et spécifique : il répond à la question de savoir si un ensemble de règles défini aurait produit un résultat positif sur une période choisie de l'histoire. Il ne répond pas à la question de savoir si ce trader précis, dans des conditions de marché réelles, peut réellement suivre les règles.

Ce qu'un backtest ne peut pas voir

Un backtest s'exécute sur des données historiques propres et une exécution simulée à chaque signal. Il n'a pas accès à ce qui se passe entre la règle et l'ordre réel : la demi-seconde d'hésitation avant de cliquer sur acheter, le stop qu'on déplace parce que le trade "ne le sent pas", la position clôturée trop tôt par nervosité, ou celle qu'on garde trop longtemps en espérant un rebond. Rien de tout cela n'apparaît dans une simulation, parce qu'une simulation n'a pas de nerfs.

Un backtest a aussi tendance à sous-estimer les coûts réels de trading. Les exécutions historiques dans un backtest sont fréquemment supposées se faire exactement au prix du signal, alors qu'un ordre réel s'exécute au prix que le marché offre un instant plus tard, plus le spread et la commission. Le slippage sur un instrument liquide peut représenter une fraction de pourcent ; sur un marché plus mince, il peut largement dépasser un pourcent, et même une petite hypothèse de slippage peut transformer un edge démontré en backtest en perte réelle une fois appliquée de façon cohérente à chaque trade.

Important. Un backtest qui n'a jamais tenu compte d'un slippage, de commissions et d'exécutions réalistes ne mesure pas la stratégie qu'un trader vivra réellement en réel. Une courbe de backtest propre doit être traitée comme une hypothèse de départ, pas comme une garantie.

Ce qu'un journal de trading capture à la place

Un journal de trading enregistre le trade réellement passé : le prix d'entrée et de sortie réel, la taille réelle, le résultat réel après frais et, si le journal le capture, l'état d'esprit avant et après le trade. C'est le seul enregistrement qui montre l'écart entre la règle sur le papier et la règle exécutée.

Cet écart est souvent là où se trouve la vraie histoire. Un setup peut être backtesté avec un win rate propre de 55 % et quand même perdre de l'argent en réel, non pas parce que le setup était mauvais, mais parce que l'exécution réelle cède systématiquement quelques points de base par trade au slippage, à l'hésitation ou à une sortie prise une bougie trop tôt. Journaliser chaque trade avec une étiquette de setup est ce qui rend cette comparaison possible en premier lieu ; sans cela, une série de pertes en réel et une idée cassée se ressemblent de l'intérieur.

L'angle mort que chaque méthode a à elle seule

Un processus pratique : backtester d'abord, puis journaliser l'écart d'exécution

Les deux pratiques fonctionnent mieux en séquence, pas comme un choix exclusif. Backtester d'abord une idée sur une période d'historique assez longue et sur plus d'une condition de marché, pour filtrer les règles qui n'ont jamais eu de mérite, avant d'engager le moindre capital. Si le backtest tient la route, trader l'idée en réel avec une taille réduite et journaliser chaque trade sous une étiquette dédiée, y compris le prix d'entrée et de sortie, la taille et le résultat après coûts.

Après un nombre significatif de trades réels sous cette étiquette, comparer le win rate journalisé et le résultat moyen aux chiffres du backtest pour ce même ensemble de règles. Une correspondance proche, dans la limite de ce que les coûts et la variance normale expliqueraient, est un signe que la stratégie survit au contact de l'exécution réelle. Un écart large et constant indique un vrai problème : des coûts sous-estimés dans le backtest, ou des règles qui ne sont pas suivies telles qu'écrites une fois que le vrai argent et les vraies émotions entrent en jeu. Revoir le détail par stratégie pour cette étiquette sur une base régulière, plutôt que seulement quand le setup donne l'impression d'avoir cessé de fonctionner, c'est ce qui garde cette comparaison honnête.

Lire une série de pertes en réel face à une référence de backtest

Une série de pertes sur un setup réel et journalisé est facile à mal interpréter sans backtest pour comparer. Si le test historique montrait déjà des séquences de cinq ou six pertes consécutives comme faisant normalement partie du profil de rendement de cette stratégie, une série de pertes réelle de longueur similaire n'est pas une information nouvelle ; c'est la stratégie qui se comporte comme prévu. Sans cette référence, la même série peut ressembler à une preuve que l'idée a cessé de fonctionner, et les traders abandonnent des setups qui n'ont jamais été cassés, ou doublent la mise sur ceux qui le sont discrètement.

C'est un type d'erreur différent de juger un edge sur un échantillon réel trop petit, qui est un problème de taille d'échantillon. Ici, le problème est de n'avoir aucun point de référence de ce à quoi ressemble la "normale" pour cette stratégie précise, parce que l'étape du backtest a été sautée. L'expectancy, calculée de la même façon dans le backtest et dans le journal réel, est le chiffre qui rend cette comparaison concrète plutôt qu'un ressenti.

Ce qu'il faut journaliser pour que la comparaison fonctionne réellement

La comparaison entre backtest et résultats réels ne fonctionne que si le journal capture assez de détails pour être confronté à la sortie du backtest lui-même. Une entrée de journal qui n'enregistre que le gain ou la perte ne peut pas être comparée à un backtest qui rapporte le win rate, le résultat moyen et le drawdown ; les deux jeux de données doivent parler le même langage.

Au minimum, chaque trade réel sous l'étiquette a besoin du nom du setup, du prix d'entrée et de sortie, de la taille de position, du résultat après frais et de la date, afin que les mêmes statistiques (win rate, résultat moyen, drawdown maximal pour cette étiquette) puissent être calculées des deux côtés et placées côte à côte. Des exemples de journaux de trading construits à ce niveau de détail transforment cette comparaison en une vérification de cinq minutes plutôt qu'en une reconstruction manuelle à partir des relevés du broker après coup.

Erreurs courantes

• Trader en réel une idée backtestée sans jamais comparer les résultats réels au backtest. Cette comparaison est tout l'intérêt de la démarche ; la sauter transforme le backtest en exercice ponctuel au lieu d'un contrôle continu.
• Supposer que les exécutions et les coûts du backtest correspondent aux conditions réelles. Des hypothèses irréalistes de slippage et de commission transforment régulièrement un edge de backtest en perte réelle.
• Journaliser des trades réels pour une idée qui n'a jamais été testée sur des données historiques. Impossible de distinguer une série de pertes normale d'une idée cassée sans référence.
• Abandonner une stratégie après une série de pertes qui correspond à son propre profil de drawdown backtesté. Comparer avec le backtest avant de conclure que l'edge a disparu.
• Traiter un seul run de backtest comme une preuve permanente. Les conditions de marché changent ; un ensemble de règles bien testé il y a un an nécessite une revérification périodique sur des données fraîches, tout comme un edge réel.

Cet article est fourni à titre éducatif uniquement et ne constitue pas un conseil financier ou en investissement. Le trading avec effet de levier comporte un risque élevé de perte. Les performances passées, qu'elles proviennent d'un backtest ou d'un historique réel, ne garantissent pas les résultats futurs.

Comparez automatiquement les attentes du backtest aux résultats réels journalisés avec le journal de trading BitStat, plutôt que de tenir deux feuilles de calcul séparées et de deviner l'écart entre elles.