Variables exogènes : quelles informations sont réellement disponibles à la date de prévision ?

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

En bref

Pour prévoir une activité, il faut utiliser les informations accessibles au moment de la décision, avec leur degré de certitude. Une variable exogène désigne ici une information fournie au modèle en complément de la grandeur à prévoir. Les travaux de Lim et ses coauteurs, version du 27 septembre 2020 distinguent 3 familles d’entrées : caractéristiques stables, observations passées et informations connues à l’avance. Un calendrier peut renseigner des dates futures ; une mesure obtenue ultérieurement relève d’un autre usage. Dans leur ouvrage de 2021, Hyndman et Athanasopoulos distinguent ainsi prévision faite avec l’information disponible, analyse rétrospective et scénario. Avant de comparer des modèles, la direction doit donc faire préciser quelles données seront effectivement fournies à chaque décision.

1. Quelles catégories d’entrées faut-il distinguer ?

Le classement des variables dépend de leur disponibilité dans le temps. Dans Temporal Fusion Transformers, prépublication déposée sur arXiv le 19 décembre 2019, Lim et ses coauteurs, version du 27 septembre 2020 séparent les caractéristiques statiques des entrées qui évoluent dans le temps. Parmi ces dernières, certaines sont seulement observées au fil des périodes, tandis que d’autres peuvent être déterminées à l’avance.

Une covariable est une information associée à la série à prévoir. « Statique » signifie qu’elle reste constante dans la représentation retenue ; « connue dans le futur » signifie que sa valeur pour les dates visées est disponible dès la production de la prévision. L’horizon désigne cette période future. Le tableau reprend la distinction des auteurs.

La distinction entre historique et valeurs futures connues se retrouve dans Chronos-2, d’Ansari et ses coauteurs, prépublication déposée sur arXiv le 17 octobre 2025. Le modèle assemble les valeurs historiques de la cible et des covariables. Lors de la construction de ses entrées futures, les valeurs de la cible et des covariables limitées au passé sont déclarées manquantes ; les valeurs connues à l’avance occupent les emplacements correspondants.

Pour préparer les données, TW3 recommande de classer chaque colonne avant le premier essai. Consignez notamment la période pendant laquelle une caractéristique réputée stable est valable. Ce classement forme le point de départ du contrat de disponibilité proposé ici : une description des informations autorisées à entrer dans chaque prévision.

2. Quand le calendrier est-il réellement connu ?

Un calendrier est utilisable dans l’horizon lorsque ses valeurs peuvent être établies à la date de décision. Dans Forecasting: Principles and Practice, ouvrage de 2021, Hyndman et Athanasopoulos expliquent comment représenter les jours de semaine et les jours particuliers par des variables indicatrices. Une indicatrice signale la présence ou l’absence d’une catégorie, par exemple le caractère férié d’un jour.

Les auteurs distinguent aussi plusieurs représentations d’une intervention : une impulsion pour un effet limité à une période, ou une marche pour un changement de niveau permanent. Ces constructions décrivent une forme d’effet que le modèle cherchera à estimer. Dans la méthode proposée ici, leur pertinence métier reste une hypothèse à tester : connaître la date d’un événement et établir son effet sur l’activité sont des questions distinctes.

Pour un calendrier opérationnel, archivez la version approuvée avant la décision. Associez-lui son périmètre d’application et la date à partir de laquelle l’équipe pouvait l’utiliser. Si un événement planifié est déplacé ensuite, rejouez la prévision historique avec le calendrier qui était alors disponible. Conservez la révision pour les décisions suivantes.

Cette pratique permet de poser une question précise au responsable métier : le calendrier renseigne-t-il une date déterminée, une décision déjà approuvée ou une intention susceptible de changer ? Dans ce dernier cas, qualifiez explicitement l’entrée d’hypothèse. Le sujet des cycles calendaires fait l’objet de la fiche « Saisonnalités multiples : représenter les cycles horaires, hebdomadaires et calendaires ».

3. Comment traiter une variable future incertaine ?

Une variable future incertaine peut être fournie sous forme de prévision ou de scénario, en conservant ce statut. Hyndman et Athanasopoulos, dans leur ouvrage de 2021, nomment ex ante une prévision construite uniquement avec l’information disponible à l’avance. Si elle exige des valeurs futures de prédicteurs inconnus, il faut prévoir ces prédicteurs ou disposer de prévisions provenant d’une autre source.

Une analyse ex post utilise au contraire des informations obtenues ultérieurement sur les prédicteurs. Les auteurs lui donnent un intérêt diagnostique : comparer les résultats obtenus avec les prédicteurs prévus et avec leurs observations permet d’examiner l’origine des erreurs. Il faut donc conserver des résultats séparés pour ces usages.

Le scénario constitue encore un autre objet : il fixe des valeurs possibles pour les variables d’entrée. Les auteurs précisent que les intervalles de prévision calculés sous scénario supposent ces valeurs connues et n’intègrent pas leur incertitude. Une plage de résultats conditionnelle à un scénario ne décrit donc pas, à elle seule, tous les futurs possibles.

Pour appliquer cette distinction, conservez la date de production de chaque prévision d’entrée, sa période de validité et son producteur. Nommez les scénarios et faites approuver leurs hypothèses. Si les anciennes prévisions des variables d’entrée sont indisponibles, documentez le périmètre réellement évaluable ; une observation récupérée ensuite ne remplace pas la prévision manquante. Les auteurs proposent également l’emploi de valeurs retardées des prédicteurs : cette possibilité mérite un essai lorsque ces valeurs sont accessibles au moment voulu.

4. Où apparaît une fuite de données ?

Il y a fuite lorsque le test fournit au modèle une information qui aurait été inaccessible au moment de prévoir. Shchur et ses coauteurs, dans fev-bench, prépublication déposée sur arXiv le 30 septembre 2025, définissent une tâche par son jeu de données, son horizon, ses dates de coupure et le rôle de ses colonnes. La disponibilité des covariables fait ainsi partie du problème évalué.

TW3Cast applique cette séparation temporelle aux décisions de sélection des modèles. Dans TW3Cast, de Thierry et Rochet, prépublication déposée sur arXiv le 16 septembre 2026, les décisions de sélection reposent sur des fenêtres extraites de la période d’entraînement. Le dispositif de sélection des modèles est figé avant la lecture des fenêtres de test. Le contrôle des versions de covariables proposé ci-dessous prolonge cette exigence de séparation ; il constitue une méthode à mettre en place dans l’organisation.

Pour chaque valeur, distinguez la date de l’événement mesuré de la date à laquelle la donnée est devenue accessible au système de prévision. Ajoutez la période future visée lorsqu’il s’agit d’une prévision d’entrée. Au moment de rejouer une décision passée, sélectionnez la version disponible à cette date et conservez la preuve de cette sélection.

Appliquez le même contrôle aux corrections d’historique : une valeur révisée doit porter sa propre date de disponibilité. Si la provenance ne permet pas de reconstituer l’entrée, écartez la fenêtre concernée du test opérationnel ou qualifiez séparément l’analyse. Le choix du traitement et son effet sur le périmètre évalué doivent apparaître dans le compte rendu.

5. Comment représenter les entrées dans un outil d’évaluation ?

Séparez explicitement l’historique des données fournies pour l’horizon. La documentation AutoGluon de fev, dans son état du 9 octobre 2026 montre que window.get_input_data() renvoie les objets past_data et future_data. Le premier contient les identifiants, les dates passées, la cible et les covariables. Le second contient les identifiants, les dates futures et les covariables connues à la date de prévision.

Notre proposition consiste à compléter cette interface par un registre de disponibilité, tenu en amont de l’évaluation. Pour chaque variable, renseignez son nom, son rôle, son propriétaire et sa source. Pour chaque version, ajoutez la date de disponibilité, la période couverte, le statut observé, prévu ou scénarisé, ainsi que la référence de l’archive permettant de la retrouver.

Traduisez ensuite le contrat en contrôles automatiques :

• Vérifier que la version utilisée était accessible à la date de décision.
• Vérifier que les dates et les identifiants correspondent à l’horizon demandé.
• Autoriser dans future_data uniquement les colonnes déclarées pour cet usage.
• Vérifier que la cible future reste réservée au calcul de l’erreur.
• Conserver le statut et la provenance des valeurs prévues ou scénarisées.

Prévoyez une règle explicite lorsque les entrées attendues manquent : reporter le calcul, utiliser une solution de repli préalablement évaluée ou réduire le périmètre. Le journal d’exécution doit indiquer quelle règle a été appliquée. Il devient alors possible de relire une prévision en retrouvant les données effectivement transmises au modèle, indépendamment de la version courante des tables métier.

6. Que faire valider avec la direction métier ?

La validation doit porter sur les conditions d’usage de chaque variable. En nous appuyant sur la distinction entre prévisions et scénarios de Hyndman et Athanasopoulos, 2021, nous recommandons une revue du contrat de disponibilité avec le responsable de la décision et les propriétaires des données.

Pour chaque entrée, faites confirmer qui produit la valeur, quand elle devient accessible et jusqu’à quelle échéance elle est utilisable. Demandez aussi qui autorise une révision et comment retrouver la version antérieure. Une variable annoncée comme disponible doit correspondre à une livraison identifiable dans le système qui exécutera la prévision.

La revue doit ensuite fixer le sens des résultats attendus. Une prévision alimentée par les estimations disponibles sert à évaluer le fonctionnement prévu. Un scénario sert à examiner une hypothèse approuvée. Une analyse fondée sur les valeurs observées ultérieurement répond à une question diagnostique. Faites inscrire cet usage dans le compte rendu remis au décideur.

Avant d’élargir le jeu de variables, comparez les résultats sur un même périmètre avec et sans les entrées candidates. Conservez ensemble le résultat, le contrat appliqué et les exceptions rencontrées. Il s’agit d’un protocole proposé pour décider de l’utilité d’une variable, sans présumer le gain qui sera mesuré. La décision d’intégration peut alors tenir compte de sa contribution observée et des conditions nécessaires à sa fourniture régulière.

FAQ

Quelles catégories d’entrées faut-il distinguer ?
Les caractéristiques statiques, les observations passées et les valeurs connues dans l’horizon correspondent à la séparation de Lim et ses coauteurs, version de 2020. Le contrat proposé ajoute, pour les entrées incertaines, un statut explicite de prévision ou de scénario.

Quand le calendrier est-il réellement connu ?
Les variables déterminées par le calendrier peuvent être établies à l’avance, comme l’expliquent Hyndman et Athanasopoulos, 2021. Pour les événements planifiés par l’organisation, conservez la version approuvée disponible lors de la décision. Leur effet sur l’activité reste une hypothèse à évaluer.

Comment traiter une variable future incertaine ?
Utilisez la prévision disponible à la date de décision ou un scénario identifié. Selon Hyndman et Athanasopoulos, 2021, les intervalles calculés sous scénario n’incluent pas l’incertitude des valeurs imposées aux prédicteurs. Cette condition doit accompagner la lecture du résultat.

Où apparaît une fuite de données ?
Elle apparaît notamment lorsqu’une information obtenue après la décision entre dans le test censé la reproduire. Le contrôle proposé compare donc la disponibilité de chaque version à la date de décision. Une analyse rétrospective utilisant les observations ultérieures doit être identifiée séparément, suivant la distinction ex ante et ex post de Hyndman et Athanasopoulos, 2021.

Comment représenter les entrées dans un outil d’évaluation ?
La documentation AutoGluon de fev, état du 9 octobre 2026 distingue past_data et future_data. Pour l’application métier, associez cette séparation à un registre des versions et de leur disponibilité. Les contrôles proposés doivent vérifier le contenu effectivement transmis à chaque prévision.

Pour aller plus loin

• Saisonnalités multiples : représenter les cycles horaires, hebdomadaires et calendaires.
• Chronos-2 : comment l’attention de groupe partage l’information entre séries.
• fev-bench et GIFT-Eval : choisir un benchmark selon les informations disponibles.

Sources

• Lim et ses coauteurs, Temporal Fusion Transformers for Interpretable Multi-horizon Time Series Forecasting, prépublication déposée sur arXiv le 19 décembre 2019, version du 27 septembre 2020. Texte intégral, consulté le 9 octobre 2026.
• Ansari et ses coauteurs, Chronos-2: From Univariate to Universal Forecasting, prépublication déposée sur arXiv le 17 octobre 2025. Texte intégral, consulté le 9 octobre 2026.
• Hyndman et Athanasopoulos, OTexts, Forecasting: Principles and Practice, 2021. Some useful predictors et Forecasting with regression, consultés le 9 octobre 2026.
• Shchur et ses coauteurs, fev-bench: A Realistic Benchmark for Time Series Forecasting, prépublication déposée sur arXiv le 30 septembre 2025, version initiale. Texte intégral, consulté le 9 octobre 2026.
• Thierry et Rochet, TW3 Partners, TW3Cast: A Frozen Router of Lightly Fine-Tuned Foundation Models for Time-Series Forecasting on GIFT-Eval, Selected Entirely on the Training Split, prépublication déposée sur arXiv le 16 septembre 2026. Texte intégral, consulté le 9 octobre 2026.
• AutoGluon, fev, documentation officielle, état du 9 octobre 2026. README consulté le 9 octobre 2026.