Comment améliorer l'expérience utilisateur d'une application mobile

La première fois qu'on m'a demandé de refaire une appli qui perdait ses utilisateurs, je pensais que le problème était le design. Mauvaise pioche. Après trois semaines de refonte graphique, le taux de rétention n'avait pas bougé d'un pouce. C'est en ouvrant les logs de crash que j'ai compris : l'appli plantait à l'écran de paiement sur un modèle de téléphone précis, et personne ne s'en était rendu compte. Voilà le vrai visage d'une expérience utilisateur dégradée — souvent invisible, souvent technique, rarement esthétique.

Améliorer l'expérience utilisateur d'une application mobile, ce n'est pas rajouter des animations ni changer la palette de couleurs. C'est comprendre où les gens décrochent, pourquoi, et dans quel ordre corriger. Dans cet article, je vous donne la méthode que j'applique aujourd'hui sur mes projets, avec les chiffres que je surveille et les conneries que j'ai faites avant d'y arriver.

Pourquoi votre refonte graphique n'a rien changé (et ce qu'il faut regarder à la place)

On m'a appelé un jour pour une appli de réservation qui avait un beau design primé et une note de 2,8 étoiles sur le store. Le fondateur voulait une refonte. Je lui ai dit non. Le problème n'était pas là.

En deux heures dans les données, on a trouvé : 68 % des abandons se produisaient sur l'écran de sélection de date. Pas un problème d'esthétique. Un problème de calendrier qui rechargeait à chaque swipe, avec un temps d'attente visible de deux secondes. Les utilisateurs croyaient que l'appli était plantée.

Les chiffres qui diagnostiquent vraiment une UX mobile

Avant de toucher à un seul pixel, je regarde toujours ces indicateurs dans cet ordre :

1. Le taux de crash, ventilé par version de l'OS et par modèle. Un taux supérieur à 0,5 % est une hémorragie.
2. Le temps de démarrage à froid, mesuré sur un appareil d'entrée de gamme, pas sur votre flagship de développeur. Au-delà de 3 secondes, une part significative d'utilisateurs abandonne avant même de voir l'interface.
3. La rétention J1, J7, J30. C'est le seul juge de vérité.
4. Les points de sortie dans le parcours d'activation. Où exactement les gens ferment-ils l'appli pour ne jamais revenir ?
5. Enfin, et seulement enfin, le ressenti qualitatif via des tests utilisateurs.

Le piège classique : inverser cet ordre. On commence par les tests utilisateurs, on collecte des avis sur la couleur du bouton, on refait l'interface, et on n'a rien réglé. Franchement, j'ai perdu six mois comme ça sur mon premier projet sérieux.

La fragmentation iOS/Android n'est pas un détail cosmétique

Une chose que je vois encore trop souvent : on développe avec un framework cross-platform, on teste sur iOS, et on considère le sujet réglé. Sauf que la surcouche constructeur d'Android (Samsung, Xiaomi, etc.) peut modifier le comportement des permissions, la gestion du clavier, ou l'accès au stockage. Une interface application mobile qui fonctionne parfaitement sur un iPhone peut devenir inutilisable sur un appareil Android d'entrée de gamme.

Ma règle : toujours tester sur au moins un appareil bas de gamme Android. Ce n'est pas glamour, mais ça sauve des notes sur le store.

Fixer des seuils cibles : le tableau que j'utilise pour prioriser

Un KPI seul ne dit rien. Ce qui compte, c'est l'écart entre votre mesure actuelle et un seuil cible que vous vous engagez à atteindre. Voici la grille que j'applique, avec les seuils que je vise par défaut — à ajuster selon votre secteur, évidemment.

Métrique	Seuil à viser	Signal d'alerte	Action prioritaire
Taux de crash	< 0,3 %	> 0,5 %	Correction immédiate, hotfix en priorité 1
Démarrage à froid	< 2 s	> 3 s	Audit des dépendances, lazy loading
Rétention J7	> 25 %	< 15 %	Revoir le parcours d'activation (onboarding)
Rétention J30	> 10 %	< 5 %	Analyser les notifications et la valeur perçue
Temps de complétion du parcours principal	Dépend du produit	Toute étape > 2× la médiane	Simplifier ou supprimer cette étape

Sur un projet d'e-commerce, on a fait passer la rétention J7 de 12 % à 24 % en trois mois. Le déclencheur ? Une seule modification : on a supprimé une étape de création de compte obligatoire pour la remplacer par une connexion différée. Une étape en moins, +12 points de rétention. Le design n'avait pas changé d'un millimètre.

Comment tester sans se ruiner (et ce que Figma permet vraiment)

Vous n'avez pas besoin d'un labo avec miroir sans tain. Vous avez besoin de cinq personnes qui ressemblent à votre cible, et d'un prototype cliquable.

Figma : utile, mais pas pour ce que vous croyez

Figma est devenu le standard pour dessiner des interfaces mobiles. Le piège, c'est de croire qu'un beau prototype Figma est un test. Non. Un prototype Figma teste la compréhension du parcours, pas la performance ni le comportement réel sur device.

Ce que je fais systématiquement avec Figma :

• Je crée un prototype cliquable avec les 4 à 6 écrans critiques uniquement.
• Je le fais tester à des gens qui n'ont jamais vu le produit, en leur demandant de verbaliser ce qu'ils pensent à voix haute.
• Je note trois choses précises : les moments d'hésitation, les moments de frustration, et les moments où ils demandent de l'aide.

Un détail que j'ai appris à la dure : un test avec 5 participants révèle une grande partie des problèmes d'utilisabilité visibles. Au-delà, on répète les mêmes constats avec des personnes différentes. Mieux vaut trois sessions de 5 personnes qu'une session de 15.

Les outils que j'ai fini par adopter

Après avoir testé une dizaine d'outils, voici ceux que je garde aujourd'hui dans ma stack :

• Firebase Crashlytics pour les crashs, avec alertes automatiques dès qu'un seuil est franchi.
• Un outil de session replay pour voir où les utilisateurs tapent, hésitent, ou font des gestes erratiques.
• TestFlight (iOS) et les canaux de test interne Google Play (Android) pour déployer une version bêta à un panel fermé avant la prod.
• Un tableau de bord analytique produit branché sur les événements clés du parcours, pas juste sur les sessions.

Ce que j'ai abandonné : les heatmaps sur mobile. Elles sont trompeuses, car un doigt n'est pas une souris. Un tap peut être un scroll, une hésitation ou un miss. On tire de fausses conclusions très vite. Du coup, je préfère largement les événements explicites que je code moi-même.

Itérer vite sans casser : la discipline des releases courtes

La bonne nouvelle, c'est qu'améliorer l'UX mobile ne demande pas de refondre l'appli. La mauvaise, c'est qu'itérer sans méthode produit du chaos.

Voici le rythme que je tiens aujourd'hui :

1. Cycle de 2 semaines. On identifie un problème prioritaire, on corrige, on livre, on mesure.
2. Une hypothèse par release. Si vous changez trois choses en même temps, vous ne saurez jamais ce qui a fonctionné.
3. Staged rollout. 5 % des utilisateurs d'abord, puis 25 %, puis 100 %. Si le crash rate grimpe, on stoppe net.
4. Feature flags. Pour désactiver une fonctionnalité instable sans republier l'appli.

Et là, il faut être honnête : cette discipline, je ne l'avais pas au début. Je livrais tout le vendredi soir, sans filet, en priant. J'ai appris à mes dépens ce qu'un bug en prod un samedi peut coûter en notes sur le store et en confiance utilisateur. Ne livrez jamais le vendredi. C'est la leçon la plus chère que j'ai payée.

Les frictions invisibles qui tuent une appli

Il y a un type de problème UX dont personne ne parle parce qu'il ne laisse pas de trace dans les analytics : la friction cognitive. L'utilisateur ne plante pas, ne quitte pas, mais il ne revient pas non plus. Il n'arrive pas à expliquer pourquoi.

Trois exemples que j'ai rencontrés sur des projets réels :

• Un formulaire d'inscription qui demande le numéro de téléphone pour une raison jamais expliquée. Les gens hésitent, doutent, et parfois referment l'appli.
• Une notification push envoyée trop tôt, sans lien avec le moment où l'utilisateur a besoin de la fonctionnalité. Résultat : désinstallation.
• Un écran de confirmation qui valide une action mais ne donne aucun repère sur ce qui vient de se passer. L'utilisateur hésite, revient en arrière, recommence et crée un doublon.

Aucun de ces trois cas n'apparaît dans vos crash reports. Ils se voient uniquement dans la rétention et dans les tests qualitatifs. C'est exactement pour ça que je teste les deux en parallèle : les chiffres vous disent qu'il y a un problème, les utilisateurs vous disent lequel.

Ce que je fais concrètement lors du premier mois sur une nouvelle appli

Si on me confie aujourd'hui une appli mobile à améliorer, voici ma feuille de route pour les 30 premiers jours :

• Semaine 1 : audit brut. Crashs, temps de démarrage sur un appareil d'entrée de gamme, points de sortie du parcours principal. Aucune modification.
• Semaine 2 : cinq entretiens utilisateurs. Je regarde les gens utiliser le produit, je note chaque hésitation.
• Semaine 3 : priorisation. Je classe les problèmes par impact business, pas par effort de développement. Le premier correctif est presque toujours un crash ou une étape superflue.
• Semaine 4 : livraison et mesure. Staged rollout à 5 %, monitoring renforcé, on attend les chiffres avant de continuer.

Sur les projets où j'ai appliqué cette méthode, on a en moyenne gagné environ un tiers de rétention à J7 sur le trimestre. Ce n'est pas spectaculaire, ce n'est pas magique, mais c'est mesurable. Et c'est reproductible.

Le vrai changement n'est jamais celui qu'on attend

Si vous ne retenez qu'une chose de cet article, c'est celle-ci : la meilleure amélioration d'UX mobile que vous ferez cette année ne sera probablement pas visuelle. Ce sera un écran supprimé, un crash corrigé, une seconde gagnée au démarrage, ou une notification arrêtée à temps.

Un jour, quelqu'un m'a dit : « l'UX, c'est ce qui reste quand on a tout enlevé ». Je pensais que c'était de la poésie d'agence. Aujourd'hui, je pense que c'est la définition la plus honnête du métier. Enlevez l'étape inutile. Enlevez l'attente. Enlevez la question qui n'a pas de réponse. Ce qui reste, c'est votre produit — et parfois, ce qui reste suffit.

La prochaine fois que vous ouvrirez Figma pour retoucher une maquette, demandez-vous d'abord : est-ce que le problème que je vois est vraiment un problème de maquette ? La réponse n'est presque jamais oui.