ALGO TRADING
Pourquoi une stratégie qui fonctionnait en simulation sous-performe avec du capital réel, comment distinguer les trois causes, et comment prouver que le côté live est réel.
– L'ÉCART
Un backtest est une simulation de stratégie sur des données historiques. Un track record live est ce que cette même stratégie a réellement fait avec du capital réel. Quand les deux divergent, la question utile n'est pas de savoir si le backtest a menti. C'est de savoir lequel des trois mécanismes distincts a produit l'écart, car chacun a son propre diagnostic et son propre correctif.
Une part de la dégradation est attendue et ne porte aucune information. Un résultat hors échantillon tiré de la même distribution se situe en moyenne sous un optimum in-sample, pour la simple raison que cet optimum a été sélectionné parmi de nombreux candidats. Le reste de l'écart n'est pas statistique du tout : il pointe vers un modèle de coûts trop généreux, une fuite dans le signal, ou un problème d'exécution qui n'est jamais apparu en simulation.
Faire la comparaison suppose que les deux côtés soient mesurables. Un backtest qui n'applique aucun frais n'est comparable à rien. Un historique live fait de captures d'écran ne l'est pas davantage, et il l'est encore moins pour quelqu'un qui n'a pas pris les captures lui-même.
– TROIS CAUSES
La plupart des post-mortems les réduisent à une conclusion vague sur le surapprentissage. Elles sont séparables, et les séparer est précisément ce qui indique si la stratégie est récupérable.
Chaque valeur de paramètre testée, chaque règle ajoutée puis retirée, chaque fenêtre décalée compte comme un essai. Le meilleur de N essais est biaisé à la hausse même quand aucune des variantes ne détient un véritable edge. C'est ce que la Probability of Backtest Overfitting et le Deflated Sharpe Ratio (Bailey et Lopez de Prado) ont été conçus pour quantifier.
Comptez le vrai nombre de configurations évaluées, presque toujours plusieurs fois celui dont vous vous souvenez, puis calculez le PBO. Si le Sharpe déflaté tombe à zéro, il n'y a jamais eu d'edge démontré à perdre.
Frais, slippage, funding, coûts d'emprunt, exécutions partielles et spread se soustraient tous d'un compte réel et ne coûtent rien dans une simulation naïve. La fuite de look-ahead est la version plus sévère du même problème : un signal calculé sur une bougie qui n'était pas encore clôturée est de l'argent gratuit en backtest, et tout simplement indisponible en live.
Relancez le même backtest avec des frais réalistes par venue et une hypothèse de slippage. Si l'edge s'évapore à 5 points de base, l'edge était le modèle de coûts, pas la stratégie.
Une interruption de service, une intervention manuelle pendant un drawdown, une position plafonnée par la marge disponible, un ordre rejeté par la venue, un flux de données tombé une après-midi. Chacun de ces événements rompt l'équivalence entre les deux séries sans qu'aucune ne soit fausse dans son propre référentiel.
Comparez l'exposition dans le temps plutôt que les rendements. Si le compte live était plat les jours où la simulation était en position, l'écart est opérationnel et aucun réajustement ne le refermera.
– CÔTÉ BACKTEST
Avant toute comparaison, le côté simulé doit être capable de perdre de l'argent comme un compte réel en perd. Voici le minimum pour que la comparaison porte de l'information.
Tous les moteurs de backtest ne modélisent pas cette liste, et ceux qui font l'impasse sur le réalisme d'exécution sont ceux qui produisent les écarts les plus larges. Pour une stack qui la couvre, ManifoldBT est une bibliothèque de backtesting Python à cœur Rust qui simule des exécutions séquentielles avec frais, slippage et funding, en plus du walk-forward, du Monte Carlo et de la détection de look-ahead.
Divulgation : ManifoldBT est développé par la même équipe qu'AuditZK. Le code est source-available sous Apache 2.0 avec Commons Clause ; le walk-forward et les safety checks relèvent de son offre Pro.
– CÔTÉ LIVE
Le côté backtest reçoit toute l'attention, puis le côté live se résume à un tableur assemblé par le trader. Cette asymétrie explique pourquoi la plupart des comparaisons backtest contre live ne convainquent personne.
La série live doit être continue. Des valorisations quotidiennes du portefeuille, pas une liste de trades clôturés, car les pertes latentes vivent dans l'espace entre les trades.
Elle doit être pondérée par le temps plutôt qu'en P&L brut, sinon chaque dépôt et retrait se lit comme de la performance et la comparaison mesure votre calendrier de financement.
Elle doit venir de la venue plutôt que du trader. Une comparaison menée sur vos propres chiffres vous prouve quelque chose à vous, et rien à un tiers.
Elle doit commencer quand vous dites qu'elle commence. Un historique assemblé après un bon trimestre porte un biais de backfill, le jumeau côté live de la sélection en backtest.
– COMMENT COMPARER
Six étapes, dans cet ordre. Sauter l'une des quatre premières produit un chiffre qui ressemble à une comparaison sans en être une.
| Étape | Ce qu'il faut faire | Pourquoi c'est important |
|---|---|---|
| Choisir les fenêtres | Comparer le live au segment hors échantillon du backtest, jamais au segment in-sample | Le segment in-sample est celui où les paramètres ont été ajustés : ce n'était jamais une prédiction |
| Normaliser la métrique | Rendement pondéré par le temps des deux côtés, même taux sans risque, même convention d'annualisation | Un Sharpe calculé de deux façons différentes n'est pas une comparaison, c'est une coïncidence |
| Borner le bruit | Établir combien d'observations live vous avez avant de lire un écart de Sharpe comme réel | Un échantillon live court ne distingue pas un 1,2 d'un 0,6 à un niveau de confiance utile |
| Déflater le backtest | Appliquer le PBO et le Sharpe déflaté avec le vrai nombre d'essais | Ramène le chiffre du backtest à ce qui a été démontré plutôt qu'à ce qui a été sélectionné |
| Superposer l'exposition | Tracer le temps en position pour les deux séries, pas seulement les rendements | Sépare un écart opérationnel d'un écart statistique, ce que rien d'autre ne fait |
| Publier le côté live | Utiliser un historique vérifié pour que la comparaison soit vérifiable par quelqu'un qui ne vous fait pas confiance | Sinon l'exercice entier n'est qu'une affirmation auto-déclarée de plus |
FAQ
Lectures connexes
ÉTAPE SUIVANTE
Connectez vos comptes en lecture seule. AuditZK construit l'historique live vérifié auquel votre backtest est comparé, sans exposer les trades individuels ni la logique de la stratégie.