WiFi Direct

Expérience utilisateur mobile : 7 erreurs à éviter absolument

La plupart des erreurs UX mobile ne sont pas visuelles : elles sont tactiles. Zones trop petites, gestes mal placés, formulaires inadaptés — des bugs silencieux qui tuent vos conversions sans que vous le sachiez jamais.

Expérience utilisateur mobile : 7 erreurs à éviter absolument

Les erreurs d'expérience utilisateur mobile qui plombent vraiment vos conversions

Un utilisateur ouvre votre application. Il a le pouce posé au milieu de l'écran, l'autre main occupée à tenir un café. Il voit un bouton. Il appuie. Rien ne se passe. Il appuie une deuxième fois, plus fort, comme si la pression allait changer quoi que ce soit. Il ferme l'app.

Vous venez de perdre un client, et vous ne le saurez jamais. Pas de plainte, pas de mail, pas d'avis à une étoile. Juste un décrochage silencieux dans vos statistiques, que vous mettrez sur le compte d'un « trafic de mauvaise qualité ».

La plupart des listes d'erreurs UX mobile que je croise parlent de temps de chargement et de navigation confuse. C'est vrai, mais c'est déjà connu. Le vrai problème est ailleurs : la majorité des erreurs UX mobiles sont des erreurs de pouce. Des zones tactiles trop petites, des gestes mal placés, des formulaires pensés pour un clavier physique. Et ça, presque personne n'en parle.

Points clés à retenir

  • La zone tactile minimale recommandée est de 44x44 pixels (Apple) et 48x48 dp (Google) — en dessous, vous perdez des taps.
  • Un formulaire mobile avec plus de 3 champs et sans type adapté double le taux d'abandon.
  • Sous 3 secondes de chargement, un utilisateur mobile reste. Au-delà, une bonne partie abandonne.
  • Le scroll horizontal accidentel et les modales mal fermables sont les deux erreurs les plus sous-estimées.
  • On corrige dans l'ordre : impact business d'abord, élégance ensuite. Jamais l'inverse.

Les erreurs tactiles que tout le monde ignore

Quand j'ai commencé à auditer des apps mobiles il y a quelques années, je regardais surtout les wireframes. Grave erreur. Un écran peut être impeccable sur Figma et catastrophique dans une main. La différence, c'est le pouce.

1. Les zones de tap trop petites (et le mythe du pixel visible)

Le piège classique : un designer place une icône de 20 pixels en haut à droite de l'écran, et considère que c'est bon parce que l'icône est bien visible. Sauf que la zone tactile et la zone visuelle ne sont pas la même chose. Apple recommande une cible minimale de 44x44 pixels, Google parle de 48x48 dp. Si votre croix de fermeture fait 24 pixels avec 0 de padding autour, vous avez un bouton qui marche une fois sur deux.

J'ai vu une app de réservation de restaurants perdre 18 % de ses réservations après une refonte. Cause : le bouton « Confirmer » avait été réduit de 12 pixels en hauteur pour « gagner de la place ». Douze pixels. Trois semaines de dev, un billet de train, et un retour arrière en urgence.

2. Ignorer la zone du pouce

Sur un écran de 6 pouces, votre pouce atteint confortablement le tiers inférieur de l'écran. Le coin supérieur droit, non. Mettre vos actions principales — panier, achat, suivre — dans le bandeau du haut, c'est demander à l'utilisateur de réorganiser sa main à chaque clic.

La règle simple que j'applique maintenant : les actions critiques vivent dans le tiers bas. Les filtres, la recherche, les préférences peuvent rester en haut. Les règles de navigation, elles, ne se négocient pas avec l'ergonomie.

3. Le scroll horizontal accidentel

Vous connaissez cette sensation : vous voulez faire défiler la page vers le bas, et l'écran part sur le côté parce qu'un carrousel a capté le geste. Vous vous retrouvez sur une pub pour un site partenaire, et vous perdez 4 secondes à revenir. La deuxième fois, vous quittez.

C'est une erreur d'autant plus vicieuse qu'elle est invisible dans vos tests. Elle n'apparaît que sur un vrai appareil, avec un vrai pouce, dans un vrai métro. La solution n'est pas technique (même si overscroll-behavior aide), elle est stratégique : ne mettez pas de carrousel horizontal à l'endroit exact où l'utilisateur fait défiler verticalement. Jamais.

Les formulaires mobiles : le cimetière des conversions

Combien de champs dans votre formulaire d'inscription ? Quatre ? Six ? Dix ?

Les formulaires mobiles : le cimetière des conversions

Chaque champ supplémentaire sur mobile coûte plus cher qu'en desktop, parce que le clavier virtuel couvre la moitié de l'écran, que le passage d'un champ à l'autre est laborieux, et que les erreurs de saisie explosent. Un formulaire avec plus de 3 champs obligatoires et sans attribut type adapté (email, tel, number) peut voir son taux d'abandon doubler.

Deux corrections simples, testées sur un de mes projets :

  • Attribuer le bon inputmode à chaque champ → le clavier numérique s'ouvre automatiquement sur les champs de téléphone.
  • Découper le formulaire en étapes visuelles avec barre de progression → +23 % de complétion en deux semaines.

Le reste, franchement, c'est du vernis. Vous pouvez ajouter des animations et du feedback haptique tant que vous voulez : si votre champ « code postal » ouvre un clavier alphabétique, vous avez perdu.

Performance mobile : au-delà du temps de chargement

Le seuil des 3 secondes, tout le monde le connaît. Mais sur mobile, la performance ne s'arrête pas au premier chargement. Trois autres choses tuent l'expérience, et elles sont presque toujours absentes des checklists :

La batterie

Une app qui vide la batterie de 15 % en 20 minutes d'usage, personne ne la garde. Les animations lourdes, les capteurs GPS sollicités en permanence, les connexions WebSocket maintenues en arrière-plan : ça consomme, et l'utilisateur le voit dans ses réglages.

Le comportement hors-ligne

Vous êtes dans le métro. Vous ouvrez votre app. Écran blanc, ou pire, une erreur « impossible de charger les données ». Pas de cache, pas de message utile. L'utilisateur n'a pas de problème avec le fait que votre app ne fonctionne pas hors-ligne. Il a un problème avec le fait qu'elle plante silencieusement. Un état dégradé propre vaut mieux qu'un écran vide.

Le poids des assets

Une image hero en 4K, trois polices custom, un bundle JavaScript non découpé : à l'arrivée, plusieurs mégaoctets sur une connexion 4G moyenne. Le premier affichage prend 6 secondes. L'utilisateur, lui, a déjà tapé sur l'icône suivante.

Tableau comparatif : erreurs visibles vs erreurs invisibles

Type d'erreur Détectable sur Figma ? Impact sur la conversion Coût de correction
Zone tap < 44px Non Élevé Faible
Formulaire trop long Partiellement Très élevé Moyen
Scroll horizontal parasite Non Moyen Faible
Pas de cache hors-ligne Non Élevé selon secteur Élevé
Contraste insuffisant Oui Faible (mais critique accessibilité) Faible

La colonne intéressante, c'est la dernière. Les erreurs les plus coûteuses à corriger sont rarement celles qui rapportent le plus. Les zones de tap, le scroll horizontal, les formulaires : ce sont des corrections à quelques heures de dev, avec un impact immédiat.

Tableau comparatif : erreurs visibles vs erreurs invisibles

Comment optimiser l'expérience utilisateur ?

L'optimisation de l'expérience utilisateur repose sur quatre étapes incontournables : analyser le comportement de vos visiteurs, comprendre leurs attentes, identifier les points de friction, puis corriger en priorité ce qui bloque la conversion. La première étape est la plus souvent zappée — on saute directement à la refonte visuelle.

Commencez par observer, pas par redessiner

Un outil d'analyse comportementale (heatmaps, enregistrements de sessions, tunnels de conversion) vous montre où les utilisateurs cliquent, où ils hésitent, où ils abandonnent. C'est cette phase de recherche qui révèle les points de friction — pas votre intuition de designer, ni la réunion où quelqu'un a dit « je trouve que ce bouton est trop petit ».

Concrètement, sur un projet e-commerce, j'ai installé des enregistrements de session pendant 10 jours. Résultat : 40 % des utilisateurs tapaient trois fois de suite sur le même bouton « Ajouter au panier ». Personne ne l'avait signalé. Le bouton mettait 800 ms à répondre visuellement. Aucun retour, aucune erreur — juste un silence qui passait pour un bug.

Comment prioriser les corrections quand tout semble cassé

Vous avez identifié 30 problèmes. Vous ne pouvez pas tous les corriger. L'ordre que j'utilise, et dans lequel je crois fermement :

  1. Impact business direct (réservation, achat, inscription) — à traiter en premier, peu importe l'esthétique.
  2. Fréquence d'usage — un bouton cliqué 100 fois par jour passe avant une page vue une fois par mois.
  3. Accessibilité — contraste, taille de police, compatibilité lecteurs d'écran. Ce n'est pas de la cerise, c'est une obligation.
  4. Cohérence avec les règles des stores — Apple et Google rejettent régulièrement des apps pour des manquements UX basiques (gestes non standards, absence de politique de confidentialité accessible).

Cette grille m'a évité plusieurs fois de refaire une interface entière pour un problème qui tenait à trois lignes de CSS. Avouez qu'il y a de quoi être amer quand on y pense.

Ce qu'il faut retenir quand vous regardez votre app dans le métro

Le meilleur test UX mobile que vous ferez jamais ne coûte rien : prenez votre téléphone, mettez-vous debout dans le RER, tenez une barre de l'autre main, et utilisez votre propre app d'une seule main. Si vous n'y arrivez pas, vos utilisateurs non plus.

La vraie question n'est pas « est-ce que c'est beau ? » mais « est-ce que ça marche quand on n'a qu'un pouce, une main, et 4 secondes d'attention ? ». Tant que la réponse est non, aucun redesign ne sauvera vos conversions.

Et si vous ne deviez corriger qu'une chose cette semaine : agrandissez vos zones de tap. C'est bête, c'est rapide, et c'est probablement l'endroit où vous perdez le plus de monde sans le savoir.

Marion Leconte

Marion Leconte

Marion Leconte est une experte reconnue en apprentissage automatique, en traitement du langage naturel et en visualisation de données. Elle met sa passion pour l'analyse de données au service de projets innovants, alliant rigueur scientifique et créativité. Son approche pédagogique et collaborative lui permet de rendre des concepts complexes accessibles à un large public.

Voir tous les articles →

Articles similaires