UX mobile : pourquoi adapter l’expérience et pas seulement réduire la maquette ?

Un téléphone ne s’utilise pas comme un ordinateur miniature

Une souris permet de viser précisément un petit élément. Un doigt, beaucoup moins.

Un clavier physique laisse tout l’écran disponible. Sur mobile, le clavier virtuel peut masquer presque la moitié de l’interface.

Une comparaison entre quatre offres fonctionne facilement lorsqu’elles sont côte à côte. Sur un téléphone, ces quatre offres vont probablement défiler l’une après l’autre.

Ces différences ont des conséquences concrètes sur la conception.

Il faut parfois revoir :

• la taille des actions ;
• l’ordre des contenus ;
• le fonctionnement d’un menu ;
• la manière d’afficher une comparaison ;
• la quantité d’informations visibles à un instant donné.

web.dev rappelle d’ailleurs qu’un responsive design moderne doit prendre en compte les caractéristiques du périphérique, notamment les capacités de survol et de pointage.

Voir : web.dev – Les bases du responsive web design.

Le petit écran oblige à choisir ce qui compte vraiment

Sur desktop, plusieurs informations peuvent partager le premier écran sans vraiment se gêner.

Une image, une accroche, quelques arguments, deux boutons et une navigation complète peuvent rester visibles en même temps.

Sur mobile, il faut faire des choix.

Imaginons une page de service qui commence par :

• une grande illustration ;
• un H1 ;
• une phrase de présentation ;
• deux CTA ;
• trois bénéfices.

Si l’illustration passe automatiquement en premier, elle peut occuper une grande partie du premier écran avant que l’utilisateur ait compris de quoi parle la page.

Dans ce cas, je préfère souvent faire passer le H1 et la promesse avant l’image.

Ce choix dépend évidemment du rôle de l’image. Sur une fiche produit, elle peut au contraire constituer l’information la plus importante.

C’est exactement le type de décision que j’aborde dans mon article sur la hiérarchie visuelle.

L’ordre des contenus ne doit pas être laissé au hasard

Prenons une section desktop très classique : une photographie à gauche et, à droite, un titre, un texte puis un bouton.

Lorsque les deux colonnes passent en une seule, plusieurs ordres restent possibles :

Image → titre → texte → CTA

ou :

Titre → texte → CTA → image

ou encore :

Titre → image → texte → CTA.

Les trois variantes tiennent sur mobile. Leur impact sur la compréhension n’est pourtant pas le même.

Si la photographie n’est qu’un élément d’ambiance, je peux décider de la placer après l’information principale. Si elle montre précisément le produit ou le résultat attendu, son rôle change.

Je préfère prendre cette décision dès les wireframes plutôt que découvrir le problème une fois toute la maquette desktop finalisée.

Adapter la navigation sans tout cacher

Une navigation desktop peut afficher six ou sept entrées sans problème.

Sur téléphone, cette place n’existe plus.

Le premier réflexe est souvent de ranger l’ensemble dans un menu hamburger.

Cela fonctionne bien pour une grande partie de la navigation, mais certaines actions méritent parfois de rester visibles.

Un restaurant peut garder « Réserver ». Un site de service peut conserver « Demander un devis ». Une boutique peut rendre le panier immédiatement accessible.

Je pars donc du parcours utilisateur plutôt que de la seule contrainte de largeur.

Quelle action est suffisamment importante pour rester accessible sans ouvrir le menu ?

Le menu hamburger n’a pas vocation à tout absorber

Le menu hamburger est une convention comprise par une grande partie des utilisateurs. Je n’ai donc aucun problème avec son usage.

Ce qui me gêne davantage est d’y cacher mécaniquement tout ce qui ne tient plus dans le header.

Imaginons un site de réservation avec quatre entrées principales et un bouton « Réserver ».

La version mobile :

Logo | Réserver | Menu

peut être plus efficace que :

Logo | Menu

avec la réservation cachée au milieu de huit liens.

Le menu doit servir la navigation. Il ne doit pas devenir le débarras de la version desktop.

Les actions prioritaires doivent rester faciles à atteindre

Une action importante peut être parfaitement visible sur desktop et devenir difficile à retrouver dès que les contenus s’empilent.

C’est fréquent sur les pages longues.

Un CTA placé à droite d’une introduction peut se retrouver, après adaptation, beaucoup plus bas que prévu.

Je vérifie donc sa position dans le parcours réel :

• après quelle information apparaît-il ?
• faut-il faire défiler beaucoup de contenu avant de le retrouver ?
• existe-t-il une autre action visuellement plus forte à proximité ?

La solution n’est pas forcément de dupliquer le bouton partout. Parfois, un deuxième CTA placé après une section de réassurance suffit.

Concevoir pour le doigt et pas seulement pour le pointeur

Un petit pictogramme de fermeture peut sembler très clair dans Figma lorsqu’on le sélectionne avec une souris.

Sur un téléphone, toucher précisément cette croix dans l’angle d’une modal peut devenir beaucoup moins agréable.

Le problème concerne aussi les liens proches, les cases à cocher, les flèches de carrousel ou certaines icônes d’action.

L’espace autour de l’élément compte presque autant que sa taille.

Deux petites actions éloignées peuvent rester utilisables. Les mêmes actions collées l’une à l’autre deviennent beaucoup plus risquées.

Quelle taille prévoir pour les zones tactiles ?

WCAG 2.2 introduit au niveau AA le critère 2.5.8 Target Size (Minimum).

Il demande, sauf exceptions prévues par le critère, une cible d’au moins 24 × 24 pixels CSS ou un espacement équivalent permettant d’éviter les activations accidentelles.

Le détail est disponible dans Understanding Target Size (Minimum).

Le niveau AAA prévoit une exigence renforcée à 44 × 44 pixels CSS dans le critère 2.5.5.

Je préfère néanmoins éviter une lecture purement comptable de ces valeurs.

Un bouton de 24 pixels placé juste à côté d’un autre bouton de 24 pixels peut toujours être inconfortable. Le contexte compte.

Une information importante ne doit pas dépendre du hover

Le hover est pratique sur ordinateur. Il peut révéler un sous-menu, un texte complémentaire ou une action sur une carte.

Sur tactile, le comportement n’est pas équivalent.

Si une information essentielle n’apparaît qu’au passage de la souris, une partie des utilisateurs risque simplement de ne jamais la voir.

Il faut alors prévoir un autre fonctionnement : information visible directement, clic, accordéon ou bouton dédié.

Les media queries permettent aussi d’identifier certaines capacités du périphérique grâce à des caractéristiques comme hover et pointer.

Voir la documentation MDN sur les media queries CSS.

Cette distinction évite aussi un raccourci fréquent : petit écran ne signifie pas forcément tactile, et tactile ne signifie pas forcément petit écran.

Faut-il supprimer du contenu sur mobile ?

Pas par défaut.

Une personne qui consulte un site depuis son téléphone n’a pas forcément un besoin d’information plus faible.

Si une information est indispensable pour comprendre une offre ou faire un choix, elle reste probablement indispensable sur mobile.

En revanche, sa présentation peut changer.

Une FAQ très longue peut utiliser des accordéons. Une fiche technique peut être divisée en sections plus faciles à parcourir. Une image purement décorative peut disparaître si elle occupe une place disproportionnée.

Je préfère donc revoir la manière d’accéder au contenu avant de commencer à supprimer des informations utiles.

Quand une page devient trop dense sur petit écran

Une grille de six cartes paraît assez légère lorsqu’elle occupe deux lignes sur desktop.

Sur mobile, ces six cartes deviennent six blocs successifs. Si chacune contient une image, un titre, trois lignes de texte et un bouton, la page s’allonge rapidement.

Il peut être utile de simplifier les cartes, de réduire les contenus secondaires ou de regrouper certains éléments.

Le scroll horizontal peut aussi être intéressant pour une série de réalisations ou de catégories, à condition que l’utilisateur comprenne qu’il existe des éléments hors écran.

Je n’utilise pas les accordéons comme solution universelle. Masquer chaque section derrière un clic finit également par alourdir l’expérience.

Adapter la typographie sans la rendre minuscule

Un H1 de 72 pixels peut fonctionner parfaitement sur une grande maquette.

Conservé tel quel sur mobile, il peut occuper cinq ou six lignes et repousser toute information utile sous la ligne de flottaison.

La taille doit donc évoluer.

L’interlignage aussi.

En revanche, réduire fortement tous les textes pour gagner de la place est rarement une bonne idée.

Une typographie de petite taille, peu contrastée et avec un interlignage serré reste difficile à lire, quel que soit le support.

Églantine détaille ces choix dans son article consacré à la typographie web et à l’association des polices.

Une image mobile mérite parfois un autre cadrage

Une bannière panoramique peut contenir une personne à droite et beaucoup d’espace à gauche pour accueillir un titre.

Réduite en conservant exactement le même cadrage, la personne peut devenir minuscule.

Une version mobile peut avoir besoin d’un recadrage différent, voire d’une autre image.

La même réflexion vaut pour :

• les captures d’écran ;
• les photographies de produit ;
• les infographies ;
• les illustrations contenant du texte.

Il faut aussi éviter de télécharger sur un petit écran un fichier bien plus lourd que nécessaire. La qualité visuelle ne dépend pas du fait d’envoyer systématiquement l’image desktop complète.

Grilles et cartes : empiler n’est pas toujours la meilleure solution

Trois cartes côte à côte deviennent naturellement trois cartes verticales.

Cette solution est souvent très bonne.

Mais pas toujours.

Pour une série de dix témoignages ou quinze catégories, l’empilement peut transformer une zone courte en très longue section.

Je peux alors envisager :

• un défilement horizontal ;
• une sélection initiale plus courte ;
• un bouton pour afficher la suite ;
• une autre structure de contenu.

Le choix dépend de ce que l’utilisateur doit réellement faire avec ces cartes.

Les tableaux demandent un traitement particulier

Un tableau de comparaison est justement intéressant parce qu’il permet de regarder plusieurs informations simultanément.

Le transformer automatiquement en une succession de cartes peut lui faire perdre cet avantage.

Selon le cas, je peux préférer :

• un scroll horizontal ;
• une sélection des colonnes à comparer ;
• une vue simplifiée ;
• un tableau complet accessible dans un second niveau.

WCAG prévoit d’ailleurs des exceptions au principe de reflow pour des contenus dont la compréhension nécessite réellement une disposition bidimensionnelle, comme certains tableaux, cartes ou interfaces complexes.

Voir : W3C – Understanding Reflow.

Les formulaires sont plus exigeants sur mobile

Un formulaire demande déjà de la concentration sur desktop.

Sur mobile, chaque champ implique en plus un clavier qui apparaît, des changements de focus et davantage de scroll.

C’est pour cela que les champs inutiles deviennent particulièrement visibles.

Demander un téléphone, une adresse complète et un budget précis dans une simple prise de contact peut transformer un parcours rapide en tâche assez longue.

Je détaille ce travail dans mon article consacré à l’UX des formulaires web.

Sur mobile, les bonnes pratiques restent les mêmes, mais leurs conséquences sont souvent plus fortes.

Le clavier virtuel change réellement l’interface

On l’oublie facilement sur une maquette.

Dès que l’utilisateur sélectionne un champ, le clavier virtuel peut occuper une grande partie de l’écran.

Le champ suivant peut sortir de la zone visible. Une instruction placée plus haut peut disparaître. Un bouton sticky peut se retrouver très proche du clavier.

Les types de champs HTML permettent aussi de proposer des claviers plus adaptés selon l’information demandée : e-mail, téléphone, nombre ou URL.

Ce n’est pas spectaculaire dans une maquette.

À l’usage, quelques gestes évités à chaque champ changent réellement le confort du formulaire.

Les éléments sticky peuvent vite prendre trop de place

Un bouton « Ajouter au panier » fixé en bas de l’écran peut être très pratique sur une longue fiche produit.

Le problème apparaît lorsqu’il partage l’écran avec :

• un header fixe ;
• un bandeau de consentement ;
• un chat flottant ;
• un autre CTA fixe.

Sur un écran déjà petit, ces éléments peuvent occuper une part importante de la surface utile.

Je garde donc les composants sticky pour les actions dont l’accès permanent apporte réellement quelque chose.

Le contenu doit pouvoir se réorganiser

Le critère WCAG 2.2 1.4.10 Reflow demande, pour la majorité des contenus et hors exceptions prévues, qu’une page puisse être utilisée à une largeur équivalente à 320 pixels CSS sans perte d’information ou de fonctionnalité et sans imposer un scroll dans deux directions.

Le détail du critère est disponible dans Understanding Reflow.

Cette règle répond notamment aux besoins des personnes qui agrandissent fortement l’interface.

Elle rejoint aussi directement les problématiques mobiles.

Une bonne mise en page doit être capable de passer de trois colonnes à deux puis une, de laisser les textes revenir à la ligne et de déplacer certains composants sans faire disparaître une fonction.

UX mobile et accessibilité se rejoignent souvent

Une zone tactile trop petite peut gêner une personne qui utilise son téléphone en marchant. Elle peut devenir beaucoup plus problématique pour quelqu’un qui possède une précision motrice limitée.

Un texte trop petit gêne beaucoup d’utilisateurs. Une personne ayant besoin de zoomer rencontrera encore plus rapidement les limites de l’interface.

Beaucoup de bonnes pratiques se recoupent donc :

• cibles suffisamment grandes ;
• contrastes lisibles ;
• contenus capables de se réorganiser ;
• labels explicites ;
• navigation cohérente ;
• absence de dépendance exclusive au hover.

Les WCAG 2.2 en français permettent d’aller plus loin sur ces critères.

TooNetCreation traite également le sujet dans l’article « Accessibilité web et design : non, un site accessible n’est pas forcément moche ».

Sur mobile, la performance se ressent immédiatement

Une vidéo lourde en hero, plusieurs webfonts et de grandes images peuvent sembler acceptables sur une connexion rapide et un ordinateur récent.

Le comportement peut être très différent sur un smartphone moins puissant ou une connexion mobile instable.

Je regarde donc chaque élément lourd avec une question simple :

« Qu’est-ce qu’il apporte réellement à cette page ? »

Une animation peut être intéressante si elle explique une interaction ou renforce clairement l’identité. Si elle ralentit simplement l’apparition du contenu, son intérêt est beaucoup plus discutable.

La même logique vaut pour les images et les vidéos.

La page UX/UI Design de TooNetCreation relie d’ailleurs directement ergonomie, responsive et performance dans la conception de l’interface.

Choisir les breakpoints à partir du contenu

Il est pratique de travailler avec quelques valeurs connues pour organiser un projet.

Mais un breakpoint devrait surtout apparaître lorsque la composition commence à se dégrader.

Le menu ne tient plus. Deux cartes deviennent trop étroites. Un titre se casse de manière difficile à lire. Une colonne secondaire prend trop de place.

C’est à ce moment qu’une autre disposition devient nécessaire.

MDN recommande également de ne pas construire toute la stratégie responsive autour de dimensions correspondant à quelques appareils précis.

Voir : MDN – Responsive web design.

Les appareils changent. Le contenu reste un bien meilleur indicateur.

Penser le comportement des composants, pas seulement trois maquettes

Trois écrans Figma — mobile, tablette, desktop — ne décrivent pas tout ce qui se passe entre 390 et 1440 pixels.

Je préfère donc définir ce que fait chaque composant lorsque l’espace diminue.

Une carte horizontale peut devenir verticale.

Un header complet peut perdre quelques entrées avant de basculer vers un menu mobile.

Un bloc composé d’un texte et d’une image peut inverser son ordre.

Un CTA peut passer sous le texte.

Cette logique facilite aussi la discussion avec le développement : on décrit des comportements plutôt qu’une série de captures figées.

Exemple : transformer une page de service pour le mobile

Imaginons un hero desktop composé de deux colonnes.

À gauche : le H1, une phrase de présentation et deux CTA.

À droite : une grande illustration.

Sous ce hero, trois bénéfices sont alignés sur une même ligne.

Version mobile automatique

Si les colonnes sont simplement empilées dans leur ordre HTML, on peut obtenir :

Illustration → H1 → texte → CTA principal → CTA secondaire → bénéfices.

L’utilisateur commence alors par une grande image sans encore connaître le sujet de la page.

Version mobile retravaillée

Je pourrais plutôt organiser :

H1 → promesse → CTA principal → illustration recadrée → bénéfices → CTA secondaire.

Le contenu n’a pas changé.

L’expérience, oui.

La deuxième version donne d’abord les informations nécessaires pour comprendre la page, puis utilise l’image comme soutien.

Exemple : réorganiser une fiche produit

Une fiche produit desktop peut afficher la galerie à gauche pendant que prix, variantes, disponibilité, livraison et bouton d’achat restent visibles à droite.

Sur mobile, tout passe dans une seule colonne.

Je cherche alors à suivre les questions de l’utilisateur.

1. Quel est ce produit ?
2. À quoi ressemble-t-il ?
3. Combien coûte-t-il ?
4. Est-il disponible ?
5. Quelle variante dois-je choisir ?
6. Comment l’acheter ?

L’ordre de la fiche peut être construit à partir de cette progression.

On retrouve ici la logique du parcours utilisateur : le support change, mais la personne essaie toujours d’atteindre un objectif précis.

12 erreurs fréquentes en UX mobile

1. Empiler automatiquement toutes les colonnes

L’ordre desktop n’est pas forcément le meilleur ordre mobile.

2. Réduire tous les éléments proportionnellement

Certains composants doivent changer de structure.

3. Cacher l’action principale dans le menu

Une réservation ou un panier mérite parfois de rester visible.

4. Utiliser des cibles tactiles trop petites

Une petite icône précise à la souris peut devenir pénible au doigt.

5. Coller deux actions sensibles

« Modifier » et « Supprimer » ne devraient pas être faciles à confondre.

6. Dépendre du hover

Une information nécessaire doit rester accessible sans souris.

7. Réduire les textes pour gagner de la place

Le petit écran ne justifie pas une mauvaise lisibilité.

8. Transformer chaque section en accordéon

Un écran plus compact n’est pas forcément un écran où tout doit être caché.

9. Empiler des dizaines de cartes

La longueur de la page peut devenir disproportionnée.

10. Multiplier les éléments fixes

Ils réduisent rapidement la surface réellement disponible.

11. Oublier le clavier virtuel

Le formulaire ne ressemble plus du tout à la maquette lorsque le clavier occupe la moitié de l’écran.

12. Valider la version mobile uniquement dans Figma

Une maquette regardée sur un écran de bureau ne reproduit ni le tactile ni les conditions d’utilisation d’un téléphone.

Ma méthode pour travailler une interface mobile

1. Je définis l’objectif de la page

Je veux savoir ce que l’utilisateur vient chercher avant de travailler l’ordre des blocs.

2. Je hiérarchise les informations

Le petit écran oblige à distinguer ce qui doit apparaître immédiatement de ce qui peut attendre.

3. Je construis l’ordre mobile

Je ne me contente pas du comportement automatique des colonnes.

4. Je regarde chaque composant séparément

Navigation, cartes, tableaux, formulaires, images et CTA n’ont pas toujours besoin de la même adaptation.

5. Je vérifie le tactile

Je regarde la taille des actions et surtout ce qui se trouve autour.

6. Je teste la saisie

Le clavier virtuel et l’autocomplétion doivent être pris en compte dans les formulaires.

7. Je contrôle le reflow

Le contenu doit rester accessible lorsque la largeur diminue ou que l’utilisateur agrandit la page.

8. Je surveille les éléments fixes

Chaque composant sticky prend une partie du viewport.

9. Je vérifie le poids de la page

Les médias et animations sont évalués selon leur utilité réelle.

10. Je teste sur de vrais appareils

C’est souvent à ce moment que les petits défauts deviennent évidents.

Cette démarche fait partie du travail de conception UX/UI et expérience utilisateur chez TooNetCreation.

Comment auditer rapidement un site sur mobile ?

Je préfère commencer par des tâches concrètes plutôt que parcourir le site au hasard.

Par exemple :

• trouver une prestation ;
• demander un devis ;
• acheter un produit ;
• retrouver les coordonnées ;
• remplir un formulaire.

Pendant le parcours, je note les endroits où je dois réfléchir inutilement.

Le menu est-il clair ? Le CTA principal est-il visible ? Les textes sont-ils confortables ? Les boutons sont-ils faciles à toucher ? Le clavier masque-t-il certaines informations ?

Je regarde aussi si une fonctionnalité qui semblait évidente sur desktop est devenue difficile à trouver.

Un audit mobile efficace peut être assez court. Quelques tâches bien choisies donnent déjà beaucoup d’informations.

FAQ sur l’UX mobile

Quelle différence entre responsive design et UX mobile ?

Le responsive design adapte techniquement la mise en page aux différentes tailles d’écran. L’UX mobile s’intéresse également à l’ordre des contenus, au tactile, aux formulaires, à la navigation et aux conditions réelles d’utilisation.

Un site responsive est-il forcément agréable sur mobile ?

Non. Une page peut ne plus déborder tout en conservant de petits boutons, une mauvaise hiérarchie ou un parcours inutilement long.

Faut-il toujours travailler en mobile first ?

Non. C’est une méthode très utile pour clarifier les priorités, mais certains projets peuvent commencer par d’autres formats. Le point important est de traiter le mobile suffisamment tôt.

Quelle taille prévoir pour un bouton tactile ?

WCAG 2.2 prévoit au niveau AA un critère de taille minimale de cible à 24 × 24 pixels CSS, avec plusieurs exceptions. Le contexte et l’espacement entre les actions restent également importants.

Faut-il supprimer du contenu sur mobile ?

Seulement lorsqu’il n’apporte réellement rien dans ce contexte. Dans beaucoup de cas, il est préférable de revoir sa présentation ou son ordre.

Le menu hamburger est-il mauvais pour l’UX ?

Non. Il permet de regrouper efficacement une navigation. Certaines actions très importantes peuvent toutefois gagner à rester visibles directement dans le header.

Pourquoi éviter les interactions basées uniquement sur le hover ?

Parce qu’un écran tactile ne reproduit pas le survol de la souris. Une fonction essentielle doit donc disposer d’une autre manière d’être déclenchée ou découverte.

Qu’est-ce que le reflow ?

Le reflow correspond à la capacité du contenu à se réorganiser lorsque l’espace disponible diminue, sans perdre d’information ni imposer inutilement un scroll horizontal et vertical.

Comment tester correctement une interface mobile ?

Les outils de simulation sont utiles, mais ils doivent être complétés par des tests sur de vrais téléphones, avec le tactile, le clavier virtuel et les principales tâches du parcours.

Sources et ressources

• MDN – Responsive design : principes de conception des mises en page adaptatives.
• MDN – Requêtes média CSS : adaptation selon le viewport et certaines caractéristiques du périphérique.
• MDN – Accessibilité mobile : problématiques d’accessibilité liées aux appareils mobiles.
• web.dev – Les bases du responsive web design : viewport, responsive design et modes d’interaction.
• W3C – Understanding Reflow : règles relatives au réagencement du contenu.
• W3C – Target Size (Minimum) : critère WCAG 2.2 concernant la taille minimale des cibles.
• W3C – Target Size (Enhanced) : recommandation renforcée concernant la taille des cibles.
• W3C – WCAG 2.2 en français : traduction française des règles pour l’accessibilité des contenus web.

À lire également sur toonetcreation

• UX et UI : quelles différences et pourquoi les deux sont indispensables à un site web ?
• Qu’est-ce qu’un wireframe ? Définition, utilité et méthode pour concevoir un site web
• Hiérarchie visuelle : comment organiser une page web pour guider l’utilisateur ?
• Comment construire un parcours utilisateur efficace sur un site web ?
• UX des formulaires web : comment réduire les frictions et les abandons ?
• Typographie web : comment choisir et associer les polices d’un site sans sacrifier la lisibilité ?
• Conception UX/UI et expérience utilisateur
• Accessibilité web et design : non, un site accessible n’est pas forcément moche