Système intelligent de prévision et d'alerte sur la consommation de carburant
Des sites télécoms au Cameroun perdaient du gasoil sans que personne voie où. Le système prévoit ce que chaque site devrait consommer et signale ceux qui consomment plus. Les exploitants s'en servent toujours.
Vue d'ensemble
Pile : Python, Flask, Scikit-Learn, Pygal, Pandas
Déploiement : Render.com
Résultat : 84 617 litres de carburant tracés, et le compte rendu ramené de plusieurs jours à quelques secondes.
Les stations de base télécoms au Cameroun tournent sur des groupes électrogènes diesel, parce que le réseau tombe souvent et longtemps. Cela veut dire une forte consommation de carburant, du carburant qui disparaît, et un problème logistique que personne ne voyait assez nettement pour le régler. Ce projet a donné le tableau aux exploitants : ce que chaque site devrait consommer, et quels sites consomment davantage.
Le contexte du secteur et le défi
En 2018, il n'existait presque aucun travail d'apprentissage automatique visant les centrales de production dont dépendent les sites isolés. La recherche pointait vers les moteurs automobiles.
Porter les méthodes d'un domaine à l'autre. J'ai repris les techniques de modélisation de la consommation des véhicules et je les ai adaptées aux groupes électrogènes fixes. Cela a donné l'un des premiers systèmes de maintenance prédictive de la région pour des stations de base télécoms.
La solution technique
1. Le cœur d'apprentissage automatique
Le premier travail était une référence : ce qu'un site devrait consommer, dans ses conditions.
- Algorithme. Un régresseur Random Forest (Scikit-Learn).
- Performance. Efficience de Nash-Sutcliffe (NSE) de 0,986.
- Alerte sur écart. Le seuil se place à la moyenne plus 2 écarts-types. Un site au-dessus est signalé pour vérification, et l'équipe confirme l'alerte avant qu'elle déclenche une maintenance ou un changement logistique. L'objectif est un délai court entre l'apparition d'un écart et l'action de quelqu'un.
2. L'ingénierie et l'architecture (Flask)
L'application est déployée et tourne sur Render.com.
fuel_prediction_app/
├── columns_app.py
├── config.py
├── pkl_objects/
│ └── filename.joblib
├── uploads/
├── logs/
├── templates/
├── utils/
│ ├── file_utils.py
│ ├── validation_utils.py
│ ├── data_utils.py
│ ├── model_utils.py
│ ├── metrics_utils.py
│ ├── chart_utils.py
│ └── export_utils.py
└── routes/
├── main_routes.py
├── visualization_routes.py
└── export_routes.py Une conception modulaire
L'application utilise les Blueprints de Flask pour tenir la logique d'API à l'écart de la visualisation.
- utils/ garde une logique Python pure (validation, ingénierie des variables) sans dépendance au cadre web, donc testable unitairement hors d'un contexte Flask.
- routes/ traite les requêtes HTTP, avec les routes de visualisation séparées des routes d'export, pour que chaque fichier reste lisible.
- pkl_objects/ garde le modèle Random Forest, sérialisé avec Joblib et chargé en mémoire une seule fois au démarrage, plutôt qu'à chaque requête.
- Association dynamique des colonnes. La figure 1 la montre : l'utilisateur associe les colonnes de son propre jeu de données aux entrées du modèle, donc un tableur avec d'autres en-têtes fonctionne sans prétraitement. Les fichiers sources n'ont jamais nommé deux fois les choses de la même façon.
- Des graphiques dans le navigateur. Pygal produit des graphiques SVG légers qui restent interactifs dans la page.
Ce que montre le tableau de bord
L'application transforme la sortie du modèle en 4 vues sur lesquelles un responsable d'exploitation peut agir, toutes accessibles depuis la barre de navigation :
- Vue par grappe. La consommation de carburant agrégée par région.
- Vue par site (20 premiers). Les sites les plus consommateurs, pour que la maintenance aille là où elle rapporte.
- Analyse de distribution. Des histogrammes qui montrent la dispersion de la consommation.
- Séries temporelles. Les tendances de consommation dans le temps, là où les motifs saisonniers apparaissent.
La figure 3 montre la consommation prévue par grappe, ce qui reste le moyen le plus rapide de repérer une grappe qui s'emballe.
L'export et le compte rendu
Les audits et les présentations à la direction se font hors de l'application, donc elle exporte ce qu'ils demandent :
- Données brutes. Des fichiers CSV et Excel pour l'archivage et les analyses ultérieures.
- Graphiques. Des fichiers SVG et PNG en haute résolution qui se posent directement dans une présentation ou un rapport technique.
La valeur pour l'entreprise
- Maîtrise des coûts. Les écarts que le système a fait remonter ont permis de tracer 84 617 litres de carburant. C'est la vue en séries temporelles qui rend visible une dérive lente, à côté des variations saisonnières et des pics isolés.
- Logistique. La planification du carburant est passée devant le problème, et les livraisons d'urgence ont baissé.
- Efficacité. L'ingestion automatisée des journaux a fait passer le compte rendu de plusieurs jours à quelques secondes.
MLOps : la supervision en production
Un modèle livré sans supervision est un modèle auquel personne ne se fie six mois plus tard. L'application porte un tableau de bord de supervision qui rend compte de la chaîne pendant qu'elle tourne :
- Performance du modèle. Le score NSE sur le lot courant (0,981), pour qu'une baisse par rapport au 0,986 d'entraînement se voie au lieu de se déduire.
- Santé du système. Les taux de succès des API et la latence de traitement.
- Statistiques de cache. L'état du cache côté serveur, qui empêche les gros jeux de données de dépasser le délai sur l'offre gratuite de Render.com.