PrestaShop 9.2 Beta : le nouveau checkout mérite un test, pas une mise en production

PrestaShop 9.2 Beta : le nouveau checkout mérite un test, pas une mise en production

Imaginez deux copies de la même boutique.

La première encaisse les commandes du vendredi : paiements, transporteurs, promotions, factures et emails doivent fonctionner sans surprise. Elle n'a rien à faire sur une version bêta.

La seconde ne contient aucune vraie commande et peut être réinitialisée. C'est sur celle-ci que PrestaShop 9.2 Beta devient intéressante : non pour « prendre de l'avance » en production, mais pour découvrir aujourd'hui ce qui pourrait casser demain.

Le 22 juillet 2026, le projet PrestaShop a publié la première bêta de la version 9.2, après le jalon de feature freeze déjà expliqué par 1Design. La nouveauté la plus visible pour une boutique est un module natif de paiement en une page, le One Page Checkout. La version présente aussi l'assistant Ask AI, un système Extra Properties destiné aux extensions et plusieurs pages du back-office migrées vers Symfony.

La consigne officielle est sans ambiguïté : cette version de préproduction peut contenir des problèmes et ne doit pas être installée sur une boutique en activité.

Le vrai sujet n'est pas « une page ou quatre »

Réduire le checkout à son nombre d'écrans ferait manquer l'essentiel.

Un parcours sur une page rapproche l'identité, les adresses, le transport et le paiement. PrestaShop indique que le nouveau module permet un parcours invité, actualise livraison et paiement sans rechargement de page et laisse choisir entre le checkout sur une page et le parcours en quatre étapes.

Pour le client, cela peut sembler plus fluide. Pour la boutique, cela change le rythme des interactions entre le thème, les modules et les données. Un transporteur peut dépendre du code postal. Un moyen de paiement peut disparaître selon le pays, la devise ou le montant. Une promotion peut modifier le panier et les frais de port. Un module de consentement peut intervenir avant la validation.

La question utile n'est donc pas : « Le nouveau checkout est-il meilleur ? »

Elle est : notre combinaison réelle de thème, modules, règles commerciales et prestataires reste-t-elle cohérente dans ce nouveau parcours ?

Construire une boutique jumelle, pas un décor vide

Une installation de test avec trois produits simples produit rarement un résultat exploitable. Elle valide l'affichage de base, mais pas le fonctionnement de votre commerce.

Préparez plutôt une copie isolée et nettoyée de la boutique, ou un environnement de recette représentatif, avec :

• les versions réelles du thème et des modules indispensables ;
• plusieurs types de produits, dont les déclinaisons, lots ou produits virtuels utilisés ;
• des règles de panier et codes promotionnels représentatifs ;
• les zones, taxes et devises réellement servies ;
• les transporteurs avec leurs seuils, exclusions et points relais ;
• les moyens de paiement en mode test ;
• les emails transactionnels, factures et statuts de commande ;
• les personnalisations spécifiques qui touchent le panier ou la commande.

Les données personnelles et secrets de production ne doivent pas être recopiés sans contrôle. Utilisez des comptes de test, anonymisez ce qui doit l'être et vérifiez que les connecteurs ne peuvent pas envoyer de vrais emails, débiter une carte ou pousser une commande vers la logistique. Si l'équipe ne dispose pas encore d'une recette isolée, commencez par cadrer l'hébergement et la gestion technique de cet environnement avant d'y brancher des services externes.

Un vendredi de test vaut mieux qu'une visite guidée

Au lieu de parcourir le back-office au hasard, faites exécuter des scénarios avec un résultat attendu.

1. Une commande simple sur mobile

Ajoutez un produit courant depuis un téléphone, poursuivez sans compte, changez l'adresse, choisissez le transport, payez en mode test puis contrôlez la page de confirmation et l'email reçu.

Observez les détails que le test technique oublie souvent : clavier adapté au téléphone, message d'erreur compréhensible, bouton visible, total stable, consentement lisible et retour possible à l'étape précédente sans perdre le panier.

2. Une commande qui modifie les options disponibles

Changez le pays ou le code postal après avoir sélectionné un transporteur. Ajoutez ensuite un coupon ou franchissez le seuil de livraison offerte. Les tarifs, taxes, moyens de paiement et totaux doivent se recalculer sans conserver une option devenue invalide.

Ce scénario expose les dépendances entre modules plus sûrement qu'une simple commande réussie.

3. Un échec de paiement puis une reprise

Simulez un refus, un abandon et un retour depuis la page du prestataire. Vérifiez le statut de commande, la réserve de stock, l'absence de doublon, les messages client et la possibilité de reprendre proprement.

Une boutique peut afficher « paiement refusé » tout en créant une commande ambiguë dans le back-office. Le contrôle doit relier ce que voit le client à ce que traite l'équipe.

4. Une commande qui sort du cas standard

Testez au moins une configuration difficile : produit personnalisé, retrait en magasin, point relais, livraison hors métropole, commande B2B, adresse de facturation distincte ou module de fidélité. C'est souvent là que les adaptations historiques apparaissent.

Pour chaque scénario, conservez quatre preuves : capture de l'étape critique, résultat attendu, résultat constaté et journal ou erreur utile à reproduire. Une liste « ça marche / ça ne marche pas » aide peu un développeur.

5. Le parcours avant et après le checkout

Le tunnel n'est pas une île. Ouvrez une catégorie, utilisez les filtres, consultez une fiche produit, ajoutez une déclinaison puis revenez au catalogue. Après la commande, contrôlez le compte client, l'historique, l'email transactionnel, la facture et les événements de mesure attendus.

Comparez aussi les éléments qui doivent rester lisibles par les moteurs : titres, descriptions, canonicals, données structurées, liens vers les catégories et pages de contenu. Une recette de checkout réussie ne doit pas masquer une régression sur les pages qui amènent le visiteur jusqu'au panier. Le cadre 1Design d'optimisation SEO à Lyon permet de séparer ces contrôles de visibilité des tests de paiement proprement dits.

Ask AI : traiter l'accès aux données avant la démonstration

PrestaShop 9.2 Beta inclut aussi Ask AI, un assistant conversationnel dans le back-office. Selon la présentation officielle, il s'appuie sur le serveur MCP PrestaShop, permet de choisir un fournisseur d'IA et demande une approbation avant d'agir sur la boutique.

Ce mécanisme d'approbation est utile, mais il ne remplace pas une politique d'accès. Avant un essai, une entreprise doit documenter :

• les données que l'assistant peut lire ;
• les actions qu'il peut préparer ou déclencher ;
• les rôles autorisés à l'utiliser ;
• le fournisseur choisi et les conditions d'envoi ou de conservation des données ;
• le journal permettant de relier une action à un utilisateur ;
• la procédure d'arrêt et de révocation des clés.

Le test pertinent n'est pas une question spectaculaire posée devant l'équipe. C'est une série de demandes bornées avec vérification de la réponse, des permissions et de l'effet produit. Pour approfondir cette méthode, le guide 1Design sur ce qu'un assistant peut lire, écrire ou envoyer fournit une matrice de contrôle distincte du test de mise à jour.

Extra Properties : chercher les personnalisations cachées

Le système Extra Properties doit permettre aux modules d'ajouter des champs aux produits, clients, commandes ou autres entités avec une prise en charge native du multiboutique, du multilingue, des formulaires, des grilles et de l'API d'administration.

Pour le marchand, l'intérêt immédiat n'est pas d'ajouter de nouveaux champs pendant la bêta. Il est d'inventorier les champs existants : référence métier, date de livraison, information B2B, personnalisation produit, donnée transmise à un ERP ou étiquette logistique.

Aujourd'hui, ces champs peuvent vivre dans une table spécifique, un override, un module privé ou une synchronisation externe. Une future migration ne doit ni les dupliquer ni les rendre invisibles. Documentez pour chacun sa source, son propriétaire, les écrans où il apparaît et les systèmes qui le consomment.

Ce que la bêta ne permet pas encore de décider

Une bêta donne un signal, pas un feu vert.

Elle ne prouve pas que tous les modules seront compatibles avec la version stable. Elle ne fixe pas nécessairement le comportement final des fonctionnalités. Elle ne donne pas, à elle seule, une date de mise à jour adaptée à votre calendrier commercial.

PrestaShop précise en outre qu'une installation de cette bêta ne pourra pas être mise à jour vers la Release Candidate ou la version finale par le canal standard de l'Update Assistant. Pour des tests réalistes, le projet recommande une installation neuve. Votre environnement bêta est donc jetable : ne construisez pas dessus un chantier destiné à devenir la production.

La décision à prendre avant la version stable

À la fin du test, classez les résultats en trois colonnes.

Compatible en l'état : les parcours critiques réussissent et les preuves sont conservées.

À confirmer : le scénario fonctionne, mais dépend d'un module dont l'éditeur n'a pas encore confirmé la compatibilité finale.

À corriger ou remplacer : une personnalisation casse, un module n'est plus maintenu, ou le parcours produit un résultat commercial incorrect.

Cette carte permet de demander des réponses précises aux éditeurs et à l'agence, de chiffrer les corrections et de choisir une fenêtre de maintenance après la sortie stable. Elle évite les deux réflexes coûteux : mettre à jour le jour de la sortie sans filet, ou laisser vieillir la boutique parce que personne ne sait ce qui la rend fragile.

1Design peut préparer une recette technique et commerciale de boutique PrestaShop : inventaire du thème et des modules, copie de test, scénarios de checkout, contrôle des intégrations et plan de retour arrière. Pour une évolution plus large du catalogue ou du parcours, consultez aussi l'accompagnement e-commerce à Lyon. L'objectif n'est pas de pousser la bêta en production, mais de transformer ses enseignements en décision de maintenance.

Décrivez les parcours critiques de votre boutique pour cadrer le périmètre à tester.