Vérifications de qualité

Cette page couvre la mécanique : quel outil prouve quel palier, comment l’exécuter et ce qu’il faut pour en ajouter un. La règle de gouvernance — cinq paliers de vérification, la vérification la plus économique en premier, des vérifications plus solides là où une affirmation publique en dépend — vit dans Modèle de qualité et n’est pas répétée ici.

Les vérifications à la source, Hugo, de sortie générée, d’exécution et dans un navigateur sont câblées aujourd’hui. Des audits planifiés élargissent la couverture des liens, de la performance et de l’accessibilité manuelle sans ralentir chaque commit.

Vérifications à la source — installées#

Toutes s’exécutent par npm run lint et sont assez rapides pour l’édition courante.

lint:interfaces exige une preuve observable dans chaque traduction d’un composant implémenté : un component-preview encadré, un exemple rendu directement ou un mode interface_preview pris en charge (page, render-hook ou consumer). Un aperçu consumer doit nommer une page interface_preview_page et y pointer avec component-relationship. Chaque traduction d’un composant spécifié doit porter un bloc implementation-status avec critères d’acceptation. La documentation d’un shortcode utilise live par défaut et doit appeler ce shortcode dans les deux traductions. Un enregistrement qui utilise documentation_mode: dependent doit déclarer un seul champ preview_parent ou preview_page, y pointer avec component-relationship et mener vers une page qui appelle le shortcode. Un enregistrement nonvisual doit documenter Résultat et Contraintes dans les deux langues.

Vérifications Hugo — installées#

lint:build:main et lint:build:brand exécutent hugo --renderToMemory pour chaque site — une vérification rapide et ciblée que les gabarits, les points de montage de contenu, les cibles relref et les relations entre pages se résolvent encore sans écrire de sortie générée sur disque. La dernière barrière de npm run lint va plus loin avec lint:rendered, qui effectue de nouvelles compilations sur disque pour les deux sites et vérifie le HTML obtenu.

Vérifications de sortie générée — installées#

Ces vérifications confirment ce qu’une personne visiteuse ou un robot reçoit réellement. Elles effectuent donc de nouvelles compilations avant d’inspecter la sortie.

Vérification du HTML rendu#

lint:rendered exécute scripts/check-rendered-output.mjs pour les sites principal et de marque. La vérification échoue en présence d’identifiants d’élément en double, de références aria-labelledby non résolues ou de liens vers des fragments internes dont la page de destination existe, mais pas l’identifiant ciblé. Le script fait partie de npm run lint et du flux de validation; les barrières locale et d’intégration continue exercent donc le même contrat de sortie rendue.

Vérifications planifiées de sortie générée — installées#

Lychee#

Lychee vérifie les deux arborescences de sites générées après une compilation complète. Il étend l’audit des fragments rendus aux pages manquantes, aux mauvais alias, aux chemins localisés morts et aux liens externes défaillants. Exécutez npm run build && npm run lint:links localement après avoir installé Lychee avec brew install lychee; ce passage rapide hors ligne valide les liens internes avec la bonne racine pour chaque site. Exécutez npm run audit:links pour le passage réseau. Le flux hebdomadaire Intégrité des liens exécute les deux paliers, met en cache les résultats externes réussis pendant sept jours et accepte les réponses limitées par débit ou volontairement interdites sans les considérer comme du contenu manquant.

Le passage interne comporte quatre exemptions de frontière explicites : le répertoire de ressources Pagefind n’a pas d’index HTML; /api/contact existe seulement dans le Worker; /publications/ est servi depuis R2; le changelog et l’introduction des pages slash mènent volontairement à des brouillons non publiés ou à des routes d’exécution planifiées. Ces exclusions sont des motifs étroits d’entrées ou d’URL, pas des exceptions de codes d’état pour les pages internes ordinaires.

Lighthouse#

@lhci/cli audite des pages représentatives en anglais et en français des deux sites. Le flux hebdomadaire Audit Lighthouse exige des notes minimales de 95 pour l’accessibilité, de 90 pour les pratiques exemplaires et de 90 pour le référencement; une performance inférieure à 80 produit un avertissement au lieu de faire échouer l’audit. Exécutez npm run build && npm run audit:lighthouse localement. Les rapports sont écrits dans reports/lighthouse et conservés comme artefact du flux pendant 30 jours.

Vérifications d’exécution — installées#

npm run test:worker exécute Vitest avec @cloudflare/vitest-plugin dans l’environnement d’exécution Workers de Cloudflare. La suite simule la liaison ASSETS et les requêtes réseau sortantes, recueille le travail différé avec waitUntil() et protège ces contrats :

• routage selon l’hôte et redirections
• en-têtes de sécurité sur les redirections et les réponses de ressources
• envoi d’analytique sans chaîne de requête complète ni URL complète du référent
• troncature de l’adresse IP avant que l’analytique quitte le Worker
• limitation de débit du formulaire de contact, comportement ouvert en cas d’échec et assainissement des en-têtes
• rejet des redirections hors site après l’envoi

Les sites déployés se trouvent derrière Cloudflare Access pendant leur développement, mais aucune route du Worker ne lit les revendications Access ni n’en dépend. La suite vérifie donc que le routage normal des ressources ne change pas lorsqu’un en-tête Access non vérifié est présent. Des données de test JWT deviennent obligatoires si une route prend plus tard une décision d’autorisation à partir de revendications Access; en ajouter maintenant codifierait un comportement inexistant.

Vérifications dans un navigateur — installées#

npm run test:browser démarre les deux sites Hugo et exécute Playwright contre leurs pages rendues. Le flux de validation installe Chromium et exécute la suite pour chaque envoi et chaque demande de tirage.

Les tests d’interaction couvrent les libellés anglais et français de l’aperçu de thème, l’activation native avec Entrée et Espace, les changements de thème délimités, la fermeture de la navigation mobile avec Échap et le retour du focus, le piège et le retour du focus de la boîte de dialogue de recherche, puis les onglets de contenu pilotés par les touches fléchées.

La même suite utilise @axe-core/playwright pour analyser des pages représentatives en anglais et en français des deux sites selon les règles WCAG 2.0 et 2.1 A et AA. Elle détecte des échecs repérables comme les noms accessibles manquants, l’ARIA invalide, les problèmes de points de repère et certains défauts de contraste. Une analyse axe réussie constitue une preuve, pas un remplacement du passage manuel ci-dessous.

Passages manuels — un processus, pas un outil#

Les outils automatisés détectent ce qui est structurellement incorrect; ils ne détectent pas si le résultat a réellement du sens pour une personne qui utilise un clavier ou un lecteur d’écran.

• Passage au clavier seul : sans souris, parcourez une page avec Tab. Chaque élément interactif devrait être atteignable, dans l’ordre visuel, avec un indicateur de focus visible, et rien ne devrait piéger le focus en dehors d’une véritable fenêtre modale.
• Vérification rapide au lecteur d’écran : macOS inclut VoiceOver — aucune installation, Cmd + F5 le démarre. Naviguez par titre et par point de repère et confirmez que les libellés se lisent comme prévu, pas seulement qu’ils existent.

Effectuez les deux après tout changement au comportement clavier ou à la structure ARIA d’un composant, pas seulement avant une publication. Le flux mensuel Passage manuel d’accessibilité ouvre un enjeu de suivi avec la liste de vérification au clavier et avec VoiceOver. Il n’ouvre pas de doublon tant que la liste précédente demeure active.

Ordre de vérification locale#

Utilisez d’abord la vérification pertinente la plus économique, puis élargissez la preuve avant la livraison :

1. npm run lint
2. npm run test:worker
3. npm run test:browser
4. npm run build, puis inspection de chaque région modifiée en anglais et en français
5. npm run lint:links lorsque les destinations de liens changent
6. npm run audit:lighthouse lorsque la mise en page, les ressources, les métadonnées ou le comportement de chargement changent

Les flux planifiés répètent les vérifications plus larges même lorsqu’une modification ne les déclenche pas directement. L’implémentation demeure ainsi alignée sur le Modèle de qualité sans faire payer le coût complet des audits à chaque modification locale.