Intégrer une démarche qualité web (VPTCS)

Ce guide décrit comment installer une démarche qualité web dans un projet et la tenir dans la durée — pas comme un audit ponctuel de fin de chantier, mais comme une pratique continue intégrée au flux de développement. Il s'appuie sur l'esprit du référentiel Opquast et son modèle VPTCS (Visibilité, Perception, Technique, Contenus, Services).

Il s'adresse à quelqu'un qui sait déjà livrer un site ou une application web et veut une méthode reproductible pour en garantir la qualité perçue et vérifiée.

Ce guide décrit une méthode. Pour les normes officielles à référencer (WCAG, RGAA, HTML5, sécurité HTTP…), voir reference/standards-et-normes.md.

Avant de commencer

Trois prérequis conceptuels rendent la démarche opérante.

• Une règle qualité doit être vérifiable. Si personne ne peut trancher « c'est conforme / ça ne l'est pas » en quelques secondes, ce n'est pas une règle qualité, c'est une opinion. Formulez chaque exigence de façon binaire.
• La qualité est une propriété du produit livré, pas une intention. Elle se constate sur le rendu final, du point de vue de l'utilisateur — pas dans le code seul.
• La check-list doit être opposable. Elle est partagée, connue à l'avance, et sert de critère commun. On ne la découvre pas à la revue : on livre en la connaissant.

Étape 1 — Adopter le modèle VPTCS comme grille de lecture

VPTCS répartit les bonnes pratiques en cinq familles. L'intérêt n'est pas la liste elle-même mais le fait qu'elle couvre tout le périmètre perçu d'un site, au-delà du seul code. Passez chaque livraison au filtre de ces cinq familles.

Visibilité

Ce qui permet à l'utilisateur — et aux moteurs — de trouver le contenu et de se repérer.

• Chaque page a un titre de document (<title>) unique et descriptif.
• La structure de navigation est cohérente et présente sur toutes les pages.
• Les métadonnées de partage (titre, description, image) sont renseignées.
• L'URL est lisible et stable.

Perception

Ce qui rend le contenu lisible et compréhensible pour tous, quelle que soit la condition de consultation.

• La hiérarchie de titres est logique et sans saut de niveau (H1 → H2 → H3).
• Les contrastes de couleur sont suffisants (recoupe directement l'accessibilité).
• L'information ne repose jamais sur la seule couleur.
• Les contenus restent lisibles au zoom et sur petit écran.

Technique

Ce qui garantit que la page fonctionne, se charge et résiste.

• Le code HTML est valide et bien formé.
• Les liens internes et externes ne sont pas cassés.
• Les pages d'erreur (404, 500) sont gérées et utiles.
• Le site se charge en HTTPS et applique les en-têtes de sécurité attendus.
• La performance de chargement est mesurée, pas supposée.

Contenus

Ce qui touche à la justesse et à la fiabilité de l'information affichée.

• Les informations affichées sont exactes et à jour.
• Les unités, dates, prix et formats sont explicites et cohérents.
• Les contenus multimédias ont leurs alternatives (texte, transcription).
• La langue principale de la page est déclarée.

Services

Ce qui concerne la relation avec l'utilisateur : formulaires, engagements, réassurance.

• Les formulaires indiquent clairement les champs obligatoires et les erreurs.
• Les informations de contact et les mentions légales sont accessibles.
• Le comportement après une action (envoi, paiement, inscription) est confirmé.
• Les conditions d'utilisation d'un service sont énoncées avant l'action.

Étape 2 — Construire une check-list opposable

Transformez la grille VPTCS en une liste de contrôle propre à votre projet.

1. Sélectionnez les bonnes pratiques applicables à votre contexte parmi les cinq familles. Toutes ne s'appliquent pas à tous les projets ; assumez les exclusions explicitement.
2. Reformulez chaque règle en critère binaire. « Le formulaire est accessible » n'est pas contrôlable ; « chaque champ de formulaire a une étiquette associée » l'est.
3. Figez la liste dans le dépôt, versionnée avec le code. Elle évolue par modification tracée, pas par mémoire orale.
4. Rendez-la partagée et connue à l'avance. C'est ce qui la rend opposable : au moment de la revue, la conformité n'est pas une surprise.

Le résultat est une check-list où chaque ligne peut être cochée ou non, sans débat, par n'importe qui dans l'équipe.

Étape 3 — Insérer la qualité dans le flux de développement

Une check-list qui vit à part de la production ne sert à rien. Ancrez-la à trois moments du flux.

Dans la définition de « terminé »

Une tâche n'est pas « terminée » quand le code fonctionne, mais quand elle satisfait les critères qualité applicables. Intégrez les lignes VPTCS pertinentes à votre definition of done : c'est le levier le plus efficace, car il déplace la qualité de la fin du projet vers chaque incrément.

À la revue

La revue de code ou de livraison inclut un passage explicite sur la check-list. L'objectif n'est pas de piéger l'auteur mais de forcer une seconde lecture, avec un regard qui n'a pas l'angle mort de celui qui a produit. Même en solo, s'imposer ce passage recrée cette distance.

En vérification automatisée quand c'est possible

Une partie des critères techniques se contrôle sans humain : validation HTML, détection de liens morts, mesure de performance, vérification des contrastes, présence des en-têtes de sécurité. Automatisez ce qui peut l'être pour réserver l'attention humaine aux critères de contenu et de service, qui exigent du jugement.

Étape 4 — Articuler avec l'accessibilité et le référencement

VPTCS n'est pas une discipline isolée : elle recoupe largement deux exigences souvent traitées séparément.

• Accessibilité. Une grande partie des familles Perception et Technique est commune avec les critères d'accessibilité (contrastes, structure de titres, alternatives textuelles, accès clavier). Traiter la qualité web tire mécaniquement l'accessibilité vers le haut — mais ne la remplace pas : la conformité au référentiel d'accessibilité applicable reste un objectif propre. Voir le catalogue des normes (WCAG, RGAA) dans la reference.
• Référencement (SEO). La famille Visibilité (titres, structure, métadonnées, URL stables) et la famille Technique (HTML valide, performance, absence de liens morts) sont précisément les fondations d'un référencement naturel sain. Une démarche qualité bien tenue produit un socle SEO technique par construction, sans stratégie séparée.

Le message opérationnel : ne pas empiler trois check-lists concurrentes. Construire une check-list qualité VPTCS et y intégrer les critères d'accessibilité et de référencement comme des sous-ensembles.

Étape 5 — Tenir la démarche dans la durée

Une démarche qualité se dégrade si elle n'est pas entretenue.

• Revoyez la check-list périodiquement : retirez ce qui n'a plus de sens, ajoutez ce qu'un incident a révélé manquant.
• Tracez les évolutions de la liste comme n'importe quel changement de code.
• Mesurez plutôt que supposer : contrastes, performance, liens morts se chiffrent. Une règle non mesurée finit ignorée.

Récapitulatif

1. Adopter VPTCS comme grille couvrant tout le périmètre perçu.
2. En dériver une check-list de critères binaires et opposables, versionnée.
3. L'ancrer dans la definition of done, la revue et l'automatisation.
4. La faire recouvrir accessibilité et référencement plutôt que les dupliquer.
5. L'entretenir : mesurer, tracer, réviser.

Voir aussi

• reference/standards-et-normes.md — normes officielles à référencer (WCAG, RGAA, HTML5, sécurité HTTP, etc.).
• explanation/discipline-ingenierie.md — pourquoi la qualité est une propriété du système et non du code seul.