Typographie des formulaires et champs de saisie

Il existe un échec de formulaire si courant qu’il porte désormais un nom : le formulaire où le placeholder tient lieu d’étiquette. Chaque champ est une jolie boîte vide avec un texte gris pâle à l’intérieur — « Adresse e-mail », « IBAN », « Numéro de TVA » — et dès que l’utilisateur clique et tape, l’étiquette disparaît. Remplissez six champs, faites-vous interrompre, revenez, et le formulaire n’est plus qu’un mur de boîtes anonymes : vérifier ce que vous avez saisi par rapport à ce qui était demandé devient impossible sans vider les champs pour revoir leurs étiquettes. Sur une page de paiement ou un virement bancaire, ce n’est pas de la friction — ce sont des paniers abandonnés et de l’argent envoyé à la mauvaise adresse.

La typographie des formulaires est réglée pour le balayage et la vérification plutôt que pour la lecture continue : texte des champs à 16px minimum, étiquettes au-dessus du champ à la taille du corps ou un cran en dessous dans une graisse moyenne, texte d’aide et d’erreur petit mais pas en dessous d’environ 13px, erreurs signalées par autre chose que la couleur, et monospace pour tout ce qui se vérifie caractère par caractère. Chaque règle de cette liste existe parce que les erreurs de formulaire, contrairement aux mélectures de prose, coûtent du temps et de l’argent réels. Cet article fait partie de notre guide de typographie.

Pourquoi les formulaires ont-ils besoin d’une typographie différente du corps de texte ?

La prose se lit dans le flux — l’œil suit le contexte et anticipe les mots à venir. Les formulaires se lisent dans un tout autre mode : balayer jusqu’au champ suivant, lire une courte étiquette, produire son propre texte, puis vérifier ce que l’on a produit. C’est l’étape de vérification qui est inhabituelle. Relire les caractères que vous venez de taper est plus difficile que de lire de la prose composée, car il n’y a aucun contexte de phrase pour anticiper — rien dans un IBAN ne laisse deviner si le chiffre suivant devrait être un 4 ou un 9, donc chaque caractère doit être décodé individuellement — un travail de lisibilité (déchiffrer les caractères) plutôt que de confort de lecture.

Cela fait des formulaires le terrain le plus à risque de la typographie. Un paragraphe un peu trop gris coûte du confort ; un numéro de compte mal vérifié coûte un ticket de support, un paiement échoué, ou pire. Les règles ci-dessous sont des idées typographiques ordinaires poussées plus loin, parce que le prix de l’échec est plus élevé.

Quelle taille de police pour les champs de formulaire ?

Seize pixels, au minimum, pour le texte à l’intérieur du champ. Deux raisons — l’une mécanique, l’autre perceptuelle.

La raison mécanique, c’est le piège du zoom sous iOS : quand la taille de police d’un champ ayant le focus est inférieure à 16px, Safari sur iPhone zoome sur toute la page pour compenser. La mise en page saute, le champ se décale, et l’utilisateur doit dézoomer après chaque champ. Ce comportement est ancien, et régler le texte des champs à 16px ou plus est la solution évidente — le navigateur impose en pratique un plancher pour le texte que vous êtes censé y saisir.

La raison perceptuelle, c’est la lecture de vérification. Le corps de texte survit à 14px parce que le contexte fait une partie du travail ; votre IBAN fraîchement tapé à 14px ne bénéficie d’aucune aide de ce genre, et la vérification caractère par caractère a besoin de la taille supplémentaire. Les équipes qui construisent des outils internes réservés au bureau descendent parfois les champs à 14px sans dommage — mais partout où un téléphone peut atteindre la page, 16px est le plancher.

Où placer les étiquettes — au-dessus, à côté ou dans le champ ?

Au-dessus du champ, aligné à gauche avec lui. Les recommandations d’ergonomie fondées sur la manière dont l’œil parcourt les formulaires — reflétées dans le tutoriel du W3C sur l’étiquetage des formulaires — privilégient les étiquettes en haut : l’œil descend une seule colonne, et chaque paire étiquette–champ est saisie comme une unité. Les étiquettes à côté du champ imposent un balayage en zigzag et un écart variable disgracieux entre l’étiquette et la boîte ; elles cassent aussi en premier sur les écrans étroits.

Les étiquettes dans le champ — le motif du placeholder évoqué en ouverture — échouent structurellement plutôt que stylistiquement : l’étiquette est détruite par l’acte même d’y répondre. Les placeholders ont encore un rôle légitime comme indications de format complémentaires (« [email protected] ») — mais jamais comme seul nom d’un champ.

Comment styliser les étiquettes, le texte d’aide et les erreurs ?

• Étiquettes : taille du corps ou un cran en dessous, graisse moyenne. Sur une échelle de 16px, cela veut dire 16px ou 14px en graisse 500 — assez présentes pour se repérer, assez discrètes pour ne pas concurrencer ce que l’utilisateur tape. L’appartenance se joue dans l’espacement, pas dans le style : une étiquette doit être visiblement plus proche de son propre champ que du champ au-dessus (le principe de proximité issu de la perception — ce qui est plus proche se lit comme appartenant ensemble). Si l’étiquette est à 8px du champ, le champ doit être à 20px ou plus de l’étiquette suivante.
• Texte d’aide : petit, mais pas en dessous d’environ 13px. Un cran en dessous du corps est naturel ; sous environ 13px, le texte qui explique les formats et les cas limites devient le texte que personne ne peut lire.
• Texte d’erreur : même plancher, et jamais la teinte seule. Texte rouge, plus une icône, plus un message — les personnes daltoniennes perdent les signaux de teinte pure, donc l’erreur doit aussi se repérer par la forme et la position (jamais la couleur seule, en tenue de formulaire). Une graisse moyenne l’aide à s’imposer.
• Le texte saisi lui-même : encre à plein contraste. Un nombre surprenant de formulaires en production affichent le texte tapé par l’utilisateur dans le même gris pâle que les placeholders — les propres mots de l’utilisateur se lisent alors comme une suggestion plutôt qu’une réponse, et la vérification devient plus difficile sans raison. Le texte saisi est du contenu, pas une indication.

À quoi ressemble un champ de formulaire sur une échelle de 16px ?

À partir d’une échelle de base à 16px (ratio 1,333, deux notes par intervalle → 12, 14, 16, 18, 21…), voici l’anatomie complète d’un champ :

L’espacement vient du même système : 8px entre l’étiquette et le champ, 20–24px entre les champs, et chaque interligne un multiple de l’unité de ligne de base de 8px — ainsi un long formulaire s’empile sur un seul rythme vertical au lieu d’accumuler une dérive champ après champ.

Vous pouvez inspecter ces niveaux en typographie vivante : ouvrez les trois niveaux de texte du formulaire dans Scale Composer — étiquette, champ et aide tirés d’une même échelle de 16px, chacun avec sa propre graisse et son interlettrage — et tapez vos propres étiquettes dans le spécimen pour les juger à taille réelle.

Quand un champ doit-il être en monospace ?

Chaque fois que le mode de lecture est caractère par caractère : codes de confirmation, IBAN, clés de licence, jetons d’API, numéros de carte. La raison est le pas fixe — chaque caractère occupe la même largeur, donc le cinquième caractère se trouve au même endroit dans toutes les chaînes, les chiffres peuvent être comparés colonne par colonne, et un caractère manquant change visiblement la longueur de la chaîne. Les polices proportionnelles sont optimisées pour les formes des mots ; la vérification ne lit pas des mots. Associez le monospace à un regroupement (SE35 5000 0000 …) et vous offrez à l’œil de l’utilisateur la même structure que celle qu’utilise le validateur de la banque.

Construisez la variante dense

Les formulaires de back-office échangent de l’air contre des lignes à l’écran, et cette compression est un bon test pour voir quelles règles plient : les étiquettes peuvent descendre à 12px medium avec un interlettrage légèrement ouvert, les interlignes se resserrent d’un cran de ligne de base, les écarts entre champs rétrécissent de 24px vers 16px — tandis que le texte d’aide se maintient à 14px (le cran suivant de l’échelle, 12px, franchit le plancher d’environ 13px) et que le texte saisi reste à 16px, parce que le comportement de zoom et la lecture de vérification se moquent de la densité de votre tableau de bord. Pour voir quelles règles se sont comprimées et lesquelles ont refusé, chargez la variante dense de la même anatomie de champ.