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

Ce que j'ai mis en œuvre

J'ai pris en charge le cycle de vie complet du modèle (données → modèle → API → cloud → monitoring → ré-entraînement). Pour faire tenir la stack sur une instance dotée de 1 Go de RAM, j'ai allégé l'image Docker et sécurisé les accès cloud sans clés statiques.

Pilotage : nous avons conduit le projet en mode agile (Scrum/Kanban, backlog, KPIs) et produit les livrables de cadrage (cahier des charges, registre des risques), le plan de tests et le runbook de mise en production.

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 j'ai mis en œuvre

J'ai traduit le besoin métier en architecture de données, puis industrialisé les règles de gestion dans des pipelines supervisés. Les équipes utilisent l'outil au quotidien pour piloter la collecte et simuler leurs scénarios. Le modèle reste simple, avec une priorité donnée à la fiabilité et à l'autonomie des utilisateurs.

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 j'ai mis en œuvre

J'ai travaillé sur des données géospatiales, des images satellite et des séries temporelles incomplètes. J'ai validé le dataset sur neuf axes d'analyse, puis mesuré l'apport de l'imagerie par une étude d'ablation. Ce projet complète MilkCast par un travail davantage orienté R&D.

Le problème

La pneumonie reste l'une des premières causes de mortalité infectieuse dans le monde. Son diagnostic repose sur la lecture de radiographies thoraciques, un examen courant mais dont l'interprétation varie selon l'expérience du praticien. Un outil d'aide au pré-screening automatisé permettrait de prioriser les cas suspects et de réduire le risque de diagnostic manqué.

Démarche

Le dataset Chest X-Ray Images (Kermany et al., 2018) contient 5 856 radiographies réparties en deux classes : Normal et Pneumonia, avec un déséquilibre de 2,89x en faveur de la classe pathologique.

• Transfer learning : backbone ResNet-18 pré-entraîné sur ImageNet, couches convolutives gelées. Seule la tête de classification est entraînée (Dropout 0,3 + couche linéaire 512 → 2).
• Augmentation : retournement horizontal, rotation ±10°, variation de luminosité et contraste pour compenser le déséquilibre et améliorer la robustesse.
• Entraînement : Adam (lr=10⁻³), scheduler ReduceLROnPlateau, early stopping (patience 4). Meilleur modèle sauvegardé à l'époque 11 sur 15.
• Explicabilité : Grad-CAM sur la dernière couche convolutive, pour visualiser les zones de l'image qui déclenchent la prédiction.

Résultats sur le jeu de test

Sur 624 radiographies jamais vues, le modèle atteint une AUC de 0,956 avec un intervalle de confiance bootstrap à 95 % de [0,938 ; 0,973]. La sensibilité élevée (96,7 %) est prioritaire en contexte clinique : le modèle manque très peu de pneumonies.

La matrice de confusion confirme le compromis : 377 vrais positifs contre seulement 13 faux négatifs (pneumonies manquées), au prix de 46 faux positifs (normaux signalés), ce qui est acceptable en pré-screening où chaque cas signalé est revu par un praticien.

Explicabilité : Grad-CAM

Pour chaque prédiction, Grad-CAM produit une carte d'activation sur la dernière couche convolutive du réseau, révélant les régions de l'image qui ont le plus pesé dans la décision. Les zones chaudes (rouge/jaune) concentrées sur les opacités pulmonaires confirment que le modèle a appris des motifs cliniquement pertinents.

API de prédiction

Le modèle est servi par une API REST FastAPI avec documentation Swagger auto-générée. L'endpoint /predict/gradcam retourne la prédiction, les probabilités par classe et la carte Grad-CAM encodée en base64, consommée par un dashboard interactif intégré pour la prédiction en direct.

Ce que j'ai mis en œuvre

J'ai construit un pipeline complet de vision par ordinateur appliquée à la santé : du choix d'architecture au déploiement en API, en passant par l'évaluation statistique rigoureuse (bootstrap, intervalle de confiance) et l'explicabilité. Le projet illustre comment le deep learning peut assister le diagnostic médical tout en restant interprétable.