TerrainScénario type
Banque en ligne accessible : les corrections prioritaires
Le rapport d'audit compte plusieurs centaines de non-conformités et ne dit pas par où commencer. Le scénario d'une banque qui trie par parcours plutôt que par critère, et corrige d'abord ce qui empêche un client de payer.
Le rapport d’audit arrive un vendredi : plusieurs centaines de non-conformités sur l’espace client web et l’application mobile, classées critère par critère, de 1.1.1 à 4.1.3. La directrice du numérique de cette banque de détail le lit pendant le week-end et pose, le lundi, la seule question qui compte : par quoi commence-t-on ? Ce scénario type raconte comment l’équipe a transformé une liste de défauts en un plan de corrections, et pourquoi l’accessibilité d’une banque en ligne se trie par parcours plutôt que par critère.
Un rapport juste, mais inutilisable tel quel
L’audit est sérieux. Il a été mené selon les règles pour l’accessibilité des contenus web (WCAG), sur un échantillon de pages représentatif, avec des tests au clavier et au lecteur d’écran. Son classement par critère convient à une mesure de conformité ; il ne dit pas ce qui empêche concrètement un client d’utiliser sa banque. Un défaut de contraste sur une page de mentions légales et un bouton de validation de virement inatteignable au clavier y figurent avec le même poids.
Le contexte presse. Depuis le 28 juin 2025, l’European Accessibility Act s’applique aux services bancaires destinés aux consommateurs. Les équipes de développement, elles, ont une feuille de route déjà chargée. Il faut donc un ordre, défendable devant la direction et compréhensible par les équipes.
Trier par parcours, pas par critère
L’équipe, composée de la responsable accessibilité, de deux développeurs, d’un concepteur d’interfaces et d’une auditrice extérieure, commence par lister les parcours sans lesquels la banque en ligne ne sert à rien. Elle en retient sept : se connecter ; consulter ses comptes et ses opérations ; faire un virement ; ajouter un bénéficiaire ; faire opposition sur une carte ; télécharger un relevé ; contacter la banque.
Chaque non-conformité est ensuite rattachée aux parcours qu’elle touche, et qualifiée selon un seul critère d’impact : est-ce qu’elle bloque un utilisateur (il ne peut pas finir le parcours sans aide), est-ce qu’elle le gêne (il y parvient au prix d’un effort important), ou est-ce qu’elle reste mineure ? Le tri fait apparaître une vérité rassurante : les blocages sur les parcours essentiels ne représentent qu’une petite partie de la liste, et beaucoup proviennent de quelques composants réutilisés partout.
Un champ de formulaire mal étiqueté, s’il appartient à la bibliothèque de composants, se retrouve sur des dizaines d’écrans. Le corriger une fois règle d’un coup des dizaines de non-conformités. L’équipe a donc identifié, pour chaque défaut bloquant, s’il venait d’un composant partagé ou d’un écran particulier.
Le premier lot de corrections
Le premier lot, programmé sur deux cycles de développement, se concentre sur les blocages des parcours essentiels.
| Problème | Parcours touchés | Critère WCAG | Pourquoi d’abord |
|---|---|---|---|
| Code à usage unique expirant trop vite, sans possibilité de prolonger | Connexion, virement | 2.2.1 Réglage du délai | Bloque les clients qui saisissent lentement |
| Collage interdit dans le champ du mot de passe | Connexion | 3.3.8 Authentification accessible | Empêche l’usage d’un gestionnaire de mots de passe |
| Clavier virtuel à positions aléatoires, non vocalisé | Connexion | 2.1.1 Clavier, 4.1.2 Nom, rôle et valeur | Bloque les utilisateurs de lecteur d’écran |
| Bouton de validation du virement inatteignable au clavier | Virement, bénéficiaire | 2.1.1 Clavier | Bloque toute personne qui n’utilise pas la souris |
| Erreurs de saisie signalées par la seule couleur rouge | Virement, bénéficiaire, opposition | 1.4.1 Couleur, 3.3.1 Identification des erreurs | Empêche de comprendre pourquoi le formulaire est refusé |
| Focus masqué par le bandeau fixe en bas d’écran | Tous | 2.4.11 Focus non masqué | Fait perdre la position aux utilisateurs du clavier |
| Relevés en PDF non balisés | Relevés | 1.3.1 Information et relations | Rend illisible le document de référence du client |
Deux de ces corrections relèvent de critères introduits par la version 2.2 des WCAG, publiée en octobre 2023 : l’authentification accessible et le focus non masqué. La norme européenne EN 301 549, dans sa version en vigueur, se réfère encore à la version 2.1 ; l’équipe choisit néanmoins de viser la 2.2 pour les parcours de connexion, où ces critères répondent à des difficultés que les clients signalent déjà au service client.
Ce qui a résisté
Le clavier virtuel à positions aléatoires a fait l’objet du débat le plus long. L’équipe sécurité y voyait une protection contre l’enregistrement des frappes ; l’auditrice a montré qu’il bloquait les utilisateurs de lecteur d’écran et gênait fortement les personnes ayant des troubles moteurs ou cognitifs. La décision a été de le retirer, au profit d’un champ standard compatible avec les gestionnaires de mots de passe, en s’appuyant sur l’authentification forte déjà exigée pour les opérations sensibles. Les deux équipes ont signé ensemble la note de décision.
L’application mobile a posé une autre difficulté : l’écran de validation des opérations provenait d’un composant fourni par un prestataire, que l’équipe ne pouvait pas modifier elle-même. La correction a été demandée au prestataire, avec une échéance contractuelle, et un contournement documenté a été mis en place en attendant.
Les relevés de compte, enfin, étaient produits par un système ancien. Leur balisage complet a été inscrit dans le projet de remplacement de ce système ; dans l’intervalle, la banque propose sur demande un relevé dans un format alternatif, et l’indique dans sa déclaration d’accessibilité.
Vérifier avec des clients
Avant de clore le lot, l’équipe organise des séances de test avec des clients volontaires : une personne aveugle utilisant un lecteur d’écran sur téléphone, une personne naviguant au clavier, une personne âgée utilisant un fort agrandissement, une personne ayant des troubles de l’attention. Chaque séance porte sur les sept parcours. Les tests confirment la plupart des corrections et révèlent deux problèmes que l’audit n’avait pas vus, dont un message de confirmation de virement qui disparaissait avant d’avoir été lu par le lecteur d’écran.
Ce que le scénario enseigne
Un rapport d’audit mesure ; il ne priorise pas. Le travail de priorisation appartient à l’organisation, et il gagne à suivre une logique simple, que cette banque a ensuite inscrite dans son schéma pluriannuel.
- Lister les parcours sans lesquels le service ne sert à rien, avant de regarder les critères.
- Qualifier chaque défaut par son impact : bloquant, gênant, mineur.
- Remonter chaque défaut bloquant à sa source : composant partagé ou écran particulier.
- Arbitrer explicitement les conflits avec la sécurité, et documenter la décision.
- Inscrire les exigences d’accessibilité dans les contrats des prestataires.
- Vérifier avec des utilisateurs réels avant de déclarer un parcours corrigé.
Notre guide sur la conduite d’un audit d’accessibilité décrit les livrables qui facilitent ce tri, et notre dossier complet sur l’accessibilité numérique replace la démarche dans l’ensemble des obligations. Notre offre accessibilité et inclusion accompagne les organisations, de l’audit à la correction et aux tests avec des utilisateurs.
Scénario type construit à partir de situations courantes ; il ne décrit pas une organisation réelle.
Questions fréquentes
Les banques sont-elles soumises à l'European Accessibility Act ?
Oui pour les services bancaires destinés aux consommateurs, depuis le 28 juin 2025 : sites, applications mobiles, documents et terminaux concernés doivent respecter les exigences d'accessibilité, selon les modalités fixées par chaque transposition nationale. Les services réservés aux entreprises ne sont pas visés au même titre.
Par quoi commencer quand un audit révèle beaucoup de non-conformités ?
Par les parcours qui conditionnent l'accès au service : se connecter, consulter ses comptes, payer, contacter la banque. Sur ces parcours, on corrige d'abord ce qui bloque complètement un utilisateur, puis ce qui le gêne. Les composants partagés par toutes les pages, comme les menus et les formulaires, offrent souvent les corrections les plus rentables.
L'authentification forte est-elle compatible avec l'accessibilité ?
Oui, à condition d'offrir plusieurs méthodes et de ne pas imposer de test cognitif. La version 2.2 des WCAG demande qu'aucune étape de connexion n'exige de mémoriser, de recopier ou de résoudre une énigme sans alternative ; la validation dans l'application mobile, la possibilité de coller un mot de passe ou l'usage d'un gestionnaire de mots de passe y répondent.