Carbon Aware : au-delà du Greenwashing

Le mythe du "site vert"

Nous vivons une époque paradoxale. D'un côté, l'urgence climatique nous pousse à repenser chaque aspect de notre consommation. D'un autre, le numérique, souvent perçu comme immatériel, cache une empreinte carbone grandissante.

Beaucoup de sites web tentent de répondre à cette problématique par ce qu'on appelle le "greenwashing" : un badge vert en bas de page, une promesse de planter un arbre pour chaque commande, ou un mode sombre activé par défaut. Si ces initiatives partent d'une bonne intention, elles manquent souvent de fondement technique. Changer la couleur d'un bouton ne sauve pas la planète si, en arrière-plan, des serveurs surdimensionnés tournent à vide 24h/24 alimentés par des centrales à charbon.

Parce que je culpabilise de l'empreinte carbone de mon activité professionnelle, j'ai choisi une approche radicalement différente. Je ne voulais pas simplement "paraître" vert, je voulais que mon infrastructure agisse concrètement en fonction de l'état du réseau électrique. C'est ce qu'on appelle le Carbon Aware Computing.

Cet article vous plonge dans les entrailles de mon système, de la récupération des données RTE jusqu'aux algorithmes prédictifs, en passant par les défis techniques que j'ai dû surmonter.

La source de vérité (API RTE)

Tout système "Carbon Aware" repose sur une donnée fiable : l'intensité carbone de l'électricité à l'instant T. En France, j'ai la chance d'avoir accès à RTE (Réseau de Transport d'Électricité) qui fournit ces données en temps réel via son portail Open Data (Éco2mix).

Le défi de l'intégration

Récupérer cette donnée semble simple sur le papier, mais l'implémentation réelle pose plusieurs défis :

1. La latence : On ne peut pas interroger l'API de RTE à chaque requête utilisateur. Cela ralentirait le site et exploserait les quotas d'API.
2. La fiabilité : Que se passe-t-il si l'API de RTE est indisponible ? Le site doit-il planter ?
3. La Granularité : RTE fournit des données toutes les 15 minutes, mais avec parfois un léger décalage.

Ma solution technique

J'ai développé un service Symfony dédié, le CarbonAwareService, qui agit comme un tampon intelligent.

Il interroge l'API RTE toutes les 15 minutes et stocke le résultat dans un cache (Redis). Si l'API répond, je mets à jour ma "Météo Carbone". Si l'API échoue (timeout, erreur 500), le système bascule automatiquement sur un mode dégradé utilisant des données statistiques moyennes (basées sur l'heure et la saison), garantissant que le site reste toujours fonctionnel.

// Exemple simplifié de la logique de fallback
public function getCarbonIntensity(): int
{
    return $this->cache->get('carbon_intensity', function (ItemInterface $item) {
        try {
            return $this->rteApi->fetchRealTimeData();
        } catch (ApiException $e) {
            // En cas de panne RTE, on utilise une estimation statistique
            return $this->getStatisticalFallback(new \DateTime());
        }
    });
}

C'est cette brique fondamentale qui alimente tout le reste du système.

L'expérience utilisateur adaptative

Une fois que je sais que le réseau est "sale" (par exemple, lors d'un pic de consommation hivernal à 19h où les centrales à gaz tournent à plein régime), que faire ?

J'ai défini deux seuils d'action :

1. Mode Éco (> 50 gCO₂/kWh) : Le réseau commence à être sollicité.
2. Mode Critique (> 100 gCO₂/kWh) : Le réseau est sous forte tension.

Une interface qui communique

Au lieu de cacher cette information, je la rends visible. Lorsque le Mode Éco s'active, l'interface du site change subtilement mais visiblement :

• Le thème bascule automatiquement en mode sombre (Dark Mode) pour économiser l'énergie des écrans OLED (jusqu’à 10–20 % d’économie sur écran OLED).
• Les animations superflues et les effets de particules sont désactivés via JavaScript, les polices de caractères chargées sont remplacées par des polices système pour économiser la bande passante.

L'objectif n'est pas de punir l'utilisateur, mais de le sensibiliser. En voyant le site "s'éteindre" légèrement, il comprend intuitivement que l'énergie est précieuse à cet instant.

L'intelligence prédictive (le backend)

C'est ici que mon approche se distingue des solutions classiques. Réagir au présent, c'est bien. Anticiper le futur, c'est mieux.

Le problème de la réactivité

Si j'attends 19h (le pic de pollution) pour agir, il est souvent trop tard. Le trafic utilisateur est déjà là, les serveurs doivent répondre, et je consomme de l'énergie carbonée pour servir ces requêtes.

La solution : algorithme prédictif

J'ai intégré un moteur de Machine Learning (basé sur la librairie PHP Rubix ML directement dans mon application. Ce modèle analyse l'historique des données RTE couplé aux prévisions météorologiques (vent, ensoleillement, température).

Pourquoi la météo ? Parce qu'en France, le vent et le soleil influencent directement la part d'énergie renouvelable dans le mix. S'il fait froid et sans vent demain à 19h, le modèle sait que les éoliennes seront à l'arrêt et que le chauffage électrique sera à fond : le pic carbone est inévitable.

L'Action : Le "Cache Warming" anticipé

Grâce à cette prédiction, mon système peut prendre une décision autonome et intelligente :

"L'algorithme prévoit un pic de pollution demain à 19h. Je vais donc lancer la génération de toutes les pages du site (Cache Warming) à 17h, moment où l'énergie est encore verte."

Résultat : À 19h, quand les utilisateurs arrivent, le serveur ne fait aucun calcul. Il sert des pages statiques déjà prêtes. J'ai déplacé la consommation d'énergie d'une heure "sale" vers une heure "propre". C'est le principe du Load Shifting.

L'infrastructure (théorie et expérimentation)

Si les parties Frontend et Backend sont pleinement opérationnelles, j'explore également une troisième couche : l'infrastructure elle-même.

Cette partie est pour l'instant à l'état de concept. L'idée est d'adapter la taille même de mes serveurs (Docker containers) en fonction de la météo carbone.

Le concept de "scaling écologique"

Habituellement, l'autoscaling (ajustement automatique des serveurs) est basé sur la charge CPU : "Si le serveur force, on en ajoute un autre".

Je propose d'ajouter une variable carbone : "Si l'énergie est sale, j'accepte de réduire la performance pour économiser des ressources".

Concrètement, cela signifie :

• Réduire le nombre de "Workers" PHP (processus qui traitent les requêtes) en période critique.
• Désactiver temporairement des services de confort comme le moteur de recherche avancé (Meilisearch), en revenant à une recherche SQL basique mais moins gourmande.
• Accepter une légère dégradation du temps de réponse (passer de 100ms à 300ms) pour réduire drastiquement la consommation électrique.

C'est un changement de paradigme : la performance n'est plus l'unique métrique reine. L'efficience énergétique devient un critère de pilotage.

Le mot de la fin

Je souhaite, une fois terminé, que ce POC démontre qu'il est possible de sortir du binaire "Polluer ou ne pas utiliser". Le numérique peut devenir organique, c'est-à-dire capable de s'adapter à son environnement.

Les défis sont nombreux : apprendre à dompter l'API de RTE, entraîner un modèle de Machine Learning fiable, et surtout, accepter que mon site ne soit pas toujours à 100% de ses capacités visuelles ou techniques.

Mais le résultat est là : un système transparent, auditable, qui ne se contente pas de promesses, mais qui agit, heure par heure, pour aligner sa consommation sur la réalité physique du réseau électrique.

C'est, je le crois, le véritable avenir de l'éco-conception web.