Tunnel de commande PrestaShop : réduire les abandons entre le panier et le paiement

Le tunnel de commande natif de PrestaShop enchaîne quatre étapes : identité, adresses, transporteur, paiement. Au 14 octobre 2026, la version 9.2, sortie le 30 septembre, y ajoute une commande sur une seule page, à activer. Refaire le tunnel commence par la mesure : l’étape où vos clients décrochent décide de ce qui change.

• Le tunnel de commande natif de PrestaShop 8 enchaîne quatre étapes
• Plusieurs motifs d’abandon d’un panier PrestaShop se rattachent à un réglage
• La mesure étape par étape précède toute refonte du tunnel de commande
• PrestaShop 9.2 propose une commande en une page, à activer dans le back-office
• Le coût d’un chantier de tunnel se chiffre sur l’inventaire des modules à retester
• Les livrables à exiger du prestataire d’un chantier de tunnel
• Des retouches mal pensées aggravent les abandons du tunnel de commande PrestaShop
• Sources consultées
• Foire aux questions

Le tunnel de commande natif de PrestaShop 8 enchaîne quatre étapes

La documentation développeur de PrestaShop 8 nomme quatre étapes, dans l’ordre. « checkout-personal-information-step » : le client se connecte ou saisit ses coordonnées en invité. « checkout-addresses-step » : adresses de livraison et de facturation. « checkout-delivery-step » : choix du transporteur. « checkout-payment-step » : choix du moyen de paiement. La validation crée ensuite la commande.

Un panier de produits virtuels, c’est-à-dire téléchargeables, saute les adresses et le transporteur. Les transporteurs proposés dépendent de l’adresse, du poids et des prix du panier et du groupe du client. Les moyens de paiement se restreignent par devise, pays et groupe.

La documentation de la 1.6, sans support de l’éditeur depuis le 30 juin 2019, décrit un réglage « Type de processus de commande » (Order process type). Il choisit entre les cinq étapes, chacune sur sa page, et une seule page.

Plusieurs motifs d’abandon d’un panier PrestaShop se rattachent à un réglage

Plusieurs motifs d’abandon renvoient à un écran ou à un réglage de PrestaShop, du transporteur à la commande invité. Baymard Institute compile 50 études. Selon son enquête sur les raisons d’abandon, 42 % des acheteurs en ligne américains ont déjà abandonné un panier parce qu’ils ne faisaient que regarder : une part des abandons échappe à tout tunnel. Le tableau reprend huit des autres motifs, chiffrés par la page mise à jour le 22 septembre 2025, sans base précisée par Baymard.

Un parcours américain moyen affiche 23,48 éléments de formulaire selon Baymard, contre 12 à 14 pour un parcours idéal. Aucun de ces chiffres ne décrit votre boutique : ils donnent un ordre de grandeur, pas un diagnostic.

La mesure étape par étape précède toute refonte du tunnel de commande

Avant de toucher au code, demandez le nombre de sessions qui entrent à chacune des quatre étapes et le nombre qui en sortent, téléphone et ordinateur séparés. Sans cette base, aucune amélioration ne se prouve. Une étape non mesurée reste indéterminée, pas réussie.

Les pages de documentation lues ne décrivent aucune adresse distincte par étape. Demandez comment chacune est repérée dans l’outil de mesure : événement ou paramètre.

La page Commandes > Paniers (Orders > Shopping carts) liste les paniers ; ceux restés sans commande portent un lien de suppression en bout de ligne. Elle dit combien sont restés en route et ce qu’ils contenaient ; la documentation ne dit pas qu’elle indique l’étape où le client s’est arrêté. La lecture sur téléphone relève de la mission boutique sur mobile.

Décrire mon besoin →

PrestaShop 9.2 propose une commande en une page, à activer dans le back-office

L’annonce de la 9.2.0, le 30 septembre 2026, place « One Page Checkout » dans la version stable. La page « Notable changes in PrestaShop 9.2.x » de la documentation développeur décrivait encore la 9.2 comme une version bêta le 14 octobre 2026. Le module « ps_onepagecheckout » est installé par défaut, mais le marchand l’active. Le menu Design (Apparence) > Checkout propose la disposition « One-page checkout » ; « Four-page checkout » rétablit les quatre étapes.

Pour un invité, l’adresse e-mail suffit au départ. La connexion et la création de compte passent sur des pages distinctes, hors du tunnel.

Les thèmes issus de Hummingbird fonctionnent sans retouche. Un thème issu de Classic ou sur mesure demande des copies de gabarits (les fichiers de mise en page) plus larges. Un gabarit qui supprime un identifiant attendu casse le script du tunnel. Les modules de paiement et de transport se testent avec ce parcours : leurs éléments ajoutés à la page doivent se réinitialiser après un changement de transporteur ou d’adresse.

Le module déclare la 9.2.0 au minimum : une boutique en 8.2 ou en 1.7 n’y accède qu’après une migration. La 9.2 se met à jour depuis la 9.0.x ou la 9.1.x avec le module Update Assistant. Les annonces de l’éditeur ne disent pas si une 8.x la rejoint en un seul passage.

Un module tiers de commande en une page, installé avant la 9.2, se vérifie auprès de son auteur. Le guide « One Page Checkout for module developers » prévoit le cas de deux fournisseurs actifs déclarés par le point d’accroche « actionCheckoutBuildProcess » : le parcours natif reprend alors la main.

Le coût d’un chantier de tunnel se chiffre sur l’inventaire des modules à retester

Le chiffrage part de votre inventaire. Selon toute vraisemblance, le prix monte avec le nombre de modules de paiement et de transport, le thème (Hummingbird, Classic ou sur mesure), les langues et les devises, et les règles par groupe de clients. Une préproduction, copie de la boutique invisible des clients, s’ajoute. Le retest sur téléphone se chiffre à part.

Sur une boutique en 8.2, un tunnel sur mesure bâti sur le thème actuel peut se reprendre au passage en 9. Faites chiffrer les deux ordres, tunnel d’abord ou migration d’abord, et demandez quels fichiers survivent.

Un paiement qui tombe en panne après intervention pose la question du retour arrière. Faites écrire qui le paie et en combien d’heures il s’exécute : un contrat muet se négocie après la panne.

Décrire mon besoin →

Les livrables à exiger du prestataire d’un chantier de tunnel

Exigez trois livrables : la mesure par étape avant et après, un essai d’achat réel avec chaque moyen de paiement et chaque transporteur, la liste des fichiers modifiés du thème et des modules. Cette liste évite qu’une mise à jour future écrase les retouches sans prévenir.

L’essai passe en invité, sur téléphone, avec un panier mêlant produits en stock et produits sur commande. Le compte administrateur peut ne pas reproduire ce qu’un client voit.

La conformité du paiement lui-même relève de la mission conformité des paiements. La mesure globale des visites qui deviennent commandes relève de taux de conversion.

Des retouches mal pensées aggravent les abandons du tunnel de commande PrestaShop

Ajouter des champs pour mieux connaître le client allonge un formulaire dont la moyenne américaine, selon Baymard, approche déjà le double de l’idéal. La page « Customer Preferences » de la documentation de la 8 recommande, pour la date de naissance (« Demander la date de naissance », Ask for birthdate), d’expliquer pourquoi vous la demandez.

Relancer chaque panier par un bon de réduction expose à l’abus que la page « Shopping carts » de la documentation de la 8 signale : certains clients abandonnent exprès leur panier pour le recevoir.

Dans le message du formulaire de cette page, reportez votre version de PrestaShop, vos modules de paiement et de transport, et l’étape où vos clients décrochent.

Sources consultées

• PrestaShop, documentation développeur de PrestaShop 8, « Orders lifecycle », étapes de la commande, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Orders preferences », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Carriers », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Shopping carts », consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 8, « Customer Preferences », et documentation française de PrestaShop 1.7, « Préférences clients », consulté le 14 octobre 2026.
• PrestaShop, documentation de PrestaShop 1.6, « Orders preferences » et, en français, « Préférences des commandes », consulté le 14 octobre 2026.
• PrestaShop, « 1.6.1.x : what’s next », 2019, fin du support officiel de la 1.6, consulté le 14 octobre 2026.
• PrestaShop, documentation française de PrestaShop 1.7, « Préférences des commandes », « Gérer les transporteurs » et « Paniers », consulté le 14 octobre 2026.
• Baymard Institute, « Cart Abandonment Rate Statistics », mise à jour du 22 septembre 2025, consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 9.2 is available », 30 septembre 2026, et « Introducing One Page Checkout », 22 juillet 2026, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Notable changes in PrestaShop 9.2.x », « One Page Checkout for module developers » et « One Page Checkout for theme developers », consulté le 14 octobre 2026.
• Ecommerce Nation, « Livraison : ce qui pousse 1 Français sur 3 à ne pas finaliser son achat », 21 novembre 2025, consulté le 14 octobre 2026.

Foire aux questions

Quel taux d’abandon de panier est normal ?

Baymard Institute donne une moyenne de 70,22 % sur 50 études, tous sites confondus. Une étude de Sendcloud publiée en 2025, qui compte 1 000 répondants français, relève que 36,9 % des e-acheteurs français ont abandonné un achat en ligne en douze mois à cause d’un problème lié à la livraison.

La commande en une page convertit-elle mieux ?

Les pages de l’éditeur lues ne chiffrent aucun gain. Baymard estime à 35,26 % la hausse de conversion d’un grand site qui corrigerait ses défauts d’ergonomie connus, sans lien avec la commande en une page. Seule votre mesure, avant et après, dira si le changement paie.

Comment relancer les paniers abandonnés avec PrestaShop ?

Par défaut, c’est à vous de contacter le client. Le module Relances (Reminder), livré avec l’installation, envoie des bons de réduction aux clients qui ont laissé un panier. Un module payant de relance figure sur le catalogue des modules de l’éditeur.

Faut-il faire accepter les conditions générales avant de payer ?

L’option « Conditions générales de vente » (Terms of service) oblige le client à accepter vos conditions avant de valider. Elle pointe vers une page de contenu statique créée dans Apparence > Pages (Design > Pages). La documentation ne dit pas ce que la loi impose à votre activité : faites valider le texte par votre conseil.