Look-ahead Bias est une erreur temporelle d’évaluation qui consiste à utiliser des informations devenues disponibles plus tard pour une décision, un entraînement ou un choix de règle antérieurs. La mesure ultérieure du résultat d’une prédiction déjà formulée ne constitue pas en elle-même cette erreur.
QuantConnect décrit Look-ahead Bias comme une décision utilisant une information qui ne serait disponible que plus tard. Notre question de contrôle est donc : que pouvait réellement savoir la procédure au moment précis de cette décision ? Il ne suffit pas qu’une donnée appartienne au même jour civil. L’événement, la publication, la réception et l’envoi de l’ordre peuvent survenir à des moments différents. Il faut établir la disponibilité de chaque entrée et l’ordre des opérations ; un tableau correctement trié ne suffit pas à le prouver. [QuantConnect — Custom Securities: Avoid Look-Ahead Bias]
Le modèle temporel de LEAN transmet un point de données achevé selon son EndTime. Notre conséquence : le cours de clôture définitif, le plus haut, le plus bas et le volume de toute la période ne doivent pas piloter une décision antérieure à l’intérieur de celle-ci. Avec plusieurs unités de temps, chaque série doit avoir sa propre règle de disponibilité. Décaler une ligne peut corriger une erreur précise, mais ne remplace pas la vérification des fuseaux horaires, de la fin de période et du retard de la source. Utiliser une valeur antérieure déjà connue diffère de l’utilisation de la valeur finale, connue plus tard, de la bougie en cours. [QuantConnect — Time Modeling: Timeslices]
La documentation FRED distingue les informations sur le passé disponibles aujourd’hui de celles connues pendant une période historique ; ALFRED permet de choisir la période de disponibilité correspondante. Notre exigence méthodologique : pour une donnée corrigée ultérieurement, il faut conserver la version d’alors et sa publication. La date de la période économique ne remplace pas la date de publication. Même une version historique ne prouve pas à elle seule la disponibilité intrajournalière précise ; celle-ci doit être vérifiée séparément. Une correction ultérieure ne peut pas être réinjectée discrètement dans une décision antérieure. [Federal Reserve Bank of St. Louis — FRED API Real-Time Periods]
scikit-learn demande d’apprendre les transformations uniquement sur les données d’entraînement, puis d’appliquer la même transformation apprise au test. Notre contrôle temporel couvre la normalisation, l’imputation des valeurs manquantes, la sélection de variables et les cibles d’entraînement. Le résultat d’une période future peut servir à évaluer plus tard une prédiction ; il ne doit pas servir à la créer auparavant ni à choisir la règle. Lors d’un réentraînement continu, seules les cibles déjà connues à l’instant considéré peuvent entrer dans l’entraînement. [scikit-learn — Common Pitfalls: Data Leakage]
TradingView explique que son émulateur de courtier utilise des hypothèses sur les mouvements à l’intérieur d’une bougie lorsqu’il travaille sur des données OHLC historiques. Notre distinction : le plus haut et le plus bas enregistrés ne déterminent pas à eux seuls l’ordre réel de tous les prix et ordres. Le test doit distinguer la formation du signal, l’envoi et l’exécution possible. Choisir une entrée ou une sortie selon un extrême connu plus tard est un autre problème qu’un modèle de coûts simplement optimiste. Des données plus détaillées peuvent affiner le contrôle, mais ne garantissent pas l’exécution réelle. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
Freqtrade compare les résultats de tests répétés et les changements d’indicateurs ou de signaux ; il attire aussi l’attention sur l’accès aux lignes futures et les agrégations sur tout le tableau. Notre audit examine donc non seulement la syntaxe du décalage, mais aussi l’origine de chaque calcul. La documentation limite explicitement le contrôle aux signaux déclenchés pendant le test. Une sortie sans alerte ne valide pas les branches non parcourues. Le résultat doit être lu avec la couverture et les paramètres de simulation ; certaines configurations d’ordres à cours limité peuvent provoquer de faux positifs. [Freqtrade — Lookahead Analysis]
TradingView distingue Look-ahead Bias de Overfitting, c’est-à-dire l’ajustement de règles à des données de développement particulières. Notre conclusion : même un test temporellement admissible peut résulter d’une vaste sélection du gagnant. Inversement, une règle simple peut contenir une fuite d’informations futures. Après correction, il faut recalculer les résultats et consigner le changement ; on ne peut pas conserver le rapport bénéficiaire initial. L’écart entre résultat historique et résultat ultérieur ne dit pas à lui seul si la cause était une erreur temporelle, un changement de marché ou une autre hypothèse. [TradingView — Strategies: Broker Emulator and Lookahead Bias]
La NFA souligne la différence entre résultats hypothétiques et négociation réelle. Notre trace reproductible contient donc la version des données et des règles, l’instant de disponibilité des entrées, l’état du compte, la séquence des ordres et les coûts décrits. L’audit doit pouvoir rejouer la décision avec les seules informations alors disponibles. Paper Trading peut fournir d’autres observations au fil du temps, mais ne garantit à lui seul ni la bonne préparation des données ni la liquidité réelle. Supprimer une erreur démontrée n’est pas promettre un rendement futur. [NFA — Use of Promotional Material Containing Hypothetical Performance Results]
Un gain fondé sur la connaissance du futur n’est pas une stratégie disponible
Pour une vision complète, lisez aussi Backtesting, Overfitting, Walk-forward Analysis, Survivorship Bias, Paper Trading. Cette entrée est également citée par Walk-forward Analysis, Overfitting, Survivorship Bias, On-chain Analysis.
01Suffit-il de décaler tous les indicateurs d’une ligne ?+
Non. Un décalage peut supprimer une utilisation précise d’une valeur future, mais ne règle pas automatiquement les fuseaux horaires, les publications tardives, les révisions ou la préparation des données. La disponibilité démontrée de chaque entrée à l’instant considéré est déterminante.
02Utiliser un résultat futur dans l’évaluation est-il toujours une erreur ?+
Non. Un résultat constaté plus tard est nécessaire pour évaluer une prédiction créée auparavant. L’erreur apparaît si cette information future entre dans la décision antérieure, l’entraînement ou le choix de la règle qui a produit cette prédiction.