Projets.

Le problème

Anticiper la consommation électrique est un enjeu critique pour l'équilibrage du réseau. À partir des données publiques RTE éco2mix (2012-2024), j'ai construit un modèle capable de prédire la consommation moyenne d'une journée à partir de la seule date, en exploitant la saisonnalité, les cycles hebdomadaires, les jours fériés et l'historique récent.

Démarche Data Science

Côté données, 15 features construites : encodage cyclique (mois, jour de l'année, jour de la semaine en sin/cos), week-end, jours fériés français, lags (J-1, J-7, J-30, J-365) et moyennes glissantes (7 et 30 jours).

Sept approches comparées sur un découpage strictement temporel (train 2013-2021 / validation 2022 / test 2023-2024), toutes tracées dans MLflow pour une comparaison reproductible et auditable :

Résultats sur la période de test

Sur les 731 jours jamais vus (2023-2024), la prédiction épouse la consommation réelle, pic hivernal comme creux estival, pour un MAPE de 2,37 %. Moyennes mensuelles, en gigawatts moyens par jour :

Mise en production : le cœur du projet

• API REST FastAPI : endpoints de prédiction (date unique, plage jusqu'à 365 jours), d'exploitation (/health, /system, suivi de la qualité dans le temps), auth optionnelle par clé d'API, doc Swagger auto-générée.
• Docker : image allégée dédiée à l'API (sans Keras/TensorFlow) pour tenir sur une petite instance ; docker-compose orchestrant API + MLflow + Prometheus.
• Déploiement AWS EC2 (t3.micro, eu-west-3) : 1 worker uvicorn, swap, IP fixe (Elastic IP), HTTPS via reverse proxy Caddy (Let's Encrypt). Pipeline de données sur S3 via rôle IAM d'instance, aucune clé statique.

Le pipeline GitLab CI/CD couvre tout le cycle de vie, ré-entraînement quotidien inclus, avec mise en prod conditionnée à un seuil de qualité (MAPE < 3 %) :

Maintenabilité & monitoring

• Détection de data drift via le PSI (Population Stability Index), rapport JSON archivé, branché en CI en mode alerting.
• Observabilité Prometheus : latence, volumétrie, codes HTTP par endpoint, métriques métier et système (RAM/CPU).
• Tests automatisés : smoke tests de l'API + test de charge Locust ; manifests Kubernetes (HPA) pour démontrer une cible scalable.
• Conformité RGPD documentée et exposée (/rgpd) : aucune donnée personnelle (open data + variables calendaires).

Chaque ré-entraînement mensuel est tracé : le MAPE de test reste stable bien sous le seuil de mise en prod (3 %), condition de promotion automatique du modèle :

La détection compare la distribution de référence (2012-2021) à l'année courante via le PSI. En 2024, toutes les variables franchissent le seuil d'alerte (0,25) : la consommation a structurellement baissé (crise énergétique de 2022, sobriété). C'est précisément ce signal qui déclenche l'alerte et légitime le ré-entraînement automatique.

En production, pour de vrai

Au-delà des graphiques ci-dessus, la solution tourne réellement sur le cloud. Quelques captures de la stack en fonctionnement :

Ce que ce projet démontre

La maîtrise du cycle de vie complet d'un modèle (données → modèle → API → cloud → monitoring → ré-entraînement) et un sens de l'ingénierie sous contrainte réelle : faire tourner toute une stack sur une instance à 1 Go de RAM, optimiser l'image Docker, sécuriser les accès cloud sans clés statiques. Le projet a aussi été piloté en mode agile (Scrum/Kanban, backlog, KPIs) avec des livrables formels (cadrage, plan de tests, runbook).

Le problème

Le pilotage de la collecte laitière est une activité critique, encadrée par un contrat annuel à fort enjeu financier et une tolérance d'erreur faible. Le processus historique reposait sur un tableur rempli manuellement depuis l'ERP métier : risque d'erreurs de saisie, absence de référentiel commun entre collaborateurs, extractions chronophages à faible valeur ajoutée, et aucune capacité de simulation prospective.

Ma démarche

• Cadrage et pilotage : expression de besoin formalisée avec le métier, découpage en trois lots successifs, registre des risques et suivi Jira, chiffrage validé par la direction.
• Rétro-engineering de l'ERP : identification des tables sources permettant de reconstituer l'historique complet des volumes par producteur.
• Pipeline serverless : quatre jobs Python (AWS Lambda + S3), chacun défini par un data contract et ordonnancé automatiquement : historique mensuel, référence annuelle, référentiel géographique et projection.
• Modèle de projection : baseline par coefficients de variation saisonniers calibrés sur l'historique de chaque producteur, avec repli sur la moyenne globale pour les nouveaux entrants, projetée sur 36 mois glissants.
• Restitution : tableaux de bord Qlik Cloud permettant aux équipes de comparer la trajectoire à la cible contractuelle et de simuler des scénarios (crises sanitaires, aléas climatiques).
• RGPD : minimisation des données dès la conception, seules les tables et colonnes strictement nécessaires sont ingérées.

Le pipeline de données

Quatre traitements serverless s'enchaînent chaque jour, chacun cadré par un data contract et ordonnancé automatiquement, de l'extraction jusqu'aux tableaux de bord consultés par le métier.

Ce que ce projet démontre

L'ensemble des compétences attendues d'un chef de projet data : traduire un besoin métier critique en architecture de données fiable, industrialiser des règles de gestion en pipelines supervisés, et livrer un outil que les équipes utilisent réellement au quotidien. La valeur ne vient pas de la sophistication du modèle, mais de la fiabilité et de l'autonomie rendues au métier.

Le problème

La planification des récoltes qui alimentent les usines de transformation dépend d'une anticipation fine, à quelques jours près, de la date de récolte et du rendement de chaque parcelle. Les modèles existants, entraînés par stade phénologique sur les campagnes historiques, restaient fragiles face aux phénomènes climatiques extrêmes et manquaient d'un signal mesuré directement sur la parcelle.

Ma démarche

• Consolidation du dataset : intégration de données pédologiques ouvertes (SoilGrids, ISRIC) et météorologiques, refonte du feature engineering (indicateurs de stress hydrique et thermique, cumuls et fenêtres glissantes).
• Clusters de variétés : regroupement de plus d'une centaine de variétés par K-means (méthode du coude + silhouette score) pour éviter la fragilité des modalités rares.
• Pipeline satellite : interrogation du catalogue STAC public de Sentinel-2, lecture des fichiers COG par requêtes HTTP partielles (sans télécharger les scènes complètes), calcul des indices NDVI, EVI, NDWI, SAVI par parcelle et par date.
• Reconstruction des nuages : une part importante des passages étant masquée, un modèle XGBoost dédié reconstruit les indices manquants, avant densification en grille quotidienne du semis à la récolte.
• Optimisation : traitement par lots par tuile satellite, parallélisation des entrées-sorties, mise en cache des transformations géographiques.
• Étude d'ablation : deux modèles identiques entraînés avec et sans variables satellites pour quantifier objectivement l'apport de l'imagerie sur la prédiction de rendement, décisif en fin de cycle.

Le signal mesuré sur la parcelle

Le pipeline reconstruit, pour chaque parcelle, une courbe quotidienne d'indice de végétation. On y lit la dynamique de croissance : un NDVI faible et stable au début, puis une montée marquée à partir de la floraison (autour de 50 jours), jusqu'à un plateau avant la récolte. C'est ce signal, absent des seules données météo et pédologiques, qui manquait aux modèles.

Agrégé sur sept campagnes (2017 à 2023), ce même motif se répète d'une année sur l'autre : le signal monte régulièrement du semis à la fin de cycle. Une régularité qui en fait une variable explicative fiable pour la prédiction.

L'apport, mesuré par ablation

Pour ne pas surestimer l'intérêt du satellite, j'ai comparé deux modèles identiques, l'un entraîné avec les variables satellites, l'autre sans. L'écart d'erreur (MAE) sur le rendement, en fin de cycle, mesure l'apport réel de l'imagerie selon l'horizon avant récolte.

L'apport culmine autour de J-10, précisément le moment où se prennent les décisions de planification industrielle. C'est cette fenêtre qui justifie tout le pipeline satellite.

Ce que ce projet démontre

Du Machine Learning appliqué sous contraintes réelles : données géospatiales, imagerie satellite, séries temporelles incomplètes, et une démarche scientifique rigoureuse (validation du dataset sur neuf axes d'analyse, apport quantifié par ablation plutôt qu'affirmé). C'est le versant R&D de mon profil, complémentaire du pilotage de MilkCast.