Part des utilisateurs ayant pu terminer l’ensemble de la vérification sans avoir à recommencer.
leur première tentative
Étude de cas

LE PROJET
AR24, filiale de Docaposte, propose des services de vérification d’identité à distance pour des situations nécessitant un haut niveau de confiance dans l’identité d’une personne.
En 2021, l’ANSSI, l’Agence nationale de la sécurité des systèmes d’information, a introduit le référentiel PVID (Prestataire de Vérification d’Identité à Distance). Il définit un ensemble d’exigences renforcées en matière de sécurité et de vérification pour les organisations qui vérifient des identités à distance, notamment pour des services numériques sensibles où il est essentiel de s’assurer de l’identité de la personne derrière l’écran.
Ce niveau de confiance plus élevé impliquait un parcours plus exigeant pour les utilisateurs, avec davantage d’étapes de capture et de vérification qui devaient rester compréhensibles et correctement exécutées.
Lorsque nous avons rejoint le projet en 2022, une première version était déjà en production. Certaines étapes généraient des taux d’échec plus élevés que souhaité par AR24. Notre équipe a donc été sollicitée pour auditer le parcours existant, comprendre où et pourquoi les utilisateurs rencontraient des difficultés, puis repenser l’expérience sans réduire le niveau de vérification requis.
J’ai travaillé étroitement avec un UX Designer sur l’audit, la recherche et la conception UX. J’ai pris un ownership plus direct sur l’UI, l’interaction design, le prototypage haute fidélité et le delivery Design-to-Dev.
LA PROBLÉMATIQUE
Part des utilisateurs ayant pu terminer l’ensemble de la vérification sans avoir à recommencer.
01Diagnostic
Avant de proposer une nouvelle version, nous voulions comprendre l’expérience existante sous tous ses angles plutôt que de la repenser à partir de simples hypothèses.
Nous avons commencé par un audit détaillé du parcours en production, écran par écran, afin d’identifier ce qui fonctionnait, ce qui créait de la friction et les endroits où l’expérience pouvait être améliorée. Nous avons ensuite présenté ce diagnostic à l’équipe produit pour partager une compréhension commune des problèmes avant de commencer la conception.
Nous avons complété cet audit par des tests utilisateurs sur le produit existant. Observer des personnes parcourir l’expérience réelle nous a permis d’identifier leurs hésitations, les consignes qu’elles survolaient, les actions qu’elles comprenaient mal et les moments où le parcours devenait difficile ou stressant.
En parallèle, nous avons benchmarké d’autres expériences de vérification d’identité à distance, notamment des acteurs qui adaptaient eux aussi leurs produits au nouveau référentiel PVID. Cela nous a permis de comprendre comment un marché encore émergent répondait à des contraintes similaires de sécurité et d’utilisabilité.
En combinant audit expert, comportements utilisateurs, retours directs et benchmark, nous disposions des bases nécessaires pour engager la refonte.
02Contraintes
Notre recherche confirmait que l’expérience devait devenir plus claire et plus simple à réaliser. Mais contrairement à de nombreux parcours numériques, simplifier ne pouvait pas simplement signifier supprimer les étapes jugées difficiles par les utilisateurs.
Le niveau de confiance exigé par le référentiel PVID imposait une succession d’actions liées au document d’identité et à la vérification du visage. Ces contraintes faisaient partie intégrante du service et ne pouvaient pas être supprimées.
Une autre contrainte entrait en jeu : une fois la vérification soumise, elle devait être examinée par un opérateur humain dans le cadre du processus PVID. Les utilisateurs pouvaient donc terminer l’intégralité du parcours sans savoir si chaque action avait été correctement réalisée. Le résultat pouvait arriver quelques minutes ou plusieurs heures plus tard et, si une ou plusieurs actions avaient échoué, la vérification pouvait être rejetée et l’utilisateur devait parfois tout recommencer. Pour des raisons de sécurité, il n’était pas toujours possible de lui indiquer précisément quelle étape avait causé l’échec.
Deux enjeux de design sont alors devenus centraux : rendre le parcours plus facile à anticiper et aider les utilisateurs à réussir chaque action demandée dès la première tentative.
03Guidage
L’expérience existante donnait l’impression d’une longue succession d’actions indépendantes. Plutôt que de chercher à masquer cette complexité, nous avons travaillé à rendre le parcours plus compréhensible avant et pendant son déroulement.
Structurer le parcours
Plutôt que de présenter le parcours comme une longue succession d’étapes, nous l’avons organisé autour de deux grandes phases : Document d’identité puis Capture du visage.
Cela donnait aux utilisateurs une représentation mentale plus simple du parcours et leur permettait de mieux comprendre ce qu’ils avaient déjà accompli et ce qu’il leur restait à faire.

Certaines erreurs ne pouvant être détectées qu’après la soumission, il était impossible de les corriger directement pendant le parcours.
Nous avons donc concentré nos efforts sur la préparation et le guidage avant et pendant chaque action, afin d’augmenter les chances de réussir correctement dès la première tentative.
Comprendre
Les premières versions reposaient beaucoup sur des instructions écrites, qui n’étaient pas toujours adaptées pour expliquer des gestes physiques inhabituels.
Nous avons simplifié les textes et les avons accompagnés d’illustrations animées montrant directement le mouvement attendu, afin de faciliter sa compréhension avant le début de l’enregistrement.
04Tests réalistes
Certains des problèmes d’utilisabilité les plus importants apparaissaient lorsque les utilisateurs interagissaient physiquement avec la caméra.
Un prototype de navigation classique aurait obligé les participants à imaginer ces moments plutôt qu’à réellement les effectuer, rendant les tests moins représentatifs de l’expérience finale.
J’ai proposé d’utiliser ProtoPie et construit un prototype haute fidélité intégrant une caméra fonctionnelle, permettant aux participants de réellement se filmer et d’effectuer les gestes demandés pendant les tests.
Nous avons ensuite suivi les réussites et les échecs étape par étape, puis croisé ces résultats avec nos observations afin de comprendre non seulement où les utilisateurs rencontraient des difficultés, mais surtout pourquoi.
05Itération
Une étape se distinguait par le taux d’échec le plus élevé de nos tests : plus de 20 % des utilisateurs échouaient lorsqu’ils devaient se filmer en tournant la tête dans la direction demandée.
Sur le papier, la consigne semblait simple. En pratique, beaucoup d’utilisateurs tournaient la tête du mauvais côté. Le problème devenait encore plus visible lorsqu’ils se filmaient, l’image miroir de la caméra rendant la distinction entre gauche et droite plus difficile.
Première itération : rendre la direction plus claire.
Au départ, l’interface demandait explicitement aux utilisateurs de tourner la tête vers la droite ou vers la gauche. Les tests ont montré que de nombreux participants continuaient à confondre les deux directions : rendre la consigne plus visible ne suffisait donc pas.
Deuxième itération : montrer le mouvement plutôt que le décrire.
Nous avons complètement supprimé la notion de droite et de gauche pour la remplacer par une grande flèche animée indiquant la direction à suivre, accompagnée d’une illustration de visage réalisant le mouvement attendu.
L’interaction ne demandait plus aux utilisateurs d’interpréter une direction, mais simplement de reproduire un mouvement montré à l’écran. Les tests suivants ont montré une nouvelle amélioration.
06Adapter la recherche
Certaines interactions présentaient encore des taux d’échec significatifs, mais dans une session classique avec un petit groupe de participants, cela pouvait ne représenter qu’un ou deux échecs.
C’était suffisant pour détecter un problème potentiel, mais pas toujours pour en comprendre la cause.
J’ai donc adapté notre approche de recherche en menant des guerrilla tests ciblés autour de certains gestes, chaque session se concentrant sur les interactions que nous avions encore besoin de mieux comprendre.
Nous avons également rencontré les opérateurs AR24 à Strasbourg. Comme ils examinaient quotidiennement les vérifications échouées, ils avaient une visibilité sur des erreurs d’exécution récurrentes qu’il était beaucoup plus difficile pour nous d’observer régulièrement lors de tests utilisateurs ponctuels.
Plutôt que de nous appuyer sur une seule méthode de recherche, j’ai adapté la méthode en fonction de ce qu’il nous restait à comprendre.
07Delivery et produit en production
Lorsqu’une itération était prête, mon implication se poursuivait pendant son implémentation. Je préparais les écrans, les différents états et les spécifications d’interaction, travaillais directement avec le développeur et réalisais la QA design et fonctionnelle sur plusieurs appareils.
Une fois en production, le produit devenait une nouvelle source d’information. Nous utilisions Hotjar pour identifier les frictions restantes et poursuivions les itérations à partir des comportements réels des utilisateurs.
08Réflexion
Je conserverais la même démarche globale, mais je mettrais en place le suivi de la data plus tôt dans le processus.
Nous avons commencé à utiliser ces données après plusieurs itérations. Les avoir dès le départ nous aurait permis d’identifier plus rapidement les interactions nécessitant notre attention et de mieux déterminer où une investigation qualitative était la plus utile.
Ce projet a également fait évoluer ma manière de considérer l’interaction design. Sur un parcours aussi guidé, un décompte, un mouvement ou un état de feedback ne sont pas de simples détails de finition : ils peuvent directement influencer la manière dont une action est comprise et correctement exécutée.