Comment une major européenne de l'énergie a économisé 500K€/an grâce au forecasting IA
Du Excel-basé sur règles à un Random Forest en production · 400 variables · 92 % de précision · 12 semaines
TL;DR
- Forecasting basé sur Excel + règles, équipe de 4 analystes consacrant 60 % de leur semaine à des tableurs.
- Random Forest sur 400 variables (météo, historique, types de contrat, géo, jours fériés) → 92 % de précision vs 78 % baseline.
- Production en 12 semaines : Python + scikit-learn, pipeline batch quotidien, monitoring + détection de drift.
- Résultat : −35 % de coûts logistiques en pilote, 500K€ d'économies annuelles extrapolées.
Le contexte
Une major européenne de l'énergie — 2M+ clients résidentiels et B2B en France, ~1 500 camions, distribution de propane en vrac. Marché ultra-saisonnier (pics hivernaux × 3 vs été), réglementé, où la supply chain représente le premier poste de coût. Carburant, chauffeurs, stocks de dépôt : tout dépend d'un forecast fiable.
Le problème
Le forecast existant tournait sur Excel et 4-5 scripts Python basés sur règles. Les analystes (4 personnes) passaient 60 % de leur temps à reconstruire les fichiers chaque semaine — peu de temps réel pour analyser les écarts. Trois conséquences directes :
- Sur-stockage dans les zones à faible demande (capital immobilisé).
- Ruptures dans les zones à forte demande → livraisons d'urgence à 2-3× le coût standard.
- Camions "deadheading" (retour à vide) à cause de routages bâtis sur de mauvais forecasts.
L'erreur de forecast coûtait ~5-8 % du budget logistique total. Sur des centaines de millions d'euros de logistique annuelle, le calcul est vite fait.
Pourquoi les solutions du marché ont échoué
Avant moi, deux pistes avaient été explorées et abandonnées :
- BI "forecast en un clic" : les outils SaaS proposent du forecast time-series univarié. Sur un produit saisonnier multi-zones avec 400 variables exogènes, les résultats étaient pires que la baseline humaine.
- Deep learning : un POC interne sur LSTM avait tourné 4 mois, atteint 87 % de précision, mais aucune équipe métier n'arrivait à comprendre les sorties. Adoption nulle, projet enterré.
La leçon : la précision n'est pas la métrique. C'est l'adoption × la précision. Un modèle à 87 % que personne n'utilise vaut moins qu'un modèle à 85 % que toute l'équipe ops adopte.
L'approche
Quatre décisions d'architecture, chacune motivée par le contexte business :
1.Random Forest plutôt que XGBoost ou Deep Learning
RF est interprétable (feature importance directe + SHAP), robuste aux données manquantes (huge dans le réel), rapide à ré-entraîner (1h hebdo) et performe quasi aussi bien que XGBoost sur ce type de données structurées. L'équipe métier pouvait débugger un forecast en 2 minutes.
2.Forecast à la zone × jour, pas global
Le business raisonne en "dépôt × jour de livraison". Aligner la granularité du modèle sur celle de la décision opérationnelle a doublé l'adoption.
3.Pipeline batch quotidien, pas temps réel
La planification logistique se décide la veille pour le lendemain. Pas besoin de streaming. Un cron à 4 h du matin, sortie dans le data warehouse, lecture par l'outil de planning à 6 h. Simple et robuste.
4.Monitoring + drift detection dès le J1 de prod
Distribution des features trackées vs base train, alerte Slack si drift > 2σ. La météo change, les prix changent, la pandémie casse les patterns : sans monitoring, le modèle dérive en silence.
Implémentation · 12 semaines
Semaines 1-2 · Diagnostic & data audit
12 systèmes sources analysés, 400+ variables identifiées (vente, météo, contrats, géo, holidays, économique). 60 entretiens en 2 semaines avec ops, IT, finance, commerce. Document : 1 schéma de bout en bout, 1 baseline mesurée à 78 %.
Semaines 3-6 · Modèle baseline & validation
Random Forest + cross-validation glissante 12 mois. Itération sur 8 versions de feature engineering. Choix final : 400 features, ensemble RF + corrections post-hoc pour les jours fériés et les pics climatiques.
Semaines 7-9 · Pipeline production
Python + scikit-learn sur AWS. Cron quotidien, écriture data warehouse, retraining hebdomadaire. Tests d'intégration avec l'outil de planning. Documentation handoff (50 pages) pour l'équipe data interne.
Semaines 10-12 · Rollout progressif & training
10 % du volume (3 dépôts pilote) semaine 10, 50 % semaine 11, 100 % semaine 12. Comparaison vs groupe contrôle à chaque étape. 2 bugs critiques détectés et corrigés en pilote — invisibles en synthétique.
Résultats mesurés
Mesurés sur les 6 premiers mois de production (vs 6 mois précédents, même saisonnalité) :
- Précision forecast : 78 % → 92 % (+14 pts)
- Coûts logistiques : −35 % en pilote, −22 % rollout complet (effet dilué sur zones moins forecastables)
- Économies annuelles : 500K€ extrapolées plein run
- Temps analyste : 60 % spreadsheet → 15 % (le reste passe en analyse de scénarios à valeur ajoutée)
- Time-to-value : 12 semaines kickoff → première livraison en prod
Leçons
L'interprétabilité n'est pas un nice-to-have
Sans elle, l'équipe métier ne fait pas confiance, et le modèle finit en placard. RF + SHAP ont rendu chaque forecast "débuggable" en 2 minutes — c'est ce qui a fait passer l'adoption de 30 % à 95 %.
Les données réelles sont 20 % plus sales que le dev set
Lors du rollout, on a découvert : timezones inconsistants entre 3 systèmes, contrats anciens avec champs vides, jours fériés régionaux non documentés. Si vous testez uniquement sur du synthétique, vous découvrez ces bugs en client.
Le rollout progressif a sauvé le projet
Les 2 bugs critiques détectés en pilote 10 % auraient bloqué les opérations à 100 %. Conclusion : ne jamais lancer 100 % le J1, peu importe la pression du sponsor.
Le doc de handoff vaut plus que le modèle
6 mois après mon départ, l'équipe data interne a re-entraîné le modèle, ajouté 30 features, étendu à 2 nouveaux pays. Sans le handoff de 50 pages, le projet aurait stagné.
Stack technique
Vous avez un cas similaire ?
Si vous avez un problème de forecasting, supply chain, classification ou extraction où l'IA pourrait débloquer un goulot, parlons-en. Diagnostic gratuit 15 min, sans engagement.