Tester un service numérique auprès de personnes handicapées

Depuis un an, je participe à l’organisation de tests auprès de personnes handicapées à la Digital Factory de la MAIF. C'est l'un des chantiers de ma mission d'AccessibilityOps — une pratique que Devon Persing définit comme l'équivalent du DesignOps pour l'accessibilité : une façon de lier les gens, les outils et les process autour de l'accessibilité numérique.

Concrètement, cette mission, que j'occupe depuis juillet 2025, s'articule autour de plusieurs chantiers :

• mettre l'accessibilité en avant chaque fois que c'est pertinent,
• accompagner les équipes pour adopter les bonnes pratiques,
• améliorer les process pour anticiper les erreurs d'accessibilité récurrentes,
• contribuer à la documentation du design system,
• coordonner l'organisation de tests avec des personnes handicapées.

Cette mission occupe 50 % de mon temps, le reste étant dédié à mon activité d'UX designer dans la squad mobilité. Non pas qu'il n'y ait pas assez de travail dans l'une ou l'autre activité, mais je pense qu'il est important de rester sur le terrain. En étant directement concernée par les changements opérationnels que je demande aux équipes, je ne perds pas de vue ce que ça implique.

Dans cet article, je vous propose un retour d’expérience sur le chantier qui a occupé une grande partie de ma dernière année : les tests avec des personnes handicapées. Les retours d'expérience sur le sujet viennent presque toujours des prestataires de recherche, je voulais le raconter côté client.

Pourquoi tester avec des personnes handicapées ?

Pour mieux comprendre les personnes concernées

Pour répondre aux besoins des personnes qui utilisent nos services, il n'y a pas d'autre option que d'échanger directement avec elles, quelle que soit leur situation d'usage ou leur expérience de vie.

Selon ce qu'on cherche à améliorer, on n'interrogera pas forcément les mêmes personnes. Je distingue donc volontairement deux cibles : les personnes en situation de handicap sur le numérique et les personnes handicapées.

Une personne en situation de handicap sur le numérique rencontre des difficultés de navigation quand le site n'est pas codé correctement. Par exemple, elle ne peut pas activer un lien avec la commande vocale si le nom accessible n'est pas le même que l'intitulé visible.

Une personne handicapée, elle, peut très bien ne pas rencontrer de difficultés sur le numérique. Par exemple, une personne qui utilise un fauteuil roulant car elle a perdu l'usage de ses jambes ne devrait pas avoir de mal à utiliser une souris ou un clavier. Pour autant, elle reste handicapée, et ça peut influencer les informations qu'elle cherche. Elle pourrait notamment se renseigner sur l'assurance de son fauteuil au moment de souscrire une assurance auto ou habitation.

Cette distinction guide le recrutement. Si je cherche à vérifier la mise en avant d'une information, j'interroge des personnes handicapées. Si je cherche à vérifier l'utilisabilité d'un parcours, je fais plutôt appel à des personnes en situation de handicap sur le numérique. Et bien entendu, on peut être concerné par les deux situations en même temps.

Parce que les audits ne remplacent pas les tests

Depuis plusieurs années, la Digital Factory de la MAIF est accompagnée par la société Temesis, dont les équipes expertes réalisent nos audits de conformité, ainsi que des audits ponctuels sur des maquettes ou des environnements de test.

Mais un audit, aussi rigoureux soit-il, a une limite structurelle : il est réalisé par des personnes qui maîtrisent parfaitement les technologies d'assistance. Or ce n'est pas le cas de tout le monde. 

Une personne malvoyante qui commence à utiliser une synthèse vocale à 50 ans, parce que sa vue ne lui permet plus de naviguer comme avant, ne devient pas subitement experte des technologies d'assistance. Là où l'audit vérifie la conformité à un référentiel, le test révèle ce qu'une personne vit réellement sur l’interface. C'est ce que l'audit ne peut pas voir, et c'est pour ça que l'un ne remplace pas l'autre. C’est la même logique que dans tout travail d’UX research : on ne conclut pas à la place des personnes, on observe ce qu’elles font et on écoute ce qu’elles disent de leur expérience.

Pour tenir compte de la diversité des expériences — et par souci de démocratie

Une autre raison, peut-être évidente, d'organiser des tests avec des personnes handicapées est la représentativité. De la même manière qu'on interroge des personnes de tous genres, de foyers modestes comme aisés, vivant à la campagne et en ville, nous voulons aussi discuter avec des personnes qui ont besoin de l'accessibilité numérique au quotidien.

C'est aussi un principe démocratique : toute personne a le droit d'être représentée et d'avoir son mot à dire. Tester avec des personnes handicapées, c'est donc leur donner une prise directe sur les services qu'elles utilisent. C'était d'ailleurs l'esprit du slogan historique des mouvements de personnes handicapées : nothing about us without us, (rien sur nous sans nous).

Parce que c'est reconnu dans le schéma pluriannuel

Le schéma pluriannuel de mise en accessibilité, qui présente la politique d'accessibilité numérique d'une organisation, doit présenter des informations sur « la prise en compte des personnes en situation de handicap dans les tests utilisateurs ». Si ces tests sont mentionnés, c'est bien parce qu'ils comptent.

Le texte ne les rend pas obligatoires pour autant. Mais cette mention officielle donne un point d'appui qui devrait encourager les équipes à s'y intéresser.

Déconstruire les idées reçues sur l’UX research avec des personnes handicapées

Si vous connaissez mon travail, vous savez que je parle beaucoup de la déconstruction des idées reçues, notamment quand il s'agit de défendre l'accessibilité numérique.

Pour organiser des tests avec des personnes handicapées, j'ai dû faire face à quelques idées reçues. Je vous propose des arguments pour celles qui reviennent régulièrement.

Est-ce légal de questionner les gens sur leur handicap ?

Oui, on peut légalement faire de l'UX research avec des personnes handicapées. Pour les recruter dans un panel, on peut utiliser les questions du Washington Group, qui se concentrent sur la situation d'usage plutôt que sur l'état de santé des gens.

Par exemple, je cherche à recruter des personnes qui utilisent une plage braille ou une synthèse vocale. Je ne cherche pas à recruter des personnes aveugles. Ça me permet de ne pas stocker une donnée médicale sensible dont je n'ai, en réalité, pas besoin.

Ce qui exigerait un cadre juridique bien plus lourd — et dont on n'a justement pas besoin — ce serait de conserver un document associant des personnes identifiées par leur nom et prénom, à leur handicap. 

Qu'elles aient un handicap ou non, il est indispensable de garantir la sécurité des données personnelles de vos panélistes. Si vous recrutez des prestataires pour faire ce type de recherche, demandez-leur une notice RGPD pour vous assurer que tout sera conforme.

Faut-il une formation particulière pour faire des tests avec des personnes handicapées ?

Oui et non : ça dépend de qui mène les tests. Si vous les animez vous-même, une vraie montée en compétence s'impose — adapter les protocoles et les sessions aux personnes participantes est un savoir-faire à part entière. Mais si, comme nous à la Digital Factory, vous êtes commanditaires, non : ce sont des prestataires spécialisés qui s'en chargent, et c'est leur métier.

En revanche, même côté commanditaire, il y a des paramètres à prendre en compte : savoir ce qu'il faut cadrer en amont et ce que les designers des squads concernées doivent préparer. Cet apprentissage se fait en faisant. On tâtonne les premières fois, comme dans tout nouveau projet, ce n'est pas une raison de se décourager. De mon côté, j'avais la chance de connaître des personnes compétentes pour nous aiguiller, mais ce n'est pas un prérequis. Les prestataires font aussi ce travail d'accompagnement auprès de la clientèle qui débute.

Les tests avec des personnes handicapées sont-ils plus compliqués à organiser ?

Non, pas quand on passe par des prestataires. Si vous constituez et entretenez vos panels vous-même, la donne change : maintenir un panel est une activité exigeante. Mais à la Digital Factory, l'UX research est généralement effectuée par des prestataires de recherche qui collaborent avec des panels. Pour ces tests, nous les mettons simplement en relation avec un panel spécialisé dont nous apprécions la qualité de travail.

Il n'y a donc pas tellement plus de logistique en amont pour nous. Elle est peut-être un peu plus lourde pour le prestataire, mais ça fait partie de la commande. Côté MAIF, notre seule tâche supplémentaire est de nous assurer de la pertinence des profils — j'y reviens plus loin dans cet article.

Comment nous l’avons fait à la Digital Factory de la MAIF

Pendant le cadrage, sur une recommandation de Gwenaëlle Brochoire, co-fondatrice d’Oocity, nous avons scindé notre projet en deux parties :

• une étude dédiée auprès de personnes handicapées, pour apprendre ce que nous ne savions pas ;
• une expérimentation en incluant 2 personnes handicapées dans des tests déjà programmés, pour comprendre si cette inclusion pouvait devenir systématique.

Étude dédiée sur le rapport des personnes handicapées à l'assurance et à ses services numériques

Comment préparer une étude dédiée

Jusque-là, nous n'avions jamais recruté de personnes handicapées pour nos tests, même si certaines y ont peut-être participé sans que nous le sachions. Nous avions donc beaucoup de questions à leur poser : trop pour un test d’utilisabilité ou de compréhension. Une étude dédiée nous permettait de mener un entretien exploratoire plus complet et d'apprendre ce qu'on ne savait pas.

Elle nous permettait aussi d'avoir un panel de situations plus large que dans un test classique. Nous voulions notamment savoir si la situation d'usage pouvait faire varier les attentes et l'utilisabilité d'un parcours, dans quelles conditions, et si, au-delà de la conformité, nous avions encore des choses à anticiper. Toutes ces questions n'auraient jamais tenu dans un test classique.

Pour cette étude dédiée, nous avons travaillé avec LunaWeb pour la partie recherche et Oocity pour constituer le panel.

Je cite LunaWeb et Oocity parce qu'un retour d'expérience anonyme n'aiderait personne, pas pour vous les vendre. Ce qui compte ici, ce sont les critères qui nous ont permis de faire un choix.

Comment choisir les bons prestataires ?

Deux critères ont fait la différence : la capacité à accueillir une demande encore floue, et l'éthique vis-à-vis des panélistes.

Quand nous avons commencé nos travaux, notre demande était loin d'être claire. Nous avons discuté avec plusieurs prestataires de recherche et spécialistes de l'accessibilité numérique pour nous aiguiller. 

LunaWeb a compris notre besoin et a su faire une proposition bien alignée avec nos valeurs et nos ambitions. Anaïs Demaretz, chef de projet, et Justine Nicol, lead UX researcher, nous ont fait une proposition extrêmement soignée. LunaWeb travaille le sujet de l'UX research avec des personnes handicapées depuis des années – Justine en a d’ailleurs tiré un talk à Paris Web en 2025.

Côté panel, Oocity est une référence qui existe depuis longtemps. Les personnes qui interviennent dans le panel sont toujours rémunérées, correctement accueillies et accompagnées. Cette éthique correspond très bien aux valeurs MAIF, notamment dans son attention sincère à l'autre. J'avais déjà interviewé Gwenaëlle Brochoire et je savais à quel point son travail serait sérieux, exigeant et à la hauteur de nos propres ambitions.

En combinant LunaWeb et Oocity, nous avions un duo idéal pour une étude dédiée.

Construire le protocole et le panel

L'étude dédiée devait répondre à deux objectifs : mieux comprendre les personnes concernées, mais aussi vérifier l'utilisabilité d'un parcours sans erreurs bloquantes.

Nous avons donc organisé les tests en deux parties :

1. un entretien exploratoire ;
2. un test d'utilisabilité et de compréhension sur le parcours d'assurance habitation.

Chaque personne recrutée devait pouvoir servir les deux objectifs de l'étude : être handicapée, pour nourrir l'entretien exploratoire, et être en situation de handicap sur le numérique, pour le test du parcours avec ses outils. C'est la distinction posée en début d'article — sauf qu'ici, il nous fallait les deux à la fois. Nous avons donc recruté 23 personnes qui :

• ont un implant auditif ou utilisent la LSF,
• utilisent des sous-titres et des transcripts,
• utilisent des plages braille ou des synthèses vocales,
• adaptent les contrastes, le zoom, la taille de la police...
• utilisent le mode sombre,
• ont des stratégies de contournement (codes couleur...),
• utilisent la commande vocale,
• ont des difficultés de lecture ou de mémoire de travail.

Oocity nous a proposé un panel équilibré entre les personnes qui sont dans une situation d'usage depuis la naissance et celles qui ont dû prendre de nouvelles habitudes au cours de leur vie. Cet équilibre est important car il peut impacter l'utilisation des services numériques : une personne aveugle de naissance ne peut pas faire appel à sa mémoire visuelle, là où une personne devenue malvoyante a peut-être encore une vision partielle et va naturellement chercher à compenser les défauts d'une interface.

Nous voulions aussi recruter des personnes avec une déficience intellectuelle pour étudier le niveau de compréhension de nos parcours et envisager une traduction en FALC (Facile à Lire et à Comprendre). Mais au cours du recrutement, nous avons constaté que les personnes contactées ne s'occupaient pas de leurs démarches d'assurance de façon autonome — le sujet leur paraissait trop complexe, ou était pris en charge par leur entourage. Aucune personne avec une déficience intellectuelle n'a donc fait partie de cette étude.

Enseignements de l’étude dédiée

Résultats de l’entretien exploratoire

Le numérique, censé faciliter la vie, est en réalité très complexe. Pendant l'entretien exploratoire, les personnes interrogées ont évoqué les problèmes qu'elles rencontrent quotidiennement sur internet :

• des blocages techniques pour les personnes aveugles (ex : captcha)
• des difficultés de lecture pour les personnes malvoyantes et avec des troubles cognitifs (ex : polices, mise en page chargée)
• des difficultés de saisie pour les personnes avec un handicap moteur ou des troubles cognitifs (ex : recopie inutile des informations, inversions de chiffres, etc.).

Dans un environnement inadapté — c'est-à-dire qui ne prend pas en compte leurs besoins comme des besoins humains, normalisés — les gens vivent plusieurs choses :

• surcharge cognitive pour les personnes malentendantes, en état d'alerte constant pour comprendre leur environnement ;
• fatigue visuelle pour les personnes malvoyantes ;
• épuisement lié à la concentration pour les personnes avec des troubles psychiques ;
• anxiété pour les personnes avec des troubles cognitifs, qui craignent de faire des erreurs aux conséquences lourdes sur les documents administratifs.

Quand on leur a demandé si elles connaissaient des entreprises réputées pour leur accessibilité numérique, les personnes interrogées ont répondu que non (20 sur 23). Et même si une marque communiquait sur son inclusion, elles ne la croiraient pas sur parole. Les personnes aveugles, notamment, préfèrent vérifier par elles-mêmes que les services sont bien compatibles avec leurs outils.

Quand on leur a demandé ce qu'elles attendaient des services numériques, deux types d'attentes sont ressorties. La structure technique et la navigation, très importantes pour les personnes aveugles et/ou avec un handicap moteur car elles ont une sensibilité commune sur la compatibilité des services avec leurs outils techniques (lecteur d'écran et commande vocale). Il y a aussi une forte exigence sur la lisibilité et la charge cognitive pour les personnes avec des troubles cognitifs ou psychiques et les personnes malvoyantes. Elles partagent le même besoin de confort visuel (contrastes marqués, bonne taille de caractères, simplicité de l'interface, structure et cohérence visuelles).

Résultats du test sur le parcours d’assurance habitation

Le test a été effectué en production sur le parcours d'assurance habitation, récemment mis à jour. Le tester en production plutôt que sur une maquette Figma nous permettait de vérifier la compatibilité réelle avec les technologies d'assistance. Le parcours n'était pas encore conforme à 100 %, mais aucun problème bloquant n'avait été identifié par les audits.

Les efforts de la squad Design System ont pu être valorisés, notamment par les personnes avec des difficultés de lecture ou de mémoire. Elles ont souligné la mise en page du parcours, le choix des espacements, les illustrations, l'utilisation des pictogrammes, la graisse sur les titres et l'utilisation de polices lisibles.

Le parcours a aussi été jugé très fluide par les personnes malvoyantes, qui ont apprécié le passage séquentiel d'une question à l'autre. Les personnes avec des troubles cognitifs ont apprécié l'aide à la complétion proposée tout au long du parcours, notamment les exemples qui aident à vulgariser le jargon assurantiel.

Côté points d'amélioration, on a constaté que le temps de complétion du parcours était doublé, voire triplé, par rapport à une navigation par une personne valide. Trois enseignements en ressortent :

• ce qui n'est pas conforme n'est évidemment pas utilisable par les personnes qui utilisent des technologies d'assistance ;
• ce qui est conforme peut rester complexe à utiliser avec des technologies d'assistance ;
• le vocabulaire peut encore être trop complexe pour les personnes sourdes et malentendantes ou avec des troubles cognitifs.

Conclusion de l’étude dédiée

En conclusion, le handicap agit comme un amplificateur de frictions. Il met en lumière des blocages techniques ou cognitifs invisibles pour une personne sans handicap. Cet enseignement doit nous encourager à poursuivre l'inclusion de personnes handicapées dans nos tests, afin de donner du poids aux signaux faibles.

Les personnes interrogées ont, dans leur majorité, été surprises d'apprendre que des équipes s'intéressaient à leur expérience du numérique. Beaucoup sont arrivées aux tests en disant "c'est bien de nous demander notre avis". D'autres ont parlé d'avoir complètement renoncé à ce genre de démarches.

Les équipes de conception ne peuvent pas, à elles seules, réparer ce renoncement. Mais c'est un retour indispensable pour l'entreprise. Au-delà de la mise en conformité et de l'amélioration de l'expérience, il est primordial de mieux communiquer sur les efforts d'accessibilité numérique — j'en parlais déjà dans mon article sur le design validiste. C'est ce qui permettra d'atteindre les personnes qui ont renoncé au web par lassitude et frustration.

Une expérimentation pour élargir les panels de tests de façon systématique

En parallèle de l'étude dédiée, nous avons lancé la seconde partie du projet : élargir le panel de personnes interrogées lors des tests déjà programmés à la Digital Factory.

Ces tests peuvent être modérés en labo, à distance, ou encore non modérés via une plateforme. Généralement, ils comprennent environ 20 personnes directement recrutées par nos prestataires de recherche. Là encore, j'ai servi de point de contact entre Oocity et nos prestataires de recherche, dont We Love Users, pour inclure des personnes dont la situation d'usage pouvait être pertinente. Ce rôle de point de contact entre des acteurs qui ne travaillaient pas ensemble jusque-là, c'est le cœur de ma mission d'AccessibilityOps.

Nous avons inclus 2 personnes supplémentaires à chacun des 5 tests dans différents produits et parcours d’assurance : devis d’assurance habitation, navigation dans l’espace personnel, déclaration de sinistre, etc.

Comment préparer un test avec des personnes handicapées

Pour chaque test, et surtout les premiers, j'ai orchestré de nombreux échanges entre Oocity pour le recrutement, Audrey Dreillard (la référente en UX research de la Digital Factory), les designers des squads concernées et We Love Users. Cet effort s'est considérablement réduit au fur et à mesure qu’on organisait de nouveaux tests, chaque partie prenante adoptant de nouvelles habitudes.

Mon rôle était de faire le relais pour définir les profils les plus pertinents pour chaque test. Par exemple, quand un test porte principalement sur la compréhension du parcours, il peut être intéressant d'inclure des personnes avec des difficultés de lecture ou de mémorisation, qui réagissent plus vite et plus fort au contenu et à la façon dont il est présenté.

À l'inverse, pour vérifier l’utilisabilité d’un parcours sur un environnement de test, on peut faire intervenir des personnes qui utilisent des technologies d'assistance, si tant est qu’il n’y ait aucun problème bloquant identifié en amont. Dans le cas contraire, vous risquez de faire perdre du temps à tout le monde, vous compris. Si la personne se retrouve bloquée dès l'entrée du parcours, inutile d'aller plus loin. La débloquer pour continuer le test ne refléterait pas ce qu'elle vivrait en situation réelle.

Ce que les designers ont retenu de cette expérimentation

Plutôt que de vous parler des différents enseignements récoltés sur les parcours testés, je vais me concentrer sur les réactions des designers des squads concernées.

Quand je leur ai demandé "auriez-vous loupé quelque chose si ces 2 personnes n'avaient pas fait partie de votre panel ?", les designers m'ont unanimement répondu que non. Cette réponse s’explique aussi par la maturité déjà acquise par les équipes sur certains aspects de l’accessibilité. Les tests n’ont pas révélé de difficulté majeure qui leur aurait entièrement échappé.

Les designers ont néanmoins cité plusieurs observations :

• une personne a eu des difficultés à écrire sans faute d'orthographe, ce qui a ralenti la complétion du formulaire ;
• une autre a fait beaucoup de retours positifs sur l'UI, notamment les pictogrammes ;
• une dernière a identifié des problèmes de structure.

Aucun de ces constats ne remettait à lui seul le parcours en question. Mais chacun constituait un signal qu’aucune autre personne du panel n’avait fait remonter. Ça rejoint ce que l’étude dédiée nous avait appris : le handicap peut amplifier certaines frictions et donner davantage de poids aux signaux faibles.

Audrey Dreillard a aussi observé que cette expérimentation a fait évoluer notre manière de préparer, mener et analyser les tests :

Au-delà des enseignements en lien avec l'utilisabilité d'un produit ou d'un parcours testé auprès de personnes handicapées, la démarche de recherche inclusive impulsée par Tamara nous a appris à développer durablement des réflexes dès la phase de préparation de nos tests, notamment en ce qui concerne les conditions d'accueil des participants ("est-ce que le lieu retenu est accessible à tous ?", "est-ce que la luminosité de la salle peut facilement être adaptée pour le confort des participants qui en feraient la demande ?"), ou encore la façon de formuler des questions dans un protocole. Et ce même dans des tests n'incluant pas spécifiquement des personnes handicapées. Car cette démarche nous a aussi rappelé que nous avions "naturellement" dans nos panels des personnes handicapées.

Vers la systématisation

Notre équipe a choisi de poursuivre l'inclusion systématique de personnes handicapées pour nos tests.

Quand on a commencé ces travaux l'an dernier, on ne savait pas grand-chose du sujet. Aujourd'hui, nous maîtrisons mieux le process :

• qui recruter ;
• avec qui collaborer ;
• comment analyser un retour.

Mon rôle dans ce projet n'a jamais été de mener les tests ni de rédiger les livrables — d'autres le font mieux que moi. Il a été de tenir les fils entre les personnes, les outils et les étapes : coupler les bons prestataires, faire circuler la compétence entre les squads et la recherche, veiller à ce que l'attention aux personnes handicapées irrigue tout le processus. C'est précisément ce que recouvre l'AccessibilityOps.

Nos prestataires ont également pris de nouvelles habitudes et savent désormais anticiper nos besoins pour élargir le panel de personnes interrogées. La Digital Factory travaille aussi sur une charte d'UX research qui définit nos attentes et engagements vis-à-vis de ces prestataires. J'ai relu cette charte, rédigée par le lead UX et la référente en UX research, en veillant à diffuser l'attention aux personnes handicapées tout au long du processus — du recrutement à la restitution, en passant par la participation et l'analyse. Par exemple, nous demandons à ce que les documents de consentement soient produits dans un format accessible, afin que la personne puisse en prendre connaissance en toute autonomie. Ce qui paraît tout à fait évident une fois documenté.

Il nous reste des choses à affiner. Il nous faudra plus de précision dans la sélection des panélistes, peut-être en priorisant les profils les plus en difficulté pour ne pas risquer de louper un signal faible. Nous souhaitons aussi capitaliser sur la présence de ces panélistes pour continuer à apprendre des choses sur le rapport à l'assurance des personnes handicapées — il faudra donc travailler la partie entretien exploratoire de sorte qu'elle s'adapte à ces profils.

Enfin, j’espère que le partage de cette expérience encouragera d'autres systématisations,  en assurance comme ailleurs. Car ces tests montrent que c'est possible, pertinent, et que ça en vaut la peine.

Ce retour d'expérience est déjà long, et je n'ai pas pu tout dire. Si vous avez des questions sur cette démarche, écrivez-moi : j'y répondrai volontiers.