La sobriété, c'est un métier du « ne pas ».

Juin 2026, une vague de chaleur sans précédent, les fils d'actualité et les réseaux sociaux chauffent à la même vitesse que l'air : le numérique brûle la planète, vos mails noient des ours, l'IA assèche les nappes phréatiques.

Il serait mensonger et inconscient de dire que l'activité numérique n'y est pour rien, mais il faut contextualiser, sans pour autant balayer l'évidence.

Derrière tout ce bruit, une question gênante : est-ce que moi, développeur, qui n'a jamais rangé l'empreinte de ce que je code parmi mes critères, je fais partie du problème ? La performance, la sécurité, la lisibilité, oui ; l'empreinte, jamais. Et je ne crois pas être le seul dans ce cas et de manière intentionnelle.

Ce billet examine où la main d'un développeur pèse vraiment sur l'empreinte de ce qu'il produit, et où elle ne pèse pas. Le résultat est un peu vexant : les trois seuls leviers qui comptent sont des choses qu'on ne fait pas. Ils ne coûtent rien, ils rapportent souvent, et la plupart d'entre nous en avons déjà les réflexes.

Deux mensonges qui se valent

Avant les leviers, il faut sortir de deux récits car ils sont aussi faux l'un que l'autre, et tant qu'on reste dedans, on ne fait pas de technique, on fait de l'ambiance.

Le premier, c'est le catastrophisme, c'est-à-dire celui qui transforme un kilowattheure en fin du monde. On a tous entendu qu'une heure de Netflix pèse plus d'un kilo de CO₂. Le mythe viral, c'est 1,6 kg pour trente minutes ; la vraie valeur tourne autour de 36 g par heure (Netflix, donnée 2019, mix mondial, estimation IEA révisée fin 2020). L'écart vient d'un empilement d'erreurs : une conversion bit/byte qui gonfle le débit, et des intensités datacenter et réseau surévaluées de 35 à 50 fois. Et sur cette heure, 72 % de l'énergie part dans notre téléviseur, pas dans le datacenter (IEA, 2020).

Le fameux « 4 g par mail » ? C'est un calcul de coin de table de 2010, que son auteur a lui-même divisé par plus de dix en 2020, autour de 0,3 g, dans une fourchette de 0,03 à 26 g (Berners-Lee, How Bad Are Bananas?, 2020). La précision affichée est une illusion. La requête ChatGPT « dix fois une recherche Google » ? L'estimation de 3 Wh datait de 2023, calée sur l'ère GPT-3 (de Vries, 2023) ; les mesures 2025 la situent autour de 0,2 à 0,3 Wh, l'ordre de grandeur d'une recherche web (Google, 2025 ; Epoch AI, 2025). La « bouteille d'eau par requête » ? Les 500 mL mesurés couvrent dix à cinquante réponses de GPT-3, eau de production électrique comprise (Li et al., UC Riverside, 2023). Et le « numérique = 14 % des émissions mondiales en 2040 » est une extrapolation que la littérature juge intenable (Belkhir & Elmeligi, 2018 ; critiqué par Freitag et al., 2021).

On voit le motif. Pas un de ces chiffres ne résiste à la question « périmètre ? ». Vendre la peur là-dessus, ce n'est pas de l'écologie, c'est du remplissage d'antenne, et ça décrédibilise les vrais problèmes.

Le second mensonge est plus flatteur, donc plus dangereux : le développeur, moi compris, qui se rassure en rabotant des allocations mémoire sur un container. C'est confortable, parce que ça ne coûte rien et ça valorise notre geste habituel. Sauf que l'efficacité technique, à elle seule, ne règle rien : on verra à la fin pourquoi car c'est le nœud du sujet.

Entre les deux, il y a le métier, et sur ce terrain, le métier, c'est surtout savoir ce qu'on ne fait pas.

Ne pas faire jeter le matériel

En France, le numérique pèse 4,4 % de l'empreinte carbone nationale (ADEME-Arcep, données 2022). Là-dedans, les terminaux (nos téléphones, nos box, nos ordinateurs) comptent pour la moitié ; les datacenters, 46 % (y compris ceux à l'étranger qui hébergent nos usages, une précision méthodologique récente) ; les réseaux, 4 %. Le cloud lointain n'écrase pas le reste : l'appareil dans notre poche fait quasiment jeu égal avec lui.

L'essentiel de l'empreinte d'un terminal est déjà payé avant qu'on l'allume. Un smartphone, c'est environ trois quarts à 80 % de son empreinte à la fabrication : extraction, gravure, assemblage, transport (Apple, 2024 ; ADEME), et le reste à l'usage. Autrement dit : la pire chose qu'on puisse faire, écologiquement, avec un appareil, c'est en racheter un.

D'où le levier le plus lourd pour un développeur frontend, et c'est le moins « codeur » au sens noble : ne pas forcer le remplacement de l'appareil. Un site qui exige le dernier navigateur, qui rame sur un CPU de 2019, qui balance 2,3 Mo (la médiane mobile en octobre 2024, contre 505 Ko dix ans plus tôt, HTTP Archive) pour afficher un article ne réchauffe peut-être pas le datacenter. Mais il rend un téléphone « lent », et un téléphone lent finit remplacé.

La bonne nouvelle, c'est que la marge est gratuite, et qu'on sait déjà faire. La médiane mobile trimballe environ 200 Ko de JavaScript inutile au chargement (HTTP Archive, 2024). L'AVIF, le format d'image le plus efficace, plafonne à 1 % des requêtes ; le GIF, le pire, en tient encore 17 % ; le lazy-loading natif, un attribut, n'est posé que sur un site sur trois (HTTP Archive, 2024) : ce ne sont pas des optimisations exotiques mais des wins qu'on laisse sur la table.

Et pour une fois, la loi pousse dans le bon sens : depuis juin 2025, l'UE impose aux fabricants des pièces détachées pendant sept ans et des mises à jour d'OS pendant cinq (règlement UE 2023/1670). Un appareil qui vit plus longtemps amortit son énorme coût de fabrication sur plus d'années. Notre part du marché, c'est de ne pas saboter cet allongement avec du logiciel qui réclame toujours le dernier cran de matériel.

On appelle négawatt le watt qu'on choisit de ne pas consommer. Ici, le geste, c'est le néga-terminal : l'appareil qu'on n'oblige pas à mourir. C'est moins gratifiant que d'optimiser une boucle, mais c'est là qu'est la masse, et le faire c'est juste du bon métier.

Ne pas réveiller le serveur

Passons au backend. Première lucidité : il pèse peu dans l'usage ! Sur une heure de streaming, le datacenter, c'est 5 % de l'empreinte ; le terminal, 72 % (IEA, 2020). Mais c'est la part qu'un développeur backend tient vraiment dans sa main, et il y a du gras facile à dégager.

Plusieurs relevés sur la décennie 2008-2016 convergent autour de 30 % de serveurs « comateux », c'est-à-dire sous tension, prêts à consommer du courant mais sans rendre le moindre service utile (Koomey & Taylor, 2015). Ce n'est pas un problème de génie, c'est un problème de ménage. Right-sizer une instance dimensionnée trois fois trop grand « au cas où », éteindre une préproduction qui tourne la nuit, tuer le cron fossile, supprimer le N+1 qui réveille la base 400 fois pour afficher une liste, c'est autant de néga-serveurs.

Là, le levier est imbattable, parce qu'il se paie tout seul : ça baisse la facture cloud. La sobriété backend n'a pas besoin de morale pour se vendre car elle se vend en euros : c'est le geste le plus facile à faire passer en réunion car personne ne défend le serveur qui ne sert à rien.

Deux pièges, au passage, parce qu'ils font dépenser de l'énergie pour rien. Le premier, c'est de croire que tout est proportionnel au trafic. La consommation d'un réseau est en grande partie un coût fixe : son énergie ne suit pas la courbe du trafic (Mytton, Lundén & Malmodin, 2024). Le modèle « X kWh par gigaoctet » est faux comme outil de décision. Le second, c'est le « carbon-aware », à savoir l'idée de décaler les calculs vers les heures propres. Ça marche peu : sur deux ou trois heures, l'intensité carbone du réseau bouge à peine. Ce qui compte, c'est le choix de la région où tourne le serveur, bien plus déterminant que le décalage horaire (Sukprasert et al., EuroSys 2024), une décision de config prise une fois et pas un ordonnanceur sophistiqué.

Reste l'IA car c'est le sujet de l'année, que l'on soit en faveur ou contre cette technologie. Générer un texte coûte aujourd'hui autour de 0,2 à 0,3 Wh par requête (Google, 2025 ; Epoch AI, 2025), entraînement non compris, à savoir l'ordre de grandeur d'une recherche web : à l'unité c'est négligeable. Sauf que ça grimpe vite avec le contexte : autour de 2,4 Wh à 10 000 tokens, jusqu'à 40 Wh à 100 000 (Epoch AI, 2025, GPU seuls, estimation haute), et les modèles de raisonnement empilent en plus des milliers de tokens de réflexion cachés. Et c'est l'inférence (chaque appel en production) qui domine la consommation d'un modèle déployé : déjà 60 % de l'énergie ML chez Google sur 2019-2021 (Patterson et al., 2022). Le levier, ce n'est donc pas « entraîner moins », c'est « appeler moins ».

La vraie question n'est pas « l'IA pollue-t-elle » : c'est : est-ce que ça méritait un modèle ? Une bonne partie des features « IA » sont une règle métier qu'on a sous-traitée à un LLM parce que c'était plus rapide à brancher qu'à écrire la règle.

// Repéré en review : un appel LLM pour « extraire le numéro de commande » d'un objet d'e-mail.
$ref = $ai->ask("Donne le numéro de commande dans : {$subject}");

// Le numéro suit un format maison stable (CMD-2026-04839).
// Une regex le fait pour 0 Wh côté modèle, sans latence réseau ni clé d'API à provisionner :
$ref = preg_match('/CMD-\d{4}-\d{5}/', $subject, $m) ? $m[0] : null;

Ne pas réveiller le modèle quand un preg_match suffit, c'est encore un néga-serveur, et quand le modèle est vraiment nécessaire, le mettre en cache, router vers le plus petit qui fait le travail, couper le contexte inutile : c'est la même hygiène, sur un composant qui coûte juste plus cher.

Ne pas mentir avec les chiffres

Le troisième levier n'est pas dans le code, il est dans la tête. Et c'est peut-être le plus important, parce que c'est lui qui rend les deux autres crédibles. Un chiffre faux relayé de bonne foi, sur ce sujet, ça donne des bâtons pour se faire battre.

Or presque tout ce qui circule est faux, gonflé, ou cité hors périmètre. Trois réflexes suffisent à faire le tri, et on les a déjà au boulot.

Premier réflexe : le périmètre. Le « 4 % des émissions mondiales » est en réalité une fourchette de 1,8 à 3,9 % selon ce qu'on compte (Freitag et al., 2021, données 2020, d'avant la vague IA). Le « numérique français a doublé, de 2,5 à 4,4 % » n'est pas une explosion physique : on a élargi la mesure pour y inclure les datacenters à l'étranger qui servent des usages français (ADEME, données 2022). La frontière a bougé, pas la réalité. Comparer les deux chiffres bruts, c'est se tromper soi-même.

Deuxième réflexe : médiane contre moyenne, et la méthode de comptage carbone. Le chiffre le plus propre du moment, les 0,24 Wh par requête publiés par Google, est une médiane, auto-déclarée, hors entraînement, en carbone « market-based ». En « location-based » (l'électricité réellement tirée du réseau, pas celle achetée sur le papier via des certificats verts), le même calcul donne environ trois fois plus (Google, 2025). Aucun des deux n'est un mensonge ; il faut juste savoir lequel on lit.

Troisième réflexe : la source. C'est le plus délicat, parce qu'il vise des gens qu'on aime bien. Les acteurs français du numérique responsable ont un outillage solide : le RGESN et ses 78 critères, les centaines de bonnes pratiques d'écoconception. On s'en sert, et on a raison. Mais c'est aussi de cet écosystème que sont sortis le Netflix à 1,6 kg et le « 70 % des fonctionnalités ne servent à rien » jamais vraiment sourcé. On peut saluer l'outil et refuser le chiffre. Les deux à la fois, sans se sentir traître.

Au passage, ça désamorce une exagération dans l'autre sens : non, le RGESN n'est pas « opposable » ni sanctionné. Il reste volontaire pour le privé ; la loi REEN en rend seulement la déclaration obligatoire pour les grandes collectivités (Arcep-Arcom-ADEME, 2024). Le dire, ce n'est pas être contre, c'est juste ne pas mentir.

Voilà le néga-chiffre : celui qu'on refuse de répéter parce qu'on ne l'a pas vérifié. C'est le moins coûteux des trois leviers, et le plus contagieux. Et c'est un réflexe de développeur pur : on sait déjà flairer un benchmark truqué.

Quand le climat devient un paramètre d'archi

Jusqu'ici, on a parlé de réduire l'empreinte de ce qu'on produit. Mais la canicule rappelle l'autre moitié du problème, celle dont on ne parle jamais entre devs : on ne va pas seulement agir sur le climat, on va le subir, jusque dans nos architectures.

Premier signal, l'énergie. Elle devient chère, et surtout intermittente. Nos archis sont pensées pour une électricité abondante, stable, au prix qu'on veut : on provisionne large, on laisse tourner, on réplique « au cas où ». Ce confort a une date de péremption. Le jour où le coût de calcul varie selon l'heure et la météo, le sur-provisionnement ne sera plus seulement du gras carbone, ce sera une ligne de facture qui pique.

Deuxième signal, la concentration. Les datacenters ne sont pas répartis au hasard : ils s'agglutinent là où le foncier, le réseau et le climat sont favorables, et ils saturent les réseaux locaux. En Irlande, ils tirent déjà 22 % de l'électricité nationale (CSO Ireland, 2024), et le pays a gelé puis conditionné les nouveaux raccordements. Le « mets ça dans le cloud, c'est élastique » se heurte à une limite très peu élastique : le poste électrique du coin.

Troisième signal, la chaleur elle-même. Le refroidissement pèse de 7 % dans un hyperscale efficace à plus de 30 % dans un datacenter d'entreprise classique (IEA, 2025), et la canicule le fait grimper : sur deux datacenters de Phoenix suivis sur un an, le PUE culmine l'été, jusqu'à 2,00, contre 1,84 de moyenne pour le plus exposé (Karimi et al., 2022). La chaleur n'attaque pas le datacenter de façon abstraite : elle le rend plus cher et plus fragile précisément quand le réseau est déjà sous tension.

Tout ça dessine une compétence qu'on n'a pas encore : penser une architecture pour un monde où l'énergie est instable, chère par moments, et où le datacenter régional peut tirer la langue en août. Dégrader proprement plutôt que tomber, prévoir un mode sobre, ne pas dépendre d'une seule région : ce sont des réflexes de résilience qu'on applique déjà pour les pannes, et qu'il va falloir étendre au climat. Moi, je ne l'ai pas encore fait. C'est peut-être le vrai chantier de la décennie, et il n'a presque rien à voir avec « coder plus propre ».

Ce que la loi commence à exiger

Petit détour utile, parce que c'est là que le « il faudrait » devient « il faut ». La réglementation arrive, en ordre dispersé.

Du contraignant, déjà : l'UE impose des exigences d'efficacité aux serveurs vendus sur le marché, et depuis 2024 tout datacenter d'au moins 500 kW doit déclarer sa consommation, son PUE, son usage de l'eau (directive EED 2023/1791 + règlement délégué 2024/1364). Côté terminaux, les pièces sept ans et les mises à jour cinq ans, on l'a vu. Ce sont des obligations, pas des vœux.

Et beaucoup de mou, encore : le RGESN n'est pas opposable, et le reporting extra-financier qui devait embarquer des milliers d'entreprises a été fortement réduit — la proposition Omnibus de la Commission (février 2025) en retirait environ 80 % du champ (Commission européenne, paquet Omnibus, 2025). La règle, pour l'instant : on mesure et on déclare, on ne plafonne pas. Connaître cette frontière, c'est encore de la rigueur : ni surjouer une contrainte qui n'existe pas, ni ignorer celle qui existe déjà.

Ce que ça ne règle pas

D'abord, l'effet rebond est têtu. Google annonce une requête Gemini 33 fois moins gourmande en un an (Google, 2025) ; dans le même mouvement, la demande électrique de ses datacenters bondit de 27 % sur l'exercice 2024 et ses émissions totales restent à +51 % depuis 2019 (Google Environmental Report, 2025). Côté web, on a eu HTTP/3, Brotli, AVIF, et la page médiane a quand même doublé en dix ans. On optimise, l'usage avale le gain, puis en redemande. Tant qu'il n'y a pas de plafond quelque part, l'efficacité finance l'expansion au lieu de la freiner. Optimiser sans regarder le volume, c'est huiler la machine en croyant la ralentir.

Ensuite, le plafond de verre. Le levier vraiment lourd (faut-il cette feature, ce produit, ce service) se décide au-dessus de moi, en réunion produit, pas dans ma pull request. Je tiens le petit levier, le code. Pas le grand, le pourquoi. Prétendre l'inverse, ce serait me donner un rôle que je n'ai pas.

Alors pourquoi s'embêter ? Parce que l'autre option, ne rien faire en attendant que « le système » change, est juste la version paresseuse de la même défausse. Et parce que ces trois gestes ne demandent aucun héroïsme. Juste de remettre l'empreinte dans la liste des critères, à côté de la perf et de la sécu. Une case mentale à cocher avant de merger, pas une croisade.

Le mot de la fin

Ce billet ne dit pas comment mesurer le carbone de notre app : personne ne sait le faire honnêtement à la maille d'un service. Il ne fait le procès de personne. Il dit une seule chose. Notre métier a pris le pli du ship, add, more, et l'empreinte est le premier critère qu'on oublie parce que, contrairement à un bug, elle ne casse jamais un test. La sobriété, ce n'est pas une techno de plus à apprendre, c'est un métier du ne pas.