Google Research lance TimesFM-3, mais son meilleur modèle s’accompagne d’une contrainte commerciale

Google Research a publié TimesFM-3 le 31 août 2026, ajoutant la prévision multivariée native à une famille de modèles auparavant limitée aux prédictions sur une seule série. Le modèle de 330 millions de paramètres traite davantage d’informations en un seul passage, notamment des séries liées, des signaux historiques et des événements futurs connus.

Ce changement compte, car les prévisions réelles dépendent rarement d’un seul historique. La demande dans le commerce de détail réagit aux promotions et à la météo. La consommation d’énergie suit la température, les plannings et l’activité. Les métriques d’infrastructure évoluent ensemble lorsqu’un service partagé tombe en panne.

Selon Google, TimesFM-3 comble cette lacune sans nécessiter d’ajustement fin spécifique à chaque tâche. Toutefois, cette publication comporte une contradiction importante. Le code reste ouvert sous licence Apache 2.0, tandis que les nouveaux poids préentraînés interdisent tout usage commercial et en production.

Le résultat va au-delà d’une simple mise à jour de modèle. Google Research a produit une architecture de prévision généraliste plus robuste, tout en séparant l’expérimentation publique d’un déploiement sans restrictions. Cela met sous pression Chronos-2 d’Amazon, la famille Toto de Datadog et les équipes qui maintiennent des pipelines de prévision spécialisés.

Ce que Google Research a changé dans TimesFM-3

TimesFM-3 fait passer la famille TimesFM d’un outil de prévision à série unique à un modèle capable de raisonner sur des variables connectées.

Google a présenté le TimesFM original en février 2024. Ce modèle utilisait un transformeur uniquement décodeur, ce qui signifie qu’il prédisait de futurs segments de séries temporelles à partir des segments précédents. Ses 200 millions de paramètres ont été entraînés sur 100 milliards de points temporels réels.

Le modèle initial réalisait des prévisions zéro-shot, c’est-à-dire qu’il produisait des prédictions sur un jeu de données inédit sans entraînement spécifique à ce jeu de données. Google a rapporté des résultats compétitifs face aux méthodes statistiques et aux modèles supervisés d’apprentissage profond dans son article sur le modèle de prévision.

TimesFM-2.0 a ensuite porté la taille du modèle à 500 millions de paramètres. TimesFM-2.5 est revenu à 200 millions tout en étendant le contexte pris en charge de 2 048 à 16 384 points temporels. Il a également ajouté des prévisions continues par quantiles pour des horizons atteignant 1 000 étapes.

Ces versions restaient toutefois fondamentalement univariées. Chaque prévision traitait principalement une série cible comme l’objet à prédire, même lorsque des régresseurs externes étaient disponibles via un mécanisme distinct.

TimesFM-3 modifie cette conception. Ses 330 millions de paramètres ont été préentraînés sur plus d’un trillion de points temporels réels et synthétiques. Ce corpus d’entraînement est plus de dix fois supérieur à celui communiqué pour le premier modèle.

Le modèle accepte plusieurs types d’informations distincts. Plusieurs cibles représentent des séries liées que les utilisateurs souhaitent prévoir ensemble. Les covariables passées fournissent des variables connues uniquement sur la période d’observation. Les covariables passées-futures incluent des valeurs déjà connues sur l’ensemble de l’horizon de prévision.

Un détaillant peut, par exemple, prédire conjointement la demande de glaces, de cornets et de sirop. La fréquentation historique peut servir de covariable passée. Les promotions planifiées et les prévisions météorologiques peuvent devenir des covariables passées-futures.

Cette organisation permet au modèle d’exploiter des liens que la prévision univariée écarte. Une hausse des ventes devient plus facile à interpréter lorsque le modèle constate qu’elle a coïncidé avec une promotion. Les variations de la demande entre produits associés peuvent également apporter des éléments sur des comportements communs.

La publication officielle de TimesFM-3 indique que le modèle prend en charge les prévisions ponctuelles et par quantiles pour chaque cible. Une prévision ponctuelle fournit une valeur attendue unique. Les quantiles décrivent une plage de résultats possibles et leur incertitude.

TimesFM-3 produit neuf quantiles, allant du 10e au 90e percentile. C’est important pour les décisions où une seule prédiction ne suffit pas. Les équipes chargées des stocks doivent comprendre les risques de rupture et de surstock, et pas seulement la demande attendue.

Google indique également que le modèle fonctionne en mode univarié. Les développeurs peuvent donc tester le nouveau checkpoint sur des charges de travail existantes à série unique avant de construire un pipeline de données multivarié complet.

La publication est déjà disponible via le dépôt public de Google Research et un checkpoint Hugging Face. Google indique qu’une intégration BigQuery suivra dans les prochaines semaines, ce qui fait du 31 août la date vérifiée de l’événement à l’origine de la visibilité renouvelée du dépôt.

La tendance GitHub est donc liée à une publication récente, et non à une redécouverte du projet de 2024. TimesFM-3 est le modèle le plus récent du dépôt, et sa nouvelle architecture multivariée est l’événement qui suscite l’attention.

Pourquoi la prévision multivariée change les enjeux concurrentiels

Le changement important ne réside pas seulement dans une meilleure précision. TimesFM-3 cible les relations complexes qui déterminent l’efficacité de la prévision en production.

La plupart des prévisions opérationnelles s’inscrivent dans des systèmes connectés. Un entrepôt ne subit pas la demande indépendamment des prix, des promotions, de la météo, des jours fériés et des stocks voisins. Un centre de données ne génère pas des signaux isolés de CPU, de mémoire, de trafic et de latence.

Les modèles univariés simplifient ces relations. Ils peuvent détecter la saisonnalité, les tendances et les schémas récurrents dans l’historique d’une seule cible. En revanche, ils ne peuvent pas interpréter directement une promotion programmée sans que cette information soit introduite par un autre mécanisme.

La prévision multivariée traite plusieurs séries conjointement. Elle peut modéliser la façon dont une variable évolue avec une autre et comment des signaux externes modifient la cible. Cette approche est particulièrement utile lorsque ces relations se répètent dans le contexte historique.

L’exemple de vente au détail présenté par Google montre pourquoi. Une prévision univariée prolonge le schéma historique des ventes hebdomadaires. Elle ne peut pas anticiper les jours de promotion, car le calendrier n’apparaît pas dans les valeurs passées de la cible.

TimesFM-3 reçoit ce calendrier comme covariable future connue. Le modèle associe alors les promotions historiques aux variations des ventes et applique cette relation aux dates prévues. L’exemple de Google montre une hausse anticipée des ventes d’environ 20 % pour chaque jour de promotion.

Ce chiffre est illustratif et ne prouve pas que le modèle produira la même prévision de hausse chez tous les détaillants. Les effets des promotions dépendent des prix, des produits, des clients, du moment choisi et de la qualité des données. L’exemple montre plutôt comment les informations futures sont intégrées à la prévision.

Cette capacité exerce une pression directe sur les autres modèles de fondation pour séries temporelles. La famille Chronos d’Amazon a contribué à établir le préentraînement de type modèle de langage comme une approche viable de prévision. Chronos-2 a ensuite étendu la concurrence aux tâches multivariées et tenant compte des covariables.

La famille Toto de Datadog vise également la prévision généraliste, y compris les charges de travail multivariées. La famille Moirai de Salesforce et les Tiny Time Mixers d’IBM représentent d’autres tentatives pour remplacer des modèles distincts et spécifiques à chaque tâche par des systèmes préentraînés réutilisables.

La concurrence porte de plus en plus sur l’étendue du déploiement. Un modèle de fondation qui ne fonctionne que sur des benchmarks publics et propres offre une valeur limitée à une équipe opérationnelle. Le système gagnant doit gérer un contexte métier irrégulier, l’incertitude, l’évolution des relations et des coûts d’inférence acceptables.

TimesFM-3 offre à Google une réponse crédible aux concurrents qui ont déjà dépassé la prévision univariée. Il relie également la recherche à un canal de distribution existant. Les capacités antérieures de TimesFM étaient accessibles dans les environnements BigQuery, AlloyDB, Google Sheets et Vertex AI.

Google a indiqué que TimesFM traitait déjà des centaines de millions de requêtes mensuelles via BigQuery et AlloyDB en 2025. Ce chiffre concerne les versions précédentes du modèle, et non TimesFM-3, mais il montre une voie établie entre la recherche et l’usage régulier.

La distribution pourrait compter autant que le rang dans les benchmarks. Un modèle de prévision intégré à un entrepôt de données permet aux analystes de travailler à proximité de données métier gouvernées. Il évite à chaque équipe de devoir assembler un service d’inférence distinct avant de tester une prévision.

La pression s’exerce également sur les pipelines de prévision spécialisés. De nombreuses organisations entraînent encore des modèles différents pour des produits, régions ou métriques distincts. Chaque modèle exige de l’ingénierie de variables, de la validation, du monitoring et une maintenance répétée.

Un généraliste zéro-shot change le point de départ. Les équipes peuvent évaluer un modèle sur de nombreuses séries avant de décider où un entraînement spécialisé reste pertinent. Cela n’élimine pas les modèles personnalisés, mais relève le niveau qu’ils doivent surpasser.

C’est aussi pourquoi l’expression « sans ajustement fin » exige une interprétation prudente. Les utilisateurs doivent toujours sélectionner les cibles, préparer les covariables, éviter les fuites de données, choisir les horizons de prévision et évaluer les coûts métier. Le modèle supprime une étape d’entraînement, pas la discipline de prévision qui l’entoure.

Un modèle en un seul passage réécrit le mécanisme de prévision

TimesFM-3 combine l’attention inter-séries à un décodage en un seul passage, s’attaquant à la fois au contexte manquant et à l’accumulation des erreurs.

Comme les versions précédentes de TimesFM, le modèle regroupe les observations adjacentes en segments de 32 pas de temps. Un segment fonctionne comme un token dans un modèle de langage, en compressant plusieurs valeurs continues dans une représentation interne.

Le découpage en segments réduit la longueur des séquences et facilite le traitement de longs historiques. Il permet aussi au transformeur d’opérer sur des schémas locaux récurrents plutôt que de traiter chaque mesure comme un élément sans lien avec les autres.

TimesFM-3 organise ces tokens sur deux dimensions. L’une représente le temps. L’autre représente les différentes séries cibles et covariables incluses dans la requête.

Le transformeur alterne entre deux opérations d’attention. L’attention temporelle causale examine les segments antérieurs au sein d’une série. « Causale » signifie que le modèle ne peut pas examiner des valeurs cibles futures inconnues lorsqu’il forme une prédiction.

L’attention complète entre variables fonctionne entre les séries à la même position temporelle. Elle permet à une cible de tirer des informations d’autres cibles et covariables. C’est ainsi qu’un calendrier de promotions peut influencer la prévision de ventes associée.

Les covariables passées-futures reçoivent un traitement spécial par anticipation. Chaque token combine son segment actuel avec des segments futurs contenant des informations déjà connues. Le modèle peut donc voir les événements programmés sans se voir révéler les résultats futurs de la cible.

Cette distinction est essentielle. Un calendrier futur de jours fériés constitue une entrée valide parce que les dates sont déjà connues. Les ventes réelles de demain ne constituent pas une entrée valide, car les révéler reviendrait à divulguer la réponse.

Google Research a également modifié le processus de décodage. Les anciens modèles TimesFM généraient les segments de prévision de manière séquentielle. Chaque segment prédit devenait le contexte permettant de produire le suivant.

La génération séquentielle présente deux faiblesses. Elle accroît la latence, car chaque étape attend l’étape précédente. Elle permet également à une erreur de prédiction précoce d’influencer tous les segments suivants.

TimesFM-3 utilise à la place un masquage de segments contigus. Le système ajoute des espaces réservés masqués couvrant l’ensemble de l’horizon de prévision, puis prédit ces positions lors d’un seul passage avant.

Les covariables futures connues restent visibles tandis que les valeurs cibles demeurent masquées. L’alternance entre attention temporelle et attention entre variables traite le contexte combiné. Le modèle remplit l’horizon de prévision sans boucle de génération itérative.

Cette conception non autorégressive, c’est-à-dire qu’elle ne produit pas l’horizon morceau par morceau, est au cœur de l’affirmation de performance de Google. Les horizons plus longs ne nécessitent plus un nombre proportionnellement plus élevé de cycles de décodage.

Le mécanisme modifie également ce que les utilisateurs doivent mesurer. La latence brute du modèle devient importante, mais l’utilisation mémoire et la montée en charge sur un grand nombre de variables le sont tout autant. La prévision conjointe peut intégrer davantage de séries dans chaque requête, augmentant la quantité de calcul liée à l’attention.

Le dépôt public TimesFM inclut des exemples pour des entrées univariées de longueur variable et des tableaux multivariés. Il présente aussi des entrées distinctes pour les covariables uniquement passées et les covariables passées-futures.

Ces exemples mettent en évidence une exigence pratique. Les utilisateurs doivent aligner chaque cible et chaque covariable sur une chronologie cohérente. Des observations manquantes, des remontées tardives et des fréquences incompatibles peuvent compromettre le résultat avant même le début de l’inférence.

Prenons une charge de travail d’observabilité. L’utilisation CPU peut arriver chaque minute, les données de facturation chaque heure et les marqueurs de déploiement uniquement lors des mises en production. Les combiner impose des choix de rééchantillonnage et de traitement des valeurs manquantes.

Les cas d’usage dans la santé et la finance ajoutent des contraintes plus strictes. Les équipes doivent déterminer si une variable externe aurait réellement été disponible au moment de la prédiction. Dans le cas contraire, un benchmark peut sembler précis parce qu’il a accidentellement utilisé des informations futures.

Présenter TimesFM simplement comme un transformer plus grand manque l’essentiel. Sa taille n’a augmenté que modestement depuis TimesFM-2.5, tandis que le corpus de préentraînement a dépassé un trillion de points. Le changement plus profond réside dans la façon dont l’architecture représente les relations et produit l’horizon.

Cette conception rend le modèle Google TimesFM plus pertinent pour la planification opérationnelle. Elle rend aussi l’évaluation plus difficile. La réussite dépend désormais de la réalité, de la stabilité, du bon horodatage et de l’utilité décisionnelle des relations fournies.

Les benchmarks ne tranchent pas la question de la production

Google annonce des résultats de premier rang sur trois benchmarks publics, mais les licences et la validation indépendante limitent ce que les adoptants peuvent en conclure aujourd’hui.

Google a évalué TimesFM-3 sur GIFT-Eval, FEV-Bench et TIME. Ces suites couvrent des jeux de données, des tâches de prévision, des horizons et des paramètres d’évaluation différents.

L’entreprise indique que TimesFM-3 s’est classé premier parmi les modèles de fondation préentraînés, tant pour les prévisions ponctuelles que probabilistes. Elle affirme également que le modèle a dominé FEV-Bench sur 100 tâches réelles et le benchmark TIME sur 98 tâches issues de 50 domaines.

GIFT-Eval propose un autre test étendu de prévision zero-shot. Google affirme que TimesFM-3 s’y est classé premier parmi les modèles de fondation inclus dans cette comparaison.

Le modèle serait resté compétitif en mode univarié, où il ne pouvait exploiter ni covariables ni informations inter-séries. L’activation du mode multivarié complet a encore amélioré son rang moyen.

Ces résultats constituent des signaux significatifs, car ils testent la capacité d’un modèle préentraîné unique à se transférer sur des jeux de données variés. Ils comparent également TimesFM-3 à des systèmes récents, notamment Chronos-2, Toto 2.0 et TimesFM-2.5.

Cependant, le rang moyen condense de nombreux résultats en un seul chiffre. Il ne révèle pas si le modèle l’emporte sur les séries, les horizons et les coûts d’erreur qui comptent pour une organisation donnée.

Un planificateur de supermarché peut surtout se préoccuper des erreurs avant les pics de vacances. Un ingénieur en capacité peut se soucier des événements de trafic extrêmes manqués. Une équipe finance peut accorder davantage de valeur à une incertitude bien calibrée qu’à une faible amélioration moyenne.

Les benchmarks publics peuvent également différer des données de production. Les séries métier comportent des ruptures de stock, des changements de politique, des lacunes de reporting, des lancements de produits et des chocs ponctuels. Les relations apprises à partir de l’historique peuvent échouer lorsque ces conditions changent.

L’angle sceptique le plus fort concerne l’accès. Le code source du dépôt est sous licence Apache 2.0, et les poids des modèles jusqu’à TimesFM-2.5 conservent cette licence. Les poids de TimesFM-3 utilisent une licence non commerciale distincte.

Cette licence restreint les poids préentraînés TimesFM-3 fournis par défaut à des usages non commerciaux et hors production. Une entreprise peut étudier l’architecture et mener des expériences autorisées, mais ne peut pas supposer que le checkpoint téléchargé est déployable dans un flux de travail générant des revenus.

Cela crée un écart net entre disponibilité technique et disponibilité opérationnelle. Le modèle est public, mais son chemin de production le plus immédiat demeure sous le contrôle de Google.

Le dépôt avertit également que sa version ouverte n’est pas un produit Google officiellement pris en charge. Les développeurs doivent donc distinguer le code accessible à la communauté d’un service assorti d’engagements de support d’entreprise.

L’intégration à BigQuery peut résoudre une partie de la question du déploiement. Google indique que cette intégration arrivera dans les semaines suivant la sortie. Ses conditions, sa disponibilité géographique, ses quotas, les entrées prises en charge et son comportement en production seront déterminants.

Une prise en charge antérieure de TimesFM existe déjà via la fonction AI.FORECAST de BigQuery. Cette interface abaisse la barrière pour les utilisateurs SQL, mais la prise en charge de TimesFM-3 devra être vérifiée après son déploiement.

La sortie ne dispose pas non plus du type de preuves de production indépendantes qui s’accumulent avec le temps. Les utilisateurs publics n’ont eu que quelques jours pour tester le comportement multivarié, les besoins mémoire, les modes de défaillance et la sensibilité aux choix de covariables.

Même le chiffre de Google d’un trillion de points d’entraînement laisse des questions sans réponse. La sortie décrit un mélange de séries temporelles réelles et synthétiques, mais ne fournit pas un inventaire complet du corpus. Les utilisateurs ne peuvent pas juger pleinement de la couverture des domaines à partir de la seule échelle.

Le modèle initial utilisait notamment les données Google Trends et les données de pages vues de Wikipedia parmi ses sources publiques. Ces jeux de données contiennent des motifs temporels utiles, mais on ne peut pas présumer de la similarité entre ces motifs et les opérations internes d’une entreprise.

Les prédictions par quantiles nécessitent également une validation. Produire neuf estimations d’incertitude ne garantit pas que leurs intervalles soient calibrés dans un nouveau domaine. Les équipes devraient vérifier à quelle fréquence les résultats réels se situent dans chaque plage prédite.

Le test pratique est donc comparatif. Les organisations devraient évaluer TimesFM-3 face à TimesFM-2.5, Chronos-2, Toto, des références statistiques et leurs modèles de production actuels, en utilisant les mêmes découpages temporels.

Elles devraient également noter les décisions générées par chaque prévision. Un faible gain statistique peut avoir peu de valeur si l’inférence est plus difficile, les covariables peu fiables ou la licence bloque le déploiement.

Les benchmarks de Google justifient une évaluation sérieuse. Ils ne justifient pas le remplacement d’un système de production sans tests locaux, garde-fous opérationnels et droits d’utilisation clairs.

Ce qu’il faudra surveiller après la publication de Google Research

Trois signaux détermineront si TimesFM-3 devient une couche de prévision largement utilisée ou reste un checkpoint de recherche influent.

Le premier signal est l’intégration promise à BigQuery. La disponibilité via SQL offrirait aux analystes un accès direct aux prévisions multivariées à proximité des données déjà présentes dans l’entrepôt.

Les détails de l’implémentation révéleront quelle part de TimesFM-3 atteint les utilisateurs de services gérés. Les acheteurs devraient surveiller la prise en charge de cibles multiples, de covariables historiques, de covariables futures connues, de sorties par quantiles et d’horizons de prévision réalistes.

Les conditions tarifaires comptent également, même si l’évaluation initiale devrait se concentrer sur l’adéquation à la charge de travail plutôt que sur le coût affiché. La latence, les quotas, la disponibilité régionale et les contrôles de gouvernance des données détermineront si les équipes peuvent utiliser le service de manière répétée.

Une large prise en charge dans BigQuery renforcerait la position de Google, car elle transformerait une sortie de recherche en infrastructure accessible. Une intégration retardée ou limitée laisserait une ouverture aux concurrents et aux fournisseurs indépendants de prévision.

Le deuxième signal est la reproduction indépendante des benchmarks. Chercheurs et praticiens doivent confirmer le classement annoncé avec des jeux de données fixes, des règles d’évaluation identiques et des conditions de calcul comparables.

Une attention particulière devrait être accordée aux tâches multivariées pour lesquelles des covariables futures utiles sont disponibles. Ces cas testent l’affirmation centrale de TimesFM-3 plutôt que ses performances univariées rétrocompatibles.

Les évaluateurs devraient également publier des résultats au niveau des tâches, et pas seulement des rangs moyens. Ce détail montrera où TimesFM-3 rencontre des difficultés et si ses gains se concentrent sur des domaines ou des horizons particuliers.

Des tests impliquant des valeurs manquantes, des changements de régime, des covariables bruitées et un grand nombre de séries liées offriraient davantage de pertinence pour la production. Ils pourraient affaiblir le dossier de Google si les performances dépendent d’entrées exceptionnellement propres.

Le troisième signal est le statut commercial des poids préentraînés. Une licence plus large permettrait à davantage d’organisations de déployer le checkpoint dans leur propre infrastructure. Des restrictions maintenues orienteraient l’adoption commerciale vers les services Google gérés.

Ce choix influence la carte concurrentielle. Chronos-2, Toto, Moirai et des modèles de prévision plus petits peuvent gagner du terrain lorsque leurs conditions d’accès correspondent mieux aux exigences de déploiement privé.

Les développeurs devraient examiner la licence du modèle avant de bâtir un produit autour du checkpoint. La disponibilité publique ne prévaut pas sur les restrictions énoncées.

Les équipes peuvent néanmoins utiliser cette sortie pour poser de meilleures questions techniques. Les informations inter-séries améliorent-elles la précision après des contrôles stricts contre les fuites de données ? Les événements futurs connus entraînent-ils des changements cohérents ? Les prévisions par quantiles sont-elles calibrées pendant des périodes inhabituelles ?

Une évaluation utile devrait préserver un jeu de validation temporel, comparer des références simples et calculer des coûts propres à chaque décision. Les équipes devraient documenter quelles covariables étaient réellement connues à chaque point de prédiction historique.

Elles devraient également conserver le modèle crédible le plus simple. Si une référence saisonnière offre des performances comparables, le modèle de fondation ajoute de la complexité sans bénéfice suffisant. Si TimesFM-3 l’emporte régulièrement, cela justifie un flux de travail de prévision différent.

Google Research a défendu l’idée que les modèles de prévision généralistes devraient comprendre des variables connectées et générer efficacement des horizons complets. Il n’a pas encore tranché la question de la manière dont ses poids les plus performants seront accessibles à la production.

Les prochains mois montreront si disponibilité gérée, résultats indépendants et licences convergent. D’ici là, TimesFM-3 doit être considéré comme une sortie d’architecture importante et un candidat au déploiement soigneusement encadré.

Pour les développeurs et les équipes data, l’action immédiate est simple : choisissez un problème de prévision conséquent, construisez une évaluation protégée contre les fuites de données et testez le modèle face au système qui prend déjà les décisions. TimesFM-3 améliore-t-il le résultat auquel votre organisation accorde réellement de la valeur ?