Ne faites pas confiance aux gens qui exhibent leurs backtests.

Aujourd'hui, nous allons parler de backtest. Un backtest, c'est évaluer une stratégie actuelle sur une période historique avec des données réelles. Ce thème s'est développé ces dernières années avec l'ascendance des méthodes quantitatives. Par le passé, personne ne parlait de backtest. Quand Charles Dow énonce sa fameuse théorie dans les éditos du Wall Street journal, il ne doit fournir aucune preuve. Sa démarche est empirique : Elle n'est pas validée par une protocole expérimental ou un modèle quantitatif. De nos jours, Il est impossible de se passer d'un backtest, mais c'est aussi une des pires sources d'erreur. Les backtest introduisent un biais systématique, et éviter ce biais ou le corriger nécessite un tel degré de prophylaxie, qu'il est virtuellement impossible que toutes les précautions soient appliqués.  Je vais être très clair dès le départ, un backtest ne prouve pas qu'une stratégie va fonctionner dans le futur. Et inversement, ce qui est beaucoup moins intuitif, un backtest peu reluisant peu aussi cacher une stratégie performante.  Les backtests sont un seul et même indicateur, et pris séparément ils ne peuvent expliquer qu'une toute petite partie des éléments qui vont présider au succès d'une stratégie.
Malheureusement, il s'ajoute parfois à l'erreur humaine, la pure et simple malhonnêteté intellectuelle. Sous prétexte de promotions, certaines entreprises, que je ne citerai pas pour des raisons évidentes, utilisent des backtests tellement biaisés, qu'on arrive à deux concluions, la première c'est qu'ils ne peuvent pas l'ignorer, et la seconde inévitable et qu'ils vous prennent pour des imbéciles.

Où les choses commencent à mal tourner

Revenons en arrière, et reprenons notre raisonnement depuis le départ. Supposons que vous ayez construit une stratégie automatisée. Cette stratégie se traduit par des règles de trading (rééquilibrer mon portefeuille tous les mois) et par une série d'allocations proposée dans le temps. Avec un backtest vous allez surveiller l'exécution de votre stratégie dans un intervalle du passé. Votre premier backtest ne sera pas très performant, mais vous pouvez moduler votre stratégie avec des paramètres. Vous pouvez changer l'heure ou la date de trading, ou favoriser les actifs qui ont du momentum, ou une volatilité faible. Vous allez conduire de manière itérative un cycle de backtest suivi d'une phase d'optimisation des paramètres, et ainsi de suite jusqu'à obtenir le niveau de performance qui vous convient.
Cette démarche est suivie par toute la profession financière. Il y a pourtant plusieurs problèmes avec cette approche. Le premier, c'est le choix de la période de backtest. Si on fait un backtest en 2008 ou en 2016, avec des conditions de marchés différentes, on va obtenir des résultats différents. Si on utilise une fenêtre très longue, on risque d'adapter sa stratégie à des conditions de marché qui sont obsolètes actuellement, si c'est une fenêtre courte on ne connait pas la performance de l'algorithme en période de stress…. Je passe rapidement, car ce n'est qu'une petite partie du problème.
Le cœur du problème, C'est que vous allez adapter votre algorithme pour qu'il produise le plus haut degré de performance avec les données de votre période de test. Avec le temps, votre algorithme va évoluer vers la version qui colle le plus avec les spécificités de votre ensemble de test, et pas celle qui offre le plus de généralisation. Pour donner un exemple, supposons que vous ayez trois actifs A,B et C et que votre période de test soit de 2008 à 2017. En 2009, l'actif A fait un saut de plus de 100%. Ce saut n'a pas vocation à se répéter. Mais quand vous allez tester plusieurs versions de votre algorithme, toutes les versions de votre algorithme qui ne sont pas investies dans A en 2009 seront immédiatement rejetés car cette observation pèse énormément sur la performance finale de l'algorithme. Dans tous les ensembles de données, on peut trouver des observations ponctuelles qui dominent toutes les autres, on appelle ça le bruit statistique, et qui excluent tous un spectre de paramètre tout à fait valide. Ce problème est souvent appelé overfitting. Cette problématique est liée au fait que déterminer si un résultat est dû à la chance ou à un pouvoir de généralisation/prédiction est un problème plus général et une tâche difficile en théorie et en pratique.
A titre d'illustration, je vous invite à consulter le travail du chercheur Marcos López de Prado, Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance. Il prouve qu'avec un nombre limité d'itérations de backtests, il est possible de construire une stratégie grossière capable de générer n'importe quel niveau de performance prédéterminé. Ces stratégies se révèlent bien sûr toutes inutiles dans des conditions réelles (Out-of Sample).
A moins de mettre en place des méthodes statistiques lourdes et pénalisantes pour contrôler ce risque, ce biais méthodologique est inévitable. Qui plus est, c'est un biais qui est asymétrique. Comme tous les acteurs cherchent à maximiser leur performance, il est impossible pour eux de sélectionner des stratégies qui ont des performances non conformes à leur attente, c'est une erreur qui est toujours vers le haut. Il y a un survival bias pour les stratégies : Tous les backtests surévaluent les performances réelles. Toute l'industrie connait  ce problème. Alors quand un professionnel exhibe ses résultats de backtests, il faut absolument dénoncer cette pratique qui exploite l'inexpérience des investisseurs et qui est pour moi de la pure malhonnêteté. On peut faire dire ce qu'on veut à un backtest.

Et c'est encore pire pour le machine learning…

Dans la communauté du machine learning, l'overfitting fait partie des premières choses qui sont apprises. Il n'est littéralement pas possible de construire un outil de machine learning si une approche corrective n'est pas prise. Pour se protéger contre ce biais, on divise toujours les données entre les données de training, les données de tests et les données de validation. Sur les données temporelles, on a recours à une cross validation imbriquée pour éviter le lookahead bias. Toutes ces précautions sont essentielles parce que par définition, tout algorithme de ML va s'adapter aussi près que possible à l'ensemble de données passées en entrée. Si on utilise les données utilisée pour apprendre à l'algorithme pour valider la performance de l'algorithme, on va obtenir un résultat parfait (modulo le compromis biais/variance). C'est pourquoi dans le cadre du trading systématique les données d'apprentissage de l'algorithme sont systématiquement écartées de toute mesure de performance. Tout le monde du ML le sait.
Quelle n'a donc pas été ma surprise, quand récemment, je suis allé consulter le site d'une Fintech respectable de la place parisienne, et que j'ai vu ça :
Les bras m'en tombent. Ils utilisent la version 2017 de leur algorithme pour préjuger de leur performance en 1999 ! mais à cette époque-là, ils vous aurait été virtuellement impossible de monter un algorithme de ML dans les conditions actuelles ! Bien sur aucune mention de la limite de la période de training, les données d'apprentissage doivent polluer tous les résultats. Par contre, grand absent de cette simulation, on ne trouve aucune mention de la performance en conditions réelles Out-Of-Sample….

Je fais ce que je dis, et je dis ce que je fais.

Si vous êtes déjà passé par ce blog, et sans vouloir faire de l'autopromotion, vous savez que je propose régulièrement une allocation possible pour un portefeuille ETF au sein d'une assurance-vie ou d'un ETF. Vous avez alors noté que je ne propose pas de backtest historique dans mon reporting et uniquement des indicateurs de performances uniquement OOS et rien sur la performance par le passé. Si vous lisez ce paragraphe, les raisons sont claires….