Je choisis l’outil selon le besoin métier, pas juste selon le score. Prophet rassure, NeuralProphet apprend des retards, TimeGPT simplifie via API, Chronos ouvre la voie aux modèles fondationnels. Le vrai sujet, c’est le compromis entre précision, coût, explicabilité et déploiement.
Pourquoi le choix du modèle compte ?
Le choix du modèle compte parce qu’une bonne prévision inutile en production ne sert à rien. Si le modèle est précis sur un notebook mais impossible à expliquer, trop lent à entraîner, trop cher à faire tourner ou pénible à déployer, vous n’avez pas un outil de prévision. Vous avez une démo.
Je vois souvent des équipes partir sur le modèle le plus sophistiqué disponible. Réseau neuronal, modèle fondationnel, API magique, tout y passe. Puis elles passent trois semaines à expliquer au métier pourquoi la prévision bouge, pourquoi elle rate certaines périodes, pourquoi personne ne peut vraiment interpréter les variables. C’est rarement là que se gagne le projet.
La précision compte, bien sûr. Mais elle n’est qu’un critère parmi d’autres. Avant de choisir un outil de prévision de séries temporelles, je regarde surtout ces points :
- Explicabilité : Est-ce que je peux expliquer simplement pourquoi le modèle prévoit une hausse ou une baisse ?
- Scalabilité : Est-ce que l’outil tient quand je passe de 10 séries à 10 000 séries ?
- Vitesse d’entraînement : Est-ce que je peux réentraîner souvent sans bloquer toute l’équipe data ?
- Coût : Est-ce que l’usage API, GPU ou cloud reste raisonnable quand le volume augmente ?
- Déploiement : Est-ce que je peux le mettre en production proprement, avec monitoring et relance automatique ?
- Contexte technique : Est-ce que j’ai besoin d’une API externe, ou est-ce que tout doit rester en local pour des raisons de sécurité ?
Prophet reste très bon quand je veux de la clarté, des tendances, des saisonnalités et quelque chose de compréhensible par le business. NeuralProphet ajoute une couche d’apprentissage neuronal, avec notamment les valeurs retardées, c’est-à-dire les valeurs passées utilisées pour prédire le futur. TimeGPT de Nixtla réduit beaucoup la configuration avec une API et une clé API, pratique quand je veux tester vite. Chronos permet de tester des modèles fondationnels open-weight, donc des modèles pré-entraînés dont les poids sont accessibles, via son package ou AutoGluon.
| Outil | Point fort | Limite à surveiller |
| Prophet | Clarté et explicabilité | Moins adapté aux signaux très complexes |
| NeuralProphet | Ajout du neuronal et des valeurs retardées | Plus de réglages à maîtriser |
| TimeGPT | Très rapide à tester via API Nixtla | Dépendance à une API et à une clé API |
| Chronos | Modèles fondationnels open-weight | Déploiement et coûts à cadrer selon l’usage |
Quand choisir Prophet ?
Je choisis Prophet quand j’ai besoin d’un modèle clair, rapide à expliquer, et adapté à des données métier avec une tendance, des saisonnalités et parfois des événements récurrents.
Prophet, c’est un outil open-source développé à l’origine par Facebook, devenu Meta. Il est très utilisé parce qu’il force une structure simple. Votre dataset doit contenir deux colonnes : ds pour la date, et y pour la valeur à prévoir. Rien que ça, c’est déjà un avantage. On évite de passer trois jours à préparer un format exotique avant même d’avoir une première prévision.
Son vrai intérêt, c’est la lisibilité. Prophet décompose la série temporelle en éléments faciles à comprendre : la tendance générale, les saisonnalités, et éventuellement des jours spéciaux ou événements métier. Une saisonnalité, c’est juste un motif qui se répète, par exemple chaque semaine, chaque mois, ou chaque année. Dans beaucoup d’équipes, ça vaut plus qu’un modèle très sophistiqué que personne ne sait défendre en réunion.
| Sortie Prophet | Signification |
| yhat | La prévision centrale du modèle. |
| yhat_lower | La borne basse de l’intervalle d’incertitude. |
| yhat_upper | La borne haute de l’intervalle d’incertitude. |
Un intervalle d’incertitude, c’est la zone dans laquelle le modèle pense que la vraie valeur a de bonnes chances de tomber. C’est très utile pour éviter les fausses certitudes. J’ai vu des clients préférer ça à un score technique plus joli, parce que ça leur permettait de dire “voilà notre scénario probable, voilà le risque bas, voilà le risque haut”.
import pandas as pd
from prophet import Prophet
# Création d'un petit jeu de données avec les colonnes attendues par Prophet
df = pd.DataFrame({
"ds": pd.date_range(start="2024-01-01", periods=10, freq="D"),
"y": [100, 112, 108, 120, 125, 130, 128, 140, 145, 150]
})
# Entraînement du modèle
model = Prophet()
model.fit(df)
# Création des dates futures à prévoir
future = model.make_future_dataframe(periods=7)
# Génération des prévisions
forecast = model.predict(future)
# Colonnes utiles
print(forecast[["ds", "yhat", "yhat_lower", "yhat_upper"]].tail())
Je le vois souvent comme un excellent premier benchmark. Avant de sortir l’artillerie lourde avec du deep learning ou des modèles plus complexes, Prophet donne vite une base propre, explicable, et souvent déjà très correcte. Si le métier doit comprendre la prévision, la challenger, puis l’utiliser, Prophet mérite clairement sa place dans la shortlist.
Quand passer à NeuralProphet ?
Je passe à NeuralProphet quand les valeurs récentes pèsent beaucoup dans la prévision et que Prophet commence à devenir trop limité. C’est typiquement le cas quand la série dépend fortement de ce qui vient juste de se passer : hier, la semaine dernière, les derniers points, parfois même les dernières heures.
NeuralProphet garde l’idée simple de Prophet : une tendance, des saisonnalités, des jours spéciaux si besoin. Mais il ajoute une couche neuronale basée sur PyTorch, la librairie de deep learning. Ça lui permet d’intégrer de l’autorégression, c’est-à-dire l’utilisation des anciennes valeurs de la série pour prévoir les prochaines. On parle aussi de valeurs retardées, ou lags en anglais. Par exemple, dire au modèle : “Regarde les 30 derniers points avant de prédire”.
Ce que ça change concrètement, c’est que le modèle peut apprendre des dépendances plus proches dans le temps. Prophet est très bon pour capter des tendances propres, une saisonnalité hebdo, annuelle, des effets calendrier. Mais si votre business est très sensible aux derniers comportements observés, il peut manquer de mémoire courte. NeuralProphet comble mieux ce trou.
Je le vois souvent sur des séries comme ça :
- Des ventes e-commerce où les derniers jours influencent fortement demain.
- Des volumes de tickets support avec des effets de rattrapage.
- Des métriques produit où l’activité récente donne un signal très fort.
- Des séries opérationnelles avec inertie, comme du trafic, des stocks ou de la charge.
import pandas as pd
from neuralprophet import NeuralProphet
# Le DataFrame doit contenir deux colonnes : ds pour la date, y pour la valeur
df = pd.DataFrame({
"ds": pd.date_range(start="2024-01-01", periods=200, freq="D"),
"y": range(200)
})
# n_lags indique combien de valeurs passées le modèle regarde
model = NeuralProphet(
n_lags=30,
n_forecasts=7
)
metrics = model.fit(df, freq="D")
future = model.make_future_dataframe(df, periods=7)
forecast = model.predict(future)
print(forecast[["ds", "yhat1"]].tail())
NeuralProphet permet aussi d’ajouter des covariables. Une covariable, c’est une variable externe qui peut aider la prévision : budget pub, météo, prix, stock disponible, nombre de campagnes envoyées. C’est très utile, mais ça demande des données propres. Sinon, on donne juste plus d’occasions au modèle de se tromper.
Petit point terrain : NeuralProphet est plus technique à maintenir que Prophet. Comme il dépend de PyTorch, il peut y avoir des sujets de compatibilité selon les versions, notamment autour de torch.load. Dans un projet sérieux, je fige toujours les versions de librairies dans un requirements.txt ou un pyproject.toml. Ça évite les surprises six mois plus tard.
Donc non, NeuralProphet n’est pas juste Prophet en mieux. Il est plus flexible, plus puissant sur certaines séries, mais aussi un peu plus exigeant. Je le prends quand cette flexibilité apporte vraiment quelque chose, pas par réflexe.
Que changent TimeGPT et Chronos ?
TimeGPT et Chronos changent surtout le niveau d’abstraction. On passe d’un modèle que je configure moi-même, avec ses paramètres, ses features et ses choix d’entraînement, à des approches pré-entraînées ou fondationnelles. Dit autrement, je ne pars plus toujours d’une page blanche.
TimeGPT, proposé via le SDK Nixtla, fonctionne avec une clé API. Je lui envoie mes séries, je définis l’horizon de prévision, et l’outil renvoie des prédictions sans que j’aie à régler toute la mécanique interne du modèle. Son intérêt principal, pour moi, c’est la vitesse de test. Quand un client veut savoir en quelques heures si une prévision est exploitable sur ses ventes, ses volumes d’appels ou sa consommation énergétique, c’est pratique. On évite de construire tout le pipeline modèle, entraînement, tuning, validation, déploiement dès le départ.
Chronos va plutôt du côté des modèles fondationnels open-weight pour séries temporelles. Open-weight veut dire que les poids du modèle sont accessibles, donc on peut l’utiliser plus librement qu’une API fermée, selon les licences et les contraintes techniques. Il est utilisable via le package Chronos ou via AutoGluon TimeSeries, qui fournit une couche plus automatisée pour tester plusieurs approches. C’est intéressant quand on a plusieurs séries et qu’on veut voir si un modèle plus générique tient la route sans repartir sur un modèle spécialisé à chaque fois.
Mais je ne les prends pas comme des solutions magiques. Une série temporelle reste très dépendante du métier, des ruptures, des promotions, des jours fériés, des données manquantes. Je mesure toujours sur mes propres données, avec un vrai backtest, c’est-à-dire une simulation du passé où je cache une période connue pour vérifier si le modèle aurait bien prévu.
| Question pratique | Point à vérifier |
| Dépendance API | Est-ce acceptable si le service externe change, ralentit ou tombe ? |
| Confidentialité | Est-ce que les données peuvent sortir de votre environnement ? |
| Coût | Est-ce viable si les prévisions deviennent fréquentes ou massives ? |
| Latence | Est-ce assez rapide pour votre usage opérationnel ? |
| Reproductibilité | Est-ce que je peux retrouver le même résultat plus tard ? |
| Ressources machine | Est-ce que l’infra suit, surtout avec Chronos en local ? |
Je les teste quand le gain opérationnel potentiel justifie la complexité ou la dépendance supplémentaire.
Comment comparer proprement ?
Je compare proprement en gardant le même jeu de données, le même horizon, les mêmes métriques et les mêmes contraintes de déploiement. Sinon, on ne compare pas des modèles, on compare des conditions de course.
Je pars toujours d’un protocole simple. Un split temporel, pas un split aléatoire. Ça veut dire que j’entraîne sur le passé, puis je teste sur une période future que le modèle n’a jamais vue. Si je prévois 30 jours, tout le monde prédit 30 jours. Prophet, NeuralProphet, TimeGPT, Chronos, AutoGluon, même combat.
Côté installation, je garde ça assez direct :
pip install prophet
pip install neuralprophet
pip install nixtla
pip install chronos-forecasting
pip install autogluon.timeseries
Prophet et NeuralProphet peuvent être entraînés localement, donc c’est pratique pour garder la donnée chez soi. TimeGPT passe par le SDK Nixtla, donc il faut une clé API. Une API, c’est juste un accès externe à un service, avec authentification. Chronos peut être testé via son package dédié ou via AutoGluon TimeSeries, qui encapsule plusieurs modèles et facilite les benchmarks.
Je regarde quelques points, toujours les mêmes, sinon on se raconte vite une belle histoire :
- Je fixe un horizon clair, par exemple 7, 30 ou 90 jours.
- Je mesure l’erreur avec MAE ou RMSE. MAE, c’est l’erreur moyenne absolue. RMSE pénalise plus fort les grosses erreurs.
- Je trace les prévisions. Un bon score avec une courbe absurde, ça arrive plus souvent qu’on croit.
- Je note le temps d’exécution, le coût API ou GPU, et la facilité de maintenance.
- Je vérifie si l’équipe peut vraiment l’exploiter en production, pas juste lancer un notebook.
Sur un client retail, le modèle le plus précis était aussi le plus pénible à maintenir. Au bout de trois semaines, l’équipe a préféré un modèle un peu moins bon, mais stable, lisible, et facile à relancer.
| Outil | Configuration | Explicabilité | Scalabilité | Coût | Meilleur cas d’usage |
| Prophet | Locale, simple | Bonne | Moyenne | Faible | Séries business avec tendance et saisonnalité |
| NeuralProphet | Locale, un peu plus technique | Moyenne | Moyenne | Faible | Séries avec effets non linéaires simples |
| TimeGPT | SDK Nixtla et clé API | Faible à moyenne | Bonne | Variable selon usage API | Prévision rapide sans entraînement lourd |
| Chronos | Package dédié ou AutoGluon | Faible | Bonne si infra adaptée | Variable, surtout GPU | Benchmark moderne sur beaucoup de séries |
Le meilleur outil, au fond, c’est celui qui tient en production. Pas celui qui gagne une démo sur un notebook.
Alors, lequel je teste en premier ?
Si je dois résumer, je commence rarement par le modèle le plus impressionnant. Je pars du besoin. Si le business doit comprendre la prévision, Prophet reste un excellent point de départ. Si les valeurs récentes comptent beaucoup, NeuralProphet mérite le test. Si je veux aller vite via API, je regarde TimeGPT. Si je veux explorer les modèles fondationnels open-weight, je teste Chronos. Le bon choix dépend de vos données, de vos contraintes et de votre capacité à maintenir le modèle. Le bénéfice pour vous, c’est simple : choisir plus vite, éviter les usines à gaz, et produire des prévisions vraiment utilisables.
FAQ
- Prophet est-il encore utile pour la prévision de séries temporelles ?
Oui, surtout quand je veux un modèle simple, local, explicable et rapide à mettre en place. Il reste très pratique pour des données business avec tendance, saisonnalité et événements récurrents. - Quelle différence entre Prophet et NeuralProphet ?
Prophet se concentre sur une structure lisible de tendance et saisonnalité. NeuralProphet reprend cette logique, mais ajoute PyTorch, l’autoregression, les valeurs retardées et des covariables. Je le regarde quand les derniers points de la série influencent fortement la suite. - TimeGPT remplace-t-il les modèles classiques ?
Pas forcément. TimeGPT réduit la configuration grâce à une API, ce qui peut faire gagner du temps. Mais je dois quand même vérifier le coût, la confidentialité, la latence et la performance sur mes propres séries. - Chronos sert à quoi dans un projet de forecasting ?
Chronos permet de tester une approche fondationnelle open-weight pour les séries temporelles, notamment via son package ou AutoGluon TimeSeries. C’est intéressant quand je veux comparer une approche plus générale à des modèles configurés manuellement. - Comment choisir le meilleur outil de prévision ?
Je garde le même horizon, les mêmes données de test et les mêmes métriques. Puis je compare aussi l’explicabilité, le coût, la scalabilité et le déploiement. Le meilleur outil n’est pas toujours le plus précis, c’est celui qui tient dans votre contexte réel.
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, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes sur des sujets data très concrets : fiabiliser la mesure, automatiser les flux, industrialiser les analyses et rendre les modèles vraiment exploitables. J’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer un projet data, IA ou automatisation, 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.






