5 erreurs d'algo trading qui m'ont coûté du temps et de l'argent (ne les reproduis pas)

8 ans de finance de marché et de trading systématique. Ces 5 erreurs, je les ai toutes faites. Certaines m'ont coûté de l'argent. La plupart m'ont brûlé des semaines de travail inutile. Cet article les décortique une par une — ce que c'est, pourquoi ça arrive, et exactement comment les corriger.

Si votre backtest est faux, tout ce qui suit est faux. Il ne sert à rien d'optimiser l'exécution, l'infrastructure ou la gestion du risque si la recherche repose sur une simulation incorrecte. Il existe trois biais classiques qui corrompent les backtests — et tous les trois sont corrigeables.

Le premier est le look-ahead bias. C'est le fait d'utiliser dans votre signal des données qui n'auraient pas été disponibles au moment du trade. L'exemple le plus courant : vous générez un signal d'achat sur le close d'une barre journalière, puis vous exécutez sur l'open de cette même barre — qui a eu lieu des heures plus tôt. En pratique, si votre signal se déclenche au close d'une barre, l'exécution ne peut avoir lieu qu'à l'open de la barre suivante. Si vous ne faites pas ça dans votre backtest, chaque signal vous offre 1% d'avance gratuit que vous ne reproduirez jamais en live. Multipliez ça sur des centaines de signaux et votre backtest semble excellent pendant que votre P&L réel saigne dès le premier jour.

Le deuxième est le biais du survivant — celui que tout le monde connaît et que presque personne ne corrige, par flemme ou par manque d'accès à des données de qualité. Si vous backtestez une stratégie long equity sur la composition actuelle du S&P 500, toutes les entreprises de votre univers sont celles qui ont survécu et prospéré sur les 20 dernières années. Les entreprises qui étaient dans l'indice et ont fait faillite, ont été retirées de la cote ou exclues de l'indice — elles ne sont pas dans votre dataset. Votre backtest sélectionne littéralement les gagnants en rétrospective. Pour corriger ça correctement, il faut des données de composition point-in-time : la liste exacte des constituants du S&P 500 pour chaque mois de votre période de backtest, y compris les entreprises qui n'existent plus.

Le troisième est d'ignorer les coûts de transaction et les spreads. Chaque trade exécuté sur les marchés réels a un coût : commissions broker, spread bid-ask, slippage à l'entrée et à la sortie. Si votre backtest ignore ces éléments, vous surestimez systématiquement votre edge. La correction est simple : modélisez le worst case. Appliquez les commissions maximales et un spread conservateur (par exemple 0,20% par transaction) à chaque trade. Un backtest qui semble moyen avec des coûts réalistes vaut infiniment plus qu'un backtest spectaculaire qui s'effondre dès qu'il touche les marchés réels.

Celle-ci n'est pas vraiment une erreur technique — c'est une erreur comportementale. Le backtesting perpétuel, c'est le schéma qui consiste à enchaîner les backtests, à affiner indéfiniment, et à ne jamais passer en live. Je le vois constamment chez les gens que j'accompagne. Le backtest est solide. Les paramètres de risque sont raisonnables. Et pourtant l'algo n'est jamais déployé.

Il y a trois raisons à ça. La première, c'est le manque de confiance dans le système — soit parce que la personne n'a pas pleinement compris le code (surtout quand c'est l'IA qui l'a généré), soit parce que le saut entre la simulation et le capital réel paraît trop grand. La deuxième, c'est la peur du premier drawdown. Toute stratégie en live traversera une série de pertes à un moment donné. Si vous n'y êtes pas mentalement préparé — si vous n'avez pas déjà accepté ça comme un résultat statistique normal intégré à votre backtest — vous couperez la stratégie exactement au mauvais moment. La troisième, c'est simplement de ne pas faire le travail de connecter le backtest à un broker live : lire la documentation de l'API, comprendre les types d'ordres, tester l'exécution proprement.

La correction, c'est un processus forcé. Une fois votre backtest validé, passez immédiatement en paper trading sur Interactive Brokers. N'attendez pas que tout semble parfait. Faites tourner l'algo en live sur un compte paper, observez chaque ordre, vérifiez chaque exécution. Une fois qu'il se comporte exactement comme votre backtest le prédisait, vous avez la confiance pour basculer sur du capital réel — parce que vous l'avez déjà vu fonctionner dans un environnement de marché réel.

C'est là que la plupart des algos échouent silencieusement. Le backtest est correct. La stratégie est solide. Mais l'implémentation live ne correspond pas à la simulation — et la divergence se cumule dans le temps.

Les écarts les plus fréquents : les décalages de timezone entre vos données de backtest (souvent UTC) et votre environnement d'exécution live (souvent l'heure locale de la bourse ou Eastern New York) — particulièrement dangereux en crypto et sur les stratégies cross-asset. Les erreurs de lot : envoyer une quantité en unités quand le broker attend des contrats, ou inversement, ce qui résulte en des positions 100 fois plus grandes que prévu. Les différences de calcul de signal : votre signal live utilise une source de données légèrement différente, un alignement de barres différent, ou une normalisation différente de votre backtest. Et enfin, les ordres fantômes : votre algorithme envoie un ordre, la position s'ouvre chez le broker, mais l'algo ne reçoit pas la confirmation — à la boucle suivante, il recalcule le signal, ne trouve aucune position en mémoire, et envoie un nouvel ordre. Ça se répète jusqu'à ce que vous ayez une taille de position catastrophique que vous n'avez jamais voulue.

La mitigation consiste à traiter le paper trading avec autant de sérieux que le backtesting. Chaque type d'ordre, chaque taille de lot, chaque chemin d'exécution doit être vérifié dans un environnement de marché réel avant que du capital réel soit engagé. Prévoyez une journée entière à surveiller votre algo tourner et à confirmer que chaque action correspond à votre intention.

Faire tourner un algorithme de trading sur votre machine locale, c'est une source de risque permanente. Coupure de courant, déconnexion internet, mise à jour système, ordinateur qui se met en veille — n'importe lequel de ces événements peut tuer votre algo en pleine session. Si vous tradez un marché 24h/24 comme la crypto, vous vous réveillerez tôt ou tard face à un chaos de positions ouvertes, de signaux manqués, et aucune trace de ce qui s'est passé.

La solution professionnelle, c'est une machine virtuelle cloud — un serveur qui tourne 24h/24 7j/7 sur AWS, GCP ou Azure. Coût : 10 à 20 dollars par mois selon l'usage, souvent gratuit les premiers mois sur un forfait de test. Votre algo tourne en continu indépendamment de ce qui arrive à votre matériel local.

Au-delà du serveur, une architecture sérieuse nécessite une base de données. Chaque trade, chaque signal, chaque position — loggés de façon persistante. Ça vous donne deux choses : la capacité d'analyser les performances de la stratégie en temps réel, et la fondation pour la reprise sur panne. Votre algo doit être stateless : à chaque cycle, il lit son état courant depuis la base de données et le broker, calcule la position qu'il devrait avoir, et envoie uniquement le delta. Il ne doit pas dépendre de variables en mémoire qui disparaissent quand le process plante.

C'est l'erreur qui m'a le plus coûté. Un algo sans système de reprise sur panne est dangereux en proportion de la fréquence à laquelle il plante — et tout algo plante tôt ou tard. Quand il redémarre sans connaître son état précédent, il recalcule le signal depuis zéro, ne trouve aucune position en mémoire, et en ouvre une nouvelle. S'il plante cinq fois dans la nuit, vous avez cinq fois la position prévue. Vous vous réveillez en pensant avoir gagné de l'argent et vous découvrez un book démesuré qui n'a rien à voir avec votre stratégie.

La solution, c'est une architecture stateless avec un état persistant. Au début de chaque cycle, votre algo fait trois choses avant de calculer le moindre signal : il lit depuis la base de données, lit depuis un fichier d'état local si disponible, et se réconcilie avec le broker — qui est toujours la source de vérité ultime. À partir de cet état réconcilié, il calcule la position qu'il devrait avoir et envoie uniquement la différence. Peu importe combien de fois il a planté, peu importe à quel moment du cycle, le redémarrage suivant est toujours propre.

Le dernier élément que tout algo live doit avoir, c'est un coupe-circuit. Un paramètre — lu à chaque cycle depuis un fichier de config ou une table de base de données — qui peut être passé à OFF. Quand il se déclenche, l'algo ferme immédiatement toutes les positions, annule tous les ordres, et envoie un rapport du capital et de l'exposition courants. Le déclencheur peut être n'importe quoi : un pic de volatilité, une explosion des spreads, un seuil de drawdown, ou simplement un kill switch manuel. Sur les desks institutionnels, c'est géré par un desk de risque dédié. Quand vous tradez seul, vous êtes le desk de risque. Construisez le coupe-circuit avant de passer en live — pas après.