Climate & Carbon‑Aware Planner
Un planificateur domestique qui note chaque créneau de 30 minutes sur 48 heures selon le carbone, le prix, la météo et le confort — et associe un chiffre concret (£ économisés, kg CO₂ évités) à chaque recommandation. L’intensité carbone du réseau varie d’un facteur sept environ au fil de la journée ; le seul choix du moment suffit à faire passer un cycle lavage-séchage de ~1,6 kg à ~0,2 kg CO₂
- Problème — L’intensité carbone du réseau britannique varie plusieurs fois par jour (~50 à ~380 gCO₂/kWh), pourtant aucun outil ne traduit le carbone, le prix et la météo en un planning domestique
- Insight — Le seul choix du moment — même appareil, même charge — fait passer un cycle lavage-séchage de ~1,6 kg à ~0,2 kg CO₂
- Solution — J’ai développé seule un planificateur qui note chaque créneau de 30 min sur 48 h selon le carbone, le prix, la météo et le confort, avec des fenêtres nommées et des économies en £/kg pour 3 villes
- Résultat — En ligne sur greenhours.ontwrpn.com : 6 mois de développement, 5 flux gratuits, 30 tests réussis, ~£184/an et ~68 kg CO₂/an économisés par foyer londonien
Le conseil carbone classique porte sur ce qu’on achète. Personne ne parle du moment où on l’utilise
Un soir d’hiver, le réseau britannique tourne à ~380 gCO₂/kWh. À 3 h du matin un dimanche venteux, il descend à ~50 gCO₂/kWh — plusieurs fois moins. La plupart des foyers traitent ces deux créneaux à l’identique. Un cycle lavage-séchage de 4,2 kWh au pic du soir émet environ 1,6 kg CO₂. Le même cycle lancé dans un creux nocturne propre émet environ 0,2 kg CO₂. Ces 1,4 kg d’écart tiennent au seul moment choisi — même appareil, même charge, même énergie, juste une autre heure.
J’ai passé huit outils au crible avant d’écrire la moindre ligne de code. National Grid ESO affiche l’intensité carbone, mais sans prix ni planification. Octopus affiche les tarifs Agile, mais aucun signal carbone. Loop est uniquement historique. Home Assistant exige du matériel et une configuration technique. Ce qui manque : aucun outil ne fusionne carbone × prix × météo × confort en une fenêtre temporelle nommée assortie d’un chiffre d’économies — indépendant du fournisseur, sans matériel.
Le problème n’est pas la prise de conscience — les gens savent que le réseau varie. Le problème, c’est la traduction : une fenêtre nommée, un vrai montant en £, un vrai nombre de kg CO₂, sans aucune configuration
greenhours.ontwrpn.com — la grille de créneaux sur 48 heures et l’espace de travail du planificateur
Quatre semaines de recherche, sans code — sources de données, profilage des tâches, conception du modèle de scoring
Novembre 2025 a été consacré uniquement à la recherche. Semaine 1 : audit concurrentiel de 8 outils et évaluation des sources de données réseau. Semaine 2 : tests des API carbone pour le Royaume-Uni, la France et la Belgique, et contrôles de qualité des données. Semaine 3 : profilage énergétique des appareils — consommations réelles en kWh pour le linge, le lave-vaisselle, la charge VE, la ventilation. Semaine 4 : conception du modèle de scoring et choix d’architecture.
Le choix des sources de données a façonné toute l’architecture. L’UK Carbon Intensity API fournit une prévision régionale sur 48 heures — la seule source gratuite proposant de vraies données carbone prospectives à une granularité régionale de 30 minutes. La France (RTE éco2mix via ODRE) et la Belgique (Elia ods192) ne publient que des valeurs actuelles ; j’ai donc construit un proxy cyclique fondé sur l’heure de la journée pour leurs fenêtres prospectives. Electricity Maps couvre plus de 50 pays à une résolution de 15 minutes, mais derrière un palier payant. Open-Meteo gère la météo pour les trois villes, gratuitement et sans clé.
Quand j’ai intégré les vraies données Elia ods192 pour la Belgique, l’intensité carbone moyenne est passée de ~165 à ~87 gCO₂/kWh — presque la moitié. Le modèle initial n’était pas seulement imprécis : il se trompait systématiquement sur un réseau qui est nucléaire à ~40 %
Un moteur de scoring à 4 axes, un planificateur à fenêtre glissante et des fournisseurs de données interchangeables
La stack est volontairement minimale : backend FastAPI + Python, frontend React + Vite, pandas pour la grille de créneaux, SQLAlchemy sur SQLite en local et Postgres en production. Pas de file de messages, pas de processus workers, pas de base vectorielle. Les requêtes de planification s’exécutent en quelques centaines de millisecondes ; le brief hebdomadaire IA Groq, optionnel, ajoute ~1,5 s pour un seul appel LLM.
Un score composite unique de 0 à 100 par créneau de 30 minutes et par tâche, pondéré par l’utilisateur selon le mode. Mode Vert : carbone 55 %, prix 10 %, météo 35 %. Économiser : carbone 10 %, prix 55 %, météo 35 %. Équilibré : 33/33/34. Le confort est une porte stricte — pas un axe pondéré. Un créneau qui enfreint une contrainte (pluie pendant le séchage du linge en extérieur) est entièrement écarté, pas seulement pénalisé. Les recommandations ne sont jamais absurdes. Le planificateur à fenêtre glissante teste chaque départ valide dans la grille de 48 heures, applique les portes de confort et retourne une fenêtre principale plus une fenêtre de secours sans chevauchement. L’espace de recherche est minuscule — ≤192 créneaux × 5 tâches = 960 recherches par requête — donc un scan exact est plus rapide et plus auditable qu’un solveur.
Les routes async de FastAPI lancent en parallèle les 3 à 5 appels API amont par requête avec asyncio.gather. Un framework synchrone les sérialiserait, ajoutant ~1,5–2 s par requête. pandas gère le rééchantillonnage (les données horaires d’Elia ramenées à une résolution de 30 minutes en deux lignes) et le scoring vectorisé sur 192 créneaux. Compromis : ~40 Mo ajoutés à l’image Docker.
Fenêtres nommées, chiffres réels, trois villes — sans matériel, sans compte
En direct — sélectionnez une ville, choisissez une tâche et visualisez la fenêtre recommandée avec les £ et kg CO₂ économisés
Cartes de recommandations avec bandes de fenêtre recommandée sur la grille de 48 heures
Prévision sur 7 jours avec brief hebdomadaire généré par Groq
Comparaison des modes : Équilibré vs Vert vs Économiser
Les économies financières sont réservées au Royaume-Uni : elles viennent des tarifs demi-heure Octopus Agile, et la France comme la Belgique n’ont pas de flux de prix public gratuit équivalent. L’interface étiquette la devise par ville (£ vs €) pour qu’un chiffre ne soit jamais mal attribué. Le planificateur VE nocturne a demandé deux corrections — une contrainte naïve « même journée » rejetait entièrement les départs après minuit, et une revue de code ultérieure a révélé un bug plus subtil qui écartait en silence les créneaux les plus propres du petit matin. La vraie correction se cale sur un instant absolu d’ouverture de fenêtre, étayée par un test de régression. Un rappel que « ça marche sur le chemin heureux » et « c’est correct » sont deux affirmations différentes.
Environ ~£184/an et ~68 kg CO₂/an estimés par foyer londonien suivant les recommandations
Calculé à partir de données réseau en direct par rapport à une ligne de base définie (pic du soir britannique, 17:00–20:00). On suppose un seul foyer londonien suivant les recommandations de façon constante. Charge VE (intelligente vs brancher-et-oublier) : ~36 kg CO₂/an économisés. Séchage du linge à l’air (sèche-linge évité, 52 lessives) : ~32 kg CO₂/an économisés. Économie de coût VE (Agile nuit vs soir) : ~£125/an. Économie de coût linge (Agile heures creuses vs heures pleines) : ~£59/an. Pour 1 000 foyers britanniques suivant les recommandations VE + linge : ~68 tonnes CO₂/an — l’équivalent de retirer environ 15 voitures de la route.
Ce que je ferais autrement : démarrer avec Neon plutôt que Render Postgres (la politique de suppression à 90 jours est un piège dans lequel je suis tombée en plein milieu du projet). Mesurer avant d’optimiser — le moteur n’a aucune télémétrie sur le fait que les utilisateurs suivent ou non les fenêtres recommandées ; même un simple « avez-vous suivi ceci ? » binaire fermerait la boucle de rétroaction. Rendre la ligne de base explicite dans l’interface : un utilisateur qui planifie déjà à midi voit une économie moindre et pourrait se méfier du chiffre. Et repenser la bascule de mode comme un problème UX — qui choisit Équilibré à 09:00 voudra peut-être Vert à 22:00, quand la charge de nuit est quasi gratuite.
Faits de développement : 6 mois, en solo, de la recherche au déploiement. 3 villes (Londres, Paris, Anvers) avec des données carbone en direct. 5 types de tâches. 5 sources de données en direct, toutes en palier gratuit. 30 tests unitaires, tous réussis. Auto-hébergé sur Coolify (VPS personnel) ; £0 de coûts de données.
Sources
- National Energy System Operator — UK Carbon Intensity API (regional 48-hour forecast).
- Sukprasert et al. (2024). On the limitations of carbon-aware temporal and spatial workload shifting. ACM e-Energy. — les économies réelles dépendent des émissions marginales, et non moyennes, du réseau
