L'accessibilité d'une application métier n'est pas une question d'audience

On présente presque toujours l’accessibilité numérique comme un enjeu de site public : toucher plus de visiteurs, élargir l’audience, respecter une norme. Pour une application métier, ce cadre ne tient pas — parce que ses utilisateurs n’ont pas le choix. Sur un site, un visiteur qui bute sur un obstacle s’en va ; dans une application métier, celui qui bute ne s’en va pas, il est empêché de travailler. La question n’est donc pas combien de personnes on touche, mais si l’on exclut celles qui dépendent de l’outil. Et derrière cette question, deux risques bien concrets pour le dirigeant : un risque opérationnel et un risque juridique.

L’utilisateur d’une application métier ne peut pas partir

Le discours courant sur l’accessibilité est bâti sur la logique du site public. Un site est une option parmi d’autres : si la navigation est confuse, si la page met trop de temps, si elle est inutilisable sur tel appareil, le visiteur part — chez un concurrent, ou simplement ailleurs. Dans cette logique, l’accessibilité sert à élargir l’entonnoir : la soigner, c’est perdre moins de visiteurs. Tout le vocabulaire — taux de rebond, conversion, audience — découle de cette idée que l’utilisateur peut s’en aller.

Une application métier inverse cette logique. Un employé qui saisit ses dossiers, un adhérent qui dépose une demande, un professionnel qui consulte un planning ne choisissent pas l’outil : c’est celui qu’on leur impose pour faire le travail. S’ils butent sur un obstacle, ils ne partent pas chez un concurrent — ils restent, bloqués. L’obstacle ne coûte pas un visiteur ; il empêche quelqu’un d’accomplir sa tâche.

La question change donc de nature. Elle n’est plus « combien de personnes touchons-nous de plus ? », mais « excluons-nous des gens qui n’ont aucune sortie ? ». L’accessibilité cesse d’être un levier d’audience pour devenir une affaire d’inclusion par nécessité : faire en sorte que celles et ceux qui doivent utiliser l’outil le puissent réellement.

Qui exclut-on, concrètement

L’image spontanée de l’accessibilité se réduit souvent à une petite minorité de personnes en situation de handicap permanent. La réalité couvre une population bien plus large.

Il y a d’abord les différences durables : une vision basse ou une perception altérée des couleurs, une dextérité réduite qui rend la souris difficile à manier, des troubles cognitifs comme la dyslexie, ou une mémoire de travail vite saturée par une interface surchargée. Il y a l’âge : une base d’utilisateurs professionnels est souvent plus âgée que l’audience d’un site grand public, avec ce que cela suppose de presbytie et d’interactions plus lentes. Et il y a les limitations temporaires ou liées au contexte, qui touchent tout le monde un jour ou l’autre : une main plâtrée, un écran en plein soleil, un open space bruyant, un poste vieillissant, une mauvaise connexion sur le terrain.

Le point décisif, pour une application métier, est qu’on ne choisit pas ses utilisateurs. Dans une base captive de professionnels, toute la variabilité humaine est présente — et obligée de se servir de l’outil. L’accessibilité n’est alors rien d’autre que ce qui rend l’application utilisable par les gens réels qui doivent l’utiliser, et non par une minorité abstraite que l’on pourrait négliger.

Les deux risques que porte le dirigeant

Le premier risque est opérationnel, et il est immédiat. Une application inaccessible produit de la friction à l’intérieur de l’organisation : des personnes qui ne parviennent pas à terminer une tâche seules, des contournements, une dépendance à l’aide d’un collègue, des erreurs, un travail ralenti — parfois une fonction qu’on finit par déserter. Le coût n’est pas un visiteur perdu dans la nature ; c’est une perte de productivité interne, récurrente, et souvent invisible dans les indicateurs.

Le second est juridique, et il monte. Le devoir d’aménagement de l’employeur envers ses salariés en situation de handicap s’applique aux outils de travail internes. Et au-delà, le cadre réglementaire s’est élargi : la directive européenne sur l’accessibilité, applicable depuis juin 2025, étend pour la première fois des obligations d’accessibilité au secteur privé, pour les services et produits numériques destinés au public — sites, applications, services bancaires, e-commerce. Selon que votre application sert vos employés ou un public d’usagers et de clients, ce ne sont pas les mêmes textes qui s’appliquent ; déterminer lesquels, et ce qu’ils impliquent, relève précisément du travail d’un bureau d’études. Une certitude est commune à tous ces cadres : un correctif de surface n’y répond pas. Les surcouches d’accessibilité que l’on greffe sur une application existante ne valent pas conformité — elles traitent l’apparence, pas les obstacles présents dans le code et la conception.

L’accessibilité est une décision de conception, pas un correctif

Cela conduit au vrai sujet : l’accessibilité se décide à la conception. Une structure de page sémantique, une navigation entièrement possible au clavier, des contrastes suffisants, des libellés explicites — ce sont des choix que l’on pose en concevant, et qui ne coûtent presque rien à ce moment-là. Rattrapée après coup sur une application qui ne les a pas prévus, l’accessibilité devient chère et partielle : on colmate, on ajoute une surcouche, et l’on n’obtient qu’une conformité de façade qui laisse les vrais obstacles dans le code.

En prime — mais c’est un bénéfice, pas la raison —, ces mêmes choix rendent l’outil meilleur pour tout le monde. Une structure claire, une navigation logique et des libellés sans ambiguïté servent l’utilisateur pressé, celui qui découvre l’application, celui qui travaille sur un petit écran. Et une application bien structurée est plus simple à maintenir et à faire évoluer. La rigueur qui rend accessible est la même qui rend robuste.

Concevoir pour ceux qui n’ont pas le choix

Pour une application métier, l’accessibilité n’est donc ni une question d’audience, ni un geste de charité, ni un label à afficher. C’est une question simple et exigeante : les personnes qui doivent utiliser l’outil le peuvent-elles vraiment ? Un visiteur que l’on n’a pas su retenir s’en va, et l’on n’en saura rien ; un utilisateur captif que l’on a exclu reste, empêché, et son empêchement se paie — en productivité, en risque, en dépendance.

Le rôle du dirigeant est d’en faire une exigence de départ, au même titre que la sécurité ou la performance, et non un audit que l’on repousse. Le rôle du bureau d’études est de la concevoir dès l’origine, là où elle est peu coûteuse et pleinement efficace. La bonne question n’a jamais été de savoir combien de personnes on touche. Elle a toujours été de savoir si l’on a laissé quelqu’un dehors.