LFW

Blog · Réussir ses formulaires

Zones tactiles et claviers mobiles

Les bouts des doigts ne sont pas des curseurs. Tailles des zones tactiles, libellés qui acceptent le toucher, et les réglages de champ qui décident quel clavier apparaît : les détails mobiles qui déterminent en silence si votre formulaire est terminé.

Le formulaire a été approuvé sur un écran où personne ne le remplit

Les formulaires sont relus comme ils sont construits : sur un grand écran, à la souris, par quelqu'un à un bureau. Puis ils sont utilisés sur un téléphone, dans un couloir, d'un pouce, par quelqu'un qui était au milieu d'autre chose. Pour la plupart des organisations, la version téléphone n'est pas le cas limite. C'est là qu'est une grande partie du trafic, souvent la majorité. La version de bureau que votre équipe a approuvée est l'expérience minoritaire.

Un pointeur de souris est un pixel unique qui va exactement là où on le vise. Un bout de doigt est un instrument mou et imprécis d'environ un centimètre de large qui cache ce qu'il touche au moment du contact. Le toucher raté, la mauvaise case, le lien atteint à la place du bouton voisin : chaque frustration d'un formulaire mobile commence par une mise en page dimensionnée pour le pixel et livrée au bout du doigt.

Dimensionnez les zones pour des doigts, et laissez le libellé prendre le toucher

Les recommandations d'accessibilité mettent des chiffres précis sur ce dont un bout de doigt a besoin. Les repères courants tournent autour de 44 pixels pour une zone confortable, avec à peu près 24 comme plancher sous lequel les touchers ratés sont pour ainsi dire intégrés à la conception. Les cases à cocher et boutons radio natifs n'en approchent pas seuls ; sans aide, ils sont parmi les plus petits éléments interactifs du web, chargés d'un travail de précision sur le dispositif de saisie le moins précis que possèdent la plupart des gens.

Le correctif le plus ancien reste le meilleur, et il est gratuit : associez correctement le libellé au contrôle, et tout le libellé devient touchable. Le visiteur cesse de viser une petite case et touche simplement les mots « S'abonner à la lettre ». C'est une zone vingt fois plus grande, obtenue avec un balisage que le formulaire aurait dû avoir de toute façon.

C'est la même association qui fait fonctionner le libellé pour les lecteurs d'écran, ce qui est un schéma à remarquer : sur les formulaires, la construction accessible et la construction confortable s'avèrent encore et encore être la même construction.

L'espacement est l'autre moitié du dimensionnement. Deux zones de taille adéquate collées l'une à l'autre produisent encore des touchers sur le mauvais bouton, et l'endroit le plus coûteux pour cela est celui que tout formulaire possède : Envoyer à côté d'Annuler ou de Réinitialiser. Si un centimètre mal placé peut effacer le travail du visiteur, la mise en page (ou l'existence même de ce bouton de réinitialisation) mérite un second regard.

Votre balisage décide quel clavier apparaît

Quand un visiteur touche un champ sur un téléphone, le clavier logiciel qui monte n'est pas le fruit du hasard : il est choisi par le type déclaré du champ. Marquez le champ comme e-mail et le clavier arrive avec @ et le point sur son premier écran. Marquez-le comme téléphone et un pavé numérique apparaît. Laissez tout en champ texte générique et le visiteur reçoit le clavier générique pour tout, fouillant dans les couches de symboles pour taper une adresse que votre balisage aurait pu rendre plus facile de deux touches.

Les mêmes déclarations alimentent le remplissage automatique. Les champs qui disent ce qu'ils sont (nom, e-mail, organisation, adresse) laissent le navigateur proposer de les remplir avec ce qu'il sait déjà, réduisant le tronçon le plus fastidieux de tout formulaire mobile à un seul toucher. Pour un visiteur sur téléphone, c'est souvent la différence entre terminer maintenant et abandonner pour un « plus tard » qui ne vient pas.

Un piège de plus, propre au téléphone : certains navigateurs mobiles zooment toute la page quand le visiteur active un champ dont le texte est plus petit que ce que le navigateur juge lisible. Le visiteur finit de taper, la page est toujours agrandie et décentrée, et le formulaire semble soudain cassé. Garder le texte des champs à une taille confortable et honnête empêche le zoom de se déclencher. C'est un rappel que sur mobile, le petit texte n'est pas seulement difficile à lire ; il a des effets secondaires.

Désactivez l'aide qui nuit

Les claviers de téléphone sont livrés avec des réflexes réglés pour la prose : mettre une majuscule à la première lettre, corriger automatiquement les mots inconnus. Dirigés vers un champ de message, ces réflexes aident. Dirigés vers une adresse e-mail, ils la vandalisent : majuscule à la première lettre, « correction » d'un nom de famille ou d'un domaine inhabituel en mot du dictionnaire, fabriquant exactement le problème de mauvaise adresse par lequel cette série a commencé. Le visiteur a tapé avec soin ; le clavier a défait sa frappe.

Les champs qui contiennent des identifiants plutôt que des phrases, comme les e-mails, les identifiants de connexion et les numéros de référence, doivent dire au clavier de se retirer : pas de majuscule automatique, pas de correction automatique. C'est une décision d'une ligne par champ, invisible quand elle est bonne, et discrètement corrosive quand elle est mauvaise, parce que le visiteur remarque rarement la retouche du clavier avant d'appuyer sur Envoyer.

L'audit est dans votre poche

Rien de tout cela ne demande un laboratoire. Sortez votre téléphone, ouvrez votre propre formulaire et remplissez-le pour de vrai, au pouce seul, en marchant, sans complaisance. Chaque toucher raté, chaque mauvais clavier, chaque pincement pour zoomer sur une case est une note qu'un vrai visiteur a déjà prise en silence. Dix minutes de cela sont le test d'utilisabilité le moins cher que votre organisation fera jamais, et la liste de corrections qu'il produit est d'une concrétude rafraîchissante.

Cela boucle aussi la série jusqu'ici : les libellés qui restent visibles sont aussi les libellés qui prennent le toucher ; les envois qui préservent le travail comptent deux fois plus quand retaper signifie taper au pouce ; les erreurs qui s'expliquent comptent davantage sur un écran qui montre un champ à la fois. Le prochain épisode reste sur le thème de ce qui a l'air bien sur l'écran du designer : les contrôles natifs de formulaire sur un thème sombre, et la flèche du menu déroulant qui se fond dans le fond.

À lire ensuite

6 septembre 2026 8 minutes

Les quatre fichiers vers lesquels personne ne fait de lien

Chaque site web porte quatre fichiers texte qu'aucun visiteur ne voit jamais : robots.txt, sitemap.xml, security.txt et llms.txt. Les moteurs de recherche, les scanners de sécurité et les agents d'IA les lisent à chaque visite. Ce qu'est chacun d'eux, qui les lit vraiment, quoi y mettre, et la seule règle qui les garde tous sûrs. Nous avons repris cette liste sur notre propre site cette semaine et trouvé des manques, alors l'audit gratuit les vérifie désormais.

6 septembre 2026 6 minutes

Notre image principale disparaissait sur iPhone. Un bloqueur de publicités la cachait.

Pendant des semaines, l'image principale de trois de nos propres pages disparaissait une seconde et demie sur iPhone, au premier chargement seulement. Rien ne le reproduisait en laboratoire. Un relevé de terrain de cinquante lignes l'a trouvé en trois chargements de page : un bloqueur de publicités masquait tout élément dont la classe commençait par ad-.

Tous les articles →

Prefer to write?

Tell us what needs to work better.

Slow, fragile, hard to edit, missing a workflow. Say it plainly, and you'll get a straight answer, not a ticket number.

You'll get a straight answer, usually the same day.