Google TimesFM-3 lit désormais la météo et les promotions, mais son déploiement reste restreint

Google TimesFM-3 traite désormais plusieurs flux de données liés, des événements futurs connus et 330 millions de paramètres dans un seul modèle de prévision. Ce changement répond à une limitation majeure de l’approche précédente de Google. Les versions antérieures projetaient principalement une série à partir de son propre historique.

Un détaillant peut désormais combiner les ventes avec la fréquentation, les produits associés, les prévisions météo, les jours fériés et les promotions programmées. Google affirme que le modèle peut exploiter ces relations sans ajustement spécifique à une tâche. Son exemple prévoit une hausse estimée de 20 % des ventes les jours de promotion.

La concurrence ne consiste plus seulement à générer une courbe plausible à partir de valeurs passées. Google, Amazon, Datadog, Salesforce et d’autres développeurs cherchent à créer des modèles de prévision réutilisables pour des données opérationnelles hétérogènes. Google TimesFM-3 entre dans cette compétition avec de solides affirmations fondées sur des benchmarks, mais ses poids préentraînés restent limités à un usage non commercial et hors production.

Google TimesFM-3 dépasse l’approche d’une série à la fois

Le changement central est la prévision multivariée native, qui permet à un modèle de relier une cible à des signaux associés avant de projeter son avenir.

Google Research a annoncé TimesFM-3 le 31 août 2026. L’entreprise le présente comme un modèle fondationnel zero-shot pour les séries temporelles. Zero-shot signifie qu’il peut aborder un nouveau jeu de données de prévision sans recevoir au préalable d’entraînement spécifique à ce jeu de données.

Une série temporelle est simplement une séquence de mesures organisée dans le temps. Les ventes quotidiennes d’un magasin, la charge horaire d’un serveur, les revenus mensuels et les relevés de glucose en sont des exemples courants. Les modèles de prévision étudient les mesures antérieures et estiment ce qui vient ensuite.

Les précédentes versions de TimesFM facilitaient ce processus en fournissant un modèle préentraîné pour de nombreux types de données temporelles. Toutefois, le modèle principal traitait encore chaque série cible indépendamment. Sa vision directe du problème s’arrêtait à l’historique propre de cette série.

TimesFM-2.5 pouvait ajouter des covariables via un parcours de régression XReg distinct. Les covariables sont des variables externes qui aident à expliquer les variations d’une cible. Cet ajout était utile, mais Google n’avait pas préentraîné TimesFM-2.5 comme prévisionniste multivarié natif.

TimesFM-3 modifie le fondement même du modèle. Selon l’annonce du modèle, Google l’a préentraîné pour traiter simultanément les cibles et les variables de soutien. Le modèle peut prévoir plusieurs cibles liées en parallèle tout en examinant leurs connexions.

Google répartit ces entrées en trois groupes utiles. Les cibles multiples couvrent les mesures liées à prévoir, comme les ventes de plusieurs marques de glace. Les covariables passées incluent des signaux disponibles uniquement pour les périodes antérieures, tels que la fréquentation enregistrée d’un magasin.

Les covariables passé-futur s’étendent à la fois sur la période historique et sur l’horizon de prévision. Elles incluent des événements dont les valeurs futures sont déjà connues. Un calendrier de promotions, un planning de jours fériés, une remise planifiée ou une prévision météo externe peuvent relever de cette catégorie.

Cette distinction importe, car les prévisions d’entreprise dépendent rarement du seul historique. Une tendance hebdomadaire ne peut pas savoir qu’un détaillant a programmé une remise mardi prochain. Elle ne peut pas non plus déduire l’arrivée d’une vague de chaleur sans une autre entrée qui la représente.

L’exemple illustratif de Google dans le commerce de détail montre la différence. Une projection univariée répète une tendance hebdomadaire des ventes, car elle ne voit que les ventes antérieures. La prévision de TimesFM-3 reçoit également le calendrier des promotions futures, de sorte que sa sortie augmente aux jours programmés.

Google indique que l’exemple produit une hausse anticipée des ventes d’environ 20 % pour chaque jour de promotion. Ce chiffre illustre le mécanisme plutôt qu’il ne prouve un effet universel dans le commerce de détail. Les réponses réelles des ventes dépendront du produit, du magasin, de la remise, de la saison et du comportement des clients.

La publication concerne donc davantage que l’ajout de colonnes supplémentaires à une requête de prédiction. Google a entraîné le modèle à reconnaître les relations entre les colonnes avant même de voir le jeu de données d’un client particulier. C’est la promesse de la prévision multivariée de Google sous forme zero-shot.

Pourquoi les modèles de prévision ont besoin d’événements futurs connus

Une prévision devient plus utile lorsqu’elle peut distinguer l’historique récurrent d’une intervention future déjà planifiée par les responsables.

De nombreuses décisions opérationnelles modifient le résultat à prévoir. Les détaillants ajustent leurs prix, les spécialistes du marketing programment des campagnes, les usines planifient leur maintenance et les hôpitaux modifient leurs effectifs. Un modèle qui ignore ces actions peut produire une prévision techniquement cohérente mais opérationnellement non pertinente.

Prenons une chaîne d’épiceries qui planifie ses stocks de desserts glacés. Les ventes historiques de glaces peuvent révéler la saisonnalité, les tendances selon les jours de la semaine et la croissance à long terme. Les ventes associées de cornets et de sirops peuvent exposer des relations de demande qu’une seule série de produits ne détecte pas.

La fréquentation enregistrée ajoute des éléments sur l’activité antérieure du magasin. Les prévisions météo apportent des informations sur les conditions durant la période de prévision. Les calendriers de promotions indiquent précisément au modèle quand le détaillant prévoit une intervention.

TimesFM-3 peut examiner ces flux ensemble. Il n’a pas besoin de faire comme si la promotion prévue était une surprise future inattendue. Il peut comparer les périodes de promotion antérieures avec les dates futures programmées et ajuster la prévision en conséquence.

La même structure s’applique au-delà du commerce de détail. Un opérateur cloud pourrait prévoir la demande à l’aide de l’historique des charges de travail, des calendriers de publication et des programmes de maintenance. Un planificateur énergétique pourrait combiner des mesures de charge avec des prévisions de température et des arrêts industriels connus.

Les fabricants pourraient projeter des relevés de capteurs parallèlement aux calendriers de production. Les analystes de santé pourraient relier des mesures issues de plusieurs appareils à des événements thérapeutiques connus. Les équipes financières pourraient examiner des indicateurs opérationnels associés plutôt que d’extrapoler une seule ligne comptable.

Ces cas ne sont pas identiques, et un modèle réutilisable doit gérer d’importantes différences d’échelle. Le trafic d’un site web peut atteindre des millions tandis qu’un capteur d’appareil enregistre de petites valeurs décimales. TimesFM-3 normalise chaque série afin que ces échelles ne dominent pas les comparaisons internes du modèle.

Google indique avoir préentraîné le système sur plus de mille milliards de points temporels issus de sources réelles et synthétiques. Les sources citées incluent les données de préentraînement GIFT-Eval, les vues de pages Wikipédia, les requêtes Google Trends et des séquences synthétiques augmentées.

Le modèle contient 330 millions de paramètres. Cela le rend plus grand que TimesFM-2.5, qui utilisait 200 millions de paramètres, mais plus petit que de nombreux modèles de langage généralistes. Le nombre de paramètres ne détermine pas à lui seul la précision des prévisions ni leur coût de déploiement.

La distinction la plus importante concerne ce que le modèle a appris lors du préentraînement. La prévision multivariée de Google demande au réseau de transférer des schémas de relations, et non seulement des formes au sein d’une série unique. Cela ouvre la possibilité d’expérimentations plus rapides sur des jeux de données comportant de nombreuses variables connectées.

Cela modifie également ce que les équipes doivent préparer. Un modèle ne peut pas tirer parti d’un calendrier de promotions que personne n’a enregistré avec précision. Les données météo doivent correspondre aux bons emplacements et intervalles de temps. Les cibles et les covariables doivent disposer d’horodatages cohérents.

Les covariables futures introduisent une autre dépendance. La sortie ne peut être aussi fiable que ces entrées futures. Une prévision fondée sur une projection météo inexacte ou un plan de promotion abandonné hérite de cette erreur.

Les équipes doivent aussi éviter de fournir des informations qui n’auraient pas été disponibles au moment où la prévision a été établie. Ce problème est appelé fuite de données. La fuite rend les évaluations historiques plus favorables en permettant à un modèle de voir des éléments provenant du futur.

Le cas d’usage le plus solide n’est donc pas la prédiction automatique à partir de chaque colonne disponible. Il s’agit d’une prévision contrôlée, avec des variables dont les significations et règles de disponibilité sont claires. TimesFM-3 réduit le travail de modélisation, mais n’élimine pas la gouvernance des données.

Comment la prévision TimesFM-3 fonctionne en un seul passage

Google a repensé le chemin de prévision afin que les relations temporelles et les relations entre séries alternent au sein du même transformer.

Le modèle commence par regrouper 32 points temporels consécutifs dans un patch. Le patching convertit une longue séquence numérique en une série plus courte de tokens. Cela ressemble à la manière dont certains vision transformers traitent des patches d’image plutôt que des pixels individuels.

Chaque cible ou covariable disponible uniquement dans le passé reçoit des tokens créés à partir de ses patches historiques. Les covariables passé-futur utilisent une construction avec anticipation. Leurs tokens incluent le patch actuel et des patches futurs contenant des signaux déjà connus.

Ces tokens entrent dans un transformer uniquement décodeur comportant 20 couches, une dimension de modèle de 1 280 et 16 têtes d’attention. Ces spécifications figurent sur la fiche officielle du modèle. L’architecture alterne deux formes d’attention.

L’attention temporelle causale se déplace horizontalement dans le temps au sein d’une série. Causale signifie que chaque token peut examiner les informations antérieures, mais pas des cibles futures inconnues. Cette restriction aide à empêcher les valeurs cibles futures de fuiter dans la prédiction.

L’attention complète entre variables se déplace verticalement entre différentes séries à la même position temporelle. Elle permet aux tokens de ventes d’examiner les signaux de promotion, de météo, de trafic ou de produits associés. Le modèle alterne ces opérations temporelles et inter-séries dans sa pile de transformers.

Ce schéma alterné définit le mécanisme central de prévision de TimesFM-3. Une opération apprend ce qui a changé au fil du temps. La suivante examine comment les variables évoluent ensemble.

Google a également modifié la manière dont le modèle génère l’horizon. Les versions précédentes de TimesFM prédisaient un patch de sortie, puis utilisaient ce résultat lors de la génération du suivant. Cette boucle autorégressive peut accumuler les erreurs et ajouter de la latence sur de longs horizons.

TimesFM-3 place à la place des tokens masqués sur l’horizon futur demandé. Les tokens masqués agissent comme des positions vides que le réseau doit remplir. Le modèle génère la prévision complète en un seul passage avant plutôt que dans une boucle sortie par sortie.

Les cibles futures inconnues et les covariables disponibles uniquement dans le passé restent masquées. Les signaux futurs connus, y compris les promotions et jours fériés programmés, restent visibles. Cette disposition permet au modèle de remplir l’horizon cible tout en consultant les événements déjà connus des planificateurs.

L’approche s’appuie sur le masquage de patches contigus, une méthode d’entraînement qui cache des sections consécutives d’une séquence. Le modèle apprend à reconstruire ces sections à partir de leur contexte environnant. Google applique ce principe à un horizon de prévision entier.

Une estimation ponctuelle unique masquerait une incertitude importante. TimesFM-3 produit donc neuf quantiles à chaque étape future, couvrant les 10e à 90e percentiles. Les quantiles décrivent une plage de résultats plausibles plutôt qu’une seule réponse certaine.

Un détaillant pourrait utiliser l’estimation médiane pour un plan de stock de base. Les quantiles inférieurs et supérieurs peuvent soutenir des scénarios prudents et ambitieux. L’écart entre eux révèle également les zones où le modèle exprime une plus grande incertitude.

Ces intervalles ne sont utiles que s’ils restent calibrés sur les données locales. Un 90e percentile nominal devrait se comporter comme tel lors de prévisions réelles répétées. Les équipes ont besoin de tests rétrospectifs pour déterminer si l’incertitude rapportée correspond à leur environnement opérationnel.

Google fournit le code via le dépôt public TimesFM. Le projet prend en charge les entrées univariées, plusieurs cibles, les covariables limitées au passé et les covariables couvrant passé et futur. Les poids PyTorch sont disponibles séparément via Hugging Face.

Le dépôt comprend également un backend MLX pour Apple silicon. Ses exemples documentés prennent en charge des cibles multivariées et les deux types de covariables. Cette option réduit les obstacles à l’expérimentation locale, même si les poids préentraînés restent soumis à une licence restrictive.

Cette architecture ne raisonne pas sur la causalité métier au sens humain. Si les remises et les ventes évoluent historiquement de concert, le modèle peut exploiter cette relation. Il n’établit pas qu’une remise particulière a causé la hausse.

La corrélation peut également échouer lorsque les conditions commerciales changent. Une promotion peut sous-performer parce qu’un concurrent baisse ses prix ou que les stocks sont épuisés. Les utilisateurs de prévisions ont toujours besoin d’un contexte opérationnel qu’aucune série d’entrée ne capture entièrement.

De Solides Benchmarks Ne Tranchent Pas la Question du Déploiement

Les classements publiés par Google font de TimesFM-3 une référence sérieuse, mais ils ne garantissent pas de meilleures prévisions sur chaque jeu de données privé.

Google a évalué le modèle sur GIFT-Eval, FEV-Bench et TIME. Ces suites publiques testent la prévision sur différents jeux de données, fréquences, horizons et métriques. L’entreprise indique que TimesFM-3 a obtenu le meilleur rang moyen sur les trois.

Les comparaisons incluaient Chronos-2 d’Amazon, la famille Toto 2.0 de Datadog et TimesFM-2.5 de Google. Google indique que TimesFM-3 a obtenu de solides résultats même en mode univarié. L’ajout d’informations inter-séries et de covariables a encore amélioré son rang moyen.

Le dépôt décrit FEV-Bench comme un ensemble de 100 tâches de prévision réelles. Il décrit TIME comme comprenant 50 jeux de données sectoriels et 98 tâches d’évaluation. GIFT-Eval fournit une autre comparaison étendue entre modèles de fondation, couvrant plusieurs domaines.

Cette diversité aide à réduire la dépendance à un jeu de données particulièrement favorable. Les métriques ponctuelles et probabilistes testent également des qualités différentes. Les métriques ponctuelles évaluent les prédictions centrales, tandis que les métriques probabilistes examinent la qualité des distributions de prévision.

Cependant, les résultats résumés publiquement reposent sur des rangs moyens plutôt que sur un pourcentage universel d’amélioration. Le rang indique un positionnement relatif entre les tâches. Il ne renseigne pas un acheteur sur l’ampleur du gain de précision pour un catalogue de ventes ou un parc de serveurs donné.

Google a également publié le résultat lui-même. Une réplication indépendante sera importante, en particulier pour les entrées multivariées et les covariables futures connues. Les équipes ont besoin de résultats fondés sur leurs propres horizons de prévision, schémas de données manquantes et coûts de décision.

Le préentraînement introduit une autre incertitude. Le modèle a vu plus d’un billion de points temporels, incluant des signaux du web public et des données synthétiques. Cette ampleur peut améliorer le transfert, mais la similarité entre les données de préentraînement et un jeu de données en aval peut influencer les performances zero-shot.

Une étude de 2025 sur la généralisation des prévisions a constaté que des modèles de fondation pour séries temporelles antérieurs s’affaiblissaient face à certains changements de distribution. Ses tests utilisaient TimesFM 2.0, et non TimesFM-3, ils n’invalident donc pas les nouveaux résultats de Google.

L’étude identifie néanmoins un risque de déploiement pertinent. Sur un petit jeu de données d’électricité, un modèle spécialisé de 49 500 paramètres a surpassé, après adaptation, le modèle TimesFM antérieur beaucoup plus volumineux. Un préentraînement plus vaste n’a pas supprimé la valeur de la spécialisation locale.

TimesFM-3 pourrait mieux gérer de tels cas, car son architecture et son entraînement ont changé. Google affirme que son mode univarié améliore déjà les versions précédentes. Toutefois, une nouvelle avance dans les benchmarks n’annule pas le problème du changement de domaine.

Les données de vente au détail illustrent ce défi. Un modèle entraîné sur de larges motifs temporels peut bien gérer la saisonnalité normale. Il peut néanmoins rencontrer des difficultés après le déménagement d’un magasin, une refonte de l’assortiment, l’arrivée d’un concurrent, une rupture d’approvisionnement ou un changement soudain du comportement des clients.

Les covariables aident lorsqu’elles représentent ce changement. Elles offrent peu de protection lorsque l’événement pertinent reste non enregistré. Elles peuvent également induire le modèle en erreur lorsque les relations historiques cessent de tenir.

La comparaison avec la prévision spécifique à une tâche reste donc le principal enjeu. Les modèles de fondation promettent un déploiement plus rapide et une réutilisation plus large. Les modèles spécialisés promettent une adaptation plus étroite aux schémas de demande, contraintes et fonctions de perte d’une entreprise.

La précision n’est qu’une partie de cette décision. Les équipes doivent mesurer la latence d’inférence, les besoins en infrastructure, le comportement en cas de défaillance, la calibration et l’effort de surveillance. Elles doivent également déterminer si une prévision peut être expliquée suffisamment bien pour des approbations d’inventaire ou financières.

TimesFM-3 fournit des sorties probabilistes, mais les quantiles ne sont pas des explications. Un analyste doit encore déterminer pourquoi le modèle a réagi à la météo ou à une promotion. Des tests d’ablation contrôlés peuvent aider en retirant une entrée et en mesurant le changement.

Le backtesting doit reproduire les informations disponibles à chaque date de coupure historique. Les entrées météo futures doivent provenir des prévisions émises à ce moment-là, et non d’observations enregistrées ultérieurement. Les calendriers promotionnels doivent refléter leurs versions antérieures, y compris les annulations survenues par la suite.

Les équipes devraient également comparer avec des références simples. Les prévisions naïves saisonnières, les régressions linéaires, les arbres à gradient boosting et les modèles spécialisés établis peuvent rester compétitifs. Un modèle de fondation ne mérite sa place que s’il améliore le résultat opérationnel.

La Licence Non Commerciale Crée le Point de Pression Immédiat

Les développeurs peuvent examiner TimesFM-3 dès aujourd’hui, mais la plupart des entreprises ne peuvent pas intégrer ses poids préentraînés par défaut dans un flux de production.

Google a publié le code source du dépôt sous Apache 2.0. Cependant, les poids préentraînés de TimesFM-3 utilisent la licence distincte TimesFM Non-Commercial License v1.0. Le dépôt indique que ces poids sont réservés à une utilisation non commerciale et hors production.

Cette séparation compte. La disponibilité du code source permet aux chercheurs d’inspecter l’implémentation et de mener des expériences. Elle n’accorde pas à un détaillant l’autorisation d’utiliser les poids par défaut pour le réapprovisionnement en direct ou la planification des revenus.

Les poids TimesFM antérieurs, jusqu’à la version 2.5, restent sous Apache 2.0. Les équipes peuvent donc rencontrer des droits différents au sein d’un même projet. Elles doivent vérifier la licence associée au checkpoint exact qu’elles prévoient d’utiliser.

Cette restriction façonne également la pression concurrentielle. Amazon, Datadog, Salesforce, Nixtla, IBM et d’autres organisations développent des systèmes de prévision réutilisables. La disponibilité, l’intégration, le support et les licences peuvent l’emporter sur une faible avance dans les benchmarks.

Google indique que l’intégration BigQuery arrivera dans les prochaines semaines. Ce déploiement est le premier signal important à surveiller. Il devrait préciser comment les clients accèdent à TimesFM-3 et quelles conditions commerciales régissent l’utilisation hébergée.

BigQuery expose déjà la fonction AI.FORECAST pour la prévision univariée basée sur TimesFM. Une version multivariée native pourrait rapprocher le nouveau modèle des données d’entreprise existantes. L’accès SQL réduirait également le travail d’intégration requis des équipes de prévision.

Le deuxième signal est la réplication indépendante des benchmarks. Les chercheurs devraient confirmer les résultats sur les trois suites d’évaluation et tester des changements de distribution difficiles. Les comparaisons publiques devraient également publier les écarts réels de métriques en plus des rangs moyens.

Le troisième signal est la preuve en production. Les études de cas devraient montrer si les covariables améliorent des décisions telles que l’allocation des stocks, les effectifs, la planification de capacité ou la préparation aux anomalies. Les rapports utiles incluront des comparaisons avec des références et des coûts d’erreur, et non uniquement la précision du modèle.

Un service de production renforcerait l’affirmation de Google selon laquelle un prévisionniste généraliste peut dépasser les expériences de recherche. Le maintien de restrictions de licence sans voie commerciale affaiblirait cette conclusion. Les développeurs pourraient étudier le modèle tout en choisissant un autre système pour le déploiement.

Des résultats indépendants pourraient également modifier le paysage concurrentiel. Des gains constants sur des jeux de données métier inédits soutiendraient la stratégie zero-shot de Google. Des résultats mitigés renforceraient l’idée de traiter TimesFM-3 comme une référence de départ plutôt que comme un système de prévision final.

La sortie du modèle marque néanmoins une avancée technique significative. Le précédent modèle de fondation de Google ne pouvait pas combiner nativement plusieurs cibles avec des signaux historiques et futurs connus. TimesFM-3 intègre ces relations au préentraînement et à l’inférence.

Cette capacité rapproche la prévision par modèles de fondation des véritables problèmes de planification. Les entreprises ne vivent pas les ventes, la météo, le trafic, les remises et les jours fériés comme des chronologies isolées. Leurs systèmes de prévision ne devraient pas être obligés d’ignorer ces connexions.

Pourtant, l’avenir reste hors du contrôle du modèle. Les prévisions météorologiques changent, les promotions sont annulées et le comportement des clients évolue. Neuf quantiles peuvent exprimer l’incertitude, mais ils ne peuvent pas transformer des entrées incomplètes en certitude.

Pour les développeurs, la prochaine action raisonnable consiste en une évaluation hors ligne contrôlée. Comparez Google TimesFM-3 à la référence de production actuelle, préservez les limites historiques de l’information et testez la calibration des prévisions. Surveillez ensuite BigQuery pour la voie commerciale que les poids téléchargeables ne fournissent pas actuellement.