Pourquoi le checkout PrestaShop natif perd des clients sur mobile
Conversion & UX

Pourquoi le checkout PrestaShop natif perd des clients sur mobile

Le tunnel de commande de PrestaShop a été conçu pour un écran large. Sur mobile, où passe désormais la majorité du trafic, il conserve des choix d’interface qui coûtent des commandes à chaque étape.

Voici l’analyse écran par écran, avec ce qui se corrige sans refonte.

Écran 1 : le panier

Trois problèmes récurrents.

Le bouton de commande sous la liste. Sur un panier de cinq articles, il se trouve sous un long défilement. Le comportement attendu est un bouton fixe en bas d’écran, affichant le total, visible en permanence.

Les sélecteurs de quantité minuscules. Les boutons plus et moins font souvent moins de trente pixels. La recommandation d’accessibilité situe la cible tactile minimale autour de quarante-quatre pixels de côté. En dessous, le client se trompe de bouton, ce qui l’oblige à corriger et l’agace.

La suppression sans confirmation ni annulation. Un appui accidentel sur la corbeille vide une ligne sans recours. Une option d’annulation temporaire évite le rechargement mental complet du panier.

Écran 2 : identification

C’est l’écran qui produit le plus d’abandons sur mobile, et deux détails techniques y suffisent.

Le champ email n’appelle pas le bon clavier. Un champ correctement typé fait apparaître un clavier avec l’arobase accessible. Sans cela, le client passe par la touche de bascule à chaque saisie.

Le remplissage automatique ne fonctionne pas. Les navigateurs savent remplir email, nom, adresse et carte bancaire, à condition que les champs portent les indications d’auto-complétion attendues. Un formulaire correctement annoté se remplit en deux appuis. Un formulaire sans annotation impose une saisie complète.

C’est probablement la correction la plus rentable de tout le tunnel, et elle ne demande que d’ajouter des attributs aux champs existants.

Troisième point : le mot de passe. Si vous imposez la création de compte, l’absence d’option pour afficher le mot de passe saisi produit des erreurs répétées sur un clavier tactile.

Écran 3 : l’adresse

Le formulaire d’adresse est le plus long du tunnel et le moins bien adapté.

Trop de champs. Beaucoup de configurations demandent société, complément d’adresse, second complément, téléphone fixe et mobile. Sur mobile, chaque champ supplémentaire est un obstacle. Réduisez au strict nécessaire et masquez les champs facultatifs derrière un lien.

Le code postal n’appelle pas le clavier numérique. Même remarque que pour l’email : le type de champ détermine le clavier proposé.

L’ordre des champs ne suit pas la logique locale. En France, on saisit le code postal avant la ville, et le premier devrait pré-remplir la seconde. Cette autocomplétion supprime un champ entier et réduit les erreurs.

Les erreurs s’affichent après validation. Un formulaire qui signale cinq erreurs en bloc après un appui sur le bouton oblige à remonter dans la page. La validation au fil de la saisie, champ par champ, est nettement moins frustrante.

Checkout Simple & Élégant pour PrestaShopUn checkout one-page élégant qui convertit€99.00

Écran 4 : la livraison

Deux problèmes.

Les options de transport en radio serrés. Trois transporteurs présentés en lignes compactes avec des boutons radio de petite taille produisent des sélections erronées. Chaque option devrait être une carte entièrement cliquable.

Le point relais dans une carte non adaptée. Les modules de point relais affichent souvent une carte conçue pour desktop, avec des repères minuscules et un zoom capricieux. Sur mobile, une liste ordonnée par distance, avec la carte en option, fonctionne mieux.

Écran 5 : le paiement

C’est l’écran où un problème coûte le plus cher, puisque tout l’effort précédent est perdu.

Le clavier numérique pour la carte. Le numéro de carte, la date d’expiration et le code de sécurité doivent appeler un clavier numérique. C’est encore fréquemment mal configuré, y compris dans des modules de paiement récents.

Le remplissage automatique de la carte. Les navigateurs et les gestionnaires de mots de passe savent remplir une carte enregistrée, sous réserve des indications d’auto-complétion correctes. Sans elles, le client doit sortir sa carte physique, ce qui interrompt le parcours et laisse le temps de renoncer.

La redirection vers une page bancaire non adaptée. L’authentification forte ouvre parfois une page à l’affichage cassé sur mobile. Testez ce parcours en conditions réelles, avec une vraie carte : c’est le point du tunnel le moins testé et le plus critique.

Le retour après authentification. Si le client bascule vers son application bancaire pour valider, il quitte le navigateur. Le retour doit restituer la session et poursuivre la commande, pas repartir du panier.

Les problèmes transversaux

Quatre éléments qui affectent tous les écrans.

Le zoom automatique à la mise au point. Sur certains navigateurs mobiles, un champ dont la taille de police est inférieure à seize pixels déclenche un zoom automatique à la sélection, ce qui décale toute la page. La correction consiste à ne jamais descendre sous cette taille dans les formulaires.

Le clavier qui masque le champ actif. Sur un formulaire long, le clavier virtuel recouvre parfois le champ en cours de saisie. Le défilement doit s’ajuster à l’ouverture du clavier.

Les bandeaux fixes cumulés. En-tête fixe, bandeau cookies, bandeau promotionnel : sur un écran de téléphone, il ne reste parfois qu’un tiers de la hauteur pour le contenu. Dans le tunnel, supprimez tout ce qui n’est pas nécessaire.

Le temps de chargement entre étapes. Chaque rechargement complet est une occasion d’abandon. Un tunnel en une page, ou avec des transitions sans rechargement, supprime ces points de rupture.

La méthode de diagnostic

Trois actions, dans cet ordre, avant toute modification.

Passez une commande sur votre propre téléphone, en conditions réelles, avec une vraie carte et un réseau mobile plutôt qu’un accès sans fil. Cela révèle en dix minutes l’essentiel des problèmes.

Relevez le taux de complétion par étape, séparément sur mobile et sur ordinateur. L’écart entre les deux localise le problème : si le mobile décroche à l’adresse, inutile de retoucher le paiement.

Regardez des enregistrements de sessions mobiles qui n’ont pas abouti. Les hésitations, les corrections répétées et les zooms manuels se voient immédiatement et désignent les champs problématiques.

Par où commencer

Si vous ne devez faire que trois choses, prenez celles-ci.

Les attributs d’auto-complétion sur tous les champs du tunnel. Coût faible, effet immédiat, et cela profite à tous les navigateurs.

Les types de champs, pour que chaque saisie appelle le bon clavier. Même logique, même rapport effort sur résultat.

Les zones tactiles portées à quarante-quatre pixels minimum sur tous les éléments interactifs du tunnel.

Ces trois corrections ne demandent aucune refonte et traitent la majorité des frictions mesurables.

Le module Checkout Simple et Élégant pour PrestaShop reprend ce parcours sur PrestaShop 8 et 9 : tunnel en une page sans rechargement entre étapes, formulaire d’adresse allégé avec pré-remplissage de la ville par le code postal, types de champs et attributs d’auto-complétion correctement posés, et zones tactiles dimensionnées pour le mobile.

À lire ensuite

Articles similaires