Être conforme au RGAA ne suffit pas. On l'a appris en regardant quelqu'un utiliser son téléphone écran éteint.

BINOMES est souvent présenté comme un “cas d’école” en accessibilité. Tu confirmes ?

Oui, mais pas pour les raisons qu’on croit. On présente souvent le projet comme exemplaire parce qu’on a atteint 100% de conformité RGAA. C’est rare, moins de 10% des sites en France atteignent ce niveau. Mais ce qui fait de BINOMES un cas intéressant, c’est qu’on a compris très tôt que la conformité n’était pas le sujet. Une plateforme conforme n’est pas nécessairement accessible. Et sur ce projet, si on s’était arrêtés à la conformité légale, on aurait livré quelque chose d’inutilisable pour une grande partie des utilisateurs.

La différence entre les deux, c’est quoi concrètement ?

Le RGAA liste 106 critères. 60% sont testables automatiquement. Les 40% restants demandent du contexte, un regard humain, une mise en situation réelle. Aucun outil ne peut décider à ta place si une alternative textuelle est pertinente pour un contenu donné. Et surtout, le référentiel ne te dit rien sur la façon dont les gens utilisent vraiment leurs outils numériques.

Pendant les tests utilisateurs, un des déficients visuels nous a demandé si on voulait qu’il allume son écran avant qu’on le filme. Il ne l’utilisait jamais. Son écran était éteint en permanence. Ça, aucun outil de vérification automatique ne l’anticipe. Et si on ne fait pas de tests avec des utilisateurs réels, on n’en sait rien.

Tu parles de tests utilisateurs comme si c’était exceptionnel. Ça ne se fait pas systématiquement ?

Rarement. Et c’est exactement le problème. La plupart des équipes qui travaillent sur l’accessibilité n’ont jamais observé une personne déficiente visuelle utiliser un téléphone. Moi-même, avec 14 ans d’expérience sur ces sujets, je n’avais jamais fait de tests utilisateurs sur mobile avec des DV avant ce projet. Ce que j’ai appris en quelques sessions dépasse ce que j’avais accumulé en années de mise en conformité.

Donne-moi un exemple précis de ce que ça a changé.

La connexion à l’application utilise un OTP, un code à six chiffres envoyé par email. L’email contenait aussi un lien de connexion directe, plus simple, mais placé après le code. Aucun utilisateur n’a trouvé ce lien. Ni les déficients visuels, ni les valides qui participaient aux tests. Personne ne lit un email en entier quand l’application lui dit d’aller chercher un code. Déplacer le lien avant le code a changé l’expérience. L’email était conforme avant cette modification. L’application est devenue accessible après.

Il y a eu d’autres moments où une hypothèse de départ a été remise en question ?

Le système de messagerie interne. On avait prévu un module complet pour que les utilisateurs puissent s’écrire directement dans l’application. C’était complexe à développer, mais on pensait que c’était nécessaire. Les DV nous ont dit qu’ils préféraient qu’on leur laisse la main : une mise en relation avec échange de contacts, et ils utilisent leurs propres outils ensuite. Ils voulaient moins de fonctionnalités, pas plus. La simplicité et l’autonomie. Ce sont les deux choses qui sont ressorties le plus fort de tous les tests.

On entend souvent que design et accessibilité sont incompatibles. BINOMES vient de recevoir un prix de design international.

Ce préjugé est tenace et faux. Il vient du fait que la plupart des gens qui font de l’accessibilité n’ont jamais vu une application accessible qui soit aussi bien designée. Ce prix, c’est le résultat d’une équipe pluridisciplinaire où tous les corps de métier ont pris l’accessibilité en compte, pas seulement les développeurs en bout de chaîne. On peut faire beau, utile et accessible. La contrainte, quand elle est intégrée dès la conception, devient une discipline de design.

Justement, quelle erreur faut-il absolument éviter quand on démarre un projet accessible ?

Penser qu’on pourra faire l’accessibilité plus tard. C’est l’erreur la plus commune et la plus coûteuse. Revenir sur des composants déjà construits pour “forcer” l’accessibilité, ça coûte beaucoup plus cher que de bien faire dès le départ. Et ça livre souvent moins bien. Sur BINOMES, on a fait les tests et les modifications avec les déficients visuels avant la mise en conformité au RGAA. Dans l’ordre inverse de ce que font la plupart des projets. L’accessibilité n’est pas non plus un “one-shot” : une mise à jour peut casser ce qui fonctionnait. C’est une démarche continue, pas une case à cocher.

Pourquoi les entreprises ne font pas ce travail alors ?

Parce qu’il n’y a pas de raison structurelle de le faire. Pas de KPI qui prouve qu’investir dans l’accessibilité réelle a un impact tangible sur le business. Pas de données solides sur le retour sur investissement. L’accessibilité reste avant tout une démarche éthique dans un monde qui arbitre sur le ROI. Et le seul vrai levier aujourd’hui, c’est le cadre légal. Mais on manque encore de contrôles et de sanctions réelles. La directive européenne de juin 2025 élargit le champ d’application et mandate de nouveaux organismes de contrôle par secteur. C’est un progrès. Mais le temps que les sanctions arrivent vraiment, il se passera encore quelques années.

Un mot pour les ingénieurs et développeurs qui lisent ça et qui n’ont jamais fait d’accessibilité ?

Commencez par éteindre votre écran. Prenez votre téléphone, ouvrez l’application sur laquelle vous travaillez, et essayez de naviguer avec le lecteur vocal activé. Cinq minutes suffisent pour comprendre ce que des années de documentation ne transmettent pas. L’accessibilité n’est pas une contrainte qui s’ajoute à la fin. C’est une façon de construire. Et une fois qu’on a vu comment les gens utilisent vraiment ce qu’on construit, on ne peut plus faire semblant de ne pas savoir.