Rechercher
Je deviens Shifter

Vous êtes ici :

(éco)Conception

Le Site Web des Shifters – SWS de son petit nom – est le fruit du travail de toute une équipe sur de longs mois pour construire un site qui nous ressemble. C’est aussi toute une démarche d’éco-conception pour trouver le juste équilibre entre les enjeux de sobriété numérique et les objectifs d’avoir un site ergonomique et attrayant, à destination d’une population grandissante de Shifters.
Petit tour d’horizon sur les coulisses de ce site…

Écoconception

À chaque étape, de sa conception à sa réalisation et à chaque évolution, nous essayons de maitriser son impact écologique.

Choix technologique

Nous avions comme pré-requis d’avoir un CMS pour permettre à des équipes non-techniques d’actualiser le site. Donc, pour réduire notre impact, nous avons fait le choix d’utiliser un générateur de site statique qui viendrait, lors de la modification des contenus et de leur publication, récupérer les nouvelles contributions et se redéployer. Cela afin de réduire la tension énergétique sur le serveur et la base de données, ce que ne permet pas de faire un CMS classique.

Nous avons aussi fait le choix technologique d’utiliser un framework CSS pour simplifier la gestion du design au vu de l’hétérogénéité de l’équipe sur ce point. Contrairement aux frameworks CSS traditionnels, une étape de compilation permet de ne conserver que les déclarations de style réellement utilisées par les pages lors de la mise à disposition du site. Ceci permet de diminuer considérablement le poids des pages.

Rendre écoresponsable le besoin

À chaque demande de nouvelle fonctionnalité, nous interrogeons l’équipe en charge de la contribution sur

  • la réelle nécessité de celle-ci, « la fonctionnalité qui à le moins d’impact est celle qui n’existe pas » ;
  • si l’on ne peut pas faire autrement (faire un lien mailto: plutôt qu’un formulaire, par exemple) ;
  • si la fonctionnalité n’existe pas déjà ailleurs et fait donc doublon. Si oui, alors le choix de désactiver une des deux doit être fait.

Ainsi, lorsque la fonctionnalité est jugée nécessaire, nous nous demandons comment l’implémenter avec comme objectif d’en limiter son impact écologique sur les terminaux utilisateurs, le réseau et les serveurs, tout en assurant une expérience utilisateur optimale.

  • en cherchant comment réutiliser un composant existant qui pourrait faire le job, cela permet de ne pas augmenter le volume de code du projet ;
  • en développant un nouveau composant ayant un impact maitrisé.

Dans tous les cas, nous optimisons les « requêtes » afin de réduire le volume de données échangé.

Architecture technique

Cette partie de la description est destinée davantage aux profils techniques qui s’intéressent aux arcanes du site, tout en restant « relativement » accessible aux profanes

Architecture WordPress

A écrire

Les bénéfices ?

  • A écrire
  • D’abord la performance du site : Pas besoin d’attendre que le serveur génère la page pour l’afficher sur ton navigateur. C’est du simple affichage d’une page statique et de son contenu pré-généré. Le site étant également une Single Page Application, un changement de page n’implique qu’un chargement des nouveaux contenus. La structure de la page n’est ni regénérée par le serveur, ni envoyée par le réseau. Et comme cela sollicite beaucoup moins les infrastructures serveurs et le réseau, cela consomme beaucoup moins d’énergie aussi !
  • Ensuite la sécurité du site : Il n’y a que des pages web statiques à « voler ». Il n’y a pas d’accès possible à un base de données, aucune faille exploitable par l’execution d’un script. Et si il n’y a rien à voler, on limite ainsi les tentatives de hack et les indisponibilités du site web qui vont avec.
  • Enfin la facilité de gestion : On sépare complètement la gestion du contenu (le CMS) et le rendu à l’affichage de ce contenu (par le générateur de site statique). Les rédacteurs peuvent ainsi tranquillement rédiger leur articles sans se soucier des contingences HTML d’une page. Et les développeurs front-end peuvent travailler tranquillement sur le rendu graphique et sur la disposition des contenus, sans interférer avec les rédacteurs.

Infrastructure

Les différentes machines qui hébergent les outils ci-dessus sont virtuelles. Elles proviennent de la plateforme Cloud Jelastic, qui est fournie par l’infrastructure d’Infomaniak.
Infomaniak est un hébergeur suisse, qui s’est engagé de longue date pour protéger l’environnement (énergies renouvelables, performance énergétique, compensation carbone,etc.).
La gestion des environnements déployés est fait sous Docker, ce qui contribue à l’interopérabilité de notre solution.
Pour le stockage des données, nous utilisons MariaDB, un système de gestion de bases de données open source basé sur MySQL.
Pour la partie service web (serveur web, reverse proxy, cache HTTP, load balancer,…) nous utilisons la solution open source F5 Nginx.

Moyens de développement collaboratifs

L’équipe travaillant de manière asynchrone (les disponibilités étant rarement compatibles entre elles), nous utilisons une plateforme GitLab pour suivre le traitement des incidents et des bugs, le développement de nouvelles fonctionnalités, leur qualification, leur intégration, etc. La plateforme utilise le composant d’intégration et de déploiement continue (CI/CD).
Pour une meilleure communication asynchrone, tous les échanges destinés au projet se passent aussi par là, via les commentaires.
Enfin nous avons un focus particulier sur la documentation à produire à chaque étape, qui est primordiale pour la pérennité et la maintenabilité du projet.