Green Software : patterns pour une architecture cloud verte

La durabilité dans le cloud est le plus souvent présentée comme une diapositive marketing : logo vert, compensation CO₂, rapport RSE. La discussion intéressante se déroule ailleurs. Le scheduling « carbon‑aware » déplace les charges de travail là où le mix énergétique est propre, ou les programme dans le temps où il le deviendra. Ce n’est pas une idéologie, mais une décision d’architecture avec des chiffres concrets, de vrais compromis et un niveau de maturité qui varie fortement selon le pattern.

Liens associésL’IA propulse le cloud – et la consommation d’énergie  /  Coûts d’inférence IA 2026 : FinOps pour les charges GPU

Les moteurs sont la Green Software Foundation (fondée en 2021 sous l’égide de la Linux Foundation, membres notamment Accenture, Microsoft, GitHub, Intel) et un ensemble de fournisseurs de données qui délivrent en temps réel l’intensité CO₂ du réseau par région. La fondation a identifié trois leviers dans ses patterns : Demand Shifting (Location‑Shifting et Time‑Shifting) et Demand Shaping. Chaque levier a un impact différent sur les émissions, la latence et les coûts. Qui connaît ces différences prend de meilleures décisions d’architecture. Qui les mélange aboutit à un projet de greenwashing avec un effort CI.

Ce texte classe techniquement les trois patterns. Il montre où le levier CO₂ est réel, où il reste limité et ce que cela signifie concrètement aujourd’hui pour les architectes cloud.

Ce qu’est le scheduling sensible au carbone sur le plan technique

Le scheduling sensible au carbone consiste à décider quand et où une charge de travail s’exécute, en se basant sur un signal externe : l’intensité CO₂ du réseau électrique dans une région donnée à un moment précis. L’intensité est exprimée en grammes d’équivalent CO₂ par kilowattheure. Plus la part d’éolien et de solaire est élevée, plus la valeur est basse. Plus la part de charbon ou de gaz est élevée, plus la valeur est haute.

Ce signal est fourni par des services tels que Electricity Maps ou WattTime via des API. La granularité typique est de 5 minutes ou d’une heure. Le scheduling proprement dit s’effectue soit dans le cluster (via des plugins du scheduler Kubernetes), soit dans le système CI/CD (GitHub Actions propose un mode de build sensible au carbone via l’intégration Azure), soit dans la logique applicative (frameworks batch qui retardent le démarrage d’un job jusqu’à ce que l’intensité soit en dessous d’un seuil).

La Green Software Foundation distingue trois patterns pratiques. Il ne s’agit pas de termes marketing, mais de décisions architecturales claires avec des impacts et des risques différents.

Location‑Shifting : amener la charge de travail vers une énergie propre

Le location‑shifting déplace un job vers une région où l’intensité carbone est actuellement plus faible. Sur le plan technique, c’est la solution la plus évidente : les fournisseurs de cloud disposent déjà de nombreuses régions, la définition de la charge de travail est généralement indépendante de la région. Les grands hyperscalers proposent désormais les données d’émissions régionales dans leurs exports de facturation.

Le levier est réel, car les réseaux électriques européens sont très hétérogènes. Un batch exécuté dans une région à forte part d’énergies renouvelables génère nettement moins d’émissions qu’un même batch dans une région à forte base fossile. Ce n’est pas un tour de comptabilité : l’électricité est locale. Le mix énergétique du lieu détermine la charge réelle.

Les limites sont concrètes. La résidence des données (RGPD, réglementation sectorielle, contrats clients) peut interdire un déplacement à travers l’Europe. La latence augmente lorsque les données ou les utilisateurs ne se trouvent pas dans la région cible. Et le trafic inter‑régional sortant coûte de l’argent – pour de gros volumes, le coût peut absorber l’avantage CO₂ si le transfert n’est pas maîtrisé.

Le location‑shifting est le plus efficace lorsqu’il s’applique à des données déjà multirégionales : jeux de données d’entraînement stockés en object storage et déjà répliqués. Ou à des charges de travail sans persistance : batchs sans état qui ne font que lire des entrées et écrire des résultats.

Time‑Shifting : placer la charge de travail dans l’heure la plus propre

Le time‑shifting laisse la charge de travail dans sa région, mais décale son lancement vers une fenêtre d’intensité plus basse. Cas typique : un nightly build ou un entraînement de modèle ML qui démarre à 2 h du matin, moment où la part d’énergie éolienne dans le réseau est élevée. Ou qui ne démarre qu’à 4 h parce que les prévisions d’intensité le recommandent.

Techniquement, c’est souvent plus simple que le location‑shifting : pas d’effets réseau, pas de questions de résidence. Un plugin de scheduler ou un wrapper Cron basé sur le polling interroge l’API d’intensité et déclenche le job dès que le seuil est franchi. Des projets Kubernetes comme le Carbon‑Aware KEDA‑Scaler ou le Batch de Google Cloud avec le flag Carbon‑Sensitivity vont dans ce sens.

La limite réside dans la tolérance au retard. Un build CI qui attend quatre heures ne bloque pas de release – mais un job d’ingestion de logs qui attend six heures peut violer les exigences de conformité (délais RGPD, pistes d’audit). Qui pratique le time‑shifting doit définir, pour chaque charge de travail, le délai acceptable. Sinon on crée une seconde catégorie de jobs « un jour, ça s’exécutera » que plus personne ne débogue.

Demand‑Shaping : moins de calcul lorsque l’électricité est polluée

Le Demand‑Shaping est le pattern le plus exigeant. Au lieu de déplacer la charge de travail, l’application ajuste sa demande de ressources en fonction du signal. Exemples : un encodeur vidéo choisit, en cas d’intensité CO₂ élevée, un préréglage moins puissant, une chaîne de recommandation réduit la profondeur de son modèle, un job d’analyse calcule des agrégats plus grossiers.

Le charme : le Demand‑Shaping fonctionne aussi pour les applications sensibles à la latence, qui ne peuvent ni attendre ni migrer. Le prix : l’application doit modéliser explicitement le compromis. Ce n’est plus un sujet d’infrastructure, mais un sujet produit. Une équipe qui passe son encodage vidéo, en cas de mix énergétique défavorable, de « High » à « Standard », doit justifier le résultat auprès du client. Qui ne le communique pas s’expose à des tickets de support.

Compromis : ce qui s’oppose au Carbon‑aware Scheduling

Le Carbon‑aware Scheduling n’est pas un repas gratuit. Les patterns entrent en collision avec d’autres objectifs d’architecture. Ces collisions ne sont pas théoriques. Qui ne les identifie pas tôt accumule une dette technique, plus difficile à débattre sous le label « Durabilité » que la complexité ordinaire.

Pilote : à quoi ressemble réellement un démarrage

La tentation est grande de lancer le Carbon‑aware Scheduling comme une initiative plateforme. Cela est rarement judicieux. Le meilleur chemin est un pilote étroit, qui produit un résultat concret avant d’écrire des politiques.

1. Identifier les candidats. Quels workloads tolèrent un retard de plusieurs heures ? Typiquement : nightly builds, entraînements ML, transformations de logs, agrégations analytiques. Aucun service orienté utilisateur, aucune pipeline synchrone.
2. Choisir et vérifier la source du signal. Electricity Maps et WattTime sont des fournisseurs établis, les hyperscalers disposent de leurs propres API. Vérifier une fois par jour les valeurs par rapport à la facture du provider, jusqu’à ce que le signal paraisse fiable.
3. Planifier réellement un workload. Pas « concept », mais un job qui figure dans le scheduler de production et qui est retardé ou déplacé géographiquement. Mesurer pendant quatre semaines : durée, coût, CO₂, incidents.
4. Mesurabilité dès le départ. Comparaison avant‑après dans le même tableau de bord où figurent également les coûts et les SLO. Si le chiffre CO₂ n’apparaît que dans le rapport de durabilité, il ne sera pas exploité.
5. Ne scaler qu’après. Si le pilote montre un modèle reproductible, le remonter à la couche plateforme – en tant qu’option du scheduler, pas en obligation.

Ce qui reste difficile

Le principal point ouvert est l’attribution. Les fournisseurs cloud déclarent les émissions par région, mais rarement par job ou service. Qui veut savoir combien de CO₂ un micro‑service précis a généré pendant un sprint doit le calculer lui‑même – en tenant compte de l’intensité électrique, de la durée, de l’utilisation et des hypothèses sur le Power Usage Effectiveness du datacenter. C’est faisable, mais c’est du travail d’ingénierie, pas un simple clic dans un tableau de bord. En pratique, cela implique un modèle de télémétrie interne qui combine les métriques de durée du scheduler avec les courbes d’intensité régionale et agrège les résultats par équipe ou service. Les équipes qui n’ont pas ce modèle se retrouvent avec des estimations difficiles à défendre auprès des clients ou lors d’audits.

Un autre point souvent sous‑estimé : la responsabilité opérationnelle du scheduler lui‑même. Si le flux de signal carbone tombe, il faut savoir ce qui se passe – le job s’arrête, reprend immédiatement, attend un timeout. Sans fallback défini, on crée des pannes silencieuses. Le Carbon‑aware Scheduling doit disposer de la même rigidité en gestion d’incident qu’un scheduler de production classique, sinon il devient un système d’ombre à côté du Cron ou de Kubernetes.

Le deuxième point ouvert est la qualité du signal. Les prévisions pour les prochaines heures sont plus précises, mais pas exactes. Un scheduler qui réagit à chaque mini‑spike du mix énergétique produira des démarrages de jobs instables. Une règle plus pragmatique : retarder jusqu’à la prochaine fenêtre sous un seuil, sinon lancer après un temps d’attente maximal. Pas d’optimisation de second ordre, pas de prévision ML de la prévision.

Et enfin la limite la plus honnête : le Carbon‑aware Scheduling réduit les émissions des workloads déplacés. Il ne diminue pas la demande absolue d’électricité. Qui veut parler sérieusement de durabilité IT ne peut ignorer les questions d’efficacité : déplacer moins de données, modèles plus légers, politiques de rétention propres, usage conscient des infrastructures inactives. Le scheduling est un levier, pas la solution.

Recommandation

Pour les équipes qui exécutent de nombreux workloads batch, le time‑shifting est la première étape : faible complexité, économies fiables, aucune contrainte de résidence. Le location‑shifting est intéressant si le multi‑région est déjà en place et que les données le permettent – sinon cela devient rapidement coûteux. Le demand‑shaping vaut le coup pour quelques produits bien choisis avec des parts critiques en latence et intensifs en calcul, mais pas comme initiative transversale.

Qui traite le Carbon‑aware Scheduling comme un sujet d’architecture l’intègre aux discussions où il doit être présent : choix de région, conception du scheduler, agencement des données. Qui le considère comme un sujet de communication crée un label qui bouge peu. Les patterns de la Green Software Foundation ne sont pas un manifeste – c’est un vocabulaire qui permet de prendre ces décisions de façon rigoureuse.

Foire aux questions

Source image de couverture : Pexels / Alfo Medeiros (px:15418504)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.