Vous ouvrez votre site sur votre téléphone, dans le métro, une main cramponnée à la barre. Vous voyez un bouton. Vous tendez le pouce. Vous ratez le bouton. Vous appuyez sur la pub collée juste à côté. Voilà votre expérience utilisateur mobile : deux secondes de frustration, une fermeture d'onglet, et vous ne reviendrez probablement pas.
Ce scénario, je l'ai vécu des dizaines de fois en audit — et je l'ai aussi provoqué, à mes débuts, en livrant un menu qui exigeait le pouce d'un pianiste. Depuis, j'ai fait mon deuil d'une idée tenace : une expérience utilisateur mobile réussie n'est pas une version rétrécie du site desktop. C'est un objet différent, pensé pour une main, un pouce, une attention de trente secondes et un réseau qui vacille.
Points clés à retenir
- Un site mobile se conçoit à partir de la zone du pouce, pas du curseur.
- Trois seuils mesurables font 80 % du travail : LCP sous 2,5 s, CLS sous 0,1, cibles tactiles d'au moins 48 px.
- La barre d'onglets en bas bat le menu hamburger pour une navigation à 3-5 entrées ; au-delà, assumez le tiroir.
- L'accessibilité mobile (lecteur d'écran, contraste, alternatives aux gestes) n'est pas une case à cocher, c'est un test à refaire à chaque livraison.
- Un test utilisateur à 5 personnes attrape la majorité des blocages grossiers d'un parcours mobile.
- Ne copiez pas une app native par réflexe : pour beaucoup de besoins, une PWA bien faite suffit et coûte bien moins cher à maintenir.
Repenser le mobile à partir du pouce, pas des pixels
La première fois que j'ai dessiné une interface mobile sérieusement, j'ai commis une erreur classique : j'ai posé mes éléments là où ils tombaient bien, joliment alignés en haut de l'écran. Résultat, l'action principale — s'inscrire — se trouvait dans le coin supérieur droit. Inaccessible pour une main qui tient le téléphone. J'ai corrigé en déplaçant le bouton vers le bas, et le taux de clic sur cette action a grimpé de manière franche sur mes tests internes. Pas de magie : juste une ergonomie élémentaire qu'on oublie trop souvent.
La zone du pouce, ce concept qu'on devrait enseigner avant le CSS
Sur un écran tenu à une main, tout n'est pas équitable. Le tiers inférieur est confortable. Le centre demande un léger étirement. Les deux coins supérieurs exigent de déplacer la main — et à ce moment-là, l'utilisateur abandonne. Ce n'est pas une théorie : observez quelqu'un dans la rue.
Concrètement, sur les projets que j'ai accompagnés, cette règle a changé des choses simples :
- Le bouton d'action principal (acheter, valider, envoyer) descend en bas de l'écran, toujours dans la zone du pouce.
- La navigation principale se glisse en barre d'onglets fixe quand le site compte peu de sections — 3 à 5 maximum.
- Les actions destructrices (supprimer, se déconnecter) partent volontairement dans les recoins, pour limiter les erreurs.
- Les formulaires n'exigent jamais de glisser horizontalement sur plusieurs colonnes, ce qui est l'enfer au pouce.
Le menu hamburger en haut à gauche, on le garde pour les sites à arborescence large. Mais pour une application ou un e-commerce simple, il cache l'information au lieu de la montrer, et le coût en découverte se paye en clics perdus.
Le piège du desktop simplement rétréci
Sur les sites que j'audite, le même symptôme revient : la page d'accueil est une grille desktop compressée, avec des textes en 11 px et des boutons de 30 px de haut. Ça passe la revue visuelle d'un chef de projet pressé. Ça échoue à tous les tests réels. Un doigt moyen couvre environ 9 mm de diamètre ; une cible tactile confortable fait au minimum 48 px sur 48 px, avec un espacement suffisant entre deux éléments cliquables. En dessous, on devine, on rate, on rage.
Performance : les seuils qu'on peut vraiment mesurer
L'UX mobile, ce n'est pas qu'une histoire de boutons. C'est d'abord une question de patience. Un utilisateur qui attend trois secondes a déjà changé d'avis mentalement, même s'il regarde encore l'écran. La bonne nouvelle : la performance se mesure, et on sait où mettre la barre. Ces seuils viennent des Core Web Vitals, que Google utilise comme signaux d'expérience.
| Indicateur | Ce qu'il mesure | Seuil à viser | Ce qui le fait exploser |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Le temps d'affichage du plus gros élément visible | Moins de 2,5 secondes | Images non optimisées, polices bloquantes, JavaScript inutile en tête de page |
| CLS (Cumulative Layout Shift) | Les sauts visuels pendant le chargement | Moins de 0,1 | Images sans dimensions, publicités injectées, bannières qui poussent le contenu |
| INP (Interaction to Next Paint) | La réactivité aux interactions | Moins de 200 ms | Scripts lourds sur les événements tactiles, animations surchargées |
Sur un projet e-commerce que j'ai suivi, l'INP dépassait les 400 ms à cause d'un carrousel animé mal câblé. On a retiré le carrousel automatique. Le temps de réponse est redescendu, et le taux de rebond sur la fiche produit a baissé. Le carrousel était joli. Il coûtait des ventes.
Les outils que j'utilise réellement
Pas besoin d'un arsenal. Lighthouse intégré à Chrome et PageSpeed Insights suffisent pour un diagnostic de départ. Pour observer les comportements réels, un outil de heatmap et d'enregistrement de sessions comme Hotjar ou Clarity montre où les gens tapotent dans le vide. Et pour tester un prototype mobile, Maze ou même un simple test à distance avec cinq personnes donnent plus d'informations qu'une réunion de trois heures.
Faut-il une app native, une PWA ou du responsive ?
Question qu'on me pose systématiquement en début de projet, et à laquelle on répond souvent trop vite par « il nous faut une app ». Sauf que développer et maintenir deux applications (iOS et Android) coûte cher, très cher, et que la plupart des besoins fonctionnels des PME n'en ont pas l'usage.
Le tableau de décision honnête
| Approche | Quand elle s'impose | Quand elle est un mauvais choix |
|---|---|---|
| Responsive web | Site vitrine, blog, e-commerce standard, premiers tests de marché | Besoin d'accès hors ligne intensif, notifications push lourdes, matériel natif (Bluetooth, capteurs) |
| PWA | Service récurrent, contenu consulté souvent, notifications push simples, budget contraint | Besoin de performance graphique élevée (jeux, réalité augmentée), fonctionnalités iOS limitées |
| App native | Usage quotidien intensif, dépendance au matériel, monétisation par les stores | Le projet est un test, l'audience est majoritairement occasionnelle, l'équipe est petite |
Mon avis tranché : pour 80 % des projets que je croise, une PWA bien conçue fait le travail et évite de se retrouver avec deux bases de code à maintenir. Les 20 % restants relèvent d'un besoin vraiment spécifique — et si vous n'êtes pas déjà sûr d'appartenir à cette catégorie, vous n'y appartenez probablement pas.
L'accessibilité mobile, l'angle mort que presque personne ne teste
Sur les sites que j'ai audités, la même histoire : personne n'a jamais ouvert le site avec un lecteur d'écran. On me répond souvent « l'accessibilité, on verra plus tard ». Sauf que l'accessibilité mobile recoupe des usages très ordinaires : une personne qui conduit et écoute, une personne âgée qui monte la taille du texte système, une personne daltonienne qui distingue mal les états d'un bouton.
Les trois vérifications que je fais à chaque livraison
- Le contraste respecte le seuil WCAG AA (4,5:1 pour le texte normal, 3:1 pour les gros caractères). C'est mesurable en deux clics dans les outils du navigateur.
- Chaque élément interactif a un libellé lisible par un lecteur d'écran, pas une icône muette.
- Aucun geste (glisser, pincer) n'est la seule façon d'accomplir une action essentielle — il faut toujours une alternative tap.
- Le zoom n'est pas désactivé dans la balise viewport, parce que bloquer le zoom est une violence faite à une partie des utilisateurs.
Ces vérifications prennent vingt minutes. Elles évitent des procès en ergonomie que personne ne veut vivre.
Tester, pas deviner : la méthode qui change tout
Le vrai différenciateur entre un site mobile médiocre et un site mobile qui retient, ce n'est ni le budget ni la taille de l'équipe. C'est la discipline de tester avec de vraies personnes. Sur les projets que j'ai suivis, la première session à cinq testeurs révèle presque toujours un blocage que l'équipe ne soupçonnait pas — un libellé ambigu, un bouton invisible, un parcours à trois étapes qui pourrait en compter une.
Le protocole en cinq questions
Je ne cherche pas à évaluer si les gens « aiment » le site. Je cherche à savoir s'ils atteignent leur objectif. Cinq tâches suffisent pour la première passe :
- Trouvez le prix d'un produit.
- Ajoutez-le au panier.
- Modifiez la quantité dans le panier.
- Trouvez comment nous contacter.
- Revenez à la page d'accueil sans utiliser le bouton retour du téléphone.
Ce que je mesure est simple : taux de réussite, temps par tâche, hésitations visibles (pauses, retours en arrière, tapotements dans le vide). Les hésitations sont plus instructives que les échecs : elles montrent ce que l'interface laisse deviner au lieu de montrer.
Les erreurs que je vois le plus souvent (et que j'ai commises)
Ce n'est pas une liste exhaustive. C'est ce qui revient dans un audit sur deux.
- Placer l'action principale en haut de l'écran. Je l'ai fait. Le bouton était magnifique. Personne ne cliquait.
- Charger des pop-ups de newsletter dès la première seconde. Le taux de fermeture est proche de 100 % sur mobile, et j'ai vu des abandons de panier liés à ça.
- Multiplier les polices décoratives. Trois familles de caractères sur un mobile, c'est trois familles de trop.
- Ignorer les états de chargement et d'erreur. Un formulaire qui n'affiche rien pendant cinq secondes sur un réseau faible perd l'utilisateur.
- Oublier les petites connexions. Une bonne partie des utilisateurs mobiles naviguent sur un réseau dégradé, pas en 5G parfaite.
Ce dernier point mérite qu'on s'y attarde. Concevoir pour un réseau parfait, c'est concevoir pour une minorité. Concevoir pour un réseau qui vacille et un doigt maladroit, c'est concevoir pour tout le monde.
Ce que je retiens après des années d'audits mobile
Améliorer l'expérience utilisateur mobile, ce n'est pas une somme de recettes indépendantes. C'est un changement de posture : passer de « comment je présente mon contenu » à « comment quelqu'un va-t-il le recevoir avec une main, un pouce et trente secondes d'attention ».
Le reste — les seuils de performance, les tailles de cible, les tests à cinq personnes — ce sont des garde-fous. Utiles, mais secondaires. Le vrai levier, c'est d'accepter que l'écran mobile n'est pas un écran, c'est un geste. Et tant qu'on conçoit pour l'écran et pas pour le geste, on rate la cible. Parfois de trois millimètres. Parfois de tout un business.
