Le client a contacté l’agence un lundi matin, inquiet : son tableau de suivi d’accessibilité, alimenté par un audit automatisé mensuel, affichait une chute de dix points par rapport au mois précédent. Aucune modification n’avait pourtant été demandée à l’équipe de développement durant cette période. L’enquête a rapidement pointé vers un mécanisme activé depuis WordPress 5.5 : les mises à jour automatiques de plugins.
Ce billet retrace le diagnostic complet de cette régression, la correction appliquée, et surtout la procédure mise en place pour ne plus être pris au dépourvu par une future mise à jour silencieuse.
Symptôme
Le score de l’audit automatisé mensuel avait chuté du jour au lendemain, un motif de non-conformité pointant spécifiquement vers le plugin de formulaire utilisé sur le site, sans qu’aucune intervention humaine n’ait eu lieu sur cette période.
Diagnostic
Le journal des mises à jour automatiques, consultable depuis l’écran Mises à jour de l’administration WordPress, confirmait qu’une nouvelle version mineure du plugin de formulaire s’était installée automatiquement trois jours plus tôt. En comparant le changelog du plugin, la cause est apparue : l’éditeur avait modifié la façon dont les messages d’erreur de validation sont injectés dans le DOM, passant d’un affichage statique déjà présent au chargement à une injection dynamique via JavaScript, sans conserver l’association aria-describedby entre le champ et son message d’erreur.
Ce changement, présenté dans le changelog comme une simple « amélioration de la fluidité du formulaire », n’avait fait l’objet d’aucune communication spécifique sur son impact en matière d’accessibilité — un cas fréquent, les éditeurs de plugins ne testant pas systématiquement ce type de régression avant publication.
Correctif
Deux options ont été évaluées : revenir à la version précédente du plugin en désactivant ses mises à jour automatiques, ou corriger le comportement via un filtre exposé par le plugin lui-même. La documentation du plugin exposait un filtre permettant de personnaliser le gabarit des messages d’erreur, ce qui a permis de restaurer l’association manquante sans geler le plugin sur une version obsolète :
add_filter( 'plugin_formulaire_gabarit_erreur_champ', function ( $gabarit, $id_champ ) {
return str_replace(
'<span class="erreur-message"',
'<span class="erreur-message" id="erreur-' . esc_attr( $id_champ ) . '" aria-describedby="' . esc_attr( $id_champ ) . '"',
$gabarit
);
}, 10, 2 );
Ce correctif restaure le lien entre le champ et son message d’erreur sans désactiver les mises à jour automatiques, ce qui aurait exposé le site à des failles de sécurité non corrigées sur les versions suivantes du même plugin.
Prévention
La vraie leçon de cet incident ne porte pas sur ce plugin en particulier, mais sur l’absence de filet de sécurité entre une mise à jour automatique et sa vérification. Trois mesures ont été mises en place :
- Un audit automatisé exécuté immédiatement après chaque mise à jour de plugin détectée, plutôt qu’une fois par mois seulement
- Une alerte envoyée à l’équipe dès qu’un écart de score significatif apparaît entre deux exécutions consécutives
- Une revue systématique du changelog des plugins critiques (formulaires, navigation, panier) avant que la mise à jour automatique ne s’applique, via un canal de test préalable
Encadrer sans désactiver
Désactiver purement et simplement les mises à jour automatiques n’a pas été retenu comme solution : cela expose à des vulnérabilités de sécurité non corrigées, un risque plus grave à long terme qu’une régression d’accessibilité ponctuelle. La bonne réponse consiste à détecter rapidement, pas à empêcher la mise à jour d’avoir lieu.
Une mise à jour automatique qui ne casse rien visuellement n’est pas forcément une mise à jour sans conséquence. Le score RGAA doit faire partie des indicateurs surveillés au même titre que la disponibilité du site.
En résumé
Une régression RGAA après une mise à jour automatique de plugin n’est pas un cas isolé : c’est un risque structurel de tout site qui accepte les mises à jour automatiques, ce qui reste par ailleurs recommandé pour la sécurité. La réponse ne consiste pas à couper ce mécanisme, mais à le surveiller avec un audit déclenché systématiquement après chaque mise à jour détectée, plutôt qu’un contrôle mensuel qui laisse dix jours de régression passer inaperçue.
