Nous avons teste le One Page Checkout natif de PrestaShop 9.2 : ce qui marche, ce qui ne marche pas, et quand il vous en faut plus

Testé en juillet 2026 sur PrestaShop 9.2.0 bêta 1.

PrestaShop 9.2 intègre un One Page Checkout natif. Pour quiconque gère une boutique, cela transforme une vieille certitude en vraie question : si le tunnel de commande est désormais intégré, avez-vous encore besoin d'un module de checkout ?

Nous ne voulions pas répondre à partir des notes de version. Nous avons donc installé la bêta 9.2 dans un conteneur propre, activé le one page checkout natif et parcouru tout le tunnel avec un navigateur piloté par script, en journalisant chaque navigation, chaque script, chaque requête XHR et document (les ressources statiques comme les images et les polices étaient exclues du journal) ainsi que les temps. Cet article rapporte ce que les instruments ont réellement mesuré.

L'essentiel avant le détail : c'est mieux que ce que nous attendions. Nous sommes partis avec un soupçon précis, à savoir que saisir une adresse forcerait discrètement des rechargements de page et que le "one page" ne serait vrai que sur le papier. Ce soupçon était faux, et nous le disons en premier parce que c'était précisément ce que nous nous attendions le plus à trouver.

Ce n'est pas parfait, mais les aspérités sont plus petites que ce que nous avions d'abord rapporté. Deux de nos constats initiaux se sont révélés être des défauts de notre propre script de test, et nous les retirons plus bas plutôt que de les laisser en place. Il reste une requête dupliquée, des attributs de formulaire manquants, un problème de mise en page mobile, et un choix de conception délibéré qui retire quelque chose que l'ancien tunnel savait faire.

Avant tout : notre conflit d'intérêts

Nous vendons des modules de checkout PrestaShop. Un tunnel natif dans le cœur est, commercialement, un concurrent pour nous. Lisez donc tout ce que nous en disons en gardant cela à l'esprit.

Voici comment nous avons traité la question, pour que vous puissiez vérifier notre travail plutôt que de faire confiance à nos intentions. Chaque affirmation ci-dessous est un chiffre que nous avons relevé ou une capture que nous avons prise, sur une installation que n'importe qui peut reproduire depuis une image Docker publique. Là où nous nous attendions à trouver un défaut et n'en avons pas trouvé, nous le disons. Là où notre première lecture était fausse, nous l'avons corrigée au lieu de garder la version qui nous arrangeait : nous pensions d'abord que les codes de réduction manquaient au nouveau tunnel, ce qui est faux. Les étapes d'installation, les versions exactes et tout ce que nous n'avons pas pu tester sont listés. Si une mesure ne se reproduit pas chez vous, dites-le nous et nous irons voir.

Ce que nous avons testé, exactement

Chaque chiffre ci-dessous vient de cet environnement. Si quelque chose ne se reproduit pas chez vous, cela peut venir de votre version, de votre configuration ou de notre méthode, et nous préférons le savoir.

Deux remarques d'installation relèvent de l'honnêteté. D'abord, l'installation par défaut n'avait aucun transporteur desservant le pays de la boutique, parce que le Royaume-Uni se trouve dans la zone "Europe (hors UE)" alors que les transporteurs d'exemple ne couvrent que deux autres zones. Nous avons affecté les transporteurs à cette zone, ce qui relève de la configuration marchande ordinaire et non d'un problème de tunnel. Ensuite, les temps proviennent d'un réseau local : voyez-les comme une comparaison entre les deux tunnels sur un matériel identique, pas comme des valeurs que votre boutique reproduira.

Ce qu'est réellement l'OPC natif de 9.2

Il arrive sous forme de module, ps_onepagecheckout, inclus dans le paquet 9.2. Deux détails que nous avons confirmés à l'installation méritent d'être connus avant de planifier quoi que ce soit :

• Il est désactivé par défaut. Après une installation propre de 9.2, le module est présent et activé, mais le réglage PS_ONE_PAGE_CHECKOUT_ENABLED vaut 0. Vous l'activez depuis Design > Checkout dans le back-office, et vous pouvez revenir au tunnel classique en quatre pages quand vous voulez.
• C'est 9.2 ou rien. Le module déclare ps_versions_compliancy avec un minimum de 9.2.0. Une boutique en 1.7, 8.x, 9.0 ou 9.1 ne peut pas l'installer.

Sur le plan architectural, il fait ce que décrit l'annonce officielle sur le blog build de PrestaShop. Il injecte son propre processus de commande via un hook du cœur au lieu de surcharger le contrôleur de commande, et remplace les quatre classes d'étapes par une seule étape combinée. La connexion et la création de compte ont été volontairement sorties du tunnel vers des pages dédiées. Nous avions traité la conception avant sa sortie dans ce que marchands et développeurs doivent savoir sur l'OPC natif de 9.2. Cet article remplace les suppositions d'alors par des mesures.

Le benchmark

Le one page checkout natif de 9.2 avec l'adresse renseignée. Mode de livraison, moyen de paiement, conditions et bouton de paiement sont tous sur le même écran, et le récapitulatif à droite se met à jour en direct.

Même boutique, même produit, mêmes valeurs d'adresse, mêmes transporteurs, chaque fois dans un panier neuf. Les deux parcours étaient équivalents plutôt qu'identiques action par action, puisque les deux tunnels ne proposent pas les mêmes actions. Les "chargements de page complets" comptent les navigations du frame principal depuis l'ouverture du tunnel jusqu'à la confirmation de commande.

La même boutique avec le one page checkout désactivé. Trois des quatre étapes sont inaccessibles tant que la précédente n'est pas terminée, et chaque étape validée coûte un chargement de page complet.

Évaluez cet échange honnêtement, et gardez la taille de l'échantillon en tête. Ce sont cinq exécutions sur un réseau local, donc purement descriptives. L'écart au premier affichage en particulier se situe à l'intérieur de la dispersion entre exécutions (one page checkout 152 à 180 ms, classique 148 à 188 ms) et nous ne le présenterions pas comme une vraie différence. L'écart sur DOMContentLoaded et les volumes en octets, eux, étaient constants sur toutes les exécutions. Le one page checkout met environ 50 ms de plus pour atteindre DOMContentLoaded et embarque à peu près 28 Ko de JavaScript en plus, parce qu'il rend contact, adresse, livraison, paiement et récapitulatif dans un seul document au lieu d'une étape à la fois. En échange, il supprime trois chargements de page complets du parcours. Sur n'importe quelle connexion réelle, trois allers-retours serveur en moins l'emportent largement sur 50 ms de rendu local.

Là où l'hypothèse de l'adresse est morte

C'était précisément ce que nous cherchions à prendre en défaut, voici donc le détail brut par action. Chacune a été enregistrée avec le journal réseau du navigateur.

Ajouter une adresse ne recharge pas la page. En modifier une ne recharge pas la page. Changer de pays ne recharge pas la page : le formulaire d'adresse est reconstruit en AJAX, parce que les champs obligatoires et le comportement fiscal changent. Le changement de transporteur a mis à jour le total en direct, de 19,12 EUR à 26,12 EUR, sans la moindre navigation.

La logique de rafraîchissement est aussi plus soignée que nous ne le pensions. Modifier la ligne de rue, qui ne peut pas changer un prix de livraison, a déclenché une unique requête d'enregistrement de brouillon et rien d'autre. Transporteurs et options de paiement n'étaient rechargés que lorsque quelque chose les concernant vraiment changeait, comme le pays ou l'adresse complétée. C'est un comportement sensé, avec une réserve : nos transporteurs d'exemple étaient à tarif fixe, un changement de code postal ne pouvait donc pas modifier le prix. Un transporteur qui tarifie au code postal demanderait son propre test, car ici une modification de rue et une modification de code postal n'ont produit qu'un enregistrement de brouillon.

Ce qu'il fait bien

Le reconnaître correctement compte, car ce sont les points que les marchands vont ressentir.

• C'est vraiment un seul écran. Contact, adresse de livraison, mode de livraison, paiement, récapitulatif et bouton de paiement sont tous dans un formulaire unique dès le premier affichage. Aucun verrouillage par étapes, rien de replié derrière un bouton "continuer".
• Les états d'attente s'expliquent d'eux-mêmes. Tant que l'adresse est incomplète, les blocs livraison et paiement ne restent pas vides. Ils indiquent "Complétez votre adresse de livraison ci-dessus pour voir vos options de livraison" puis listent exactement ce qui manque : "Encore nécessaire : Prénom, Nom, Adresse, Ville, Code postal". C'est un micro-texte remarquablement clair pour un tunnel par défaut.
• La validation en ligne bloque les données invalides sans rechargement. Avec la France sélectionnée (qui définit un format de code postal), saisir ABC a marqué le champ comme invalide, affiché "Code postal invalide, il devrait ressembler à "NNNNN"", remplacé la liste des transporteurs par "Veuillez corriger les champs d'adresse en surbrillance" et refusé la soumission. Un clic sur Payer a produit zéro requête réseau et a remis le focus dans le formulaire. Rien n'a été perdu, rien n'a été rechargé. Dans le test distinct où nous avions vidé un champ Ville obligatoire, le navigateur a mis le focus exactement sur ce champ à la soumission.
• Le bouton de paiement reste honnête. Il reste désactivé tant qu'un consentement obligatoire manque, ce que nous avons enregistré avec un client de retour dont le transporteur et le paiement étaient déjà résolus mais dont la case des conditions n'était pas cochée, et il affiche le total en direct sur lui-même. Ce n'est pas un indicateur complet de disponibilité : avec un champ Ville obligatoire vidé, il est resté actif, et c'est le navigateur plutôt que le tunnel qui a bloqué l'envoi ("Payer 19,12 EUR", puis "Payer 26,12 EUR" après avoir choisi le transporteur payant).
• Les adresses enregistrées se gèrent sans quitter la page. Pour un client connecté, la liste d'adresses propose "Utiliser une autre adresse de livraison", et cette option comme le menu d'édition par adresse ouvrent une fenêtre modale sur le même écran. Ajouter ou modifier une adresse en plein tunnel ne fait jamais quitter la page.
• Les codes promo sont pris en charge et recalculent en direct. Le récapitulatif comporte un accordéon "Code promo" avec un champ "Collez votre bon ici". Appliquer un code a recalculé la remise, les transporteurs et les options de paiement en AJAX, sans aucun rechargement. Une chose à savoir : le champ n'apparaît qu'une fois qu'au moins une règle panier existe dans la boutique, car PrestaShop désactive toute la fonctionnalité tant qu'il n'y en a aucune.
• Les clients de retour bénéficient d'un chemin vraiment rapide. Connecté avec une adresse enregistrée, le formulaire était affiché en 193 ms, et la liste d'adresses, les deux transporteurs et les trois moyens de paiement se sont résolus quelques instants plus tard en AJAX, sans la moindre interaction. Finaliser la commande a demandé deux actions : cocher les conditions, cliquer sur payer. Le champ e-mail disparaît totalement pour un client connecté, exactement comme l'annonce le décrit.
• La mise en page mobile tient. À 375 px, aucun débordement horizontal (largeur du document 375 px, viewport 375 px), et le premier affichage de contenu à 152 ms. Les lignes de transporteur et la ligne des conditions ont de grandes zones tactiles (351x136 px et 327x48 px).

Un code postal français invalide. Le champ est signalé en ligne, la liste des transporteurs est remplacée par une invite de correction, et cliquer sur Payer n'a produit aucune requête réseau.

Un client connecté retrouve ses adresses enregistrées sous forme de cartes sélectionnables, avec un menu par adresse et la possibilité d'en ajouter une.

Ajouter une adresse ouvre une modale par-dessus le tunnel. La page derrière n'est jamais rechargée et rien de ce qui a déjà été saisi n'est perdu.

La page de confirmation de commande a elle aussi été retravaillée et paraît nettement plus nette que celle qu'elle remplace.

Les aspérités que nous avons réellement mesurées

Ce sont des choses que nous pouvons prouver, pas des impressions.

1. Le point d'accès des moyens de paiement est appelé deux fois

Chaque fois que l'adresse se résout, le tunnel demande ses options de paiement deux fois avec une URL identique à l'octet près :

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

Nous l'avons enregistré six fois dans quatre sessions de navigateur indépendantes : à la première saisie d'adresse et lors d'un changement de pays dans l'exécution invité, dans l'exécution mobile, dans une exécution avec code postal invalide, et lors d'un premier puis d'un second passage en caisse d'un client connecté. Le cas du second passage est le plus parlant, car il survient sur un simple chargement de page, sans aucune interaction scriptée. C'est une requête en double, pas deux états différents. Dans une boutique où les modules de paiement effectuent un vrai travail à chaque rendu (calcul de frais, règles de disponibilité, appels distants), c'est du temps serveur gaspillé sur la page la plus critique pour la conversion. C'est exactement le genre de chose qu'un module en 0.6.2 a encore à nettoyer.

2. Aucune indication d'autofill sur les champs d'adresse

Nous avons audité chaque champ du bloc adresse de livraison. Aucun ne porte d'attribut autocomplete, aucun ne porte d'inputmode :

L'autofill d'adresse des navigateurs et des téléphones repose sur ces jetons (given-name, address-line1, postal-code, etc.). Sans eux, la seule chose qui supprime le plus de saisie sur mobile fonctionne de façon peu fiable, ce qui dessert un tunnel dont l'objectif affiché est justement la friction mobile. Nous savons qu'il s'agit d'un oubli et non d'un choix, car la page d'inscription de 9.2 dans le même thème pose correctement les jetons : email, given-name, family-name, new-password et tel-national. Le formulaire d'adresse du tunnel, qui en aurait le plus besoin, n'en a aucun. Le téléphone utilise au moins type="tel", ce clavier-là est donc correct.

3. Impossible de créer un compte en commandant, et c'est une régression

Connexion et inscription ont été délibérément sorties du tunnel, ce que l'annonce indique clairement. Ce que cela signifie en pratique mérite d'être détaillé, car c'est un recul par rapport au tunnel qu'il remplace.

Nous avons comparé les deux tunnels sur la même boutique. Le tunnel classique en quatre étapes rend un véritable <input type="password" name="password"> à l'intérieur du tunnel, un acheteur peut donc créer un compte en commandant, et son "Se connecter" est un onglet dans la page. Le one page checkout n'a aucun champ mot de passe nulle part, et les deux commandes sont de simples liens qui font quitter la page :

Un client qui veut acheter et conserver un compte doit donc quitter le tunnel, s'inscrire sur une page distincte, puis revenir. Pour un tunnel pensé d'abord pour les invités, c'est une décision cohérente, et les acheteurs invités ne le remarquent jamais. Pour une boutique qui dépend des inscriptions au moment de l'achat, cela retire quelque chose que l'ancien tunnel savait faire. Cela signifie aussi que le moment où un client est le plus motivé pour s'inscrire, juste après avoir décidé d'acheter, est précisément celui où le tunnel ne le lui permet pas.

4. Sur mobile, le bouton de paiement est très loin en bas

Le one page checkout à 375 px. La mise en page tient sans débordement horizontal, mais tout le tunnel forme une seule colonne très haute.

Tout mettre sur un écran rend cet écran très haut. Sur un viewport de 375 px, le bouton de paiement se situe à 3337 px vers le bas, et il n'est pas collant : sa position calculée est static, sans ancêtre fixe ou collant. Même un client de retour avec une adresse enregistrée doit faire défiler tout le formulaire pour l'atteindre. Un récapitulatif ou une barre de paiement collante est la réponse habituelle, et elle n'est pas encore là.

5. C'est un module avant la 1.0, et son propre README le dit

Ce n'est pas un défaut, mais c'est le fait le plus important pour planifier. Le paquet bêta testé embarque la version 0.6.2 du module, alors qu'en amont la 0.6.5 avait déjà été taguée quelques jours avant notre test : traitez donc les numéros de version précis comme une cible mouvante. Et l'annonce bêta de PrestaShop est sans ambiguïté : "cette version bêta est un logiciel de préversion. Il est possible que vous rencontriez des problèmes. Ne l'utilisez pas dans votre boutique de production !" Vous ne pouvez pas non plus faire évoluer une bêta vers la release candidate ou la version stable par le chemin de mise à jour normal.

Le dépôt du module est encore plus direct. Le README de PrestaShop/ps_onepagecheckout indique : "Ce module est en développement intensif. Il n'est pas prêt pour la production et ne doit pas être utilisé en environnement réel." À l'heure où nous écrivons, il compte une poignée d'issues ouvertes, et deux d'entre elles recoupent exactement ce que nous avons rencontré indépendamment : #94 signale des identifiants de champ dupliqués entre la modale d'adresse masquée et le formulaire d'adresse en ligne, ce qui explique pourquoi le même id #field-postcode apparaît plusieurs fois dans la page que nous avons auditée, et #102 décrit la pile de cases de consentement qui place le bloc le plus lourd sur le premier écran, soit exactement la friction décrite plus bas. #132 concerne le formulaire d'adresse qui ignore l'ordre des champs propre à chaque pays, et #105 est une demande ouverte d'exposer un contrat de checkout express. Ce dernier point compte si vous vendez via des portefeuilles ou des paiements express, car la surface sur laquelle ils viendraient se brancher est encore en cours de conception.

6. Trois cases de consentement obligatoires séparent le client des options

Sur une installation 9.2 par défaut, un premier acheteur en mode invité rencontre trois cases obligatoires : confidentialité des données client, la case propre au module RGPD, et les conditions générales. Pour un invité, les deux premières verrouillent les options de livraison et de paiement, qui restent derrière un message "veuillez accepter les conditions requises" tant qu'elles ne sont pas cochées. Pour un client de retour, c'est plus doux : nous avons mesuré des options se résolvant normalement alors que seule la case des conditions restait décochée, ce qui verrouille le bouton de paiement et non les options. Cette pile relève de la configuration de votre boutique et non d'un défaut du tunnel, et elle est supprimable, mais c'est bien ce qu'une installation 9.2 neuve présente à un premier acheteur. PrestaShop a une issue ouverte exactement là-dessus, la #102.

Une correction : deux constats retirés

Une version antérieure de cet article contenait deux autres constats. Les deux étaient faux, et les deux venaient de nous et non du tunnel. Nous les laissons consignés ici plutôt que de les effacer discrètement.

Nous avions rapporté qu'appliquer un code de réduction réinitialisait le mode de livraison du client, et séparément que le tunnel pouvait afficher un transporteur et un total pendant que le panier enregistré en contenait un autre. Les deux venaient de la même erreur : notre script sélectionnait le transporteur par programme au lieu de cliquer dessus, si bien que le choix n'atteignait jamais le serveur et que chaque rendu ultérieur montrait simplement la version du serveur.

Ce qui a tranché, c'est de finaliser une vraie commande puis de lire la ligne en base plutôt que de se fier à l'écran :

Cliqué comme le ferait un humain, la commande correspond à l'écran à chaque fois, avec ou sans bon de réduction. Les codes de réduction fonctionnent correctement : le champ apparaît dès que la boutique possède réellement une règle panier, et en appliquer un recalcule la remise, les transporteurs et les options de paiement en AJAX sans rechargement. Nous n'aurions dû publier ni l'un ni l'autre, et nous consignons la correction parce qu'un benchmark incapable de se corriger lui-même ne vaut pas la lecture.

Ce que nous n'avons pas pu tester

Le dire clairement fait la différence entre un benchmark et une opinion.

• Les vraies passerelles de paiement. Nous n'avons testé qu'avec des méthodes hors ligne. Une passerelle carte, un parcours portefeuille ou une étape 3D Secure ajouteront chacun leur propre passage de relais, qui peut être une redirection, une popup ou un cadre embarqué. La dernière navigation mesurée était le module chèque passant la main à sa page de validation.
• Le thème classic. Nous avons testé sur hummingbird, le thème qu'installe 9.2. L'annonce officielle prévient que les thèmes classic ne sont pas pris en charge par défaut et que vous "devrez peut-être surcharger certains templates du module One Page Checkout pour le faire fonctionner". Nous n'avons pas mené à bien une installation classic proprement migrée, nous citons donc PrestaShop sur ce point plutôt que notre propre résultat.
• La charge et la concurrence. Mesures avec un seul navigateur sur un réseau local. Rien ici ne dit comment les points d'accès AJAX supplémentaires se comportent sous trafic réel.
• Les modules de checkout tiers. Nous n'avons pas testé le rendu des modules de transport, de frais ou d'upsell existants dans le flux one page. C'est le point le plus important à vérifier sur votre propre copie de préproduction.

Reproduisez-le vous-même

Tout cela ne vaut pas grand-chose si vous ne pouvez pas le vérifier. Le banc d'essai complet tient dans une image publique et environ dix minutes d'installation. Voici une version abrégée du fichier compose utilisé (ajoutez les habituels MYSQL_* et les DB_* correspondants, et pointez le domaine vers votre environnement) :

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # laissez-le DESACTIVE, sinon tous les temps sont fausses
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Ensuite, quatre choses qui vous coûteraient sinon votre après-midi, parce qu'elles nous ont coûté le nôtre :

• Activez le tunnel. Il est livré installé mais désactivé. Design > Checkout, ou mettez PS_ONE_PAGE_CHECKOUT_ENABLED à 1.
• Donnez la bonne zone à vos transporteurs. Une installation par défaut place le Royaume-Uni dans "Europe (hors UE)" alors que les transporteurs d'exemple ne desservent que deux autres zones : une adresse britannique n'affiche donc légitimement aucun transporteur. Ce sont des données d'exemple, pas un défaut du tunnel, et nous avons failli le signaler comme tel.
• Testez la validation du code postal avec la France, pas le Royaume-Uni. PrestaShop livre un zip_code_format vide pour GB : n'importe quoi passe et le tunnel semble cassé alors qu'il ne l'est pas. La France définit NNNNN et valide correctement.
• Pour reproduire le cas du bon, il vous faut plus que la boutique par défaut. Le benchmark principal tournait avec les deux transporteurs d'exemple, mais le test du bon nécessite un transporteur dont la perte se voit : nous avons ajouté Standard Delivery à 4,90, Economy à 6,90 (gratuit au-delà de 100) et Express 24h à 12,90, chacun couvrant toutes les zones, puis créé une règle panier de 10% avec le code TEST10 et la livraison gratuite désactivée. Choisissez le transporteur le plus cher, appliquez le code, finalisez la commande et comparez le mode de livraison de la commande obtenue avec celui que vous aviez choisi. Un piège : le champ code promo est invisible tant qu'aucune règle panier n'existe, car PrestaShop bascule PS_CART_RULE_FEATURE_ACTIVE à 0 sur une boutique qui n'en a aucune.

Pour compter les rechargements, ouvrez le panneau Réseau, filtrez sur Doc et observez le nombre de navigations du frame principal entre l'ouverture du tunnel et la page de confirmation. Pour la requête en double, filtrez sur paymentmethods.

L'OPC natif de 9.2 vous suffit-il ?

D'après ce que nous avons mesuré, voici le partage honnête.

L'OPC natif suffit vraiment si

• Vous passez de toute façon à 9.2 et utilisez le thème hummingbird ou un thème enfant.
• Votre tunnel est standard : quelques transporteurs, des moyens de paiement usuels, pas de champs personnalisés.
• Vous vendez aux particuliers et la commande invité est la norme.
• Vous voulez le parcours en quatre étapes condensé et un total mis à jour en direct, ce qu'il fournit exactement, avec zéro rechargement.
• Vous acceptez d'attendre la version 9.2 stable avant de l'activer.

Pour cette boutique, la réponse est simple : la plateforme le couvre désormais, et vous ne devriez pas acheter un module pour faire ce que fait le cœur. Si votre tunnel perd actuellement des commandes et que vous voulez savoir s'il est bien le problème, commencez par pourquoi votre page de paiement vous fait perdre des ventes et les raisons pour lesquelles les clients partent avant de payer.

Vous buterez encore sur un mur si

• Vous n'êtes pas en 9.2. C'est le point dur. Le module refuse de s'installer en dessous de 9.2.0, et les montées de version qui touchent au tunnel sont précisément celles que les marchands repoussent. Une boutique en 1.7, 8.x, 9.0 ou 9.1 ne tire rien de cette version.
• Vous voulez que l'étape de paiement elle-même tienne en un geste. Le one page checkout supprime la friction avant le paiement. Il ne transforme pas une passerelle en bouton portefeuille. C'est une autre fonctionnalité, traitée dans le paiement express et dans le paiement en un clic sur PrestaShop.
• Le mobile fait l'essentiel de votre chiffre d'affaires et il vous faut une barre de paiement collante, ou un formulaire d'adresse qui coopère avec l'autofill du téléphone. Les deux sont des manques mesurés plus haut.
• Vous voulez que les clients s'inscrivent au moment de l'achat. Il n'y a pas de champ mot de passe dans le tunnel, créer un compte implique donc d'en sortir.
• Vous avez besoin de règles du type "ce moyen de paiement uniquement entre X et Y de montant". Ce type de logique conditionnelle de paiement et de transport ne fait pas partie du module natif.
• Vous avez besoin de champs personnalisés, de règles B2B, d'upsells au niveau de la commande ou d'un sélecteur de date de livraison. Rien de tout cela n'entre dans le périmètre du module natif.

Là où un module garde sa place

Nous vendons des modules de checkout : traitez ce paragraphe avec le scepticisme qu'il mérite et confrontez-le au tableau ci-dessus. Les manques que nous avons réellement mesurés sont plus étroits qu'il y a un an, et sur une boutique 9.2 standard, le tunnel natif fait désormais bien le travail de base.

Le seul manque qui ne relève pas du goût est la portée en versions. L'OPC natif démarre à 9.2, ce que confirme la déclaration de compatibilité du module lui-même. Notre Checkout Revolution existe pour apporter un tunnel en une page aux versions de PrestaShop que la plupart des boutiques en production font réellement tourner aujourd'hui, sans toucher au cœur. Consultez la fiche produit pour la plage exacte de versions prises en charge, et notez que nous ne l'avons pas encore certifié sur 9.2 elle-même. Son histoire est dans Checkout Revolution 3.0. Si en revanche vous voulez compresser le geste de paiement lui-même plutôt que le formulaire au-dessus, c'est Express Checkout, et cela reste pertinent quel que soit le tunnel qui affiche la page. Si vous comparez les différentes voies, le guide d'optimisation du checkout et le panorama du processus et des alternatives les mettent à plat.

Si vous êtes en 9.2 avec un catalogue standard et un tunnel standard, nous vous dirions d'utiliser le natif. C'est ce que soutiennent les mesures.

FAQ

Le one page checkout de PrestaShop 9.2 est-il assez stable pour la production ?

Pas encore, et PrestaShop le dit deux fois. L'annonce de la bêta 9.2 précise qu'il s'agit d'un logiciel de préversion et déconseille aux marchands de l'utiliser sur une boutique de production, et le README du module indique : "Ce module est en développement intensif. Il n'est pas prêt pour la production et ne doit pas être utilisé en environnement réel." Le module lui-même en est à la version 0.6.2. Chaque commande que nous avons passée correspondait à ce que le tunnel avait affiché, mais un module avant la 1.0 sur une plateforme en bêta a tout de même sa place en préproduction jusqu'à ce que 9.2 soit stable. Vous ne pouvez pas non plus passer de la bêta à la release candidate ou à la stable par le chemin de mise à jour standard : testez sur une copie jetable.

Fonctionne-t-il avec mon thème ?

Il est conçu pour hummingbird, le thème qu'installe le paquet 9.2 et celui sur lequel nous avons testé, où il a fonctionné sans la moindre modification. L'annonce officielle de PrestaShop prévient que les thèmes classic ne sont pas pris en charge par défaut et que vous devrez peut-être surcharger certains templates du module pour le faire fonctionner. Nous n'avons pas vérifié nous-mêmes le cas du thème classic : traitez donc votre thème comme la première chose à tester en préproduction, surtout s'il surcharge des templates de tunnel.

Ai-je encore besoin d'un module de checkout ?

Si vous êtes en 9.2, sur hummingbird ou un thème enfant, avec un tunnel conventionnel, alors honnêtement non. Le module natif condense les quatre étapes en un écran, met à jour les totaux en direct, valide en ligne et finalise une commande en deux actions pour un client de retour. Vous voudrez toujours un module dédié pour ce qu'il ne fait pas d'après nos tests : fonctionner sur PrestaShop 1.6 à 9.1, le paiement portefeuille en un geste, les champs de tunnel personnalisés ou B2B, les upsells au niveau de la commande, et les raffinements mobiles comme une barre de paiement collante.

Comment l'activer ?

Allez dans Design > Checkout dans le back-office et sélectionnez la mise en page one page checkout. Le module est livré installé avec 9.2 mais le réglage est désactivé par défaut : une installation neuve vous donne donc le tunnel classique en quatre étapes tant que vous n'activez pas. Vous pouvez revenir en arrière à tout moment, et en multiboutique le choix se fait par boutique et non globalement.

Les clients peuvent-ils utiliser des codes de réduction dans le one page checkout ?

Oui. Le récapitulatif de commande comporte un accordéon "Code promo" avec un champ, et appliquer un code recalcule la remise, les transporteurs et les options de paiement en AJAX sans recharger la page. Nous avions initialement signalé qu'appliquer un code réinitialise le transporteur du client. C'était notre script de test qui sélectionnait le transporteur par programme au lieu de cliquer dessus, et nous avons retiré cette affirmation : pilotée par de vrais clics, la commande finale correspondait à chaque fois au mode de livraison choisi, avec ou sans bon. La seule vraie particularité est que le champ code promo reste masqué tant que la boutique n'a pas au moins une règle panier, car PrestaShop désactive alors entièrement la fonctionnalité.

One page checkout signifie-t-il aucune redirection ?

Non, et c'est le malentendu le plus fréquent. Nous avons mesuré deux chargements de page complets sur tout le parcours : l'ouverture du tunnel et le passage de relais du module de paiement après l'envoi. Tout ce qu'il y a entre les deux, y compris saisir une adresse, la modifier, changer de pays, changer de transporteur et choisir un moyen de paiement, s'est fait sans un seul rechargement. Mais un vrai moyen de paiement peut toujours passer la main à une page hébergée, à un défi 3D Secure, à une popup ou à un cadre embarqué. Nous n'avons mesuré que le relais du module chèque hors ligne, et ce type d'étape est un comportement e-commerce normal, pas un défaut du tunnel.

Mes modules de paiement et de transport existants continueront-ils de fonctionner ?

Par conception, oui, car le tunnel natif utilise la découverte standard des options de paiement de PrestaShop au lieu de la contourner, et nos trois moyens de paiement hors ligne sont apparus et ont fonctionné sans modification. La réserve, c'est que tout s'affiche désormais en même temps sur un seul écran : les modules de transport réagissant aux changements d'adresse en direct et les modules de paiement rendus dans un contexte une page sont exactement les endroits où les hypothèses héritées du flux par étapes peuvent casser. Notez aussi que le point d'accès des options de paiement est actuellement appelé deux fois par changement d'adresse, ce qui compte si vos modules de paiement font un travail coûteux à chaque rendu.

Sources et méthode de test

Sources primaires, toutes publiques :

• Introducing One Page Checkout in PrestaShop 9.2, l'annonce officielle sur le blog build de PrestaShop.
• PrestaShop 9.2 Beta is open for feedback, qui porte l'avertissement de préversion cité plus haut.
• PrestaShop/ps_onepagecheckout sur GitHub, le code source du module, son README et sa liste d'issues ouvertes.

Méthode. Une installation propre de PrestaShop 9.2.0 bêta 1 depuis l'image Docker officielle, thème hummingbird, mode debug désactivé et cache de production chaud. Le parcours invité, le parcours client de retour et la comparaison avec le tunnel classique en quatre étapes ont chacun été pilotés par un navigateur scripté qui journalisait les navigations et les requêtes XHR, fetch et document, hors ressources statiques, les navigations du frame principal étant comptées séparément des appels AJAX. Les temps de chargement sont la médiane de cinq exécutions, le cache HTTP étant vidé avant chacune. Deux constats d'une version antérieure de cet article ont été retirés après que nous les avons attribués à notre propre script sélectionnant le transporteur par programme au lieu de cliquer dessus ; toute commande passée avec de vrais clics correspondait à l'affichage du tunnel, vérifié sur la ligne de commande en base de données. Les captures automatisées utilisaient des viewports CSS de 1440 px et 375 px ; les images publiées ont été recadrées ou redimensionnées pour la présentation, mais leur contenu n'est pas retouché.

Daté et provisoire. Ces mesures décrivent PrestaShop 9.2.0 bêta 1 avec ps_onepagecheckout 0.6.2, testé le 27 juillet 2026. Il s'agit d'un logiciel de préversion en développement actif : les défauts décrits pourront très bien être corrigés quand 9.2 sera stable, et d'autres pourront apparaître. Nous comptons rejouer exactement ce benchmark à la release candidate puis à la version stable, et mettre cet article à jour avec les nouveaux chiffres plutôt que de laisser discrètement les anciens en place. Si vous reproduisez autre chose, dites-le nous et nous corrigerons.