L'inscription est le maillon le plus rentable de votre funnel : un visiteur qui l'abandonne a déjà coûté de l'acquisition et ne rapportera jamais rien. C'est aussi l'endroit où circulent le plus de conseils recyclés, souvent adossés à des chiffres que plus personne ne vérifie. J'ai donc fait l'inverse : sept guidelines du Baymard Institute relues à la source, appliquées à deux inscriptions que vous connaissez, Plausible et Notion, puis le HTML réellement servi par leurs formulaires. Voici ce qui tient, ce qui ne tient pas, et ce que vous pouvez corriger chez vous dès ce week-end.
Le cadre : d'où viennent les données, et ce que j'ai vraiment testé
Trois précisions de méthode avant de dérouler, parce que c'est ce qui sépare une analyse d'une compilation.
Les recherches Baymard portent sur le checkout e-commerce, pas sur les inscriptions SaaS. L'institut teste des parcours d'achat en laboratoire UX depuis 2009, et personne d'autre ne publie des données de cette qualité sur les formulaires. Une inscription SaaS partage la même mécanique, des champs, des erreurs, un utilisateur pressé, mais pas le même contexte. Quand une guideline se transpose mal, je le dis.
J'ai observé les deux parcours le 19 juillet 2026 sur desktop, sans créer de compte, et relu leur HTML le 25 juillet 2026. Pour Notion, l'analyse s'arrête donc à ce que montre la première étape. Les deux pages peuvent avoir changé depuis.
Chaque chiffre cité vient d'une page publique que j'ai ouverte, le lien à l'appui. C'est plus contraignant qu'il n'y paraît : plusieurs statistiques célèbres attribuées à Baymard n'existent sur aucune de leurs pages. J'y reviens en fin d'article.
Les 7 guidelines, à l'épreuve de deux vraies inscriptions
1. Réduire le nombre de champs visibles
La donnée : le checkout moyen affiche 11,3 champs de formulaire, alors que 8 suffisent dans la plupart des cas, et 17 % des utilisateurs déclarent avoir déjà abandonné un achat à cause d'un checkout trop long ou trop complexe. Le principe qui se transpose au SaaS : chaque champ visible a un coût cognitif, y compris les champs optionnels que personne ne remplit.
Sur le terrain : Plausible demande trois champs, nom complet, email, mot de passe. Notion en demande un seul, l'email, et repousse tout le reste après la première étape. Aucun des deux ne demande d'entreprise, de taille d'équipe ou de numéro de téléphone à l'inscription. La qualification, ils la font plus tard, dans le produit.
Détail qui vaut une guideline à lui seul : Plausible demande le nom en un seul champ « Full name ». Baymard a mesuré que 89 % des sites scindent encore prénom et nom, alors qu'avec un champ unique seuls 4 % des utilisateurs testés hésitent, contre 42 % qui tapent leur nom complet dans le premier champ quand il est scindé.
2. Marquer les champs requis ET les champs optionnels
La donnée : seuls 14 % des sites marquent explicitement les deux, un chiffre mesuré à 9 % en 2012 puis 14 % dans les benchmarks Baymard de 2016 et 2021 : dix ans sans progrès sur ce point. Quand seuls les champs optionnels sont marqués, 32 % des utilisateurs testés ont rencontré une erreur de validation évitable.
Sur le terrain : Plausible et Notion appliquent la solution la plus radicale, et la meilleure. Zéro champ optionnel : tout ce qui est affiché est requis, il n'y a rien à marquer et rien à deviner. Si votre inscription mélange requis et optionnels, vous avez deux options : marquer les deux explicitement, ou supprimer les optionnels et les demander plus tard dans le produit.
3. La validation à la sortie du champ, pas pendant la frappe
La donnée : 31 % des sites n'ont aucune validation inline, c'est à dire aucune vérification du champ avant l'envoi du formulaire. Et Baymard précise le « bien implémentée » : ne pas valider pendant la frappe mais à la sortie du champ, retirer le message d'erreur dès que la saisie devient valide, confirmer les champs corrects.
Sur le terrain, c'est le point faible commun de mes deux cobayes, et le test est reproductible chez vous en dix secondes. J'ai tapé « pasunemail » dans le champ email des deux formulaires, puis je suis passé au champ suivant. Aucun des deux ne réagit : l'erreur ne se révélera qu'à la soumission. Plausible se rattrape sur le mot de passe : en quittant le champ après « abc », le message « Password is too weak. Sequences like abc or 6543 are easy to guess. » apparaît immédiatement, spécifique et pédagogique.
4. Jamais de placeholder en guise de label
La donnée : dans tous les tests utilisateurs de Baymard sur le sujet, les labels affichés à l'intérieur du champ ont causé des problèmes d'utilisabilité majeurs : dès que l'utilisateur tape, le label disparaît, et avec lui le contexte pour se relire ou corriger une erreur. C'est une étude qualitative de 2013, sans pourcentage, mais elle n'a jamais été contredite depuis.
Sur le terrain : conformité parfaite des deux côtés. Label permanent au-dessus du champ, placeholder utilisé comme exemple de saisie : « Jane Doe » et « example@email.com » chez Plausible, « name@company.com » chez Notion. C'est le partage des rôles que recommande Baymard.
5. Pas de champ téléphone sans justification
La donnée : 39 % des sites exigent un numéro de téléphone sans expliquer pourquoi, alors que dans leur sondage auprès de 1 026 acheteurs américains, 14 % déclarent qu'ils ne donneraient jamais leur numéro. La guideline exacte : si un champ sensible est requis, expliquer pourquoi juste à côté ; sinon, le rendre optionnel ou le supprimer.
Sur le terrain : aucun des deux ne demande de téléphone, le sujet est réglé par l'absence. Mais Notion illustre la version positive de la règle avec son microcopy sous le champ email : « Use an organization email to easily collaborate with teammates ». Le champ demande quelque chose de précis, un email professionnel, et dit au visiteur ce qu'il y gagne. Si votre inscription B2B exige un téléphone pour router les leads vers les commerciaux, écrivez-le à côté du champ, ou assumez de le demander après l'inscription.
6. Le mot de passe : une longueur minimale, pas une chasse au trésor
La donnée : 82 % des sites e-commerce imposent des règles de complexité (majuscule, chiffre, caractère spécial), et Baymard mesure environ 19 % d'abandon parmi les utilisateurs confrontés à un problème de mot de passe ou de réinitialisation. Leur recommandation : une longueur minimale, rien d'autre.
Sur le terrain : Plausible affiche « At least 12 characters » sous le champ, avant toute erreur, et n'impose aucune règle de composition. Douze caractères, c'est au-dessus des 6 à 8 que Baymard suggère pour un site grand public, mais la logique est la bonne : juger la longueur et la force réelle du mot de passe, pas sa conformité à une liste de symboles. Notion contourne le sujet entièrement : pas de mot de passe à la première étape, l'authentification passe par un code envoyé par email ou par Google et Microsoft. La friction n'a pas disparu, elle est déplacée vers la boîte mail, mais elle ne bloque plus l'inscription elle-même.
7. Une seule colonne
La donnée : 18 % des sites affichent encore leur formulaire sur plusieurs colonnes, un layout qui provoque des champs sautés et des erreurs de parcours dans les tests. Transparence : cette page synthèse de Baymard n'affiche pas de date de publication, c'est la seule donnée de cet article dans ce cas. Un formulaire se lit de haut en bas, sans ambiguïté sur le champ suivant.
Sur le terrain : une colonne partout, sujet réglé. Cette guideline est surtout un piège pour les inscriptions « riches » qui demandent dix champs et les compressent en deux colonnes pour paraître courtes. Un formulaire en deux colonnes ne paraît pas deux fois plus court, il se remplit deux fois moins bien.
La friction que votre analytics ne verra jamais : le HTML servi
Les sept guidelines ci-dessus se voient à l'œil nu. La huitième friction, celle que les rapports de conversion ne montrent pas, se lit dans le code de votre page. Elle décide si le gestionnaire de mots de passe de votre visiteur, celui qui remplit ses formulaires à sa place depuis des années, sait quoi faire du vôtre.
Le mécanisme tient dans un attribut HTML, autocomplete, dont les valeurs sont normalisées par la spécification du langage. Trois seulement concernent une inscription, et leur définition est publique :
<input type="email" autocomplete="username" />
<input type="password" autocomplete="new-password" />
<input type="password" autocomplete="current-password" />username désigne l'identifiant de compte, email compris. new-password signale un mot de passe en cours de création : le navigateur évite d'y coller un ancien mot de passe et propose d'en générer un solide. current-password est réservé à la connexion. Sans ces marqueurs, le gestionnaire de mots de passe doit deviner, et il devine mal.
J'ai relu le HTML servi par les deux inscriptions le 25 juillet 2026. Plausible pose autocomplete="new-password" sur son champ mot de passe, ce qui est le bon choix et déclenche la proposition de génération. Ses champs nom et email, eux, ne portent aucun attribut autocomplete : un seul des trois est marqué. Le champ email est bien en type="email", ce qui reste l'essentiel côté mobile puisque cet attribut fait apparaître le clavier avec l'arobase. Chez Notion, le formulaire est construit par JavaScript après le chargement : le HTML servi ne contient aucun champ à inspecter, et la vérification demande l'inspecteur du navigateur plutôt que le code source de la page.
Voilà le « comment je vérifie » chez vous, sans outil ni budget. Ouvrez votre page d'inscription, clic droit sur le champ email, « Inspecter », et lisez la balise. Si l'attribut autocomplete manque, ajoutez-le. C'est une ligne de code, elle ne déplacera aucun pixel de votre design, et elle rend votre formulaire remplissable en un clic pour tous les visiteurs qui ne tapent plus leurs identifiants depuis longtemps.
« Moins de champs égale plus de conversion » : vrai, ou cargo cult ?
C'est LE conseil formulaire par excellence, et il mérite le détour par ses sources, parce qu'elles sont plus fragiles que leur célébrité.
Le cas fondateur tient sur 36 soumissions. L'étude « 11 champs réduits à 4 » qui circule partout vient d'Imaginary Landscape, en 2008 : un formulaire de contact passé de 11 à 4 champs, un taux de conversion qui grimpe de 5,4 % à 11,9 %, soit le fameux « +120 % ». Ce que presque personne ne relaie : ce n'est pas un A/B test mais une comparaison avant/après sur deux périodes différentes, et l'échantillon total est de 36 soumissions, 10 avant, 26 après.
Le champ à 12 millions de dollars est un souvenir de conférence. L'anecdote Expedia, un champ optionnel « Company » supprimé qui aurait rapporté 12 M$ par an, vient de propos de Joe Megibow, alors VP analytics d'Expedia, rapportés par la presse en 2010. Le site qui a publié l'article d'origine, silicon.com, n'existe plus : aucune donnée de test n'a jamais été publiée. Plausible comme mécanisme, invérifiable comme chiffre.
Le contre-exemple le plus cité n'a plus de source du tout. Le test de Michael Aagaard où réduire un formulaire de 9 à 6 champs fait chuter la conversion de 14 %, avant qu'une réécriture des labels à 9 champs ne l'améliore de 19 %, a été publié sur ContentVerve, un site aujourd'hui disparu. Il ne survit que dans des relais comme CXL, qui en tire la vraie leçon : ce ne sont pas les champs en moins qui convertissent, ce sont les champs inutiles en moins. CXL ajoute l'arbitrage que les listicles oublient : un formulaire plus court produit plus de leads, mais pas forcément de meilleurs leads. Et leur remarque la plus utile résume cette section : la plupart des données qui circulent sur les champs de formulaire ont plus de dix ans.
Mon verdict en une phrase : le principe par défaut reste bon, chaque champ doit justifier son existence, mais c'est une heuristique de conception, pas une loi avec un pourcentage garanti. Et avant de vouloir trancher chez vous par un test, rappelez-vous qu'un A/B test demande un volume que la plupart des SaaS bootstrappés n'ont pas : à petit trafic, appliquez les guidelines, ne les testez pas.
La scorecard, et par où commencer
Le bilan des deux cobayes sur les sept guidelines, plus le HTML servi :
| Guideline | Plausible | Notion (étape 1) |
|---|---|---|
| Champs visibles réduits | 3 champs | 1 champ |
| Requis / optionnels marqués | Aucun optionnel | Aucun optionnel |
| Validation à la sortie du champ | Mot de passe oui, email non | Non observée |
| Labels permanents | Oui | Oui |
| Téléphone justifié ou absent | Absent | Absent |
| Mot de passe : longueur seule | Oui, 12 caractères annoncés | Pas de mot de passe |
| Une colonne | Oui | Oui |
Attributs autocomplete | 1 champ sur 3 | Non lisible dans le HTML servi |
Deux produits matures, sept guidelines, et il reste des trous : c'est la leçon rassurante de l'exercice. Personne ne coche tout, et votre inscription n'a pas besoin de tout cocher pour progresser. Si vous ne faites qu'une chose cette semaine, faites le test des dix secondes : tapez une adresse invalide dans votre champ email, passez au champ suivant, et regardez si votre formulaire vous prévient. Puis inspectez vos trois champs et posez les attributs autocomplete manquants. Ces deux corrections tiennent en une heure et ne demandent l'accord de personne.
Ensuite seulement, comptez vos champs et exigez de chacun qu'il justifie sa place. Si le sujet dépasse le formulaire et que c'est tout le parcours qui fuit, c'est le travail de l'audit CRO, dont je détaille les prix pratiqués sur le marché dans un article dédié.
FAQ
Combien de champs pour une inscription SaaS ?
Il n'existe pas de chiffre magique validé par une étude sérieuse. Les données Baymard montrent que les checkouts affichent en moyenne 11,3 champs quand 8 suffisent, et les deux inscriptions analysées ici tiennent en 1 à 3 champs. La bonne question n'est pas « combien » mais « lequel puis-je supprimer ou repousser après l'inscription ».
Inscription en une étape ou multi-étapes ?
Baymard ne tranche pas sur le nombre d'étapes : leur donnée dit que c'est le nombre total de champs qui pèse, pas leur découpage. Notion choisit le multi-étapes radical, un champ puis le reste plus tard, ce qui lisse l'engagement. La version dangereuse du multi-étapes est celle qui cache la longueur réelle du parcours au visiteur.
À quoi sert l'attribut autocomplete sur un formulaire d'inscription ?
Il indique au navigateur et au gestionnaire de mots de passe la nature de chaque champ, avec des valeurs normalisées par la spécification HTML. Sans lui, le remplissage automatique devient approximatif, et le visiteur qui ne tape plus ses identifiants depuis des années se retrouve à le faire chez vous. C'est une ligne de code par champ, invisible pour le design.
Faut-il proposer l'inscription via Google ou Apple ?
Notion propose Google et Microsoft, un choix cohérent avec sa cible entreprise. Plausible n'en propose aucun, cohérent avec son positionnement vie privée. Le social login supprime le champ mot de passe et ses abandons, au prix d'une dépendance à un tiers. C'est un arbitrage de positionnement autant que de conversion.
Faut-il demander le numéro de téléphone à l'inscription ?
Dans le sondage Baymard, 14 % des répondants ne donneraient jamais leur numéro. Si votre équipe commerciale en a réellement besoin, expliquez à côté du champ pourquoi vous le demandez, ou déplacez la demande après l'inscription, au moment où elle devient légitime.
Quelles règles de mot de passe imposer ?
Une longueur minimale, rien d'autre : c'est la recommandation Baymard, appliquée par Plausible avec ses 12 caractères annoncés avant toute erreur. Les règles de composition (majuscule, chiffre, symbole) sont présentes sur 82 % des sites testés et sont une source d'abandon mesurée, pas un gage de sécurité.
Comment savoir où les visiteurs abandonnent mon inscription ?
Les session recordings sont l'outil le moins cher pour le voir : un enregistrement montre le champ où le curseur s'arrête, les erreurs répétées et la sortie. J'explique comment faire dans mon guide de Microsoft Clarity, l'outil gratuit de session recording.
Réduire les champs suffit-il à améliorer ma conversion en essai payant ?
Non. L'inscription est la porte d'entrée, pas le tunnel entier : un parcours parfait qui débouche sur un onboarding confus ne produit que des comptes morts. La suite se joue dans la conversion de l'essai gratuit en client payant.