Principes — Le beau code web

À qui s’adresse ce guide

Ce guide a été créé par des enseignants et professionnels du web de la communauté du master Web éditorial et stratégie UX. Il s’adresse aux étudiants et aux professionnels de la communication au moyen de sites web ou, plus généralement, d’applications web.

Objet de ce guide

Ce guide a pour objet la conception technique d’applications web, dans son sens le plus général. Une application web peut ne proposer que de la consultation de contenu, jusqu’à la manipulation de données et de processus spécifiques (applications métier). On entendra donc par applications web, notamment :

les sites web (statiques, dynamiques, CMS, e-commerce, etc.),
les applications fonctionnant sur le web (dashboards, applications métiers, etc.),
les applications web destinées aux mobiles,

dans la mesure où ces applications sont concernées :

par les langages abordés,
par le public visé.

Principes et objectifs

1. Principe de service de l’utilisateur

Une application web est d’abord au service de ses utilisateurs, de ses lecteurs. On s’attachera donc à l’expérience utilisateur également dans la façon de coder.

2. Objectif de sécurité

Découle du principe de service : quand plusieurs façons de coder sont possibles, il faut s’efforcer de privilégier la plus sûre.

3. Objectif de performance

Découle du principe de service : quand plusieurs façons de coder sont possibles, il faut s’efforcer de privilégier l’efficience, en temps d’exécution ou de chargement ou en ressources consommées.

4. Principe de maintenabilité

Les applications web ont vocation à durer dans le temps. Il convient donc de prévoir que leurs professionnels y reviennent régulièrement. La maintenabilité est le fait de pouvoir comprendre un code aisément, s’y repérer, y modifier ce qu’il est nécessaire de modifier, pas plus.

Ce principe de maintenabilité et les objectifs qui en découlent, ci-après, s’appliquent autant au code qu’à la documentation associée, interne ou externe.

5. Objectif de respect des standards

Découle du principe de maintenabilité : on ne devrait pas avoir à revenir sur un document quand il n’y a pas besoin de modifier son contenu. Le respect des standards permet une plus grande durabilité du code.

Ce principe facilite aussi la collaboration entre plusieurs acteurs, simultanément ou au cours de la durée de vie d’un code.

Parmi les standards reconnus, on s’attachera en particulier à respecter l’esprit des Principes de conception du HTML [HTMLDP], notamment : la compatibilité, l’utilité, dont la priorité au terrain, la modularité (separation of concerns), l’interopérabilité et l’accès universel. La priorité au terrain impose, notamment, de s’attacher autant que possible aux usages déjà répandus, quand ils ne sont pas contraires aux grands principes retenus ici.

6. Objectif de lisibilité

Découle du principe de maintenabilité : le code doit minimiser la charge cognitive de sa lecture. En particulier, il convient d’être régulier, d’éviter les formulations ambiguës ou techniquement ou conceptuellement complexes quand elles ne sont pas nécessaires.

7. Objectif de cohérence

Découle de l’objectif de lisibilité : la cohérence est le fait d’appliquer des choix de façon homogène au sein d’un projet ou d’un collectif de travail. Elle permet ainsi d’alléger la charge cognitive pour lire, créer ou modifier un code.

8. Objectif d’accessibilité

Découle des principes de service et de maintenabilité : quand plusieurs façons de coder sont possibles, il faut s’efforcer de privilégier les plus accessibles.

L’accessibilité numérique consiste à rendre les services de communication au public en ligne accessibles aux personnes handicapées, c'est-à-dire : perceptibles […] ; utilisables […] ; compréhensibles […] et robustes : par exemple, optimiser la compatibilité avec les utilisations actuelles et futures, y compris avec les technologies d’assistance. [RGAA]

Les méthodes d’accessibilité permettent également à certains outils, comme les moteurs de recherche, d’être plus efficaces. Outre la maintenabilité en général, l’accessibilité peut améliorer la cohérence en formalisant la structuration de la documentation et de certaines fonctionnalités.

Glossaire

Typographie

alphanumérique: Un caractère alphanumérique est un chiffre ou lettre latine, minuscule ou majuscule, sans accent ni diacritique. Certains langages ajoutent également le souligné (_).
casse: La casse est la différence entre minuscules et majuscules.; Du temps des presses mécaniques, la casse était le casier dans lequel on rangeait les caractères. Ainsi bas de casse, en anglais lower case, est synonyme de minuscule et haut de casse, en anglais upper case, de majuscule. [Wikipedia]
kebab-case: Mots écrits en minuscules, joints par des tirets.; Le terme kebab désigne de la viande rôtie, en particulier à la broche. Dans le -kebab-case⊸, les mots sont comme embrochés.
camelCase: Mots collés entre eux, les initiales en majuscules sauf la première, les autres lettres en minuscules.; Le langage de programmation Camel a popularisé cette notation. On dit parfois que les bosses sont au milieu comme pour un chameau. En anglais, le mot camel désigne aussi bien un chameau 🐫 qu’un dromadaire 🐪.
PascalCase
StudlyCase: Mots collés entre eux, les initiales en majuscules, les autres lettres en minuscules.; Le langage de programmation Pascal a popularisé cette notation. Le terme PascalCase est univoque. Le terme StudlyCase, parfois employé, peut, lui, désigner d’autres écritures.

Autres termes techniques

version: Versionnement sémantique [SemVer] :
Premier nombre, majeur : changements non-rétrocompatibles.
Second nombre, mineur : ajouts rétrocompatibles aux règles.
Troisième nombre, correctif : corrections rétrocompatibles d’anomalies.; Pour être plus précis, un changement de numéro majeur correspond à un renforcement d’une règle (ajout de doit ou devrait). Un changement de mineur correspond à un relâchement d’une règle, à l’ajout d’un peut, ou à l’ajout de clarifications ou d’exemples. Un changement du numéro de correctif correspond à une correction d’orthographe, de grammaire ou de style ou à un changement de mise en forme ou d’organisation des contenus.; Les versions en cours de rédaction peuvent avoir également un numéro de prélivraison : A.B.C-alpha.N, de même que celles en cours de discussion : A.B.C-beta.N, A.B.C-pre.N. La version peut être suivi d’une métadonnée d’étape sur le dépôt.

Modalités aux termes de la [RFC2119]

doit
devra
obligatoire: Ce(s) terme(s) désigne(nt) une exigence absolue de ce guide [RFC2119, §1].
ne doit pas
ne devra pas: Ce(s) terme(s) désigne(nt) une interdiction absolue de ce guide [RFC2119, §2].
devrait
recommandé: Ce(s) terme(s) signifie(nt) qu’il peut exister des raisons valables dans des circonstances particulières pour ignorer un élément précis, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir une voie différente [RFC2119, §3].
ne devrait pas
non recommandé: Ce(s) terme(s) signifie(nt) qu’il peut exister des raisons valides dans des circonstances particulières quand le comportement spécifique est acceptable ou même utile, mais les répercussions complètent devraient être comprise et le cas soigneusement évalué avant d’implémenter [ceci] [RFC2119, §4].
peut
facultatif: Ce(s) terme(s) signifie(nt) que ce choix est vraiment facultatif [RFC2119, §5].; Un fabricant peut choisir d’inclure l’élément parce que un secteur particulier du marché le réclame ou parce que le fabricant pense que cela améliore le produit tandis qu’un autre fabricant peut omettre le même élément. Une mise en œuvre qui n’inclut pas une option particulière doit pouvoir interopérer avec une autre mise en œuvre qui n’inclut pas l’option, peut-être au prix de fonctionnalités réduites. Dans la même veine, une mise en œuvre qui n’inclut pas une option particulière doit être préparée à interopérer avec une autre mise en œuvre qui n’inclut pas l’option (excepté, bien sûr, pour la caractéristique fournie par l’option).

Références

[HTMLDP] van Kesteren, Anne (éd.), Stachowiak, Maciej (éd.). (26 nov. 2007). HTML Design Principles. W3C. W3C working draft.
[RFC2119] Bradner, Scott. (1997). Key words for use in RFCs to Indicate Requirement Levels. IETF. RFC 2119 / BCP 14.
[RGAA] Direction interministérielle du numérique. (2020). Référentiel général d’amélioration de l’accessibilité, RGAA 4.1. gouvernement français.
[SemVer] Preston-Werner, Tom. Gestion sémantique de version 2.0.0.
[TechSEO] Martin, Alexandra, Chartier, Mathieu. (2021). Techniques de référencement web, Audit et suivi SEO. Eyrolles. 4^e édition.

Mentions légales

Le beau code web est distribué sous licence libre GNU GPL, version 3.

Le beau code web ne conserve pas de données personnelles, ne dépose pas de cookies et ne comporte pas de publicité ni de contenu sponsorisé, mais son hébergeur peut avoir recours à l’un de ces moyens.

Le beau code web est hébergé par Github à partir du dépôt Git github.com/YannisDelmas/beau-code-web. Il s’agit d’une œuvre collective dont les contributeurs sont listés sur ce dépôt. Le directeur de la publication est Yannis Delmas. Il peut être contacté via les coordonnées indiquées sur son site personnel.

Le thème utilisé emploie comme image de fond « Rice Paper » de Alte Mo. Certains exemples peuvent utiliser des images publiées par le site LoremPixel.com.