Le 9 juillet 2026, PrestaShop 9.2 a changé de phase : le développement est entré en « feature freeze ». Pour une équipe technique, l’expression décrit un jalon précis. Pour un marchand, elle peut facilement être mal comprise comme « la mise à jour est prête ».
Ce n’est pas encore le cas.
Une feature freeze signifie que l’équipe n’accepte plus de nouvelles fonctionnalités dans la branche 9.2 et concentre désormais ses efforts sur la stabilisation. PrestaShop annonce ensuite une bêta publique, lorsque le logiciel sera jugé assez stable pour des tests plus larges. La bonne décision n’est donc pas de programmer une bascule en production dès aujourd’hui. C’est d’utiliser cette période pour découvrir ce que votre boutique devra prouver avant toute montée de version.
Autrement dit, le calendrier utile ne commence pas le jour où vous cliquez sur « mettre à jour ». Il commence avec un inventaire.
Trois décisions, pas une seule
Face à PrestaShop 9.2, une boutique ne devrait pas répondre par un simple oui ou non. Elle doit distinguer trois décisions.
Attendre concerne la production. Tant que la version stable, ses notes de version et les compatibilités indispensables ne sont pas confirmées, une boutique qui encaisse des commandes n’a rien à gagner à se comporter comme un environnement de test.
Préparer concerne l’existant. C’est le moment de connaître la version actuelle de PrestaShop, de PHP, du thème, des modules et des connecteurs. Cette préparation est utile même si la mise à jour est repoussée de plusieurs semaines.
Tester concerne une copie isolée. Lorsque la bêta puis la version stable seront disponibles, les scénarios métier devront être rejoués sur un environnement de staging représentatif, sans exposer les clients ni les commandes réelles.
Cette séparation évite deux erreurs fréquentes : attendre la sortie pour découvrir une dette technique ancienne, ou confondre curiosité technique et autorisation de toucher à la production.
Ce que 9.2 change dans la conversation
PrestaShop met en avant plusieurs évolutions pour 9.2. Le One Page Checkout natif doit réunir le parcours de commande sur une seule page. Extra Properties doit permettre aux développeurs d’ajouter des champs aux entités comme les produits, clients ou commandes, avec prise en charge du multiboutique, du multilingue, du back-office et de l’Admin API. Le projet évoque aussi des améliorations liées aux expéditions.
Pour un marchand, ces annonces ne sont pas une liste de fonctions à activer automatiquement. Elles posent des questions de coexistence avec l’existant.
Une boutique utilise-t-elle déjà un module de checkout en une page ? Le thème surcharge-t-il les templates du tunnel de commande ? Les transporteurs, paiements ou outils de consentement ajoutent-ils leurs propres blocs et validations ? Des champs personnalisés sont-ils déjà créés par un module ou du code maison ? Une intégration ERP dépend-elle de la structure actuelle des commandes ?
La nouveauté la plus visible n’est pas forcément le risque principal. Un nouveau checkout peut sembler séduisant, mais une boutique française doit aussi conserver le bon fonctionnement de la TVA, des adresses, des points relais, des moyens de paiement, des conditions de livraison et des informations précontractuelles affichées au bon moment.
La fiche d’identité à constituer avant la bêta
Une préparation efficace tient sur un document partagé. Il ne s’agit pas encore d’un plan de migration détaillé, mais d’une photographie exploitable.
Socle technique
Notez la version exacte de PrestaShop, la version de PHP, le moteur et la version de base de données, les ressources serveur et la méthode de déploiement. La documentation PrestaShop 9 rappelle que les compatibilités PHP varient selon la branche. Il faut donc vérifier la matrice de la version cible au moment du test, et pas seulement constater que le site actuel fonctionne.
Ajoutez la stratégie de sauvegarde : fichiers, base de données, médias, fréquence, durée de conservation et surtout procédure de restauration déjà testée. Une sauvegarde que personne n’a restaurée est une hypothèse, pas un plan de retour arrière.
Thème et surcharge
Identifiez le thème actif, sa version, son éditeur et ses surcharges. Distinguez les réglages visuels ordinaires des personnalisations qui touchent au panier, au checkout, au compte client, aux prix ou aux données structurées.
Hummingbird ne doit pas transformer cette discussion en faux choix « ancien thème contre nouveau thème ». La vraie question est celle du coût et du risque de compatibilité. Une boutique peut préparer la montée de version sans décider immédiatement de refaire son identité ou son front-office.
Modules et dépendances métier
Exportez la liste des modules installés, mais ne vous arrêtez pas à leur nom. Pour chacun, notez son rôle, son caractère critique, son éditeur, sa version, son mode de licence et son état de compatibilité annoncé.
Classez-les par impact:
- encaissement et lutte contre la fraude;
- livraison, points relais et suivi;
- TVA, facturation et comptabilité;
- promotions, fidélité et prix spécifiques;
- recherche, filtres et navigation à facettes;
- ERP, PIM, marketplace, CRM et logistique;
- consentement, analytics et marketing;
- SAV, retours et documents de commande.
Cette carte fait ressortir les modules « silencieux » : ceux qui ne dessinent presque rien à l’écran, mais dont l’arrêt bloque les stocks, les factures ou la préparation des commandes.
Un plan de test construit autour des commandes françaises
Le test le plus trompeur consiste à ouvrir la page d’accueil, ajouter un produit simple au panier et conclure que tout fonctionne. Un vrai plan suit les cas qui financent l’entreprise.
Commencez par cinq commandes représentatives plutôt que cinquante clics sans résultat attendu.
Commande standard France métropolitaine. Vérifiez prix TTC, promotion, adresse, transport, paiement, email, facture, stock et remontée dans les outils connectés.
Commande avec variante et règle de prix. Testez taille ou couleur, stock de déclinaison, coupon, remise par quantité ou tarif client si ces mécanismes existent.
Commande avec livraison particulière. Rejouez un point relais, un produit lourd, une zone exclue, la Corse ou un autre cas réellement vendu par la boutique.
Commande professionnelle ou intracommunautaire. Lorsque l’activité le nécessite, contrôlez identité de l’entreprise, numéro de TVA, affichage des taxes et données transmises à la facturation.
Commande suivie d’un incident. Annulation, remboursement partiel, retour, nouvelle expédition ou avoir : la qualité d’une mise à jour se mesure aussi après le paiement.
Pour chaque scénario, conservez le résultat attendu, le résultat observé, l’identifiant de commande, une capture utile et la sortie dans l’ERP ou l’outil logistique. Ce dossier accélère le diagnostic et pourra être rejoué lors de futures mises à jour.
Le One Page Checkout mérite son propre banc d’essai
Le checkout natif en une page est l’une des annonces les plus visibles de 9.2. Il ne faut pourtant pas le juger seulement sur son apparence ou sur le nombre de clics.
Un parcours plus compact n’est meilleur que s’il reste compréhensible, accessible et fiable. Testez les erreurs de formulaire, le changement d’adresse, l’achat invité, la connexion d’un client existant, le rafraîchissement des frais de port, les moyens de paiement conditionnels et le retour après un paiement refusé. Sur mobile, vérifiez que le récapitulatif, les mentions essentielles et l’action de paiement restent lisibles sans masquer une erreur plus haut dans la page.
Si un module de checkout tiers est déjà en place, ne l’empilez pas avec le nouveau module « pour voir ». Comparez deux configurations isolées et documentez la couverture fonctionnelle de chacune.
Ce qui autorise réellement une mise à jour
La sortie de la version stable n’est qu’un prérequis. Une boutique peut envisager la bascule lorsque les éléments suivants sont réunis:
- les notes de version finales ont été lues;
- l’hébergement satisfait les exigences de la branche cible;
- le thème et les modules critiques ont une compatibilité confirmée ou une solution de remplacement testée;
- le staging ressemble suffisamment à la production;
- les commandes représentatives passent de bout en bout;
- les sauvegardes et le retour arrière ont été testés;
- une fenêtre d’intervention et une période de surveillance sont définies;
- une personne est responsable de la décision de poursuivre ou d’annuler.
Le bon moment dépend donc moins de l’enthousiasme autour de 9.2 que de la capacité de l’entreprise à démontrer que son parcours de vente reste intact.
Faut-il préparer 9.2 si la boutique est encore en PrestaShop 8 ?
Oui, mais la réponse n’est pas nécessairement une migration directe ni immédiate. L’inventaire révèle d’abord l’écart réel : version du cœur, PHP, thème, modules abandonnés, dette de données et dépendances externes. Une boutique stable mais ancienne peut avoir besoin d’un projet plus large qu’une simple mise à jour. À l’inverse, certaines corrections de maintenance peuvent être réalisées avant toute décision sur 9.2.
Si un module critique n’est plus maintenu, si personne ne sait restaurer le site, ou si le thème dépend de nombreuses surcharges non documentées, le premier chantier est de réduire ce risque. Cela évite de faire porter à PrestaShop 9.2 la responsabilité de problèmes qui existaient déjà.
Transformer l’attente en avance opérationnelle
La feature freeze ouvre une fenêtre utile : les contours de la version deviennent plus clairs, tandis que la production n’a pas encore à bouger. Les boutiques les mieux préparées ne seront pas celles qui mettront à jour le jour le plus tôt. Ce seront celles qui sauront ce qu’elles doivent tester, qui peut valider le résultat et comment revenir en arrière.
1Design peut réaliser ce diagnostic en amont : état du socle, thème, modules critiques, connecteurs, scénarios de commande et conditions de rollback. L’objectif est de répondre simplement à trois questions — attendre, tester ou planifier — avec des preuves propres à votre boutique.
Pour cadrer une montée de version ou une modernisation plus large, consultez notre accompagnement en création et évolution de site e-commerce à Lyon, puis contactez 1Design avec votre version actuelle et vos principales dépendances.
Pour compléter le diagnostic, relisez également notre guide sur la sécurité et la maintenance de PrestaShop 9 et notre point sur PrestaShop 9.1, Hummingbird et le choix du thème.
FAQ
PrestaShop 9.2 est-il déjà disponible en version stable ?
Non au moment de cette vérification, le 16 juillet 2026. PrestaShop a annoncé la feature freeze le 9 juillet et indique qu’une bêta publique doit suivre lorsque la branche sera suffisamment stable. Il faut vérifier la page officielle des versions avant tout projet.
Peut-on tester PrestaShop 9.2 maintenant ?
Le projet invite les développeurs, auteurs de thèmes et de modules à tester la branche 9.2.x. Pour un marchand, ces essais doivent rester sur un environnement isolé et être encadrés par une personne capable d’interpréter les erreurs. Une branche en stabilisation n’a pas sa place sur la boutique de production.
Faut-il adopter immédiatement le nouveau One Page Checkout ?
Non. Il faut comparer sa couverture avec le checkout actuel et tester les paiements, transporteurs, adresses, validations, achats invités et cas mobiles. Le bénéfice attendu doit être démontré sans perdre une règle métier indispensable.
Combien de temps faut-il prévoir pour préparer la mise à jour ?
Cela dépend surtout du nombre de modules, de surcharges et de connecteurs. Une petite boutique documentée peut être auditée rapidement; un site multiboutique relié à un ERP nécessite un inventaire et des tests plus longs. Commencer avant la sortie stable réduit la pression sans engager la production.
Vous voulez un site plus clair, plus crédible ou mieux pensé pour convertir ?