Diminuer l'impact écologique dans le web

On parle sans cesse de "Transition numérique", partout, tout le temps. Mais on ne parle quasiment jamais de "Transition écologique". Pourtant, à bien des égards, les deux ne sont peut-être pas si éloignés.

Alors loin de moi l'envie de participer à la culpabilisation de masse sur l'écologie, l'encre coule déjà bien assez sur le sujet. Parlons un peu du numérique là-dedans.

Le numérique c'est un outil formidable, qui peut tout aussi bien réduire l'impact écologique que l'aggraver. L'utilisation déraisonnée du numérique peut engendrer des dépenses énergétiques non négligeables. La dépense énergétique du web est d'ailleurs un sujet préoccupant de ces dernières années.

Mais il y a une bonne nouvelle, là où nous avons besoin de performances, là où nous avons besoin de référencement, de clarté, de simplicité, nous pouvons faire en sorte de développer de manière éco-responsable. Et comme on a toujours besoin d'être performants, référencés et ergonomiques... tu vois où je veux en venir.

La transition numérique et la transition écologique sont deux axes complémentaires, qui peuvent, si on le veut, s'alimenter l'un-l'aute.

Une dernière chose à garder cependant en tête. Le moindre développement consomme, l'objectif ici est de réduire au maximum notre empreinte. Mais l'annuler complètement, c'est malheureusement illusoire.

Je propose donc de prendre en compte le principe de parcimonie :

Une fonctionnalité 100% écologique, est une fonctionnalité non-développée.

Côté littérature, je te conseille le livre Écoconception web : les 115 bonnes pratiques de Frédéric Bordage. Un must-have.

Sinon, tiré de ce même livre quelques liens utiles pour tester l'éco-responsabilité d'un site :

Quelques principes

Je ne vais pas faire un résumé du livre ou des pratiques, cela n'aurait pas tellement de sens, autant te conseiller d'aller directement à la source (et vraiment, je te le conseille).

Je vais simplement réagir sur quelques-unes, que je rencontre malheureusement trop souvent.

Tout comme le livre, je vais tâcher de les regrouper par phase-produit :

  1. Conception
  2. Côté client
  3. Côté serveur
  4. Hébergement
  5. Contenus

1. Conception

La définition des fonctionnalités

Puisqu'on utilise souvent le terme "taillé sur mesure", autant le faire réellement. Selon moi, et cela n'engage certes que moi, mais tout de même, le principe de parcimonie doit s'appliquer ici, le plus possible.

Premièrement parce qu'on sait très bien que 70% des fonctionnalités demandées :

Qu'on se le dise, 70% des fonctionnalités, sont donc de la perte sèche, ni plus, ni moins.

Et tu ne sais pas le plus drôle ?

Ces 70% de merdes empêchent les concepteurs de se concentrer sur les 30% réellement rentables, efficaces et qui ont besoin d'avoir des améliorations car elles sont le principe même du produit.

Donc pendant la phase conceptuelle, par pité, épure les concepts, et n'hésite pas à jeter de la fonctionnalité débile.

Pour cela, à chaque fonctionnalité il faut être exigeant au possible :

On peut toujours ajouter plus tard une fonctionnalité bien réfléchie, mais composer avec des fonctionnalités inutiles, est un coût qu'aucune entreprise ne peut se permettre (et pas seulement du point de vue écolo, financièrement aussi)

En définitive le plus important est :

  1. D'isoler ce qui est réellement important
  2. De quantifier, tout, tout le temps, c'est avec des chiffres qu'on réfléchit, qu'on mesure, même des ordres de grandeurs, ça donne de l'information
  3. De simplifier les fonctionnalités que l'on garde à leur plus simple objectif, c'est dans le nom : une fonctionnalité est une fonction qui transforme A en B.

Déjà si cet effort est correctement mené en amont, on aura moins de travail en aval pour optimiser, réparer, faire évoluer, maintenir... bref choisi ton verbe. Petite piqure de rappel :

Une fonctionnalité 100% écologique, économique et efficace, est une fonctionnalité non-développée.

Une fois les fonctionnalités définies correctement. Le principe de parcimonie continue sur la suite, à savoir le design.

Le design

C'est génial le design, surtout à notre époque ! On tend de plus en plus vers du simple, du clair, de l'ergonomique, de l'épuré. Pourquoi ? Parce que c'est :

Un design simple, c'est tout bénef. Alors certes, ce n'est pas simple à concevoir (c'est même l'inverse) et c'est encore plus dur d'en donner une personnalité. Mais le jeu en vaut largement la chandelle.

Et d'ailleurs concernant l'épuration du design, il serait temps en 2020 de se mettre à la conception mobile first, non ?

Le plus petit en premier

Alors ok, ce n'est pas le mobile first d'abord, mais plutôt le plus petit appareil utilisé par la clientèle qu'on devrait choisir. Mais franchement... dans 99% des cas ce sera le mobile, faut pas déconner.

Donc, pourquoi mobile first ? C'est pas juste parce que c'est plus simple de prendre un design petit et de l'agrandir (mais déjà ce simple constat représente d'énormes économies). Ben oui, quand on réduit les fonctionnalités au mobile, on ne vient pas bourrer encore plus ledit appareil à lui demander de charger des choses inutiles, déjà parce que ça revient à se tirer un boulet de canon au pied économiquement parlant (site lent = client qui se barre = pas de vente, c'est assez clair ou je te fais un dessin ?). Mais aussi et surtout, parce que c'est juste beaucoup plus simple de passer du mobile au desktop que de compresser un design desktop vers le mobile et le rendre impraticable par toute personne saine d'esprit.

Et oui, tes clients sont un minimum saint d'esprit. Quand même.

Le stockage des données

Stockage navigateur

C'est bon maintenant, on peut utiliser LocalStorage, WebStorage, SessionStorage, indexedDB. Donc ami développeur, tu vas pouvoir souffler un peu et te reposer sur les navigateurs, ouf !

Alors oui, on ne demande pas de conserver toutes les données mais un petit peu, cela évite les appels en base, les traitements côté serveur, le client ça reste le plus écologique (pas toujours, mais là, oui).

Json, Redis, Memcached

Si tu ne peux pas, tu as toujours les stockages en cache, Redis et compagnie. Je te laisse te documenter.

Mais prévoir les manières de stocker dès la conception, c'est faire des écologies !

Framework, CMS, le choix de l'architecture

Bon, c'est pas compliqué :

Pourquoi ? Parce qu'un framework apporte plus de contrôle, mais ce contrôle demande aussi de très bien concevoir et développer son produit. C'est donc un coût et un investissement. Mais on n'a rien sans rien.

J'ai conscience d'aller peut-être un peu vite en besogne sur ce point. Il est clair que mal conçu, un Framework sera une plaie sur tous les points sus-cités et un CMS épuré, bien développé et clairement conçu peut se révéler être formidable.

Mais dans tous les cas, c'est leur principe de fonctionnement et de développement qu'il faut garder en tête.

Un CMS utilise souvent des hooks, qui ont un coût énergétique, pas forcément énorme, mais non nul, là où un framework, que nenni !

Un CMS gère ses bases de données dans un objectif de correspondre au plus grand nombre d'applications, et ce faisant, rogne donc un peu sur les performances.

Et ce n'est pas tout, mais c'est déjà le plus important.

Ce n'est pas rédhibitoire, mais il faut le prendre en considération.

Et on termine la conception, sur la donnée, élément clé de tout logiciel.

Structurer la donnée

Je ne dirais qu'une chose :

Qui peut le plus, peut le moins, mais consomme à mort pour le faire.

Donc là encore on applique le principe de parcimonie. On ne sauvegarde que ce qui est utile, dans sa forme la plus simple possible. Et quand on doit appeler une page avec des données, on ne fait que transiter les éléments dont on a besoin, si possible en une seule fois, ni plus, ni moins.

Quand on dit, sur mesure, on fait vraiment du sur-mesure.

Je te fais confiance pour comprendre par tes propres moyens tous les bénéfices de faire cela (indice : performances, maintenabilité, écologie, RGPD aussi, etc.)

Pour la suite, je vais être succinct, je te propose des petites check-lists non exhaustives qui permettent de vérifier rapidement quelques bonnes pratiques performantes et écologiques.

2. Côté client

Concernant le CSS

Concernant le JS

Pour les deux derniers je jure qu'à force je vais finir par faire un article dessus.

3. Côté serveur

Stock

PHP

SQL

4. Hébergement

5. Contenus

La Conclusion

Je veux croire qu'un monde numérique vert est possible. Et ça m'a l'air d'être bel et bien le cas quand je me rends compte que quasiment toutes les bonnes pratiques du web et du développement en général, sont juste celles qui ont également le plus bas impact environnemental.

Donc nous n'avons plus la moindre excuse pour ne pas les appliquer.

Les sources

Je remets ici les sites de tests utiles :