Écoconception: 8 cas pratiques d’application
Cet article présente 8 principes avec leurs cas concrets d’actions allant dans le sens du numérique responsable. Si vous voulez comprendre pourquoi il est important de maîtriser son impact environnemental, nous vous encourageons à lire d’abord cet autre article Numérique responsable : contrainte ou opportunité ?
Le numérique responsable s’appuie sur trois piliers appelés les 3P : People, Planet, Profit. People pour inclure un maximum d’utilisateurs, éviter de proposer des services numériques élitistes (équité sociale) et améliorer l’expérience utilisateur. Planet pour garantir que les activités numériques de l’entreprise aient un impact maîtrisé sur l’environnement et garantir leur soutenabilité sur le long terme. Profit pour réduire les coûts de développement et de maintenance des services de l’entreprise.
Pour chaque principe évoqué, un exemple concret permettra d’illustrer la mise en pratique. Tous les aspects sont abordés: conception, UX, front, back, réseau, etc. Pour chacun, nous résumons les gains sur chaque axe des 3P.
Éliminer les fonctionnalités non essentielles
Dans l’imaginaire collectif, plus c’est mieux. La tendance actuelle dans le numérique est de proposer des solutions avec toujours plus de fonctionnalités, pour donner à l’utilisateur l’impression qu’il peut tout faire. L’idée est d’être en mesure de répondre à n’importe quel cas d’usage. Être exhaustif permet d’éviter de frustrer nos utilisateurs. La contrepartie est de tendre vers un obésiciel, c’est-à-dire un produit extrêmement riche avec un panel de fonctionnalités très vaste, dont une partie non négligeable ne sert qu’à une petite proportion d’utilisateurs.
Or, une fonctionnalité qui ne sert pas ou trop peu a un coût : le temps de développement, l’hébergement, la maintenance, l’utilisation de CPU si elle tourne inutilement (par exemple, en accompagnant une autre fonctionnalité très utilisée). Pour les utilisateurs, ces services gourmands nécessitent des machines toujours plus puissantes pour pouvoir profiter de ces solutions. Faute de matériel adéquat, les utilisateurs devront renoncer au service (perte de clientèle) ou changer leur matériel pour un plus puissant bien que le leur soit encore fonctionnel (coût environnemental).
Il est donc important de challenger l’utilisation de chaque fonctionnalité. Prenons par exemple le site de Boursorama Banque, qui propose dans un sous-menu The Corner des offres de promotions pour les vacances, loisirs, etc.
On peut légitimement se demander si cette fonctionnalité est pertinente sur le site d’une banque. Certes, elle peut être utile, mais les clients en ont-ils connaissance ? L’utilisent-ils ?
Pour pouvoir répondre à ces questions, il est nécessaire de mesurer le trafic sur cette page, le taux d’utilisation, etc. Le choix des métriques dépend de la fonctionnalité à mesurer. La clé est de fixer un seuil sur la bonne métrique pour déterminer si la fonctionnalité est suffisamment utilisée ou non. La solution préconisée repose sur la mise en place de traces et de sondes qui permettent d’obtenir les mesures nécessaires pour pouvoir ensuite les analyser.
Mais ce menu a déjà été développé et déployé, et il ne gêne personne. Alors pourquoi ne pas simplement le laisser ainsi ? Pourquoi passer encore du temps sur une fonctionnalité terminée ? Parce que le code associé nécessite malgré tout un stockage, de la maintenance, du temps de build, etc. La correction d’un bug sur un écran trop peu utilisé n’est pas rentable. Faut-il consacrer du temps à des évolutions sur cette fonctionnalité ? De plus, ce sous-menu est toujours présent dans le menu principal de Boursorama, ce qui alourdit la navigation pour tous les utilisateurs:
Dans le cas présent, il peut être intéressant de mesurer le nombre de clics dans ce menu par rapport au nombre de visites sur le site, pour connaître le taux d’utilisation et vérifier qu’il justifie l’existence de ce menu.
Gains sur chaque axe des 3P
People: l’expérience utilisateur est améliorée, l’application est plus claire et continue de tourner sur les appareils plus modestes.
Planet: moins de capacité d’hébergement nécessaire et de sollicitations réseau, et moins de renouvellement d’appareils par les utilisateurs.
Profit: en amont, cela permettrait de se questionner et d’éviter le coût de développement d’une fonctionnalité inutile. Sinon, diminution du coût de maintenance humain (dev) et matériel (hébergement).
Fluidifier le processus
Le temps passé sur un site a un coût financier et environnemental. L’utilisation du site sollicite le réseau, de l’énergie pour faire tourner les serveurs, de la scalabilité pour servir tous les utilisateurs… L’idée est donc de faire en sorte que l’utilisateur parvienne à son objectif en un minimum de temps. On peut penser qu’il est préférable de maximiser le temps passé par l’utilisateur sur le site. En réalité, un utilisateur qui passe trop de temps sur une action ou qui peine à atteindre son objectif aura plutôt une impression négative du site. Ce qui compte pour l’utilisateur est d’arriver au bout de son action facilement. Si l’expérience est pénible, il risque d’abandonner en cours de route et de ne plus revenir. Il est donc impératif de rendre son expérience la plus efficace possible.
Prenons ici l’exemple de Chronodrive. Pour un client régulier, il est courant d’avoir ses produits préférés, qui sont enregistrés en tant que favoris sur le site et reconnaissables par une étoile jaune. La plupart des utilisateurs ont leurs habitudes de consommation. C’est très pratique pour filtrer dessus et les retrouver facilement depuis la page produits.
Au moment de la recherche d’un produit via la barre de recherche, une popin s’ouvre et permet de proposer une courte liste de produits correspondants. Malheureusement, les produits favoris du client ne ressortent pas toujours dans cette liste.
Dans ce cas, l’utilisateur n’a pas d’autre choix que de valider sa recherche pour se rendre sur la page produits qui contient l’intégralité des résultats pour pouvoir alors filtrer sur ses favoris. Pourtant, quand un produit favori est proposé directement, il suffit alors d’un clic pour effectuer la mise au panier :
Il paraît pertinent de systématiser l’arrivée des produits favoris en premier dans cette liste pour fluidifier le processus. Cela évite d’ouvrir une autre page, avec tout le chargement que cela implique, et on éviterait d’afficher des dizaines de produits pour ensuite les filtrer sur ses favoris et n’en choisir qu’un. En plus, l’affichage de cette popin pousse l’utilisateur à lire la liste de produits, alors que son produit habituel n’y est pas. Il va donc passer inutilement du temps sur cet écran, et cela rallonge le temps nécessaire pour passer commande. Cela peut paraître anodin, mais rapporté au nombre de produits, au nombre d’utilisateurs, avec la régularité d’utilisation, le gain final serait loin d’être négligeable.
Gains sur chaque axe des 3P
People: amélioration de l’expérience utilisateur et de l’image de marque (le côté pratique).
Planet: diminuer le temps passé sur une application réduit la consommation énergétique de l’appareil de l’utilisateur et des machines hébergeant le service. Diminuer le nombre d’éléments chargés dans le navigateur réduit la consommation de bande passante.
Profit: fidélisation de la clientèle et diminution des coûts car moins de sollicitations du serveur.
Redimensionner les images en dehors du navigateur
Les images représentent souvent une part significative du poids total d’une page, notamment dans le e-commerce, où l’image est importante. Chaque image est téléchargée par le navigateur telle qu’elle est sauvegardée sur le serveur, quelle que soit la taille qui est ensuite affichée à l’utilisateur. L’utilisation des attributs height et width ne change rien au poids de l’image. De plus, le format de l’image a aussi un impact sur son poids.
Prenons ici l’exemple d’une jolie icône de bouton Suivant :
Admettons que nous souhaitons l’afficher dans une barre d’outils avec une taille de 24px par 24px. Il faut à la fois considérer la taille en pixels de l’image hébergée ainsi que son format, qui jouent sur le poids total du fichier. Voici ici un comparatif pour cette icône dans différents formats et tailles :
Ici, on peut voir que télécharger les images en 240px par 240px pour l’afficher en 24px par 24px engendre un surpoids significatif. Le ratio va de 1 à 100 sur notre exemple.
Nous sommes ici sur des petits formats, donc la différence peut sembler négligeable, mais il faut la multiplier par le nombre d’icônes sur une page, extrapoler le ratio pour des images plus volumineuses… Le SVG est pratique car il fait le même poids quelle que soit la taille affichée ensuite, ce qui offre une grande liberté, mais il a de bien meilleures performances sur des images simples ou monochromes. Le JPG est souvent plus léger que le PNG, mais il faut regarder au cas par cas pour chaque image.
Gains sur chaque axe des 3P
People: chargement des pages plus rapides, moins d’impression que la page rame à s’afficher.
Planet: moins de sollicitations réseau, images plus légères à héberger.
Profit: gain d’attractivité de l’application grâce à des pages performantes.
Mise en cache
Certaines données sont peu volatiles, il est inutile de requêter plusieurs fois des résultats identiques sur le serveur. Par défaut, les navigateurs mettent en cache les ressources statiques, telles que les images, fichiers js et css, etc. Le header Cache-control permet de contrôler les options de mise en cache, par exemple une durée maximale avant de redemander la ressource, ou une date d’expiration explicite. A moins d’avoir ce genre de besoins spécifiques, mieux vaut laisser le navigateur utiliser les options par défaut.
Parfois, on peut avoir un résultat de requête qui n’est pas une ressource mais qui varie peu au cours du temps et n’est pas spécifique à l’utilisateur. On peut citer par exemple des configurations globales du site, identiques pour tous les utilisateurs. Dans ce cas, il est intéressant de placer sur cette requête un cache HTTP, qui va reconnaître que la requête a déjà été jouée pour un utilisateur et qu’elle est redemandée à l’identique pour un autre utilisateur. Au lieu de réitérer son calcul, le cache va renvoyer directement le résultat précédemment retourné, ce qui permet d’éviter de solliciter l’application et déclencher des calculs ou lectures en base de données. Différentes options de mise en place sont possibles : passer par un cache externe type Varnish ou bien mettre en place soi-même son propre cache (ex: middleware express pour une application NodeJS). Dans les deux cas, il s’agit d’éviter d’arriver jusqu’au endpoint de notre application.
Sinon, lorsqu’un résultat de requête est long à calculer, une bonne idée est de le stocker en mémoire dans l’application afin de ressortir ce résultat directement lors du prochain appel. Cela permet de mutualiser des traitements entre plusieurs utilisateurs par exemple, et d’éviter de répéter les mêmes opérations inutilement.
Pour résumer, voici les places possibles pour les différents caches :
Le choix du cache dépend de la typologie de la donnée et de sa capacité de réutilisation.
Gains sur chaque axe des 3P
People: une application plus rapide et plus fluide.
Planet: moins d’utilisation du CPU et du disque, donc réduction du nombre de machines pour servir les requêtes.
Profit: coût d’hébergement réduit.
Limiter le nombre de requêtes HTTP
Aujourd’hui, les utilisateurs n’ont que peu de patience pour attendre l’affichage d’une page. Si une page nécessite un grand nombre de requêtes pour s’afficher entièrement et devenir interactive, l’expérience peut se révéler très pénible pour les utilisateurs, donnant l’impression que la page rame. Plus une page met du temps à s’afficher, plus le nombre d’utilisateurs qui renoncent augmente.
Prenons l’exemple du site internet de La Poste, sur lequel on peut trouver une boutique e-commerce permettant d’acheter divers biens, notamment du matériel de déménagement. Lorsqu’on arrive sur cette page, le nombre de requêtes initiales est si grand (272 requêtes !) qu’il faut presque 20 secondes pour que la page soit totalement chargée. Pendant ce laps de temps, on voit les images sauter et les éléments se replacer, et la page n’est pas encore interactive. Et son poids final est de 11,5 Mo, ce qui est énorme !
Ici, nous sommes sur ordinateur en métropole avec la fibre. Sur mobile ou sur un réseau moins performant, la plupart des utilisateurs abandonneront avant que la page soit chargée.
Sur cette page, il faudrait analyser la nature des requêtes pour les regrouper, les différer, les éliminer éventuellement. Il faudrait aussi éviter d’appeler plusieurs domaines depuis la même page car le navigateur doit ouvrir une connexion HTTP par domaine, ce qui est assez gourmand en temps d’exécution. Pour les images, l’utilisation du lazy-loading permet d’éviter de télécharger celles qui ne s’affichent pas encore à l’écran, et de les récupérer au moment de l’affichage. Les ressources statiques type js ou css peuvent être regroupées en un fichier minifié chacun, et se limiter à ce qui est utile pour cette page. S’il n’est pas possible de regrouper toutes les requêtes, il vaut mieux préparer un squelette de page pour le placement des éléments, afin d’éviter cette impression de page qui saute.
Gains sur chaque axe des 3P
People: site plus rapidement chargé, plus accessible pour les appareils plus modestes, expérience plus fluide et plus agréable.
Planet: moins de sollicitations réseau, moins de machines pour servir toutes les requêtes, moins de repaint/reflow côté front et donc moins d’utilisation de la batterie.
Profit: rétention de la clientèle, image de marque, coût d’hébergement réduit.
Debounce
Sur un site, il est fréquent de mettre à disposition un champ de recherche, dans lequel l’utilisateur saisit ce qu’il cherche. Une fonctionnalité intéressante est de lui proposer aussitôt des suggestions qui correspondent à ce qu’il est en train de taper.
L’inconvénient de ce type de fonctionnalité est qu’à chaque lettre tapée par l’utilisateur, une requête part côté serveur pour obtenir les suggestions. Tant que l’utilisateur est en train de taper, il ne s’y intéresse pas immédiatement. Pour un utilisateur qui tape vite, plusieurs requêtes vont partir en parallèle alors que seul le dernier résultat sera utile.
Il peut être intéressant ici d’attendre une courte pause de la part de l’utilisateur, et de n’envoyer la requête qu’une seule fois avec la dernière valeur du champ. C’est ce qu’on appelle le debounce : attendre un délai défini avant de déclencher une action, et si elle est redemandée avant que ce temps soit écoulé, alors annuler l’exécution précédente et relancer le délai de zéro. Cela permet d’éviter un bon nombre d’appels intermédiaires inutiles.
Lodash propose une fonction debounce. Voici ici un exemple de mise en place, où on imprime en console la valeur saisie si l’utilisateur arrête de taper pendant 500ms (compatible aussi avec Typescript).
Évidemment, cette fonctionnalité n’est pas à appliquer systématiquement, elle dépend du besoin de performance attendu. Par exemple, elle peut être inadaptée sur un site e-commerce qui a besoin de réactivité, mais très intéressante sur un outil interne. Il faut par ailleurs ajuster le délai pour que cela reste confortable à l’utilisation, et même quasiment imperceptible.
Gains sur chaque axe des 3P
People: éviter les appels réseau superflus (data) et économiser la batterie.
Planet: diminuer le nombre d’appels réseau et le nombre de serveurs nécessaires pour répondre à l’afflux de requêtes.
Profit: moins de machines signifie moins de coût d’hébergement.
Privilégier les changements visuels instantanés
Les animations peuvent être très utiles pour montrer un fonctionnement dans une application. Elles doivent être au service de l’UX pour mettre en évidence un changement. Néanmoins, les animations sollicitent beaucoup le CPU ainsi que la batterie, car elles nécessitent un succession de repaint/reflow dans le navigateur. Il vaut donc mieux les éviter lorsqu’elles n’ont pas une utilité avérée.
Voici typiquement le cas d’une animation qui apporte peu de valeur : cliquer sur un bouton fait apparaître un contenu avec une animation de fade in au lieu d’une simple apparition instantanée.
Ici, il vaudrait mieux tout simplement retirer l’animation et laisser le contenu apparaître instantanément. Cela reviendra au même pour l’utilisateur. Toutes les animations ne sont pas à bannir, il faut juste s’en servir avec parcimonie quand elles portent du sens. Par exemple, une animation qui met en avant une mise à jour suite à une action de l’utilisateur peut être pertinente car elle sert à la compréhension par l’utilisateur.
Gains sur chaque axe des 3P
People: éviter de fatiguer la batterie de l’utilisateur.
Planet: moins de consommation CPU et rallonger la durée de vie des batteries.
Profit: diminuer le coût de développement et maintenance liés à la mise en place des animations.
Remplacer les boutons officiels de partage des réseaux sociaux
Il est intéressant de mettre sur son site les boutons de partage des réseaux sociaux tels que Facebook, Twitter, etc. Ces réseaux sociaux fournissent des plugins tout faits à intégrer directement pour placer un bouton de partage directement dans sa page.
Par exemple, pour le bouton Partager de Facebook, en suivant la documentation officielle, on obtient ce bouton avec ce code :
Par contre, rien qu’avec ce petit bouton de partage, on a déjà une page d’un poids de 200 ko. Et ce n’est qu’un bouton de partage, imaginez mettre plusieurs réseaux sociaux, le poids de votre page est déjà considérablement augmenté.
Il est possible d’obtenir un résultat identique avec un simple lien vers la page de partage Facebook et un peu de style :
L’effort d’intégration n’est pas beaucoup plus élevé (de l’ordre de quelques minutes supplémentaires sur cet exemple), mais notre page est passée de 214 ko à 10 ko ! Alors que l’action au clic est exactement la même, l’expérience utilisateur est identique dans les deux cas.
Gains sur chaque axe des 3P
People: chargement de page plus rapide, meilleure inclusion des configurations modestes.
Planet: moins de sollicitation de la batterie, moins de réseau utilisé.
Profit: capacité à conserver les utilisateurs aux configurations modestes.
Nous avons abordé 8 cas concrets sur lesquels il serait judicieux d’appliquer des principes d’éco-conception. Dans chacun de ces cas, il y a des gains pour les utilisateurs, pour la planète et pour l’entreprise. Leur mise en place engage un cercle vertueux et bénéfique pour tous, même si elle peut demander des efforts pour certains des exemples donnés. Dans tous les cas, les bénéfices sont présents.
Ce n’est qu’un petit échantillon de toutes les pratiques d’éco-conception qu’il est possible de mettre en place. Pour en découvrir d’autres, vous pouvez vous référer au guide Ecoconception web: les 115 bonnes pratiques qui nous a largement inspirés.
Co-écrit par Célia et Rémi Doolaeghe
