Je choisirais l’outil selon votre contrainte principale, pas juste selon la précision. Prophet explique bien, NeuralProphet capte mieux les effets récents, TimeGPT accélère via API, Chronos ouvre la porte aux foundation models. Le vrai sujet, c’est le bon compromis pour votre business.
Pourquoi le choix compte vraiment ?
Le choix compte parce qu’un modèle de forecasting inutilisable par les équipes ne sert pas longtemps, même s’il est précis sur un benchmark. C’est un point que je vois souvent. Sur le papier, le modèle gagne 2 points de précision. Dans la vraie vie, personne ne comprend ses sorties, personne ne sait le recalibrer, et au bout de trois mois il dort dans un notebook.
Choisir entre Prophet, NeuralProphet, TimeGPT et Chronos, ce n’est pas juste comparer une métrique d’erreur comme le MAPE, qui mesure l’écart moyen entre prévision et réel en pourcentage. Il faut regarder ce que l’outil permet vraiment dans votre contexte. Une prévision de ventes utilisée en comité commercial n’a pas les mêmes contraintes qu’une prévision de demande électrique, de trafic web, de stocks ou de planning d’équipes.
Les critères qui comptent vraiment sont assez concrets :
- Interprétabilité : Est-ce que les métiers comprennent pourquoi la prévision monte ou baisse ?
- Scalabilité : Est-ce que l’outil tient quand vous passez de 20 séries à 20 000 séries ?
- Vitesse d’exécution : Est-ce que le modèle tourne assez vite pour vos cycles de décision ?
- Coût : Est-ce que le prix API, infra ou GPU reste cohérent avec la valeur métier ?
- Facilité de déploiement : Est-ce que vous pouvez l’intégrer proprement dans vos pipelines existants ?
- Niveau de configuration acceptable : Est-ce que votre équipe peut maintenir le modèle sans dépendre d’un expert rare ?
J’ai déjà vu des équipes choisir un modèle trop complexe parce qu’il était meilleur en test. Puis revenir à quelque chose de plus lisible, simplement parce que les métiers ne faisaient pas confiance aux sorties. Et franchement, ils avaient raison. Une prévision doit être utilisée, challengée, ajustée. Pas seulement admirée dans un rapport.
Prophet reste intéressant quand on veut de la clarté, avec des composantes faciles à expliquer comme la tendance, la saisonnalité et les jours spéciaux. NeuralProphet fait le pont entre cette logique lisible et des réseaux de neurones, utiles quand les séries ont des comportements plus riches. TimeGPT pousse une approche API, avec moins de configuration à gérer. Chronos part plutôt sur une logique de foundation model, avec des poids ouverts, utilisable via chronos-forecasting ou AutoGluon.
| Outil | Point fort | Vigilance principale |
| Prophet | Lisibilité et explication des composantes | Moins adapté aux patterns très complexes |
| NeuralProphet | Compromis entre clarté et réseaux de neurones | Paramétrage plus sensible |
| TimeGPT | API simple, peu de configuration | Dépendance au service et au coût d’usage |
| Chronos | Foundation model à poids ouverts | Déploiement et ressources à cadrer |
Quand Prophet suffit largement ?
Prophet suffit largement quand la série a une tendance, des saisonnalités lisibles et éventuellement des jours fériés, et que les utilisateurs ont besoin de comprendre la prévision.
Je le vois comme un très bon outil de forecasting “métier”. Prophet est un outil open-source développé initialement par Facebook, aujourd’hui Meta, pensé pour être simple à manipuler et surtout lisible. Il marche bien quand on peut dire des choses comme “ça monte depuis 2 ans”, “il y a un effet semaine”, “le mois de décembre est spécial”, “les jours fériés cassent la demande”.
Son format est volontairement minimal. Il attend un DataFrame avec deux colonnes obligatoires : ds pour la date, et y pour la valeur à prévoir. C’est bête, mais ça évite pas mal de complexité inutile au départ.
import pandas as pd
from prophet import Prophet
data = {
"ds": pd.date_range(start="2023-01-01", periods=100, freq="D"),
"y": [100 + i * 0.5 for i in range(100)]
}
df = pd.DataFrame(data)
model = Prophet()
model.fit(df)
future = model.make_future_dataframe(periods=30)
forecast = model.predict(future)
print(forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].tail())
Dans les résultats, yhat correspond à la prévision centrale. yhat_lower et yhat_upper donnent un intervalle d’incertitude. Dit simplement : “voilà la prévision, et voilà la zone raisonnable autour”. C’est très utile quand on parle à des équipes finance, supply, marketing ou opérations. Elles n’ont pas juste besoin d’un chiffre, elles ont besoin de savoir à quel point ce chiffre est fragile.
Je garde Prophet en priorité dans ces cas-là :
- Première baseline sérieuse, quand je veux un modèle propre rapidement.
- Besoin d’explication côté métier, sans boîte noire trop lourde.
- Séries avec calendrier, saisonnalité hebdo, mensuelle ou annuelle.
- Prototype rapide, pour savoir si le sujet mérite plus d’effort.
J’ai déjà vu des clients gagner beaucoup de temps avec Prophet juste parce que le modèle était compréhensible. Pas parfait, mais assez clair pour déclencher une vraie discussion.
Ses limites arrivent quand les interactions deviennent complexes, quand les valeurs très récentes pilotent fortement le futur, quand il faut beaucoup de covariables avancées, ou quand on a un très gros volume de séries à industrialiser finement.
Quand le passé immédiat devient très important, j’ai besoin d’un modèle qui regarde mieux les lags, c’est-à-dire les valeurs précédentes de la série. Là, je commence à regarder NeuralProphet.
Pourquoi passer à NeuralProphet ?
Je passe à NeuralProphet quand Prophet reste utile mais que les valeurs récentes, les retards et certaines variables explicatives doivent peser davantage dans la prévision.
Prophet est très bon quand la série a une tendance, une saisonnalité, des jours spéciaux, et qu’on veut un modèle lisible. NeuralProphet garde cet esprit, mais il ajoute une couche d’apprentissage neuronal avec PyTorch, la librairie Python utilisée pour entraîner des modèles de deep learning. L’idée n’est pas de tout transformer en boîte noire. L’idée, c’est de donner au modèle un peu plus de mémoire.
Les notions à connaître sont assez simples.
- Autoregression : Le modèle utilise les anciennes valeurs de la série pour prédire les suivantes. Par exemple, les ventes d’hier et d’avant-hier aident à prévoir les ventes de demain.
- Lags : Ce sont les retards utilisés par le modèle. Si je mets 14 lags, je lui donne les 14 dernières observations comme contexte.
- Covariables : Ce sont des variables explicatives externes. Météo, prix, budget média, trafic, jours de promo, température, charge réseau… Tout ce qui peut aider à expliquer la série.
- Apprentissage neuronal : Le modèle apprend des relations un peu plus souples entre les signaux. Pas juste une tendance plus une saisonnalité.
Ça aide bien sur des cas où le passé récent compte beaucoup. Un trafic web qui réagit vite après une campagne. Une demande électrique très sensible à la température et aux habitudes des derniers jours. Des ventes avec une inertie récente, où une rupture de stock ou une promo laisse une trace pendant plusieurs jours. J’ai vu ça chez un client e-commerce : Prophet captait bien la saisonnalité, mais il réagissait trop lentement après les pics de campagnes. NeuralProphet donnait un signal plus nerveux.
Le bon positionnement, pour moi, c’est celui-ci : plus flexible que Prophet, moins opaque qu’un modèle deep learning pur. Ce n’est pas magique. Il faut surveiller la qualité des données, le découpage train test, l’horizon de prévision, et le temps d’entraînement. Un mauvais dataset reste un mauvais dataset, même avec PyTorch derrière.
from neuralprophet import NeuralProphet
import pandas as pd
df = pd.DataFrame({
"ds": pd.date_range(start="2024-01-01", periods=100, freq="D"),
"y": [100 + i * 0.3 for i in range(100)]
})
model = NeuralProphet(
n_lags=14,
n_forecasts=7
)
metrics = model.fit(df, freq="D")
future = model.make_future_dataframe(
df,
periods=7,
n_historic_predictions=True
)
forecast = model.predict(future)
print(forecast[["ds", "yhat1"]].tail())
Petit détail pratique, mais il compte. L’environnement Python et les versions de PyTorch peuvent créer des surprises. Certains workflows demandent parfois un ajustement de compatibilité autour de torch.load pour charger correctement des poids selon les versions. Rien d’insurmontable, juste un point à anticiper avant de mettre ça en production.
Si je veux réduire fortement la configuration et déléguer une partie du modeling, là je commence plutôt à regarder du côté API, avec TimeGPT.
Que change TimeGPT dans le workflow ?
TimeGPT change le workflow parce qu’il réduit la configuration du modèle et déplace une partie du travail vers une API spécialisée dans le forecasting. Au lieu de passer du temps à choisir une architecture, régler des hyperparamètres, entraîner, valider, versionner le modèle, on peut tester une prévision beaucoup plus vite.
TimeGPT est accessible via le SDK Nixtla, avec une clé API. Dans la pratique, ça veut dire qu’on installe le package, on prépare une série temporelle propre, on appelle l’API, et on récupère les prédictions. Le format reste simple : une colonne ds pour la date, une colonne y pour la valeur à prévoir. C’est très proche de ce qu’on voit dans d’autres outils de forecasting modernes.
J’aime bien cette approche quand l’objectif est de tester vite. Par exemple, sur une série de ventes hebdo, un volume de tickets support, une charge serveur, ou une demande produit. On peut obtenir une première baseline sans construire toute l’architecture soi-même. Et parfois, cette baseline est déjà assez bonne pour décider si le sujet mérite plus d’investissement.
Il y a quand même des critères à regarder avant de brancher ça en production :
- Coût API : Plus on envoie de séries et plus l’horizon est large, plus il faut surveiller la facture.
- Confidentialité : Les données partent vers un service externe, donc je vérifie toujours ce qui est envoyé.
- Dépendance : Si l’API change, ralentit, ou devient indisponible, votre pipeline peut être impacté.
- Volumes : Sur de très gros batchs, il faut tester les limites et les temps de réponse.
- Intégration : Le bon outil est celui qui rentre proprement dans votre stack data existante.
Pour certains clients, l’API est un accélérateur énorme. Mais je vérifie toujours la gouvernance data avant d’envoyer des séries sensibles hors de l’infra interne. C’est souvent là que le vrai sujet se joue, pas dans le modèle.
pip install nixtla
from nixtla import NixtlaClient
import pandas as pd
# Initialisation du client avec une clé API
client = NixtlaClient(api_key="VOTRE_CLE_API")
# Préparation d'une série temporelle simple
df = pd.DataFrame({
"ds": pd.date_range("2024-01-01", periods=100, freq="D"),
"y": range(100)
})
# Prévision sur les 14 prochains jours
forecast = client.forecast(
df=df,
h=14,
time_col="ds",
target_col="y"
)
print(forecast.head())
Si je veux aller plus loin, garder plus de contrôle sur les modèles, tester des poids ouverts et maîtriser davantage l’infrastructure, Chronos devient intéressant. TimeGPT accélère le workflow. Chronos redonne la main.
Chronos est il le bon pari ?
Chronos est un bon pari si vous voulez expérimenter des foundation models pour séries temporelles avec plus de contrôle qu’une API fermée.
Chronos fait partie des modèles de forecasting de type foundation model. Dit simplement, c’est un modèle déjà pré-entraîné sur beaucoup de séries temporelles, qu’on peut réutiliser sur vos propres données sans repartir de zéro avec un modèle statistique classique à chaque projet. C’est un peu la logique des grands modèles de langage, mais appliquée aux courbes de ventes, de trafic, de stock ou de consommation.
Vous pouvez l’utiliser directement avec le package chronos-forecasting, ou passer par AutoGluon TimeSeries, qui donne un cadre plus large pour entraîner, tester et comparer plusieurs approches.
pip install chronos-forecasting
pip install autogluon.timeseries
Je le vois surtout comme un outil d’exploration sérieuse. Moins immédiatement lisible que Prophet, parce qu’on perd le côté “tendance + saisonnalité + jours fériés” facile à raconter aux métiers. Mais beaucoup plus intéressant si votre équipe veut tester des modèles pré-entraînés ouverts, comparer les performances à l’échelle, et voir si ce type d’approche apporte vraiment quelque chose sur vos séries.
Le workflow reste assez simple dans l’idée :
- Charger vos données avec une date, un identifiant de série et une valeur à prédire.
- Créer un jeu de séries temporelles propre, avec une fréquence cohérente.
- Définir l’horizon de prédiction, par exemple 7 jours, 30 jours ou 12 mois.
- Lancer la prédiction avec Chronos ou AutoGluon TimeSeries.
- Comparer les résultats à Prophet ou NeuralProphet sur les mêmes périodes de test.
Les points de vigilance sont réels. Il faut prévoir les ressources de calcul, vérifier le packaging, tester la stabilité en production, et surtout faire un benchmark interne. Pas un benchmark vu sur GitHub. Le vôtre, avec vos séries, vos trous de données, vos ruptures, vos bizarreries. Chez un client retail, c’est exactement là que les surprises sont sorties : un modèle très bon sur les produits réguliers, mais moins robuste sur les références avec promotions agressives.
| Besoin principal | Outil conseillé | Raison |
| Expliquer aux métiers | Prophet | Simple à lire, facile à justifier, bon pour une première mise en place. |
| Capter les effets récents | NeuralProphet | Plus flexible, utile quand les comportements changent vite. |
| Aller vite avec une API | API de forecasting managée | Peu d’infrastructure, pratique pour tester rapidement. |
| Tester un foundation model ouvert | Chronos | Approche pré-entraînée, plus contrôlable qu’une API fermée, intéressante à benchmarker. |
Alors lequel je mettrais en production ?
Je ne mettrais pas le même outil partout. Pour une baseline claire, comprise par les métiers, je pars souvent sur Prophet. Quand les valeurs récentes structurent vraiment la prévision, je regarde NeuralProphet. Si l’objectif est de tester vite avec peu de configuration, TimeGPT peut faire gagner du temps, à condition d’assumer l’API. Pour explorer les foundation models avec plus de contrôle, Chronos mérite un benchmark sérieux.
Le bon choix, c’est celui qui tient dans votre contexte data, technique et business. Vous gagnez du temps, moins de bruit, et des prévisions que vos équipes peuvent vraiment utiliser.
FAQ
- Quel est le meilleur outil de forecasting pour commencer ?
Prophet est souvent le plus simple pour commencer. Il demande un format clair avec une date et une valeur, il gère bien tendance, saisonnalité et jours fériés, et ses résultats sont plus faciles à expliquer aux équipes métier. - Quand choisir NeuralProphet plutôt que Prophet ?
Je choisis NeuralProphet quand les valeurs récentes influencent fortement la suite. C’est utile pour du trafic web, des ventes ou de la demande électrique. Il ajoute des lags, de l’autorégression et des covariables grâce à PyTorch. - TimeGPT remplace t il les modèles classiques ?
Pas automatiquement. TimeGPT réduit la configuration via une API, ce qui peut accélérer les tests. Mais il faut regarder le coût, la confidentialité des données, la dépendance au service externe et la qualité réelle sur vos séries. - Chronos sert à quoi dans le forecasting ?
Chronos permet de tester des approches de type foundation model pour séries temporelles, avec des poids ouverts et une utilisation possible via chronos-forecasting ou AutoGluon. C’est intéressant pour benchmarker des modèles plus récents avec plus de contrôle. - Faut il choisir le modèle le plus précis ?
Pas seulement. La précision compte, mais l’interprétabilité, la vitesse, le coût, la scalabilité et la facilité de déploiement comptent aussi. Un modèle un peu moins précis mais compris et maintenable peut être un meilleur choix en production.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No Code et Low Code avec n8n, l’intégration de l’IA dans les process business, et les sujets SEO/GEO. J’ai travaillé avec des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer vos prévisions, vos pipelines data ou vos automatisations IA proprement, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, 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.






