Les modèles de fondation pour séries temporelles expliqués : Timestral vs TimesFM-3 en production

Toutes les équipes opérationnelles effectuent des prévisions. Une usine anticipe le comportement de ses pompes et compresseurs pour le prochain quart de travail. Un détaillant prévoit la demande. Une entreprise énergétique anticipe la charge. Pendant des décennies, chacune de ces prévisions impliquait de construire un modèle pour un jeu de données spécifique, puis de le maintenir à mesure que les données évoluaient.

Les modèles de fondation pour séries temporelles adoptent une approche différente. Pré-entraînés sur de très vastes collections de séries temporelles, ils peuvent prévoir des données inédites sans aucun entraînement de votre côté. En l'espace de six semaines, deux des modèles les plus performants ont vu le jour :

• TimesFM-3 de Google Research, publié le 31 août 2026.
• Timestral de Mistral AI, publié le 15 octobre 2026.

Cet article utilise ces deux modèles comme études de cas pour illustrer trois évolutions majeures dans le domaine de la prévision :

1. De la série unique à la prévision multivariée.
2. Des prédictions ponctuelles aux prévisions probabilistes.
3. Des modèles de recherche aux systèmes déployables, où le matériel, la longueur de contexte, les licences et la gouvernance des données comptent autant que la précision.

Tout au long de cet article, nous suivrons un exemple concret : la maintenance prédictive d'une pompe industrielle.

De l'ARIMA aux modèles de fondation

Méthodes classiques comme ARIMA et le lissage exponentiel, ajustent un modèle par série. Ils sont rapides, interprétables et difficiles à battre sur des signaux saisonniers simples, mais chaque série nécessite son propre modèle. Modèles d'apprentissage profond comme DeepAR ou PatchTST, apprennent à partir de nombreuses séries, mais ils sont généralement entraînés à partir de zéro pour chaque jeu de données.

Modèles de fondation appliquent l'approche de pré-entraînement des LLM aux données numériques. TimesFM-3 a été pré-entraîné sur plus de mille milliards de points temporels, et la majeure partie des données d'entraînement de Timestral est synthétique. Vous fournissez l'historique récent et obtenez une prévision en mode « zero-shot ». Ces modèles sont également bien plus petits qu'un LLM : 5 millions de paramètres pour le plus petit Timestral, 330 millions pour TimesFM-3.

Cette taille reflète une tâche différente. Un modèle de séries temporelles produit des prédictions calibrées sur des milliers de relevés, de manière économique et répétée. Un LLM est plus performant pour ce qui suit : relier une prévision à des notes de maintenance et l'expliquer. Les systèmes de production fonctionnent mieux lorsque chaque tâche est confiée au modèle conçu pour elle, l'argument que nous avons avancé dans Arrêtez d'utiliser votre LLM pour tout.

Ce qui a changé en 2026

Les prévisions sont devenues multivariées. La vibration d'une pompe, la température des roulements et la pression de refoulement n'évoluent pas indépendamment : une hausse de l'une explique ou précède souvent un changement dans une autre. Les modèles multivariés prévoient conjointement les séries liées et apprennent ces dépendances, au lieu de traiter chaque capteur isolément.

Les covariables sont devenues des entrées natives. La prévision peut utiliser des signaux qui ne sont pas eux-mêmes prévus. Les deux modèles acceptent des covariables passées uniquement et des covariables connues pour le futur. Timestral accepte également directement des entrées catégorielles, comme l'état planifié d'une machine. Google ne documente pas les covariables catégorielles pour TimesFM-3, bien que Chronos-2 d'Amazon les prenne également en charge.

Les prévisions sont devenues probabilistes. Au lieu d'affirmer que la température des roulements sera de 78 °C demain, le modèle renvoie une distribution des valeurs probables. Cela change la nature d'une alerte. Si la prévision du 90e percentile dépasse la limite d'alarme dans 18 heures alors que la médiane reste en dessous, vous disposez d'un avertissement précoce et quantifié qu'un chiffre unique masquerait.

Deux façons de prévoir l'avenir : TimesFM-3 vs Timestral

Les deux modèles divisent chaque série en segments de 32 pas de temps, traitent les données à travers le temps et les séries, et prévoient de nombreuses étapes en un seul passage. Là où ils diffèrent, c'est dans la manière dont ils représentent le futur qu'ils doivent prédire.

TimesFM-3 : espaces réservés masqués pour l'horizon

TimesFM-3 est un modèle unique de 330 millions de paramètres et le premier TimesFM nativement multivarié. Jusqu'à la version 2.5, chaque série était prévue uniquement à partir de son propre historique.

Ses couches alternent entre une attention causale temporelle et une attention complète sur l'ensemble des séries, tandis que les covariables dont le futur est connu intègrent leurs valeurs à venir. Pour effectuer des prévisions, il ajoute des espaces réservés masqués pour l'ensemble de l'horizon et les remplit en un seul passage. Google appelle cela Contiguous Patch Masking. Cela remplace la génération patch par patch des versions précédentes, qui ajoutait de la latence et cumulait les erreurs.

Timestral : des jetons distincts pour lire l'historique

Timestral est une famille de quatre modèles, 5M, 28M, 123M et 209M de paramètres, partageant une architecture et une méthode d'entraînement communes. La contribution principale de Mistral est le Decoupled Horizon Forecasting (DHF). Mistral soutient que les valeurs d'horizon masquées ressemblent à des données manquantes et gaspillent du contexte ; le DHF utilise donc des jetons de prévision appris distincts qui lisent l'historique intact à la place.

Chaque entrée se voit également attribuer un rôle, de sorte qu'un calendrier de production peut éclairer la prévision sans divulguer le futur de la cible elle-même. L'entraînement a été principalement synthétique, suivi d'un mélange de données réelles et synthétiques avec un contexte quatre fois plus long. Le rapport technique de Mistral n'étant pas encore publié, les détails présentés ici proviennent de son article de lancementetdépôt.

Benchmarks : quel est leur niveau de performance ?

Au moment du lancement, Google présentait TimesFM-3 comme le meilleur modèle de fondation sur les trois principaux benchmarks publics : GIFT-Eval, fev-bench et TIME. Six semaines plus tard, l'évaluation publiée par Mistral plaçait Timestral-209M légèrement devant TimesFM-3 sur toutes les métriques rapportées, avec moins de paramètres.

Ces chiffres sont à interpréter avec prudence. Les écarts sont faibles : de 1,4 à 2,6 % sur les métriques d'erreur et 1,4 point sur fev-bench. L'avance de Timestral sur le second du classement de Mistral, t0-gamma de The Forecasting Company, est de 0,003 sur le MASE de GIFT-Eval.

Ces chiffres sont également auto-déclarés, le rapport technique de Mistral n'est pas encore disponible et le classement évolue rapidement : TimesFM-3 n'a conservé la première place que pendant six semaines. Les faibles écarts sur les benchmarks globaux ne permettent pas de déterminer quel modèle sera le plus performant sur vos propres données.

Le constat le plus robuste concerne la taille. Selon les résultats de Mistral, Timestral-123M se situe à moins de 0,2 % du modèle 209M, et Timestral-28M surpasse Chronos-2 d'Amazon, un modèle environ quatre fois plus grand, sur GIFT-Eval et TIME. Pour de nombreuses charges de travail, un petit modèle suffit.

Le reste du secteur

Timestral et TimesFM-3 sont deux sorties récentes importantes, mais ne représentent pas l'intégralité de l'état de l'art. Deux autres méritent d'être connus :

• Chronos-2 d'Amazon est un modèle de 120 millions de paramètres avec une prise en charge native des variables multivariées et des covariables, y compris les covariables catégorielles. Il dispose d'un contexte de 8 192 étapes et de poids sous licence Apache 2.0.
• Toto 2.0 de Datadog est disponible dans des tailles allant de 4 millions à 2,5 milliards de paramètres, également sous licence Apache 2.0. Il est largement évalué sur des données d'observabilité.

Ce que les modèles de fondation ne résolvent toujours pas

Les modèles de fondation n'ont pas fait de la prévision un problème résolu. Le document sur Toto 2.0 est franc à ce sujet. Les méthodes classiques conservent des avantages qui font défaut aux modèles de fondation, comme une extrapolation propre sur des signaux simples, et la prévision à long terme reste une lacune.

En pratique, un modèle saisonnier peut toujours l'emporter sur un signal stable et répétitif. Et n'importe quel modèle peut rencontrer des difficultés après un changement de régime, comme une pompe après le remplacement d'un roulement, qui ne ressemble à rien de ce qu'il a connu dans son contexte.

Peut-on réellement les déployer ?

La précision ne signifie pas grand-chose si le modèle ne peut pas fonctionner là où se trouvent vos données, sur votre matériel et sous une licence que vous pouvez accepter.

Matériel et latence. Timestral est conçu pour fonctionner sans GPU. Sur un serveur CPU à 8 threads, Mistral rapporte 17 ms avec le modèle de 5 millions de paramètres et 113 ms avec le modèle de 209 millions pour une prévision d'une journée à partir de trois semaines de données échantillonnées toutes les 15 minutes. Le modèle de 28 millions est 3,6 fois plus rapide que celui de 209 millions.

Le point de contrôle ouvert de TimesFM-3 fonctionne avec PyTorch sur GPU, ou nativement sur Apple Silicon. Sur une puce M4 Max, Google rapporte environ 11 ms pour une série unique avec 512 points de contexte. Ces chiffres proviennent de configurations différentes et ne sont pas directement comparables.

Longueur du contexte. Pour un capteur échantillonné toutes les 15 minutes :

• 2 048 points, la limite de BigQuery pour TimesFM-3, couvrent environ 21 jours.
• 32 768 étapes, la longueur d'entraînement de Timestral, couvrent environ 341 jours.

Si les modèles qui vous intéressent se répètent sur des semaines ou des saisons, cette différence compte plus que n'importe quel score de référence.

Licences. C'est là que les deux modèles diffèrent le plus. Les poids téléchargeables de TimesFM-3 sont publiés sous une licence non commerciale, donc une utilisation en production implique BigQuery. Timestral licence MIT modifiée est gratuit uniquement pour les entreprises réalisant jusqu'à 20 millions de dollars de revenus mensuels, et cette limite s'applique également aux versions affinées. Un modèle peut être léger, téléchargeable et exécutable sur un ordinateur portable, tout en restant inutilisable pour votre entreprise. Les quatre voies ci-dessous présentent ce que chaque option permet.

TimesFM-3 dans BigQuery

Pour les équipes utilisant Google Cloud, BigQuery est la solution la plus simple : aucun modèle à héberger et des prévisions générées directement depuis SQL. Pour les prévisions multivariées, la fonction AI.FORECAST prend en compte les colonnes cibles, les covariables passées et les covariables futures. Voici comment elle prévoit les données des trois capteurs de la pompe pour les 24 prochaines heures :

SELECT *
FROM AI.FORECAST(
  TABLE `plant.pump_sensors_hourly`,
  model => 'TimesFM 3.0',
  timestamp_col => 'reading_ts',
  target_cols => ['vibration_mm_s', 'bearing_temp_c', 'discharge_pressure_bar'],
  past_covariate_cols => ['motor_current_a'],
  future_covariate_cols => ['planned_load_pct', 'planned_stop'],
  id_cols => ['asset_id'],
  horizon => 24,
  confidence_level => 0.9
);

Un détail est facile à oublier : les lignes passées et futures doivent figurer dans la même table d'entrée. Les lignes correspondant à l'horizon de prévision ne contiennent que les horodatages et les covariables futures, tandis que les colonnes cibles et les covariables passées sont définies sur NULL. Le tutoriel multivarié de Google présente la configuration complète. Comme TimesFM-3 ne prend pas en charge les entrées catégorielles, un arrêt planifié est encodé sous forme de colonne indicatrice 0/1.

De la prévision à la décision : un pipeline de maintenance prédictive

Une prévision indique ce qui est susceptible de se produire, mais pas pourquoi. Lorsque la borne supérieure de la température du roulement de la pompe dépasse son seuil d'alerte, au moins cinq facteurs différents entrent en jeu, et un système performant doit les distinguer :

1. Le modèle de prévision prédit une plage probable pour chaque capteur.
2. La règle de surveillance signale que la prévision P90 dépasse une limite.
3. Les dossiers de maintenance suggèrent ce qui s'est produit lors de situations similaires par le passé.
4. Un LLM résume les éléments probants et propose des vérifications, clairement identifiées comme des hypothèses.
5. Un ingénieur confirme la cause et décide de la marche à suivre.

Mistral décrit la même répartition des tâches pour Timestral dans les environnements industriels : le modèle de prévision détecte, un agent recherche les pannes passées et les dossiers de maintenance, et une personne reçoit un projet de diagnostic étayé par des données. L'étape à ne surtout pas négliger est la dernière. Le franchissement d'un seuil est un signal invitant à l'investigation, et non la preuve d'une défaillance imminente.

La place d'Eden AI

Eden AI n'exécute pas la prévision ; celle-ci reste sur votre infrastructure ou dans Google Cloud. Il gère les deux étapes suivantes via une seule clé API :

• Recherche de précédents.L'le point de terminaison rerank identifie les incidents passés les plus similaires à une alerte.
• Rédaction du rapport. Un LLM de votre choix le rédige, et changer de modèle ne nécessite que la modification d'une chaîne de caractères.

Via le point de terminaison européen, les deux requêtes sont envoyées uniquement aux fournisseurs autorisés pour la résidence des données dans l'UE. Un modèle non conforme est refusé plutôt que redirigé silencieusement ailleurs. Notre guide sur le maintien des requêtes et des données d'IA en Europe contient les détails.

Le flux ci-dessous prévoit les données de trois capteurs de pompe simultanément sur un processeur, en utilisant le calendrier de production et l'état planifié de la machine comme entrées prévisionnelles. Il ne fait appel à Eden AI que lorsqu'une prévision dépasse un seuil d'alerte.

import json
import numpy as np
import requests
from timestral import TimestralForecaster  # pip install git+https://github.com/mistralai/timestral.git

EDEN = "https://api.eu.edenai.run/v3"
HEADERS = {"Authorization": "Bearer YOUR_EDENAI_API_KEY"}
SIGNALS = ["vibration_mm_s", "bearing_temp_c", "discharge_pressure_bar"]
ALARM = {"vibration_mm_s": 7.1, "bearing_temp_c": 85.0, "discharge_pressure_bar": 8.5}

# 1. Forecast the next 24 hours of three sensors jointly, on CPU
model = TimestralForecaster.from_pretrained("mistralai/Timestral-28M", device="cpu")

history = np.load("pump7_sensors.npy")        # (3, 2016): three sensors, 3 weeks at 15 min
planned_load = np.load("pump7_load.npy")      # (2112,): production schedule, history + 24 h
planned_state = np.load("pump7_state.npy")    # (2112,): 0 running, 1 idle, 2 maintenance

forecast = model.forecast(
    history[None],                                         # (1, 3, 2016)
    prediction_length=96,                                  # 96 x 15 min = 24 h
    known_covariates=planned_load[None, None],             # (1, 1, 2112)
    categorical_known_covariates=planned_state[None, None],
)
median = np.asarray(forecast.median)[0]       # (3, 96)
p90 = np.asarray(forecast.quantile(0.9))[0]   # (3, 96)

# 2. Alert rule: keep only sensors whose P90 forecast crosses its alarm limit
flagged = []
for i, name in enumerate(SIGNALS):
    hours_above = float((p90[i] > ALARM[name]).sum()) * 0.25
    if hours_above > 0:
        flagged.append({
            "signal": name,
            "last_value": round(float(history[i, -1]), 2),
            "median_peak_24h": round(float(median[i].max()), 2),
            "p90_peak_24h": round(float(p90[i].max()), 2),
            "alarm_limit": ALARM[name],
            "hours_p90_above_limit": hours_above,
        })

if not flagged:
    raise SystemExit("No forecast crosses an alarm limit: no report needed.")

# 3. Find the most similar past incidents (records from your maintenance system)
incidents = [
    {"id": "WO-2291", "text": "Pump 7: bearing temperature rose over two days, lubrication found degraded."},
    {"id": "WO-2410", "text": "Pump 7: vibration spike after impeller cleaning, resolved by rebalancing."},
    # ... more work orders and incident notes for this asset
]
query = "Pump 7: " + ", ".join(f"{f['signal']} forecast above alarm limit" for f in flagged)

ranked = requests.post(f"{EDEN}/rerank", headers=HEADERS, json={
    "model": "cohere/rerank-v3.5",
    "query": query,
    "documents": [r["text"] for r in incidents],
    "top_n": 3,
}).json()
similar = [incidents[r["index"]] for r in ranked["results"]]

# 4. Ask an LLM for a draft report that separates evidence from hypotheses
system = (
    "You draft maintenance reports for engineers. Use only the forecast facts and incident "
    "records provided. Never present a root cause as confirmed. Respond in JSON with the keys: "
    "summary (string), similar_incidents (list of incident ids), "
    "hypotheses (list of strings, each starting with 'Unconfirmed:'), "
    "suggested_checks (list of strings) and needs_human_review (true)."
)
response = requests.post(f"{EDEN}/chat/completions", headers=HEADERS, json={
    "model": "mistral/mistral-large-latest",
    "response_format": {"type": "json_object"},
    "messages": [
        {"role": "system", "content": system},
        {"role": "user", "content": json.dumps({"asset": "pump_7", "forecast": flagged, "incidents": similar})},
    ],
}).json()

report = json.loads(response["choices"][0]["message"]["content"])

# json_object guarantees valid JSON, not these fields: check them in code
required = {"summary", "similar_incidents", "hypotheses", "suggested_checks", "needs_human_review"}
missing = required - report.keys()
if missing:
    raise ValueError(f"Report is missing fields: {missing}")
report["needs_human_review"] = True  # enforced by the pipeline, not left to the model
print(json.dumps(report, indent=2))

Le LLM ne s'exécute qu'en cas d'alerte, ce qui permet d'aligner les coûts sur les événements réels, tandis que l'historique brut des capteurs ne quitte jamais vos systèmes. Deux garde-fous sont intégrés au code plutôt qu'au prompt :

• La révision humaine est systématique. Le pipeline l'impose au lieu de s'en remettre au modèle.
• Les champs du rapport sont vérifiés. Le mode objet JSON garantit un JSON valide, mais pas des champs spécifiques. Sur les modèles qui le prennent en charge, le mode schéma JSON contraint la structure elle-même.

L'étape de rapport nécessite rarement le plus grand modèle disponible. Notre guide sur les SLM par rapport aux LLM en production explique comment choisir.

Comment évaluer un modèle de prévision avant de lui faire confiance

Les benchmarks publics font la moyenne de centaines de jeux de données, et vos pompes peuvent se comporter différemment. Testez sur votre propre historique avant qu'une prévision ne dicte vos opérations de maintenance ou vos achats.

1. Effectuez des backtests à partir de nombreux points de départ. Établissez des prévisions à partir de dizaines de points de coupure passés, en utilisant uniquement les données disponibles à ce moment-là, et comparez-les avec ce qui s'est réellement produit.
2. Surpassez les références simples. Comparez avec une prévision naïve saisonnière (« même période la semaine dernière »), votre méthode actuelle et au moins un modèle de base sous licence Apache 2.0.
3. Évaluez l'incertitude, pas seulement la médiane. Les valeurs réelles doivent se situer dans la bande P10–P90 environ 80 % du temps ; mesurez cela avec le CRPS ou la perte quantile pondérée. Si les alertes utilisent le P90, son étalonnage importe davantage que la précision médiane.
4. Mettez en évidence les points faibles. Analysez les résultats par horizon. Incluez les périodes suivant une maintenance, un remplacement de capteur ou un changement de processus, là où les modèles « zero-shot » peuvent échouer sans signalement.
5. Vérifiez les fuites et les coûts. Une covariable à futur connu doit réellement être connue au moment de la prévision : un plan de production l'est, mais une charge mesurée ne l'est pas. Mesurez la latence à votre volume réel, sur l'ensemble des actifs.

Les petits modèles de Timestral s'exécutent sur le processeur d'un ordinateur portable ; un premier test rétrospectif peut donc être réalisé en un après-midi. Laissez-le tourner en production pour détecter les dérives à mesure que l'équipement vieillit.

Bon à savoir

Les chiffres de référence proviennent de l'article de lancement de Mistral (15 octobre 2026) et de l'annonce de TimesFM-3 par Google Research (31 août 2026) ; aucun n'a fait l'objet d'une reproduction indépendante au moment de la rédaction. TimesFM 3.0 est en préversion dans BigQuery et Timestral est étiqueté en préversion publique ; les interfaces, les limites et les licences sont donc susceptibles d'évoluer. L'exemple en Python suit le dépôt Timestral et la documentation d'Eden AI ; il est conçu comme un point de départ et non comme du code de production. Les résumés des licences reflètent les fiches de modèles publiées au 3 novembre 2026 et ne constituent pas un avis juridique.

Pour aller plus loin

Travaux originaux

• TimesFM-3 : un modèle de fondation « zero-shot » pour la prévision multivariée, Google Research
• Un modèle de fondation « decoder-only » pour la prévision de séries temporelles, l'article original sur TimesFM (ICML 2024)
• Masquage de patchs contigus, la méthode de décodage derrière TimesFM-3
• Présentation de Timestral, Mistral AI, et le dépôt Timestral
• Toto 2.0 : La prévision de séries temporelles entre dans l'ère du passage à l'échelle, Datadog, incluant sa discussion sur les problèmes ouverts
• Fiche du modèle Chronos-2, Amazon
• Classements publics : GIFT-Eval,fev-benchetTIME

Sur le blog d'Eden AI

• Arrêtez d'utiliser votre LLM pour tout : les modèles d'IA spécialisés qui s'imposent en 2027
• Point de terminaison IA dans l'UE : comment conserver les requêtes et les données d'IA en Europe
• AWS Bedrock vs Azure AI Foundry vs Google Vertex AI vs Alibaba Cloud Model Studio, pour la question plus large de l'engagement envers un seul fournisseur cloud

FAQ