Les 7 biais systémiques qui gonflent artificiellement les résultats, le piège du breakeven qui masque les pertes, et la méthode war room qui transforme un backtest complaisant en outil de décision fiable. Avec des cas réels du scanner DailyTickers.
Un backtest qui montre +200% par an n'est pas un signal d'achat — c'est un signal d'alarme. Le backtesting est le seul domaine où l'on connaît déjà la réponse avant de poser la question. On sait comment les prix ont évolué. On sait quels tickers ont survécu. On sait quand les crises ont commencé et fini. Et cette omniscience crée des biais systémiques qui tous, sans exception, favorisent les résultats optimistes.
Ce n'est pas un problème théorique. Chez DailyTickers, nous avons découvert — après trois war rooms successives sur les configurations v6 et v7 du scanner — qu'une fonctionnalité appelée « stale tightening » fermait entre 38% et 46% de nos trades au breakeven. Le backtest « avait l'air bien » : drawdown faible, pas de grosses pertes. Mais en réalité, ces fermetures prématurées laissaient entre +19% et +64% de profit sur la table, par mode. Le backtest ne mentait pas sur les chiffres — il mentait par omission.
Ce guide documente les leçons tirées de ces war rooms. Pas de théorie abstraite : chaque section s'appuie sur un bug réel, une découverte concrète, ou une métrique vérifiable. L'objectif est de transformer votre backtest d'un outil de confirmation en un outil de falsification — parce que la valeur d'un backtest n'est pas de vous dire que votre stratégie marche, mais de vous montrer comment elle peut échouer.
Un backtest consiste à simuler une stratégie de trading sur des données historiques pour voir comment elle aurait performé. C'est comme regarder un match de foot enregistré en prétendant que vous ne connaissez pas le score : vous allez inconsciemment repérer les « bonnes » actions et ignorer les mauvaises. Le backtesting souffre exactement du même biais, à grande échelle.
Chaque péché est un biais systémique qui gonfle les résultats dans la même direction : vers le haut. Pris individuellement, chacun peut ajouter 5 à 30% de performance fictive. Combinés — et ils le sont presque toujours — ils peuvent transformer une stratégie médiocre en machine à rendement apparent.
| # | Péché | Biais | Impact typique | Solution |
|---|---|---|---|---|
| 1 | Survivorship Bias | +15–30% | Ignore les faillites, delistings | Univers frozen par date |
| 2 | Look-Ahead Bias | +10–25% | Signaux calculés sur données futures | Shift +1 barre minimum |
| 3 | Overfitting | +20–50% | Paramètres optimisés sur le bruit | Train/test split + OOS |
| 4 | Coûts oubliés | -5–15% | Spread, slippage, market impact | Coûts par tier de mcap |
| 5 | Regime Blindness | ±20% | Moyenne bull + bear = rien | Évaluation par régime |
| 6 | Cherry-Picking | +10–40% | Période qui flatte | Rolling windows |
| 7 | Stale Data Artifacts | Variable | Données fantômes | Replay temps réel |
Vous testez votre stratégie sur le S&P 500 d'aujourd'hui. Mais le S&P 500 de 2015 contenait des sociétés qui ont depuis fait faillite, été rachetées, ou délistées. En ne testant que sur les survivants, vous excluez automatiquement toutes les positions qui auraient été des pertes totales.
Chez DailyTickers, le cas INDO illustre parfaitement le problème. Ce ticker apparaissait dans les screeners avec des signaux techniques positifs, mais une analyse de dilution a révélé des programmes ATM toxiques. Sur un univers survivorship-biased, INDO n'apparaîtrait même plus — le ticker a été radié après effondrement.
« Acheter quand le RSI croise 30 par le bas. » Le RSI est calculé sur le prix de clôture. Mais dans un backtest naïf, le signal et l'exécution se font sur la même barre — vous « savez » que le RSI va croiser 30 avant que la barre ne se ferme. En réalité, vous ne pouvez exécuter qu'à l'ouverture de la barre suivante, au plus tôt.
Le look-ahead bias est particulièrement insidieux avec les indicateurs qui utilisent des moyennes mobiles (EMA, SMA) : le dernier point de la moyenne change jusqu'à la clôture. Un backtest qui entre « au moment du croisement » capture un prix qui n'était pas disponible au moment de la décision.
Vous testez 100 combinaisons de paramètres (période RSI × multiplicateur ATR × horizon). 5 combinaisons montrent des résultats « exceptionnels ». Est-ce du signal ou du bruit ? Avec 100 essais, la probabilité de trouver au moins un résultat à 2 écarts-types par pur hasard est supérieure à 99%.
L'overfitting est le piège le plus courant parce qu'il est le plus gratifiant : on « trouve » toujours les bons paramètres quand on cherche assez longtemps. Le résultat est une stratégie qui fonctionne parfaitement sur le passé et échoue immédiatement en live.
« Ma stratégie fait +80% par an. » Avec combien de trades ? Si c'est 500 trades sur des small-caps à $50M de market cap, le slippage seul peut manger 2% par trade aller-retour. 500 × 2% = 1000% de coûts de friction. La stratégie à +80% est en réalité à -920%.
Même sur les large caps, le spread bid-ask et l'impact de marché ne sont pas négligeables pour les stratégies haute fréquence. Un spread de 0,05% sur 200 trades/an = 10% de friction annuelle.
Votre stratégie momentum fait +40% en 2023 (bull) et -25% en 2022 (bear). La moyenne sur 2 ans est +7,5%. Mais cette moyenne est un mensonge : la stratégie ne fonctionne que dans un seul régime. Si le marché entre en bear au moment où vous la déployez, vous subirez -25% — pas +7,5%.
Le problème est aggravé par le fait que les régimes ne sont pas distribués uniformément : les marchés passent ~70% du temps en mode haussier. Un backtest sur 10 ans capture majoritairement du bull — la stratégie semble « robuste » alors qu'elle n'a jamais été vraiment testée en bear.
regimeFilters. On n'agrège qu'après, en pondérant par la fréquence
historique de chaque régime.
« Testé de janvier 2020 à décembre 2024. » Cette période inclut le crash COVID de mars 2020 suivi du plus grand rally de l'histoire. Toute stratégie qui achète les creux montre des résultats spectaculaires sur cette fenêtre — parce que chaque dip a été suivi d'un rebond violent. Testez la même stratégie de 2000 à 2003, ou de 2007 à 2009, et les résultats s'inversent.
Les données historiques ne reflètent pas ce qui était visible en temps réel. Les cours sont souvent ajustés rétroactivement (splits, dividendes). Les indicateurs fondamentaux sont révisés. Et certains « événements » dans les données n'ont jamais existé dans le flux temps réel.
Le bug du stale tightening de DailyTickers est un cas d'école : la fonctionnalité serrait les stops au breakeven après N jours sans nouveau plus haut. En backtest, le prix de breakeven était exact (prix d'entrée). Mais en réalité, le stop au breakeven exact est rarement touché — le prix peut osciller autour sans le déclencher, ou le déclencher sur un wick intraday invisible dans les barres daily. Le backtest créait des fermetures « fantômes » au breakeven qui n'auraient pas eu lieu en live.
deploying) sert précisément à comparer les résultats live vs backtest
sur la même période.
Source : Bailey, Borwein, López de Prado — « Pseudo-Mathematics and Financial Charlatanism » (SSRN)
Le stale tightening semblait être une bonne idée de gestion du risque : si une position ne fait pas de nouveau plus haut pendant N jours, serrer le stop au prix d'entrée (breakeven) pour « protéger le capital ». En théorie, c'est prudent. En pratique, c'est une machine à tuer les gagnants.
Le stale tightening fonctionne comme suit :
Les war rooms v6/v7 ont analysé chaque trade sur 6 mois. Voici les résultats par mode :
| Mode | Trades totaux | Breakevens | % BE | Profit laissé sur la table |
|---|---|---|---|---|
| Dynamic | 127 | 48 | 38% | +19% |
| Balanced | 89 | 37 | 42% | +31% |
| TKL | 74 | 34 | 46% | +64% |
TKL est le mode le plus touché parce que c'est un mode momentum : les noms momentum ont besoin de temps pour développer leur mouvement. Serrer le stop après 5-7 jours revient à couper la jambe d'un sprinter au milieu de sa course.
Le backtest avec stale tightening montrait un drawdown plus faible — évidemment, quand 40% de vos trades ferment à zéro, le DD est mécaniquement bas. Mais le rendement aussi. Les métriques standard (Sharpe, profit factor, win rate) ne distinguent pas un « bon » drawdown bas (peu de pertes) d'un « mauvais » drawdown bas (peu de gains). Il a fallu l'autopsie trade-par-trade pour voir le problème.
La solution a été double :
Un trade fermé au breakeven coûte réellement : le spread aller-retour (0,05–0,20%), le coût d'opportunité (le capital était bloqué pendant 5-7 jours), et le coût psychologique (une « non-opération » qui consomme de l'attention et de la discipline). Un système qui génère 40% de breakevens est un système qui brûle 40% de sa capacité pour rien.
Source : Investopedia — Trailing Stop ; cas interne DailyTickers war rooms v6/v7
Quand un bug est identifié ou qu'une config change, le réflexe est de « rejouer » la nouvelle config sur un segment historique pour quantifier l'impact. « Avant : DD -16%. Après : DD -4%. Amélioration de 75%. » Sauf que ces deux chiffres sont potentiellement faux.
Le segment replay — prendre une config et la simuler sur une fenêtre passée — souffre de trois problèmes fondamentaux :
En juin 2026, un segment replay du mode Dynamic sur avril-mai a signalé un drawdown de -16%. C'était alarmant — au-delà du seuil de tolérance de -8%. La réaction initiale était de modifier la config d'urgence.
Mais la vérification par les données frozen (les snapshots temps réel sauvegardés par le pit-engine à chaque séance) a montré un DD réel de -4,59%. Le segment replay surestimait par un facteur 3,5×. La cause : un phantom MtM de -8% sur une position NVDA ouverte avant le début du segment, combinée à un configVersion blend qui appliquait les stops v7 (plus larges) aux entries v6 (plus serrées).
| Métrique | Segment Replay | Frozen Reality | Erreur |
|---|---|---|---|
| Max Drawdown | -16,0% | -4,59% | ×3,5 |
| Return sur la période | +2,1% | +5,8% | -64% |
| Win rate | 52% | 58% | -6 pts |
| Trades comptés | 31 | 27 | +4 fantômes |
La solution n'est pas d'abandonner le replay — c'est d'abandonner les valeurs absolues qui en sortent. Au lieu de dire « la config A donne DD -16% et la config B donne DD -8% », on compare A et B sur le même replay avec le même modèle de MtM. Le delta relatif (B est meilleur de X% que A) est fiable, même si les valeurs absolues ne le sont pas.
// Correct : comparer A/B en relatif sur le même modeling const resultA = replay(configA, segment, { mtmModel: 'frozen' }); const resultB = replay(configB, segment, { mtmModel: 'frozen' }); const delta = { dd: resultB.maxDD - resultA.maxDD, // relatif → fiable ret: resultB.totalReturn - resultA.totalReturn, sharpe: resultB.sharpe - resultA.sharpe }; // INCORRECT : utiliser les valeurs absolues du replay // if (resultA.maxDD < -0.08) panic(); // peut être un phantom MtM
Pour les valeurs absolues (DD réel, return réel, PF réel), ne faites confiance qu'aux
données frozen_* du pit-engine et aux resweeps append-only. Jamais aux
reconstructions après-coup. Le segment replay ne sert qu'à comparer des configs
entre elles — pas à mesurer la réalité.
Source : Investopedia — Walk-Forward Testing
Un backtest qui agrège tous les régimes de marché dans une seule métrique commet la même erreur qu'un médecin qui moyenne la température de patients sains et fiévreux : la moyenne est « normale », mais elle ne décrit aucun patient réel.
Le scanner utilise le VIX (CBOE Volatility Index) comme proxy de régime de marché. Quatre niveaux sont définis, chacun avec des implications différentes pour les stratégies :
| Régime | VIX | Fréquence historique | Caractéristiques | Implication stratégie |
|---|---|---|---|---|
| Risk-On | < 15 | ~35% | Tendance haussière, faible volatilité | Momentum plein, stops serrés OK |
| Neutral | 15–20 | ~35% | Range-bound, rotation sectorielle | Sélectif, diversifié, stops moyens |
| Early Risk-Off | 20–28 | ~20% | Volatilité croissante, incertitude | Réduire taille, élargir stops, défensifs |
| Risk-Off | > 28 | ~10% | Panique, corrélations → 1 | Cash ou couvertures uniquement |
Considérons une stratégie momentum testée sur 2 ans :
| Régime | Durée (jours) | Rendement cumulé | Drawdown max |
|---|---|---|---|
| Risk-On (VIX < 15) | 175 | +32% | -3% |
| Neutral (15-20) | 175 | +8% | -6% |
| Early Risk-Off (20-28) | 100 | -4% | -12% |
| Risk-Off (> 28) | 50 | -18% | -22% |
| Agrégé (trompeur) | 500 | +18% | -22% |
L'agrégé montre +18% avec un DD de -22%. Ça semble acceptable. Mais ce qui compte pour l'opérateur, c'est : en quoi crois-tu, là, maintenant ? Si le VIX est à 25 (early risk-off), la stratégie perd -4% en moyenne sur ce régime. Le +18% agrégé n'est pas le monde dans lequel vous vivez.
La méthode walk-forward adapte les paramètres au régime courant :
L'outil optimize-param du scanner est utile pour explorer l'espace des
paramètres, mais ses résultats sont des artefacts statiques : il applique
des filtres figés sur toute la période, ignorant les changements de régime et de
configVersion. Les résultats surestiment systématiquement. Toute
modification de config suggérée par optimize-param doit être re-validée par
validate-config-change.js, qui est regime-aware et teste en OOS.
Source : CBOE — VIX Index methodology
La question fondamentale n'est pas « ma stratégie a-t-elle marché dans le passé ? » mais « ma stratégie marchera-t-elle sur des données qu'elle n'a jamais vues ? » La seule façon de répondre est le test out-of-sample (OOS) : réserver une portion des données que la stratégie n'a pas vue pendant l'optimisation, puis mesurer sa performance sur cette portion vierge.
Le split train/test est nécessaire mais pas suffisant. Même un bon OOS historique peut échouer en live à cause de différences d'exécution (slippage, latence, partial fills). Le paper-ramp est l'étape suivante : exécuter la stratégie en paper trading (sans argent réel) sur le marché live.
Le scanner DailyTickers utilise le statut deploying pour le paper-ramp :
| Mode | Statut | Début paper-ramp | Review date | Critère de passage |
|---|---|---|---|---|
| Alpha (Mode 7) | deploying | 4 juin 2026 | 4 juillet 2026 | Battre le DD du Nasdaq sur la même période |
| Orbit (ex-Secured) | deploying | 3 juin 2026 | 3 juillet 2026 | DD max ≤ 8%, win rate ≥ 50% |
Le paper trading élimine le risque financier mais introduit ses propres biais :
La war room a défini des critères stricts pour le passage en live :
| Critère | Seuil | Pourquoi |
|---|---|---|
| Surperformance hebdo vs SPY | ≥ 3× pendant 4 semaines | Prouver que le mode ajoute de l'alpha, pas juste du beta |
| Drawdown max | ≤ 8% | Seuil de tolérance opérationnel |
| Win rate | ≥ 50% | Seuil minimal pour la viabilité psychologique |
| Profit factor | ≥ 1.3 | Marge suffisante pour absorber les coûts réels |
| Ratio breakevens | < 15% | Leçon du stale tightening — trop de BE = problème |
| OOS/IS dégradation | < 30% | Robustesse des paramètres |
Un mode qui performe en paper et échoue en live révèle un problème d'exécution ou de psychologie — pas de stratégie. Un mode qui échoue en paper n'a même pas besoin d'être testé en live. Le paper-ramp est un filtre, pas une preuve. La preuve, c'est la performance live sur 3+ mois.
Source : Investopedia — Out-of-Sample Testing
Une war room est une session structurée d'analyse adverse où plusieurs perspectives indépendantes examinent le même système à la recherche de défauts. Ce n'est pas un brainstorm — c'est une chasse aux bugs systématique, avec des rôles définis et un protocole strict.
Voici les bugs majeurs identifiés lors des war rooms v6 → v7 → v7.1 du scanner DailyTickers. Aucun n'avait été détecté par les métriques standard du backtest :
| Bug | War room | Impact | Correctif |
|---|---|---|---|
| Dead Optimizer | v6 | L'optimiseur de paramètres ne tournait plus — les clés de config ne correspondaient plus aux clés du moteur d'exécution | Aligner les noms de clés config/engine |
| Score Mutation | v6 | Les scores de screening changeaient entre le moment de la sélection et l'exécution. Un ticker sélectionné à 92 pouvait être exécuté à 78 | Figer le score au moment du screening |
| Correlation Sign Error | v7 | La matrice de corrélation traitait les corrélations négatives comme positives — résultat : des positions corrélées à 0.9 passaient le filtre de diversification | Utiliser Math.abs() dans le gate de corrélation |
| BE-as-Loss | v7 | Les breakevens étaient comptés comme des pertes dans le calcul du profit factor, le faisant paraître meilleur qu'il ne l'était (dénominateur gonflé) | Exclure les BE du calcul du PF |
| Stale Tightening | v6/v7 | 38-46% de breakevens, +19-64% de profit abandonné | Désactiver, élargir ATR |
La war room v7.1 a produit un ensemble de correctifs systémiques, chacun validé par A/B replay avec delta relatif :
pausing (sortie organique, pas de nouvelles
entrées).// Extrait de validate-config-change.js // Compare l'ancienne et la nouvelle config en delta relatif async function validateChange(oldConfig, newConfig, segment) { const old = await replay(oldConfig, segment); const cur = await replay(newConfig, segment); const delta = { dd: cur.maxDD - old.maxDD, ret: cur.totalReturn - old.totalReturn, pf: cur.profitFactor - old.profitFactor, winRate: cur.winRate - old.winRate, beRate: cur.breakEvenRate - old.breakEvenRate, }; // Régression check : aucune métrique ne doit se dégrader de plus de 5% const regressions = Object.entries(delta) .filter(([k, v]) => { if (k === 'dd' || k === 'beRate') return v > 0.05; // plus haut = pire return v < -0.05; // plus bas = pire }); return { approved: regressions.length === 0, delta, regressions, }; }
deploying → liveSource : Bailey, Borwein, López de Prado — « Pseudo-Mathematics and Financial Charlatanism » (SSRN) ; voir aussi Investopedia — Stress Testing
Un backtest honnête produit des rendements plus faibles qu'un backtest malhonnête. C'est structurellement garanti : chaque biais corrigé retire de la performance fictive. Ce qui reste est la vraie capacité de la stratégie — et elle est toujours inférieure à ce que le backtest naïf promettait.
| Métrique | Backtest naïf | Backtest honnête | Live (3 mois) |
|---|---|---|---|
| Return annualisé | +45% | +18% | +15% |
| Max Drawdown | -6% | -11% | -9% |
| Sharpe Ratio | 2.8 | 1.4 | 1.2 |
| Win Rate | 68% | 55% | 53% |
| Profit Factor | 3.2 | 1.6 | 1.5 |
| Écart BT→Live | -67% | -17% | — |
Le backtest naïf promet +45% et livre +15% : un écart de -67%. Le backtest honnête promet +18% et livre +15% : un écart de -17%. Les deux convergent vers la même réalité live, mais le backtest honnête vous y prépare au lieu de vous décevoir.
Le mode Fortress de DailyTickers illustre le danger de l'optimisation malhonnête. Le mandat de Fortress est clair : « participer à la hausse SANS plafonner les rendements + parachute toujours actif contre les retournements soudains ». Autrement dit, capturer l'upside avec un filet de sécurité contre le downside.
Un backtest naïf suggérait « breakout-only everywhere » — n'acheter que sur cassure de résistance, avec des stops serrés. En backtest, les résultats étaient spectaculaires : aucun drawdown significatif (parce que les stops serrés coupent vite). Mais en réalité, cette approche bride les rendements : on n'entre que sur les cassures (manquant les accumulations), et les stops serrés sortent trop tôt des trades gagnants.
La solution honnête, identifiée par la war room, était un mécanisme de trailing locks (qui verrouillent les gains progressivement) combiné à la décorrélation de cluster (diversifier les positions pour qu'un retournement sectoriel ne les touche pas toutes) et le de-risking sur détérioration de régime (réduire l'exposition quand le VIX monte).
Le Sharpe gap = Sharpe du backtest – Sharpe du live. C'est la métrique la plus simple pour évaluer l'honnêteté d'un backtest. Un gap < 0.3 est excellent (le backtest est réaliste). Un gap entre 0.3 et 1.0 suggère des biais non corrigés. Un gap > 1.0 indique un backtest fondamentalement malhonnête — les paramètres sont overfittés et la stratégie ne survivra pas en live.
Les gestionnaires qui montrent des backtests conservateurs (Sharpe 1.2–1.5, return modéré) et les matchent en live surperforment systématiquement ceux qui montrent des backtests spectaculaires (Sharpe 2.5+, return élevé) et sous-performent en live. La raison est simple : le premier groupe a éliminé les biais et mesure la vraie capacité de sa stratégie. Le second groupe a optimisé les biais et découvre en live que sa stratégie est beaucoup moins bonne que prévu.
En tant qu'investisseur, un backtest « trop beau » devrait vous rendre plus sceptique, pas moins. La beauté des résultats est inversement corrélée à leur fiabilité. Les meilleurs signaux sont les backtests modestes qui tiennent leurs promesses.
Jamais. Si le backtest est destiné à guider une décision d'investissement — même indirectement, même « juste pour voir » — il doit passer par le filtre OOS et idéalement par une war room. La seule exception est un backtest explicitement exploratoire, marqué comme tel, et jamais utilisé pour communiquer des résultats à un tiers.
Source : Harvey, Liu, Zhu — « …and the Cross-Section of Expected Returns » (SSRN)
Cette checklist résume les leçons de trois war rooms, des centaines d'heures d'analyse, et des milliers de trades autopsiés. Chaque point correspond à un bug réel que nous avons découvert — et que nous aurions voulu connaître avant de l'apprendre à nos dépens.
frozen_*) ou d'un segment replay reconstruit ?deploying)
d'au moins 4 semaines a-t-il confirmé les résultats avant le passage live ?Un backtest honnête ne vous dit pas ce que vous voulez entendre — il vous dit ce que vous avez besoin de savoir. La différence entre un trader qui survit 10 ans et un qui explose en 10 mois n'est pas la qualité de sa stratégie, mais la qualité de sa validation.
Les war rooms coûtent du temps. L'OOS réduit la taille de l'échantillon d'entraînement. Le paper-ramp retarde le passage en live de 4 semaines. Les coûts modélisés réduisent les rendements affichés. Chacune de ces « concessions » est un investissement dans la survie à long terme — et aucune n'est négociable.
Le backtest parfait n'existe pas. Mais le backtest honnête — celui qui a survécu à une war room, passé l'OOS, confirmé en paper-ramp, et dont le Sharpe gap est inférieur à 0.3 — est le meilleur outil dont dispose un trader systématique.
Harnesses IA en Finance —
comment contraindre les modèles à produire des résultats fiables.
Workflows Multi-Agents —
orchestrer des escouades d'agents pour la vérification adverse.
Inside the Scanner Pipeline —
comment le scanner DailyTickers transforme les signaux en positions.
Source : López de Prado — « Machine Learning for Asset Managers » (SSRN)