PF 1.40 sur backtest, 0/5 en walk-forward — autopsie d'une stratégie qui semblait gagnante
Il y a quelques jours, j'ai lancé un backtest sur une stratégie que je voulais évaluer : un setup type ORB + FVG retest (Opening Range Breakout + Fair Value Gap) sur l'or (XAU/USD) et l'euro/dollar (EUR/USD). C'est un setup populaire dans les communautés ICT/SMC.
Le résultat brut était excellent. Trop excellent, en fait. Voilà comment j'en suis venu à le rejeter, en deux étapes.
La stratégie en une minute
Pour chaque session de marché (Asie, Londres, Comex, NY) :
- Opening Range — je note le plus haut et le plus bas pendant les 30 premières minutes de la session.
- Breakout — j'attends la première bougie M1 qui clôture au-dessus du range (long) ou en dessous (short).
- FVG — je cherche un Fair Value Gap dans le sens du breakout : un gap entre le plus haut de la bougie N-1 et le plus bas de la bougie N+1.
- Retest — j'entre quand le prix revient toucher cette FVG.
- Risque — stop-loss au-delà d'une référence structurelle, take-profit à 1× la distance du SL (R:R = 1).
Trois grandes décisions à tester : comment définir la FVG, où placer le SL, comment caractériser le retest. Avec 5 sessions et 3 variantes par décision, ça fait 5 × 3 × 3 × 3 = 135 configurations sur l'or, plus 81 sur l'euro/dollar (3 sessions × 27).
Phase 1 — le backtest "full data"
J'ai tourné les 216 configs sur ~2 ans de données M1 (2024-01 → 2026-03). Première leçon pendant le run : les coûts comptent énormément.
Le piège des coûts
Le moteur de backtest utilisait par défaut total_per_trade = 0.19 % round-trip — c'est réaliste pour des perps crypto (Binance Futures), totalement faux pour l'or au comptant. Avec ces coûts, toutes les configurations sortaient PF ≤ 0.25 — l'air d'une stratégie morte.
En réalité, sur un broker CFD or correct (spread 0.3-0.5 pips + slippage 0.5 pip), le coût round-trip est plutôt 0.02 % — environ dix fois moins. Une fois la correction faite, les résultats sont devenus interprétables.
Les 5 configs gagnantes
Après correction des coûts, 5 configurations sortaient avec PF ≥ 1.20 sur les 135 testées :
Toutes sur la session Asie 00:00 UTC. Toutes avec un SL placé à l'opposé du range d'ouverture (orb_opposite). Le pattern semblait robuste : 3 définitions différentes de FVG (strict, avec filtre ATR, fenêtre 5 bougies) × 3 mécaniques de retest, et le résultat convergeait. C'est exactement le genre d'insensibilité paramétrique que je cherchais : ça suggère un edge structurel, pas un overfit aux paramètres.
Côté EUR/USD : zéro configuration au-dessus de PF 1.0, le meilleur sortait à PF 0.46. NO_GO clair.
Phase 2 — la walk-forward
C'est la dernière étape avant tout paper. Le principe est simple et il sauve la mise plus souvent qu'on ne le pense :
Identifie les meilleurs paramètres sur une portion passée des données (in-sample). Mesure-les sur une portion future qu'ils n'ont jamais vue (out-of-sample). Si l'edge tient sur l'OOS, c'est probablement réel. Sinon, c'est du data-mining.
J'ai coupé les données 70/30 :
- IS (in-sample) : 2024-01-01 → 2025-07-16 — 545 673 bougies M1, ~18 mois
- OOS (out-of-sample) : 2025-07-16 → 2026-03-13 — 233 861 bougies M1, ~8 mois
J'ai relancé les 135 configurations sur l'IS uniquement, sélectionné le top 5 par PF, puis évalué ces 5 sur l'OOS sans toucher aux paramètres.
Surprise #1 : l'IS donne un top 5 complètement différent
4 sur 5 sont des configurations NY 14:30 UTC — plus aucune trace de l'Asie. Et quand je regarde les PF des fameuses configs Asie sur cette portion IS seulement, elles étaient sous l'eau : PF 0.80 à 0.87. Si je n'avais que vu l'IS, je n'aurais jamais sélectionné les configs Asie.
Premier signal d'alarme : la sélection change radicalement selon la fenêtre observée.
Surprise #2 : sur OOS, les configs IS s'effondrent
Zéro configuration sur cinq ne tient le seuil PF ≥ 1.10 sur l'OOS. Le PF moyen chute de 1.18 à 0.79. Le WR chute de 5 à 10 points. C'est un effondrement systématique.
Le diagnostic n'est pas du simple data-mining — c'est un régime shift
Si l'IS picke NY et que NY s'effondre sur OOS, et que sur full data l'Asie domine alors qu'elle était sous l'eau sur l'IS — la lecture la plus probable est qu'il y a eu un changement de microstructure mi-2025.
On peut le retraduire numériquement : les configs Asie avaient un IS PF d'environ 0.85 sur 184 trades, et un full PF de 1.40 sur 260 trades. Les 76 trades supplémentaires (qui sont sur la portion OOS) doivent avoir un PF très élevé — probablement entre 1.8 et 2.5 — pour faire passer la moyenne d'environ 0.85 à 1.40.
En d'autres termes : un edge ORB+FVG existe peut-être réellement sur la session Asie depuis juillet 2025, mais il n'existait pas avant. Pendant ce temps, un autre edge (NY + ATR filter) qui était présent en 2024-2025 a disparu.
Le problème pour une décision de trading : je ne peux pas savoir quel edge tiendra le prochain mois. Le winner d'une période est remplacé par le winner d'une autre, sans signal prédictif identifiable.
Limite statistique
Je reste honnête : 75 trades par configuration sur l'OOS, c'est peu. L'intervalle de confiance autour de PF 0.78 est large (environ ±0.15). Donc "PF < 1.0 OOS" ne veut pas dire "edge strictement négatif", ça veut dire "pas d'edge mesurable sur 75 trades". C'est suffisant pour rejeter un GO, ça ne prouve pas que la stratégie est dans le négatif définitif.
Ce que je garde quand même
Même avec un NO_GO sur la stratégie globale, le travail produit trois insights structurels :
-
orb_oppositeest le seul placement de SL viable sur ce type de setup. Toutes les sessions, toutes les périodes —fvg_opposite(SL à 1 tick au-delà de la FVG) était mort partout (la distance était trop serrée par rapport au bruit du marché).swing_structureétait borderline. C'est un pattern réutilisable pour de futures stratégies breakout, hors du framework ORB+FVG. -
Le coût domine quand le SL est serré. Une stratégie à SL ≈ 0.05 % du prix est massivement exposée à un coût mal modélisé. Si tu lis quelque part qu'une stratégie a un PF magique sans voir explicitement quel coût a été utilisé, méfiance.
-
Le WR autour de 50-55 % à R:R 1 est le bon ordre de grandeur pour ce type de setup ICT/SMC. Quand des configs reportent un WR < 20 % à R:R 1, c'est qu'il y a un bug mécanique (entry à l'intérieur du SL, stop-out instantané, etc.). Quand elles oscillent autour de 45-55 %, c'est qu'on est dans le domaine du vrai bruit stratégique. Ça donne un repère de sanity check pour les prochains backtests sur des setups similaires.
Pourquoi je publie ça
Trois raisons.
D'abord, parce que la majorité du contenu trading ne publie que les wins. On voit rarement, dans un fil Twitter ou une vidéo YouTube, "j'ai testé cette stratégie, le backtest disait PF 1.40, la walk-forward l'a tuée, voici pourquoi". Pourtant c'est exactement ce qui arrive le plus souvent dans la vraie vie d'un quant.
Ensuite, parce que la discipline de méthode est rare même chez les pros. Tester sur full data, lister des "stratégies gagnantes" basées sur ce résultat, puis passer à la production — c'est le piège classique. La walk-forward 70/30 est l'outil le plus simple qui existe pour s'en prémunir, et il est sous-utilisé.
Enfin, parce qu'un résultat honnête est une donnée utile. Si quelqu'un d'autre essaie de trader cette même configuration, sachant que le backtest était excellent mais la walk-forward négative, ça change la décision. Et si quelqu'un me lit et pense "tiens, je devrais regarder pourquoi l'edge a changé de session à mi-2025" — peut-être que cette personne trouvera quelque chose que je n'ai pas vu.
Et maintenant ?
- Pas de paper trading sur cette stratégie. Archivée NO_GO.
- Pattern
orb_oppositeSL gardé en tête pour des designs futurs. - Décision pending : faire une walk-forward roulante sur 4-5 fenêtres pour quantifier l'instabilité régime-par-régime. Ça ne changera pas la décision actuelle (toujours NO_GO), mais ça me dirait si l'instabilité est universelle sur ce setup ou seulement présente sur cette fenêtre 2024-2026. Pas urgent.
Les artefacts bruts (JSON par configuration, scripts, logs) sont disponibles dans mon vault de recherche apex-trading. Si quelqu'un veut reproduire le backtest avec un autre cost model, un autre split, ou ajouter des sessions, le code est conçu pour ça.
Une stratégie morte avant le live, c'est de l'argent qui n'est pas perdu. Le job du backtest, c'est de tuer ce qui peut l'être avant que ça ne coûte cher.
Suivre la recherche
Si cet article t’a servi : je publie mes backtests, mes rejets et les évolutions du labo. Laisse ton email pour recevoir les prochains write-ups. Pas de spam, désinscription sur simple réponse.