Par où commencer quand un audit RGAA rend un rapport de 2 000 lignes d’anomalies sur un intranet interne, avec une équipe de deux développeurs et un budget de correction limité à quelques sprints par trimestre ? Traiter les anomalies dans l’ordre du rapport, généralement classé par page puis par critère RGAA, revient à corriger au hasard : certaines lignes bloquent totalement un agent malvoyant dans son travail quotidien, d’autres relèvent d’un détail cosmétique sans impact réel.
Cette checklist ne traite pas la correction technique elle-même, déjà largement documentée ailleurs, mais la méthode de tri qui permet de transformer un rapport brut en plan d’action réaliste, aligné sur le temps de développement réellement disponible.
Étape 1 : distinguer blocage total et gêne partielle
Une anomalie qui empêche complètement un utilisateur d’accomplir une tâche (un bouton de validation de formulaire inatteignable au clavier, un champ obligatoire sans étiquette associée) n’a rien à voir avec une anomalie qui dégrade le confort sans empêcher l’action (un contraste légèrement sous le seuil sur un texte secondaire). Classez chaque anomalie en trois niveaux : bloquant, gênant, cosmétique. Sur cet intranet, ce premier tri a réduit à 180 le nombre d’anomalies réellement bloquantes parmi les 2 000 remontées.
Étape 2 : regrouper par gabarit plutôt que par page
Un intranet expose rarement des pages uniques : la grande majorité des anomalies se répètent à l’identique sur des dizaines de pages générées par le même gabarit (fiche collaborateur, formulaire de demande de congés, tableau de suivi de projet). Regrouper les 2 000 anomalies par gabarit d’origine plutôt que par URL individuelle révèle souvent qu’une correction unique dans un composant partagé résout des centaines de lignes du rapport en une seule intervention.
- Identifiez le gabarit ou le composant source de chaque anomalie récurrente.
- Comptez le nombre de pages impactées par gabarit, pas le nombre de lignes du rapport.
- Corrigez en priorité les gabarits à fort volume de pages, même pour une anomalie jugée mineure.
Étape 3 : pondérer par fréquence d’usage réelle
Toutes les pages d’un intranet ne sont pas consultées au même rythme. Une anomalie sur la page d’accueil, visitée par chaque agent chaque jour, pèse davantage qu’une anomalie sur un formulaire archivé consulté trois fois par an. Croisez les statistiques de fréquentation internes (si elles existent) avec la liste des gabarits impactés pour affiner l’ordre de traitement.
Étape 4 : isoler les critères à faible coût de correction
Certaines anomalies bloquantes coûtent cher à corriger (restructuration complète d’un tableau de données complexe), d’autres coûtent une ligne de code (ajout d’un attribut for manquant sur une étiquette de formulaire). Une matrice impact/effort, même approximative, permet de traiter en premier les corrections à fort impact et faible coût, qui produisent le meilleur rendement visible dès le premier sprint.
Étape 5 : documenter les exceptions temporaires
Certaines anomalies bloquantes touchent des composants tiers non maintenus en interne (un widget de reporting fourni par un éditeur externe). Documentez ces cas comme dérogations temporaires dans la déclaration d’accessibilité, avec un plan de remédiation daté, plutôt que de les laisser sans statut dans le backlog.
Checklist de priorisation à appliquer
- Classer chaque anomalie en bloquant, gênant ou cosmétique.
- Regrouper les anomalies par gabarit ou composant source.
- Croiser avec la fréquentation réelle des pages concernées.
- Estimer le coût de correction de chaque groupe.
- Traiter en priorité les groupes à fort impact et faible coût.
- Documenter en dérogation les anomalies liées à des composants tiers non maîtrisés.
Ce qui a changé sur ce projet
Après application de cette méthode, 60 % des 180 anomalies bloquantes identifiées ont été traitées en deux sprints, simplement parce qu’elles se concentraient sur six gabarits partagés par l’ensemble de l’intranet. Le reste du backlog, moins critique, a été planifié sur les trimestres suivants avec une visibilité claire pour la direction, qui pour la première fois disposait d’un plan chiffré plutôt que d’un rapport brut de 2 000 lignes.
