Quels foundation models pour séries temporelles choisir ?

Résumer ce contenu avec :

Perplexity ChatGPT Claude Grok Mistral

Les foundation models pré-entraînés pour séries temporelles permettent des prévisions zero-shot et probabilistes multi-pas, utilisables sans entraînement spécifique. Chronos-2, TiRex, TimesFM, IBM Granite TTM R2 et Toto Open Base couvrent la plupart des cas d’usage selon contraintes de précision, latence et multivariance (sources : Hugging Face, Google Research, IBM).

Pourquoi opter pour des foundation models en forecasting

Les foundation models pour séries temporelles sont des modèles pré-entraînés sur de larges corpus de séries qui apprennent des motifs globaux (saisonnnalité, relations entre séries, effets de calendrier) et permettent un transfert direct sur de nouvelles séries sans entraînement local massif.

• Définition simple. Les modèles sont pré-entraînés de manière massive (apprentissage auto-supervisé ou supervisé sur des milliers à centaines de milliers de séries), puis utilisés en zero-shot (prévisions directes sur une nouvelle série) ou few-shot (quelques séries/épisodes d’ajustement) pour transférer la compétence de forecasting.
• Avantages concrets. Gain de temps : possibilité de prototyper et déployer des prévisions sans collecte d’étiquettes dédiée, ce qui peut réduire des semaines de travail en production. Robustesse aux séries courtes : le modèle exploite le signal appris globalement plutôt que d’attendre 2–3 saisons de données. Capacités probabilistes : sortie de quantiles utiles pour la gestion des risques (par ex. quantiles 0.1/0.5/0.9). Mémoire longue et multi-pas : architectures basées sur Transformers ou architectures récurrentes améliorées gèrent des contextes longs et produisent des prévisions multi-horizons simultanées.
• Limites importantes. Biais de pré-entraînement : performances amoindries si votre domaine est hors distribution du corpus d’entraînement. Besoin de covariables connues : la plupart des modèles exigent les covariables futures (prix promotionnel, calendrier) pour de bonnes prévisions. Performance variable : certains cas métiers très spécifiques requièrent un fine-tuning pour atteindre l’exactitude attendue.
• Termes clés expliqués.
  • Zero-shot : capacité à prédire sur une tâche/une série sans entraînement supplémentaire.
  • Few-shot : adaptation rapide avec quelques exemples étiquetés.
  • Quantiles : valeurs de seuil d’une distribution (ex. 0.9 = valeur sous laquelle on attend 90% des observations), utilisées pour l’incertitude.
  • Univariate vs Multivariate : univariée = une variable temporelle; multivariée = plusieurs séries ou séries + covariables.
  • Horizon : nombre de pas de temps à prévoir (ex. horizon = 24 pour 24 heures).
  • Contexte : fenêtre historique utilisée pour prédire l’avenir.
  • Inference CPU/GPU : inference sur CPU est pratique pour faibles débits, GPU accélère gros modèles et faibles latences.

Pour approfondir, consulter des travaux et outils établis comme DeepAR (Amazon) (https://arxiv.org/abs/1704.04110), Temporal Fusion Transformers (Google) (https://arxiv.org/abs/1912.09363), N-BEATS (https://arxiv.org/abs/1905.10437), la boîte à outils GluonTS (https://ts.gluon.ai/) et le répertoire time-series de Hugging Face (https://huggingface.co/topics/time-series). Pour des benchmarks historiques, voir M4 (https://www.m4.unic.ac.cy/) et les compétitions M5 (https://www.kaggle.com/c/m5-forecasting-accuracy).

Quels sont les modèles clés et leurs différences

Read moreComment l'IA réinvente le performance marketing ?

Je compare les modèles clés pour séries temporelles en me focalisant sur l’architecture, la taille, les capacités de covariables, le type de sortie, la longueur de contexte et les cas d’usage recommandés.

Chronos-2: Architecture decoder-only optimisée pour génération et forecasting auto-régressif. Taille approximative : petite à moyenne (~50–200M paramètres). Supporte séries univariées et multivariées, avec covariables passées ; support des covariables futures limité selon le checkpoint (voir Hugging Face / repo). Sortie : ponctuelle et souvent quantiles via head dédié. Contexte typique : quelques centaines de pas ; horizon : court à moyen. Inference : efficace sur GPU, utilisable sur CPU pour batchs réduits. Cas d’usage : déploiement cloud, prévisions à fréquence haute (min/heure) (source : Hugging Face / article projet).

TiRex: Architecture xLSTM (Long Short-Term Memory étendu) conçue pour capturer dépendances longues. Taille approximative : moyenne (~100–300M paramètres). Supporte fortement multivarié et covariables passées/futures explicites. Sortie : quantiles et ponctuelle. Contexte typique : centaines à milliers de pas ; horizon : moyen à long. Inference : plus coûteuse CPU, optimisée GPU. Cas d’usage : séries industrielles avec dépendances longues et besoins d’uncertainty (source : repo officiel / paper).

Read moreClaude Code vs Codex

TimesFM: TinyTimeMixers / attention cross-time, architecture hybride mixer/transformer. Taille approximative : très petite à petite (~5–50M paramètres). Supporte univarié et multivarié léger, covariables passées et futures basiques. Sortie : ponctuelle/quantiles selon configuration. Contexte typique : court (≤512) ; horizon : court. Inference : très efficace sur CPU et edge. Cas d’usage : prototypes rapides et devices contraints (source : Hugging Face / docs).

IBM Granite TTM R2: Architecture encoder-only orientée tabulaire + time-to-event (TTM = time-to-moment). Taille approximative : moyenne à grande (~200–600M paramètres). Supporte multivarié, covariables complètes passées/futures, sorties probabilistes (quantiles, distribution). Contexte typique : long ; horizon : moyen à long. Inference : GPU recommandé en production. Cas d’usage : finance, maintenance prédictive à forte exigence d’uncertainty (source : IBM Research / publication).

Toto Open Base: Large-scale decoder-only généraliste, architecture proche LLM adaptés au temporel. Taille approximative : large (>500M paramètres). Supporte multivarié et intégration riche de covariables futures via prompts. Sortie : ponctuelle, possibilité quantiles via fine-tuning. Contexte typique : très long ; horizon : long/épisodique. Inference : GPU/TPU requis pour latence faible. Cas d’usage : analyses à large échelle, transfert learning (source : repo GitHub / model card).

Read moreMCP : comment sécuriser l'accès des modèles aux outils ?

Notes pratiques : Vérifier les checkpoints et model cards sur Hugging Face ou les repos GitHub des projets pour chiffres exacts et téléchargements (Hugging Face / GitHub). Indiquer la popularité via les stars/downloads directement sur ces pages pour une mesure fiable. Fournir des sources précises (paper ou model card) pour chaque affirmation lors de la rédaction finale.

Synthèse courte : Pour prototype rapide privilégier TimesFM (léger). Pour production haute échelle privilégier Toto Open Base ou IBM Granite TTM R2 selon besoin d’incertitude. Pour edge/contraintes choisir TimesFM ou Chronos-2 selon latence et précision.

Comment choisir et déployer en production

Choisir et déployer un foundation model pour séries temporelles demande d’abord de confronter les besoins métier aux contraintes techniques : nature des séries, exigences probabilistes, latence et confidentialité. Voici un guide opérationnel prêt à l’emploi.

• Checklist de décision : Déterminer si vos séries sont univariées ou multivariées (une seule variable vs plusieurs variables dépendantes).
• Estimer la longueur d’horizon (prévisions court terme < 24h vs long terme > semaines).
• Vérifier la disponibilité de covariables futures (features prévisibles comme calendrier ou météo).
• Prendre en compte les contraintes matérielles (CPU uniquement vs GPU disponible) et le coût par requête.
• Évaluer la confidentialité des données pour décider on-premise vs cloud.

• Stratégie de déploiement : Commencer en zero-shot si modèle public covere votre domaine, puis passer au few-shot/fine-tuning si besoin.
• Fine-tuner quand l’erreur relative dépasse vos SLAs ou quand pattern locaux ne sont pas captés ; prévoir typiquement 10k–100k timesteps ou quelques centaines de séries pour un fine-tuning utile.
• Tester en parallèle avec tests A/B en production : mesurer MAE/RMSE et métriques probabilistes avant bascule.

• Aspects techniques : Format d’entrée = séquence temporelle + covariables temporelles + features statiques. Normaliser par série (z-score) ou global selon variance.
• Gérer valeurs manquantes par imputation simple (ffill, median) ou modélisation (mask + embedding).
• Utiliser fenêtres glissantes (sliding windows) pour entraîner et inferer de façon efficace.

• Optimisation d’inférence : Appliquer quantization INT8 pour réduire la mémoire (~3–4×) et accélérer inference CPU.
• Batcher les requêtes pour amortir coût GPU/CPU et utiliser Triton ou TorchServe pour serving scalable.
• Mettre en cache embeddings ou précomputations pour séries stables afin de réduire latence.
• Attendre latences typiques : CPU 50–500 ms/serie, GPU 5–50 ms/serie selon batch.

• Monitoring et validation : Surveiller MAE/RMSE pour point estimates, CRPS (Continuous Ranked Probability Score) pour probabiliste — CRPS mesure la qualité d’une distribution prédite.
• Contrôler coverage des quantiles (p.ex. 90% interval coverage) et détecter dérive via tests statistiques (KS, PSI).
• Mettre en place alerting et tests d’intégrité (schema checks, drift alerts).

• Exemple d’architecture intégrée : Ingestion (Kafka) → Feature store (Feast ou équivalent) → Prétraitement → Serving model (Triton/TorchServe) → Dashboarding (Grafana) avec capacité de rollback.

Read morePourquoi les token economics rendent l'IA moins chère ?

// Exemple input JSON
{
  "series_id": "s_123",
  "timestamps": ["2026-04-01","2026-04-02"],
  "values": [120.5, 118.3],
  "covariates": {"promo": [0,1], "temp": [15.2, 14.8]}
}

Consulter les pages pratiques : Hugging Face model hub (https://huggingface.co), Google Research (https://research.google) et IBM Developer (https://www.ibm.com) pour guides et modèles.

• Plan d’action en 5 étapes pour un POC :
• Collecter un échantillon représentatif (quelques centaines de séries ou 10k timesteps).
• Tester zero-shot avec un modèle public et mesurer MAE/CRPS.
• Fine-tuner sur un sous-ensemble si gain attendu (prévoir 1–2 jours GPU pour POC).
• Déployer en blue/green avec monitoring, puis itérer.

Exemples pratiques et snippets d’inférence

Je montre ici des exemples pratiques pour lancer du zero-shot et un fine-tuning léger sur des foundation models pour séries temporelles, avec snippets en Python utilisables comme point de départ.

Zero-shot minimal (Hugging Face + PyTorch)

# Exemple d'illustration : récupérer checkpoint depuis Hugging Face et faire une passe forward
from huggingface_hub import snapshot_download
import torch
import numpy as np

# Télécharger le repo du modèle (remplacez par le repo réel, ex: 'org/chronos-2')
repo_dir = snapshot_download(repo_id="org/chronos-2")

# Charger un fichier checkpoint PyTorch (illustratif)
ckpt = torch.load(f"{repo_dir}/pytorch_model.bin", map_location="cpu")
# Ici j'instancie le modèle selon l'implémentation fournie par le repo
model = MyChronosModel()  # Remplacer par la classe réelle
model.load_state_dict(ckpt)
model.eval()

# Préparer les données d'entrée : liste de valeurs + covariables optionnelles
series = np.array([100.0, 101.2, 99.8, 102.5])  # univarié
covariates = None  # ou np.array([...])

# Tensoriser et batcher
x = torch.tensor(series, dtype=torch.float32).unsqueeze(0)  # shape (1, T)
if covariates is not None:
    cov = torch.tensor(covariates, dtype=torch.float32).unsqueeze(0)

with torch.no_grad():
    out = model(x, covariates=cov if covariates is not None else None)
# Interpréter sortie : par ex. dict avec quantiles et forecast ponctuel
# out['q0.1'], out['q0.5'] (médiane), out['q0.9'], out['mean_forecast']

Fine-tuning few-shot (IBM Granite TTM R2) — pseudo-code

# Préparer un dataset few-shot, entraînement court
# 1) Construire dataset (input windows -> target horizon)
# 2) DataLoader, batch_size petit (8-32)
# 3) Optimiseur léger (AdamW), lr faible (1e-4)
# 4) Quelques epochs (3-10) pour adaptation rapide

for epoch in range(5):
    for x_batch, y_batch in train_loader:
        optimizer.zero_grad()
        preds = model(x_batch)  # modèle Granite
        loss = loss_fn(preds, y_batch)
        loss.backward()
        optimizer.step()
    # évaluation rapide sur validation set
    val_metrics = evaluate(model, val_loader)
    print(f"Epoch {epoch}: val {val_metrics}")

TimesFM pour longues séquences — chunking & concaténation

# Chunker la séquence en fenêtres glissantes et concaténer prédictions multi-pas
def chunk_sequence(seq, window, stride):
    return [seq[i:i+window] for i in range(0, len(seq)-window+1, stride)]

windows = chunk_sequence(series, window=1024, stride=512)
all_preds = []
for w in windows:
    x = torch.tensor(w).unsqueeze(0)
    p = timesfm_model(x)  # multi-step output
    all_preds.append(p.numpy())

# Stitching : aligner chevauchements en moyenne pondérée
final_forecast = stitch_predictions(all_preds)

• Conseils d’engineering : Batcher plusieurs séries pour amortir overhead CPU/GPU.
• Conseils d’engineering : Préférer GPU pour modèles >200M paramètres ; utiliser CPU pour inférences légères ou quantisées.
• Conseils d’engineering : Quantization avec torch.quantization (post-training) ou exporter en ONNX et utiliser ONNX Runtime avec quantization.
• Conseils d’engineering : Estimation ressources — règle empirique : 500M paramètres ≈ 2-4GB VRAM pour l’inférence (float32 pour les poids = ~2GB, activations ajoutent mémoire).

Prêt à expérimenter un foundation model sur vos séries temporelles ?

J’ai synthétisé les forces et limites des principaux foundation models pour séries temporelles : Chronos-2 et TiRex pour des déploiements zero-shot rapides, TimesFM pour des horizons longs univariés à grande échelle, IBM Granite TTM R2 pour l’edge et les contextes multivariés compacts, et Toto Open Base pour monitoring haute-dimension. Choisir dépendra de votre besoin : latence, multivariance, disponibilité des covariables et budgets GPU. En testant d’abord en zero-shot puis en few-shot si nécessaire, vous réduisez le time-to-value et validez le modèle avant investissement. Bénéfice : accélérer vos prévisions opérationnelles sans repartir à zéro.

FAQ

• Qu’est-ce que le zero-shot forecasting et pourquoi ça marche ?
  Le zero-shot forecasting consiste à utiliser un modèle pré-entraîné sur de larges collections de séries pour prévoir de nouvelles séries sans entraînement spécifique. Ça marche grâce au transfert appris lors du pré-entraînement et à des architectures capables de généraliser les motifs temporels (voir pages modèles sur Hugging Face et articles de recherche cités).
• Quand faut-il fine-tuner un modèle plutôt que d’utiliser le zero-shot ?
  Je recommande le fine-tuning si vos séries ont des caractéristiques très spécifiques (saisonnnalité inédite, distribution d’erreur atypique) ou si l’amélioration de précision justifie le coût compute. Faire d’abord un test zero-shot, puis few-shot pour valider le gain.
• Quel modèle choisir pour des séries multivariées et contraintes d’edge ?
  Pour l’edge et contraintes de ressources, IBM Granite TTM R2 (TinyTimeMixers) est adapté : compact, rapide et performant en zero/few-shot. Pour multivariable haute-dimension sur infrastructure, Toto Open Base peut être privilégié.
• Comment évaluer des prévisions probabilistes ?
  Utilisez des métriques adaptées : CRPS (Continuous Ranked Probability Score) pour distributions, coverage et largeur d’intervalles de confiance, et MAE/RMSE pour comparaisons ponctuelles. Monitorer la couverture empirique des quantiles en production.
• Quelles sont les contraintes hardware pour déployer ces modèles ?
  Les besoins varient : les modèles ~500M paramètres demandent typiquement quelques GB de VRAM (2–8GB selon optimisation), tandis que les modèles tiny (≈1M) peuvent tourner sur CPU ou edge. Prévoir quantization ou ONNX pour réduire l’empreinte et latence.

A propos de l’auteur

Franck Scandolera — expert & formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA  ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.