# Bloquer un déploiement WordPress sous un score d’accessibilité Lighthouse

> Un score d'accessibilité qui chute de 96 à 71 en production sans que personne ne le remarque : voici comment poser un seuil bloquant dans le pipeline de déploiement.

- Auteur : WordPress Développement
- Publié le : 2022-05-27
- Mis à jour le : 2022-05-27
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/lighthouse-ci-budget-accessibilite-pipeline/

## L’essentiel

- Lighthouse CI peut bloquer un merge sous un score d'accessibilité défini
- Le budget doit rester réaliste pour ne pas être contourné en douce
- L'audit automatisé complète l'audit manuel, il ne le remplace jamais

`npx @lhci/cli autorun` : cette seule commande, une fois posée dans une étape de CI, aurait évité trois régressions d'accessibilité passées inaperçues sur un projet e-commerce l'an dernier — un bouton de filtre produit devenu injoignable au clavier, un contraste de texte tombé sous le seuil AA après un changement de charte, et un formulaire de newsletter dont le label avait disparu lors d'une réorganisation de blocs Gutenberg.

Aucune de ces régressions n'avait été volontaire. Chacune est passée par la revue de code sans que personne ne pense à ouvrir les outils de développement pour vérifier l'accessibilité d'un changement qui, sur le papier, ne concernait que du CSS ou de la mise en page. Poser un budget Lighthouse CI bloquant dans le pipeline change la donne : la régression est détectée avant la mise en production, pas après un signalement d'utilisateur.

## Étape 1 : installer et configurer Lighthouse CI

Lighthouse CI (`@lhci/cli`) s'installe comme dépendance de développement dans le projet, ou via un exécutable autonome dans l'environnement d'intégration continue. Un fichier de configuration `lighthouserc.json` à la racine du projet définit les URL à auditer, le nombre de passages par URL (pour lisser la variance des mesures) et les seuils par catégorie.

```
{
  "ci": {
    "collect": {
      "url": [
        "https://staging.exemple.fr/",
        "https://staging.exemple.fr/boutique/",
        "https://staging.exemple.fr/contact/"
      ],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", { "minScore": 0.9 }]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}
```

## Étape 2 : choisir un seuil réaliste, pas symbolique

> L'essentiel à retenir : Lighthouse CI peut bloquer un merge sous un score d'accessibilité défini ; Le budget doit rester réaliste pour ne pas être contourné en douce ; L'audit automatisé complète l'audit manuel, il ne le remplace jamais

Un seuil fixé à 100 semble rassurant sur le papier, mais il devient vite un obstacle que l'équipe contourne en désactivant la vérification « juste cette fois ». L'expérience sur plusieurs projets WordPress montre qu'un seuil à 0.90 (soit un score Lighthouse de 90 sur 100) constitue un bon compromis : suffisamment strict pour attraper les régressions franches (contraste, labels manquants, rôles ARIA incohérents), suffisamment réaliste pour ne pas bloquer sur des faux positifs mineurs liés à des widgets tiers.

Le seuil doit être documenté avec sa justification dans le dépôt du projet, pour éviter qu'un développeur pressé ne le relève à 0.5 lors d'un futur passage en urgence sans en informer le reste de l'équipe.

## Étape 3 : intégrer l'étape au pipeline

Dans une pipeline GitHub Actions, l'étape Lighthouse CI s'ajoute après le déploiement sur un environnement de préproduction accessible publiquement, condition indispensable puisque Lighthouse audite une URL réelle et non le code source.

```
- name: Audit accessibilité Lighthouse CI
  run: |
    npm install -g @lhci/cli
    lhci autorun --config=./lighthouserc.json
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
```

Si le score d'accessibilité descend sous le seuil défini, l'étape échoue et le merge est bloqué par la protection de branche configurée sur le dépôt. Les développeurs reçoivent un rapport détaillé indiquant les critères en cause, avec des liens vers la documentation de chaque règle Lighthouse concernée.

## Ce que ce budget ne détecte jamais

Un score Lighthouse à 100 ne garantit strictement rien sur l'expérience réelle d'un utilisateur de lecteur d'écran. L'outil vérifie des critères automatisables : présence d'attributs, structure du DOM, contraste calculé mathématiquement. Il ne teste ni la cohérence de l'ordre de lecture, ni la pertinence des textes alternatifs, ni le comportement réel d'un piège au clavier sur une fenêtre modale, ni l'expérience de navigation complète avec un lecteur d'écran.

- Ordre de tabulation logique sur un composant complexe
- Pertinence sémantique des textes alternatifs d'image
- Annonces vocales correctes des changements dynamiques de contenu
- Cohérence globale du parcours utilisateur, au-delà d'une seule page

Le budget Lighthouse CI reste donc un filet de sécurité contre les régressions grossières, complémentaire à un audit manuel périodique réalisé par une personne formée, jamais un substitut.

## En résumé

Un budget d'accessibilité Lighthouse CI bloquant, fixé à un seuil réaliste autour de 90, permet d'attraper la majorité des régressions techniques avant leur mise en production, sans remplacer l'audit manuel qui reste indispensable pour valider l'expérience réelle des utilisateurs en situation de handicap. La combinaison des deux approches, automatisée et humaine, forme le socle d'une démarche d'accessibilité qui tient dans la durée.