500 instances actives sur un même réseau WordPress multisite : impossible de programmer 500 audits manuels sans mobiliser une équipe entière pendant des mois. Pour une agence responsable de la conformité de ce parc auprès d’un client public, la seule voie réaliste est une architecture de collecte automatisée capable de produire un score d’accessibilité par instance, actualisé régulièrement, sans intervention humaine à chaque cycle.
Ce type d’architecture ne remplace pas l’audit manuel approfondi, réservé aux sites à fort trafic ou à risque juridique élevé. Elle sert de radar : détecter les régressions, prioriser les interventions, et produire un reporting consolidé exploitable par une direction qui ne lira jamais un rapport RGAA de 80 pages par site.
Principe général de la collecte
L’architecture repose sur trois briques : un annuaire des instances (récupéré via wp site list en WP-CLI sur l’installation multisite), une file de traitement qui déclenche un audit automatisé par instance à intervalle régulier, et un entrepôt de résultats consultable via un tableau de bord centralisé. Chaque cycle d’audit tourne indépendamment des autres, pour qu’une instance en erreur ne bloque pas le traitement du reste du réseau.
Récupération de la liste des sites
wp site list --network --field=url --format=csv > sites-a-auditer.csv
Cette commande WP-CLI, exécutée sur l’installation multisite, produit la liste brute des URL à intégrer dans la file de traitement. Chaque URL devient une tâche indépendante, associée à un identifiant d’instance stable pour permettre le suivi de l’évolution du score dans le temps.
La file de traitement par instance
Un outil comme axe-core en ligne de commande (via Puppeteer ou Playwright) explore un échantillon de pages représentatives par site : page d’accueil, une page de contenu type, une page de contact si elle existe. Le résultat brut, un JSON listant les violations par règle et par gravité, est transformé en un score synthétique pondéré, calculé selon une formule simple : nombre de critiques × 3, plus nombre de sérieux × 2, plus nombre de modérés, rapporté au nombre de pages testées.
score_instance = 100 - min(100,
(violations_critiques * 3 + violations_serieuses * 2 + violations_moderees)
/ nb_pages_testees
)
Structure de l’entrepôt de résultats
audits/
instance-042/
2025-01-06/
score.json
accueil.json
contact.json
2025-01-13/
...
instance-043/
...
Cette arborescence horodatée permet de tracer l’évolution du score d’une instance dans le temps, indispensable pour distinguer une régression ponctuelle (liée à une modification de contenu) d’une dégradation structurelle (liée à une mise à jour de thème réseau).
- Chaque instance conserve son historique de score sur douze mois glissants.
- Une alerte se déclenche automatiquement quand un score chute de plus de 10 points d’un cycle à l’autre.
- Le tableau de bord agrégé classe les instances par score croissant pour prioriser les interventions.
Limites à assumer clairement
Cette architecture ne détecte ni les pièges au clavier, ni les problèmes de compréhension de contenu, ni la cohérence des parcours utilisateurs complexes : elle reste un outil de détection automatisée, avec les mêmes limites que n’importe quel scanner basé sur des règles. Le score obtenu ne se substitue jamais à une déclaration d’accessibilité RGAA, qui exige un audit conduit selon la méthodologie officielle sur un échantillon de pages défini.
Bilan de ce chantier
Sur ce réseau de 500 instances, la mise en place de cette architecture a permis d’identifier en un seul cycle une trentaine de sites présentant une régression commune, liée à la mise à jour d’un plugin de mégamenu partagé par l’ensemble du réseau. Sans cette collecte automatisée, cette régression serait restée invisible pendant des mois, noyée dans le volume du parc. L’automatisation ne remplace pas l’audit humain, mais elle rend visible ce qui, à cette échelle, serait autrement resté hors de portée.
