Climatique

Rôle

En solo, de bout en bout ⁠— recherche produit, UX/UI, modélisation, rigging et rendu Redshift dans Cinema 4D, un monde temps réel en three.js, architecture système, FastAPI + pandas, React + Vite, intégrations de données et déploiement

Client

Produit auto-initié

Disciplines

Product Design · UX · Data · 3D · Motion

Année

2026

Un planificateur domestique qui classe des créneaux de 30 minutes sur les 48 prochaines heures selon le carbone, le prix, la météo et le confort. Il propose un créneau principal et un créneau de secours, avec des écarts modélisés en kg CO₂ et des économies sur les prix britanniques de l’électricité par rapport à une référence explicite.

Problème
Les outils examinés affichent des prévisions carbone ou des prix de l’électricité, sans les combiner avec la météo et le confort dans un planning domestique nommé
Insight
Le moment choisi peut modifier l’empreinte carbone estimée d’une tâche ; un créneau nommé et une référence explicite rendent ce choix concret
Solution
J’ai développé 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 écarts modélisés en kg CO₂ pour 3 villes et des économies en £ au Royaume-Uni
Résultat
En ligne sur climatique.app : tout le site est une petite planète en temps réel dont le ciel, la brume et le rouge-gorge suivent le réseau heure par heure, dans 3 villes avec 5 flux de données gratuits. Les économies sont comparées aux heures autorisées de la tâche elle-même : des chiffres modestes, mais défendables

Transformer les prévisions du réseau en un planning domestique

Exemple de calcul fondé sur l’intensité moyenne : à un cycle lavage-séchage de 4,2 kWh à 380 gCO₂/kWh sont attribués environ 1,6 kg CO₂ ; à 50 gCO₂/kWh, environ 0,2 kg. Ces valeurs illustrent le calcul, sans promettre une plage quotidienne ni représenter un résultat mesuré chez un foyer. Un calcul sur la moyenne du réseau n’établit pas les émissions marginales réellement évitées en déplaçant une tâche.

J’ai passé huit outils au crible avant d’écrire la moindre ligne de code. NESO (ex-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.

Ce qui manque est la traduction : un créneau nommé et une comparaison explicite avec une référence, sans matériel spécialisé

Climatique aujourd’hui : toute la page d’accueil est la planète, ici un soir à Londres

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.

Pour Londres, l’application demande une prévision régionale sur 48 heures à l’UK Carbon Intensity API, avec une résolution 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é.

Les données carbone pour la Belgique proviennent désormais des mesures Elia ods192. Les créneaux futurs utilisent une estimation explicitement fondée sur l’heure de la journée, au lieu du modèle carbone initial basé sur la météo.

Du tableau de données à une planète qui se lit

L’interface a connu trois étapes. La première organisait la ville, les priorités et les tâches autour d’un grand graphique de carbone et de prix. Le planificateur d’octobre donnait un créneau nommé à la recommandation et plaçait les conditions locales à côté d’une prairie botanique rendue. Depuis le 25 octobre, le planificateur est le monde lui-même : une planète plein écran, avec les commandes dans des panneaux de verre par-dessus. Ces écrans montrent l’évolution du design ; ils ne démontrent pas une amélioration mesurée de l’utilisabilité.

Étape 1 : l’ancien tableau de bord, une itération conservée avec des valeurs illustratives

Étape 2, 10 octobre 2026 : le planificateur à côté d’une prairie Redshift native

Un moteur de scoring à 4 axes, un planificateur à fenêtre glissante et des fournisseurs de données interchangeables

La stack est volontairement minimale : FastAPI + Python en backend, React + Vite en frontend, pandas pour la grille de créneaux, SQLAlchemy avec SQLite en local et Postgres en production. Sans file de messages, processus workers ni base vectorielle. Le résumé hebdomadaire Groq facultatif est distinct de la requête de planification.

Chaque tâche reçoit un score de 0 à 100 par créneau de 30 minutes. Lorsque les prix et les données météo propres à la tâche sont disponibles, Vert utilise carbone 55 %, prix 10 %, météo 35 % ; Économiser utilise 10 %, 55 %, 35 % ; Équilibré utilise 33/⁠33/⁠34. Des pondérations de repli distinctes s’appliquent aux données manquantes. Le confort est une contrainte stricte : un créneau incompatible, par exemple avec de la pluie pendant le séchage extérieur, est exclu. Le planificateur à fenêtre glissante retourne un créneau principal et un secours sans chevauchement. Un horizon de 48 heures contient 96 créneaux d’une demi-heure par tâche, une petite grille finie qui permet un balayage exact sans solveur.

Les appels aux fournisseurs sont asynchrones (httpx) et mis en cache par source. pandas joint les séries carbone, prix et météo, rééchantillonne les données météo horaires en créneaux d’une demi-heure et calcule les scores : carbone, prix et adéquation en colonnes vectorisées, les sous-scores météo ligne par ligne. Un index tenant compte des fuseaux sépare les heures locales du foyer des horodatages UTC des flux.

Fenêtres nommées, chiffres réels, trois villes ⁠— sans matériel, sans compte

Écrans capturés les 28 et 29 octobre 2026 sur le site en ligne, avec des données réelles. Les chiffres affichés sont la prévision du jour, pas des économies mesurées auprès de foyers. Sur la carte de recommandation, le pourcentage compare l’intensité du réseau au premier départ possible de la tâche ; les kg et les £ se comparent à la moyenne de tous les départs autorisés et, pour le linge séché à l’air, comptent le sèche-linge qu’on ne fait pas tourner, qui fait l’essentiel de l’économie.

climatique.app — aperçu en ligne
Démo en ligne
climatique.app
Ouvrir

En direct ⁠— le dock montre l’heure, son carbone, le mix électrique britannique et les 48 prochaines heures ; faites glisser le soleil ou faites défiler, puis demandez l’heure la plus propre

Les données à gauche, la réponse à droite, la planète entre les deux

Sur téléphone, le titre s’empile au-dessus de la planète et la barre du haut tient sur une ligne

Le plan en feuille ; le pourcentage se compare au premier départ possible

Paris, le 29 octobre : aucune prévision du réseau n’existe, la carte dit donc que les heures reprennent les jours récents et de quand datent les données ; pas de montant sans flux de prix

Les économies financières concernent uniquement le Royaume-Uni : elles proviennent des prix semi-horaires Octopus Agile, et la France comme la Belgique n’ont pas de flux public gratuit équivalent. L’interface indique la devise par ville (£ ou €) pour qu’aucun chiffre ne soit mal attribué. Le planificateur de recharge nocturne des VE a nécessité deux corrections : une contrainte naïve « même jour » rejetait tous les départs après minuit, puis une revue de code a révélé un bug plus subtil qui écartait en silence les créneaux les plus propres de la nuit. La vraie correction s’appuie sur un instant absolu d’ouverture de la fenêtre, avec un test de régression. « Marche dans le cas nominal » et « est correct » sont deux affirmations différentes.

Tout le site est un petit monde qui donne l’heure du réseau

La planète rend la réponse visible. Le soleil se trouve là où il est vraiment pour la ville choisie, placé par une formule astronomique ; la lune montre sa phase à un jour près, les étoiles et la prairie suivent la saison. La brume suit l’intensité carbone absolue, absente à 30 gCO₂/kWh et maximale à 350, car le score du planificateur est relatif à la fenêtre de 48 heures et ferait paraître enfumé le réseau très propre de Paris. Le score relatif règle plutôt la floraison.

Midi, air pur : une image du monde en direct, pas un rendu

Le même code à 350 gCO₂/kWh ou plus : la brume montre la saleté de l’électricité, pas la qualité de l’air

Ce rouge-gorge familier, je l’ai modélisé, riggé et animé dans Cinema 4D, puis exporté en glTF et compressé à environ 319 Ko à la livraison. Il vit à l’heure de la planète : il picore le jour, chante à l’aube et dort la nuit. Quand on demande l’heure la plus propre, il cherche depuis son poteau pendant le chargement du plan, puis fait un rapide tour de la planète, se pose et chante pendant le créneau recommandé tandis que les fleurs s’ouvrent. Le vent, la pluie et le gel changent sa posture.

Le rouge-gorge sur son poteau, en gros plan dans le monde en direct

Autour : un paysage sonore facultatif généré à la volée avec la Web Audio API (vent, pluie, un bourdonnement du réseau qui devient plus rugueux avec la brume, des oiseaux qui suivent le rouge-gorge), une carte postale à partager rendue par un second monde hors écran, un court accéléré qui avance l’horloge du monde jusqu’à l’heure recommandée, une bande du mix électrique pour Londres et une page /story qui explique d’où viennent les chiffres. Une échelle de qualité protège l’appareil : le monde ne remplace l’affiche qu’au-dessus de 50 fps sur ordinateur ou 28 fps sur téléphone, réduit la résolution de rendu quand les images ralentissent et revient à l’affiche plutôt que de saccader. Le profil mobile reste sous 380 000 triangles.

Une prairie vivante, composée dans Cinema 4D et rendue avec Redshift

La planète donne une forme tangible et vivante à un signal carbone abstrait. J’ai composé la scène dans Cinema 4D à partir de modèles botaniques : un tapis continu de trèfle, des graminées, des groupes de lavande, des marguerites blanches, de petites fleurs jaunes et des fleurs de trèfle roses. Les variations d’échelle, de rotation et de regroupement évitent la répétition, tandis que la végétation basse comble les espaces sur la sphère.

Image finale du rendu Redshift ⁠— végétation en couches et lumière directionnelle douce

Vue de travail Cinema 4D ⁠— les aperçus allégés gardent la scène dense manipulable

Les cloneurs Multi-Instance réutilisent la géométrie des plantes au lieu de la dupliquer sur la sphère. Une lumière chaude en haut à gauche, un éclairage frontal large et une lumière de ciel douce détachent les fleurs du feuillage. L’animation de vent courbe la végétation avec des phases variées tout en gardant les racines ancrées ; la boucle originale comporte 240 images à 30 fps, rendues depuis une source de 1024 × 1024 pixels.

La boucle de vent Redshift de 8 secondes, exportée depuis la séquence d’images originale

Le rendu Redshift a été le premier visage de la planète. Aujourd’hui, l’affiche visible avant le démarrage du monde en temps réel, et le repli s’il ne peut pas tourner, est une image fixe du monde en direct lui-même. La planète en direct est une nouvelle construction en three.js, pas une conversion de la scène Redshift : plantes procédurales dessinées en instances, vent dans un vertex shader, prairie et atlas de nuages générés dans un web worker, hors du fil principal.

Le même système visuel, du planificateur au plus petit écran

Les titres The Seasons 700, les textes Manrope et les icônes Streamline Flex Line réunissent le produit dans un système cohérent de typographie, d’espacement et de commandes. Les modes sélectionnés gardent les mêmes retours à la ligne et dimensions. Les réglages compacts et l’édition des tâches partagent un dialogue avec prise en charge de Retour et restauration du focus ; la visite suit la cible visible lorsque la mise en page change. La page 404 reprend la même identité et offre un chemin de retour clair.

Version du 10 octobre : accueil sur écran étroit ⁠— hiérarchie typographique lisible et illustration originale

Une véritable réponse HTTP 404 avec une action de retour claire

La version d’octobre a passé des contrôles automatisés de clavier, de contraste, d’adaptation aux écrans, de routes et de sécurité, en plus des tests applicatifs. Une courte vérification instrumentée sur un iPhone 15 Pro a confirmé le fonctionnement du moteur mobile. L’écoute VoiceOver/NVDA, le défilement au doigt avec la barre Safari mobile et l’amélioration du chargement restent à vérifier ; il s’agit d’une revue technique et experte, pas d’un test utilisateur ni d’une certification d’accessibilité.

Supprimer mon propre modèle quand les données réelles l’ont contredit

La Belgique utilisait initialement un modèle carbone basé sur la météo, faute de flux prospectif gratuit dans l’intégration. Le fournisseur actuel lit les mesures Elia ods192 fondées sur la consommation et construit une estimation explicitement fondée sur l’heure de la journée pour les créneaux futurs. J’ai supprimé la voie carbone basée sur la météo pour éviter son retour silencieux comme repli. La source devient traçable, tandis que les créneaux futurs restent une estimation de tendance et non une prévision fournie par le gestionnaire du réseau.

Une décision plus petite traverse tout le planificateur. Un créneau qui viole une contrainte dure, comme de la pluie pendant un séchage du linge en extérieur, est exclu purement et simplement plutôt que pénalisé dans le score. Une pénalité laisse un mauvais créneau classable et permet à un total flatteur de recommander une action que l’utilisateur ne peut manifestement pas faire. L’exclusion est moins élégante et plus difficile à régler. C’est aussi pourquoi les recommandations survivent au contact de la météo.

C’est sur le planificateur de recharge nocturne que ce principe a été le plus dur à tenir. Une contrainte naïve de même journée rejetait entièrement les départs après minuit, et une revue de code ultérieure a mis au jour un bug plus subtil qui écartait silencieusement les créneaux les plus propres des petites heures, précisément celles que la fonction existe pour trouver. Les deux ont été corrigés plutôt que contournés. Un planificateur qui saute en silence la meilleure réponse est pire qu’un planificateur qui admet n’en avoir aucune.

Des chiffres plus petits, mais défendables

Un audit du 28 octobre a changé ce que le planificateur affirme. Les économies étaient comparées au pic britannique du soir, 17:00–⁠20:00, quelle que soit la tâche ; une recharge nocturne de VE semblait ainsi économiser 0,55 kg CO₂ et £1,43. Elles sont désormais comparées à la moyenne de toutes les heures où la tâche pouvait être lancée, ce qui ramène la même recharge à environ 0,1 kg et £0,01, selon la prévision du jour. J’ai retiré l’ancienne estimation annuelle (~£184 et ~68 kg CO₂ pour un foyer londonien), car elle reposait sur l’ancienne référence. Paris et Anvers indiquent maintenant l’âge de leurs données réseau, considèrent comme périmées les données de plus de 48 heures, et l’aperçu hebdomadaire ne classe que les jours qui ont une vraie prévision.

L’aperçu sur 7 jours après l’audit : seuls les jours couverts par la prévision à 48 heures reçoivent un score carbone ; les autres affichent « no carbon forecast » au lieu de deviner

Ce que je ferais autrement : choisir la référence honnête dès le départ et instrumenter la boucle de retour plus tôt. L’historique propre au navigateur propose « Suivi » et « Non suivi », avec vérification du propriétaire, mais cela ne démontre pas des économies réelles. Prochaines étapes : valider les recommandations avec des participants, réunir un jury blanc avant les candidatures aux prix et étudier des flux de prix locaux pour la France et la Belgique.

Faits de développement, actualisés le 29 octobre 2026 : 6 mois pour le cœur du produit, puis le monde temps réel à partir de mi-octobre. 3 villes (Londres, Paris, Anvers), 5 types de tâches et 5 sources de données gratuites. Lighthouse 12 mobile en production, derrière Cloudflare : 78 à 82 sur huit mesures le 28 octobre (LCP de 3,3 à 3,8 s) ; l’objectif de 90 n’est pas encore atteint. Auto-hébergement sur Coolify avec Postgres interne et sauvegardes nocturnes de la base ; aucun coût d’abonnement aux données.

Sources

Projet suivant
Wanderwort