L'optimisation walk-forward a la réputation d'être la manière honnête de calibrer une stratégie, et elle la mérite — comparée à une optimisation sur l'intégralité des données suivie d'une contemplation admirative du résultat. Mais la technique a des modes de défaillance discrets, et chacun produit le même artefact : un rapport de validation qui affiche « robuste », agrafé à une stratégie qui ne l'est pas. Voici les trois contre lesquels nous avons dû nous prémunir, classés par les dégâts qu'ils laissent derrière eux.
Défaillance n° 1 : les fenêtres fuient
La mauvaise approche : calibrer sur janvier-juin, valider sur juillet, puis laisser quoi que ce soit issu de juillet influencer une deuxième passe — une relance après avoir vu le chiffre out-of-sample, un « petit ajustement » de la grille de paramètres, une variable normalisée sur la série entière. Chaque geste paraît innocent. Ensemble, ils transforment la fenêtre out-of-sample en données in-sample, avec un simple décalage.
Les dégâts : un Sharpe out-of-sample qui suit mystérieusement le Sharpe in-sample. Les vrais résultats out-of-sample sont bruités et décevants ; une relation IS/OOS suspicieusement lisse signifie que l'information remonte à contre-courant. Nous surveillons ce ratio explicitement — un in-sample supérieur à 3x l'out-of-sample signale le run, et un out-of-sample inférieur ou égal à zéro le tue, aussi flatteur que soit l'in-sample.
Défaillance n° 2 : le magasinage de métriques entre fenêtres
On lance trois fenêtres walk-forward, on obtient trois résultats bruités, puis on résume : Sharpe moyen ? Médian ? On écarte la pire fenêtre pour cause de « changement de régime » ? Chaque choix est un degré de liberté, et un optimiseur déterminé (humain ou bayésien) trouvera le résumé sous lequel cette stratégie brille le plus. Soixante-quinze essais Optuna par fenêtre, ce sont soixante-quinze occasions d'ajuster du bruit, multipliées par le nombre de résumés qu'on est prêt à envisager.
Les dégâts : une stratégie qui passe la validation puis délivre en réel la performance de la pire fenêtre, parce que la pire fenêtre était la seule honnête. Notre règle : l'agrégation est figée dans la config avant le run, le budget d'essais est figé, et l'analyste lit les résultats fenêtre par fenêtre, dispersion affichée. Une stratégie qui a besoin du résumé complaisant pour passer ne passe pas.
Défaillance n° 3 : le holdout qui a cessé d'en être un
Un holdout ne fonctionne qu'une seule fois. La deuxième fois qu'une stratégie y est confrontée — après un ajustement de paramètre, une retouche de signal, un « juste pour vérifier » — ce n'est plus un holdout ; c'est un jeu de validation au ralenti. Quinze jours intacts, ça semble trivial à préserver, jusqu'à ce que la pression de l'itération arrive et qu'une nouvelle vérification paraisse inoffensive.
Les dégâts sont subtils : des résultats de holdout qui s'améliorent au fil des itérations d'une même stratégie. Des données out-of-sample fraîches n'ont aucune raison de récompenser l'itération trois plutôt que l'itération une, et quand elles le font, c'est que le holdout a été exploité. Nous imposons le coup unique de façon mécanique : le holdout est évalué une fois par run de pipeline, le résultat est inscrit au dossier, et une stratégie qui a besoin d'une nouvelle tentative repasse par tout le parcours — nouvelles fenêtres comprises. Elle doit conserver au moins 70% du Sharpe out-of-sample du walk-forward, et ce dé-là ne se relance pas.
Le signe qui survit aux trois
Avant tout cela, nous lançons un simple balayage de sensibilité : on décale chaque paramètre de ±20% et on observe les métriques. Un vrai edge se dégrade en douceur ; une coïncidence tombe d'une falaise. C'est le test le moins cher du pipeline, et il oppose son veto à des stratégies qui auraient traversé sans encombre tout ce qui précède — parce qu'une falaise de paramètre, c'est à quoi ressemble le surapprentissage avant qu'on lui ait laissé l'occasion de se cacher dans la machinerie de validation.
Rien de tout cela ne rend l'optimisation sûre. Cela rend les modes de défaillance bruyants — c'est le maximum qu'on puisse honnêtement demander à un processus de validation.
← Tous les articles