Faire tourner un test d’accessibilité sur un site, ponctuellement, résout un problème ponctuel. Le vrai enjeu pour une agence qui gère quinze ou vingt sites WordPress en parallèle est différent : comment éviter qu’une régression d’accessibilité (un contraste cassé par une mise à jour de thème, un bouton devenu inaccessible après un changement de composant) ne reparte en production sans que personne ne s’en aperçoive avant le client, ou pire, avant une plainte.
La réponse tient dans un pipeline, pas dans un outil. Ce qui suit décrit l’architecture mise en place pour faire tourner des contrôles d’accessibilité automatiquement sur chaque site suivi, à chaque changement de code, avec des seuils différents selon la gravité. Ce n’est pas un remplacement de l’audit manuel avec lecteur d’écran, déjà traité par ailleurs, mais un filet qui attrape 30 à 40 % des problèmes avant qu’un humain n’ait besoin de s’y pencher.
Vue d’ensemble de l’architecture
Le pipeline repose sur trois briques : un déclencheur (intégration continue sur chaque dépôt Git), un moteur de scan (axe-core piloté par Playwright), et un agrégateur qui centralise les résultats de tous les sites clients dans un même tableau de bord. Aucune de ces briques n’est exotique ; la valeur est dans la façon dont elles s’articulent.
agence-a11y-pipeline/
├── runner/
│ ├── scan.js # Playwright + axe-core, une page à la fois
│ ├── urls/
│ │ ├── client-boulangerie.json
│ │ ├── client-cabinet-avocat.json
│ │ └── client-menuiserie.json
│ └── seuils.json # règles par client (WCAG A, AA, AAA partiel)
├── ci/
│ └── .gitlab-ci.yml # déclenche runner/scan.js sur chaque merge request
├── agrégateur/
│ ├── ingestion.php # reçoit les rapports JSON, les stocke en base
│ └── export-csv.php # export pour les revues mensuelles
└── dashboard/
└── (application interne, un statut par client, par page, par critère)Le déclencheur : scanner avant la fusion, pas après le déploiement
Le choix le plus structurant est de placer le scan sur la merge request, avant que le code n’atteigne la production, plutôt qu’en cron nocturne sur le site en ligne. Un scan post-déploiement détecte le problème après coup ; un scan pré-fusion bloque la régression avant qu’elle n’existe pour de vrai. Concrètement, chaque merge request sur un dépôt de thème ou de plugin maison déclenche un job qui monte un environnement de prévisualisation, puis lance runner/scan.js sur un jeu d’URL représentatives (page d’accueil, une fiche produit, un formulaire de contact, une page de blog).
Le moteur de scan : axe-core, mais pas seul
axe-core couvre bien les critères automatisables (contraste, attributs ARIA invalides, labels manquants, structure de titres), mais il ne détecte ni les pièges au clavier, ni la pertinence d’un texte alternatif, ni l’ordre de tabulation logique. Le pipeline complète donc axe-core par des scripts Playwright dédiés qui simulent une navigation au clavier (une série de Tab) et vérifient que le focus reste visible et suit un ordre cohérent. Ces scripts n’attrapent pas tout, mais ils couvrent une part significative des régressions les plus fréquentes en agence : menus qui perdent le focus, modales sans piège de focus, boutons transformés en <div> par une intégration hâtive.
Trois niveaux de sévérité, pas un simple pass/fail
Un pipeline qui bloque toute merge request au moindre écart finit par être contourné. La règle adoptée distingue trois niveaux :
- Bloquant : contraste de texte insuffisant, image sans alternative, champ de formulaire sans étiquette — la merge request est refusée automatiquement.
- Avertissement : structure de titres incohérente, attribut ARIA redondant — la merge request passe, mais un commentaire est ajouté et un ticket est créé.
- Information : points qui nécessitent un jugement humain (pertinence d’un texte alternatif, ordre de lecture) — remontés dans le tableau de bord pour la revue mensuelle, sans bloquer quoi que ce soit.
L’agrégateur : un tableau de bord par client, pas par site
Chaque rapport de scan est envoyé en JSON à un petit service PHP qui l’enregistre en base, avec le client, la page et la date. L’intérêt de centraliser plutôt que de garder les rapports dans les artefacts de la CI est de pouvoir répondre en trente secondes à la question qu’un chef de projet pose systématiquement en réunion client : « où en est-on par rapport au mois dernier ? ». Le tableau de bord affiche, par client, l’évolution du nombre d’erreurs bloquantes sur les douze derniers mois, et permet d’exporter un rapport CSV pour les dossiers de conformité RGAA.
En résumé
Un pipeline de tests d’accessibilité automatisés n’est pas un produit qu’on installe : c’est une architecture qu’on assemble à partir de briques existantes (CI, axe-core, Playwright), organisée autour de deux décisions structurantes — scanner avant la fusion, pas après le déploiement, et distinguer trois niveaux de sévérité plutôt qu’un verdict binaire. Ce filet automatisé ne dispense jamais d’un audit manuel avec lecteur d’écran, mais il réduit fortement le nombre de régressions qui finissent en production sans que personne ne les ait vues venir.
