Introduction

Whale‑E est un moteur de backtesting en ligne de commande conçu pour le marché des cryptomonnaies. Il teste et optimise des stratégies de trading à partir de données historiques issues de plusieurs plateformes d’échange.

La stratégie s’écrit en TOML, un format déclaratif et lisible. Vous n’avez pas besoin d’écrire du code : vous combinez des indicateurs et des blocs conditionnels pour définir les règles d’entrée et de sortie de vos trades.

Dans votre stratégie, vous n’indiquez pas une seule valeur pour chaque paramètre, mais une plage ou un ensemble de valeurs possibles. Toutes ces combinaisons sont ensuite testées. Pour chaque test, un objectif que vous définissez calcule un score. Ce score sert ensuite à trier les résultats et à sélectionner les configurations les plus performantes selon votre critère.

Pour une même stratégie et une même combinaison de paramètres, les résultats restent toujours identiques. Vous pouvez aussi exporter une configuration de backtest en Pine Script pour vérifier une combinaison hors du moteur.

Pour tester tous les paramètres qui varient dans une stratégie, on utilise une méthode d’optimisation appelée grid search. Cette méthode consiste à explorer systématiquement toutes les combinaisons possibles des paramètres définis dans votre fichier TOML.

Prenons l’exemple d’une moyenne mobile. Plutôt que de fixer un seul type de moyenne, vous pouvez tester plusieurs variantes, par exemple SMA, EMA ou WMA. Pour chaque type de moyenne, vous définissez ensuite une plage de longueurs possibles, par exemple de 10 à 50 périodes.

Cette exploration distingue alors deux niveaux :

  • les grilles, qui regroupent tous les choix « qualitatifs » fixés, comme le type de moyenne, la source de prix, le timeframe ou le symbole
  • les hyperparamètres, qui ne concernent que des paramètres numériques, comme la longueur de la moyenne mobile, et qui sont explorés à l’intérieur de chaque grille.

Pour chaque grille et chaque combinaison d’hyperparamètres, un backtest est exécuté, puis le résultat est évalué selon la objectif que vous avez définie, ce qui permet de trier les backtests et de sélectionner les configurations les plus intéressantes selon vos critères.

Il existe d’autres méthodes d’optimisation que le grid search, comme les algorithmes génétiques ou l’optimisation bayésienne. Ces approches ne testent qu’une partie des combinaisons possibles : elles cherchent à se rapprocher de la meilleure solution en explorant en priorité les zones les plus prometteuses de l’espace de paramètres. Leur avantage est de pouvoir proposer de bonnes configurations avec beaucoup moins de tests, ce qui réduit le temps de calcul lorsque l’espace de recherche est très vaste.

Le grid search adopte une démarche différente : il teste chaque combinaison une par une, ce qui couvre toutes les possibilités définies au départ, au prix d’un nombre de tests plus élevé.

Croissance du nombre de combinaisons

Avec le grid search, le nombre de combinaisons augmente très vite dès que vous ajoutez des paramètres ou des valeurs possibles pour chaque paramètre.

Si vous définissez 3 paramètres avec 50 valeurs chacun, vous obtenez déjà 50³, soit 125 000 combinaisons. Avec 4 paramètres, on passe à 50⁴, soit 6 250 000 combinaisons. Avec 5 paramètres, 50⁵ représente 312 500 000 combinaisons, et avec 6 paramètres, 50⁶ monte à environ 15,6 milliards de combinaisons.

Le temps de calcul augmente en conséquence. A titre indicatif, quelques centaines de milliers de combinaisons se traitent généralement en secondes, quelques millions en secondes ou en minutes, et des centaines de millions peuvent déjà représenter des heures. Au-delà du milliard de combinaisons, le temps de calcul tend à se compter en jours, même sur un processeur récent, selon la stratégie et la machine utilisée.

Le grid search reste pertinent tant que l’espace de recherche reste maîtrisé.

Sur-optimisation et performances historiques

Quand vous explorez un grand nombre de combinaisons de paramètres avec un grid search, le risque de sur-optimisation augmente : la stratégie finit par s’ajuster aux particularités de l’historique utilisé plutôt qu’à des comportements de marché récurrents.

Des performances élevées en backtest montrent surtout que la stratégie s’ajuste aux données passées. Elles ne garantissent pas des résultats similaires à l’avenir.

L’objectif n’est pas seulement de maximiser la performance sur l’historique, mais d’augmenter les chances que la stratégie reste valable sur des données nouvelles, dites hors-échantillon, c’est-à-dire qui n’ont pas servi à l’optimisation. Pour limiter le risque de sur-optimisation, il existe des méthodes de validation spécifiques : tests hors-échantillon, procédures de type walk-forward, analyses de robustesse, etc.

L’optimisation reste une première étape, à compléter par des méthodes de validation et par l’examen de la cohérence économique de la stratégie avant toute utilisation en conditions réelles.