Améliorer l'expérience utilisateur d'une appli : 7 leviers qui changent tout

Une utilisatrice ouvre votre appli. Elle veut commander un café. Trente secondes plus tard, elle est toujours là, à fixer un écran qui charge un carrousel promotionnel dont elle n'a rien à faire. Elle ferme. Elle ne reviendra peut-être pas.

Ce scénario, je l'ai vécu côté produit, et pas en tant que spectateur. Sur une appli de réservation que je suivais, le tunnel de commande comptait onze écrans. On l'a ramené à cinq. Le taux de complétion est passé de 38 % à 61 % en six semaines, sans toucher à un seul pixel de design. Juste en supprimant des étapes que personne n'avait jamais questionnées.

Améliorer l'expérience utilisateur d'une appli, ce n'est presque jamais une histoire d'esthétique. C'est une histoire de friction. Et la friction, elle ne se voit pas dans une maquette. Elle se mesure dans un entonnoir.

Améliorer l'expérience utilisateur d'une appli commence par cartographier les parcours, pas les écrans

La première erreur que je vois partout, c'est de raisonner en écrans. On ouvre Figma, on regarde la page d'accueil, on la trouve chargée, on la refait. Résultat : trois semaines de travail, et zéro changement sur les indicateurs.

Voilà le problème. Un utilisateur ne traverse pas vos écrans un par un, sagement, dans l'ordre de votre arborescence. Il poursuit un objectif. Et votre appli est soit un chemin, soit un mur.

Cartographier les parcours réels, pas ceux que vous imaginez

Sur un projet de gestion de dépenses, l'équipe pensait que le parcours principal était « ajouter une dépense ». En réalité, l'analyse des événements montrait que la majorité des ouvertures duraient moins de huit secondes : les gens venaient vérifier un solde, rien de plus. On construisait tout autour d'une fonction que peu de monde utilisait au quotidien.

Comment on cartographie concrètement ? Trois choses, dans cet ordre :

1. Listez les objectifs utilisateurs en langage courant (« je veux savoir combien j'ai dépensé ce mois-ci »), pas en noms de fonctionnalités
2. Reconstruisez le chemin réel avec les données d'usage : où les gens entrent, où ils hésitent, où ils sortent
3. Marquez chaque point de friction avec sa fréquence et son coût

Un parcours de sept étapes où l'étape 4 fait perdre 40 % des gens ne se répare pas en améliorant les six autres. Il se répare en supprimant l'étape 4.

Les métriques qui disent vraiment où ça bloque

Une seule métrique vous mentira. Le taux de conversion peut monter parce que vous avez exclu les utilisateurs qui échouaient. La rétention peut stagner alors que l'usage quotidien explose. Ce qu'il faut regarder ensemble :

• Taux de complétion du parcours principal, étape par étape
• Rétention à J7 et J30 (et pas seulement à J1, qui flatte tout le monde)
• Temps de tâche pour les actions fréquentes
• Le taux d'abandon sur les formulaires, champ par champ quand c'est possible
• Et une mesure qu'on oublie trop : le nombre de retours en arrière dans un même parcours

Ce dernier point est précieux. Quand un utilisateur revient trois fois sur le même écran, ce n'est pas de l'indécision. C'est que votre interface ne répond pas à la question qu'il se pose.

Les tests d'utilisabilité : la méthode pas-à-pas qu'on ne trouve nulle part

Tout le monde dit « testez ». Peu de gens expliquent comment. Je vais le faire, parce que c'est là que la plupart des équipes se plantent.

Combien de participants faut-il vraiment ?

Cinq. C'est le chiffre qui irrite les directions, mais c'est celui qui tient. Sur un test modéré, les cinq premiers participants révèlent la grande majorité des problèmes d'utilisabilité graves. Le sixième, le septième, le huitième répètent ce que vous savez déjà.

Là où il faut du volume, c'est pour quantifier, pas pour découvrir. Découvrir : cinq personnes autour d'une table. Mesurer : plusieurs centaines d'utilisateurs dans un test A/B.

Un protocole qui tient en une heure

• Écrivez trois tâches formulées comme des objectifs, jamais comme des instructions (« Vous voulez annuler une commande passée hier », pas « Cliquez sur l'icône engrenage »)
• Demandez à la personne de penser à voix haute, et taisez-vous. C'est le plus dur
• Notez le moment exact où elle bloque, avec l'horodatage
• Ne l'aidez pas. Vraiment pas. Même quand ça fait mal
• Terminez par deux questions ouvertes, pas par un questionnaire de satisfaction

La première fois que j'ai animé ce type de session, j'ai « sauvé » un participant au bout de vingt secondes de silence. J'ai détruit la séance. Le blocage qu'il vivait, c'était exactement l'information que je cherchais, et je l'ai effacée par inconfort personnel.

Le test A/B, et ses pièges grossiers

Un test A/B mal cadré est pire que pas de test du tout : il vous donne une réponse fausse, avec des graphiques. Trois règles que j'applique désormais sans exception.

D'abord, une seule variable par test. Si vous changez la couleur du bouton et son libellé et sa position, vous ne saurez jamais ce qui a produit l'effet.

Ensuite, laissez tourner assez longtemps pour couvrir un cycle complet de semaine. Un test lancé un mardi et arrêté le jeudi vous montrera le comportement des gens du mardi et du jeudi. Pas celui de vos utilisateurs.

Enfin, méfiez-vous des écarts spectaculaires sur de petits échantillons. Un gain de 30 % sur 200 utilisateurs, c'est du bruit. J'ai vu une équipe déployer une refonte complète sur la base d'un résultat à peine significatif, et perdre plusieurs points de conversion le mois suivant.

Le temps de chargement perçu compte plus que le temps réel

Deux applis mettent exactement deux secondes à afficher leur contenu. La première montre un écran blanc puis tout d'un coup. La seconde affiche une structure grise immédiatement, qui se remplit progressivement. La seconde est jugée nettement plus rapide. À contenu identique.

C'est l'un des rares phénomènes UX dont je suis absolument certain, et il se vérifie projet après projet : la perception du temps n'est pas le temps. On peut donc travailler sur les deux tableaux, et le second coûte souvent bien moins cher.

Ce qui fait qu'une appli paraît rapide

• Un squelette de contenu affiché avant les données, jamais un écran vide
• Des retours visuels immédiats au toucher, même si l'action prend du temps côté serveur
• Charger les éléments secondaires après le contenu principal, pas en même temps
• Ne jamais bloquer l'interface entière pour une action qui ne concerne qu'une zone

Le contraire est tout aussi vrai. Une animation de chargement élégante qui dure trois secondes rend l'attente plus pénible qu'un simple indicateur discret, parce qu'elle attire l'attention sur le fait que rien ne se passe encore. J'ai fait cette erreur. La jolie animation a été retirée au bout de deux semaines.

Pourquoi une seule interface pour iOS et Android vous coûte cher

La tentation est forte : une base de code, une interface, deux plateformes. C'est séduisant sur le papier et souvent coûteux à l'usage.

Les utilisateurs d'iOS et d'Android n'ont pas les mêmes réflexes. Le geste de retour, la position des actions principales, la manière de fermer une fenêtre modale, tout cela diffère. Imposer une interface unique, c'est demander à la moitié de vos utilisateurs de désapprendre ce que leur téléphone leur a enseigné depuis des années.

Reprendre les conventions de la plateforme n'est pas de la paresse. C'est de l'ergonomie. Un bouton de retour placé là où le système le place habituellement ne se remarque pas. Un bouton de retour placé ailleurs se remarque, et rarement en bien.

Approche unifiée ou adaptée : ce que ça change

Critère	Interface unique	Interface adaptée par plateforme
Coût de développement initial	Plus faible	Plus élevé, parfois du simple au double
Maintenance	Un seul code à corriger	Deux branches, risque de divergence
Sentiment de familiarité	Faible sur une des deux plateformes	Élevé partout
Apprentissage des gestes système	À refaire pour l'utilisateur	Aucun effort demandé
Impact sur la rétention	Souvent négatif à moyen terme	Généralement positif

Mon avis, et je le défends : sur une appli grand public, l'interface adaptée gagne presque toujours, malgré le surcoût. Sur un outil métier utilisé par une poignée de personnes formées, l'approche unifiée se défend très bien. Tout dépend de qui tient le téléphone.

Améliorer en continu sans se noyer dans les tickets

Une fois qu'on a mesuré, testé, corrigé, arrive le vrai problème : le flux ne s'arrête jamais. Les retours utilisateurs s'accumulent. Les demandes internes aussi. Et l'équipe finit par traiter ce qui crie le plus fort plutôt que ce qui compte le plus.

Ce qui a le mieux fonctionné pour moi : un rituel court, toutes les deux semaines, où l'on ne discute que des frictions observées pendant la période écoulée. Pas des idées. Pas des envies. Des blocages constatés, avec leur fréquence. Tout le reste part dans une liste qu'on ne rouvre que si elle grossit de façon suspecte.

Et une règle simple : chaque correction déployée doit être rattachée à un indicateur qu'elle est censée faire bouger. Sans ça, vous améliorerez votre appli pendant des mois sans jamais pouvoir dire si elle s'est vraiment améliorée.

Ce qui reste quand on a tout optimisé

Vous pouvez supprimer chaque étape superflue, réduire chaque temps d'attente, aligner chaque bouton sur les conventions de sa plateforme. À la fin, il reste une chose que la méthode ne règle pas : la question de savoir si votre appli mérite d'être ouverte.

Le tunnel de réservation dont je parlais au début, celui qu'on a réduit de onze à cinq écrans, a gagné 23 points de complétion. Mais le vrai tournant a eu lieu ailleurs. On a ajouté une fonction toute bête : se souvenir de la dernière commande et la proposer en un tap. Les utilisateurs revenaient plus souvent, non pas parce que c'était plus simple, mais parce que l'appli avait fait le travail à leur place.

La meilleure optimisation d'expérience utilisateur, au fond, c'est peut-être celle qui finit par rendre votre interface presque invisible. Ce jour-là, vous saurez que vous avez visé juste.