[New BP] Fixer un budget carbone pour chaque scénario utilisateur

[fzaninotto]

Cette bonne pratique s'inspire d'une pratique de Web Performance, le budget de performance (détail de la pratique sur MDN).

L'idée est de fixer dès la conception un volume d'émissions de CO2 permis pour une fonctionnalité donnée, de la mesurer en continu (dans les outils d'intégration continue), et de refuser un changement de code qui dépasse ce budget. L'usage d'un outil de Robotic Process Automation (comme Cypress.io ou Playwright) permet de simuler un scénario utilisateur sur un navigateur web.

Seule une "assurance carbone" automatisée comme celle-là évitera des dérives au cours du temps. Elle s'apparente à ce que les développeurs cont déjà sur la sécurité, la performance, la non-régression, la qualité du code.

La performance a ses indicateurs (Core Web Vitals) et ses champions (Google). L'empreinte carbone, pour l'instance, n'a pas encore cela. Il faudra, immanquablement, lister des outils de mesure de ces émissions. Le guide vivra plusieurs années en ne pourra lister les outils sortis après lui, mais il ne peut pas, à mon sens, laisser au lecteur le travail de faire le tri dans les outils existants.

Je suis évidemment biaisé pour proposer des éléments dans cette liste (ma société en édite un, greenframe), ma contribution ici est donc surtout une invitation à discuter. Voici les outils que je suggère de faire figurer - et ne pas figurer - dans cette BP:

• Plugin GreenIT Analysis
• GreenFrame
• Scaphandre
• Microsoft sustainability calculator
• Google Cloud Carbon Footprint calculator
• Power API
• websitecarbon.com (calcul hautement sujet à caution)
• EcoGrader (méthodo très discutable)

Et je parle de budget carbone, mais il faudrait aussi une BP pour les budgets eau, mais là il n'existe tout simplement aucun outil.

[Trankilloman]

Je suis d'accord sur le fait d'indiquer qu'il faut monitorer néanmoins, il est nécessaire de rappeler aux utilisateurs du guide qu'un outil ce choisi en fonction : de son objectif, de son périmètre et de son UF mais surtout, le risque que j'y vois ici, des méthodes de caractérisations et des données de premiers et surtout de second plan. Cela nécessiterait de rappeler une deuxième fois la nécessité de ne pas communiquer sur ses résultats d'acv simplifiée ce qui va, de fait, être une nouvelle tentation.
Concernant le fait de donner des quotas sur des fonctionnalités spécifique, pourquoi pas mais il faudrait un échantillon d'exemple suffisamment grand pour donner quelques chose de significatif et il sera nécessaire de rappeler que ceci n'est qu'indicatifs et dépend de la fonction global du service.
Concernant l'aspect mono indicateur, c'est en effet très problématique qu'il n'existe pas d'outil d'acv simplifié multicritere pour le domaine et donc, cela serait à mon sens problématique de monitorer que les GES (et pas que le CO2 ;-)).
Pour toutes ses raisons, je suis plutôt opposé à cette BP, d'autant que le guide "évalue" déjà quelques indicateurs sur chaque bonne pratique.

[ACTLEM]

Je rejoins plutôt la remarque de @Trankilloman, nous sommes plus sur de la méthodologie finalement. Je l'intégrerais donc bien à la page de l'issue #138

[ACTLEM]

Le but est surtout de réduire les impacts environnementaux (pas uniquement l'empreinte carbone). Si l'on a des données, cela peut être comparé à des services semblables. Pour l'instant, je l'ai mis dans l'idée d'une section méthodologie (qui ne sera pas forcément embarquée dans le livre mais sera à terme disponible sur ce repository) avec comme idée ici d'avoir dans le cadre de la démarche d'écoconception, une amélioration continue sur chaque scénario utilisateur. En réalité, cela rejoint donc la démarche d'écoconception en tant que tel et non une BP pour permettre la réduction effective l'empreinte environnementale.
A termes quand nous aurons des métriques sur tout le cycle de vie et multicritères cela pourra être complété avec des indicateurs permettant de donner des éléments sur les seuils à fixer.

[fzaninotto]

Le but est surtout de réduire les impacts environnementaux (pas uniquement l'empreinte carbone).

J'entends le "pas uniquement", mais est-ce une raison pour ne pas embarquer cette BP ? D'ailleurs, l'impact environnemental des autres BP n'est pas vraiment qualifié (Consommation d'énergie ? Ralentissement de la navigation ? Renouvellement des terminaux ?), et mériterait d el'être à mon avis.

je l'ai mis dans l'idée d'une section méthodologie

Sur le fait que cette proposition ne fasse pas l'objet de bonnes pratiques mais soit ajoutée à une section "méthodo", en quoi diffère-t-elle des BP #1, #2, ou #3, qui elles sont des BP ?

une section méthodologie (qui ne sera pas forcément embarquée dans le livre mais sera à terme disponible sur ce repository)

Donc vous allez publier un livre de bonnes pratiques sans aucune preuve ni moyen de vérifier que ces pratiques sont effectivement bonnes ?

C'est l'approche qui avait pour moi discrédité l'édition précédente et motivé ma contribution à cette mise à jour. Je pense que cette approche "on ne regarde pas les preuves" amène des personnes dont l'esprit critique et le raisonnement scientifique sont bien développés à considérer le guide comme non fiable.

[ACTLEM]

@fzaninotto Pour qu'il n'y ait pas méprise, ta proposition a été accueillie très positivement. Concernant l'empreinte carbone, c'était une remarque d'amélioration en passant, pas grand chose à voir avec le fait ou non d'en faire une BP. Néanmoins, je me rends compte que mon propos n'était pas clair.

Je suis d'accord avec toi sur le fait que la qualification des BP n'est axée que sommairement sur les ressources économisées CPU, mémoire, requêtes etc...Comme tu le soulignes le but est bien de vérifier que les ressources suivantes ont été diminuées:

• Mémoire requise (terminal et DC)
• Stockage requis (terminal et DC)
• Infrastructure réseau requise (3G < 4G < 5G): Nombre requêtes et Bande passante
• Terminal (OS, puissance) requis (plus c'est ancien mieux c'est): Obsolescence perçue, ralentissement
  La diminution de ces ressources primaires IT va engendrer une diminution des impacts environnementaux, c'est pour cela qu'ils ont été choisis. N'hésite pas à proposer un indicateur primaire facile à évaluer et qui manquerait.

Les BP 1,2 et 3 permettent de réduire de manière effective ces ressources si elles sont bien appliquées dès la conception fonctionnelle. Ce sont même les premiers leviers. Ici, la proposition est plus un moyen de vérifier le résultat. D'autres discussions ont eu les mêmes remarques (elles sont listées dans l'issue #138)
Si nous avions des seuils de plusieurs indicateurs (ressources IT, indicateurs environnementaux) et des "outils" pour évaluer de manière uniforme ces indicateurs, nous pourrions ajouter cette proposition (en format BP ou autre, pas d'avis tranché) avec une référence aux seuils suivant le type de service web. Cela demande néanmoins un travail qui aujourd'hui n'existe pas ou partiellement (ce qui pourrait amener de la frustration). C'est le sens de ma toute dernière phrase.

Pour répondre à ton interrogation sur les "preuves", c'est justement l'intérêt de cette version. 26 Bonnes pratiques ont été supprimées dans cette idée car ne se justifiaient pas d'un point de vue écoconception (pas de métriques, pas d'ACV, pas de retour terrain pour justifier leur présence).
L'idée de la section méthodologie est dans un premier temps de venir compléter la section "Évaluer le niveau d’écoconception de mon site web ou de mon service en ligne" qui, de mon point de vue (et d'autres personnes vues d'autres discussions), est trop légère et manque d'exemples concrets terrain (ex: un exemple de cas terrain), d'outils et un côté plus opérationnel (tirs de perfs pour avoir le minimum requis, évaluation de chaque scénario ^^...).
D'autre part, dans la section "L’écoconception web à la rescousse", cela ne parle pas assez de l'amélioration continue, n'insiste pas assez sur le fait de ne pas augmenter les ressources requises (ou des indicateurs environnementaux si l'on a des outils qui font consensus pour leur évaluation), en résumé ne va pas assez loin dans la vulgarisation de la démarche d'écoconception normée (mais là ce n'est que mon avis personnel).
Le fait de ne pas être certain d'embarquer dans cette version cette section est surtout par non certitude d'avoir assez temps pour l'écrire.

Si tu es d'accord, et ce qui serait super, c'est que tu rédiges une section (en format bonne pratique ou libre) sur le fait de ne pas dégrader des indicateurs tout en indiquant des aides sur comment vérifier de manière continue de manière opérationnelle (outillage, démarche...). En résumé reprendre ta proposition et en considérant que fixer des seuils au tout départ est peut-être prématuré (cf manque de comparatifs suivant le type de service...sauf si tu en as auquel cas n'hésite pas). Cela pourrait déjà dans un premier temps compléter l'une des deux sections que j'ai nommées et selon la rédaction pourquoi pas finalement l'intégrer comme une BP 1.

[fzaninotto]

Merci de tes éclaircissements, je comprends mieux tes remarques.

Je veux bien contribuer à une section ; il faudrait que tu m'en dises un peu plus sur le format et la taille. Et le délai ;)

[ACTLEM]

Dans l'idéal si on veut pouvoir se reposer la question de pousser comme bonne pratique, c'est de se baser sur le template https://github.com/cnumr/best-practices/blob/main/resources/BP_xxxx_fr.md. Ne pas tenir compte de la règle de calcul sur la priorité qui est à retravailler, idem pour les impacts cela n'est pas obligatoire pour l'instant on voit cela après le 4 décembre. Le délai serait donc plutôt au 4 décembre.
Pour ajouter une section à part en format libre, il faut que cela soit finalisé pour le 15/12, donc cela laisse une semaine de plus. Pour la taille, je dirais 2 pages si on se réfère au format du livre. Beaucoup plus libre bien évidemment si cela se retrouve sur le repository uniquement (mais ce n'est pas le but dans un premier temps ;-) ).

[Trankilloman]

Merci de tes éclaircissements, je comprends mieux tes remarques.

Je veux bien contribuer à une section ; il faudrait que tu m'en dises un peu plus sur le format et la taille. Et le délai ;)

Si besoin d'aide, je suis là pour également travailler dessus

[Trankilloman]

"en résumé ne va pas assez loin dans la vulgarisation de la démarche d'écoconception normée (mais là ce n'est que mon avis personnel)."

Je confirme, j'ai eu plusieurs fois l'occasion de défendre le guide en vulgarisant la méthode

[ACTLEM]

@Trankilloman @fzaninotto J'ai eu un point rapide ce soir et je confirme qu'on fera tout pour embarquer cette section dans le livre ;-)

[fzaninotto]

Je ne sais pas exactement de quoi cette section doit traiter. Pour éviter de parler dans le vide, j'ai fait un premier jet. Dites-moi ce que vous en pensez.

---

Réduire l’empreinte écologique d’un service numérique

L’essentiel de l’empreinte écologique d’un service numérique se décide lors de la conception. Néanmoins, une fois le service mis en production, il est encore possible de réduire son impact environnemental. Quelle démarche adopter pour cela ?

Les bonnes pratiques listées dans cet ouvrage sont issues d’un travail collaboratif entre des experts de ce domaine. Vont-elles réduire significativement les émissions de votre propre site ? Cela dépend de nombreux facteurs, et il n’y a pas de réponse simple.

C’est pourquoi la démarche à suivre pour réduire son impact n’est pas d’appliquer les bonnes pratiques une à une, mais d’abord de faire un premier bilan sur cet impact, de prioriser les bonnes pratiques, de mesurer leur efficacité, et d’itérer. C’est une démarche classique d’amélioration continue.

Faire un premier bilan

Il faut commencer par mesurer l’impact de votre site. Et malheureusement, c’est plus facile à dire qu’à faire. Il existe des méthodes et des outils pour mesurer une partie de cet impact, mais aucune ne permet de le quantifier totalement en continu. Car l’impact, rappelons-le, est multiple :

• Impact lié à la construction des terminaux et à leur acheminement
• Impact lié à la consommation d’énergie côté client, réseau et serveur
• Impact lié à la fin de vie

L’approche la plus globale consiste à effectuer une Analyse du Cycle de Vie (ACV), audit normalisé de l’impact environnemental d’un produit (ISO 14 044). Ce genre d’audit, effectué habituellement par un cabinet spécialisé, prend plusieurs semaines et coûte cher – d’autant plus cher que votre site a de nombreuses ramifications et une architecture complexe. Il est néanmoins le seul apte à donner un résultat « officiel », que l’on peut inclure par exemple dans un rapport RSE. Mais son caractère ponctuel rend un tel audit peu pratique dans une démarche de réduction de son impact. En effet, comment valider ou invalider une bonne pratique si l’impact n’est mesuré qu’une fois par an ?

Voici une liste d’outils qui permettent de mesurer plus rapidement une partie de l’impact environnemental, et qui peuvent êtres utiles dans une démarche d’amélioration continue.

• GreenIT Analysis est un plugin pour navigateur qui estime la consommation d’énergie et les émissions de CO2 du client et du réseau. Il se base sur le trafic réseau, la complexité de la page, et le nombre de requêtes HTTP. C’est un outil gratuit et open-source édité par des volontaires du Collectif GreenIT, qui est aussi l’auteur de ce livre. (https://chrome.google.com/webstore/detail/greenit-analysis/mofbfhffeklkbebfclfaiifefjflcpad)
• GreenFrame est un service en SaaS qui estime la consommation d’énergie et les émissions de CO2 du client, du réseau et du serveur sur la base d’une simulation d’un scénario utilisateur dans un infrastructure conteneurisée. Il est conçu pour être appelé dans une Intégration Continue, via une API, et s’interface facilement avec les outils des développeurs. C’est un outil payant, sur abonnement, qui dispose d’un démonstrateur gratuit pour des analyses ponctuelles. (https://greenframe.io/)
• Scaphandre est un agent qui mesure la consommation d’énergie d’un serveur en temps réel et en production. Il se base sur les métriques système et s’intègre dans les infrastructures physiques et virtualisées. Il dispose d’une intégration à des outils de remontée d’alerte et de représentation graphique. C’est un outil gratuit et open-source. (https://github.com/hubblo-org/scaphandre)
• Power API est également un agent qui mesure la consommation d’énergie d’un serveur en temps réel et en production. Il se base sur les métriques système, et a été développé par l’université de Caen. C’est un outil gratuit et open-source (http://powerapi.org/).
• GreenSpector est un service en SaaS qui estime la consommation d’énergie et les émissions de CO2 des terminaux mobiles (smartphones et tablettes). Il utilise un banc de test avec des terminaux réels exécutant un scénario utilisateur. Il dispose d’une API pour s’interfacer avec une Intégration Continue. C’est un outil payant. (https://greenspector.com/en/home/)
• Microsoft Sustainability Calculator estime la consommation d’énergie et les émissions de CO2 à l’utilisation d’une infrastructure hébergée sur Azure. C’est un service payant basé sur PowerBI, réservé aux clients Azure. (https://appsource.microsoft.com/en-us/product/power-bi/coi-sustainability.emissions_impact_dashboard)
• Google Cloud carbon footprint Calculator estime la consommation d’énergie et les émissions de CO2 à l’utilisation d’une infrastructure hébergée sur Google Cloud. C’est un service payant gratuit, réservé aux clients Google Cloud. (https://cloud.google.com/carbon-footprint).

Deux services supplémentaires proposent des services similaires mais sont déconseillés, leur méthodologie ou leur modèle étant très sujets à caution :

• Website Carbon estime les émissions de CO2 du client sur la base du trafic réseau uniquement, et utilise un modèle daté qui surestime ces émissions. C’est un service en ligne gratuit dont le code est open-source. (https://www.websitecarbon.com/).
• Ecograder estime un score sur 100 notant la « vertitude » d’un site. Il se base sur des scores composites (nombre de requêtes réseau, accessibilité, qualité du référencement naturel, etc), dont la corrélation à l’impact environnemental n’est pas prouvée. C’est un service en ligne gratuit. (https://ecograder.com/)

D’autres services ne mesurent pas directement l’empreinte environnementale, mais la performance perçue par le client. Cet indicateur reflète indirectement l’influence d’un service sur le renouvellement des terminaux, puisqu’un utilisateur aura d’autant plus envie de changer de terminal que le service qu’il utilise est peu performant. Ces outils sont légion, et ce guide ne peut en citer qu’une poignée :

• Google LightHouse est un outil d’audit de performance des pages web, mais aussi de l’accessibilité et du référencement naturel. Il est gratuit et open-source. Il est intégré par défaut dans les developer tools du navigateur Chrome. (https://developers.google.com/web/tools/lighthouse/)
• PageSpeed Insight est un service d’audit de performance des pages web en ligne. Il permet de mesurer des métriques clés de la web performance (« First Contentful Paint », « First Input Delay », etc) et liste des suggestions d’améliorations. (https://pagespeed.web.dev/). C’st un service gratuit qui dispose d’une API.

Tous ces outils ne mesurent que l’impact de l’utilisation des services, et pas de leur fabrication ni l’impact de la fabrication des terminaux qui sont nécessaires pour les utiliser. Or une part prépondérante de l’impact environnemental d’un service est lié à la fabrication des équipements nécessaires à leur utilisation.

Pour estimer cet impact, testez la compatibilité de votre service avec des appareils et des systèmes anciens. Le score de votre service peut alors s’exprimer en années de rétro-compatibilité, par exemple : « mon service tourne sur 90% des appareils de plus de 7 ans ».

Il existe peu d’outils permettant d’automatiser ce genre de test.

• BrowserStack permet de tester un service numérique sur un panel d’appareils, d’OS et de navigateurs. Il dispose d’une API permettant d’automatiser des tests end-to-end multiplateformes. C’est un service payant, sur abonnement.

Au moment de la lecture de ces lignes, il existera sans doute d’autres services venant compléter la liste ci-dessus. N’hésitez pas à les tester, en vérifiant systématiquement les bases scientifiques de leur modèle.

Prioriser les bonnes pratiques

En général, l’impact environnemental est décroissant dans l’ordre suivant :

1. Construction des terminaux (smartphones, ordinateurs)
2. Utilisation des terminaux
3. Construction des équipements réseau
4. Utilisation du réseau
5. Construction des datacenters
6. Utilisation des serveurs
7. Développement du site web et outilllage associé

L’ordre de cette liste varie selon chaque site, son profil d’utilisation (B2B/B2C, pour mobile / pour desktop, trafic important / trafic épisodique), et son niveau de maturité.

Un premier bilan permet de détecter quelles composantes de votre site contribuent le plus à l’impact carbone.

Selon l’ordre que vous aurez déterminé pour votre site, vous pourrez prioriser les bonnes pratiques à mettre en œuvre.

Ainsi, si l’on prend en compte l’ordre de base listé ci-dessus, les bonnes pratiques visant à réduire le temps d’utilisation des terminaux (comme les pratiques d’optimisation des JavaScript) sont à mettre en œuvre avant celles d’optimisation des traitements serveur.

Il résultera de cette phase une liste ordonnée pour votre contexte de bonnes pratiques à tester.

Mesurer l’efficacité

La méthode scientifique permet d’apporter une réponse claire à la question « Est-ce que telle ou telle bonne pratique fonctionne pour moi ? ». La démarche est la suivante :

1. Formuler une hypothèse. Dans notre cas, l’hypothèse est du genre « l’application de la BP XXX réduira l’empreinte de mon service numérique de YY% ».
2. Imaginer une expérimentation pour valider ou invalider cette hypothèse. Pour l’empreinte d’un site, cela revient à a) sélectionner un scénario utilisateur, b) effectuer une mesure de l’empreinte de ce scénario, c) faire une modification dans le code ou l’infrastructure du service d) faire une seconde mesure du scénario et comparer.
3. Si l’expérimentation valide la bonne pratique, la généraliser à l’ensemble du service.

Les outils et services énumérés précédemment sont donc indispensables pour piloter une démarche de réduction de l’empreinte environnementale.

Itérer

L’optimisation de la performance environnementale d’un service numérique est un processus long et progressif. Certaines Bonnes Pratiques amèneront des résultats spectaculaires, d’autres n’auront pas d’effet perceptible. Certaines Bonnes Pratiques fonctionneront sur une page mais pas d’autres. Certaines bonnes pratiques pourront même avoir un effet négatif.

Un chantier de réduction de l’empreinte environnementale se déroule donc en général sur une durée longue, de plusieurs semaines à plusieurs mois. Ce chantier est divisé en petite tâches visant à tester une Bonne Pratique, ou à la généraliser.

Enfin, certains Bonnes Pratiques peuvent ne pas avoir d’effet mesurable en début de chantier (parce qu’une grosse partie de l’empreinte est générée ailleurs) et devenir pertinente une fois les optimisations majeures déjà mises en place. Il est donc important de revisiter les bonnes pratiques régulièrement.

De l’audit à l’assurance environnementale

La plupart des services numériques évoluent constamment. Des équipes de développement s’attachent en permanence à ajouter de nouvelles fonctionnalités, ou à corriger des bugs. Dans ce contexte, l’effet d’un chantier ponctuel de réduction de l’empreinte environnementale s’estompe rapidement avec le temps. En effet malgré une optimisation faite en début d’année, le code d’un développeur en fin d’année peut annuler l’optimisation.

Pour adresser ce risque inhérent au mode de développement en continu des services numériques, une solution existe : l’Intégration Continue. En effectuant une mesure de l’empreinte environnementale du service à chaque changement d’un développeur, et en définissant une limite haute pour cette empreinte, on peut garantir que l’empreinte n’augmentera pas après le chantier d’optimisation. Cela revient à passer d’une démarche d’audit environnementale à une démarche d’assurance environnementale, comme cela se fait couramment pour la sécurité, la performance, la maintenabilité, etc.

Le principe est le suivant :

• Identifier des scénarios d’usage typique du service
• Estimer, pour chacun de ces services, un « budget » maximum pour son empreinte environnementale (consommation d’énergie, CO2)
• A chaque modification du code, exécuter dans l’Intégration Continue une mesure de l’empreinte de chaque scénario
• Interdire la modification de code si le budget est dépassé

[ddebarbieux]

Merci pour ce travail!

Je l'ai lu en diagonal et je suis assez d'accord. C'est un super article de blog. J'ai du mal à voir quel place lui donner dans le livre. Par certains points il reprends des éléments de l'introduction même s'il lui ai très complémentaire.

Je suis prenneur de retour sur la section 'Mesurer l’efficacité'. Avoir une mesure concrète aidera convaicre de l'utilité d'une bonne pratique.

PS : Power API, c'est l'université de Lille ?

[ACTLEM]

Super, merci beaucoup @fzaninotto. C'est vraiment un beau travail. Pour moi c'est complémentaire sur beaucoup de points avec le début du livre (il faudra sûrement relire plus attentivement les deux, mais comme cela je n'ai pas vu de points de redondance).

Je me suis permis de créer une PR avec le texte pour pouvoir commenter, améliorer plus facilement: #328