Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

Problématiques techniques

La mise en place du socle technique - architecture réseau, framework, outil de versioning, intégration de services tiers… - a justement pour objectif de favoriser l’appropriation par le client des outils techniques, puisqu’il en sera l’unique contributeur une fois la phase de MVP terminée.

De ce fait, le socle technique n’est pas un prototype (jetable), mais bien un produit pérenne qui évoluera au-delà de la phase de MVP. Ainsi, la notion de dette technique - c’est-à-dire l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet (selon la définition de Bastien Jaillot) - apparaît dès le début du projet, et doit donc être maîtrisée. Une des solutions consiste à réaliser régulièrement des mesures de la qualité du produit, puis de suivre leurs évolutions pour prendre les mesures correctives adéquates.

Différentes manières existent pour automatiser ainsi la mesure de la qualité. Parmi elles :

• L’analyse statique de code, qui permet de s’assurer de la qualité d’un produit sans avoir à l’exécuter. Les outils qui mettent en place ce type d’analyse agissent sur le code source logiciel. Un des outils les plus connu est sans doute SonarQube.
• Les tests logiciels, qui permettent de vérifier le comportement du produit. De tels outils agissent par conséquent sur le code exécuté. Selenium fait figure de référence dans ce domaine.
• Les outils d’analyse web, qui permettent de s’assurer de la qualité des sites web d’un point de vue extérieur; tel qu’un internaute ou un robot peut les voir. Citons par exemple les outils Dareboost ou Mozilla Observatory.

Si les deux premiers types d’outils s’automatisent très bien, le dernier ne dispose pas de cette souplesse, notamment parce que la plupart d'entre eux ne peuvent opérer qu’à distance, pour simuler au mieux les conditions d’usages qu’ils cherchent à reproduire.

Ainsi, si les équipes techniques effectuent déjà quotidiennement des mesures de qualité avec ces outils, leur utilisation manuelle est vite fastidieuse, compte-tenu de la multiplicité des MVP réalisés simultanément au sein de FABERNOVEL, de la fréquence (journalière) de ces analyses, et du nombre croissant de nouveaux outils utilisés (Qualys SSL Labs Server Test par exemple). De plus, leur mise en place sur les différents MVP est très disparate. Enfin, il n’est pas toujours nécessaire ou souhaitable de tous les analyser avec l’ensemble de ces outils, ce qui complexifie encore davantage leur utilisation au quotidien.

Il y a donc un besoin de consolidation de l’usage et d’automatisation de ces outils pour se figurer la qualité des MVP tels que les internautes peuvent les percevoir.

Heart : élaboration d’un outil

C’est dans ce contexte qu’a vu le jour Heart, un outil open-source et modulaire d’automatisation d’analyses de qualité web. Heart est la dénomination de l’ensemble des modules ; une manière simple de désigner cet ensemble. De par l’aspect modulaire de l’outil, cette dénomination recouvre en pratique une grande diversité de combinaisons de modules.

Modulaire, pour répondre aux besoins de chaque utilisateur (client dans notre cas). Ainsi, la majorité des fonctionnalités sont optionnelles. Les bénéfices qui découlent d’une telle architecture sont multiples :

• réduction de la fragilité : les bugs éventuels sont contenus dans les seules fonctionnalités choisies
• réduction du poids de l’outil
• évolutivité : si un nouveau besoin émerge, le(s) nouveau(x) module(s) n’ont qu’à être ajouté(s)

Automatisé, afin de gagner un temps précieux et ainsi maximiser la valeur ajoutée des actions des collaborateurs, comme nous le fîmes avec l’étape de déploiement il y a quelques années de cela.

Open-source enfin, car nous pensons que les problématiques que nous rencontrons, et qui nous ont amenés à l’élaboration de Heart, ne sont pas spécifiques à FABERNOVEL; elles concernent très probablement d’autres acteurs de l’industrie. Le code source est ainsi disponible sur GitLab, et les modules s’installent via le gestionnaire de dépendances NPM (exemple: Heart Dareboost).

Exemple de notifications Slack émises par le module Heart Slack

Heart : fonctionnement

Familles de modules

Heart est donc un ensemble de modules, répartis en 3 grandes familles :

• Déclencheurs, qui permettent de lancer les analyses
• Analyses, qui permettent d’analyser les URLs via les services tiers
• Écouteurs, qui réagissent une fois les résultats d’analyses connus

La conception modulaire de Heart permet de limiter l’installation à deux modules seulement : un module déclencheur (Heart CLI, voir ci-dessous), et un module d’analyse.

Modules existants

A l’heure actuelle, sont disponibles 2 modules déclencheurs :

• Heart CLI, obligatoire, qui permet de déclencher une analyse en utilisant la ligne de commande,
• Heart API, facultatif, lequel expose une API HTTP permettant de déclencher une analyse,

3 modules d’analyse dont la présence d’un au moins est obligatoire :

• Heart Dareboost, qui analyse les URLs via le service Dareboost,
• Heart Observatory, qui utilise Mozilla Observatory pour analyser l’URL voulue,
• Heart SSL Labs Server, permettant d’analyser un site grâce à Qualys SSL Labs Server,

et 2 modules écouteurs facultatifs:

• Heart BigQuery, qui stocke les résultats d’analyse dans une table Google BigQuery,
• Heart Slack, lequel envoie les résultats d’analyse sur un canal Slack dédié.

Exemple de dashboard qui exploite les données enregistrées par le module Heart BigQuery

Communication entre modules

Le diagramme ci-dessous illustre ce flux de données au sein d’une installation qui comprend un module déclencheur, deux modules d’analyse et deux modules écouteurs.

Tiré de cet exemple, le flux de communication général entre les différentes familles de modules est le suivant :

1. Un module déclencheur reçoit l’ordre d’exécution de l’analyse d’une URL via un service tiers
2. Ce dernier sollicite le module d’analyse concerné
3. Le module d’analyse sollicite à son tour le service tiers pour effectuer l’analyse
4. Une fois l’analyse terminée, les modules écouteurs sont notifiés, et les résultats de l’analyse leur sont transmis
5. Les modules écouteurs réagissent, par exemple en envoyant une notification ou en stockant les résultats de l’analyse dans une base de données

Pré-requis techniques et installation

Heart a été conçu de manière à limiter au maximum les dépendances nécessaires sur le système sur lequel il est installé. Ainsi, les seuls pré-requis d’un tel système sont :

• Le runtime JavaScript Node.js doit pouvoir être installé et exécuté
• Le système doit permettre l’usage de variables d’environnement
• Une connexion internet doit être disponible afin de permettre la sollicitation des services tiers

Une fois ces pré-requis satisfaits, installer Heart s’effectue en quelques étapes, détaillées dans la documentation technique (en anglais). Un exemple d’implémentation est également fourni.

Exemple d’usages

Compte-tenu de ces pré-requis limités, Heart peut être utilisé dans de nombreux contextes, tel que sur une machine personnelle, dans une instance Docker, ou bien encore dans un environnement d’intégration continue.

Transparence

Comme nous l’avons dit précédemment, les problématiques qui nous amenés à l’élaboration de l’outil Heart concernent très probablement d’autres acteurs de l’industrie. La solution que nous avons pu élaborer pouvant leur être utile, nous avons décidé de publier cet outil en open-source.

Cette publication en open-source sert également d’autres objectifs :

• faciliter l’identification d’éventuelles failles de sécurité, le code étant accessible
• stimuler l’innovation en autorisant les travaux dérivés
• s’adapter aux pratiques des développeurs en accueillant les suggestions externes
• participer à un écosystème logiciel dont nous tirons les bénéfices
• mettre en avant notre savoir-faire

Se pose également la question de la gestion communauté. Comment accueillir les contributions externes ? Comment élaborer une feuille de route pour l’outil ? Comment assurer les évolutions de l’outil ?

Toutes ces questions sont encore en réflexion à ce stade.

Feuille de route

En attendant, la liste des évolutions prévues est accessible, et plusieurs fonctionnalités sont déjà prévues.

Parmi celles-ci, l’ajout de nouveaux modules d’analyse: Google Lighthouse ainsi qu’un module orienté SEO. Il serait également intéressant de mettre en place un module d’évaluation de l’empreinte écologique d’une page (sous une forme différente, Green IT a récemment proposé un tel outil via une extension pour le navigateur Chrome).