Choisir un modèle de prévision sans regarder les données de test : le backtest découpé dans la période d’entraînement

Par Elisha Bajemon, Ingénieur IA chez TW3 Partners. Dernière mise à jour : 24 octobre 2026.

En bref

Un backtest de prévision rejoue des périodes passées ; découpé dans l’historique d’entraînement, il guide le choix du modèle en laissant les données de test intactes. Dans leur publication TW3Cast du 16 septembre 2026 sur arXiv, Nathan Thierry et André-Louis Rochet décrivent environ 100 à 600 fenêtres de backtest par configuration. Les règles qui départagent les candidats sont elles-mêmes évaluées par un méta-backtest temporel. Les constantes sont ensuite gelées, sans réglage sur les résultats de l’évaluation officielle. La sélection repose sur l’hypothèse que les conditions récentes se prolongent dans la période à prévoir. Les auteurs reconnaissent qu’une rupture brutale à la frontière entre entraînement et test mettrait cette méthode en défaut.

1. Qu’est-ce qu’un backtest découpé dans la période d’entraînement ?

Un backtest désigne ici une simulation de prévision réalisée sur des fenêtres historiques réservées à la décision. Le protocole TW3Cast, publié en septembre 2026, prélève ces fenêtres à la fin de la période d’entraînement. Chacune associe un contexte déjà observé à un horizon dont les valeurs servent à noter la prévision rejouée.

Le découpage intervient à plusieurs positions dans chaque série et identifie les régimes horaires. Une configuration désigne la combinaison d’un jeu de données, d’une fréquence d’échantillonnage et d’une classe d’horizon. Le choix du modèle se fait donc pour un besoin de prévision défini, à partir de son propre historique.

Les données d’entraînement restantes servent à entraîner les modèles spécialisés. La table de routage, qui associe chaque configuration au modèle ou au mélange retenu, est figée avant la lecture des fenêtres de test. À l’usage, les contrôles par fenêtre examinent le contexte déjà disponible avec des seuils fixes. Cette chronologie sépare les décisions de construction du système et la mesure finale de son résultat.

2. Pourquoi ne jamais choisir un modèle sur les données de test ?

Choisir sur le test introduit dans la décision une information qui devait servir à l’évaluation indépendante. La documentation scikit-learn sur les fuites de données, non datée, explique que l’utilisation d’informations indisponibles au moment de prévoir produit des estimations de performance trop optimistes. Elle demande explicitement de réserver les choix concernant le modèle aux données d’entraînement.

Le problème posé par TW3Cast en septembre 2026 consiste précisément à choisir le système de prévision avec le seul jeu d’entraînement. Les auteurs calculent aussi un « oracle » : pour chaque configuration, il retient le membre du groupe de modèles de base ayant le plus faible score d’erreur MASE sur le test. Ce calcul sert de référence de comparaison ; le reproduire pour choisir exige de connaître les réponses attendues.

Depuis la mise à jour du 5 août 2025 de Salesforce, GIFT-Eval affiche une colonne « TestData Leakage ». Sa définition porte sur la présence de données de test dans les données d’entraînement. Pour examiner un protocole de sélection, notre recommandation est de vérifier également quelles données ont servi à choisir les modèles et leurs seuils.

3. Comment les candidats sont-ils notés sur ce backtest ?

Les candidats sont notés selon les critères du benchmark. Dans TW3Cast, septembre 2026, le score d’erreur MASE mesure la précision de la prévision ponctuelle ; son calcul utilise le contexte réel, avant tout remplissage. La perte pinball moyenne sur les neuf déciles fournit l’approximation du CRPS retenue par le protocole pour évaluer la distribution prévue.

Sur les configurations sans spécialiste désigné, le tournoi compare les candidats sur ces critères complémentaires pour retenir un modèle par défaut. Un modèle peut obtenir une bonne précision ponctuelle tout en produisant des quantiles dégénérés, tous identiques. Le critère double vise à écarter ce type de candidat. Les auteurs précisent toutefois qu’il ne sélectionne pas directement le système pour optimiser sa calibration.

Les candidats entraînés localement bénéficient d’un avantage sur les séries qu’ils ont déjà vues. Dans ce tournoi, une marge anti-mémorisation leur impose donc une amélioration de plus de 12 % sur le score de sélection face au meilleur candidat générique, sans dégradation du CRPS. Sous 3 % d’écart, le CRPS départage les candidats. Si le mélange des deux plus grandes architectures du groupe reste à moins de 5 % du gagnant, il est retenu. Les auteurs motivent ce repli par l’incertitude attachée aux petites différences de score.

4. Qu’est-ce qu’un méta-backtest temporel, et à quoi sert-il ?

Le méta-backtest temporel évalue la règle de choix elle-même. Dans le protocole décrit par Thierry et Rochet en septembre 2026, la règle choisit sur les fenêtres anciennes du backtest, puis le choix obtenu est noté sur les fenêtres récentes. L’opération est répétée sur des centaines de tirages.

Le découpage conserve ainsi l’ordre du temps à l’intérieur de la période déjà réservée aux décisions. Les auteurs rattachent cette démarche aux travaux sur la validation temporelle : elle applique au sélecteur le principe utilisé pour évaluer un modèle.

Toutes les itérations sur les marges, les départages et les seuils des contrôles ont été conduites dans ce cadre. Les données de l’évaluation officielle restent disponibles pour la mesure finale. Pour le cabinet, la question à poser lors d’une revue est donc celle de la chronologie : sur quelles observations la règle a-t-elle été choisie, et sur quelles observations ultérieures a-t-elle été évaluée ? Nous recommandons de consigner cette distinction dans le dossier de validation.

5. Quelles constantes ont été gelées, et par quoi ?

L’annexe du papier TW3Cast de septembre 2026 recense douze réglages fixes, tous choisis dans les protocoles côté entraînement puis gelés. Le tableau suivant reprend leurs valeurs et l’origine indiquée par les auteurs. Il décrit ce système ; notre recommandation est de réévaluer ces choix sur l’historique disponible avant de les adopter pour une autre application.

Les contrôles par fenêtre ont des fonctions distinctes. Le premier peut réorienter une prévision lorsque plusieurs conditions concordent. Le contrôle anti-catastrophe intervient sur les configurations confiées à un spécialiste, en cas d’échec manifeste. La vérification d’alignement sert à repérer des prévisions importées qui auraient été associées aux mauvaises fenêtres.

L’essai court est prolongé seulement s’il gagne déjà. Le nombre de fenêtres relève, lui, du budget. Retracer l’origine de chaque réglage évite de présenter toute valeur du tableau comme le résultat d’une même optimisation statistique.

6. Quelles limites les auteurs reconnaissent-ils ?

La méthode dépend de la continuité du régime et reste exposée au surapprentissage de la validation. Dans les limites de TW3Cast, septembre 2026, les auteurs expliquent que prélever la fin de l’entraînement suppose que les conditions récentes se prolongent. Ils ne présentent pas cette hypothèse comme démontrée. Une rupture brutale à la frontière entre entraînement et test mettrait en défaut le backtest comme le méta-backtest.

La seconde limite concerne la souplesse des règles de sélection. Un système comportant des marges et des seuils peut s’adapter excessivement à ses propres données de validation. Le protocole répond à ce risque par le choix temporel des constantes puis leur gel. Aucune n’a été ajustée sur les résultats officiels.

Cette protection reste procédurale. Les constantes dépendent encore du mélange de fréquences et de domaines du benchmark. Dans notre lecture, une direction doit donc demander que les conditions d’application soient explicites : historique utilisé, périodes retenues et critères de sélection. La qualité du protocole s’examine avec le périmètre sur lequel il a été évalué.

7. Comment appliquer cette discipline à ses propres séries ?

Notre recommandation est d’organiser la sélection autour d’une période de test réservée dès le départ. Cette lecture de cabinet s’appuie sur le protocole TW3Cast de septembre 2026. Elle conduit à définir un backtest dans l’historique d’entraînement, à éprouver les règles de choix sur un découpage temporel interne, puis à figer les seuils avant l’évaluation finale.

Nous recommandons de conserver, avec chaque décision, les périodes utilisées et le critère ayant départagé les candidats. Le dossier de validation devrait aussi documenter la préparation des séries, les transformations retenues et les données utilisées pour les régler.

Sur une nouvelle source, le papier décrit un tournoi qui construit son backtest sur l’historique disponible et choisit un modèle par défaut sans entraînement supplémentaire. Une spécialisation peut ensuite être examinée selon la règle d’admission.

Un parallèle de méthode figure dans la réalisation publiée par TW3 Partners sur la prévision photovoltaïque, sans date de publication affichée. La fiche décrit un protocole figé avant évaluation, une sélection sur validation et un jeu de test gelé. Cette réalisation utilise LightGBM et Chronos-2 : il s’agit d’un autre système, dont nous rapprochons ici la discipline d’évaluation.

FAQ

Qu’est-ce qu’une fuite des données de test ?
Selon la documentation scikit-learn, elle survient lorsque la construction du modèle utilise une information indisponible au moment de prévoir. Choisir un modèle à partir du test entre dans ce problème. La colonne TestData Leakage de GIFT-Eval, définie le 5 août 2025, suit plus précisément la présence de données de test à l’entraînement.

Combien de fenêtres de backtest faut-il ?
TW3Cast, septembre 2026, utilise environ 100 à 600 fenêtres par configuration, quantité fixée par le budget. Cette plage décrit le dispositif publié et ne constitue pas une règle générale de dimensionnement.

Pourquoi privilégier les fenêtres récentes ?
Les auteurs de TW3Cast estiment qu’elles ressemblent davantage aux conditions de la prévision à venir. Sur les longues séries, d’anciens régimes peuvent tromper la sélection. Cette préférence repose sur l’hypothèse de continuité discutée dans le papier de septembre 2026.

Le méta-backtest supprime-t-il le risque de surapprentissage ?
La protection décrite dans TW3Cast, septembre 2026, est procédurale : elle encadre le choix des constantes et leur gel. Celles-ci restent dépendantes des fréquences et domaines du benchmark.

Qu’est-ce que l’oracle par configuration ?
C’est le choix du membre du groupe de modèles de base ayant le plus faible MASE sur le test. Dans les résultats TW3Cast de septembre 2026, le système obtient un meilleur MASE que cet oracle sur 37 configurations sur 97. L’oracle compare les membres de ce groupe ; TW3Cast comprend aussi des spécialistes entraînés et des mélanges.

Qu’est-ce qu’une porte par fenêtre ?
Dans TW3Cast, septembre 2026, c’est un contrôle qui réexamine le choix par défaut sur des segments du contexte disponible. Le remplacement exige que toutes les conditions de comparaison concordent, avec un contrôle des transitions de régime. Les auteurs le conçoivent pour basculer rarement.

Pour aller plus loin

• TW3Cast : un système de prévision sans agent ni modèle de langage, 3e sur 130 à GIFT-Eval au 14 septembre 2026.
• Maintenir un système de prévision par petites mises à jour vérifiées : une table de routage auditable ligne par ligne.
• Lire un classement public de modèles : date du relevé, catégorie déclarée et fuite des données de test.

Sources

• Nathan Thierry et André-Louis Rochet, TW3Cast: A Frozen Router of Lightly Fine-Tuned Foundation Models for Time-Series Forecasting on GIFT-Eval, Selected Entirely on the Training Split, arXiv, version initiale du 16 septembre 2026, notice et texte intégral consultés le 9 octobre 2026.
• Salesforce, GIFT-Eval, documentation du classement dans src/about.py, entrée du 5 août 2025, consultée le 9 octobre 2026.
• scikit-learn, Common pitfalls and recommended practices, rubrique Data leakage, sans date de publication affichée, consultée le 9 octobre 2026.
• TW3 Partners, Prévision de production photovoltaïque à J+1, sans date de publication affichée, consultée le 9 octobre 2026.