Meilleures pratiques de conception de formulaires : 10 règles pour le web et le mobile
Les 10 règles pour concevoir des formulaires qui convertissent. Analyses réelles des flux d'inscription de Notion, Tally et Mercury, plus des patterns mobile-first qui fonctionnent vraiment.
Meilleures pratiques de conception de formulaires : 10 règles pour le web et le mobile
Le coût d'un mauvais formulaire
Un mauvais formulaire est une taxe stratégique sur chaque euro dépensé pour amener quelqu'un sur la page. Les taux de complétion pour les formulaires d'inscription, de paiement et d'onboarding tournent autour de 12 % quand les frictions sont présentes. Supprimez les frictions et ce chiffre dépasse les 50 %.
L'écart n'est presque jamais lié au texte ou au branding. C'est l'affaire des dix règles, appliquées avec cohérence.
Les formulaires Salesforce à 30 champs existent parce que quelqu'un a transposé un schéma de base de données sur une page et a appelé ça un formulaire. L'utilisateur n'a pas signé pour ça. Il est venu pour le produit, et votre logique de qualification vous a coûté le lead.
Règle 1 : une colonne, une tâche par écran
Une colonne, toujours. Les layouts à plusieurs colonnes paraissent efficaces dans une grille Figma et font chuter les taux de complétion à l'écran.
L'œil lit de gauche à droite et s'attend à une continuité. Quand les champs se divisent en deux colonnes, l'utilisateur doit décider quel chemin suivre, et cette micro-décision ajoute une friction avant même qu'il ait tapé un seul caractère.
Le flux d'inscription de Notion est une seule colonne centrée avec un champ mis en avant à la fois sur mobile. Le formulaire paraît rapide parce qu'il ne demande qu'une chose. C'est la règle.
Règle 2 : la position du label compte plus que son style
Les labels vont au-dessus du champ. Pas à l'intérieur, pas sur le côté. Au-dessus, toujours visible.
Le texte de placeholder utilisé comme label disparaît dès que l'utilisateur commence à taper. À ce stade, il doit vider le champ pour se rappeler ce qu'il remplit. Le flux d'onboarding de Mercury utilise des labels persistants au-dessus de chaque champ sur chaque étape, pour que le contexte ne soit jamais perdu en cours de saisie.
Voir en direct sur mercury.com
Les labels flottants, qui remontent depuis la position du placeholder au focus, sont un compromis acceptable, mais ils exigent un contraste précis et un timing soigné pour être accessibles. Dans le doute, placez le label au-dessus et laissez-le là.
La recherche UX sur le positionnement des labels est couverte en profondeur dans notre guide des méthodes de recherche UX.
Règle 3 : l'ordre des champs suit la réalité de l'utilisateur, pas le schéma de la base de données
La séquence de vos champs doit correspondre à la façon dont une personne pense à la tâche, pas à la façon dont les ingénieurs ont structuré le modèle de données.
Un formulaire de paiement qui demande l'adresse de livraison avant de confirmer le panier impose à l'utilisateur la charge du contexte. Stripe Checkout, la référence canonique pour l'UX des formulaires de paiement hébergés, séquence le formulaire en trois étapes :
- Email (qui êtes-vous)
- Paiement (comment allez-vous payer)
- Adresse (où ça va)
C'est la séquence qu'un humain raisonnable utiliserait en personne. Quand la base de données dicte l'ordre des champs, on obtient des formulaires qui demandent un code postal avant un pays, ou un titre de poste avant un nom d'entreprise.
Règle 4 : validez en ligne, jamais à la soumission
Validez le champ dès que l'utilisateur le quitte, pas quand il clique sur soumettre.
La validation à la soumission signifie que l'utilisateur remplit un formulaire de dix champs, clique sur le bouton, et se retrouve face à un mur d'erreurs rouges. Chaque erreur est une tâche de correction, et chaque tâche de correction risque de le perdre définitivement. La validation en ligne, déclenchée au blur, signale l'erreur avant que l'utilisateur ne passe à la suite.
La connexion Apple ID valide le format de l'email au blur et confirme la disponibilité du compte avant même que le bouton de soumission ne devienne actif. Ce séquençage prévient deux catégories d'erreurs à la fois. Les patterns d'interaction derrière cela sont couverts dans notre guide du design de microinteractions.
Règle 5 : mobile-first signifie claviers mobiles
Chaque type de champ doit invoquer le bon clavier. C'est 80 % du design de formulaires mobiles.
Si un champ demande un numéro de téléphone et que le clavier texte par défaut apparaît, le formulaire est cassé avant que l'utilisateur ait tapé quoi que ce soit. Utilisez inputmode="numeric" sur les champs numériques, type="email" pour faire apparaître la touche @, et inputmode="decimal" pour les prix. iOS et Android supportent tous les deux la gamme complète des modes de saisie.
Le clavier est le dispositif de saisie principal sur mobile. En spécifier le mauvais transforme un formulaire visuellement correct en une expérience frustrante.
| Type de champ | Attribut HTML correct |
|---|---|
type="email" | |
| Téléphone | type="tel" |
| Nombre entier | inputmode="numeric" |
| Décimal / prix | inputmode="decimal" |
| URL | type="url" |
| Recherche | inputmode="search" |
Pour les fondamentaux mobile-first dans lesquels s'inscrivent ces patterns, voir les fondamentaux du responsive web design.
Règle 6 : progression, microcopy et le problème des longs formulaires
Si le formulaire nécessite plus de cinq champs, montrez à l'utilisateur où il en est dans le flux.
Le flux de réservation multi-étapes d'Airbnb affiche un indicateur de progression avec des étapes nommées tout au long. Les utilisateurs qui peuvent voir qu'ils sont à 60 % ont sensiblement plus de chances de finir que ceux qui n'ont aucun point de référence.
Tally adopte une approche différente pour ses formulaires intégrables : une question à la fois avec une barre de progression persistante en haut, qui surpasse systématiquement les longs formulaires sur une seule page dans leurs tests utilisateurs documentés.
La microcopy fait le même travail. "Étape 2 sur 4" est plus honnête qu'une simple barre de progression. "Nous avons besoin de cela pour vérifier votre identité" est plus utile qu'un champ sensible sans label.
Règle 7 : les messages d'erreur sont des instructions, pas des accusations
Rédigez les messages d'erreur à l'impératif, pas sous forme d'accusation.
"Ce champ est obligatoire" est une accusation. "Saisissez votre adresse email pour continuer" est une instruction. L'utilisateur sait déjà que quelque chose s'est mal passé. Ce dont il a besoin, c'est de la solution.
Le meilleur texte d'erreur nomme la condition exacte et l'action exacte : "Le mot de passe doit contenir au moins 8 caractères et inclure un chiffre." Stripe Checkout fait cela précisément. Le message apparaît au blur, nomme le problème, et disparaît dès que la condition est résolue.
Pas d'état rouge persistant. Ça fonctionne, tout simplement.
Règle 8 : l'autofill est une fonctionnalité, pas une réflexion après coup
L'attribut autocomplete indique au navigateur exactement quoi remplir. Utilisez-le sur chaque champ.
Un formulaire de paiement avec des attributs autocomplete corrects prend environ 12 secondes à compléter sur un téléphone avec des données enregistrées. Sans eux, le même formulaire prend deux minutes parce que l'utilisateur tape tout manuellement. Cet écart de 108 secondes, c'est là que vit la majeure partie des abandons de paiement sur mobile, et il ne coûte rien à combler. Le guide des bibliothèques de composants UI explique comment intégrer ces attributs dans les composants de formulaire de votre design system pour qu'ils ne manquent jamais.
| Champ | Valeur autocomplete |
|---|---|
email | |
| Prénom | given-name |
| Nom | family-name |
| Téléphone | tel |
| Adresse | street-address |
| Ville | address-level2 |
| Code postal | postal-code |
| Numéro de carte | cc-number |
| Expiration de carte | cc-exp |
Règle 9 : le bouton de soumission décide de tout
Le bouton de soumission est le contrat. Son libellé, son état et sa position signalent si l'utilisateur peut faire confiance à ce qui se passe ensuite.
Un bouton grisé sans explication indique à l'utilisateur que le formulaire est cassé, mais pas pourquoi. C'est une impasse. Un bouton libellé "Soumettre" ne dit rien à l'utilisateur sur ce à quoi il s'engage.
"Créer mon compte", "Obtenir mon essai gratuit" et "Commencer à construire" sont tous plus honnêtes. Désactivez le bouton uniquement quand vous pouvez expliquer la raison dans l'interface. Tally utilise un texte de bouton spécifique à l'action à chaque étape dans son constructeur de formulaires, ce qui contribue directement à ses taux de complétion au-dessus de la moyenne pour les flux B2B intégrés.
Règle 10 : testez avec de vrais pouces, de vraies données, une vraie latence
Tester un formulaire sur un navigateur desktop via un wifi rapide ne vous apprend rien d'utile sur son fonctionnement réel.
Testez sur un appareil Android milieu de gamme sur une connexion 4G avec des données de longueur réelle dans chaque champ :
- Un nom avec un caractère accentué
- Une adresse avec un numéro d'appartement sur la deuxième ligne
- Un email de 22 caractères
- Un prénom d'un seul caractère
Les cas limites réels cassent des formulaires qui paraissent propres dans Figma. La latence réelle révèle si les appels de validation bloquent la saisie ou s'exécutent de façon asynchrone. Cette distinction est invisible dans un simulateur de navigateur et catastrophique sur un téléphone avec deux barres de signal.
Besoin d'un audit de formulaire sur votre flux d'inscription, de paiement ou d'onboarding ? Brainy réalise l'audit complet des dix règles sur de vrais écrans, de vraies données et de vrais chiffres de conversion.
Où les designers livrent encore les pires formulaires
Les pires formulaires en production aujourd'hui partagent trois patterns :
- Formulaires de lead commercial enterprise : écrans de qualification Salesforce à 30 champs avec des sélecteurs "chiffre d'affaires annuel" obligatoires et aucune validation en ligne
- Flux d'onboarding multi-étapes qui ne sauvegardent pas la progression : un appel téléphonique à l'étape 7 sur 9 renvoie l'utilisateur à l'étape 1
- Flux de paiement construits avant que le mobile ne soit primaire, jamais reconstruits : chaque champ numérique utilise encore
type="text"parce que "ça marche bien sur desktop"
Les choix d'état d'erreur dans ces trois cas échouent également souvent aux exigences de contraste ; les patterns de contraste de couleur accessible corrigent ce point de défaillance spécifique.
Le fil conducteur dans les trois cas : le formulaire a été conçu pour le système, pas pour la personne qui le remplit. La correction est la même.
Appliquez les dix règles. Commencez par le mobile. Laissez la base de données gérer son propre schéma.
FAQ
Combien de champs un formulaire doit-il avoir ?
Le moins possible par rapport au résultat requis. Le bon nombre est celui où en supprimer un de plus casserait le produit. Chaque champ ajouté réduit le taux de complétion. Partez de zéro et n'ajoutez que ce qui est obligatoire.
Dois-je utiliser des formulaires multi-étapes ou une seule page ?
Pour plus de cinq champs, le multi-étapes surpasse presque toujours la page unique. L'exigence est une progression visible. Sans elle, les formulaires multi-étapes sont moins performants que les formulaires sur une seule page parce que l'utilisateur n'a aucune idée de la durée du parcours. Nommez les étapes et montrez où il en est dans la séquence.
Quelle est la meilleure façon d'indiquer les champs obligatoires ?
Marquez les champs optionnels, pas les obligatoires. Si la plupart des champs sont obligatoires (ce qui devrait être le cas, compte tenu de la règle ci-dessus), marquer chaque champ avec un astérisque rouge est un bruit visuel.
Marquez les exceptions. "Optionnel" à côté d'un champ est une information significative. Un astérisque à côté de chaque champ ne l'est pas.
Comment gérer les exigences de mot de passe sans pénaliser l'utilisateur ?
Affichez les exigences avant que l'utilisateur commence à taper, pas après un échec. Une petite checklist qui s'active à mesure que chaque condition est remplie est plus performante qu'un mur d'erreurs post-soumission. Apple ID et la plupart des flux d'authentification actuels utilisent ce pattern. Le retour est en temps réel, positif, et jamais punitif.
La largeur du champ communique-t-elle quelque chose ?
Oui, et les utilisateurs le lisent. La largeur du champ signale la longueur attendue de la saisie. Un champ court signale une réponse courte. Un champ pleine largeur signale une réponse plus longue.
Faites correspondre la largeur du champ à la longueur de saisie attendue quand la mise en page le permet. Un champ de code postal pleine largeur ressemble à une erreur. Une zone de texte pour une adresse postale ressemble à une exagération. Faites correspondre le conteneur au contenu attendu.
Qu'est-ce qui cause le plus d'abandons de formulaires mobiles ?
Le mauvais type de clavier est en première position. L'autofill qui ne fonctionne pas est en deuxième. Les deux sont des échecs silencieux : le formulaire a l'air correct, l'utilisateur ne peut simplement pas le compléter efficacement.
Corrigez les deux avec deux attributs par champ. L'investissement est de 15 minutes. Le retour est mesurable dans les conversions de paiement dans le même sprint.
Need a form audit on your sign-up, checkout, or onboarding flow? Brainy runs the full ten-rule audit on real screens, real data, and real conversion numbers.
Get Started
