Tests de robustesse pour stratégies de trading

Tu as construit une stratégie qui avait l'air bonne dans le backtest, et maintenant tu fixes une liste de noms comme Monte Carlo, System Parameter Permutations, matrice walk-forward et « Retest on additional markets ». Lesquels te faut-il, et dans quel ordre ? À la fin de ce texte, tu sauras ce que ces vérifications représentent individuellement et comment elles s'enchaînent dans un exemple documenté.

Pourquoi la liste des cross-checks rebute au début

La plupart des traders tombent pour la première fois sur les tests de robustesse quand une stratégie affiche déjà de bons chiffres dans le backtest et que le logiciel propose de la vérifier en plus. Une série de dénominations apparaît alors, sans que l'on voie tout de suite ce que chacune fait réellement. Ce n'est pas un hasard : ces vérifications ne sont pas une étape unique, mais une boîte à outils avec différents outils pour différentes questions.

Ce que les tests de robustesse vérifient et contre quoi ils doivent aider

Les tests de robustesse, aussi appelés cross-checks, sont décrits comme une partie intégrante de StrategyQuant. Leur but : vérifier automatiquement comment une stratégie se comporte sous pression, par exemple quand des trades individuels sont sautés ou que des valeurs de paramètres sont légèrement modifiées. L'idée derrière est simple : une stratégie dont le résultat s'effondre déjà sur de petits changements était peut-être taillée trop précisément pour les données disponibles.

Important ici : réussir ces tests ne prouve pas qu'une stratégie n'est pas surajustée, et un résultat robuste dans ces conditions simulées n'est pas une garantie de gains futurs. Les tests montrent un comportement sous certaines perturbations, rien de plus.

Les quatre vérifications intégrées en aperçu

La documentation du fabricant décrit les tests de robustesse intégrés comme un groupe de quatre vérifications : simulations Monte-Carlo, System Parameter Permutations, une vérification du Optimization Profile et une matrice walk-forward. Ces quatre peuvent, d'après la documentation, être activées ou désactivées ensemble comme groupe pour contrer le surajustement. La désignation exacte et l'agencement dans ta version peuvent légèrement différer de cet aperçu, mais le principe d'un groupe regroupé reste le même.

La mise en parallèle de ces quatre contrôles ne remplace pas ta propre lecture des résultats. Le groupe aide à écarter tôt les stratégies visiblement fragiles, mais il ne te dispense pas d'examiner toi-même les candidats qui survivent.

Comment le Robustness Tests Tool fonctionne avec Monte Carlo

Derrière le contrôle Monte-Carlo se cache un mécanisme simple : le Robustness Tests Tool répète le test d'une stratégie avec des paramètres d'entrée modifiés aléatoirement et des données modifiées aléatoirement. De ces nombreuses répétitions naît une simulation Monte-Carlo, dont le résultat est affiché avec des niveaux de confiance.

Un niveau de confiance n'est pas une promesse. Il dit quelque chose sur la dispersion des exécutions simulées, pas sur ce qui se passe réellement en live. Et une seule exécution Monte-Carlo ne suffit de toute façon pas comme preuve de robustesse, c'est bien pour cela que l'idée de répétition existe.

Une documentation plus ancienne, valable pour les versions jusqu'à 3.6.1, décrivait le même principe de base avec un nombre fixe d'exécutions de test réglé par l'utilisateur : la stratégie était ensuite examinée pour voir comment elle réagissait à de petites modifications des entrées, des données historiques ou d'autres composants. Le principe de base, introduire de petits changements et observer la réaction, n'est donc pas nouveau, même si les versions actuelles peuvent le nommer autrement ou le construire autrement.

Un exemple simple : retest sur des marchés supplémentaires

L'un des contrôles les plus parlants est le retest sur des marchés supplémentaires. La même stratégie y est testée à nouveau sur d'autres marchés, donc sur d'autres symboles et ou d'autres unités de temps que ceux sur lesquels elle a été construite et testée à l'origine.

C'est une bonne entrée en matière, parce que le principe se comprend facilement : une stratégie dont la logique est taillée uniquement pour le tracé exact des cours d'un seul symbole donnera souvent de moins bons résultats sur un autre symbole. Réussir cette vérification ne prouve pas pour autant que la stratégie fonctionne sur n'importe quel marché ou unité de temps. Cela montre seulement comment elle s'est comportée sur les marchés supplémentaires testés concrètement.

Un exemple d'entonnoir : comment les cross-checks s'enchaînent

La liste des vérifications paraît longue quand on la regarde dans son ensemble. Dans la documentation, on trouve un exemple de la façon dont des cross-checks individuels peuvent s'enchaîner dans un ordre, de sorte que chaque stratégie ne passe pas chaque vérification dans toute sa profondeur.

Dans cet exemple, une stratégie nouvellement générée est d'abord testée avec la précision la plus rapide disponible. Si elle échoue aux filtres globaux, elle est écartée automatiquement, sans que d'autres vérifications plus coûteuses soient même lancées. Seules les stratégies qui passent cette première étape sont transmises à des vérifications plus précises, par exemple un retest avec une précision plus élevée et une vérification Monte-Carlo qui manipule des trades individuels.

L'important, c'est le cadre de cet exemple : c'est une configuration possible, pas un déroulé imposé que chaque projet doit suivre exactement de cette manière. Et même celui qui traverse tout cet entonnoir n'a pas encore montré pour autant que la stratégie fonctionnera de la même façon en live.

L'ancien chemin en cinq étapes comme contexte

Une documentation plus ancienne, également pour des versions jusqu'à 3.6.1, décrivait un chemin en cinq étapes pour vérifier la robustesse d'une stratégie : d'abord passer en revue la période out-of-sample, puis tester sur des symboles et des unités de temps supplémentaires, ensuite lancer des tests de robustesse basés sur Monte-Carlo et enfin, dans une vue dédiée à l'analyse de robustesse, passer en revue les courbes d'equity obtenues et un tableau de niveau de confiance.

Ce déroulé est utile comme contexte, parce qu'il montre que l'idée de base, appliquer plusieurs vérifications indépendantes les unes après les autres, fait partie de l'outil depuis un moment. Comme instruction exacte pour une version actuelle, il ne convient pas : les noms des onglets et les étapes individuelles peuvent avoir une autre apparence dans des versions plus récentes.

Ce que ces tests peuvent montrer, et ce qu'ils ne peuvent pas montrer

Chacune des vérifications décrites ici repose sur la même idée de base : faire tourner une stratégie sous des changements simulés de paramètres passés, de trades passés ou de données passées, et observer ce qui se passe. C'est un filtre utile pour repérer les stratégies dont le bon résultat de backtest était lié à des conditions très spécifiques.

Ce que ces tests ne fournissent pas, c'est une preuve pour l'avenir. Un retest réussi sur des marchés supplémentaires, un bon niveau de confiance issu d'une simulation Monte-Carlo ou la survie à tout un entonnoir de vérifications dit quelque chose sur le comportement sous ces conditions concrètes et passées. Cela ne dit rien sur la façon dont la même stratégie se comportera sous des conditions de marché futures, pas encore observées.

Cet article a une visée éducative et ne constitue pas un conseil en investissement. Les résultats passés, y compris ceux des backtests, ne garantissent pas les résultats futurs. Négocier des instruments financiers comporte des risques et tu peux perdre de l'argent.