Le 31 août 2026, Google Research a présenté TimesFM-3, un modèle de fondation zero-shot destiné aux séries temporelles multivariées. L’éditeur annonce 330 millions de paramètres, un préentraînement sur plus de mille milliards de points temporels et une prise en charge native de plusieurs cibles ainsi que de variables historiques ou connues dans le futur. Ces capacités rendent le modèle intéressant pour accélérer des projets de prévision. Elles ne dispensent cependant ni d’une comparaison locale, ni d’une analyse des données, ni d’un dispositif de gouvernance.
À retenir : TimesFM-3 doit être traité comme un candidat supplémentaire, pas comme une vérité universelle. Un pilote sérieux le compare à une baseline naïve, à un modèle statistique et à l’approche actuellement utilisée, sur des fenêtres temporelles reproductibles et des métriques liées aux décisions métier.
1. Ce que TimesFM-3 apporte réellement
Les premières versions de TimesFM se concentraient sur des prévisions univariées : le modèle observait l’historique d’une série et prédisait sa suite. TimesFM-3 ajoute une représentation multivariée. Il peut prévoir plusieurs séries liées et utiliser des variables qui influencent le phénomène.
Google distingue trois familles d’entrées. Les cibles sont les séries à prévoir, par exemple les ventes de plusieurs produits. Les covariables passées ne sont connues que dans l’historique, comme le trafic constaté. Les covariables dynamiques sont connues pour l’horizon futur, par exemple un calendrier de promotions, des jours fériés ou une prévision météo disponible au moment de la décision.
L’architecture alterne une attention temporelle causale et une attention entre variables. Le modèle produit l’ensemble de l’horizon en un passage non autorégressif et fournit neuf quantiles entre le 10e et le 90e percentile. Cette sortie probabiliste permet de représenter plusieurs scénarios plutôt qu’une ligne unique.
Google annonce une première place moyenne sur plusieurs benchmarks publics face à d’autres modèles préentraînés. Il s’agit de résultats communiqués par l’équipe conceptrice, sur des jeux et protocoles définis. Ils indiquent un potentiel, mais ne préjugent pas de la performance sur vos séries, vos ruptures, vos granularités et vos contraintes opérationnelles.
2. Pourquoi le zero-shot change le démarrage d’un projet
Un modèle zero-shot peut être appliqué sans entraînement spécifique sur chaque série. Cette propriété réduit le temps nécessaire pour obtenir une première référence. Une équipe peut charger l’historique, définir l’horizon et comparer rapidement le résultat à ses méthodes existantes.
Ce gain est particulièrement utile lorsque l’organisation possède beaucoup de séries courtes ou hétérogènes : ventes par point de distribution, volumes de tickets par catégorie, consommation d’infrastructure par service ou besoins de stock par référence. Entraîner et maintenir un modèle distinct pour chaque série devient coûteux.
Le zero-shot ne signifie toutefois pas « sans travail de données ». Il faut toujours définir la fréquence, gérer les trous, distinguer les zéros réels des valeurs manquantes, traiter les changements de périmètre et choisir la période d’historique pertinente. Un modèle puissant ne peut pas deviner qu’un magasin a fermé, qu’un capteur a changé ou qu’une règle comptable a déplacé les volumes.
L’inventaire, la qualité, les droits et la traçabilité doivent donc précéder le choix du modèle, comme dans notre guide pour préparer ses données à un projet d’IA générative. Pour la prévision, ajoutez à cette base la date de disponibilité réelle de chaque variable.
Il faut aussi comparer le temps total. Le modèle peut éviter une phase d’entraînement mais demander davantage de calcul à l’inférence ou une infrastructure spécifique. Le coût pertinent est celui d’une prévision produite, supervisée et utilisée, pas seulement celui du notebook initial.
3. Les cas où le multivarié peut créer de la valeur
Le multivarié est utile lorsque les séries partagent réellement une dynamique. Les ventes de produits complémentaires, les charges de plusieurs services d’une plateforme ou les volumes d’agences soumises au même calendrier peuvent s’informer mutuellement.
Les variables connues dans le futur sont souvent encore plus importantes. Un calendrier de promotions, une fermeture planifiée, un lancement, un jour férié ou une réservation déjà enregistrée peuvent modifier l’horizon. Une approche univariée voit l’effet passé mais ignore l’événement à venir ; un modèle acceptant ces covariables peut l’intégrer.
La qualité dépend toutefois de la stabilité du lien. Une promotion n’a pas toujours le même effet selon le prix, le canal, la disponibilité ou la saison. Une météo prévisionnelle contient elle-même de l’incertitude. Introduire davantage de variables ne garantit pas une meilleure généralisation et peut créer une dépendance à des données indisponibles en production.
Avant le pilote, construisez une matrice simple : variable, disponibilité au moment de la prévision, fréquence de mise à jour, qualité historique, propriétaire et justification métier. Toute variable inconnue au moment réel de la décision doit être exclue du jeu futur, même si elle est présente dans l’entrepôt après coup.
4. Éviter les fuites entre passé et futur
La fuite temporelle est l’erreur la plus dangereuse d’un projet de prévision. Elle se produit lorsqu’une information du futur est utilisée, directement ou indirectement, pour produire une prédiction censée avoir été faite dans le passé.
Un exemple classique est une donnée promotionnelle enregistrée après la campagne mais rattachée à sa date de début. Un backtest réalisé aujourd’hui considère alors que l’information était disponible, alors qu’elle ne l’était pas au moment de la décision. Le même problème concerne les corrections de données, les agrégats calculés sur une période complète et les variables mises à jour rétroactivement.
Chaque colonne doit posséder deux dates : la date de l’événement et la date de disponibilité. Le découpage utilise la seconde. Pour une prévision réalisée le 1er juin, le modèle ne reçoit que ce qui était réellement connu le 1er juin.
La normalisation peut également provoquer une fuite si les statistiques sont calculées sur l’ensemble du jeu. Même lorsque le modèle possède sa propre normalisation, les transformations métier, l’imputation et la sélection des séries doivent être ajustées uniquement sur le passé de chaque fenêtre.
Enfin, conservez un jeu de test final intact. Les nombreux essais sur le même horizon transforment progressivement ce jeu en donnée d’entraînement implicite pour l’équipe.
5. Construire un backtesting fiable
Un unique découpage passé/futur donne une vision fragile. Utilisez une validation à origine glissante : choisissez plusieurs dates de prévision historiques, entraînez ou configurez les méthodes avec les données disponibles à chaque date, puis mesurez l’horizon suivant.
Les fenêtres doivent représenter les situations importantes : saison haute, période calme, lancement, rupture d’approvisionnement et changement de tendance. Un modèle performant en moyenne peut échouer précisément pendant les périodes où la décision est la plus coûteuse.
Comparez au minimum quatre niveaux :
- une baseline naïve, telle que la dernière valeur ou la même période précédente ;
- une méthode statistique adaptée à la saisonnalité ;
- la solution actuellement utilisée par l’entreprise ;
- TimesFM-3 dans les modes univarié et multivarié lorsque les données le permettent.
La baseline naïve est indispensable. Dans de nombreux contextes stables, elle reste difficile à battre. Un modèle qui améliore légèrement un benchmark mais ne dépasse pas « même jour de la semaine précédente » n’apporte pas une valeur opérationnelle suffisante.
Documentez les versions de données, de code, de modèle et de dépendances. Le résultat doit pouvoir être rejoué plusieurs mois plus tard, notamment si une nouvelle version du modèle modifie les prévisions.
6. Mesurer l’incertitude, pas seulement l’erreur moyenne
Les métriques doivent correspondre à la décision. La MAE mesure une erreur absolue moyenne et reste lisible dans l’unité métier. La WAPE rapporte l’erreur au volume global, mais peut être dominée par les grosses séries. La MASE compare le modèle à une prévision naïve et facilite les comparaisons entre séries.
Pour les quantiles, utilisez une perte quantile et vérifiez la calibration. Si l’intervalle annoncé à 80 % ne contient la valeur réelle que 50 % du temps, l’incertitude est sous-estimée. À l’inverse, un intervalle très large couvre presque tout mais aide peu la décision.
Ajoutez des métriques métier. Une sous-prévision de stock peut coûter plus cher qu’une sur-prévision. Une erreur de 10 % sur une petite référence n’a pas le même impact que sur un produit stratégique. Calculez les ruptures évitées, le stock immobilisé, les heures planifiées ou le budget cloud réservé.
Évaluez aussi la stabilité. Une prévision qui change fortement pour une petite modification d’entrée peut être difficile à exploiter. Comparez les versions successives à mesure que de nouvelles données arrivent et mesurez la révision de l’horizon.
La sortie probabiliste de TimesFM-3 constitue un avantage potentiel, à condition que les quantiles soient calibrés sur le contexte local et réellement utilisés dans les règles de décision.
7. Décider entre modèle de fondation, modèle spécialisé et hybride
Un modèle de fondation est adapté lorsque le nombre de séries est élevé, que le temps de démarrage est court et que l’organisation souhaite une base commune. Il peut aussi servir de challenger permanent ou de solution de secours lorsqu’un modèle spécialisé manque d’historique.
Un modèle local reste pertinent lorsque le phénomène est fortement spécifique, que les variables sont bien maîtrisées et que quelques points de performance ont une valeur élevée. Il peut intégrer des contraintes métier, des fonctions de coût asymétriques ou une structure causale non représentée dans le modèle généraliste.
L’approche hybride est souvent la plus robuste. TimesFM-3 fournit une prévision de base et des quantiles ; une couche métier applique des contraintes, combine des informations locales ou corrige un biais observé. Un autre modèle peut être sélectionné pour certaines familles de séries.
La décision doit intégrer la performance, le coût, la latence, la licence, la confidentialité, l’explicabilité et la facilité d’exploitation. Vérifiez également la disponibilité des intégrations annoncées : au 31 août 2026, Google indiquait TimesFM-3 disponible sur GitHub et Hugging Face, tandis que l’intégration BigQuery était annoncée pour les semaines suivantes.
8. Un pilote en six étapes
Commencez par un périmètre où la décision et la valeur sont claires : vingt à cent séries, un horizon défini et une baseline existante. Évitez de sélectionner uniquement les séries les plus propres.
Deuxièmement, construisez la table de disponibilité des variables et supprimez les fuites. Troisièmement, préparez cinq à dix origines de backtest couvrant plusieurs situations métier. Quatrièmement, exécutez toutes les méthodes avec le même protocole et les mêmes données.
Cinquièmement, organisez une revue avec les utilisateurs. Présentez les erreurs, les intervalles et quelques cas concrets sans révéler d’abord le nom du modèle, afin de réduire le biais de nouveauté. Demandez quelle décision aurait changé et avec quel impact.
Sixièmement, déployez en mode observation. Le système génère les prévisions, mais la méthode actuelle reste décisionnaire pendant plusieurs cycles. Mesurez la qualité, le coût, la stabilité et la disponibilité avant tout basculement.
Fixez les critères de succès avant le test : amélioration minimale par rapport à la baseline, calibration acceptable, coût maximal, temps d’exécution et proportion de séries pour lesquelles le modèle ne dégrade pas le résultat. Sans seuil préalable, l’équipe trouvera toujours une manière de justifier le modèle le plus récent.
Conclusion
TimesFM-3 marque une évolution intéressante des modèles de fondation pour séries temporelles : prévision multivariée zero-shot, variables connues dans le futur et sortie probabiliste en un seul passage. Ces caractéristiques peuvent réduire le coût d’entrée et élargir le nombre de séries couvertes.
La valeur ne sera toutefois démontrée que par un protocole local, sans fuite temporelle, face à des baselines solides et avec des métriques liées au métier. Partitech accompagne la préparation des données, la construction du backtesting, l’industrialisation MLOps et la traduction des prévisions en décisions mesurables.
Références
- Google Research — « TimesFM-3: A zero-shot foundation model for multivariate forecasting », 31 août 2026 : https://research.google/blog/timesfm-3-a-zero-shot-foundation-model-for-multivariate-forecasting/
- Google Research — dépôt TimesFM : https://github.com/google-research/timesfm
- Hugging Face — modèle TimesFM-3 : https://huggingface.co/google/timesfm-3.0-pytorch