Formulaire de landing page : une colonne ou deux ?

Un formulaire de demande de devis avec douze champs occupe beaucoup de place. La tentation est immédiate : les répartir sur deux colonnes pour que l'ensemble tienne dans un écran, sans scroll, avec le bouton d'envoi visible d'emblée. L'intention est saine — un formulaire qui paraît court est un formulaire qu'on commence — mais le raccourci se paie ailleurs. En pratique, la colonne unique reste la disposition par défaut, et les situations où deux colonnes se justifient sont bien plus rares qu'on ne le croit.

Pourquoi la colonne unique est la règle par défaut

Un formulaire n'est pas un contenu qu'on parcourt, c'est une séquence qu'on exécute. Le visiteur ne balaie pas les champs pour choisir lesquels remplir : il attend qu'on lui indique quoi saisir, dans quel ordre, et jusqu'où. La colonne unique répond exactement à cette attente : un seul axe, de haut en bas, aucun arbitrage à faire. C'est très différent du parcours du regard en F ou en Z qu'on observe sur du contenu éditorial : là, le visiteur sélectionne ce qui l'intéresse ; dans un formulaire, il suit une procédure. Dès qu'on place deux champs côte à côte, on réintroduit une micro-décision (« je continue à droite ou je descends ? ») au moment précis où l'on voudrait qu'il n'y en ait aucune.

Ce qui coûte, dans un formulaire, ce n'est pas le nombre de pixels parcourus mais le nombre de fois où l'œil doit repartir en arrière. Une étude par eye-tracking de Subhrajit Das, Tom McEwan et Donna Douglas, présentée à NordiCHI en 2008, a comparé trois positions de libellé (au-dessus du champ, aligné à gauche, aligné à droite) sur un échantillon réduit d'utilisateurs. Le résultat a surpris les auteurs eux-mêmes : dans leur dispositif, les libellés alignés à droite — donc collés au champ qu'ils décrivent — donnaient les temps de complétion les plus courts, à rebours de plusieurs recommandations antérieures. Au-delà du débat sur les libellés, que nous détaillons dans notre article label ou placeholder, la leçon est transposable : la performance d'un formulaire tient à la distance que le regard doit franchir entre deux éléments qui vont ensemble. Une grille à deux colonnes multiplie ces distances.

Le coût caché du formulaire en deux colonnes

• Des champs sautés : la colonne de droite est régulièrement négligée, en particulier quand elle est plus courte que celle de gauche. Le visiteur croit avoir terminé, clique sur « Envoyer » et découvre des erreurs sur des champs qu'il n'avait tout simplement pas vus.
• Un ordre de tabulation incohérent : la touche Tab suit l'ordre du code HTML, pas l'ordre visuel. Selon la façon dont la grille est construite en CSS, le focus peut filer vers la droite quand l'œil descend, ou l'inverse.
• Plus d'erreurs de validation : davantage de champs manqués, c'est davantage de soumissions rejetées, donc des allers-retours entre le message d'erreur et le champ concerné — un moment de friction où une partie des visiteurs abandonne purement et simplement.
• Une hiérarchie brouillée : deux champs côte à côte sont perçus comme liés, même quand l'un est obligatoire et l'autre facultatif, même quand ils n'ont rien à voir. Le regroupement par proximité finit par signaler n'importe quoi.
• Un gain de hauteur souvent illusoire : sur un formulaire de six champs, passer en deux colonnes économise trois hauteurs de champ. Rarement de quoi changer la décision d'un visiteur, souvent de quoi lui faire manquer une information.

L'article de référence sur le sujet reste celui de Mirjam Seckler, Silvia Heinz, Javier A. Bargas-Avila, Klaus Opwis et Alexandre N. Tuch, « Designing Usable Web Forms – Empirical Evaluation of Web Form Improvement Guidelines », publié à la conférence CHI 2014. Les chercheurs ont appliqué un ensemble de recommandations d'ergonomie à des formulaires réels d'entreprises, puis comparé versions d'origine et versions retravaillées dans une expérience contrôlée avec eye-tracking (65 participants). Les formulaires améliorés étaient complétés plus vite, avec moins de tentatives de soumission et moins de mouvements oculaires, et les participants s'en déclaraient plus satisfaits. Or ces deux indicateurs — mouvements oculaires et soumissions ratées — sont exactement ce qu'une disposition en grille dégrade.

Le mobile tranche la question à votre place

Il y a un argument que peu de débats de maquette survivent : sous 480 pixels de large, toute grille finit empilée. Deux colonnes de champs sur un écran de téléphone donnent soit des champs trop étroits pour être lisibles et cliquables, soit — bien plus souvent — une simple pile de champs, c'est-à-dire une colonne unique. Si votre trafic est majoritairement mobile, comme c'est le cas de la plupart des landing pages issues de Meta Ads ou de Google Ads, vous concevez déjà un formulaire en colonne unique : la version deux colonnes n'existe que pour une minorité de visiteurs sur grand écran. Dans une logique mobile-first, la question se pose à l'envers : quel bénéfice justifierait de faire diverger le desktop du mobile, avec deux comportements à tester et à maintenir ?

Les rares exceptions légitimes

Deux champs peuvent partager une ligne à une condition précise : qu'ils soient courts et sémantiquement liés, au point que le visiteur les traite comme une seule information plutôt que comme deux étapes. La mise en ligne ne crée alors aucune ambiguïté sur l'ordre de saisie, et elle renforce même le regroupement perceptif. Les cas qui remplissent vraiment ce critère se comptent sur les doigts d'une main.

• Prénom + nom : une seule identité, deux champs par convention technique. Personne n'hésite sur l'ordre. C'est l'exception la plus consensuelle — sachant qu'un champ « Nom complet » unique reste souvent plus simple encore.
• Code postal + ville : deux informations que le visiteur restitue d'un bloc, et que l'on peut de toute façon compléter automatiquement l'une à partir de l'autre. Les longueurs de champ sont naturellement inégales, ce qui signale visuellement leur nature.
• Jour / mois / année : une séquence unique et culturellement ordonnée. Le vrai débat porte plutôt sur l'opportunité de découper une date en trois champs plutôt que d'utiliser un champ unique correctement formaté.

Ordre de tabulation, clavier et accessibilité

C'est le point que les maquettes ignorent presque toujours. La navigation au clavier suit l'ordre des éléments dans le DOM, c'est-à-dire l'ordre du code HTML, pas l'ordre visuel produit par le CSS. Avec une grille CSS ou un conteneur flex, le décalage est vite créé : les propriétés order, grid-auto-flow: column ou un simple flex-direction: row-reverse réorganisent l'affichage sans toucher au code sous-jacent. Le visiteur qui tabule voit alors son focus sauter sans logique apparente, et c'est un critère d'échec explicite du référentiel WCAG (critère 2.4.3 « Ordre de focus »), repris par le RGAA — un sujet traité plus largement dans notre article sur l'accessibilité d'une landing page. La règle pratique tient en une phrase : l'ordre du HTML doit être l'ordre de saisie souhaité, et on ne rattrape jamais un ordre de tabulation avec des tabindex positifs, qui aggravent le problème. Le même raisonnement vaut pour les lecteurs d'écran, qui restituent le formulaire dans l'ordre du DOM, et pour le zoom à 200 % : une grille doit alors se replier proprement en une seule colonne. Le chapitre de Javier A. Bargas-Avila, Olivia Brenzikofer, Sandra P. Roth, Alexandre N. Tuch, Silvia Orsini et Klaus Opwis, « Simple but Crucial User Interfaces in the World Wide Web: Introducing 20 Guidelines for Usable Web Form Design » (2010), synthétise la littérature académique sur les formulaires en une vingtaine de recommandations : structure claire, regroupement logique des champs, libellés sans équivoque, traitement explicite des erreurs. Aucune ne poursuit un objectif de compacité ; toutes visent à réduire l'incertitude de la personne qui remplit.

Le formulaire long : le cas de la demande de devis

C'est sur les formulaires longs que la tentation des deux colonnes est la plus forte, et c'est là qu'elle est la plus coûteuse : plus il y a de champs, plus la probabilité d'en sauter un augmente, et plus une soumission rejetée pèse lourd puisqu'elle intervient après plusieurs minutes de saisie. La bonne réponse à un formulaire trop long n'est pas de le replier sur deux colonnes, c'est de le raccourcir ou de le découper. Le raccourcir d'abord : chaque champ doit gagner sa place, et notre article sur le nombre de champs d'un formulaire détaille comment arbitrer entre volume de leads et qualification. Le découper ensuite : un formulaire en plusieurs étapes conserve la colonne unique tout en réduisant la hauteur perçue à chaque écran. Entre les deux existe une solution intermédiaire souvent suffisante : garder une seule colonne mais introduire des sections titrées (« Votre projet », « Vos coordonnées »), séparées par un peu d'air. Le formulaire fait la même hauteur, mais il se lit comme trois blocs courts plutôt que comme une liste interminable — et le regroupement, cette fois, porte du sens.

Ce qu'il faut retenir

La colonne unique n'est pas une mode esthétique, c'est la disposition qui rend l'ordre de saisie évident, qui garde l'ordre visuel aligné sur l'ordre du code, et qui survit sans arbitrage au passage sur mobile. Deux colonnes restent défendables pour une poignée de paires de champs courts et manifestement liées, jamais pour compacter un formulaire trop long — dans ce cas, c'est le nombre de champs ou le découpage en étapes qu'il faut revoir. Les 10 templates LanderKit (89 € l'unité, 229 € le pack complet) livrent des formulaires en colonne unique, avec un ordre HTML aligné sur l'ordre visuel et une navigation clavier cohérente. Le template immobilier-lead, conçu pour la capture de leads immobiliers, illustre bien le compromis : un formulaire de qualification relativement long, maintenu sur une seule colonne, structuré en sections plutôt qu'en grille.