Outre-Manche, les développeurs disposent depuis des années de carbonintensity.org.uk : une API publique qui dit, en temps réel, combien de CO₂ émet un kilowattheure d’électricité sur le réseau britannique. On s’en sert pour décaler la recharge d’une voiture, planifier des traitements lourds, afficher l’empreinte d’un service. C’est devenu une brique d’infrastructure.
En France, la donnée existe — et elle est même excellente. RTE publie l’intensité carbone du réseau au pas de quinze minutes, en open data, via éCO2mix et ODRÉ. Mais elle reste brute, plafonnée en nombre d’appels, et sans prévision d’intensité. Pour un développeur qui veut juste « savoir si c’est le bon moment pour lancer un calcul », il y a un fossé entre cette donnée et un usage réel.
C’est ce fossé que carbon-fr vient combler : l’équivalent français de carbonintensity.org.uk, bâti sur les données ouvertes RTE/ODRÉ — souverain, open source et auto-hébergeable.
Pourquoi ça compte, concrètement
L’intensité carbone française n’est pas constante : selon le vent, le soleil, la demande et les imports, un kWh peut être nettement plus ou moins propre d’une heure à l’autre. Quand on peut décaler une consommation, ça ouvre des leviers très concrets :
- recharger un véhicule électrique au creux carbone de la nuit plutôt qu’au pic du soir ;
- planifier un batch de calcul, une sauvegarde, un entraînement, quand l’électricité est la plus propre ;
- afficher honnêtement l’empreinte temps réel d’un service numérique.
Rien de tout ça n’est faisable si la donnée n’est pas interrogeable simplement, par une machine, à la demande.
Ce que c’est, en 30 secondes
Pas de compte à créer, pas de clé à demander. Une ligne :
curl https://carbon-fr-api.kovelt.fr/v1/intensity/now
{
"region": "national",
"methodology": "rte-direct",
"intensity": { "value": 21, "unit": "gCO2eq/kWh" },
"updated_at": "2026-06-17T13:45:00Z"
}
Et si vous préférez voir avant de coder, il y a un tableau de bord en direct : la carte live.
L’API couvre le national et les douze régions métropolitaines, l’historique, les statistiques, le mix de production, les prévisions, les créneaux les plus bas-carbone, les échanges transfrontaliers, un flux temps réel (SSE) et des webhooks. Le tout documenté en OpenAPI 3.1, avec un Swagger servi sur /docs et un SDK TypeScript (@carbon-fr/sdk).
Les vrais problèmes à résoudre
Si carbon-fr n’était qu’un proxy au-dessus d’ODRÉ, ça ne mériterait pas un billet. Trois problèmes ont demandé de vrais choix.
1. La prévision n’existe pas à la source. RTE publie une estimation des émissions pour le passé et le présent, mais les seules prévisions disponibles concernent la consommation, pas l’intensité carbone. Or « est-ce que ce sera plus propre dans trois heures ? » est précisément la question utile. La prévision est donc une responsabilité du service : carbon-fr la modélise derrière un port dédié, avec un modèle de référence calibré et validé par backtest avant d’être servi. (J’ai aussi exploré un modèle ML : sur un réseau aussi nucléarisé et déjà bas carbone que le réseau français, le gain s’est révélé négligeable. Je l’ai donc écarté plutôt que de le garder pour faire joli — l’honnêteté méthodologique avant l’effet d’annonce.)
2. Le quota. La source impose une limite d’appels par utilisateur. L’exposer aux clients serait absurde. La solution : un poller unique alimente une base de données, et l’API sert ensuite tous les clients depuis ce read-model. Résultat, on reste sous 8 % du quota de la source quel que soit le trafic.
3. La méthodologie doit être transparente et versionnée. Mesurer le carbone d’un kWh, ça dépend d’un choix de méthode : combustion directe (rte-direct) ou analyse de cycle de vie incluant les imports (acv-ademe). Chaque mesure porte donc explicitement sa méthodologie et sa version. Jamais de changement silencieux : si la méthode évolue, ça se voit dans la donnée. Et les révisions de RTE (temps réel → consolidé → définitif) ne s’écrasent jamais à la baisse — on sert toujours la meilleure version disponible.
Le pourquoi de ces choix est tracé publiquement dans les ADR du dépôt, pour qui veut creuser.
Les choix techniques, en bref
C’est écrit en Rust (edition 2024), en architecture hexagonale : le cœur métier ne dépend de rien — ni du réseau, ni de la base, ni du framework web. Les sources de données, la persistance et les modèles vivent derrière des ports. Concrètement, changer de source ou de modèle de prévision = un nouvel adaptateur, sans toucher au domaine.
Côté stockage, PostgreSQL natif, sans extension — un choix assumé de pureté de licence (pas de dépendance à une extension sous licence non-OSI). Le tout se déploie en un binaire léger, derrière un reverse proxy, ou via Docker. Double licence MIT OU Apache-2.0.
Si l’architecture vous intéresse, elle est détaillée dans docs/ARCHITECTURE.md (ou en version site sur la page Architecture & API).
Où ça en est
L’API est en production, hébergée sur une infrastructure française. Le national, le régional, l’historique, les prévisions, les échanges, le SDK TypeScript : tout ça tourne aujourd’hui. Le projet est en phase 0.x — donc des ruptures restent possibles, et je le dis franchement plutôt que de prétendre à une stabilité que je ne garantis pas encore. C’est précisément le bon moment pour le tester et orienter la suite.
Et maintenant
Si vous êtes développeur, le plus parlant reste la ligne de commande plus haut — testez-la, ouvrez le dashboard, et si le projet vous parle, une étoile sur le dépôt aide à le rendre visible.
Mais surtout : dites-moi ce qui manque. Un endpoint, un format, un cas d’usage que je n’ai pas vu ? C’est exactement ce que je cherche à ce stade. Je raconte la suite du projet — méthodo, coulisses techniques, décisions — sur Mastodon : @morgan_voltz@mastodon.social.