npm run lint:a11y -- --max-warnings=0 : cette seule ligne, ajoutée à l’étape de build d’un pipeline GitLab CI, a changé la façon dont une équipe de six développeurs aborde l’accessibilité sur un projet de blocs Gutenberg personnalisés pour un réseau de médiathèques. Avant cette ligne, les règles d’accessibilité existaient dans un document de bonnes pratiques que personne ne consultait plus après la phase de cadrage. Après, toute pull request qui introduit une violation connue est automatiquement bloquée, sans intervention humaine.
Cette bascule d’un contrôle documentaire à un contrôle automatisé et bloquant change la dynamique d’équipe de façon plus profonde qu’il n’y paraît : le développeur n’a plus à se souvenir d’une règle, il la découvre au moment précis où il l’enfreint, avec un message d’erreur qui pointe la ligne de code fautive.
Où positionner la passerelle dans le pipeline
L’architecture retenue place le lint d’accessibilité statique (via eslint-plugin-jsx-a11y pour le JavaScript des blocs, et un lint PHP maison pour les gabarits de template) immédiatement après l’étape de build et avant tout déploiement, y compris vers un environnement de recette. Cette position est déterminante : placer le contrôle trop tard dans le pipeline, par exemple uniquement avant la production, laisse passer des violations en recette qui seront ensuite testées et validées visuellement, créant une fausse impression de conformité qu’il faudra défaire.
Le pipeline suit cette séquence : installation des dépendances, build des assets, lint d’accessibilité statique, tests unitaires, puis déploiement conditionnel à la réussite de toutes les étapes précédentes. Si le lint échoue, le pipeline s’arrête immédiatement et aucune étape suivante ne s’exécute, y compris les tests qui pourraient sembler indépendants.
Choisir un socle de règles restreint mais fiable
L’erreur la plus fréquente lors de la mise en place d’un tel gate consiste à activer d’emblée l’intégralité des règles disponibles dans un plugin de lint, au risque de produire un pipeline qui échoue en permanence sur des règles trop strictes ou mal adaptées au contexte du projet, ce qui pousse rapidement l’équipe à désactiver le gate entier par lassitude.
Le socle retenu sur ce projet
Sur ce projet de médiathèques, seules six règles ont été activées en mode bloquant après une phase de test de deux semaines en mode avertissement seul :
jsx-a11y/alt-text: impose un texte alternatif sur les éléments image.jsx-a11y/anchor-is-valid: détecte les liens sans destination réelle.jsx-a11y/no-autofocus: interdit l’autofocus automatique, source fréquente de perte de repère.jsx-a11y/heading-has-content: empêche les titres vides générés dynamiquement.
Les règles jugées plus sujettes à faux positifs dans le contexte spécifique des blocs dynamiques Gutenberg (comme certaines règles sur les rôles ARIA redondants) sont restées en mode avertissement seul, visibles dans le rapport de build mais non bloquantes, en attendant d’accumuler suffisamment de retours pour les faire évoluer sereinement vers le mode bloquant.
Traiter les faux positifs comme des bugs du pipeline
Un principe organisationnel s’est révélé décisif : tout faux positif signalé par un développeur est traité comme un bug du pipeline lui-même, avec un ticket dédié et une correction de la configuration de lint, jamais comme une exception ponctuelle ajoutée en commentaire dans le code (// eslint-disable-next-line). Cette discipline évite l’accumulation silencieuse de dérogations qui, avec le temps, videraient le gate de sa substance.
Ce que cette architecture ne couvre pas
Un lint statique détecte des motifs syntaxiques connus à l’avance, mais ne remplace jamais un test d’exécution réel avec un lecteur d’écran, ni un audit manuel de l’ordre de tabulation. Sur ce projet, une étape complémentaire de tests automatisés avec axe-core exécutés sur les pages de recette via Playwright vient compléter le lint statique, à un niveau différent du pipeline, après le déploiement en environnement de test.
Un conseil qui a fait ses preuves dans cette équipe : commencer par un gate volontairement restreint et documenté, quitte à l’élargir progressivement, plutôt que d’imposer d’un coup l’intégralité des règles disponibles au risque de décourager l’adhésion collective.
En résumé
Un pipeline qui bloque un déploiement sur une violation d’accessibilité déplace le contrôle du terrain de la bonne volonté individuelle vers celui de l’automatisation vérifiable. La réussite d’une telle passerelle dépend moins du nombre de règles activées que de la discipline avec laquelle l’équipe traite chaque faux positif comme une amélioration du pipeline, et non comme une exception à contourner.
