Cet article est une adaptation en français de Climate-friendly software: don’t fight the wrong battle publié sur mon blog personnel.
Quand on parle de logiciels respectueux du climat (une facette seulement du numérique responsable et de l’éco-conception de service numérique), ça tourne la plupart du temps autour de l’efficacité énergétique, et du code côté serveur en particulier, avec parfois des injonctions à mettre en place des outils de mesure assez complexes pour suivre la consommation électrique dans le temps. Et si ce n’était pas la bonne approche ?
Entendons-nous bien : je ne dis pas que l’efficacité énergétique du code côté serveur ne doit pas être prise en compte, ni qu’il ne faut pas chercher à la mesurer, mais ce serait finalement se limiter au scope 2 du GHG Protocol, et il y a peut-être des actions avec plus de potentiel d’impact à réaliser en priorité.
Commençons donc par comprendre de quels impacts environnementaux on parle, avant que je donne mon avis sur les actions à portée de main, les low-hanging fruits.
Note : cet article est écrit pour les développeurs et architectes logiciels ; il y a d’autres actions pour réduire l’impact climatique du numérique que je n’aborderai pas ici.
# Prendre du recul
La plupart des logiciels aujourd’hui sont client-serveur : qu’elles soient web ou mobiles, de plus en plus d’applications parlent à des serveurs. Ça signifie qu’il y a une énorme asymétrie d’usage : même pour une application professionnelle dans une PME, les utilisateurs sont bien plus nombreux que les serveurs. Et ça implique que les impacts des clients se doivent d’être bien inférieurs à ceux des serveurs.
Ce que les analyses de cycle de vie (ACV) pour les équipements des utilisateurs finals nous disent, c’est que les phases de fabrication, transport et fin de vie cumulées pèsent bien plus que la phase d’utilisation, de 65% jusqu’à près de 98% du potentiel de réchauffement global (PRG). Bien sûr, tout dépend où l’équipement est fabriqué et où il est utilisé, le plus gros impact du lieu d’utilisation étant lié à l’empreinte carbone du système électrique, puisque la phase d’utilisation concerne finalement uniquement la charge de batteries et l’alimentation de nos smartphones et ordinateurs.
Je suis français, travaillant essentiellement pour des entreprises françaises, dont la plupart des utilisateurs sont en France, donc j’admet être influencé par une part de la phase d’utilisation très petite comparée à d’autres régions du monde : allez explorer les données pour vos propres utilisateurs sur Electricity Map et Our World in Data. Et pourtant, ça ne change pas le fait que la phase d’utilisation a de toute façon une empreinte carbone bien plus faible que les autres phases cumulées.
Ce qu’on peut en déduire, c’est que conserver nos équipements plus longtemps va augmenter la part de la phase d’utilisation dans les impacts du cycle de vie complet. Fairphone a mesuré que l’extension de la durée de vie de leurs téléphones de 3 à 5 ans « aide à réduire les émissions annuelles sur le réchauffement climatique de 31%, et un allongement jusqu’à 7 ans d’utilisation aide à réduire les impacts annuels de 44% ».
Allonger la durée de vie d’un smartphone de 3 à 5 peut réduire son impact climatique annuel de près d’un tiers.
Les choses sont différentes pour les serveurs cependant, pour lesquels la part de la phase d’utilisation varie encore plus en fonction du lieu d’utilisation : de 4% jusqu’à 85% ! La plupart des datacenters des grosses entreprises sont « neutres en carbone » (souvent par des crédits carbone, mais dans certains cas réellement par une électricité bas carbone), donc la région géographique des serveurs n’est pas la seule chose à prendre en compte, mais bien le datacenter lui-même. Ça implique que peu importe ce qu’on fait côté serveur, son impact sera vraisemblablement limité (vous vous souvenez de ce que je disais en introduction ?) Bien sûr il y a des exceptions, et il y en aura toujours, donc prenez en compte vos propres traitements serveurs.
Gardons en tête les ordres de grandeur : 70 Kg CO₂e pour un Pixel 7 (sur 3 ans) contre 7730 Kg CO₂e pour un serveur Dell PowerEdge R640 (sur 4 ans), c’est 110 smartphones pour un serveur (ou un ratio de 83:1 si on ramène aux émissions annuelles) : il y a de grandes chances pour qu’on ait bien plus d’utilisateurs que ça. Le ratio pour un PC portable (304 Kg CO₂e sur 4 ans pour un Dell Precision 3520) serait de 25 PC pour un serveur. Mais comme on l’a vu plus haut l’empreinte carbone varie beaucoup en fonction de la localisation ; on peut explorer des données dans l’outil de visualisation de données de Boavizta qui compile des dizaines d’ACVs de différents fabricants. Le Dell PowerEdge R640 en France émettrait en réalité 1701 Kg CO₂e plutôt que 7730 Kg CO₂e : c’est un ratio de 4,5:1 ! Comparativement, mon Dell Precision 3520 passerait de 304 Kg CO₂e à 261 Kg CO₂e, soit un ratio de seulement 1,16:1. Le ratio de PC portables par serveur tomberait donc de 25:1 à 7,9:1, ce qui rend l’impact des PC portables comparativement bien plus grands que ceux du serveur par rapport à d’autres régions du monde.
On a parlé jusqu’à présent des équipements des utilisateurs finals et des serveurs, mais notons qu’il y a un troisième tiers : les réseaux. La consommation énergétique des réseaux ne varie pas proportionnellement à la quantité de données transférées, ce qui signifie qu’en tant qu’utilisateurs de ces réseaux nous n’avons pas beaucoup d’influence sur leur empreinte. Ceci dit, les transmissions de données sont parmi les choses qui vident les batteries des appareils mobiles, donc réduire la quantité de données qu’on échange sur le réseau pourrait avoir un impact plus direct sur l’autonomie des smartphones des utilisateurs (même si ce qui videra le plus la batterie sera plus probablement l’écran).
# Passer à l’action
Qu’a-t-on appris jusqu’à présent ?
- Il est important que les utilisateurs gardent leurs équipements le plus longtemps possible,
- on n’a pas beaucoup d’influence sur les réseaux,
- l’emplacement (région géographique et datacenter) des serveurs compte beaucoup, bien plus que ce qu’on en fait.
Et maintenant, que peut-on faire ?
Pour les serveurs, c’est assez simple : dans la mesure du possible, louer des serveurs dans des datacenters efficient en énergie, et/ou dans des pays au mix électrique bas carbone ; et en plus (ou à défaut), bien sûr optimiser l’architecture et le code côté serveur. Et pour ceux qui gèrent des machines physiques, éviter d’en acheter pour les laisser se tourner les pouces : maximiser leur utilisation.
Prenons d’abord des serveurs dans des datacenters bas carbone, puis optimisons votre architecture et votre code
Pour les réseaux, nos actions sont probablement limitées à réduire leur utilisation, « pas parce que ça réduit immédiatement les émissions (ce qui est faux), mais pour éviter le besoin de déploiement rapide de nouvelles infrastructures » (je cite ici Wim Vanderbauwhede, dans une conversation privée).
Pour les terminaux utilisateurs, c’est plus compliqué, mais pas inatteignable : on veut que les utilisateurs gardent leurs équipements le plus longtemps possible donc, en d’autres termes, on ne doit pas être responsable de leur renouvellement. Il y aura toujours des personnes qui changeront leur matériel pour la hype ou de façon régulière (ou juste parce que le fabricant a arrêté de fournir des mises à jour de sécurité, une forme d’obsolescence programmée, ou parce qu’il ne peut plus être réparé ; deux choses que des lois pourraient réduire), mais il y a aussi beaucoup de monde qui le garde déjà aussi longtemps que possible (parce qu’ils sont éco-conscients ou qu’ils ne peuvent pas se permettre financièrement d’en acheter un nouveau, ou simplement parce que ne ressentent pas le besoin de changer quelque chose qui fonctionne encore pleinement). Pour ces personnes, ne soyons pas ceux qui les feront changer d’avis et franchir la ligne.
Ne soyons pas ceux qui inciteront les utilisateurs à renouveler leur matériel
C’est quelque chose qu’on ne saura jamais mesurer, puisque ça dépend de la façon dont les gens perçoivent l’expérience globale sur leur équipement, mais ça se résume grosso-modo à la performance perçue. Alors optimisons nos applications mobiles et nos frontends web, testons sur du vieux matériel et des réseaux lents (même si on se contente de l’émuler), et monitorons la performance pour les utilisateurs réels (par exemple avec les Web Vitals). Dans le cadre des tests de performance, on pourra regarder la consommation électrique, puisqu’elle est à la fois directement associée aux émissions pour produire cette électricité, et perceptible par l’utilisateur (autonomie de la batterie). Et n’oublions pas de prendre en compte le téléchargement des applications dans la performance perçue globale : des applications mobiles légères qui ne sont pas mises à jour tous les 4 matins, des JS et CSS frontends qui peuvent être mis en cache et ne seront pas modifiés plusieurs fois par jour (rendant la mise en cache inefficace).
Optimisons pour la performance perçue et la batterie
N’oublions pas non plus l’espace de stockage pris par les applications sur les terminaux : les utilisateurs ne devraient pas avoir à choisir entre leurs applications à cause de problème de place disponible pour les installer ; donc, quand c’est possible, on préférera un site web ou une progressive web app (PWA) à une application native (on pourra toujours publier sur les magasins d’applications si besoin, avec des wrappers légers).
Quand c’est possible, préférons un site web ou une PWA à une application native
# Note à l’attention des décideurs
Les conseils ci-dessus sont principalement techniques, répondant à la question « qu’est-ce que je peux faire en tant qu’architecte ou développeur ? » mais les décideurs (chefs de produits, etc.) ont leur part, et ils sont en réalité ceux qui ont le plus de pouvoir ici : ils choisissent quelle fonctionnalité développer ou non, ils donnent forme aux fonctionnalités, ils peuvent réduire la complexité des applications en limitant le nombre fonctionnalités et la configurabilité ; et ainsi éviter les usines à gaz, et permettre aux développeurs et architectes de produire des applications plus légères et optimisées.
Évitons le feature creep, et gardons à l’esprit la loi de Wirth.
Certaines idées ne valent pas leurs impacts.
À l’inverse, puisqu’on doit électrifier une partie de notre économie pour réduire son empreinte carbone, « le logicielle est un des rares secteurs qui part avec un avantage : on devient plus vert en même temps que le réseau électrique, sans avoir rien à faire » (je cite ici Alex Russell, dans une conversation privée), donc utilisons le logiciel pour dématérialiser et remplacer des activités qui un plus grand impact climatique.
# Autres pièges
En plus de mesurer uniquement la consommation électrique des serveurs, un autre piège est d’essayer d’attribuer les émissions à chaque utilisateur ou requête : quand on a des dizaines, centaines voire milliers de requêtes concurrentes, comment distribuer la consommation électrique entre elles ? Il existe une proposition à l’IETF d’un entête de réponse HTTP exposant cette information, et même si c’est une idée louable, je doute qu’elle soit réaliste. Mon opinion personnelle est que l’affichage de telles informations est souvent un signe de greenwhashing. À ma connaissance, ces données ne peuvent être exactes que sous forme agrégée.
Si vous voulez vraiment montrer à quel point vous êtes vert, faites une analyse de cycle de vie (ACV) : prenez en compte les 3 scopes, sur les 3 tiers, en évaluant les impacts environnementaux sur plus de critères que le réchauffement climatique seul.
Pour aller plus loin :
Merci à Alex Russell et Wim Vanderbauwhede pour leurs retours.
Laisser un commentaire