Evaluer une prévision de séries temporelles ne se résume pas à regarder un chiffre. Un modèle peut afficher une MAPE de 8 % et être en réalité moins performant qu'un simple "prévoir la valeur du mois dernier". Le bon cadre d'évaluation repose sur trois piliers : choisir des métriques adaptées aux caractéristiques de vos données, comparer systématiquement à une baseline naïve, et backtester dans des conditions qui reproduisent fidèlement le déploiement réel.
Cet article couvre les métriques essentielles - MAE, RMSE, MAPE et ses pièges sur les valeurs proches de zéro, sMAPE, WAPE, MASE - ainsi que les métriques probabilistes (pinball loss), les protocoles de backtesting temporel, les pièges classiques du data leakage, et l'importance d'une baseline naïve. Une checklist de validation est fournie en fin d'article.
Pourquoi le R² ne convient pas à l'évaluation d'une prévision
Le R² est la métrique réflexe en régression classique. Pour les séries temporelles, c'est un mauvais réflexe.
Le R² mesure la part de variance expliquée par rapport à la moyenne de la série. Sur une série avec une tendance haussière régulière, cette moyenne est une référence déjà très facile à battre. Un modèle qui se contente de prolonger naïvement la tendance peut afficher un R² de 0,92 sans aucune capacité prédictive réelle.
Deuxième problème : le R² n'est pas défini de façon stable sur des données hors-échantillon. Il peut devenir négatif (ce qui ne veut rien dire intuitivement), et il ne traduit pas directement une erreur métier. Votre responsable logistique ne sait pas ce que "92 % de variance expliquée" implique pour son stock de sécurité.
Règle de base
Pour évaluer une prévision de séries temporelles, n'utilisez pas le R². Préférez des métriques qui mesurent l'erreur en unités métier (MAE, RMSE) ou qui comparent le modèle à une baseline naïve (MASE). Le R² peut rester dans les rapports d'exploration, pas dans les décisions de déploiement.
Les métriques d'erreur : MAE, RMSE, MAPE, sMAPE, WAPE, MASE
MAE et RMSE : erreurs en unités absolues
Le MAE (Mean Absolute Error) est la moyenne des écarts absolus entre prévisions et valeurs réelles. Sa lecture est directe : si votre MAE est de 120 unités sur une prévision de stocks, vous savez que l'erreur moyenne est de 120 pièces. Pas d'interprétation, pas de transformation.
Le RMSE (Root Mean Squared Error) met les écarts au carré avant de calculer la moyenne, puis prend la racine carrée. L'effet concret : les grosses erreurs pèsent proportionnellement plus. Si un pic de demande mal prévu est particulièrement coûteux - rupture critique, surproduction, pénalité contractuelle - le RMSE est plus pertinent que le MAE. Si toutes les erreurs se valent, le MAE suffit et est plus robuste aux outliers.
MAPE et ses pièges sur les valeurs proches de zéro
La MAPE (Mean Absolute Percentage Error) exprime l'erreur en pourcentage de la valeur réelle. Elle est très répandue dans les outils de reporting métier, ce qui lui donne une aura de lisibilité. Mais elle a des défauts structurels que trop de projets ignorent.
Le problème des valeurs proches de zéro. La valeur réelle est au dénominateur. Si une référence de votre catalogue ne se vend que 2 unités par mois et que vous en prévoyez 3, la MAPE affiche 50 % - une erreur absolue d'1 unité qui ne justifie pas cette lecture catastrophiste. Et si la valeur réelle est 0, la MAPE n'est tout simplement pas calculable (division par zéro).
L'asymétrie de pénalisation. Une surestimation ne peut produire qu'une erreur maximale de 100 % (si vous prévoyez 10 alors que la valeur réelle est 5, MAPE = 100 %). Une sous-estimation est non bornée : prévoyez 5 pour une valeur réelle de 50, la MAPE est de 90 % ; prévoyez 1 pour une valeur réelle de 100, elle atteint 99 %. Ce biais peut pousser les modèles à surestimer systématiquement pour minimiser la MAPE.
sMAPE : une amélioration limitée
La sMAPE (Symmetric MAPE) tente de corriger l'asymétrie de la MAPE en utilisant la moyenne de la valeur réelle et de la prévision au dénominateur. Elle borne les erreurs entre 0 % et 200 % et traite symétriquement surestimations et sous-estimations.
Mais elle n'est pas sans défauts. Quand la valeur réelle et la prévision sont toutes les deux proches de zéro, le dénominateur s'approche de zéro et les contributions individuelles peuvent dominer la moyenne. Les compétitions de prévision M4 et M5 l'ont utilisée, mais Hyndman et Koehler (2006) ont montré qu'elle souffre encore d'instabilité sur les valeurs faibles.
WAPE : la meilleure alternative à la MAPE pour le retail
La WAPE (Weighted Absolute Percentage Error) somme toutes les erreurs absolues et les divise par la somme de toutes les valeurs réelles. Elle traite le problème des valeurs proches de zéro différemment : les références à faible volume pèsent naturellement moins dans le calcul global, car leur contribution absolue est faible.
En pratique, la WAPE est la métrique préférée dans le retail et la prévision des ventes multi-références. Elle est directement interprétable comme un "pourcentage d'erreur sur le chiffre d'affaires total" - une lecture que les équipes commerciales et logistiques comprennent sans formation.
MASE : la métrique qui force à battre la baseline
Le MASE (Mean Absolute Scaled Error), introduit par Hyndman et Koehler en 2006, normalise l'erreur du modèle par l'erreur d'une prévision naïve calculée sur les données d'entraînement. Pour une série non saisonnière, la baseline naïve prédit simplement la valeur de la période précédente. Pour une série saisonnière, elle prédit la valeur de la même période de l'année précédente.
- MASE < 1 : le modèle bat la baseline naïve - il apporte une vraie valeur ajoutée.
- MASE = 1 : le modèle est équivalent à "prévoir la valeur passée".
- MASE > 1 : le modèle est moins bon que la baseline naïve. Signal d'alarme immédiat.
Le MASE est robuste aux valeurs nulles (le dénominateur utilise les erreurs de la baseline, pas les valeurs réelles), comparable entre séries de natures et d'échelles différentes, et il force une question que trop d'équipes évitent : "Est-ce que notre modèle vaut mieux que rien ?"
| Métrique | Unité | Valeurs proches de 0 | Comparaison inter-séries | Cas d'usage recommandé |
|---|---|---|---|---|
| MAE | Absolue | OK | Non | Reporting métier, erreurs uniformes |
| RMSE | Absolue | OK | Non | Pics coûteux, grandes erreurs pénalisées |
| MAPE | Pourcentage | A éviter | Oui | Séries sans zéros, reporting simple |
| sMAPE | Pourcentage | Risqué | Oui | Compétitions (M4), avec précaution |
| WAPE | Pourcentage | Mieux que MAPE | Oui | Retail multi-références, prévision ventes |
| MASE | Ratio | OK | Oui | Validation modèle, comparaison vs naïf |
La baseline naïve : le test minimum que tout modèle doit passer
Avant d'entraîner le moindre modèle - ARIMA, Prophet, réseau de neurones - construisez votre baseline naïve. Elle sert de plancher de performance : si votre modèle ne la bat pas, vous avez un problème.
Deux baselines naïves standard :
- Naive random walk : la prévision pour t+1 est la valeur observée en t. Convient aux séries sans saisonnalité marquée.
- Seasonal naive : la prévision pour t+1 est la valeur observée au même point de la saison précédente (même mois de l'année précédente, même jour de la semaine). Adapté aux séries saisonnières.
En pratique, la baseline naïve est plus difficile à battre qu'on ne l'imagine, surtout sur des horizons courts. Des études sur les compétitions Makridakis (M3, M4, M5) ont montré à plusieurs reprises que des modèles statistiques simples - Exponential Smoothing, Theta - surpassent les architectures deep learning complexes sur la plupart des séries réelles quand les données sont limitées. Un modèle MASE = 0,85 qui bat la naïve de 15 % représente déjà une valeur réelle en production.
Ordre de travail recommandé
1. Calculez la baseline naïve et son MASE (= 1 par définition). 2. Entraînez votre modèle. 3. Calculez le MASE du modèle sur le même test set. 4. Si MASE du modèle est inférieur à 1, le modèle apporte de la valeur. Si non, cherchez la cause avant d'aller plus loin.
Métriques probabilistes : la pinball loss pour les prévisions par intervalles
Un modèle de prévision peut produire une valeur unique (prévision ponctuelle) ou une distribution de probabilités - par exemple un intervalle de confiance ou des percentiles P10, P50, P90. Dans le deuxième cas, les métriques d'erreur classiques (MAE, MAPE) ne suffisent plus.
La pinball loss (quantile loss)
La pinball loss - aussi appelée quantile loss - évalue la qualité d'une prévision probabiliste à un quantile donné. Elle pénalise asymétriquement les erreurs selon le quantile cible : pour un quantile élevé (P90), sous-estimer est plus pénalisé que surestimer, et inversement pour un quantile bas (P10).
La formule pour un quantile q, une valeur réelle y et une prévision f :
- Si y > f (sous-estimation) : perte = q × (y - f)
- Si y <= f (surestimation) : perte = (1 - q) × (f - y)
En pratique, on calcule la pinball loss à plusieurs quantiles (P10, P50, P90) et on en fait la moyenne - c'est le Weighted Scaled Pinball Loss (WSPL) utilisé dans la compétition M5.
Quand utiliser les métriques probabilistes
La prévision probabiliste et la pinball loss deviennent pertinentes quand la décision métier dépend d'un intervalle, pas d'un point :
- Gestion des stocks avec asymétrie coût de rupture / coût de surstock.
- Planification de capacité industrielle avec marges de sécurité.
- Prévision de consommation énergétique pour les appels d'offres.
- Prévision financière avec Value-at-Risk.
Pour les modèles qui produisent nativement des intervalles (Prophet, LightGBM en mode quantile, modèles bayésiens), la pinball loss est la métrique d'évaluation adaptée. Pour les modèles ponctuels qui ne produisent qu'une valeur centrale, restez sur MAE/RMSE/MASE.
Backtesting temporel : validation croisée sans data leakage
Pourquoi le train/test split simple ne suffit pas
Découper un dataset séries temporelles en 80 % train / 20 % test et calculer les métriques sur le test set donne une estimation, mais une estimation fragile. Elle repose sur un seul bloc de données, souvent les 20 % les plus récents - qui peuvent avoir des caractéristiques atypiques (crise, saisonnalité inhabituellement forte). Si votre modèle performe bien sur cette période, rien ne garantit qu'il se comportera pareil sur les périodes suivantes.
Le backtesting temporel résout ce problème en simulant plusieurs déploiements successifs dans le temps, sur des fenêtres glissantes ou extensibles.
Fenêtre extensible (expanding window)
A chaque fold, le jeu d'entraînement s'agrandit : fold 1 entraîne sur les 12 premiers mois, fold 2 sur les 14 premiers, fold 3 sur les 16 premiers, etc. Le test est toujours la même durée (horizon de prévision). C'est l'approche qui reproduit le plus fidèlement le déploiement réel : avec le temps, on accumule plus d'historique.
Avantage : stabilité accrue car le modèle final voit plus de données. Inconvénient : les premiers folds avec peu de données peuvent être trop bruités pour être représentatifs.
Fenêtre glissante (sliding window)
A chaque fold, le jeu d'entraînement se déplace d'une fenêtre fixe - les 12 derniers mois, par exemple. Le modèle ne voit jamais les données trop anciennes. C'est utile quand les comportements récents comptent plus que l'historique lointain (changement de tendance, nouveau contexte concurrentiel, effet post-COVID).
Avantage : le modèle est toujours entraîné sur des données fraîches. Inconvénient : perte de contexte long-terme.
Le data leakage temporel : le piège le plus fréquent
Le data leakage temporel est la cause la plus fréquente de modèles qui semblent excellents en validation et décevants en production. Il survient quand des informations du futur contaminent l'entraînement, souvent de façon invisible.
Les formes les plus communes :
- Normalisation globale avant split : calculer la moyenne et l'écart-type sur l'ensemble du dataset pour normaliser les features. La moyenne inclut des données futures que le modèle ne devrait pas voir.
- Moyennes mobiles calculées sur tout le dataset : une moyenne mobile centrée (passé + futur) appliquée avant le split injecte des informations futures dans les features.
- Encodages cibles (target encoding) : encoder une variable catégorielle par la moyenne de la cible sur l'ensemble des données avant le split contamime avec la cible future.
- Features dérivées d'événements futurs : inclure un indicateur "promotion" calculé à partir d'un calendrier global intègre des promotions qui n'étaient pas connues au moment de la prévision.
La règle absolue : toutes les transformations de features doivent être calculées à l'intérieur de la boucle de validation, uniquement sur les données d'entraînement du fold courant, jamais sur l'ensemble du dataset.
Signal d'alerte data leakage
Si votre modèle performe nettement mieux en validation qu'en production, ou si les métriques sur le premier fold sont anormalement bonnes, cherchez un data leakage. Refaites le pipeline en appliquant toutes les transformations strictement à l'intérieur de la boucle de cross-validation.
Définir l'horizon de test cohérent avec l'usage réel
L'horizon de test de votre backtesting doit correspondre exactement à l'horizon de prévision que vous visez en production. Si vous prévoyez à 4 semaines, testez sur 4 semaines. Tester sur 1 semaine pour un modèle qui sera utilisé à 8 semaines donne des métriques trompeuses : l'erreur croît généralement avec l'horizon, et un modèle excellent à courte portée peut être médiocre à longue portée.
Checklist d'évaluation avant de déployer un modèle de prévision
Avant de valider un modèle pour la production, voici les points à vérifier systématiquement.
- Baseline naïve calculée : avez-vous comparé le modèle à une prévision naïve saisonnière ou non ? Le MASE est-il inférieur à 1 ?
- Métriques adaptées aux données : votre série contient-elle des valeurs nulles ou proches de zéro ? Si oui, évitez la MAPE ; utilisez MASE ou WAPE.
- Backtesting multi-folds : avez-vous évalué le modèle sur au moins 3 à 6 fenêtres temporelles différentes, pas seulement un test set unique ?
- Horizon cohérent : l'horizon de votre backtesting correspond-il à l'horizon de déploiement prévu ?
- Absence de data leakage : toutes les features sont-elles calculées à l'intérieur de la boucle de validation ? La normalisation est-elle faite par fold ?
- Cohérence métier : les métriques retenues sont-elles interprétables par les équipes qui prendront les décisions (logistique, finance, production) ?
- Prévision probabiliste si asymétrie des coûts : si le coût d'une sous-estimation est très différent du coût d'une surestimation, avez-vous calculé la pinball loss ou évalué des intervalles de confiance ?
Vous construisez un modèle de prévision ?
Un cadrage de 30 minutes pour choisir les bonnes métriques et structurer votre backtesting selon vos contraintes métier réelles.
Pour aller plus loin
- Comment les métriques ont guidé le choix du modele chez un distributeur horloger - mise en pratique sur un cas réel avec résultats chiffrés.
- Tableau de décision : quelle méthode de prévision selon votre contexte - ARIMA, Prophet, gradient boosting ou deep learning.
- Prévision zero-shot avec les foundation models de séries temporelles - TimesFM, Chronos-Bolt, Moirai et leurs performances réelles.
- Eviter le leakage quand on intègre météo, promos et jours fériés - variables exogènes et discipline de feature engineering.
- Isoler tendance et saisonnalité pour mieux interpréter ses métriques - STL, stationnarité et structure de la série avant l'évaluation.
- Top librairies de prévision de séries temporelles - Nixtla, Darts, Sktime, AutoGluon et leurs métriques natives.
- Prévision des stocks par IA pour les PME en 2026 - comment choisir les métriques selon l'asymétrie des coûts de rupture.
- IA prédictive sur mesure pour PME et ETI - notre offre d'accompagnement de la donnée au modèle en production.
- Hyndman et Koehler (2006) - Another look at measures of forecast accuracy - article de référence sur le MASE.
