L'éco-conception de services numériques consiste à considérer et réduire l'impact que va avoir un service numérique sur l'environnement, et ce lors de toutes les phases d'un projet :
Le recueil du besoin
La définition de l'expérience utilisateur
Le design
Choix d'architecture
Le développement
Le choix d'infrastructure
Comment avons-nous architecturé notre service numérique dans le cadre de l'éco-conception ?
Architecture fonctionnelle
Sans vouloir amoindrir la portée de notre site institutionnel, il ne s'agit ici que de la refonte d'un site web de contenu, complètement isolé de tout système d'information, dont le but est de mettre en avant notre image de marque.
Cette simplicité se reflète dans l'architecture fonctionnelle.
Une brique centrale, le site, sur lequel des contributeurs contribuent à des contenus, et des visiteurs visitent le site, dont certains iront jusqu'à utiliser le formulaire de contact.
Architecture technique
Non éco-conçue
L’architecture traditionnelle que nous mettons en œuvre pour ce genre d’application Web serait un CMS type Drupal. Cette technologie fonctionne bien et nos contributeurs en étaient jusqu'à présent satisfaits.
L'architecture aurait donc ressemblé à ça :
Mais nous ne sommes pas partis dans cette direction.
Pourquoi ? Tout simplement parce que nous avions comme objectif d'éco-concevoir ce nouveau site. Ce genre d'architecture nous aurait amené à construire une infrastructure relativement lourde :
Un serveur pour le reverse proxy
Un serveur pour le CMS
Un serveur de base de données
Un serveur pour le cache
Et encore, nous n'aurions pas eu une infrastructure solide et résiliente, pour ça il aurait fallu au moins doubler les différentes ressources ou mettre en place une scalabilité.
Une architecture éco-conçu, c'est une architecture qui, une fois déployée, sollicitera le moins de ressources possible.
Or ici, avec une architecture "à l'ancienne", ça n'aurait pas été le cas.
Nous nous devions donc de réfléchir à une autre alternative.
Éco-conçue
Un des maîtres-mots de l'éco-conception, c'est la simplicité, non pas dans la réalisation, mais dans le rendu final.
Nous nous sommes posé les questions suivantes :
Quelle est la technologie la plus simple en matière de web
Quelle technologie consomme le moins de ressources (ici coté serveur, la partie client sera abordée dans un futur article)
La réponse à ces questions : du HTML !
Quoi de plus simple que du HTML pour du web ?
Pas grand chose, le HTML c'est le langage qui est interprété par le navigateur, mais malheureusement, dans la plupart des cas, le code HTML est généré (plus ou moins) à la volée par un serveur. N'oublions pas que nous avions l'ambition d'utiliser le moins de ressources possible.
Retournons donc aux origines du web dans les années 90, créons un site statique ...
... mais moderne quand même.
Fini le temps où, pour les plus vieux d'entre nous, on utilisait un éditeur de texte pour écrire du HTML avant même que Dreamweaver n'existe (#nostalgie). Aujourd'hui nous avons toute une panoplie de beaux outils pour nous faciliter la vie, surtout pour la contribution des contenus.
Faisons un zoom technique à l'intérieur de la brique niji.fr de l'architecture fonctionnelle présentée au début de cet article.
Récapitulons le besoin :
Les contributeurs ont besoin de contribuer à des contenus
Les visiteurs ont besoin de visiter le site
Avec cette architecture fonctionnelle, nous répondons à ce besoin :
Un CMS pour la contribution
Un Front
Server Side Rendering (SSR) pour la génération d'un site statique
Static Site Generation (SSG) pour la prévisualisation des contenus contribués
Un serveur Web HTTP pour servir les pages HTML générées
Une fois cette architecture posée, nous sommes alors partis en quête des meilleurs outils / technos / framework.
Et voici à quoi ressemble l'architecture finale du nouveau site niji.fr.
Vous aurez peut être remarqué deux subtilités dans le schéma d'architecture :
Il n'y a pas de serveur de base de données.
C'est volontaire et ce n'est pas un oubli, à quoi bon déployer un serveur pour une base de données pour gérer quelques dizaines de contenus alors qu'un simple fichier SQLite fait parfaitement l'affaire.
Encore ici l'éco-conception à été poussée au maximumIl y a une interaction du contributeur avec l'interface de l'infogéreur pour "allumer" l'environnement de staging.
En effet, l'environnement de staging est "éteint" la plupart du temps. Il n'est "allumé" qu'à la demande par les contributeurs, et il "s'éteint" automatiquement ensuite.
J'ai mis les mots "allumé" et "éteint" entre guillemets parce qu'ici nous parlons d'un hébergement sur des VMs, elles ne sont pas réellement éteintes, mais décommissionnées, ce qui laisse de la place sur le serveur pour accueillir d'autres VMs à la place.
Notre nouveau site repose donc sur trois outils / technos :
Strapi : un CMS léger en node.js
Astro : un générateur de site statique permettant de générer des sites très légers (sans aucun JavaScript par défaut) tout en offrant un puissant langage de templating à base de JSX ou de Markdown.
S'appuyant sur le concept d'Island Architecture, il permet également de lazy-loader des composants React, Vue ou encore Svelte.
NGINX : un serveur web pour servir les pages HTML
Serveur Web vs CDN
Dans cette architecture, nous avons choisi de servir les pages HTML via un serveur web et non pas par un CDN, pourquoi ce choix ?
L'objectif principal de cette refonte étant "Sustainable de A à Z", il fallait considérer l'hébergement. Un CDN étant généralement une ressource mutualisée, ça aurait fait sens d'utiliser ce genre de service.
Mais une des principales raisons qui nous a poussés à ne pas utiliser ce genre de service, c'est la preuve. Nous avions besoin de prouver que notre solution d'hébergement était "green". Or les CDN sont des services hébergés pour la plupart dans le cloud et aujourd'hui, aucun des cloud providers n'est en mesure de nous fournir de vraies preuves du côté "vert" de leurs datacenters.
C'est donc pourquoi nous avons choisi d'héberger le site sur un serveur HTTP classique, qui se trouve dans un datacenter "green", que j'aurai l'occasion de vous présenter dans un prochain article.
La preuve
En guise de conclusion, comment être certain que l'architecture à base de génération de site statique est réellement éco-conçue ?
Grâce à la mesure.
Dans un précédent article, je vous expliquais comment mesurer l'impact environnemental des développements, c'est avec cette méthode de mesure que nous avons validé notre choix d'architecture.
Pour chaque nouvelle fonctionnalité développée (merge sur develop), nous avons lancé la même analyse, pour le même scénario de test, sur 2 infrastructures de tests différentes :
Une infrastructure avec le site statique (Serveur NGINX uniquement) (en bleu ciel ci-dessous)
Une infrastructure avec le site en mode SSR (Node.js en mode Server Side Rendering) qui fait des appels à l'API Strapi en live pour construire les pages (en bleu foncé ci-dessous)
Résultat : un site statique est 85% moins énergivore qu'un site avec un serveur qui construit les pages à la volée avec des appels API, la preuve en image
