I will use this GitHub Pages blog to share my journey in prototyping my data science ideas, as well as sharing my finds in the field of data science and machine learning. I will also share my thoughts on the latest trends in the industry.

I am excited to share my thoughts and experiences with you. Stay tuned for more updates!

What I did

• Image Docker etl-openmeteo:latest (~180 Mo)
• Entrypoint idempotent : ne réécrit pas les partitions existantes sans --force
• 90 jours d’historique sur 10 stations
• README : lancement local, variables d’env, structure Parquet

Résultat

MVP terminé. Consommable par notebook (pandas/pyarrow) ou DuckDB en lecture directe. Prochaine étape possible : brancher le modèle RC chauffage sur ces données.

Next steps

• Monitoring basique (alerte si job échoue 2 jours de suite)
• Lien avec RC Model for Home Heating

What I did

• Client HTTP avec backoff exponentiel (429 / 5xx)
• Schéma cible : station_id, timestamp, temp_c, humidity, wind_ms, source
• Écriture Parquet year=/month= sur 14 jours de backfill test
• Tests unitaires sur parsing JSON (3 cas limites)

Next steps

• Dockerfile + entrypoint python -m etl.run
• Logging structuré (JSON logs)
• Documentation README du pipeline

Les modèles énergétiques et géospatial du portfolio ont besoin d’une source météo fiable et rejouable. Open-Meteo offre une API gratuite — objectif : un pipeline reproductible vers Parquet.

Rough plan

1. Liste de 10 stations (lat/lon) en France
2. Job quotidien : forecast + archive → JSON
3. Normalisation schéma → Parquet partitionné

Open questions

• Orchestration : cron simple ou prefect léger ?
• Rétention : 90 jours rolling ?

→ Pipeline ETL météo Open-Meteo

What I did

• Série complète mars → août (5 dates exploitables)
• Médiane temporelle NDVI + écart-type pixel
• Carte interactive HTML + rapport PDF 2 pages (méthode + résultats)
• Validation visuelle QGIS sur 3 points terrain

Résultat

Projet terminé au stade notebook. Pattern saisonnier visible (pic NDVI juin). Données et scripts versionnés.

Next steps

• Option : coupler avec modèle de rendement (hors scope actuel)

What I did

• Script Python : lecture COG Sentinel-2, extraction B04 (rouge) et B08 (NIR)
• Masquage nuages via bande QA60
• NDVI calculé sur 3 dates (mars, avril, mai)
• Premiers GeoTIFF exportés dans data/processed/

Next steps

• Ajouter 2 dates été pour la série complète
• Carte folium avec slider temporel
• Vérifier les valeurs NDVI sur parcelle de référence (photo sol)

Besoin de se familiariser avec le traitement Sentinel-2 et les indices de végétation sur une zone agricole connue. Projet week-end étirable sur 2 semaines.

Rough plan

1. Télécharger 5 dates L2A sans nuages (tile 31TFK)
2. Calculer NDVI = (NIR - Red) / (NIR + Red)
3. Produire une carte de synthèse (médiane temporelle)

Open questions

• Copernicus Browser vs script Python pur ?
• Reprojection nécessaire ou rester en CRS native ?

→ Cartographie NDVI Sentinel-2

What I did

• Fenêtres horaires ajoutées sur 8 arrêts (contrainte soft via pénalité)
• Notebook final avec instructions de reproduction
• Export JSON des tournées + carte HTML autonome
• Tests sur 3 scénarios de demande (faible / moyenne / pic)

Résultat

Prototype terminé au stade prototype. Gain distance médian 14 % vs construction manuelle simulée. Pas de déploiement prévu — livrable = notebook + artefacts.

Next steps

• Idée future : brancher sur API de routage réel (OSRM)
• Ou archiver comme référence pour un cas client réel

What I did

• Génération d’un jeu de 25 arrêts autour de Lyon (coordonnées aléatoires contraintes)
• Modèle RoutingIndexManager + RoutingModel avec dimension capacité
• Première solution : distance totale 142 km → 118 km vs ordre naïf (+17 %)
• Export GeoJSON des polylines + carte folium

Next steps

• Ajouter contrainte fenêtre horaire sur 5 arrêts prioritaires
• Benchmark temps de résolution selon taille de flotte
• Documenter les paramètres du solveur dans le notebook

Une connaissance gère une petite flotte de livraison locale. Les tournées sont construites à la main dans Excel. Hypothèse : un solveur VRP pourrait réduire les km parcourus de 10–15 %.

Rough plan

1. Formaliser le VRP capacité + distance
2. Prototyper avec OR-Tools sur 20–30 arrêts fictifs
3. Visualiser les tournées sur une carte

Open questions

• Fenêtres horaires client : indispensables ou V2 ?
• Données réelles disponibles ou jeu synthétique pour le prototype ?

→ Hub projet : Optimisation de tournées VRP