L'accessibilité comme contrainte d'architecture
L'obligation européenne d'accessibilité vise des services entiers et non des pages isolées. Les six décisions d'architecture qui déterminent si la conformité est atteignable, ce qu'elles coûtent prises tôt, et ce qu'elles coûtent en rattrapage.
Par Elias Varen9 min de lectureMembres
L'audit revient avec cent quarante constats. En les triant, un motif apparaît : quatre-vingt-dix d'entre eux ont cinq causes. La liste déroulante maison, utilisée dans soixante écrans. La couleur d'accent que chaque client choisit librement et qui, chez un tiers d'entre eux, rend les boutons illisibles. Le module de paiement embarqué dans un cadre, sur lequel vous n'avez aucune prise. Les images du catalogue, stockées sans champ pour un texte alternatif. Les factures PDF, générées sans structure.
Aucune de ces cinq causes n'est un bug. Ce sont des décisions d'architecture, prises un jour où l'accessibilité n'était pas sur la table, et chacune se corrige maintenant par une migration plutôt que par un correctif.
L'accessibilité se traite donc comme la sécurité ou le multi-tenant, comme une propriété qui se décide dans la structure et qui coûte un ordre de grandeur de plus à ajouter après.
Ce que la directive européenne étend au privé
Pendant longtemps, en Europe, l'obligation d'accessibilité numérique a surtout pesé sur le secteur public. La directive européenne sur l'accessibilité des produits et services, applicable depuis juin 2025, l'étend à des services privés destinés aux consommateurs : le commerce en ligne, les services bancaires, les transports, les communications électroniques, les livres numériques, entre autres. Le référentiel technique est la norme européenne harmonisée EN 301 549, qui s'appuie pour le web sur les critères WCAG de niveau AA.
Pour un architecte, la première conséquence tient au périmètre, qui est le service entier. Vendre en ligne, c'est la page produit, le tunnel de commande, le paiement, les mails de confirmation, la facture, l'espace client et le support. Un tunnel conforme qui débouche sur un paiement inutilisable au clavier ne rend pas le service accessible.
L'obligation remonte aussi la chaîne. Si vous éditez une plateforme sur laquelle vos clients vendent à des consommateurs, ce sont eux qui sont exposés, et ils vous le répercuteront par contrat. L'accessibilité devient une exigence d'appel d'offres, avec une déclaration à produire.
À lire ensuite
Toute la rubrique WebWeb
Server-driven UI : dix ans de leçons du mobile
Faire décrire l'écran par le serveur contourne le cycle de publication mobile, au prix d'un catalogue de composants qui devient une API versionnée et d'un debug à trois dimensions. Où ça paie, comment ça dérive, et le critère pour s'arrêter.
7 minMembres
Web
État serveur, état client : arrêter de les mélanger
La règle pour décider où vit chaque donnée d'un front React, les bugs que produit leur mélange dans un store global, et un chemin de migration tranche par tranche.
6 minMembres
Web
Micro-front-ends : autopsie
Ce que les micro-front-ends achètent vraiment, ce qu'ils facturent en bundle, en expérience et en exploitation, et le critère pour savoir si votre organisation a le problème qu'ils résolvent.
7 minMembres