Bouton mobile trop petit, corriger taille et espacement

Un bouton mobile trop petit ne se juge pas dans Figma à 100 % de zoom. Il se juge sur un vrai téléphone, avec un pouce, une main parfois occupée et une page qui bouge légèrement au défilement. Si l’utilisateur doit viser, recommencer ou zoomer pour toucher un CTA, le problème n’est pas seulement esthétique : il touche l’accessibilité, la confiance et la capacité du parcours à aller au bout.

La correction ne consiste pas à grossir tous les boutons. Le bon audit vérifie la cible tactile réelle, l’espacement entre actions, le libellé, le contraste, l’état actif et la position dans la zone atteignable. Un pictogramme peut rester visuellement fin si sa zone cliquable est plus large ; à l’inverse, un bouton haut mais collé à un lien voisin reste fragile. Cette distinction évite les interfaces mobiles lourdes où tout a été agrandi sans hiérarchie.

Testez avant de redessiner : le clavier, le zoom et le pouce changent vite la perception d’une cible.

Quelle taille viser pour un bouton mobile ?

Pour une action importante, une cible autour de 44 à 48 px reste un repère très pratique. Apple parle historiquement en points, Material en dp, et les WCAG distinguent plusieurs niveaux de taille selon le critère visé. Ces chiffres ne décrivent pas toujours le dessin visible du bouton : ils décrivent surtout la zone réellement activable, c’est-à-dire l’espace où le doigt peut appuyer sans précision excessive ni risque de toucher une action voisine.

La nuance est importante. Une icône de 20 px peut être acceptable si le bouton autour mesure 44 px. Un lien texte peut rester discret si sa ligne, sa hauteur et son espacement permettent une activation confortable. À l’inverse, un CTA de 44 px de haut peut rester mauvais si son texte est minuscule, si sa largeur force une cible étroite ou s’il est collé à un autre bouton. Il faut donc mesurer la cible, mais aussi observer le contexte immédiat.

En audit UX, je classe donc rarement un bouton “bon” ou “mauvais” uniquement avec une règle CSS. Je regarde d’abord son rôle : action principale, action secondaire, icône système, lien dans une liste, bouton de fermeture, bouton panier, filtre, pagination. Plus l’action est critique, irréversible ou fréquente, plus la marge tactile doit être généreuse.

Dans un site de PME, le seuil minimal n’est qu’un filet de sécurité. La vraie question est plus concrète : quel bouton coûte cher s’il est raté ? Un bouton “envoyer la demande”, “confirmer le créneau” ou “payer” mérite plus d’espace qu’un lien “lire la suite”. Les composants de navigation peuvent rester compacts, mais les étapes de conversion doivent éviter la précision obligatoire. C’est cette hiérarchie qui empêche de transformer une page mobile en suite de gros rectangles sans nuance.

Pourquoi l’espacement compte autant que la hauteur

Un bouton de bonne taille peut provoquer des erreurs s’il est trop proche d’une autre action. Le cas le plus fréquent se trouve dans les listes mobiles : supprimer, modifier, favori, ouvrir, filtrer. Chaque élément paraît clair en maquette, mais le doigt recouvre une partie de l’écran et l’utilisateur ne voit plus exactement ce qu’il touche. Ce n’est pas un détail de finition : c’est souvent la différence entre une action fluide et un retour arrière frustrant.

Le risque augmente avec les actions opposées. Placer “Annuler” et “Valider” dans une même zone compacte est plus dangereux que rapprocher deux liens informatifs. Dans un formulaire, un bouton principal trop proche d’un lien de retour ou d’une case à cocher peut créer des clics accidentels, surtout quand le clavier virtuel réduit la hauteur visible.

Sur mobile, l’espace blanc n’est pas une perte. C’est une protection contre les gestes approximatifs. Cette protection profite aussi aux utilisateurs pressés, aux personnes avec une motricité moins précise, aux écrans très grands utilisés à une main et aux pages qui s’affichent avec un zoom navigateur.

Les erreurs les plus coûteuses apparaissent souvent après une interaction : menu déroulant ouvert, filtre appliqué, message d’erreur affiché, clavier visible. Un espacement confortable au repos peut devenir insuffisant quand la page se resserre. C’est pourquoi il faut tester les états réels du parcours, pas seulement la première vue propre. Le bouton qui passe le contrôle visuel initial peut échouer dès qu’un message d’erreur pousse l’action suivante contre un lien secondaire.

Le correctif CSS ne doit pas déformer l’interface

La correction la plus saine consiste souvent à élargir la zone cliquable plutôt que l’icône elle-même. Sur un bouton classique, on travaille avec min-height, padding, gap, line-height, display: inline-flex, align-items: center et justify-content: center. Sur une icône, on ajoute une enveloppe bouton claire, une largeur minimale et une hauteur minimale, afin que l’interface garde son équilibre visuel sans sacrifier la manipulation tactile.

Pour le code, partez d’un CTA simple. Il doit garder une hauteur minimale, un centrage stable et assez d’espace vertical.

.button {
  min-height: 44px;
  padding: 0 18px;
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 8px;
}

.action-list {
  display: grid;
  gap: 12px;
}

Pour une icône seule, évitez le simple SVG cliquable. Le SVG peut rester à 20 ou 24 px, mais le bouton parent doit porter la cible tactile, le focus clavier, l’état hover/active et le nom accessible. C’est aussi plus robuste pour les lecteurs d’écran et les tests automatisés. Cette enveloppe clarifie le rôle du composant pour le code comme pour l’utilisateur.

Le correctif doit aussi rester stable au changement de contenu. Un libellé plus long, une traduction, un prix plus large ou une icône ajoutée ne doivent pas réduire la cible. Si le composant casse dès que le texte change, le problème n’est pas seulement mobile : c’est un composant fragile qui reviendra dans chaque nouvelle page.

Cette étape doit rester cohérente avec le système de design. Si vous corrigez un seul bouton à la main, le prochain composant reproduira le défaut. Mieux vaut définir des tokens de taille, des espacements minimums et des variantes de bouton utilisables par toute l’équipe.

Évitez aussi le faux correctif qui consiste à ajouter seulement du padding horizontal. Le bouton paraît plus large, mais la hauteur reste parfois trop faible et l’espacement vertical ne change pas. Un correctif complet agit sur la hauteur minimale, le rythme entre composants, les zones d’icônes et le comportement quand plusieurs boutons s’empilent sur petit écran.

Contraste, libellé et état actif font partie du problème

Un bouton mobile peut être assez grand et rester inutilisable parce qu’il ne ressemble pas à une action. Un gris trop pâle, une bordure trop fine, un texte vague ou un état désactivé mal distingué créent une hésitation. Sur une page de conversion, cette hésitation suffit parfois à faire relire tout le formulaire, puis à douter de l’étape suivante alors que le problème vient seulement d’un signal visuel trop faible.

Le libellé doit annoncer l’action réelle : “Recevoir le devis”, “Valider le créneau”, “Ajouter au panier”, “Télécharger le guide”. Les mots génériques comme “OK”, “Continuer” ou “Envoyer” ne sont pas interdits, mais ils doivent être portés par un contexte immédiat très clair. Sinon, le bouton oblige l’utilisateur à deviner la conséquence du geste, ce qui ralentit surtout les parcours de demande, devis ou paiement où la confiance dépend du moindre signal.

L’état actif est tout aussi important. Après le toucher, l’interface doit répondre : couleur, spinner, désactivation temporaire, message de confirmation ou passage à l’étape suivante. Sans retour visible, l’utilisateur retouche, recharge, abandonne ou crée une double soumission.

Le contraste ne concerne pas uniquement le texte. Il concerne aussi la différence entre action principale, action secondaire et élément désactivé. Si un bouton secondaire ressemble au bouton principal, l’utilisateur hésite. Si un bouton désactivé ressemble à un bouton cliquable, il insiste. La page doit rendre la décision attendue évidente sans forcer la lecture de toute l’interface.

Tester sur appareil réel, pas seulement dans DevTools

DevTools est utile pour repérer les tailles CSS, mais il ne remplace pas un test sur appareil. Un bouton correct dans l’émulateur peut devenir gênant avec une coque, une main gauche, un écran plus étroit, un clavier virtuel, une bannière cookie ou un zoom système. Le test au pouce révèle souvent ce que la maquette cache, parce qu’il combine portée, visibilité, fatigue du geste et contexte réel de consultation.

Testez les pages qui déclenchent une décision : formulaire, tunnel d’achat, filtre produit, prise de rendez-vous, menu mobile, recherche interne, pagination, modale et bannière. Si l’utilisateur doit toucher deux fois, corriger sa visée ou fermer une modale par une croix minuscule, le problème est avéré. Le bon test consiste à suivre le parcours jusqu’à l’état final, pas à valider uniquement le premier écran visible.

Sur un audit rapide, je fais toujours au moins deux passages : un premier en lecture normale, un second en cherchant volontairement l’erreur. Je touche près des bords, j’ouvre le clavier, je remonte une liste, je teste les icônes seules, puis je vérifie que le focus clavier reste visible. Cette démarche met en évidence les zones tactiles théoriques qui ne fonctionnent plus dès que l’usage devient réel.

1. Tester le bouton principal avec le pouce, téléphone tenu d’une seule main.
2. Afficher le clavier virtuel pour vérifier les boutons de formulaire.
3. Créer volontairement une erreur pour observer les messages et actions voisines.
4. Ouvrir les menus, filtres, modales et bandeaux qui modifient la zone visible.
5. Comparer un petit écran, un grand écran et un niveau de zoom augmenté.

La décision finale ne se limite pas à “44 ou 48 px”. Elle consiste à repérer les endroits où le site demande trop de précision à un utilisateur mobile. Là où l’action a une valeur business ou une valeur d’accessibilité, la cible doit être plus généreuse que le minimum. Là où l’action est secondaire, elle doit rester lisible, espacée et prévisible.

La règle doit rester simple à transmettre : une action critique doit être visible, atteignable, espacée et confirmée par un retour d’état.

La méthode simple pour prioriser les corrections

Commencez par les pages critiques. Le menu secondaire peut attendre.

Traitez d’abord les actions qui bloquent un parcours : bouton d’envoi, validation de panier, prise de rendez-vous, choix de créneau, filtre de recherche, fermeture de modale. Ensuite, regardez les liens et icônes fréquents : menu, retour, favori, suppression, édition, pagination. Les corrections purement décoratives viennent après, sauf si elles se répètent dans un composant partagé.

Cette priorisation évite de passer une journée sur des détails peu vus alors qu’un bouton critique bloque les demandes. Elle aide aussi à parler avec un développeur : on ne demande pas “agrandir tous les boutons”, on demande de sécuriser les actions à risque, de créer une règle commune et de vérifier les composants réutilisés. Le ticket devient plus clair, plus testable et moins dépendant d’un ressenti subjectif.

Une bonne correction est souvent discrète. L’utilisateur ne remarque pas que le bouton est plus confortable ; il réussit simplement son action du premier coup. Pour une PME, c’est précisément l’intérêt : moins d’erreurs, moins d’abandons évitables, une interface perçue comme plus sérieuse et un parcours mobile plus robuste, sans promettre une hausse automatique de conversion. Le gain attendu se vérifie ensuite dans les formulaires complétés, les erreurs évitées et les retours utilisateurs.

En pratique, je conseille de documenter la règle dans le design system ou dans un fichier CSS commun : taille minimale des boutons, espace entre actions, variante icône, retour actif et règle de test sur vrai téléphone. Sans cette trace, le correctif reste ponctuel. Avec elle, la qualité tactile devient une habitude de conception.

Un bouton fiable se remarque surtout quand il ne fait pas hésiter : il donne assez d’espace au geste, assez de sens au libellé et assez de retour visuel pour que l’utilisateur continue sans se demander s’il a touché le bon élément.