Quel outil de prévision séries temporelles choisir ?

Le bon outil dépend moins du score que de votre contexte. Si vous devez expliquer, industrialiser, payer une API ou garder la main sur les modèles, le choix change vite. Je compare Prophet, NeuralProphet, TimeGPT et Chronos avec un angle terrain, pas juste benchmark.

Pourquoi le choix du modèle compte autant ?

Le choix du modèle compte parce qu’une prévision utile doit être fiable, explicable, maintenable et exploitable en production, pas seulement précise sur un test.

Dans un projet business, je ne choisis jamais un outil de forecasting uniquement avec une métrique d’erreur. Une métrique, c’est utile, bien sûr. Mais elle ne dit pas si l’équipe va comprendre le modèle, si le coût va exploser, si le déploiement va tenir, ou si quelqu’un saura corriger le système dans six mois.

Je regarde aussi l’interprétabilité, c’est-à-dire la capacité à expliquer pourquoi le modèle prévoit une hausse ou une baisse. Je regarde la scalabilité, donc la capacité à gérer beaucoup de séries temporelles sans s’écrouler. Je regarde la vitesse de mise en place, le coût, les contraintes de déploiement, la disponibilité des compétences Python dans l’équipe, la présence d’une API, une interface qui permet à deux systèmes de communiquer, et la gestion correcte des saisonnalités, des jours fériés, des pics ou des effets métier.

Sur le terrain, c’est souvent là que la décision se joue. Dans beaucoup de missions, le modèle le plus performant sur le papier n’est pas celui qui passe en production. Il coûte trop cher à maintenir, il demande trop d’expertise, ou il est juste trop difficile à expliquer à un directeur commercial, un contrôleur de gestion ou une équipe supply chain.

Prophet reste souvent le choix simple, open-source et lisible quand on veut modéliser des tendances, des saisonnalités et des jours fériés sans construire une usine à gaz. NeuralProphet va plus loin, avec des lags, donc l’utilisation des valeurs passées, de l’auto-régression, et des covariables via PyTorch, une librairie Python très utilisée pour le deep learning. TimeGPT, lui, pousse une logique différente avec le SDK Nixtla, un kit de développement, et une API pensée pour réduire la configuration. Chronos représente plutôt l’approche foundation model open-weight, donc un modèle pré-entraîné dont les poids sont accessibles, utilisable via Chronos ou AutoGluon TimeSeries.

Outil	Point fort	Compromis principal
Prophet	Simple, lisible, efficace sur tendances, saisonnalités et jours fériés	Moins adapté aux dépendances complexes entre variables
NeuralProphet	Plus riche avec lags, auto-régression et covariables	Demande plus de réglages et de compétences Python
TimeGPT	Rapide à tester via SDK Nixtla et API	Dépendance à un service externe et à son coût
Chronos	Approche foundation model open-weight via Chronos ou AutoGluon TimeSeries	Plus technique à industrialiser proprement

Comment démarrer proprement en Python ?

Je démarre proprement en installant les bibliothèques séparément, en vérifiant les dépendances lourdes et en isolant l’environnement Python.

Le plus simple, c’est de créer un environnement dédié pour vos tests de prévision, puis d’installer uniquement les packages dont vous avez besoin. Ça évite le classique “ça marchait hier” parce qu’une dépendance a changé quelque part. En pratique, je fais un environnement par benchmark, surtout quand je teste AutoGluon ou Chronos, qui peuvent tirer pas mal de dépendances derrière eux.

Pour une première mise en route, les installations ressemblent à ça :

pip install prophet
pip install neuralprophet
pip install nixtla
pip install chronos-forecasting
pip install autogluon.timeseries

Prophet et NeuralProphet se testent assez facilement en local. Vous partez d’un DataFrame avec deux colonnes principales : une colonne de date, souvent appelée ds, et une colonne de valeur, souvent appelée y. C’est basique, mais c’est justement pratique pour valider vite une idée.

TimeGPT, lui, passe par le SDK Nixtla. Un SDK, c’est juste la bibliothèque Python qui permet d’appeler le service. Il faut aussi une clé API, donc on est sur une logique un peu différente : une partie du calcul passe par un service externe. Chronos peut être testé via le package Chronos directement, ou via AutoGluon TimeSeries si vous voulez une couche plus haut niveau, plus automatisée, avec moins de code modèle à gérer.

Avant de comparer quatre modèles, je nettoie les dates, je vérifie la granularité, les valeurs manquantes, les ruptures de série et les événements business connus. Sinon on compare surtout du bruit. J’ai vu ça chez un client retail : le meilleur modèle était juste celui qui “absorbait” le mieux une promo mal renseignée. Pas celui qui prévoyait vraiment mieux.

Pour comparer proprement, je garde quelques règles simples :

• Je garde exactement le même jeu de données pour tous les outils.
• Je fige une période de test, par exemple les 8 dernières semaines.
• Je mesure au moins une erreur de prévision, comme le MAE, l’erreur absolue moyenne.
• Je note aussi le temps de mise en place, la lisibilité des sorties, la facilité de déploiement et les dépendances.

Le bon outil, ce n’est pas juste celui qui gagne sur une métrique. C’est celui que vous comprenez, que vous pouvez maintenir, et que vous pouvez brancher proprement dans votre contexte.

Quand choisir Prophet ?

Je choisis Prophet quand j’ai besoin d’un modèle rapide à comprendre, facile à expliquer et adapté à des données business avec tendance, saisonnalité et jours fériés.

Prophet est une librairie open-source créée par Facebook, maintenant Meta, pour faire de la prévision de séries temporelles sans se perdre dans trop de complexité statistique. Son interface est simple, presque volontairement rigide. Le DataFrame doit contenir deux colonnes principales : ds pour la date ou le timestamp, et y pour la valeur à prévoir. Oui, ce format imposé est une contrainte. Mais c’est aussi une force, parce qu’il oblige à poser le problème proprement. Une date. Une mesure. Une prévision.

Ce que j’aime avec Prophet, c’est qu’il couvre vite les besoins classiques :

• La tendance, donc la direction générale de la série.
• Les saisonnalités, comme les cycles hebdomadaires, mensuels ou annuels.
• Les effets calendaires, notamment les jours fériés.
• La génération automatique d’un DataFrame futur.
• Les intervalles d’incertitude, avec une borne basse et une borne haute.

Pour des ventes, du trafic web, des réservations, des volumes de tickets ou des commandes récurrentes, c’est souvent un très bon premier modèle de référence. Chez un client e-commerce, je l’ai utilisé pour sortir une baseline en une demi-journée. Pas parfaite, mais claire, défendable, et déjà utile pour comparer les modèles plus avancés derrière.

import pandas as pd
from prophet import Prophet

# Exemple de données avec une date et une valeur à prévoir
df = pd.DataFrame({
    "ds": pd.date_range(start="2024-01-01", periods=120, freq="D"),
    "y": [100 + i * 0.5 for i in range(120)]
})

# Création et entraînement du modèle
model = Prophet()
model.fit(df)

# Création des 30 prochains jours à prévoir
future = model.make_future_dataframe(periods=30)

# Génération des prévisions
forecast = model.predict(future)

# Affichage des colonnes principales
print(forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].tail(30))

Je reste prudent quand même. Prophet n’est pas fait pour capturer tous les comportements complexes, les dépendances longues ou les interactions riches avec plusieurs variables externes. Si votre série dépend fortement du prix, de la météo, du stock, des campagnes marketing et de signaux clients, il faudra probablement aller plus loin. Je l’utilise souvent comme baseline solide, pas comme réponse magique.

Quand passer à NeuralProphet ?

Je passe à NeuralProphet quand Prophet devient trop limité et que j’ai besoin de lags, d’auto-régression ou de covariables tout en gardant une structure assez lisible.

NeuralProphet reprend l’esprit de Prophet, donc on garde cette idée assez pratique de tendance, saisonnalités et événements, mais il ajoute des composants neuronaux avec PyTorch. PyTorch, c’est une librairie de deep learning, utilisée pour entraîner des réseaux de neurones. Ici, l’intérêt n’est pas de partir dans une énorme boîte noire, mais d’ajouter un peu de mémoire au modèle.

Le cas typique, c’est une série où le passé récent compte beaucoup. Par exemple, les ventes d’hier et d’avant-hier influencent fortement les ventes de demain. Prophet peut modéliser une tendance et une saisonnalité, mais il ne “regarde” pas naturellement les dernières valeurs comme le fait un modèle auto-régressif. NeuralProphet peut le faire avec n_lags. Un lag, c’est simplement une valeur passée utilisée comme entrée du modèle.

Je le teste aussi quand il y a des phénomènes avec retard. Une campagne marketing lancée lundi peut impacter les ventes jeudi. Une rupture de stock peut continuer à déformer la demande plusieurs jours après. C’est là que les covariables deviennent utiles. Une covariable, c’est une variable explicative externe, comme le budget média, la météo, un prix, un stock, ou un jour férié métier.

import pandas as pd
from neuralprophet import NeuralProphet

# Le DataFrame doit contenir deux colonnes :
# ds = date
# y = valeur à prévoir
df = pd.DataFrame({
    "ds": pd.date_range(start="2024-01-01", periods=200, freq="D"),
    "y": range(200)
})

model = NeuralProphet(
    n_lags=14,        # Le modèle regarde les 14 derniers jours
    n_forecasts=7     # Le modèle prédit les 7 prochains jours
)

metrics = model.fit(df, freq="D")

future = model.make_future_dataframe(df, periods=7)
forecast = model.predict(future)

print(forecast[["ds", "yhat1"]].tail())

Par rapport à Prophet, NeuralProphet est plus flexible et parfois plus puissant sur les comportements temporels un peu nerveux. Mais il est aussi plus sensible à la configuration, aux versions des librairies et au volume de données. J’ai déjà vu des projets où Prophet était trop simple, mais où un modèle deep learning complet était clairement exagéré. NeuralProphet faisait bien le pont entre les deux.

Petit point pratique, il peut aussi y avoir des sujets de compatibilité PyTorch selon les versions, notamment autour de torch.load. Rien de dramatique, mais je préfère le dire, parce que ce genre de détail peut faire perdre une matinée si l’environnement Python n’est pas propre.

C’est souvent un bon compromis quand le métier veut encore comprendre les grandes composantes du modèle, mais que la série demande un peu plus qu’une tendance et une saisonnalité.

• Je le teste quand les dernières valeurs observées ont un vrai poids sur la prévision.
• Je le teste quand j’ai des effets retardés à modéliser.
• Je le teste quand j’ai des variables explicatives utiles, mais pas assez de complexité pour justifier une API ou un foundation model.
• Je le teste quand Prophet donne une base correcte, mais rate les variations court terme.

TimeGPT ou Chronos pour aller plus loin ?

Je regarde TimeGPT ou Chronos quand je veux réduire la configuration manuelle ou tester une approche foundation model sur des séries temporelles.

TimeGPT, c’est le chemin le plus simple côté développeur. Vous installez le SDK Nixtla, vous mettez une clé API, vous envoyez un DataFrame avec une colonne ds pour la date et y pour la valeur à prévoir. Ça va vite, et c’est justement son intérêt. J’aime bien l’utiliser quand un client veut valider une idée en deux heures, ou brancher une prévision dans un workflow Make, n8n, Airflow ou une app interne sans monter toute une stack ML.

import os
import pandas as pd
from nixtla import NixtlaClient

# Clé API stockée en variable d'environnement
client = NixtlaClient(api_key=os.environ["NIXTLA_API_KEY"])

# Point de départ minimal : une date, une valeur
df = pd.DataFrame({
    "ds": pd.date_range("2024-01-01", periods=100, freq="D"),
    "y": range(100)
})

forecast = client.forecast(
    df=df,
    h=14,
    time_col="ds",
    target_col="y"
)

print(forecast)

Le compromis est clair. Vous dépendez d’un service externe. Il peut y avoir un coût, des limites d’usage, une gestion de clés API, et surtout des sujets de confidentialité. Si vos données sont sensibles, il faut regarder la gouvernance avant de pousser ça en production.

Chronos, lui, est plus intéressant quand je veux tester des modèles pré-entraînés avec plus de contrôle. On parle d’une famille de modèles de forecasting open-weight, donc des modèles dont les poids peuvent être utilisés selon l’implémentation. On peut passer par le package Chronos ou par AutoGluon TimeSeries, qui simplifie beaucoup l’usage.

import pandas as pd
from autogluon.timeseries import TimeSeriesDataFrame, TimeSeriesPredictor

# Données au format long : une série, une date, une valeur
df = pd.DataFrame({
    "item_id": "serie_1",
    "ds": pd.date_range("2024-01-01", periods=100, freq="D"),
    "y": range(100)
})

train_data = TimeSeriesDataFrame.from_data_frame(
    df,
    id_column="item_id",
    timestamp_column="ds"
)

predictor = TimeSeriesPredictor(
    prediction_length=14,
    target="y"
).fit(
    train_data,
    hyperparameters={"Chronos": {"model_path": "bolt_small"}}
)

predictions = predictor.predict(train_data)
print(predictions)

Chronos demande plus de bagage technique. Les dépendances sont plus lourdes, les ressources machine comptent, et les équipes non techniques peuvent vite décrocher. Mais pour explorer une approche moderne du forecasting sans rester enfermé dans une API fermée, c’est franchement intéressant.

Besoin principal	Outil recommandé	Vigilance
Explicabilité	Modèles classiques ou ML interprétable	TimeGPT et Chronos restent moins lisibles
Lags/covariables	AutoGluon TimeSeries ou modèles ML	Bien contrôler les variables disponibles au moment de prédire
API rapide	TimeGPT	Coût, clé API, données envoyées à un service externe
Open-weight/foundation model	Chronos	Setup plus technique et dépendances plus lourdes
Production sensible aux coûts	Chronos ou modèle interne	Surveiller infra, maintenance et temps de calcul

Alors, lequel je choisirais pour votre cas ?

Je partirais rarement directement sur le modèle le plus sophistiqué. Pour une série business classique, Prophet reste une excellente base parce qu’il est simple, lisible et rapide à tester. Si la dynamique dépend beaucoup du passé récent ou de variables externes, NeuralProphet mérite le détour. Si vous voulez aller vite via API, TimeGPT simplifie beaucoup la configuration. Si vous voulez explorer les modèles fondation avec plus de contrôle, Chronos devient intéressant. Le bon choix, c’est celui qui tient dans votre vraie vie : données, budget, prod, explicabilité. Le bénéfice pour vous, c’est d’éviter un modèle brillant mais inutilisable.

FAQ

• Quel est le meilleur outil entre Prophet, NeuralProphet, TimeGPT et Chronos ?
  Il n’y a pas de meilleur outil universel. Prophet est souvent le plus simple pour démarrer et expliquer. NeuralProphet ajoute des lags, de l’auto-régression et des covariables. TimeGPT est pratique si vous voulez une API avec moins de configuration. Chronos est intéressant si vous voulez tester une approche foundation model/open-weight.
• Prophet suffit-il pour des prévisions business ?
  Souvent oui, surtout pour des séries avec tendance, saisonnalité et effets calendaires. Je l’aime bien comme premier modèle parce qu’il donne vite une base lisible. Il montre aussi rapidement si le problème vient du modèle ou de la qualité des données.
• Quand NeuralProphet devient-il plus pertinent que Prophet ?
  NeuralProphet devient pertinent quand le passé récent influence fortement le futur, quand vous avez besoin de lags ou quand des variables externes peuvent améliorer la prévision. Il demande plus d’attention côté configuration et dépendances, notamment avec PyTorch.
• TimeGPT impose-t-il d’utiliser une API ?
  Oui, l’usage de TimeGPT passe par le SDK Nixtla et une clé API. C’est confortable pour tester vite et réduire la configuration, mais il faut regarder le coût, la confidentialité des données, la gouvernance et l’intégration dans votre environnement de production.
• Chronos est-il adapté à une équipe data classique ?
  Chronos peut être adapté si l’équipe est à l’aise avec Python, les modèles pré-entraînés et des dépendances plus techniques. Via AutoGluon TimeSeries, l’accès peut être plus simple. Je le vois surtout comme une piste à tester quand on veut comparer une approche foundation model à des modèles plus classiques.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA appliquée en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes sur des sujets data très concrets : collecte, fiabilisation, automatisation, modèles prédictifs et passage en production. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet data, forecasting ou IA sans partir dans tous les sens, contactez-moi.