Il en va de notre responsabilité professionnelle, voire de notre déontologie. Parmi ces "outils", l'un d'entre eux pèse dans la balance : la présence en ligne. Celle-ci se traduit dans la présence sur les réseaux sociaux notamment, et bien évidemment dans le site web, exercice de pédagogie commerciale souvent incontournable.
Pourquoi créer un nouvel user.io ?
La démarche de refonte de notre site web est née de la conjoncture de trois principales ambitions — entre autres choses et sans entrer dans le détail :
- mieux valoriser le travail que nous avons accompli pour nos clients (depuis 13 ans déjà !), nos réflexions sur le(s) métier(s) et leur évolution, les jobs et services que nous proposons, pour mieux présenter à nos potentiels clients et recrues ce que nous pourrions faire avec et pour eux — rien de bien extraordinaire en somme en matière de communication vers l’extérieur
- mettre à jour notre identité visuelle, parce qu’on en avait un peu soupé, parce que nous cherchions à mieux incarner la sobriété de notre signature de marque vis-à-vis des projets et identités de nos clients
- revoir à la baisse le coût environnemental de notre présence en ligne et mieux respecter la dimension durable de notre baseline
C’est à cette dernière ambition que cet article est consacré : les orientations de design et les choix techniques qui ont présidé à la création de notre nouvelle présence principale en ligne.
Les principaux leviers
Au fur et à mesure de l’avancée de notre projet nous avons tenté de mettre en œuvre les bonnes pratiques pour limiter notre impact global.
Qui dit impact global dit indicateur commun pour évaluer de manière comparable les impacts des différents objets et opérations. Ainsi que Tom Greenwood l’explique dans son livre Sustainable Web Design (que nous n’avons pas pu nous procurer d’occasion mais que nous lisons sur papier 😅) la quantité de données transférées et l’intensité carbone de l’électricité consommée dans l’utilisation des artefacts digitaux que nous créons sont très pragmatiquement les seuls indicateurs objectivables pour évaluer leur pollution. C’est cet aspect que nous employons pour évaluer in fine nos pages web, et en particulier via l’outil websitecarbon.com.
Par souci de complétude, nous avons aussi entamé une réflexion à propos de nos outils de conception et de mise en œuvre : le bilan carbone de l’utilisation d’outils consommateurs d’énergie mérite certainement largement d’être pris en compte dans le bilan global des efforts réalisés pour juguler le gaspillage d’énergie réalisé. Commençons justement par là.
Les outils de création et de mise en œuvre
Lorsque l’on se penche sur le bilan carbone global d’une voiture à propulsion électrique, on constate que le bilan de sa seule fabrication repousse de plusieurs milliers de kilomètres de route le moment où elle va commencer à être plus vertueuse qu’une voiture à propulsion thermique récente. Ce qui peut ressembler à une anomalie s’explique par plusieurs facteurs, dont l’un est prépondérant : l’extraction des minerais et la fabrication des composants d’une voiture électrique sont particulièrement énergivores. On pense aux batteries Lithium-ion bien entendu, mais aussi à tous les métaux du câblage électrique et électronique et aux nombreuses terres rares requises pour l’électronique. En particulier lorsque l’on inspecte plus en détail la manière dont ces fameuses terres rares sont extraites des sols chinois (dans leur immense majorité), l’on s’aperçoit que cette extraction se fait au moyen d’énergie électrique produite par des centrales à charbon — tout simplement la source d’énergie la plus polluante au monde.
Nous ne disposons ni du temps, ni même de la capacité à réaliser un tel calcul pour nos outils de création et mise en œuvre de sites web (les outils que nous employons ne sont pas, pour l’immense majorité d’entre eux, audités publiquement sur le plan du bilan carbone). Il s’agirait d’un véritable travail journalistique doublé d’un travail de bilan qui requiert une expertise scientifique très pointue mêlant compétences informatiques et sciences de l’énergie. Cependant il est possible de comparer les pratiques — et de s’interroger quant à l’opportunité d’en changer.
Outils de design
Le design de ce nouveau site s’est déroulé à cheval sur plusieurs périodes de confinement, lorsque les projets pour nos clients le permettaient. La collaboration entre nous a dû se réaliser notamment à l’aide d’outils de communication particulièrement énergivores (nos conférences visiophoniques passent essentiellement par l’outil Meet de Google et nos conversations se déroulent sur Slack, outil auquel nous restons connectés pendant toute la journée de travail afin de rester en contact). Quand bien même nous pouvions éteindre nos caméras lors de nos « conf calls », pour des collègues dont les déplacements vers le lieu de travail se faisaient à vélo ou en transports en commun, rien ne pouvait égaler la frugalité énergétique d’une conversation « in real life » telle que nous l’aurions eue sans ces fameux confinements. Sans parler du fait que le confinement nous a imposé la climatisation de nos lieux de vie personnels pendant la journée, une montée en puissance de la consommation électrique de nos box internet respectives…
Côté outil de conception, fin 2019 nous étions d’ores-et-déjà passés de Sketch à Figma pour tout ce que concerne le dessin vectoriel (typiquement quelque chose qui nous intéresse dans le cas d’un site web : le design d’écrans, de logotypes, de pictogrammes, d’un UI kit, de chartes…) mais aussi pour la construction de planches d’inspiration, délaissant InVision sur ce plan, ou même la fabrication de certaines présentations en slides… Ce changement s’est révélé particulièrement salvateur sur le plan de la collaboration à distance (notamment dans le design d’écrans en simultané), évitant de travailler en parallèle sur des fichiers différents qu’il aurait fallu ensuite s’envoyer. Sur le plan énergétique, il en est probablement tout autrement : sans connaître le bilan carbone d’un outil tel que Figma, aussi génial soit-il le simple fait qu’il repose sur un hébergement cloud (connecté en permanence à de potentiels multiples utilisateurs dont les productions et la moindre action sont instantanément diffusés vers les autres, qu’il permet d’enregistrer et d’afficher des images en très grande définition et qu’il sauvegarde très très régulièrement et ad vitam aeternam des versions successives de chacun des fichiers dans le cloud) n’inspire pas spécialement la frugalité. D’autant que, très opportunément, la conversation audio a fait son apparition dans l’outil afin d’intégrer ce qui se faisait d’ores-et-déjà de manière plus artisanale entre nous, à savoir s’appeler pendant des heures pour travailler en direct sur Figma.
Bref, le bilan carbone du design opérationnel de notre site n’est pas spécialement glorieux. C’est sur les choix de design que nous avons pu maîtriser de manière plus sensible le bilan à venir du site web une fois publié — nous y revenons un peu plus tard.
Outils de programmation
Côté outils de programmation, l’entrée en service d’un outil que nous utilisons habituellement dans nos maquettes et prototypes tangibles nous a permis d’économiser un peu d’énergie, mais aussi et peut-être surtout de franchir un pas symbolique : le Raspberry Pi, ordinateur miniature dont la puissance est limitée et incidemment dont la consommation d'énergie est extrêmement réduite par rapport aux ordinateurs standard du marché. Un rapport de 1 à 20 par exemple avec le classique portable de la marque à la pomme bien connue que nous sommes nombreux à utiliser quotidiennement pendant des heures. La version 4 de cette machine très économique permet d’afficher des pages web dans toutes les tailles requises et avec tous leurs atours interactifs sur Chromium, équivalent de Google Chrome sur Linux. Elle permet aussi de coder avec Visual Studio Code, c’est-à-dire précisément le même environnement de développement de prédilection pour les web devs que sous MacOS ou sous Windows. Seule limite, la compilation temps réel n’est souvent pas possible par manque de mémoire vive notamment, il n’est donc pas possible de débugger facilement des éléments logiques plus complexes. Mais la création de contenus ou de styles de pages est tout à fait efficace.
Ainsi une partie non négligeable de notre code a été réalisée sur Raspberry Pi 4, et le reste sur un Mac. Même si cette concession est in fine assez symbolique… elle est justement symbolique : elle préfigure une approche que nous espérons plus systématique dans le futur, à savoir un choix plus conscient de l’outil que nous employons pour les diverses tâches que nous réalisons. Un exemple trivial : pour la rédaction d’un court email, un smartphone bas de gamme et peu énergivore suffit. Ou encore pour la rédaction d’un article tel que celui-ci, une tablette munie d’un clavier est largement suffisante. Il n’est pas spécialement vertueux de démultiplier les appareils, mais lorsque nous en disposons il est opportun de s’interroger sur le choix de la machine à employer.
Les choix déterminants en matière de conception
L’un de ces choix relève tant du design que de la technique : un site web tel que le nôtre, c’est un site franchement statique, dont les contenus n’ont pas besoin de s’adapter outre mesure à chaque visiteur à la manière d’une web app telle que Gmail ou Facebook. Les contenus évoluent de temps en temps, typiquement à la faveur d’une publication d’offre d’emploi, d’article ou de nouvelle référence de projet. L’adaptabilité requise concerne essentiellement la langue (English version is coming !) et l’architecture des contenus en fonction de la taille du navigateur utilisé (la fameuse « responsivité »).
Le choix de langue (il y en aura deux, français et anglais) double le nombre de pages différentes à présenter aux visiteurs, à ceci près que certains articles ou offres d’emploi n’ont pas besoin d’être traduits en anglais. La responsivité, une fois les différents breakpoints dessinés, se définit quant à elle avec les fameuses « feuilles de style CSS » et peut, dans des cas spécifiques, se travailler aussi dans les contenus proposés selon le terminal : un contenu créé exclusivement pour mobile VS un contenu créé exclusivement pour tablette et/ou desktop. Nous sommes en train d’expérimenter cette approche « adaptative » pour de futures publications.
Light mode VS dark mode
Vous l’aurez peut-être remarqué, nous avons créé une version « dark mode » (mode sombre) du site qui permet de présenter un contraste inversé, plus agréable pour la lecture le soir (bascule automatique en fonction de l'heure), et qui s’adapte également de manière automatique aux préférences réglées par les visiteurs dans leur navigateur ou sur leur système d'exploitation. Ainsi que Greenwood l’explique, afficher Google Maps en dark mode permet de réduire de 63% le bilan carbone lié à l’affichage chez l’utilisateur. À noter que cet effort a un impact significatif pour les visiteurs du site au delà de l’aspect confort de lecture, la batterie de leur terminal se trouvant soulagée.
Images fixes et vidéos
La quantité de données qui transitent en ligne est mondialement tirée vers le haut par l’augmentation exponentielle du trafic vidéo ces dernières années. La taille des images utilisées est également responsable d’une part non négligeable de cette course folle.
Nous avons fait le choix de réduire à zéro le nombre d’images chargées par défaut dans chacune de nos pages. La base de notre structure de page se retrouvant ainsi typiquement à l’adresse https://user.io/legal (bilan : user.io/legal - Website Carbon Calculator). Ceci implique de transformer tous les pictogrammes ou éléments d’identité de marque en images vectorielles extrêmement légères (des SVG, intégrés directement dans les pages web pour également réduire le nombre de « requests » faites au serveur).
Aussi nous avons fait le choix de charger nos images de manière « lazy » : au lieu d'être chargées par défaut dans le navigateur du visiteur, elle ne sont chargées que quand elles entrent dans le champ visible du navigateur web (le « viewport »), d’où la transition visuelle que l’on peut percevoir en scrollant, d’un aplat coloré à l’image attendue. Ainsi, si elles se situent loin dans une page qui n'est pas "scrollée" jusqu'en bas, elles ne sont pas chargées : c'est autant de bande passante, de relais télécoms et de serveurs qui ne sont pas sollicités, et comme souvent la vitesse de chargement est favorisée côté visiteur. L’expérience s’en trouve légèrement troublée, mais c’est un mal que nous assumons pour réaliser de belles économies.
Cependant il faut bien le dire, c’est aussi dans notre utilisation des images que le bât blesse : les photos, écrans, schémas, dessins que nous employons pour présenter notre travail ne sont pas encore assez optimisés, et sont parfois très nombreux sur une même page. C’est principalement un héritage issu de notre contenu « historique », et une déformation professionnelle de nous autres designers qui souhaitons présenter le contenu le plus qualitatif possible de ce point de vue… c’est pas bien et nous devons travailler là-dessus.
Le framework de programmation, le serveur et l’alimentation de l’hébergement
Nous touchons au nerf de la guerre : quand bien même les meilleurs efforts et recommandations auront été faits lors de la conception, si la mise en œuvre pèche tout de même, les efforts initiaux seront annihilés. C’est un peu comme si après avoir appris la calligraphie la plus raffinée en école d’art et de design on se mettait à écrire des emails, des SMS et des slacks à longueur de journée… Ahaha.
Framework
L’un des choix fondamentaux réalisés très en amont dans le déroulement d’un projet web concerne le framework de programmation. Chez User Studio, nous utilisons VueJS depuis quelques d’années pour créer nos outils web sous forme de Progressive Web Apps (notre Dashboard de gestion de projet ou encore notre outil de veille d’équipe, Pins) et c’est tout naturellement vers ce framework très concis et intelligent que notre choix s’est porté, mais avec un objectif tout autre que dans le cas des PWA préalablement citées : faire le rendu en amont de l’ensemble des pages web nécessaires à la présentation de nos contenus afin de les servir telles quelles aux visiteurs, avec le niveau d’interaction le plus rudimentaire nécessaire à un site vitrine tel que le nôtre. Ainsi au lieu de produire des pages web "à la volée" à chaque connexion d'un navigateur ainsi que les frameworks de type Wordpress ou Drupal le requièrent, notre framework (Gridsome) utilise un paradigme frugal qui a pour objet de pré-produire toutes les pages possibles du site, une bonne fois pour toute (ce type de framework répond au doux nom de Static Site Generator). En somme, une fois produit, le fichier est servi tel quel au "client" par le serveur, sans aucune formalité ou calcul. Ainsi le serveur est considéré comme serveur statique, sorte de vulgaire disque dur végétatif branché sur le monde qui recrache bêtement des données sans même comprendre de quoi il s’agit. Serveur bête, soit, mais une économie considérable d'énergie est faite à chaque connexion.
Intensité carbone de l’hébergeur
D’autant que nos serveurs de pages sont hébergés chez Netlify : un hébergeur dont l’intensité carbone est maîtrisée car il se fournit en électricité produite à partir de sources renouvelables pour alimenter ses « data centers ». Ce choix d’hébergeur à lui tout seul constitue l’effort le plus significatif en matière de réduction de la pollution carbone issue de notre site web.
En outre, Netlify, comme notre hébergeur d’images fixes, Cloudinary, distribuent nos fichiers avec une logique de CDN (Content Delivery Network) : ce principe de démultiplication de data centers dans le monde auprès des grands pôles économiques notamment permet de rapprocher géographiquement les serveurs de nos visiteurs et ainsi de réduire le chemin parcouru par les données. Des données sourcées en local.
Nos vidéos quant à elles sont hébergées sur la plateforme Vimeo, qui ne s’est pour l’instant pas engagée dans un programme de durabilité. Youtube est plus en avance sur le sujet, mais Vimeo est plus respectueuse en matière de propriété de nos production et propose des contenus de manière plus mesurée. Un sujet que nous ne manquerons pas de suivre désormais !
Bilan
Le résultat pour certaines pages, à contenus à peu près constants, est assez encourageant. Typiquement, le bilan carbone de notre blog qui constitue l'une de nos pages les plus fréquentées a évolué favorablement selon l'algorithme de websitecarbon.com (ancien à gauche, nouveau à droite) :
Et au passage, voici en direct le bilan carbone de cet article que vous venez de lire (dans lequel nous avons évité d'intégrer trop d'images, à dessein) : https://www.websitecarbon.com/website/user-io-future-user-io-design-developpement-web-durable/.
Le chemin est encore long quant au travail de compression et d'écrémage que nous devons réaliser sur nos images publiées. L'image ci-dessus par exemple est au format GIF, beaucoup plus économique… il faudrait auditer l'ensemble de nos JPG et PNG pour évaluer si leur conversion dans un format moins gourmand n'en réduirait pas la qualité d'expression.
Au delà ce site web, c'est tout un ensemble de pratiques que nous devons évaluer, des outils de conception aux préconisations que nous fournissons pour nos clients en passant par la multitude de réalisations hebdomadaires qui sortent de chez User Studio.
Le travail ne fait que commencer, et il sera joyeux.
Références
- Nous avons suivi, et continuons de suivre pour les phases de complément et d'amélioration les préceptes du livre Sustainable Web Design de Tom Greenwood.
- Nombre de ces préceptes se retrouvent dans l’article 17 ways to make your website more energy efficient du même auteur.
- À noter qu'un manifeste sur le sujet, dont il est également l'auteur et que chacun peut signer, est disponible ici : https://www.sustainablewebmanifesto.com/.
- Les évaluations de bilan carbone que nous menons de nos pages web sont réalisés à partir du site https://www.websitecarbon.com.
- Un outil moins « grand public », en français, plus orienté web developer, sous la forme d'une extension du navigateur Chrome : GreenIT.