7\u202fmin de lecture<\/p>\n
La durabilit\u00e9 dans le cloud est le plus souvent pr\u00e9sent\u00e9e comme une diapositive marketing\u202f: logo vert, compensation CO\u2082, rapport RSE. La discussion int\u00e9ressante se d\u00e9roule ailleurs. Le scheduling \u00ab\u202fcarbon\u2011aware\u202f\u00bb d\u00e9place les charges de travail l\u00e0 o\u00f9 le mix \u00e9nerg\u00e9tique est propre, ou les programme dans le temps o\u00f9 il le deviendra. Ce n\u2019est pas une id\u00e9ologie, mais une d\u00e9cision d\u2019architecture avec des chiffres concrets, de vrais compromis et un niveau de maturit\u00e9 qui varie fortement selon le pattern.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n Liens associ\u00e9s<\/span>L\u2019IA propulse le cloud \u2013 et la consommation d\u2019\u00e9nergie<\/a> \/<\/span> Co\u00fbts d\u2019inf\u00e9rence IA 2026\u202f: FinOps pour les charges GPU<\/a><\/p>\n Les moteurs sont la Green Software Foundation (fond\u00e9e en\u202f2021 sous l\u2019\u00e9gide de la Linux Foundation, membres notamment Accenture, Microsoft, GitHub, Intel) et un ensemble de fournisseurs de donn\u00e9es qui d\u00e9livrent en temps r\u00e9el l\u2019intensit\u00e9 CO\u2082 du r\u00e9seau par r\u00e9gion. La fondation a identifi\u00e9 trois leviers dans ses patterns\u202f: Demand Shifting (Location\u2011Shifting et Time\u2011Shifting) et Demand Shaping. Chaque levier a un impact diff\u00e9rent sur les \u00e9missions, la latence et les co\u00fbts. Qui conna\u00eet ces diff\u00e9rences prend de meilleures d\u00e9cisions d\u2019architecture. Qui les m\u00e9lange aboutit \u00e0 un projet de greenwashing avec un effort CI.<\/p>\n Ce texte classe techniquement les trois patterns. Il montre o\u00f9 le levier CO\u2082 est r\u00e9el, o\u00f9 il reste limit\u00e9 et ce que cela signifie concr\u00e8tement aujourd\u2019hui pour les architectes cloud.<\/p>\n Le scheduling sensible au carbone consiste \u00e0 d\u00e9cider quand<\/em> et o\u00f9<\/em> une charge de travail s\u2019ex\u00e9cute, en se basant sur un signal externe\u202f: l\u2019intensit\u00e9 CO\u2082 du r\u00e9seau \u00e9lectrique dans une r\u00e9gion donn\u00e9e \u00e0 un moment pr\u00e9cis. L\u2019intensit\u00e9 est exprim\u00e9e en grammes d\u2019\u00e9quivalent CO\u2082 par kilowattheure. Plus la part d\u2019\u00e9olien et de solaire est \u00e9lev\u00e9e, plus la valeur est basse. Plus la part de charbon ou de gaz est \u00e9lev\u00e9e, plus la valeur est haute.<\/p>\n Ce signal est fourni par des services tels que Electricity Maps ou WattTime via des API. La granularit\u00e9 typique est de 5\u202fminutes ou d\u2019une heure. Le scheduling proprement dit s\u2019effectue soit dans le cluster (via des plugins du scheduler Kubernetes), soit dans le syst\u00e8me CI\/CD (GitHub Actions propose un mode de build sensible au carbone via l\u2019int\u00e9gration Azure), soit dans la logique applicative (frameworks batch qui retardent le d\u00e9marrage d\u2019un job jusqu\u2019\u00e0 ce que l\u2019intensit\u00e9 soit en dessous d\u2019un seuil).<\/p>\n La Green Software Foundation distingue trois patterns pratiques. Il ne s\u2019agit pas de termes marketing, mais de d\u00e9cisions architecturales claires avec des impacts et des risques diff\u00e9rents.<\/p>\n Source\u202f: Catalogue des patterns de la Green Software Foundation 2024\/2025.<\/p>\n<\/div>\n Le location\u2011shifting d\u00e9place un job vers une r\u00e9gion o\u00f9 l\u2019intensit\u00e9 carbone est actuellement plus faible. Sur le plan technique, c\u2019est la solution la plus \u00e9vidente\u202f: les fournisseurs de cloud disposent d\u00e9j\u00e0 de nombreuses r\u00e9gions, la d\u00e9finition de la charge de travail est g\u00e9n\u00e9ralement ind\u00e9pendante de la r\u00e9gion. Les grands hyperscalers proposent d\u00e9sormais les donn\u00e9es d\u2019\u00e9missions r\u00e9gionales dans leurs exports de facturation.<\/p>\n Le levier est r\u00e9el, car les r\u00e9seaux \u00e9lectriques europ\u00e9ens sont tr\u00e8s h\u00e9t\u00e9rog\u00e8nes. Un batch ex\u00e9cut\u00e9 dans une r\u00e9gion \u00e0 forte part d\u2019\u00e9nergies renouvelables g\u00e9n\u00e8re nettement moins d\u2019\u00e9missions qu\u2019un m\u00eame batch dans une r\u00e9gion \u00e0 forte base fossile. Ce n\u2019est pas un tour de comptabilit\u00e9\u202f: l\u2019\u00e9lectricit\u00e9 est locale. Le mix \u00e9nerg\u00e9tique du lieu d\u00e9termine la charge r\u00e9elle.<\/p>\n Les limites sont concr\u00e8tes. La r\u00e9sidence des donn\u00e9es (RGPD, r\u00e9glementation sectorielle, contrats clients) peut interdire un d\u00e9placement \u00e0 travers l\u2019Europe. La latence augmente lorsque les donn\u00e9es ou les utilisateurs ne se trouvent pas dans la r\u00e9gion cible. Et le trafic inter\u2011r\u00e9gional sortant co\u00fbte de l\u2019argent\u202f\u2013\u202fpour de gros volumes, le co\u00fbt peut absorber l\u2019avantage CO\u2082 si le transfert n\u2019est pas ma\u00eetris\u00e9.<\/p>\n Le location\u2011shifting est le plus efficace lorsqu\u2019il s\u2019applique \u00e0 des donn\u00e9es d\u00e9j\u00e0 multir\u00e9gionales\u202f: jeux de donn\u00e9es d\u2019entra\u00eenement stock\u00e9s en object storage et d\u00e9j\u00e0 r\u00e9pliqu\u00e9s. Ou \u00e0 des charges de travail sans persistance\u202f: batchs sans \u00e9tat qui ne font que lire des entr\u00e9es et \u00e9crire des r\u00e9sultats.<\/p>\n Le time\u2011shifting laisse la charge de travail dans sa r\u00e9gion, mais d\u00e9cale son lancement vers une fen\u00eatre d\u2019intensit\u00e9 plus basse. Cas typique\u202f: un nightly build ou un entra\u00eenement de mod\u00e8le ML qui d\u00e9marre \u00e0 2\u202fh du matin, moment o\u00f9 la part d\u2019\u00e9nergie \u00e9olienne dans le r\u00e9seau est \u00e9lev\u00e9e. Ou qui ne d\u00e9marre qu\u2019\u00e0 4\u202fh parce que les pr\u00e9visions d\u2019intensit\u00e9 le recommandent.<\/p>\n Techniquement, c\u2019est souvent plus simple que le location\u2011shifting\u202f: pas d\u2019effets r\u00e9seau, pas de questions de r\u00e9sidence. Un plugin de scheduler ou un wrapper Cron bas\u00e9 sur le polling interroge l\u2019API d\u2019intensit\u00e9 et d\u00e9clenche le job d\u00e8s que le seuil est franchi. Des projets Kubernetes comme le Carbon\u2011Aware KEDA\u2011Scaler ou le Batch de Google Cloud avec le flag Carbon\u2011Sensitivity vont dans ce sens.<\/p>\n La limite r\u00e9side dans la tol\u00e9rance au retard. Un build CI qui attend quatre heures ne bloque pas de release\u202f\u2013\u202fmais un job d\u2019ingestion de logs qui attend six heures peut violer les exigences de conformit\u00e9 (d\u00e9lais RGPD, pistes d\u2019audit). Qui pratique le time\u2011shifting doit d\u00e9finir, pour chaque charge de travail, le d\u00e9lai acceptable. Sinon on cr\u00e9e une seconde cat\u00e9gorie de jobs \u00ab\u202fun jour, \u00e7a s\u2019ex\u00e9cutera\u202f\u00bb que plus personne ne d\u00e9bogue.<\/p>\n \n”<\/span><\/p>\n La durabilit\u00e9 dans le cloud est le plus souvent vendue comme une diapositive marketing\u202f: logo vert, compensation CO\u2082, rapport RSE.<\/p>\n<\/blockquote>\n<\/figure>\n Le Demand\u2011Shaping est le pattern le plus exigeant. Au lieu de d\u00e9placer la charge de travail, l\u2019application ajuste sa demande de ressources en fonction du signal. Exemples\u202f: un encodeur vid\u00e9o choisit, en cas d\u2019intensit\u00e9 CO\u2082 \u00e9lev\u00e9e, un pr\u00e9r\u00e9glage moins puissant, une cha\u00eene de recommandation r\u00e9duit la profondeur de son mod\u00e8le, un job d\u2019analyse calcule des agr\u00e9gats plus grossiers.<\/p>\n Le charme\u202f: le Demand\u2011Shaping fonctionne aussi pour les applications sensibles \u00e0 la latence, qui ne peuvent ni attendre ni migrer. Le prix\u202f: l\u2019application doit mod\u00e9liser explicitement le compromis. Ce n\u2019est plus un sujet d\u2019infrastructure, mais un sujet produit. Une \u00e9quipe qui passe son encodage vid\u00e9o, en cas de mix \u00e9nerg\u00e9tique d\u00e9favorable, de \u00ab\u202fHigh\u202f\u00bb \u00e0 \u00ab\u202fStandard\u202f\u00bb, doit justifier le r\u00e9sultat aupr\u00e8s du client. Qui ne le communique pas s\u2019expose \u00e0 des tickets de support.<\/p>\n Le Carbon\u2011aware Scheduling n\u2019est pas un repas gratuit. Les patterns entrent en collision avec d\u2019autres objectifs d\u2019architecture. Ces collisions ne sont pas th\u00e9oriques. Qui ne les identifie pas t\u00f4t accumule une dette technique, plus difficile \u00e0 d\u00e9battre sous le label \u00ab\u202fDurabilit\u00e9\u202f\u00bb que la complexit\u00e9 ordinaire.<\/p>\n La tentation est grande de lancer le Carbon\u2011aware Scheduling comme une initiative plateforme. Cela est rarement judicieux. Le meilleur chemin est un pilote \u00e9troit, qui produit un r\u00e9sultat concret avant d\u2019\u00e9crire des politiques.<\/p>\n Le principal point ouvert est l\u2019attribution. Les fournisseurs cloud d\u00e9clarent les \u00e9missions par r\u00e9gion, mais rarement par job ou service. Qui veut savoir combien de CO\u2082 un micro\u2011service pr\u00e9cis a g\u00e9n\u00e9r\u00e9 pendant un sprint doit le calculer lui\u2011m\u00eame\u202f\u2013\u202fen tenant compte de l\u2019intensit\u00e9 \u00e9lectrique, de la dur\u00e9e, de l\u2019utilisation et des hypoth\u00e8ses sur le Power Usage Effectiveness du datacenter. C\u2019est faisable, mais c\u2019est du travail d\u2019ing\u00e9nierie, pas un simple clic dans un tableau de bord. En pratique, cela implique un mod\u00e8le de t\u00e9l\u00e9m\u00e9trie interne qui combine les m\u00e9triques de dur\u00e9e du scheduler avec les courbes d\u2019intensit\u00e9 r\u00e9gionale et agr\u00e8ge les r\u00e9sultats par \u00e9quipe ou service. Les \u00e9quipes qui n\u2019ont pas ce mod\u00e8le se retrouvent avec des estimations difficiles \u00e0 d\u00e9fendre aupr\u00e8s des clients ou lors d\u2019audits.<\/p>\n Un autre point souvent sous\u2011estim\u00e9\u202f: la responsabilit\u00e9 op\u00e9rationnelle du scheduler lui\u2011m\u00eame. Si le flux de signal carbone tombe, il faut savoir ce qui se passe\u202f\u2013\u202fle job s\u2019arr\u00eate, reprend imm\u00e9diatement, attend un timeout. Sans fallback d\u00e9fini, on cr\u00e9e des pannes silencieuses. Le Carbon\u2011aware Scheduling doit disposer de la m\u00eame rigidit\u00e9 en gestion d\u2019incident qu\u2019un scheduler de production classique, sinon il devient un syst\u00e8me d\u2019ombre \u00e0 c\u00f4t\u00e9 du Cron ou de Kubernetes.<\/p>\n Le deuxi\u00e8me point ouvert est la qualit\u00e9 du signal. Les pr\u00e9visions pour les prochaines heures sont plus pr\u00e9cises, mais pas exactes. Un scheduler qui r\u00e9agit \u00e0 chaque mini\u2011spike du mix \u00e9nerg\u00e9tique produira des d\u00e9marrages de jobs instables. Une r\u00e8gle plus pragmatique\u202f: retarder jusqu\u2019\u00e0 la prochaine fen\u00eatre sous un seuil, sinon lancer apr\u00e8s un temps d\u2019attente maximal. Pas d\u2019optimisation de second ordre, pas de pr\u00e9vision ML de la pr\u00e9vision.<\/p>\n Et enfin la limite la plus honn\u00eate\u202f: le Carbon\u2011aware Scheduling r\u00e9duit les \u00e9missions des workloads d\u00e9plac\u00e9s. Il ne diminue pas la demande absolue d\u2019\u00e9lectricit\u00e9. Qui veut parler s\u00e9rieusement de durabilit\u00e9 IT ne peut ignorer les questions d\u2019efficacit\u00e9\u202f: d\u00e9placer moins de donn\u00e9es, mod\u00e8les plus l\u00e9gers, politiques de r\u00e9tention propres, usage conscient des infrastructures inactives. Le scheduling est un levier, pas la solution.<\/p>\n Pour les \u00e9quipes qui ex\u00e9cutent de nombreux workloads batch, le time\u2011shifting est la premi\u00e8re \u00e9tape\u202f: faible complexit\u00e9, \u00e9conomies fiables, aucune contrainte de r\u00e9sidence. Le location\u2011shifting est int\u00e9ressant si le multi\u2011r\u00e9gion est d\u00e9j\u00e0 en place et que les donn\u00e9es le permettent\u202f\u2013\u202fsinon cela devient rapidement co\u00fbteux. Le demand\u2011shaping vaut le coup pour quelques produits bien choisis avec des parts critiques en latence et intensifs en calcul, mais pas comme initiative transversale.<\/p>\n Qui traite le Carbon\u2011aware Scheduling comme un sujet d\u2019architecture l\u2019int\u00e8gre aux discussions o\u00f9 il doit \u00eatre pr\u00e9sent\u202f: choix de r\u00e9gion, conception du scheduler, agencement des donn\u00e9es. Qui le consid\u00e8re comme un sujet de communication cr\u00e9e un label qui bouge peu. Les patterns de la Green Software Foundation ne sont pas un manifeste\u202f\u2013\u202fc\u2019est un vocabulaire qui permet de prendre ces d\u00e9cisions de fa\u00e7on rigoureuse.<\/p>\n Non. Pour un pilote, un simple wrapper Cron qui interroge une API d\u2019intensit\u00e9 et retarde le d\u00e9marrage du job suffit. Les fonctionnalit\u00e9s de plateforme comme KEDA\u2011Carbon\u2011Scaler ou les modes batch propres aux fournisseurs deviennent pertinentes d\u00e8s que plusieurs workloads doivent \u00eatre coordonn\u00e9s.<\/p>\n<\/details>\n Pour le mix r\u00e9seau actuel dans la plupart des r\u00e9gions europ\u00e9ennes, ils sont corrects. Les pr\u00e9visions sur plusieurs heures sont utilisables, mais pas pr\u00e9cises \u00e0 la minute. Optimiser sur des pr\u00e9visions \u00e0 la minute expose \u00e0 un scheduling instable. Une approche robuste consiste \u00e0 combiner seuils et temps d\u2019attente maximum.<\/p>\n<\/details>\n Le d\u00e9placement de localisation ne doit se faire qu\u2019\u00e0 l\u2019int\u00e9rieur d\u2019un groupe de r\u00e9gions l\u00e9galement autoris\u00e9. Les exigences de r\u00e9sidence priment g\u00e9n\u00e9ralement sur toute r\u00e8gle carbone\u202f\u2013\u202fil faut donc s\u2019accorder au pr\u00e9alable avec les \u00e9quipes Data Privacy et Compliance avant de laisser un scheduler choisir les r\u00e9gions.<\/p>\n<\/details>\n Souvent neutre \u00e0 l\u00e9g\u00e8rement positif\u202f: les p\u00e9riodes de faible intensit\u00e9 CO\u2082 co\u00efncident fr\u00e9quemment avec les tarifs hors pointe et la disponibilit\u00e9 des Spot\u2011Instances. En cas de d\u00e9placement de localisation, le trafic sortant peut absorber l\u2019effet\u202f\u2013\u202fil faut donc toujours int\u00e9grer les co\u00fbts r\u00e9seau.<\/p>\n<\/details>\n Les API synchrones orient\u00e9es utilisateur. Les syst\u00e8mes transactionnels avec des budgets de latence stricts. Les workloads li\u00e9s \u00e0 des SLA de temps de r\u00e9ponse. Dans ces cas, le Demand\u2011Shaping reste le seul levier\u202f\u2013\u202fet il s\u2019agit d\u2019un sujet produit, pas d\u2019une d\u00e9cision d\u2019infrastructure.<\/p>\n<\/details>\n Les lectures recommand\u00e9es par la r\u00e9daction<\/p>\n Plus du r\u00e9seau MBF Media<\/p>\n\n
Ce qu\u2019est le scheduling sensible au carbone sur le plan technique<\/h2>\n
\n\n
\n \nPattern<\/th>\n Principe<\/th>\n Adapt\u00e9 \u00e0<\/th>\n Maturit\u00e9<\/th>\n<\/tr>\n<\/thead>\n \n Location\u2011Shifting<\/strong><\/td>\n D\u00e9placer la charge de travail vers une r\u00e9gion au r\u00e9seau propre<\/td>\n Batchs, entra\u00eenement ML, agr\u00e9gation de donn\u00e9es sans contrainte de latence<\/td>\n Produit chez GCP\/AWS, sous r\u00e9serve d\u2019une configuration multi\u2011r\u00e9gion<\/td>\n<\/tr>\n \n Time\u2011Shifting<\/strong><\/td>\n D\u00e9placer la charge de travail vers l\u2019heure la plus propre dans la m\u00eame r\u00e9gion<\/td>\n Rapports diff\u00e9r\u00e9s, sauvegardes, re\u2011entra\u00eenement de mod\u00e8les<\/td>\n Utilisable d\u00e8s l\u2019int\u00e9gration du scheduler (Airflow, Argo)<\/td>\n<\/tr>\n \n Demand\u2011Shaping<\/strong><\/td>\n R\u00e9duire soi\u2011m\u00eame la charge de calcul lorsque le CO\u2082 du r\u00e9seau est \u00e9lev\u00e9<\/td>\n Transcodage vid\u00e9o, fonctionnalit\u00e9s UX non critiques, pr\u00e9\u2011calcul<\/td>\n Pr\u00e9coce, souvent \u00e0 impl\u00e9menter c\u00f4t\u00e9 application<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Location\u2011Shifting\u202f: amener la charge de travail vers une \u00e9nergie propre<\/h2>\n
Time\u2011Shifting\u202f: placer la charge de travail dans l\u2019heure la plus propre<\/h2>\n
Demand\u2011Shaping\u202f: moins de calcul lorsque l\u2019\u00e9lectricit\u00e9 est pollu\u00e9e<\/h2>\n
Compromis\u202f: ce qui s\u2019oppose au Carbon\u2011aware Scheduling<\/h2>\n
En faveur<\/h3>\n
\n
Contre<\/h3>\n
\n
Pilote\u202f: \u00e0 quoi ressemble r\u00e9ellement un d\u00e9marrage<\/h2>\n
\n
Ce qui reste difficile<\/h2>\n
Recommandation<\/h2>\n
Foire aux questions<\/h2>\n
Ai\u2011je besoin d\u2019un outil sp\u00e9cifique pour la planification \u00ab\u202fCarbon\u2011aware\u202f\u00bb\u202f?<\/strong><\/summary>\n
Quelle fiabilit\u00e9 ont les signaux d\u2019\u00e9mission\u202f?<\/strong><\/summary>\n
Conflit avec la r\u00e9sidence des donn\u00e9es\u202f\u2013\u202fcomment le g\u00e9rer\u202f?<\/strong><\/summary>\n
Le scheduling \u00ab\u202fCarbon\u2011aware\u202f\u00bb est\u2011il rentable\u202f?<\/strong><\/summary>\n
Qu\u2019est\u2011ce qui ne convient absolument pas au scheduling \u00ab\u202fCarbon\u2011aware\u202f\u00bb\u202f?<\/strong><\/summary>\n
\n