Qualité frontend : à la recherche du AAA

Le World Wide Web créé par Tim Berners-Lee en 1989 au CERN ¹ s'appuie sur 3 technologies : URL, HTTP et HTML. Notre proposition se concentre sur cette troisième technologie, l'HTML, qui est toujours omniprésente et qui détermine la qualité de l'expérience Web.

En tant que développeurs et développeuses Web, nous produisons de l'HTML tous les jours. Nous avons à cœur de produire le meilleur code HTML possible, ce qui implique de définir ce qu'est un excellent code HTML. Pour cela, nous introduisons dans cet article la notion de balisage pur et parfait qui dessine un étalon de qualité en termes d'accessibilité, de sémantique, d'empreinte écologique, de performance et de minimisation du bruit. Nous ne prétendons pas produire un balisage pur et parfait, c'est un chantier qui devra être coopératif et évolutif. En revanche nous affirmons que la notion est nécessaire pour tendre vers un idéal, qui n'est aujourd'hui pas défini, donc pas consensuel.

Afin d'adresser de façon différenciée les projets Web en fonction de leur nature (information / action / émotion) et de leurs usages (public / privé), nous proposons un classement en trois niveaux. Le niveau A fixe un standard minimum acceptable, pertinent pour les usages privés de type back-office. Le niveau AA, ou double-A, fixe un standard correct pour la plupart des productions Web. Le niveau AAA, ou triple-A, fixe le standard d'excellence absolu, le balisage pur et parfait.

1. Standard

Le premier enjeu, évident, est le respect du standard HTML, tel que défini par le World Wide Web Consortium ². Depuis 2019 c'est un format unique, qui dispose d'une documentation à l'intention des devs ³ ainsi que d'un service de validation permettant de tester son balisage⁴.

2. Accessible

Le second enjeu est celui de l'accessibilité, c'est-à-dire de la minimisation de l'exclusion. Un service numérique accessible est perceptible, utilisable, compréhensible et robuste, d'après le Référentiel Général d'Amélioration de l'Accessibilité ⁵. Le référentiel définit des critères mesurables et des niveaux de conformité, qui présentent un caractère contraignant pour les services publics.

3. Qualitatif

En troisième lieu, la maîtrise de la qualité Web passe par le respect des 240 règles Opquast ⁶. Cet ensemble de bonnes pratiques en Creative Commons est élaboré depuis 2000 par des centaines de professionnelles et professionnels du Web. Chaque règle est universelle, utile, documentée, sans valeur numérique, fait consensus et n'est pas liée à un pays ou une loi spécifique.

4. Sémantique

Un balisage HTML de grande qualité définit de manière sémantique le contenu des pages. Cette qualification des objets par leur nature permet de nourrir le Web sémantique et de se rapprocher du Graph Global Géant ⁷ inventé par Tim Berners Lee en 2007. Si le WWW partage des pages, le GGG partage des connaissances, compréhensibles par des humains comme par des algorithmes. Le projet Schema.org ⁸ liste les vocabulaires consensuels pour définir un grand nombre d'objets du monde réel, et les relations entre ces objets. Ces vocabulaires thématiques se nomment ontologies.

5. SEO

Un balisage respectueux du standard HTML et sémantique est parfait pour les moteurs de recherche. Cela remplit la part technique du Search Engine Optimization (SEO). En pratique, des balises parasites propriétaires sont souvent ajoutées afin d'améliorer les partages sur les réseaux sociaux, notamment Facebook et Twitter. Dans un monde parfaitement interopérable, ces balises ne devraient pas exister, et les réseaux sociaux devraient utiliser les informations neutres et standardisées à leur disposition. Le compromis entre le balisage idéal et le balisage pragmatique devra faire l'objet d'un consensus, réévalué en fonction des évolutions des acteurs.

6. Sobre

Un frontend de grande qualité doit être aussi sobre que possible. Le Référentiel Général d'Écoconception de Services Numériques ⁹ propose un jeu de critères de haut niveau applicables au frontend. À un niveau plus bas, la mise en œuvre de l'écoconception est facilitée par un ensemble d'indicateurs nommés Web Vitals par Google ¹⁰. Ces métriques lient sobriété et performance, et sont assorties d'exemples de bonnes pratiques et d'études de cas.

7. Pur

Ces 6 critères constituent la perfection du balisage. Nous y ajoutons la nécessité de minimiser le bruit, qui constitue sa pureté. Le rapport signal/bruit ¹¹ est un indicateur de la qualité de transmission d'une information, mesuré habituellement en décibels. Curieusement, cet indicateur largement consensuel dans de nombreux domaines ne semble pas influencer le développement frontend. Le balisage pur et parfait présente une analogie avec le son haute-fidélité, c'est une sorte d'HTML Hi-Fi dans lequel il y a toute l'information et rien de plus.

Ces 7 critères définissent le quoi, le résultat que nous souhaitons atteindre. Mais les devs sont (malheureusement) souvent plus intéressés par le comment, les outils, les méthodes et les gadgets utilisables pour atteindre ce résultat. Plusieurs enjeux s'entrecroisent. D'abord, la rapidité de production : comment produire vite et faire évoluer rapidement. Ensuite, la maintenabilité : comment éviter de se retrouver avec une assiette de spaghetti impossible à démêler, ce qui a un impact sur la rapidité mais aussi sur la stabilité. Plus le code est compliqué, plus il présente d'effets de bord indésirables. Enfin, la courbe d'apprentissage : les méthodes utilisées sont-elles longues à apprendre ? Et dans tous les cas, si on en change, il faut réapprendre.

Quels outils avons-nous à notre disposition, en 2022 ? Faisons l'inventaire…

Rappelons quelques concepts de base pour les lecteurs et lectrices qui ne coderaient pas, ou pas du Web. Le cœur du Web est l'HTML, qui permet de structurer les informations. L'apparence de ces informations (les typographies, les couleurs, la mise en page...) est définie par les feuilles de style en cascade, le CSS. Une partie de l'interactivité est directement intégrée à l'HTML, par exemple les boutons, les formulaires ou les liens hypertexte. Les comportements plus sophistiqués sont développés en JavaScript. En synthèse, nous avons donc 3 composants : l'HTML (le sens et l'interactivité basique), le CSS (l'apparence) et le JS (l'interactivité avancée).  

La base low-tech consiste à écrire du code HTML, CSS et JS dans un éditeur de texte. Comme les pages HTML présentent de nombreux éléments répétitifs, plusieurs outils permettent de réutiliser du code d'une page sur l'autre. En termes techniques, si l'on se situe dans le cadre d'une application Web, on codera souvent les vues du pattern Modèle Vue Controlleur (MVC), en utilisant des mécanismes de template et d'inclusion de fragments de code. Si l'on se situe dans un projet sans base de données ni technologie backend, on utilisera souvent un générateur de site statique qui propose les mêmes mécanismes. Ces infrastructures n'ont pas d'impact sur la qualité frontend (les 6 premiers enjeux), et elles permettent aux devs d'organiser leur code et de ne pas se répéter (le 7e enjeu). Nous ne détaillerons pas plus ces questions, mais nous invitons les devs à rester DRY ¹², et à utiliser pour cela les outils qui conviennent le mieux au projet et à l'équipe.  

Le CSS a une syntaxe verbeuse, avec des parenthèses, des accolades, des règles de fermeture strictes et un seul niveau de déclaration. Pour pallier ces défauts, plusieurs technologies se sont développées, par exemple Sass, Less et Stylus. On les appelle des préprocesseurs, c'est-à-dire des outils qui traitent un langage spécifique pour générer du CSS. Là encore, nous laissons aux devs le choix des armes, avec toutefois un point de vigilance : ces outils peuvent causer une augmentation involontaire du poids du CSS et une diminution de son efficacité. Il convient donc de les employer en surveillant la traduction CSS, et avec une bonne culture du mode d'application du CSS sur le document HTML (le Document Object Model, DOM).  

Une autre école de pensée est partie de l'idée que l'on pouvait standardiser les interfaces et s'appuyer sur des classes HTML pour définir l'apparence. Ces frameworks CSS, dont le plus répandu est Bootstrap, favorisent la rapidité du développement, puisqu'on définit l'apparence sans écrire de CSS. On gagne également du temps de formation, puisque le framework est réutilisé d'un projet à l'autre. Toutefois, ce gain se fait au prix de deux sacrifices importants. Premièrement, le balisage HTML est pollué, parfois au point que l'on cherche le contenu dans une forêt de balises définissant l'apparence. Deuxièmement, les frameworks sont lourds, puisqu'ils intègrent un grand nombre de possibilités. Afin de résoudre ce problème, certains frameworks comme Tailwind proposent des solutions techniques pour limiter le poids aux éléments réellement utilisés. Il faut donc choisir les outils à intégrer en fonction des besoins, et l'outil perd en simplicité ce qu'il gagne en adaptabilité. L'outil PurgeCSS a été développé pour purger le CSS de toutes les directives non utilisées dans l'HTML. Cela revient à remplir un atelier de tous les outils possibles, puis à le vider en espérant laisser uniquement les outils utiles. Et dans tous les cas, l'HTML n'est pas pur.  

D'autres outils ou frameworks, beaucoup plus confidentiels, sont respectueux de l'HTML et ne le surchargent pas. On peut citer Ariato ¹³, développé par Base Secrète, et PicoCSS ¹⁴, par Lucas Larroche. Ces librairies sont très pertinentes pour améliorer le rendu de base de l'HTML, par exemple pour un back-office. En revanche, elles sont volontairement minimales, et intègrent des points de vue esthétiques qui peuvent ne pas convenir en fonction du projet. Il existe aussi des librairies de comportement, comme Compass, qui permettent d'écrire plus rapidement du CSS, sans imposer de bruit HTML. Ces librairies peuvent être utile, avec la même réserve que celle exprimée pour les préprocesseurs : il faut veiller à ce que le code généré soit compact et efficient.  

Des méthodologies comme BEM ou SMACSS proposent une façon standardisée de structurer l'HTML et le CSS, en fonction de logiques applicatives. Ces méthodes permettent de créer des conventions, et donc de minimiser la surprise et le temps de formation d'un projet à l'autre. En revanche, ces conventions se superposent au balisage sémantique et ajoutent du bruit à l'HTML. Si les logiques métier sont bien respectées, et que les devs s'interdisent d'intégrer des éléments purement formels dans le balisage, le bruit est bien moindre avec BEM ou SMACSS qu'avec un framework comme Bootstrap ou Foundation. D'autres méthodes, comme le pattern 7-1 et ITCSS, proposent une façon de ranger les fichiers utilisés par le préprocesseur. Nous laissons aux équipes le choix de la structure qui leur convient le mieux, cela n'a aucun impact sur la qualité front.  

De (trop) nombreuses librairies JavaScript sont développées pour proposer des fonctionnements encapsulés de toutes sortes. Toutes ces librairies ont un poids physique et cognitif. Physique, parce que ce sont des données qu'il faut transférer sur le réseau, puis des algorithmes à exécuter sur le périphérique de la personne avec parfois un effet important sur la performance, donc la batterie et l'impression d'obsolescence. Cognitif, parce qu'il faut apprendre à utiliser ces librairies, puis les maintenir : suivre leur évolution, appliquer leurs correctifs de sécurité et faire évoluer le code en cas de mise à jour majeure, non compatible avec la version précédente. La première question à poser avant l'utilisation d'une librairie concerne son utilité. Le cas typique d'illustration est jQuery. Cette librairie était pratique il y a 15 ans, parce que les navigateurs ne proposaient pas de méthode homogène pour cibler les éléments du DOM. Aujourd'hui, elle est obsolète. Rien de ce qu'elle propose n'est plus difficile en JavaScript pur (on dit aussi vanille).  

Enfin, finissons notre inventaire technologique avec les frameworks JavaScript, tels les généralistes React, Angular ou Vue et les spécialistes Three.js ou D3.js. Ces frameworks permettent de créer de véritables applications dans le navigateur, en chargeant séparément l'interface et les données, et en autorisant des interactions riches sans changer de page. Lorsque nous abordons un projet Web, nous commençons par le placer sur un triangle information / émotion / action. Tout le Web centré sur l'information ne doit pas utiliser de framework JavaScript, c'est de la pollution. Dès que des solutions technologiques spécifiques sont déployées en surcouche pour permettre l'indexation par les moteurs de recherche, c'est le signe que la technologie est employée à tort. Les frameworks applicatifs servent à produire des applications, pas des pages Web. Les frameworks 3D ou de data visualisation servent à produire des jeux et des visualisations de données. Certains projets sont hybrides, à la fois applicatifs, informationnels et expérientiels. Dans ce cas, il peut être souhaitable de traiter les informations en appliquant les principes de qualité proposés ici, et de construire des applications ou des expériences sur la base de ces informations, par exemple en utilisant des versions JSON ou JSON-LD.

Cet inventaire étant achevé, nous pouvons proposer un fléchage des niveaux de qualité en fonction des projets.

Niveau A

Le premier cas d'usage que nous proposons, le moins exigeant, concerne les back-offices et les outils d'administration. Ces outils nécessitent une authentification et ne sont donc pas référencés par les moteurs de recherche.

Passons en revue nos 7 critères : le balisage doit être respectueux du standard HTML, accessible, conforme aux règles Opquast. En revanche, ni l'excellente qualité sémantique ni la sur-optimisation SEO ne sont des impératifs, parce que le site ne sera pas indexé. La sobriété est évidemment nécessaire, mais la structure d'usage est très différente d'un site classique : peu d'utilisateurs vont utiliser l'outil, mais très fréquemment. Cela veut dire que l'utilisation du cache du navigateur est une réponse très efficace, et que l'optimisation des Web Vitals - notamment du First Contentful Paint (FCP) et du Largest Contentful Paint (LCP) - est beaucoup moins cruciale que dans un projet orienté grand public et SEO. Ce premier contexte présente très souvent des enjeux d'évolution du périmètre applicatif et de maintenabilité forts, avec de nombreux devs qui interviennent au fil du temps. Ceci justifie l'utilisation d'un framework CSS, au prix d'une réduction de la pureté de l'HTML. Cela autorise aussi une sélection réduite de librairies JavaScript, dont le poids sera d'autant plus lissé par le cache que le nombre de pages visitées sera élevé.

La pile technologique et les approches que nous déployons dans ce contexte s'appellent niveau A. C'est un niveau facile à développer et à maintenir, tolérant sur la performance et sur le bruit. Découvrir le niveau A en détail

Niveau AA

Le second contexte est très vaste, il concerne tous les sites publics.

Les 6 premiers critères s'appliquent, et le 7e tolère des compromis favorisant la maintenabilité.

La pile technologique et les approches que nous déployons dans ce contexte s'appellent niveau AA, ou Double-A. C'est un niveau optimisé, très performant, mais tolérant sur le bruit HTML. Découvrir le niveau Double-A en détail

Niveau AAA

Le dernier contexte concerne particulièrement les sites très fréquentés et pérennes, qui bénéficieront du gain de poids et d'élégance induits par la pureté du balisage, et qui profitent d'une équipe de devs expérimentée et centrée sur la qualité.

Ce niveau ne tolère aucun compromis de qualité. Tous les sites utilisant le niveau AA pourraient bénéficier du niveau AAA. C'est un choix d'exigence. Découvrir le niveau Triple-A en détail