Le rapport d’audit vient d’atterrir dans la boîte mail du client : quatre-vingts anomalies, classées par critère RGAA, dans l’ordre où l’auditeur les a testées. Le client au budget limité regarde ce document et voit une montagne infranchissable. Le rôle de l’agence, à ce moment précis, n’est pas de défendre l’audit mais de le transformer en plan d’action réaliste.
Ce billet décrit la méthode qu’on applique pour prioriser ce type de backlog, sans se limiter à trier par gravité RGAA — un classement qui, seul, ne dit rien de l’effort de correction ni de l’impact réel sur les utilisateurs.
Le problème du tri par gravité seule
Le rapport d’audit classe généralement les anomalies en bloquant, important et mineur. C’est un point de départ, mais insuffisant : une anomalie bloquante sur une page consultée dix fois par an pèse moins, en pratique, qu’une anomalie importante sur le formulaire de contact utilisé quotidiennement.
Croiser gravité et fréquence d’usage
La première étape consiste à croiser chaque anomalie avec les statistiques de fréquentation des pages concernées, extraites de l’outil d’analyse du client. Une matrice à deux axes — gravité RGAA en ordonnée, fréquence de la page en abscisse — fait immédiatement remonter les vrais points chauds : le menu principal, le formulaire de contact, le tunnel de prise de rendez-vous.
Regrouper par composant, pas par page
Une anomalie de contraste insuffisant sur les boutons peut apparaître sur quinze pages différentes dans le rapport d’audit, mais elle ne représente qu’un seul correctif si les boutons proviennent d’un composant partagé du thème. Regrouper les anomalies par origine technique — composant de thème, plugin, contenu éditorial — évite de faire gonfler artificiellement l’estimation de charge.
Un gabarit de scoring simple
Voici le gabarit utilisé pour noter chaque anomalie avant de la classer :
{
"anomalie": "Contraste insuffisant sur les boutons secondaires",
"gravite_rgaa": "importante",
"frequence_page": "haute",
"effort_estime_h": 2,
"composant": "theme/boutons",
"score_priorite": 8
}
Le score de priorité résulte d’un calcul simple : gravité et fréquence pondérées à la hausse, effort de correction pondéré à la baisse. Les anomalies à fort impact et faible effort remontent naturellement en tête de liste.
Définir un socle minimal viable
Face à un budget contraint, il faut savoir proposer un socle minimal : les correctifs qui lèvent les blocages d’usage réels (impossibilité de valider un formulaire, menu inatteignable au clavier) avant les correctifs de confort (contraste d’un texte secondaire peu consulté). Ce socle doit être chiffré et présenté comme un lot autonome, livrable en un sprint.
Étaler le reste sur plusieurs sprints
Le reste du backlog se répartit ensuite sur plusieurs sprints, avec un objectif de réduction mesurable à chaque itération plutôt qu’une promesse de conformité totale d’un coup. Cette approche rassure un client qui craint un chantier sans fin.
Variante : le backlog partagé avec le client
Certains clients préfèrent garder la main sur l’arbitrage final. Dans ce cas, le gabarit de scoring est partagé dans un tableur, avec les colonnes déjà remplies par l’agence, et une colonne de validation laissée au client. Cela responsabilise sans transformer chaque anomalie en débat technique.
Un backlog d’accessibilité qui reste dans un fichier PDF ne sera jamais traité. Il doit vivre dans le même outil de suivi que les autres tickets du projet, avec la même exigence de suivi.
En résumé
Prioriser un backlog d’accessibilité pour un budget limité ne consiste pas à choisir quelles règles ignorer, mais à séquencer intelligemment leur correction. Croiser gravité et fréquence d’usage, regrouper par composant, définir un socle minimal viable : cette méthode transforme un rapport d’audit anxiogène en plan d’action concret, sprint après sprint.
