Plus le formulaire de commande est confus, moins les acheteurs terminent

Ouvrez le checkout en live sur un téléphone. Comptez chaque champ inutile pour expédier ou encaisser. Si les commandes payantes s’arrêtent après le panier, ce chiffre explique souvent pourquoi – plus le formulaire de commande est confus, moins les acheteurs terminent.

Partie 5 de Conversion, page par page – plan complet

L’épisode précédent traitait de la page panier qui confirme le contenu du sac. Cette page encaisse. Adresse, mode de livraison, paiement. Un formulaire qui demande aussi comment on vous a trouvé, veut un deuxième téléphone « pour le soir » et cache Invité sous Créer un compte, ce n’est pas du sérieux. C’est ainsi qu’on fait abandonner une commande que le panier avait déjà gagnée.

Ce qu’un formulaire de commande doit faire

Une seule mission : encaisser et obtenir une adresse de livraison. Qui reçoit le colis. Où il va. Comment il part. Comment on paie. Puis un bouton Pay qu’on trouve vraiment.

Le panier a déjà montré les lignes et le total. Ce formulaire de commande n’a pas besoin de revendre le produit, de lancer une enquête marketing ou d’imposer un mot de passe avant la carte. Si un champ n’est pas requis pour expédier la commande ou débiter la carte, il n’a pas sa place sur cet écran.

Ce qui rend un formulaire de commande confus

Le plus long qu’on ait démêlé cette année : une boutique de vêtements sur thème par défaut – rien de custom, rien d’extravagant. Créer un compte avant la carte. E-mail, puis e-mail encore. Mot de passe, puis confirmation. Société. TVA. Fax, toujours là depuis 2012. Deux champs téléphone, dont un libellé « soir ». Une liste déroulante : comment nous avez-vous connu. Newsletter pré-cochée. Une barre de progression « Étape 3 sur 5 » sans indice sur 4 et 5. Le total en minuscule sous un widget coupon. Pay en bas de page, nommé « Continuer », impossible de savoir que le clic débite.

Rien de tout ça n’est exotique. La plupart des checkouts confus sont des extras ordinaires empilés un par un – chacun défendable, l’ensemble fatal.

Le formulaire invité le plus propre qu’on ait livré demande une adresse de livraison, un mode lisible, le paiement, un Pay. Invité par défaut. Le compte, une proposition après le débit, pour ceux qui veulent l’historique. Même mission que le long formulaire. L’un d’eux encaisse.

Champs reportables après le paiement

L’article de Nick Babich sur les formulaires mobiles dans Smashing Magazine résume la règle en une ligne : chaque champ coûte de l’effort, et plus court vaut mieux. Des questions en plus à l’inscription ou au paiement font perdre quelqu’un qu’on avait déjà. Relancez plus tard si vous voulez l’histoire. Ne retenez pas la carte en otage.

Retirez ou déplacez hors de cet écran :

• Comment nous avez-vous connu
• Inscription newsletter (demander après Payer, décochée)
• Société et TVA sauf si l’acheteur a choisi le checkout pro
• Fax
• Un deuxième téléphone
• Mot de passe compte, si l’invité peut payer
• Date de naissance, « couleur préférée », tout ce qui alimente un CRM et pas une étiquette d’expédition

Requis pour une facture légale ou une déclaration douanière n’est pas « sympa à avoir ». Gardez-les. Le test reste le même : ce champ expédie-t-il le colis ou débite-t-il la carte. Si la réponse est non, ça peut attendre.

Checkout invité vs mur de compte

Forcer une connexion pour payer, c’est deux formulaires pour le travail d’un. Ils ont déjà tapé un e-mail dans le panier, ou ils vont en taper un pour le reçu. Demander un mot de passe avant la carte, c’est un guichet adhérent entre le « oui » et l’argent.

Invité d’abord. Proposez Créer un compte après le débit, quand la commande existe et qu’un historique vaut le coup. S’ils ont déjà un compte, la connexion est un raccourci – pas la seule porte. Cacher Invité sous un gros bloc connexion, c’est le même mur avec de moins bonnes manières.

Quand le formulaire efface ce qu’ils ont déjà saisi

Un Pay raté qui vide le formulaire suffit à faire perdre la commande. L’acheteur remplit l’adresse, tape la carte, appuie sur Pay. Quelque chose échoue – CVV, une case obligatoire, un code postal que le transporteur refuse. La page recharge. Le numéro de carte a disparu. Parfois l’adresse aussi. La plupart ne recommencent pas. Ils partent.

Gardez ce qu’ils ont tapé. Signalez le seul champ en erreur. N’effacez pas la carte parce qu’une case newsletter était vide. PCI n’exige pas de punir les gens ; ça exige de ne pas stocker le PAN. Un rechargement qui vide le formulaire, c’est un bug boutique, pas une fonction sécurité.

Le même formulaire sur téléphone

Vous avez déjà combattu le dump desktop sur la page produit mobile. Le checkout, c’est là que le combat se perd plus facilement : chaque champ en plus, c’est un clavier pleine largeur et un champ zoomé, et cinq « étapes » propres sur un écran 27 pouces deviennent cinq visites dans un bus.

Champs pleine largeur. Libellés au-dessus du champ, pas à côté. Clavier numérique pour la carte. Une colonne. Pay visible sans chasse au trésor. Si vous avez besoin d’un second écran, que ce soit « coordonnées carte » – pas « dites-nous comment vous nous avez trouvés ».

Ouvrez le formulaire live ce soir et recomptez. Coupez ce qui n’expédie pas et n’encaisse pas. Le panier a déjà gagné cette commande une fois – le seul travail restant, c’est ne pas la perdre au formulaire. Puis essayez de payer au téléphone d’une main. Si vous bloquez, eux aussi.

Travaillez ça avec votre agent IA

Ne demandez pas à un agent d’« améliorer l’UX checkout ». Donnez-lui le formulaire réel et faites-le trier expédier-ou-encaisser vs peut-attendre.

À coller : le HTML du checkout, ou deux captures (desktop + téléphone). Si votre premier écran oppose invité et compte, collez ça aussi – plus l’état d’erreur, l’écran après un débit raté.

Prompt 1 – inventaire des champs. « Listez chaque champ et étape de ce checkout. Taggez chacun : nécessaire pour expédier ou encaisser, ou reportable après paiement. Proposez une liste de coupes. N’ajoutez pas de fonctionnalités. N’inventez pas Express Pay comme solution. »

Prompt 2 – parcours invité. « Voici le premier écran de checkout. Réécrivez-le pour qu’un invité puisse payer sans créer de mot de passe. Le compte devient une proposition après le débit. »

Prompt 3 – test de l’effacement. « Voici l’état d’erreur après un paiement raté. Listez tout ce que le formulaire a effacé. Réécrivez le flux pour qu’un débit raté conserve chaque champ déjà saisi par l’acheteur. »

Bon résultat : un inventaire de champs, un ordre de blocs plus court, et un état d’erreur qui garde ce qu’ils ont tapé – quelque chose à remettre au thème. Pas « améliorer le flux ».