Optimiser l’inscription SaaS : sept frictions à vérifier

Une personne qui ouvre ton formulaire a déjà fait un premier choix : elle veut essayer le produit. Il reste à lui permettre de terminer, sans lui demander des informations inutiles ni la laisser résoudre seule une erreur obscure.

Les conseils sur les formulaires sont nombreux. Certains reposent sur des observations solides ; d’autres circulent avec un pourcentage spectaculaire dont la source est devenue introuvable. Pour décider quoi changer, mieux vaut comprendre le mécanisme et le contexte de la recherche.

Voici sept points de contrôle, complétés par une vérification du HTML. Ils s’appuient sur des sources primaires et sur un relevé historique de deux pages d’inscription, Plausible et Notion. L’objectif est d’en tirer des questions utiles pour ta propre page, sans attribuer à chaque correction un gain garanti.

D’où viennent les sources de cet article

L’essentiel des recherches citées vient du Baymard Institute et porte sur des checkouts e-commerce : les mécanismes de saisie, de validation et d’effort se transposent à une inscription, les taux d’abandon non.

Les observations de Plausible et Notion viennent d’un relevé du 19 juillet 2026 sur ordinateur, sans création de compte, complété par une lecture du HTML le 25 juillet, et limité à la première étape chez Notion. Les pages ont pu changer depuis. Lis l’ensemble comme des principes de conception à éprouver sur ta page, pas comme des repères chiffrés à atteindre.

1. Demander les informations au bon moment

Commence par inventorier les champs visibles, y compris les optionnels. Pour chacun, demande ce qui empêche réellement le produit de fonctionner si l’information n’est pas fournie maintenant.

Le nom de l’entreprise, la taille de l’équipe ou le rôle servent la qualification commerciale, rarement la création du compte. Déplace ces demandes au premier usage où elles comptent, sans simplement cacher un long formulaire derrière le premier clic.

Dans ses recherches sur le checkout, Baymard rapporte une moyenne de 11,3 champs, alors que la plupart des parcours étudiés pourraient tenir en huit. L’institut indique aussi que 17 % des répondants concernés déclarent avoir abandonné un achat à cause d’un checkout trop long ou complexe. Recherche Baymard sur les champs de checkout.

Le relevé historique montrait trois champs chez Plausible : nom complet, email et mot de passe. La première étape de Notion affichait seulement l’email. Aucun des deux écrans observés ne demandait de téléphone ou de taille d’équipe. Ce sont deux façons de répartir l’effort dans le temps : tout demander une fois, ou n’ouvrir la porte qu’avec l’email.

Le champ de nom mérite lui aussi une question. Si tu as besoin d’un nom d’affichage, un champ unique peut suffire. Séparer prénom et nom n’est utile que si ton usage exige réellement ces données distinctes. La conception doit suivre le besoin métier et les personnes concernées, pas une habitude de formulaire.

2. Marquer les champs obligatoires et optionnels

Le visiteur ne devrait pas avoir à envoyer le formulaire pour découvrir les données exigées. Si tu mélanges des champs obligatoires et optionnels, indique leur statut clairement et de manière cohérente.

Baymard a observé des erreurs évitables lorsque le statut des champs reste implicite. L’enjeu n’est pas de multiplier les astérisques : c’est de permettre à l’utilisateur de savoir ce qu’il doit remplir avant la validation. Recherche Baymard sur les champs requis et optionnels.

Même quand tous les champs sont obligatoires, dis-le : l’absence de marquage n’est pas un signal, c’est un silence. Une courte indication visible, des labels compréhensibles et les attributs HTML appropriés évitent de faire deviner la règle. Le statut doit également être accessible aux technologies d’assistance.

Dans le relevé de Plausible et de la première étape de Notion, aucun champ optionnel n’apparaissait : la question du marquage ne s’y posait pas.

Si un champ optionnel attire beaucoup d’attention sans être utile à ce stade, essaie d’abord de justifier sa présence. Le marquer correctement ne résout pas la question de son utilité.

3. Signaler les erreurs sans couper la saisie

Un formulaire peut avertir trop tard ou trop tôt. Trop tard, l’utilisateur découvre plusieurs erreurs après avoir tenté de terminer. Trop tôt, il reçoit un message rouge alors qu’il n’a pas fini de taper une adresse parfaitement valide.

La validation doit tenir compte de l’état du champ. Une vérification à la sortie peut convenir pour un format simple. Après une erreur, le message doit évoluer dès que la saisie est corrigée. Il ne doit pas rester affiché jusqu’à la prochaine soumission si le problème n’existe plus.

Baymard insiste sur cette qualité d’implémentation dans ses recherches sur la validation en cours de formulaire. Son benchmark donne 31 à 32 % de sites sans validation de ce type, selon l’endroit de la page où le chiffre est repris. Recherche sur la validation des formulaires.

Lors du relevé de juillet 2026, la saisie d’un email manifestement invalide puis la sortie du champ ne produisaient pas de retour immédiat sur les deux écrans observés. Plausible affichait en revanche une explication spécifique pour un mot de passe faible constitué d’une courte séquence.

Pour ton formulaire, vérifie trois choses : le bon moment, une explication précise et un moyen de corriger. « Une erreur est survenue » ne remplit pas ce rôle pour une adresse mal formée. « Vérifie l’adresse email : elle doit contenir un nom de domaine » peut être plus utile, selon l’erreur réelle.

La validation côté navigateur ne remplace jamais les contrôles côté serveur. Elle aide la personne à saisir ; le serveur reste responsable de l’acceptation et du traitement des données. Les erreurs renvoyées par le serveur doivent aussi être compréhensibles et ne pas effacer les autres champs.

4. Garder un label visible après la saisie

Un placeholder peut donner un exemple. Il ne doit pas porter seul le nom du champ : dès que la personne écrit, ce repère disparaît. Elle peut alors avoir du mal à se relire, notamment si plusieurs champs contiennent des valeurs similaires.

Un label visible et correctement associé au contrôle donne un repère durable. La liaison technique importe autant que la présentation : un texte placé au-dessus du champ devient son nom accessible seulement s’il lui est associé. Le W3C explique comment associer les labels aux champs.

Baymard décrit également les difficultés observées lorsque les labels placés à l’intérieur disparaissent pendant la saisie, en particulier sur mobile. Recherche sur les labels des formulaires mobiles.

Les deux écrans historiques observés avaient des labels permanents au-dessus des champs, avec des exemples de saisie dans les placeholders. C’est une répartition utile : le label dit quelle information est attendue, l’exemple précise son format si nécessaire.

Si tu utilises des labels flottants, vérifie qu’ils restent lisibles, qu’ils ne chevauchent pas la valeur et qu’ils sont associés au champ. Teste-les ensuite au zoom, à l’autoremplissage et sur un message d’erreur : c’est là qu’ils cassent.

5. Expliquer les demandes sensibles

Un numéro de téléphone peut être nécessaire à une fonction ou à une vérification. Il peut aussi servir uniquement à faciliter une relance commerciale. Pour la personne qui s’inscrit, ces usages n’impliquent pas le même engagement.

Si l’information est nécessaire maintenant, explique pourquoi à proximité du champ. Si elle ne l’est pas, envisage de la demander au moment où elle devient utile. Baymard décrit l’effet de l’absence d’explication dans sa recherche sur les champs téléphone.

Aucun téléphone n’apparaissait sur les deux écrans examinés en juillet. La première étape de Notion expliquait en revanche l’intérêt d’utiliser un email d’organisation pour faciliter la collaboration. Le principe est transférable : relier la donnée demandée à une raison compréhensible pour l’utilisateur.

Ne présente pas une demande commerciale comme une nécessité technique. Si une personne doit être contactée pour accéder au produit, annonce le déroulement. Si elle peut utiliser seule le produit, vérifie que la qualification ne retarde pas inutilement ce premier usage.

6. Des mots de passe sûrs, des règles claires

La qualité de l’expérience ne justifie pas d’affaiblir la sécurité. Les conseils anciens du type « six à huit caractères suffisent » ne doivent pas être repris comme règle générale actuelle.

Le référentiel NIST SP 800-63B-4, publié en version finale le 26 août 2025, demande au moins 15 caractères pour un mot de passe utilisé comme facteur unique, et permet un minimum de huit dans une authentification multifacteur.

Il recommande aussi d’autoriser au moins 64 caractères, d’éviter les règles arbitraires de composition, de comparer les mots de passe à une liste de valeurs courantes ou compromises, et de limiter les tentatives. Référentiel NIST, section sur les mots de passe.

Traite ce référentiel pour ce qu’il est, un repère de sécurité, et fixe les exigences de ton produit selon son contexte d’authentification.

Côté interface, annonce les règles avant l’erreur, autorise le collage et le gestionnaire de mots de passe, et propose un affichage temporaire contrôlable. Explique un refus sans révéler d’informations sensibles sur les comptes existants.

Dans le relevé historique, Plausible annonçait un minimum de 12 caractères et affichait une évaluation de faiblesse. La première étape de Notion ne demandait pas de mot de passe et proposait des voies d’authentification par email ou fournisseur tiers.

Supprimer le champ mot de passe déplace l’effort vers la boîte mail ou un fournisseur d’identité. Vérifie alors cette nouvelle étape : réception du code, expiration, changement d’adresse et retour au produit.

7. Garder un ordre de lecture évident

Un formulaire disposé verticalement donne un ordre de saisie facile à suivre. Plusieurs colonnes peuvent compliquer cet ordre, notamment lorsqu’un message d’erreur apparaît ou que l’écran se rétrécit.

Une ligne à deux champs reste utilisable quand les informations vont ensemble, comme un code postal et une ville. Regarde la relation entre les informations, l’ordre de navigation et le comportement responsive. Compresser dix champs dans deux colonnes ne réduit pas le travail réellement demandé.

Les deux écrans historiques suivaient une colonne. Pour ton propre formulaire, vérifie le parcours au clavier, l’ordre des champs dans le document et la place des aides. Le focus doit rester visible, et une erreur doit pouvoir être retrouvée sans chercher dans toute la page.

Une fois ces contrôles faits, teste avec le clavier du téléphone ouvert. Les boutons, les explications et les champs suivants doivent rester accessibles sans masquer ce que l’utilisateur est en train de corriger.

Le HTML : autocomplete et labels

Un formulaire peut paraître simple tout en obligeant le navigateur à deviner la nature des champs. L’attribut autocomplete permet de préciser cette nature au navigateur et aux gestionnaires de mots de passe.

Les valeurs utiles ne se limitent pas aux mots de passe. Un nom peut utiliser name, une adresse de contact email, et un email servant d’identifiant de compte username. Un mot de passe en cours de création utilise new-password. current-password correspond à la connexion à un compte existant. Référence MDN de l’attribut autocomplete.

Voici un extrait pédagogique des associations de base pour une inscription par email et mot de passe. Il ne constitue pas un système d’authentification complet.

<label for="signup-email">Adresse email</label>
<input id="signup-email" name="email" type="email"
       autocomplete="username" required />

<label for="signup-password">Mot de passe</label>
<input id="signup-password" name="password" type="password"
       autocomplete="new-password" required />

Il faut compléter ces éléments avec les règles annoncées, les aides, la validation et le traitement sécurisé propres à ton produit. Le type="email" déclenche le clavier adapté ; c’est autocomplete qui dit au navigateur de quel champ il s’agit. Les deux se complètent.

Dans la lecture du HTML de juillet 2026, seul le champ mot de passe de Plausible portait un attribut autocomplete explicite parmi les trois champs observés. Le formulaire de Notion étant construit côté navigateur, son absence du HTML initial ne permettait pas de conclure sur les attributs des champs rendus.

C’est une distinction importante pour ta vérification : inspecte le formulaire réellement affiché, pas uniquement le code source reçu au chargement. Puis teste le comportement avec un gestionnaire de mots de passe et l’autoremplissage du navigateur. Un attribut correct est un point de départ, pas une garantie de comportement identique dans tous les environnements.

« Moins de champs » : que vaut la preuve ?

Réduire les demandes inutiles est une bonne règle de conception. En faire une formule avec un pourcentage assuré est beaucoup moins défendable.

Le cas souvent cité d’Imaginary Landscape compare un formulaire de contact passé de onze à quatre champs. Le rapport de 2008 présente les chiffres suivants :

C’est une comparaison avant/après sur deux périodes, avec 36 confirmations au total, et non une expérience randomisée simultanée. À ce volume, la saison, le trafic ou une campagne expliquent aussi bien l’écart que le formulaire. Rapport original d’Imaginary Landscape.

Le rapport précise un autre changement, plus intéressant que le passage de onze à quatre champs : le nombre de champs obligatoires est passé de quatre à trois. Autrement dit, une grande partie du travail retiré au visiteur portait sur des demandes qu’il pouvait déjà ignorer. C’est la leçon transposable : regarde d’abord ce que tu exiges, pas ce que tu affiches.

De nombreuses anecdotes de formulaires circulent sans données originales accessibles. Si tu ne peux pas retrouver le protocole, la population et la définition de la conversion, ne transforme pas leur chiffre en objectif pour ton équipe.

Le bon arbitrage ne porte pas seulement sur le nombre de soumissions. Une information peut être nécessaire à l’usage, à la sécurité ou à l’orientation vers le bon parcours. Supprimer ce champ sans traiter ce besoin peut augmenter les créations de compte tout en dégradant l’expérience suivante.

À faible volume, appuie-toi sur l’utilité de chaque donnée, les défauts observés et des vérifications fonctionnelles. Un test A/B demande une taille d’échantillon adaptée ; il n’est pas obligatoire pour corriger un label absent ou un message illisible.

Comment lire les chiffres de cet article. Les recherches Baymard portent sur des checkouts e-commerce, le cas Imaginary Landscape est une comparaison avant/après de 2008 sur 36 confirmations, le NIST est un référentiel de sécurité et les relevés Plausible et Notion décrivent deux écrans à une date donnée. Chacun soutient un principe de conception ; aucun ne fixe un objectif de conversion pour ton inscription.

Le bilan des deux relevés historiques

Ce tableau résume ce qui était visible dans les observations de juillet 2026.

L’intérêt de l’exercice est de rendre les questions concrètes. Ces deux écrans se lisent comme deux stratégies assumées : tout demander d’un coup, ou n’ouvrir la porte qu’avec l’email. C’est la suite du parcours, invisible ici, qui décide laquelle tient.

Par où commencer sur ton inscription ?

Teste d’abord le parcours de bout en bout sur ton propre environnement : création, erreur, correction et confirmation. Un défaut bloquant passe avant la réduction d’un champ secondaire.

Examine ensuite une saisie invalide, les labels, les statuts obligatoire/optionnel et l’autocomplétion. Termine par l’inventaire des champs : lesquels sont réellement nécessaires maintenant, lesquels pourraient être demandés au moment de l’usage ?

Si la difficulté apparaît avant même l’ouverture du formulaire, les sept vérifications d’un SaaS qui reçoit du trafic sans inscription aident à la situer. Après modification, vérifie le fonctionnement sur mobile, au clavier et avec l’autoremplissage. Si tu suis les événements de ton produit, distingue les tentatives, les comptes créés et les confirmations. Un enregistrement de session peut montrer un comportement à examiner ; il ne révèle pas avec certitude pourquoi la personne est partie. Le guide Microsoft Clarity détaille cette lecture.

Questions fréquentes

Combien de champs faut-il garder ?

Le bon critère n’est pas le nombre mais la justification : garde un champ si l’absence de sa donnée empêche le produit de fonctionner maintenant. Un champ utile et bien expliqué vaut mieux qu’une information manquante qui bloquera l’usage deux écrans plus loin.

Une étape ou plusieurs ?

Le découpage doit aider à progresser sans dissimuler l’engagement réel. Vérifie l’effort total, les retours en arrière, la conservation des données et ce qui est annoncé au départ.

Faut-il proposer Google, Apple ou un autre fournisseur ?

Cela dépend de ta cible et de ton modèle d’identité. Une voie tierce peut simplifier certaines saisies, mais ajoute une dépendance et des cas d’erreur. Vérifie aussi comment un utilisateur retrouve son compte s’il revient par une autre méthode.

Quelles règles de mot de passe retenir ?

Définis-les à partir des exigences de sécurité de ton produit et d’un référentiel actuel. La longueur compte, mais elle ne remplace ni le contrôle des mots de passe compromis ni la protection contre les tentatives répétées. Annonce les règles et facilite l’usage d’un gestionnaire.

Une meilleure inscription suffit-elle à obtenir des clients payants ?

Non. Elle facilite l’entrée, mais le produit doit ensuite tenir sa promesse. L’activation et le passage de l’essai gratuit au payant demandent leur propre diagnostic.