Un score d’accessibilité qui redescend sous 90 sur 100 entre deux versions d’un thème WordPress ne devrait jamais atteindre la production sans qu’un humain en soit informé : c’est le principe qui a guidé la mise en place d’un pipeline GitLab CI chez une agence qui gère une dizaine de sites clients sous un thème commun, mutualisé entre plusieurs marques.
Avant cette mise en place, les régressions d’accessibilité n’étaient détectées qu’au moment d’un audit manuel périodique, parfois plusieurs semaines après leur introduction, ce qui rendait leur origine difficile à retrouver parmi les nombreux commits accumulés entre deux audits.
Vue d’ensemble du pipeline
Le pipeline se déclenche à chaque ouverture de merge request et se structure en quatre étapes successives, chacune bloquant la suivante en cas d’échec.
build
└── deploy_staging
└── audit_accessibilite
└── deploy_production (manuel, si audit OK)
L’étape build compile les assets du thème, deploy_staging pousse le résultat vers un environnement éphémère dédié à la merge request, audit_accessibilite exécute l’outil Pa11y en ligne de commande contre plusieurs gabarits de cet environnement, et deploy_production reste déclenchable manuellement uniquement si l’étape précédente a réussi.
La configuration de l’étape d’audit
L’étape s’appuie sur Pa11y CI, configuré pour parcourir une liste de pages représentatives (accueil, fiche produit, page de contact) et calculer un score global à partir du nombre d’anomalies détectées, pondéré par leur gravité.
audit_accessibilite:
stage: test
script:
- npx pa11y-ci --config .pa11yci.json --reporter json > rapport.json
- node ./scripts/calculer-score.js rapport.json
artifacts:
paths:
- rapport.json
reports:
junit: rapport-junit.xml
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
Le script calculer-score.js, écrit spécifiquement pour ce projet, traduit le rapport JSON de Pa11y en un score sur cent, avec un poids plus lourd pour les erreurs de niveau critique (contraste insuffisant, absence de texte alternatif) que pour les avertissements mineurs.
Le seuil de blocage et sa justification
Le seuil de 90 sur 100 n’a pas été choisi arbitrairement : il correspond au score mesuré sur le thème existant au moment de la mise en place du pipeline, moins une marge de tolérance de cinq points pour absorber les faux positifs occasionnels de l’outil automatisé sans bloquer inutilement les déploiements.
- Un score supérieur ou égal à 90 laisse l’étape
deploy_productiondisponible en déclenchement manuel. - Un score inférieur fait échouer l’étape
audit_accessibilite, ce qui empêche l’apparition même du bouton de déploiement en production dans l’interface GitLab. - Le seuil est révisé trimestriellement, à la hausse uniquement, à mesure que les corrections s’accumulent sur le thème commun.
Le rapport en commentaire de merge request
Une étape complémentaire poste automatiquement un résumé du rapport en commentaire de la merge request, via l’API GitLab, avec le score obtenu, la liste des trois anomalies les plus critiques et un lien vers le rapport complet en pièce jointe du pipeline.
curl --request POST \
--header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
--data-urlencode "body=Score accessibilité : 87/100 (seuil 90). Voir rapport joint." \
"https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"
Ce commentaire donne au développeur une information immédiate, sans avoir à ouvrir les journaux détaillés du pipeline pour comprendre pourquoi son déploiement est bloqué.
Ce que ce pipeline ne remplace pas
L’audit automatisé ne détecte qu’une partie des critères d’accessibilité : la navigation au clavier réelle, la pertinence des textes alternatifs ou la cohérence de la hiérarchie de titres selon le contexte éditorial restent hors de portée d’un outil comme Pa11y. Le pipeline complète un audit manuel périodique, il ne s’y substitue pas.
Un score automatisé qui bloque un déploiement rend visible une régression le jour même où elle est introduite, ce qu’un audit manuel trimestriel ne peut jamais garantir.
En résumé
Un seuil de 90 sur 100, calculé à partir du score initial du thème, bloque désormais tout déploiement en production dès qu’une régression d’accessibilité mesurable apparaît dans une merge request. Le rapport publié en commentaire donne une visibilité immédiate au développeur, sans dispenser l’équipe d’un audit manuel périodique pour les critères que l’automatisation ne couvre pas, comme la navigation au clavier ou la pertinence contextuelle des textes alternatifs.
