80 sites sur 82 perdent entre 4 et 9 points de score d’accessibilité automatisé le même mardi matin, d’après le tableau de bord de supervision d’une agence gérant un réseau de sites de collectivités territoriales construits sur un thème commun. Aucune équipe éditoriale n’a publié de contenu ce jour-là sur l’ensemble du parc, ce qui écarte d’emblée une coïncidence de calendrier de publication.
Face à une régression synchronisée sur un grand nombre de sites, le réflexe d’aller corriger site par site est une perte de temps garantie. La bonne première question n’est pas « qu’est-ce qui a changé sur ce site », mais « qu’est-ce que ces 80 sites partagent et que les 2 sites épargnés n’ont pas ».
Diagnostic : remonter à ce qui est commun
Sur ce parc, les 80 sites touchés partageaient trois éléments : le même thème enfant, la même version de PHP 8.3, et une mise à jour automatique du thème parent déployée dans la nuit précédente. Les 2 sites épargnés utilisaient une version antérieure du thème parent, gelée volontairement pour une raison contractuelle sans rapport avec l’accessibilité.
Le journal de mise à jour (changelog) du thème parent mentionnait un changement de balisage du composant d’en-tête, passant d’une structure avec <nav> explicite à une structure générique en <div> pour, selon la note de version, « simplifier la surcharge par les enfants ». C’est ce changement, anodin en apparence, qui expliquait la perte de repère de navigation détectée par l’outil d’audit automatisé.
Isoler la cause avant de toucher à quoi que ce soit
La méthode qui fonctionne dans ce genre de situation :
- Comparer le score d’un site touché avant et après la date de régression, en conservant les captures d’écran d’audit horodatées si l’outil de supervision les propose
- Identifier tous les éléments communs aux sites impactés : thème, version de plugin, version de PHP, date de mise à jour automatique
- Reproduire la régression sur un environnement de test en installant uniquement la version suspectée du thème parent, contenu identique par ailleurs
- Comparer le DOM généré ligne à ligne entre l’ancienne et la nouvelle version pour confirmer le composant en cause
Cette approche évite le piège classique consistant à corriger un symptôme différent sur chaque site parce que l’audit remonte des erreurs de libellés variables selon le contenu, alors que la cause racine est unique et commune.
Le tableau de bord multisite peut masquer la réalité
Un piège rencontré sur ce chantier : le tableau de bord agrégé affichait une moyenne de parc quasi stable, la baisse de quelques sites très fréquentés étant compensée statistiquement par des sites peu visités dont le score n’avait pas bougé. Sans alerte configurée sur une variation individuelle par site, la régression serait passée inaperçue plusieurs semaines, jusqu’au prochain audit manuel programmé.
Depuis, le seuil d’alerte sur ce parc se déclenche dès qu’un site perd plus de 3 points en une exécution, indépendamment de la moyenne globale du réseau.
Corriger la cause, pas chaque site
Une fois la cause confirmée dans le composant d’en-tête du thème parent, le correctif s’est fait à un seul endroit : restauration de l’élément <nav> avec un aria-label distinctif, dans le fichier header.php du thème parent partagé par les 80 sites. Un seul commit, une seule mise à jour du thème, déployée sur l’ensemble du parc via le mécanisme d’auto-update existant.
Corriger directement dans chaque thème enfant aurait fonctionné à court terme, mais aurait recréé une divergence entre sites que la prochaine mise à jour du thème parent aurait de nouveau écrasée, reproduisant la même régression un mois plus tard.
Prévention pour la suite
- Geler les mises à jour automatiques du thème parent sur un environnement de pré-production avant diffusion au parc complet
- Ajouter un contrôle automatisé sur les landmarks structurels (
<nav>,<main>,<footer>) dans la suite de tests avant chaque montée de version du thème - Documenter dans le changelog interne de l’agence chaque changement de balisage jugé « simplification », précisément parce que ces changements-là passent le plus souvent sous le radar
En résumé
Face à une régression sur un grand nombre de sites similaires, cherchez le point commun avant de chercher la différence. La correction la plus efficace se fait presque toujours à la source partagée — un thème parent, un composant mutualisé — plutôt qu’en dupliquant le même correctif sur chaque instance du parc.
