Concevoir une interface mobile intuitive : 7 principes clés à maîtriser

Concevoir une interface mobile intuitive : ce que le pouce décide avant votre œil

La dernière fois qu'un client m'a dit « c'est intuitif, on comprend tout de suite », je lui ai tendu mon téléphone. Il a ouvert l'appli, posé le pouce, et il a raté le bouton. Trois fois. La quatrième, il a ri jaune. Voilà tout le problème : on juge une interface avec les yeux, alors qu'on s'en sert avec les doigts. Concevoir une interface mobile intuitive commence par accepter cette contradiction, et ça n'a rien d'un détail cosmétique.

Sur mon dernier projet, une application de prise de rendez-vous pour des cabinets médicaux, j'ai refait l'écran de confirmation sept fois. Sept. Pas parce que le design était laid, mais parce que sur le terrain, dans une salle d'attente bruyante, les gens appuyaient systématiquement à côté. Je vais vous raconter ce que ces sept itérations m'ont appris, y compris les deux qui ont été de vrais ratés.

UI et UX mobile : pourquoi la confusion vous coûte cher

Un directeur marketing m'a demandé un jour de « rendre l'appli plus jolie pour améliorer l'expérience ». J'ai refusé de commencer par là. Non pas par principe, mais parce que j'avais déjà fait l'erreur inverse : passer deux semaines à polir des dégradés et des ombres pendant que personne n'arrivait à retrouver son panier.

L'interface utilisateur, c'est la surface : la couleur, la typo, l'espacement, l'icône. L'expérience utilisateur, c'est le trajet : est-ce que je trouve ce que je cherche, est-ce que je comprends où j'en suis, est-ce que je peux revenir en arrière sans paniquer. Les deux comptent, mais elles ne se réparent pas au même endroit.

Une interface lisible n'est pas forcément intuitive

Un écran peut être magnifique et illisible d'usage. J'ai vu des maquettes parfaites, validées en réunion sur un grand écran, qui devenaient inutilisables sur un écran de 5,5 pouces en plein soleil. Le contraste choisit pour faire « premium » disparaissait dès qu'on sortait du bureau.

Une règle simple que j'applique maintenant : je conçois d'abord en noir, blanc et une seule couleur d'accent, à taille réelle sur un téléphone, debout, dans un couloir. Si ça tient là, on habille ensuite. Si ça ne tient pas, aucun dégradé ne sauvera la structure.

Le test des cinq secondes

Montrez votre écran d'accueil à quelqu'un pendant cinq secondes, retirez-le, demandez : « qu'est-ce que tu peux faire ici ? ». Si la personne hésite plus de deux secondes, votre hiérarchie visuelle est en cause, pas votre charte graphique. Sur mes derniers projets, ce test a fait virer plus de blocs que n'importe quel audit complet.

Zones tactiles et portée du pouce : ce qui se joue vraiment

Voici le chiffre que je répète à chaque début de projet. 44×44 px, c'est la cible minimale recommandée par Apple pour une zone tactile. Côté Material Design, la consigne descend à 48×48 dp. Pourquoi deux valeurs proches mais distinctes ? Parce que ce sont deux façons de compenser la même réalité : votre doigt, lui, n'a pas une précision au pixel.

Le centimètre de contact réel d'un doigt humain fait à peu près la taille d'un grain de raisin. Vous avez déjà essayé d'appuyer sur une miette de pain avec un grain de raisin ? C'est exactement ce que ressent un utilisateur face à un bouton de 24 pixels.

Tailles et conséquences concrètes

Taille de la zone tactile	Ce que ça donne à l'usage	Quand c'est acceptable
Moins de 30 px	Taux d'erreur élevé, appuis ratés systématiques	Jamais pour une action principale
32 à 43 px	Fonctionne, mais il faut viser. Fatigue au bout de quelques minutes	Actions secondaires, rarement utilisées
44 à 47 px	Confort standard sur iOS	Actions principales, la plupart des cas
48 px et plus (dp)	Confort standard sur Android, tolérant aux gros pouces	Boutons de validation, formulaires

Sur l'appli de rendez-vous, mes premiers boutons de confirmation faisaient 36 px de haut. Visuellement, ça respirait. À l'usage, je perdais environ un utilisateur sur cinq à cette étape. Pas parce qu'il ne comprenait pas, mais parce qu'il appuyait deux millimètres trop bas. En passant à 48 px, sans rien changer d'autre au parcours, cette perte est tombée à un niveau que je ne comptais même plus.

Le pouce ne va pas partout

Il y a une zone d'écran que votre pouce atteint sans effort, et une autre qu'il atteint en réajustant toute la main. Sur un grand téléphone tenu à une main, le quart supérieur gauche de l'écran est presque inaccessible. C'est là que je vois le plus souvent les boutons de retour et les actions principales. Une aberration.

La réponse la plus efficace que j'ai trouvée : les actions fréquentes en bas, l'information en haut. Sur un écran de panier e-commerce, ça veut dire valider la commande dans la zone basse, et afficher le récapitulatif en haut. Le pouce ne remonte jamais pour confirmer, et personne ne se casse le poignet.

Le processus concret pour concevoir une interface mobile intuitive

Oubliez la liste de dix principes qu'on trouve partout. Voilà comment je travaille, dans l'ordre, avec ce qui marche et ce qui ne marche pas.

Commencer par les tâches, pas par les écrans

Je liste d'abord ce que l'utilisateur doit pouvoir faire, avec des verbes. « Consulter une disponibilité. Réserver un créneau. Annuler. » Chaque verbe devient un parcours. C'est seulement après que je dessine des écrans. Quand je saute cette étape, je produis des écrans jolis qui ne correspondent à aucune tâche réelle. Ça m'est arrivé, et j'ai perdu une semaine à redessiner.

Dessiner dans le désordre, assumé

Sur papier, je dessine l'écran final en premier. Puis je remonte à l'écran précédent. Puis à celui d'avant. Cette méthode à rebours évite l'erreur classique : empiler des étapes parce que « ça fait plus complet ». En partant de la fin, chaque écran doit justifier pourquoi il existe.

Prototyper pour de vrai, pas pour la réunion

Un prototype cliquable sur un téléphone, tenu à une main, est mille fois plus utile qu'un PDF de maquettes. Je teste avec des gens qui n'ont pas participé au projet, cinq personnes suffisent pour faire remonter la majorité des blocages. Pas besoin d'un panel de cent.

Les erreurs qui me coûtent le plus cher

• Trop d'actions sur un même écran. Sur un projet, j'avais mis six boutons d'action sur la page d'accueil. Les utilisateurs ne savaient pas lequel choisir et abandonnaient. Je suis passé à deux, avec un parcours principal clair.
• Des libellés qui décrivent la fonction technique au lieu de l'intention. « Soumettre » au lieu de « Prendre rendez-vous ». Le second se comprend sans réfléchir.
• Le fameux menu hamburger tout en haut à gauche, dans la zone que le pouce n'atteint pas. Pratique pour gagner de la place, désastreux pour la fréquence d'usage des sections principales.
• Placer une action destructrice (« Supprimer ») juste à côté d'une action fréquente. Un appui mal placé, et l'utilisateur perd ses données. Ça n'arrive jamais en démo, ça arrive toujours en vrai.

Franchement, la plupart de ces erreurs ne viennent pas d'un manque de talent. Elles viennent d'un excès de confiance : on croit savoir comment l'utilisateur va se comporter, alors qu'on n'a jamais regardé quelqu'un s'en servir pour de vrai.

Comment mesurer si une interface est vraiment intuitive

« Intuitif » n'est pas un compliment, c'est une mesure. Et si vous ne la mesurez pas, vous ne saurez jamais si vos choix fonctionnent.

Les indicateurs que je suis systématiquement

• Le temps jusqu'à la première action : combien de secondes avant que l'utilisateur appuie sur quelque chose d'utile. Au-delà de dix secondes sur un écran d'accueil, il y a un problème.
• Le taux de complétion d'une tâche : quel pourcentage de vos testeurs arrivent au bout sans aide. En dessous de 80 %, l'écran a besoin d'être retravaillé.
• Le taux d'abandon par étape : où les gens lâchent. C'est souvent sur l'écran le plus « simple », celui qu'on a négligé.
• Le nombre d'appuis ratés, que je mesure en observant directement, uniquement pour les actions principales.
• Le score SUS (System Usability Scale), un questionnaire court qui donne une note globale. Au-dessus de 68, on est dans la moyenne haute. En dessous de 50, il faut tout reprendre.

Accessibilité mobile : les chiffres qu'on oublie

Un contraste insuffisant et une police trop petite excluent une partie des utilisateurs, pas seulement ceux qui ont un handicap visible. Les seuils WCAG demandent un rapport de contraste de 4,5:1 pour du texte normal, et 3:1 pour du texte large. Une taille de police en dessous de 16 px devient pénible en plein soleil, même pour un œil parfait.

Et il y a un point que je vois rarement traité sérieusement : un écran conçu pour VoiceOver ou TalkBack doit rester compréhensible quand on ne voit rien. Sur un projet de gestion de dossiers, j'ai passé une demi-journée à réordonner les libellés pour que le lecteur d'écran en donne un sens. Sans ça, l'appli était inutilisable pour une partie de nos utilisateurs, et je ne l'avais pas vu pendant des semaines.

E-commerce, santé, finance : trois terrains, trois contraintes

Un e-commerce a le luxe de la séduction : il peut guider par l'envie, jouer sur les images, retarder l'action pour créer du désir. La santé et la finance, non. Leur contrainte commune, c'est que l'erreur coûte cher, et ça change tout dans la conception.

E-commerce : la friction contrôlée

Sur un site marchand, une petite friction bien placée peut augmenter la conversion. Un récapitulatif clair avant paiement rassure. Mais attention à ne pas transformer ça en parcours à rallonge. Mon repère : si l'utilisateur doit revenir en arrière plus d'une fois dans un tunnel d'achat, la friction est devenue un obstacle.

Santé et finance : la confiance avant tout

Dans ces secteurs, l'utilisateur est souvent stressé quand il utilise l'appli. Pas de place pour l'ambiguïté. Les libellés doivent dire exactement ce qui va se passer, les actions destructrices doivent demander une confirmation, et chaque étape doit être réversible quand c'est possible. J'ai vu un formulaire de paiement où un mauvais libellé faisait croire à un engagement alors qu'il s'agissait d'un simple devis. L'utilisateur a demandé un remboursement sur la base de cette confusion. La refonte du libellé a suffi à faire disparaître le problème.

Ce qui reste quand on a tout oublié

Une interface mobile intuitive n'est pas une interface sans options. C'est une interface où l'utilisateur n'a pas à réfléchir pour agir. Le jour où quelqu'un utilise votre appli sans qu'on lui explique quoi que ce soit, et qu'il ne râle pas, vous avez gagné.

Le reste, la couleur, la typo, les animations, c'est de l'habillage. Nécessaire, mais secondaire. Ce qui compte d'abord, c'est la taille des cibles, l'ordre des priorités, et la vérité que vous acceptez quand vous regardez quelqu'un se cogner contre votre écran. La prochaine fois que vous concevez une interface, posez votre téléphone sur la table, tendez-le à quelqu'un qui n'a jamais vu votre projet, et observez. Vous apprendrez plus en dix minutes qu'en trois réunions de design.

Et si vous ne deviez retenir qu'une chose : le pouce décide avant l'œil. Concevez pour lui, pas pour votre écran de bureau.