Prévision de la demande & du stock avec Prophet et LSTM

Anticiper les ventes, détecter les ruptures avant qu'elles n'arrivent, gérer simultanément saisonnalités hebdomadaires, mensuelles et événements calendaires. Retour sur une mission retail où nous avons atteint un MAPE de 4,2 % sur 12 semaines de forecast.

Le problème : prévoir ≠ juste lisser la courbe

Dans le retail, une erreur de prévision de 10 % ne se paie pas en points de marge : elle se paie en stocks morts stockés pendant des mois, ou en ruptures qui envoient le client chez le concurrent. La demande obéit à plusieurs forces qu'il faut modéliser ensemble :

• Saisonnalité hebdomadaire — pic le vendredi/samedi, creux le lundi.
• Saisonnalité annuelle — rentrée scolaire, Black Friday, Noël, soldes d'hiver/été.
• Événements calendaires — jours fériés, vacances scolaires par zone, ponts.
• Effets promotions — qui tuent la saisonnalité naturelle si mal modélisés.
• Tendance de fond — croissance ou déclin sur 18 à 36 mois.

L'approche : Prophet pour la robustesse, LSTM pour la finesse

Prophet (Facebook/Meta) sert de base. Il décompose le signal en tendance + saisonnalité + effets calendaires, avec une paramétrisation bayésienne qui tolère bien les données manquantes et les valeurs aberrantes. C'est parfait pour une baseline solide en quelques jours.

Mais Prophet a une faiblesse : il modélise mal les interactions non-linéaires entre variables (météo × promo, prix × concurrence). C'est là qu'un LSTM (Long Short-Term Memory) prend le relais. Entraîné sur les résidus de Prophet + des features exogènes (prix, promos, trafic magasin), il capte les signaux subtils.

La combinaison Prophet + LSTM en stacking bat chaque modèle pris seul sur tous nos benchmarks internes.

Résultats concrets

Les pièges que nous avons évités

1. Le sur-apprentissage sur les promotions passées

Un LSTM trop profond apprend par cœur les promos Black Friday 2024. Problème : les règles changent chaque année. Solution : régularisation forte (dropout 0.3), fenêtre glissante courte pour les événements exceptionnels, et modèle séparé pour les périodes "normales" vs "événements".

2. L'évaluation naïve sur train/test splits aléatoires

Un split aléatoire en time series fuit de l'information du futur dans le passé. Nous avons utilisé une validation temporelle glissante (walk-forward validation) : on entraîne sur les N premières semaines, on prédit la N+1, on décale, on recommence. C'est plus coûteux mais c'est la seule métrique qui prédit les performances en production.

3. Le MAPE aveugle aux périodes basses

Sur un produit qui se vend 2 fois par jour en moyenne, une erreur de 1 unité donne un MAPE de 50 %. Nous avons complété par le WAPE (Weighted Absolute Percentage Error) pondéré par le volume, qui donne une image plus honnête de la performance globale.

Pipeline de mise en production

Le modèle tourne en batch quotidien à 4h du matin sur un cluster Spark. Les prévisions sont poussées dans le MDM (Master Data Management) du client, qui déclenche les réapprovisionnements automatiques. Un seuil de confiance de 80 % sépare les commandes auto-validées des alertes envoyées aux category managers.

Monitoring : drift detection sur les features (PSI > 0,2 déclenche une alerte), et ré-entraînement automatique si le MAPE 7j dépasse 8 % deux semaines de suite.

Un bon modèle de forecast, c'est celui qui rend le category manager plus confiant dans ses décisions, pas celui qui le remplace.

Ce qu'il faut retenir

• Combiner Prophet + LSTM donne le meilleur des deux mondes : robustesse et précision.
• La walk-forward validation est non négociable sur des problèmes de time series.
• Le MAPE seul ne suffit pas : croisez-le avec WAPE et des métriques business (taux de rupture, stock mort).
• Le vrai ROI vient de l'intégration avec les outils métier, pas de la précision du modèle pris isolément.