Backtesting et simulation

Activez le look-ahead, le biais de survie et les exécutions optimistes et regardez un faux avantage apparaître. Le plus dur dans la recherche n'est pas de trouver un avantage. C'est de ne pas se mentir sur son existence.

Voir en mouvement

Qu'est-ce qu'un backtest, et pourquoi ment-il si facilement ?

Un backtest rejoue une stratégie sur des données historiques pour estimer comment elle aurait performé. Il ment facilement parce que chaque raccourci dans la simulation flatte le résultat dans la même direction (vers un rendement plus élevé et plus lisse) et parce que vous pouvez continuer à ajuster le test jusqu'à ce qu'il ait l'air bon. La discipline honnête est de rendre la simulation pessimiste et de la juger sur des données que vous n'avez jamais touchées.

Commencez par l'intuition. Un backtest est une histoire que vous racontez sur le passé, et vous contrôlez chaque détail de la narration. Chaque hypothèse commode (« j'aurais été exécuté », « les coûts sont négligeables », « je l'aurais su à ce moment-là ») pousse l'histoire vers le profit. Empilez-en quelques-unes et vous avez une belle courbe de capital qui ne décrit rien de réel.

La propriété qui rend cela dangereux est une asymétrie : presque toutes les erreurs courantes biaisent le résultat à la hausse. Il n'y a pas de bruit symétrique qui ferait parfois paraître une vraie stratégie pire qu'elle n'est ; les erreurs sont systématiquement optimistes. L'état par défaut d'un backtest est donc « trop bon », et votre travail est de le repousser vers la réalité.

Le piège le plus profond n'est aucun péché isolé mais le processus : vous ajustez, relancez, ajustez encore. Chaque ajustement qui améliore le backtest est un ajustement à cette histoire précise, et le temps qu'il paraisse formidable, vous l'avez, sans le remarquer, surajusté au passé. Cette page est la colonne de prudence de toute la section stratégies : chaque signal là-bas doit survivre au scepticisme de cette page avant de signifier quoi que ce soit. Dans l'explorateur ci-dessus, le vrai avantage de la stratégie jouet est exactement nul par construction, si bien que chaque gain que vous pouvez produire est un artefact mesuré de l'un des péchés ci-dessous.

Qu'est-ce que le biais de look-ahead ?

Le biais de look-ahead consiste à utiliser dans une décision une information que vous n'auriez pas réellement eue à cet instant : l'erreur de backtest la plus courante et la plus létale. Utiliser la clôture d'une barre pour décider une transaction dans cette barre, appliquer un chiffre révisé à sa date d'événement, ou utiliser une statistique calculée sur tout l'échantillon laissent tous la stratégie « voir l'avenir ». Cela produit des résultats spectaculaires et entièrement fictifs.

Les formes classiques méritent d'être nommées pour que vous les reconnaissiez dans votre propre code. Décider la transaction du jour en utilisant la clôture du jour (vous ne connaissez la clôture qu'une fois la journée finie). Utiliser un chiffre d'entreprise à sa date d'événement alors qu'il a été publié en réalité des jours plus tard. Calculer une normalisation (une moyenne, un écart-type, un ajustement de modèle) sur le jeu de données entier puis l'utiliser à chaque instant, si bien que la statistique in-sample fait fuiter en silence l'avenir dans le passé.

Pourquoi est-ce si séduisant ? Une fuite minuscule produit un avantage énorme et lisse, parce qu'on donne en effet la réponse à la stratégie. Dans l'explorateur ci-dessus, le look-ahead seul fait passer le Sharpe de la stratégie jouet d'environ zéro à environ trois : pure fiction.

Utilisez des jeux de données point-in-time, décalez chaque valeur à sa disponibilité réelle, et calculez les statistiques sur une fenêtre glissante ou extensible qui ne lorgne jamais l'avenir. Une simulation par rejeu de marché fidèle l'impose structurellement, parce qu'elle injecte les événements dans l'ordre du temps et que rien d'ultérieur n'existe encore.

Qu'est-ce que le biais de survie ?

Le biais de survie consiste à backtester uniquement sur les instruments qui ont survécu jusqu'à aujourd'hui (l'univers des noms actuellement cotés), excluant en silence tout ce qui a été radié, a fait faillite ou a été racheté. Comme les échecs sont retirés, toute stratégie paraît plus sûre et plus rentable qu'elle ne l'était vraiment, surtout tout ce qui achète des noms en détresse ou en baisse.

L'intuition : n'étudier que les entreprises qui existent aujourd'hui, c'est présélectionner la survie. Une stratégie qui « achète le creux » paraît brillante si chaque nom qui a chuté à zéro a été discrètement effacé de votre jeu de données : vous ne voyez jamais ceux que le creux a tués.

Elle mord le plus fort sur les stratégies de retour à la moyenne et de valeur qui penchent vers les noms massacrés, et sur tout univers actions assemblé à partir d'une appartenance à un indice actuelle appliquée au passé : les anciens membres de l'indice écartés plus tard ont tout simplement disparu. Elle se cache aussi en crypto (tokens morts, places défuntes) et est trivialement facile à introduire par accident.

La défense est un univers point-in-time : l'ensemble des instruments qui existaient réellement et étaient tradables à chaque date, y compris ceux qui sont morts plus tard, avec leur historique complet de prix jusqu'à zéro. Des bases sans biais de survie existent pour les actions ; en crypto, vous devez délibérément conserver les actifs radiés. Dans l'explorateur ci-dessus, retirez les symboles « morts » synthétiques et la courbe s'améliore ; rétablissez-les et les pertes réapparaissent.

Que sont les exécutions irréalistes, et pourquoi la position de file en est-elle le cœur ?

Les exécutions irréalistes supposent que vous avez tradé à des prix ou des tailles que vous n'auriez pas réellement obtenus : exécuter au mid, toujours obtenir le touch, slippage nul, pas de file. Pour les stratégies passives (ordres à cours limité), c'est fatal : que votre ordre au repos s'exécute tout court dépend de votre position dans la file, et supposer qu'il s'exécute toujours invente tout l'avantage.

La famille des exécutions optimistes est large. Exécuter un ordre au marché au mid au lieu de payer le spread ; ignorer qu'un gros ordre balaie le carnet ; supposer qu'un ordre à cours limité au touch s'exécute toujours. Chacune ignore un coût réel, et le spread que vous avez ignoré est souvent toute la stratégie : un backtest de tenue de marché qui s'exécute au mid ne fait que collecter un spread imaginaire.

La position de file est le nœud pour les stratégies passives. Un ordre à cours limité rejoint l'arrière de la file à son niveau de prix, et il ne s'exécute que si assez de volume trade devant lui d'abord (priorité prix-temps). Votre taux d'exécution (et surtout quelles exécutions vous obtenez) dépend de l'endroit où vous étiez dans cette file. Le « toujours exécuté » vous donne les bonnes exécutions et vous épargne les mauvaises, inversant exactement la sélection adverse : en réalité, vous tendez à être exécuté précisément quand le marché est sur le point de bouger contre vous.

La modélisation de la file et des exécutions est donc la partie la plus dure et la plus importante d'un backtest de microstructure : vous devez modéliser l'arrivée, votre position de file, les annulations devant vous et la probabilité d'exécution, idéalement à partir de données L3 / market-by-order qui enregistrent le carnet ordre par ordre. La défense, ce sont des hypothèses d'exécution conservatrices (vous n'êtes pas exécuté à moins que la simulation ne montre la file vidée au-delà de vous), payer le spread et les frais, modéliser les exécutions partielles, et préférer un backtest par rejeu de marché qui reconstruit le carnet réel à un backtest en barres qui ne peut pas représenter la file.

Pourquoi la latence a-t-elle sa place dans le backtest ?

Parce qu'en réalité il y a un délai entre voir un signal et le fait que votre ordre atteigne le moteur d'appariement, et le monde bouge dans cet intervalle. Un backtest qui agit instantanément sur chaque signal capte des opportunités qui, le temps que votre ordre arrive vraiment, étaient déjà parties, cueillies par des joueurs plus rapides. Modéliser votre latence réelle fait partie d'un modèle d'exécution honnête.

L'intuition : vous voyez une cotation périmée et « tradez » contre elle dans le backtest à l'instant $T$. Mais votre ordre n'atteint la place qu'à $T + \ell$, où $\ell$ est votre latence, instant auquel la cotation que vous visiez est probablement déjà mise à jour ou prise. Le backtest vous a exécuté ; la réalité ne l'aurait pas fait.

C'est le visage en backtest de toute l'histoire de la latence et de la colocation. Un backtest instantané suppose implicitement que vous êtes infiniment rapide, ce qui vous accorde en silence chaque opportunité d'arbitrage de latence. Intégrez votre tick-to-trade réel et la plupart des « avantages » dépendants de la vitesse disparaissent pour quiconque n'est pas dans la classe vitesse.

La défense est de retarder chaque décision d'une latence réaliste avant qu'elle ne puisse agir, et de n'exécuter que contre le carnet tel qu'il était quand votre ordre serait vraiment arrivé, là encore une chose qu'une simulation par rejeu de marché fidèle fait naturellement.

Qu'est-ce que le surajustement, et pourquoi les tests multiples sont-ils le tueur de 2026 ?

Le surajustement consiste à régler une stratégie pour épouser le bruit de votre échantillon historique plutôt qu'un motif réel et répétable. Le mécanisme est le test multiple : essayez assez de variantes et la plus chanceuse paraîtra brillante in-sample purement par hasard. En 2026, la recherche de stratégie automatisée et assistée par l'IA rend l'essai de milliers de variantes sans effort, c'est donc désormais la façon dominante dont les backtests mentent.

L'intuition est une parabole de pile ou face. Lancez 1 000 pièces dix fois chacune et la meilleure pièce aura une belle série, non parce que c'est une bonne pièce, mais parce que vous en avez cherché 1 000. Cherchez 1 000 jeux de paramètres et le meilleur Sharpe in-sample est de même une illusion acquise d'avance : vous avez trouvé la configuration la plus chanceuse, pas un vrai avantage.

La statistique le rend précis. Le maximum espéré de $N$ résultats bruités croît avec $N$, donc plus vous essayez de stratégies ou de paramètres, plus la meilleure performance in-sample que vous verrez sera élevée même quand tout vrai avantage est nul. Le Sharpe honnête doit être escompté du nombre de choses essayées : c'est le Sharpe déflaté (Bailey & López de Prado 2014), qui ajuste le Sharpe observé du nombre d'essais et de la non-normalité des rendements.

2026 aggrave la chose, ne l'améliore pas : la recherche automatisée d'hyperparamètres et la recherche assistée par l'IA effondrent à presque zéro le coût d'essayer des variantes. La chose qui limitait jadis le surajustement (l'effort de faire tourner chaque test) a disparu, la discipline doit donc venir de la méthode, pas de la friction (voir ce que l'IA change pour le HFT). Les défenses sont concrètes. Hors échantillon / hold-out : ajustez et réglez sur une période, puis évaluez une fois sur une période que vous n'avez jamais touchée, et toucher le hold-out plus d'une fois le détruit, parce que chaque coup d'œil est un test de plus. La validation walk-forward fait rouler la fenêtre train/test dans le temps pour que chaque évaluation soit véritablement hors échantillon à travers les régimes. Comptez vos essais honnêtement et déflatez le Sharpe en conséquence. Et préférez des stratégies simples, motivées économiquement, à peu de paramètres : il y a moins à surajuster et une raison qu'elles marchent au-delà de « ça a collé au passé ».

Qu'est-ce que la simulation par rejeu de marché, et en quoi diffère-t-elle d'un backtest en barres ?

La simulation par rejeu de marché injecte le flux de messages enregistré (chaque ordre, annulation et transaction, dans l'ordre du temps) à travers votre système exactement comme cela s'est produit, et apparie vos ordres contre le carnet reconstruit à mesure qu'il évolue. Contrairement à un backtest grossier barre par barre, elle peut représenter la file, le spread, les exécutions partielles et la latence, les choses qui décident le vrai P&L d'une stratégie haute fréquence.

Un backtest en barres est l'outil grossier : vous avez des barres OHLCV et supposez des exécutions à l'ouverture, à la clôture ou au mid. Il ne peut pas voir le spread, la file ni la dynamique intra-barre, il est donc structurellement incapable de tester honnêtement toute stratégie passive ou sensible à la latence. Il convient aux stratégies actions lentes, pilotées par signal, et est inutile pour la tenue de marché.

Une simulation par rejeu de marché / pilotée par événements est l'outil honnête : rejouez la bande enregistrée message par message, reconstruisez le carnet à chaque instant, et injectez vos ordres dans ce carnet : ils prennent une position de file, attendent leur tour, s'exécutent (ou non) à mesure que le vrai volume trade, et paient de vrais frais, après votre latence réelle. C'est la même architecture pilotée par événements que le système en direct, ce qui est le but : le simulateur et la production partagent le code de stratégie, vous testez donc ce que vous ferez tourner.

Le plus dur est de savoir si votre ordre change le marché. Une simulation fidèle doit décider si votre présence affecte les autres. L'hypothèse la plus simple et la plus conservatrice est que vos ordres prennent de la liquidité et une position de file mais ne font pas réagir les autres ; modéliser l'impact de marché et les réponses des autres est plus dur et compte davantage à mesure que votre taille grandit (voir capacité). C'est pourquoi l'ordre de construction met « enregistrer et rejouer » et le harnais de backtest avant la stratégie : le simulateur est l'instrument qui vous dit si quoi que ce soit est réel.

Qu'est-ce que le test de conformité et de certification d'échange ?

Avant qu'une place ne laisse votre système trader en direct, elle exige en général un test de conformité (certification) : vous vous connectez à l'environnement de test de la place et prouvez que votre système parle correctement le protocole, gère chaque type d'ordre et message, et se comporte sous des conditions d'erreur et de récupération. C'est une porte obligatoire qui valide la correction et la sécurité, distincte du backtesting, qui valide la stratégie.

Ce qu'il vérifie : que vous encodez et décodez correctement le protocole de la place, gérez les rejets, annulations, exécutions partielles, récupération de session et trous de séquence, respectez la sémantique des types d'ordres, et ne vous comportez pas mal sous charge : que votre système est un participant sûr et conforme. Beaucoup de places et de régulateurs l'exigent avant d'activer l'accès en production, et il s'imbrique avec les obligations de contrôle du risque MiFID II RTS 6 et de la Rule 15c3-5.

Il est distinct du backtesting parce que les deux répondent à des questions différentes. Le backtesting demande « la stratégie gagne-t-elle de l'argent ? » ; la conformité demande « le système se comporte-t-il correctement face à la vraie place ? ». Vous avez besoin des deux : une stratégie rentable sur un système non conforme est un désastre réglementaire et opérationnel en attente. Pour le constructeur solo, les places crypto et de marchés de prédiction sont bien plus légères en certification formelle que les places actions et futures réglementées (une autre raison pour laquelle ces places sont le point de départ accessible), mais vous vous devez encore l'équivalent d'un auto-test contre le bac à sable de la place avant de risquer du capital.

Exemple travaillé

Prenez une stratégie jouet unique d'avantage vrai exactement nul et faites-la passer dans l'explorateur ci-dessus, en activant chaque péché tour à tour. Comme la stratégie ne peut prouvablement pas gagner d'argent, chaque gain ci-dessous est un artefact mesuré, pas un résultat ; les chiffres sont illustratifs et reproductibles à partir de la graine du widget, en 2026.

La configuration honnête (hors échantillon, vraies exécutions, coûts et latence) reporte un Sharpe d'environ zéro et un rendement annuel à peu près nul moins les coûts. C'est la vérité. Ajoutez le biais de look-ahead seul et le Sharpe bondit à environ trois sur une grande courbe lisse : pure fiction, la stratégie voyant l'avenir. Ajoutez des exécutions optimistes seules (mid, toujours exécuté) et vous collectez un spread imaginaire valant un Sharpe d'un à deux. Ajoutez le biais de survie seul (retirez les noms morts) pour un gain modeste, les échecs simplement effacés. Ajoutez le surajustement (gardez le meilleur de 200 jeux de paramètres aléatoires) et la meilleure courbe in-sample paraît formidable, l'illusion du maximum-de-N.

La leçon que le tableau enseigne en une ligne : la colonne hors échantillon est la seule qui signifie quelque chose. Un backtest est coupable jusqu'à preuve d'innocence sur des données qu'il n'a jamais vues, avec des exécutions, des coûts et une latence réalistes, et un décompte honnête du nombre de tentatives. Le widget vous laisse produire chaque ligne vous-même ; les chiffres sont délibérément une fiction que vous pouvez auditer, parce que le vrai avantage de la stratégie est nul par construction. Ceci est pédagogique seulement et pas un conseil en investissement ; aucune performance n'est sous-entendue, et les chiffres n'existent que pour démontrer les biais.