210 heures de développement facturées sur trois ans pour corriger, encore et encore, la même faille d’accessibilité sur un bouton d’accordéon : voilà le chiffre qui ressort de l’historique de tickets d’un projet de plateforme associative que nous suivons depuis son lancement. Le composant fautif, un accordéon de questions fréquentes sans gestion correcte du focus clavier, avait été corrigé une première fois en trois heures sur la page d’accueil, sans que la correction ne soit jamais reportée sur le composant source réutilisé ailleurs.
Ce cas illustre un mécanisme rarement chiffré explicitement dans les discussions sur l’accessibilité : le coût d’un défaut ne se limite pas au temps de sa correction technique initiale, mais à la multiplication de ce temps par le nombre d’endroits où le même défaut a été copié, dupliqué ou réutilisé sans que personne n’ait fait le lien entre les occurrences.
La chronologie du problème
La première alerte est arrivée par un ticket de support classique : un utilisateur signalait ne plus pouvoir refermer une section de FAQ après l’avoir ouverte au clavier. Le développeur de garde a corrigé le composant sur la page concernée, en ajoutant la gestion manquante de la touche Échap et le retour du focus sur l’en-tête de la section, sans vérifier où d’autres instances du même composant existaient dans le reste du site.
Dix-huit mois plus tard, un audit RGAA commandé pour répondre à une obligation contractuelle avec un partenaire institutionnel a retrouvé exactement le même défaut sur onze pages différentes, toutes construites à partir du même modèle de bloc d’accordéon dupliqué au fil du temps par plusieurs rédacteurs successifs, chacun ayant copié-collé un exemple existant plutôt que de repartir du composant source.
Le calcul du surcoût
La reprise généralisée a nécessité l’identification de toutes les occurrences du motif (via une recherche dans la base de contenu et une revue manuelle des modèles de page), la centralisation du composant dans un unique bloc réutilisable, puis la migration de chaque page concernée vers ce bloc unique. Le tout a représenté environ dix-huit heures de travail, contre trois heures pour le correctif initial isolé — un facteur proche de six, sans compter le temps de coordination avec le client pour valider chaque page migrée une par une.
Ce que révèle ce cas au-delà du chiffre
Le facteur multiplicateur observé sur ce projet précis n’a évidemment aucune valeur statistique généralisable — chaque contexte a sa propre architecture de contenu et son propre niveau de duplication. Ce qui est en revanche généralisable, c’est le mécanisme lui-même : tant qu’une correction d’accessibilité reste appliquée à un exemplaire isolé d’un composant plutôt qu’à sa source, chaque nouvelle page créée à partir de l’ancien modèle réintroduit le même défaut, et le compteur de reprise repart de zéro à chaque nouvel audit.
Ce phénomène est aggravé par un biais organisationnel classique : le rédacteur ou l’intégrateur qui duplique une page existante pour en créer une nouvelle n’a en général aucun moyen de savoir que le modèle qu’il copie contient un défaut connu. La correction reste tacite, mémorisée par une seule personne, jusqu’à ce qu’elle quitte le projet.
Documenter la correction à la source
La leçon opérationnelle qui en découle est simple à énoncer, plus difficile à appliquer systématiquement : toute correction d’accessibilité constatée sur un composant réutilisable doit être répercutée dans le composant source lui-même — le bloc Gutenberg réutilisable, le composant de bibliothèque de motifs, ou à défaut une note explicite dans la documentation interne du projet, plutôt que dans une seule instance publiée.
- Vérifier, avant toute correction, si le composant fautif existe en version « source » réutilisable ou uniquement en copies dispersées.
- Convertir les copies dispersées en instances d’un même composant central dès que le budget le permet, même sans lien direct avec l’anomalie d’origine.
- Consigner la correction dans le changelog interne du design system, avec une référence explicite au ticket d’origine.
Un principe qui a fait ses preuves sur nos projets : ne jamais fermer un ticket d’accessibilité tant que la question « ce composant existe-t-il ailleurs sur le site » n’a pas été posée explicitement.
En résumé
Le coût réel d’un défaut d’accessibilité n’est pas celui de sa première correction, mais celui de sa dispersion silencieuse à travers un site. Traiter la cause à la racine, dans le composant réutilisable plutôt que dans chaque page qui l’utilise, reste la seule façon de sortir de cette spirale de reprises répétées.
