Quatre pour cent : c’est le surcoût moyen mesuré sur trois projets de sites vitrines suivis en détail, en comparant le temps réellement passé sur les tâches liées à l’accessibilité au temps total de développement. Ce chiffre contredit directement une idée répandue dans les comités de pilotage, celle d’un budget d’accessibilité qui alourdirait mécaniquement n’importe quel projet de développement web.
Ce billet démonte cette idée reçue avec des chiffres tirés de projets réels, sans entrer dans les audits de mise en conformité, qui relèvent d’une démarche et d’un budget distincts, souvent postérieurs à la livraison initiale du site.
D’où vient l’idée reçue
L’idée d’un surcoût systématique repose souvent sur une confusion entre trois catégories de dépenses bien différentes : le temps de conception d’un composant accessible dès le départ, le coût d’un audit externe mené par un prestataire spécialisé, et le coût d’une correction tardive sur un site déjà en production. Ces trois postes n’ont ni la même ampleur, ni la même récurrence, et les additionner sous une seule ligne budgétaire fausse la perception du coût réel.
Ce que montrent les chiffres de trois projets
Sur les trois projets suivis, le temps de développement total variait entre 180 et 340 heures. Le temps directement attribuable à des choix d’accessibilité — structuration correcte des titres, attributs ARIA sur des composants interactifs, vérification des contrastes, tests clavier — représentait entre 3 et 6 % du total, avec une moyenne à 4 %. Ce temps se répartissait ainsi :
| Poste | Part du surcoût mesuré |
|---|---|
| Structuration des titres et des régions de la page | environ 10 % |
| Attributs ARIA sur les composants interactifs sur mesure | environ 35 % |
| Vérification et ajustement des contrastes de couleur | environ 20 % |
| Tests manuels au clavier avant livraison | environ 25 % |
| Autres ajustements ponctuels | environ 10 % |
Le poste le plus lourd, les attributs ARIA sur les composants sur mesure, se concentre presque entièrement sur deux ou trois composants complexes par projet — un menu à onglets, un carrousel, un configurateur — et non sur l’ensemble du site. La grande majorité des pages, construites à partir de composants simples correctement structurés dès le départ, n’ajoutent aucun surcoût mesurable.
Ce qui n’est pas un surcoût, mais une bonne pratique déjà attendue
Une part importante des tâches classées « accessibilité » dans les grilles de devis relève en réalité de pratiques de développement qui devraient s’appliquer de toute façon : nommer correctement un lien plutôt que d’écrire « cliquez ici », structurer les titres dans un ordre logique, associer un label à chaque champ de formulaire. Ces tâches ne coûtent rien de plus qu’une version mal faite du même composant ; elles demandent simplement de le faire correctement une seule fois, ce qui est vrai de n’importe quelle exigence de qualité, pas seulement de l’accessibilité.
Où se cache le vrai surcoût
Le surcoût réel n’apparaît pas à la conception initiale, mais au rattrapage. Sur un quatrième projet, non inclus dans la moyenne précédente car mené dans des conditions différentes, un composant de filtre à facettes développé sans considération d’accessibilité avait dû être repris intégralement six mois après la mise en ligne, une fois le problème signalé par un client. Ce correctif isolé a coûté, à lui seul, près de deux fois le surcoût cumulé mesuré sur l’ensemble des trois autres projets réunis.
Conseil maison : chiffrer le coût d’un correctif tardif sur un projet précédent, même approximativement, convainc souvent plus qu’un long discours sur le principe de l’accessibilité elle-même.
Ce que cela change en pratique
Pour une équipe qui chiffre un nouveau projet, la conclusion pratique est simple : plutôt que de provisionner une ligne budgétaire globale et anxiogène pour « l’accessibilité », mieux vaut identifier en amont les deux ou trois composants réellement complexes du projet, chiffrer leur surcoût de conception spécifiquement, et considérer le reste comme une pratique de développement standard, sans ligne budgétaire séparée. Cette décomposition évite à la fois de sous-estimer le travail sur les composants complexes et de gonfler artificiellement un budget global sur des tâches qui n’auraient de toute façon rien coûté de plus si elles avaient été bien faites dès le départ.
En résumé
L’idée d’un surcoût mécanique et uniforme ne résiste pas à un examen chiffré poste par poste : sur trois projets suivis, le surcoût réel s’est limité à 4 % en moyenne, concentré sur une poignée de composants complexes, tandis que le reste relevait de pratiques qui n’auraient rien coûté de plus à bien faire dès le départ. Le vrai risque budgétaire ne se situe pas dans la conception initiale, mais dans le rattrapage tardif d’un composant mal pensé dès l’origine.
