Chapitre 1. Le dernier kilomètre : ce que coûte vraiment la friction.
Un site e-commerce peut dépenser des fortunes en acquisition alors que tout se joue dans les dernières minutes, entre le panier et la page de confirmation. Le checkout, qui rassemble identification, livraison et paiement, est l'endroit où l'intention d'achat rencontre la friction. Champs à remplir, comptes à créer, frais découverts au dernier moment, cartes refusées. Chaque irritant a un coût mesurable, et chaque seconde gagnée se lit dans le chiffre d'affaires.
Pour savoir pourquoi on abandonne, le Baymard Institute, référence mondiale de la recherche UX e-commerce, interroge chaque année les acheteurs américains ayant abandonné un achat après l'avoir commencé, hors simple lèche-vitrine. Les résultats 2024 dessinent une hiérarchie claire des irritants :
| Motif d'abandon | Part des abandonnistes | Levier de correction |
|---|---|---|
| Frais supplémentaires trop élevés (livraison, taxes) | 48 % | Afficher le coût total le plus tôt possible, seuils de franco lisibles |
| Création de compte imposée | 26 % | Guest checkout par défaut (chapitre 3) |
| Manque de confiance pour les données de carte | 25 % | Réassurance visuelle, logos schemes, page sécurisée cohérente |
| Livraison trop lente | 23 % | Dates de livraison estimées, options express |
| Parcours trop long ou trop complexe | 22 % | Réduire les champs, wallets first (chapitres 2 et 3) |
| Impossible de connaître le coût total d'avance | 21 % | Estimateur de frais dès le panier |
| Erreurs ou plantages du site | 17 % | Monitoring du tunnel, gestion d'erreurs (chapitre 5) |
| Politique de retour insatisfaisante | 16 % | Politique claire et visible au checkout |
| Moyens de paiement insuffisants | 13 % | Couverture wallets, BNPL, virement selon la clientèle |
| Carte refusée | 9 % | Traduction des codes refus, moyens alternatifs (chapitre 5) |
Avant d'optimiser, il faut savoir où l'on perd, et le checkout se mesure comme un entonnoir dont chaque étape a son taux de passage. Le produit de ces taux donne la conversion globale. La suite du cours suit cet entonnoir dans l'ordre où le client le vit, du formulaire aux moyens de paiement puis au mobile et aux refus, avant que la mesure et l'expérimentation ne viennent en conclusion.
Chapitre 2. Le formulaire : ordre des champs, autofill et validation.
Le formulaire est l'unité de friction élémentaire du checkout, où Baymard mesure en moyenne 11,3 champs affichés quand 7 à 8 suffisent à exécuter une commande. Chaque champ superflu ajoute du temps, des erreurs de saisie et des occasions de douter. Trois principes gouvernent un bon formulaire : ne demander que le nécessaire, le demander dans le bon ordre, aider le navigateur à le remplir tout seul.
L'ordre des champs n'est pas neutre
- E-mail d'abord. C'est la clé de tout : il permet de retrouver un client connu (et de lui proposer ses moyens enregistrés), d'envoyer la confirmation, et de relancer un panier abandonné si le parcours s'arrête là. Le demander en premier maximise la valeur des abandons partiels.
- Livraison avant paiement. L'adresse détermine les frais et la date de livraison : le client doit connaître le coût total avant de sortir sa carte, jamais l'inverse (souvenez-vous des 48 % d'abandons pour frais surprises).
- Paiement en dernier. La saisie de carte est l'acte le plus engageant : on ne le demande qu'une fois toutes les questions résolues. Facturation = livraison par défaut, avec une simple case à décocher pour les cas divergents (moins de 10 % des commandes B2C).
- Un seul champ « nom complet » plutôt que prénom + nom, pas de civilité, pas de téléphone obligatoire sauf besoin réel du transporteur, et si oui, dire pourquoi (« pour vous prévenir de la livraison »).
Autofill : laisser le navigateur travailler
Les navigateurs et gestionnaires de mots de passe remplissent un formulaire entier en un clic, à condition que les champs portent correctement l'attribut HTML autocomplete. L'attribut vaut aussi comme critère d'accessibilité (WCAG 2.1, critère 1.3.5 « identifier la finalité des champs »). Entre champs découpés, noms exotiques et copier-coller bloqué, un formulaire qui casse l'autofill transforme 30 secondes en 3 minutes, sur mobile surtout.
<input name="email" type="email" autocomplete="email" inputmode="email" />
<input name="name" autocomplete="cc-name" />
<input name="cardnumber" autocomplete="cc-number" inputmode="numeric" />
<input name="exp" autocomplete="cc-exp" inputmode="numeric" placeholder="MM/AA" />
<input name="cvc" autocomplete="cc-csc" inputmode="numeric" />
<!-- inputmode="numeric" : clavier numerique sur mobile -->
<!-- Ne jamais bloquer le copier-coller ni casser la saisie avec des espaces forces -->Chapitre 3. Wallets first et guest checkout : raccourcir le chemin.
La meilleure optimisation de formulaire consiste à ne pas avoir de formulaire du tout. Un paiement wallet (Apple Pay, Google Pay, PayPal, et demain Wero) réunit en un geste l'authentification du porteur par la biométrie du téléphone, les données de carte tokenisées et l'adresse de livraison. Là où une saisie complète prend 2 à 3 minutes sur mobile, un wallet conclut en moins de 30 secondes, et il satisfait nativement en Europe l'exigence d'authentification forte (SCA) de la DSP2.
Le principe wallets first affiche les boutons express (Apple Pay, Google Pay, PayPal) en haut du checkout, voire dès la page panier, avant le formulaire classique. Le client équipé saute toutes les étapes ; les autres descendent vers la carte. Selon le Global Payments Report de Worldpay (édition 2025), les wallets représentent déjà plus de la moitié des dépenses e-commerce mondiales, et l'Europe, en retard, suit la même pente. Une précaution technique s'impose, celle de n'afficher que les wallets réellement disponibles sur l'appareil (Apple Pay sur Safari/iOS, etc.). Un bouton mort est pire qu'aucun bouton.
// Detection cote navigateur avant d'afficher le bouton express
if (window.ApplePaySession && ApplePaySession.canMakePayments()) {
showButton("apple-pay")
}
// Approche standard multi-wallets : Payment Request API
const request = new PaymentRequest(methods, details)
const canPay = await request.canMakePayment()
if (canPay) showExpressCheckout()Guest checkout : le compte est une option, jamais un péage
26 % des abandonnistes citent la création de compte imposée (Baymard, 2024). La règle est simple. L'achat invité est le chemin par défaut ; la création de compte se propose après la confirmation (« créez un mot de passe pour suivre votre commande »). L'e-mail et l'adresse sont déjà saisis, il ne manque qu'un champ. La littérature UX cite un cas d'école où ASOS a réduit massivement ses abandons en remplaçant l'écran « créer un compte » par un écran invitant simplement le nouveau client à continuer, le compte se créant au même moment, seul le mot ayant disparu.
| Stratégie | Friction | Effet conversion | Effet données/CRM |
|---|---|---|---|
| Compte obligatoire avant achat | Maximale | -26 % d'acheteurs potentiels (Baymard 2024) | Base client riche mais plus petite |
| Guest checkout pur | Minimale | Meilleure conversion immédiate | Client difficile à retenir |
| Guest + création de compte post-achat | Minimale à l'achat | Meilleure conversion et rétention | Le bon compromis pour la plupart des sites |
| Connexion wallet/réseau (Apple Pay, PayPal) | Quasi nulle | Excellente sur mobile | Données limitées à ce que partage le wallet |
Pour les clients qui reviennent, la brique complémentaire est le paiement en un clic. La carte est tokenisée au premier achat, avec un consentement explicite que la DSP2 exige en Europe pour le stockage de justificatifs, puis rejouée ensuite. Les network tokens de Visa et Mastercard remplacent le PAN par un jeton propre au marchand, et ce jeton suit en cas de carte réémise. Les réseaux revendiquent un gain de taux d'autorisation de l'ordre de deux à trois points (Visa, 2024).
Chapitre 4. Mobile first et accessibilité : concevoir pour tous les pouces.
Le trafic e-commerce est désormais majoritairement mobile, alors que la conversion mobile demeure structurellement inférieure au desktop, entre écran étroit, saisie pénible et interruptions permanentes. Chaque optimisation rapporte donc le plus sur mobile. Depuis le 28 juin 2025, l'accessibilité du parcours d'achat n'est plus une option, puisque l'acte européen d'accessibilité s'applique au e-commerce.
Les fondamentaux du checkout mobile
- Le bon clavier au bon champ :
inputmode="numeric"pour la carte et le CVV, clavier e-mail pour l'e-mail. Faire chercher le pavé numérique sur un clavier alphabétique est une micro-torture répétée 20 fois. - Cibles tactiles généreuses : boutons et zones cliquables d'au moins 44×44 points, espacés, car un pouce n'est pas un curseur.
- Une colonne, un objectif par écran : le résumé de commande se replie, le bouton d'action principal reste visible (souvent épinglé en bas), le total toujours affiché.
- Wallets first encore plus qu'ailleurs : sur mobile, Face ID contre 16 chiffres + date + CVV + adresse, le match est plié.
- Performance : chaque seconde de chargement se paie en abandon ; le checkout doit être la page la plus rapide du site, pas la plus lourde en scripts tiers.
- Ne jamais perdre l'état : changement d'application pour consulter un SMS 3DS ou copier un IBAN. Au retour, panier et champs saisis doivent être intacts.
L'accessibilité : obligation légale et levier de conversion
L'OMS estime que 1,3 milliard de personnes vivent avec un handicap significatif (2023). Un checkout inaccessible leur ferme la caisse tout en dégradant l'expérience de tous les autres. Les sous-titres profitent aux open spaces, les gros boutons aux pouces pressés, les messages d'erreur explicites à tout le monde. La directive (UE) 2019/882, dite European Accessibility Act, rend l'accessibilité obligatoire pour les services de commerce électronique depuis le 28 juin 2025. Le référentiel technique est la norme EN 301 549, alignée sur WCAG 2.1 niveau AA, tandis qu'en France le RGAA 4 sert de base d'audit et que la DGCCRF est compétente pour les sanctions.
| Critère | Exigence | Erreur fréquente au checkout |
|---|---|---|
| 1.4.3 Contraste | Ratio 4,5:1 minimum pour le texte | Placeholders gris clair, mentions légales illisibles |
| 1.3.5 Finalité des champs | Attributs autocomplete corrects | Champs carte sans annotation, autofill cassé |
| 3.3.1 / 3.3.3 Erreurs | Erreur identifiée et suggestion de correction | « Champ invalide » en rouge sans dire pourquoi ni comment corriger |
| 2.1.1 Clavier | Tout doit être utilisable au clavier | Sélecteur de date ou modale 3DS piégeant le focus |
| 4.1.2 Nom, rôle, valeur | Composants exposés aux lecteurs d'écran | Faux boutons en <div>, iframes de paiement sans titre |
| 1.4.11 Contraste non textuel | Bordures de champs et icônes à 3:1 | Champs de formulaire quasi invisibles sur fond blanc |
Chapitre 5. Messages d'erreur : traduire les codes refus en ventes sauvées.
Le client a tout rempli, il clique sur « Payer », et la banque dit non. Le tunnel est alors au plus fragile. 9 % des abandons ont pour cause une carte refusée (Baymard, 2024), et la plupart de ces ventes étaient récupérables. Le refus arrive de l'émetteur sous forme d'un code normalisé, héritage de la norme ISO 8583, que votre PSP vous transmet. L'enjeu est de ne jamais afficher ce code brut, mais de le traduire en action possible pour le client.
Soft declines et hard declines : deux familles, deux stratégies
Un hard decline est définitif pour cette carte : vol, expiration, numéro invalide. Réessayer est inutile, voire dangereux. Un soft decline est circonstanciel : provision insuffisante, plafond atteint, émetteur injoignable. Depuis la DSP2, un quatrième cas est devenu massif en Europe, l'authentification requise. L'émetteur refuse la transaction non authentifiée, mais l'acceptera si on la relance avec 3-D Secure (code Visa « 1A », Mastercard « 65 »). Ce dernier cas doit être traité automatiquement par votre PSP, sans même que le client le voie.
| Code | Signification réseau | Type | Ce qu'il faut afficher / faire |
|---|---|---|---|
| 05 | Do not honor (refus générique émetteur) | Soft | « Votre banque n'a pas autorisé ce paiement. Réessayez ou utilisez un autre moyen. » Proposer wallet/virement. |
| 51 | Provision insuffisante | Soft | Message neutre (« paiement non autorisé »), suggérer un autre moyen ou un paiement en plusieurs fois. Ne jamais écrire « fonds insuffisants » : humiliant et parfois inexact. |
| 54 | Carte expirée | Hard (cette carte) | « Cette carte a expiré. » Pré-détectable côté front dès la saisie de la date : ne laissez pas arriver ce refus. |
| 14 | Numéro de carte invalide | Hard | Contrôle de Luhn côté client avant tout appel : cette erreur ne devrait jamais atteindre l'émetteur. |
| 41 / 43 | Carte perdue / volée | Hard | Message générique, ne jamais inviter à réessayer ni révéler le motif. Proposer un autre moyen. |
| 57 | Transaction non permise au porteur | Hard | Carte inadaptée (ex. carte à autorisation restreinte) : proposer un autre moyen. |
| 59 | Suspicion de fraude | Soft/Hard | Message générique absolument neutre. Ne jamais dire « fraude » à un possible fraudeur ni à un client honnête. |
| 61 | Plafond de paiement dépassé | Soft | « Le plafond de votre carte semble atteint. » Suggérer d'appeler la banque, de payer en plusieurs fois ou par virement. |
| 91 | Émetteur indisponible | Soft | Retry automatique différé côté serveur ; côté client, « réessayez dans quelques instants ». |
| 1A / 65 | Authentification requise (soft decline SCA) | Soft | Relance automatique en 3-D Secure par le PSP. Le client ne doit jamais voir ce refus. |
Les quatre règles d'or du message d'erreur de paiement
- Dire ce qui s'est passé sans accuser : « votre banque n'a pas autorisé ce paiement » plutôt que « votre carte a été refusée ». Le refus vient de l'émetteur, autant le dire, ça oriente le client vers le bon interlocuteur.
- Toujours proposer une porte de sortie : autre carte, wallet, virement, réessayer plus tard. Un message d'erreur sans action possible est une impasse commerciale.
- Préserver l'état : panier intact, champs conservés (sauf le CVV), pas de retour à la case départ. Un client qui doit tout ressaisir après un refus est un client perdu.
- Ne jamais divulguer d'information exploitable : ne pas distinguer « carte volée » de « refus générique » à l'écran, car les fraudeurs testent les cartes justement pour lire ces réponses. Le détail va dans vos logs, pas sous les yeux de l'acheteur.
{
"05": { "retry": true, "message": "Votre banque n'a pas autorise ce paiement. Reessayez ou choisissez un autre moyen." },
"51": { "retry": true, "message": "Paiement non autorise. Essayez un autre moyen ou le paiement en plusieurs fois." },
"54": { "retry": false, "message": "Cette carte a expire. Merci d'utiliser une carte en cours de validite." },
"41": { "retry": false, "message": "Ce paiement n'a pas pu aboutir. Merci d'utiliser un autre moyen de paiement." },
"43": { "retry": false, "message": "Ce paiement n'a pas pu aboutir. Merci d'utiliser un autre moyen de paiement." },
"91": { "retry": true, "message": "Service momentanement indisponible. Reessayez dans quelques instants." },
"1A": { "retry": "auto-3ds", "message": null }
}Chapitre 6. A/B tests : expérimenter sans se raconter d'histoires.
Tout ce qui précède fournit des hypothèses solides ; chaque site a pourtant sa clientèle, son panier moyen, son mix d'appareils. La seule vérité est expérimentale. L'A/B test compare deux versions du checkout sur des populations aléatoires et mesure la différence. Mal fait, il produit des certitudes fausses, plus dangereuses que l'ignorance ; bien fait, il transforme le checkout en machine à apprendre.
Les pièges classiques qui invalident un test
- Le peeking : regarder les résultats chaque jour et arrêter dès que « ça devient significatif ». À force de regarder, on finit toujours par croiser un faux positif. Remède : fixer la durée et la taille d'échantillon avant de lancer, et s'y tenir (ou utiliser des méthodes séquentielles conçues pour ça).
- L'échantillon trop petit : avec ~2-3 % de conversion de base, détecter une amélioration relative de 10 % exige des dizaines de milliers de sessions par variante. Sur un petit site, mieux vaut moins de tests, plus radicaux.
- Le SRM (sample ratio mismatch) : vous attendiez 50/50, vous observez 53/47, et la randomisation est cassée (bug de script, cache, bots). Tout résultat est alors invalide, aussi séduisant soit-il.
- La mauvaise métrique : mesurer les clics sur « Payer » plutôt que les paiements réussis (autorisés !), ou la conversion plutôt que le revenu par session, alors qu'un test peut augmenter la conversion en attirant des petits paniers.
- Le contexte pollué : soldes, campagne TV, changement de PSP en cours de test. Un test propre vit dans un environnement stable.
- Oublier les segments : un gain global peut cacher +8 % desktop et -6 % mobile. Toujours lire mobile et desktop séparément, sans pour autant découper en 40 segments jusqu'à trouver un vainqueur (c'est du peeking déguisé).
| Métrique | Définition | Rôle dans le test |
|---|---|---|
| Conversion checkout | Paiements réussis / entrées dans le checkout | Métrique primaire la plus courante |
| Revenu par session | CA / sessions exposées | Primaire quand la variante peut changer le panier moyen |
| Taux d'autorisation | Paiements autorisés / tentatives | Garde-fou : une variante ne doit pas dégrader l'acceptation |
| Taux d'erreur formulaire | Sessions avec au moins une erreur de champ | Diagnostic : explique pourquoi une variante gagne |
| Délai de complétion | Temps médian panier → confirmation | Diagnostic de friction |
| Part wallets / carte / BNPL | Répartition des moyens choisis | Garde-fou : surveiller les reports de mix (et leurs coûts) |
Chapitre 7. Benchmarks Baymard et plan d'action.
Le Baymard Institute audite en continu les plus grands sites e-commerce mondiaux, sur plusieurs centaines de directives UX issues de tests utilisateurs. Le verdict est constant, et même les leaders du secteur présentent des dizaines de violations dans leur checkout. Personne n'a fini, et le benchmark sert surtout à prioriser. Voici la synthèse opérationnelle du cours.
autocomplete et inputmode, contrôle de Luhn côté client, labels permanents, messages de refus traduits, champ code promo replié, CVV expliqué d'un mot.- Mesurer avant de toucher : instrumenter chaque étape de l'entonnoir et le taux d'autorisation par code refus, car une semaine de données vaut mieux qu'un mois d'opinions.
- Soustraire : chaque champ et chaque étape doit justifier son existence. Cible : 7-8 champs pour une commande invitée.
- Prioriser mobile : c'est là que sont les volumes et la friction ; les wallets y font le plus gros écart.
- Traiter le refus comme une étape UX : messages traduits, panier préservé, alternative immédiate, soft declines relancés en 3DS.
- Expérimenter proprement : une hypothèse par test, taille fixée d'avance, SRM vérifié, segments lus sans triche.
- Auditer l'accessibilité : la conformité EAA du 28 juin 2025 est aussi votre meilleure checklist de conversion.