PrestaShop 9.2 ou 9.1.5 : quelle version pour votre prochaine étape ?
Pour une boutique PrestaShop 9.1.5 opérationnelle, la décision ne consiste pas simplement à savoir si la version 9.2 propose plus de fonctionnalités. Il faut déterminer si leur évaluation maintenant résoudra un problème métier, et quelles dépendances doivent être comprises avant un changement ultérieur en production.
Le 26 septembre 2026, la liste officielle des versions indique 9.1.5 comme la dernière version stable et 9.2.0-rc.1 comme une préversion. La maintenance de production et l'évaluation de la version 9.2 sont donc deux activités distinctes. Versions officielles de PrestaShop.
Cette comparaison suppose que vous exploitez ou maintenez déjà la branche 9.1. C'est une aide à la décision, et non une procédure de mise à niveau ni une introduction générale à PrestaShop 9.
Une fois le choix de version clarifié, utilisez le workflow de préproduction isolé de la RC1 pour transformer l'évaluation de la candidate en un exercice de préproduction maîtrisé.
Commencer par le rôle de chaque version
Votre boutique stable traite des paiements réels, des communications clients et l'exécution des commandes. Son besoin immédiat est un fonctionnement fiable avec des dépendances prises en charge. Un environnement RC répond à une autre question : la prochaine version peut-elle prendre en charge vos workflows, et que faut-il adapter ?
Ne faites pas servir un même environnement aux deux objectifs. Un essai qui envoie de vraies demandes d'expédition ou des événements marketing n'est plus simplement exploratoire. Un déploiement de production effectué uniquement pour examiner une nouvelle fonctionnalité entraîne des conséquences sans rapport avec la valeur de l'expérience.
L'annonce de la version 9.1.5 comprend des travaux de maintenance et de sécurité sur la branche existante. Sa description de la version 9.2 comme bêta reflète la date de rédaction de cette annonce ; l'index plus récent des versions indique désormais RC1. Cela rappelle qu'il faut comparer les dates plutôt que de considérer toutes les pages officielles comme simultanément à jour. Annonce de la version 9.1.5.
Consignez la référence stable réelle que vous souhaitez préserver : version du cœur, versions des modules, thème, intégrations actives et modifications locales connues. Une comparaison avec une boutique non documentée est difficile à interpréter, car les différences apparentes peuvent venir de la référence plutôt que de la nouvelle version.
Comparer les possibilités de workflows, pas le nombre de fonctionnalités
Le tableau suivant transforme les orientations de la version 9.2 en questions auxquelles une boutique peut répondre. Il ne suppose pas que la version 9.1.5 est dépourvue de tous les résultats similaires ; des modules et développements personnalisés peuvent déjà les fournir.
| Domaine | Question pour la boutique 9.1.5 | Question pour une évaluation de la version 9.2 |
|---|---|---|
| Checkout | Le parcours d'achat actuel répond-il aux besoins de paiement et de livraison ? | L'option native sur une seule page peut-elle respecter les mêmes règles ? |
| Données métier supplémentaires | Qui est responsable des tables personnalisées et des conventions d'intégration ? | Certains champs pourraient-ils utiliser le nouveau mécanisme natif d'extension ? |
| Assistance administrative | Quelles requêtes répétées prennent du temps au personnel ? | Une tâche conversationnelle délimitée peut-elle fournir des résultats vérifiables ? |
| Personnalisation du Back Office | Quelles pages et quels comportements les extensions modifient-elles ? | Ces extensions fonctionnent-elles sur les parcours migrés concernés ? |
| Clients d'intégration | Quels contrats sont supposés aujourd'hui ? | Quels changements propres à la version nécessitent des tests de contrat ? |
Ces nouvelles orientations sont présentées dans la série d'annonces officielles de la version 9.2. Considérez le tableau comme un cadre d'évaluation et non comme une garantie de compatibilité. Annonce des fonctionnalités de la bêta 9.2.
Cette distinction compte pour le budget. « La nouvelle version comprend un checkout » décrit une disponibilité. « Notre extension de date de livraison et notre module de paiement passent le nouveau parcours » décrit une preuve. Seule la seconde affirmation peut étayer une décision d'adoption propre à une boutique.
Séparer les correctifs partagés des véritables différences entre versions
Un long journal des changements peut exagérer l'écart apparent entre deux versions si chaque correctif est compté comme propre à une branche. Des travaux peuvent être rétroportés. Une annonce ultérieure peut également répéter des améliorations déjà évoquées pendant une bêta.
Lorsqu'un correctif précis motive votre décision, vérifiez les éléments de version ou de commit pertinents pour les deux références. Ne déduisez pas qu'un bug existe dans la version 9.1.5 simplement parce qu'un journal des changements de la version 9.2 le mentionne. Inversement, ne supposez pas que deux correctifs aux noms similaires couvrent le même comportement.
Une fiche de comparaison pratique comporte quatre champs : le problème observé, le scénario reproductible de la boutique actuelle, le changement amont susceptible de le résoudre et le résultat de ce scénario sur la candidate. Cela évite de choisir une version sur le seul titre d'un problème.
Par exemple, si une intégration de livraison échoue après un changement d'adresse, conservez le panier exact, les pays, les versions des modules et la séquence d'actions. Une entrée du journal des changements sur l'état de livraison est une piste à examiner. Ce n'est pas une preuve que l'échec de votre intégration a été corrigé.
Distinguez aussi une fonctionnalité absente d'une fonctionnalité défaillante. Si votre module actuel prend en charge une règle métier que le parcours candidat n'expose pas, aucun test de régression ne pourra établir la parité. Cet écart exige une décision produit ou d'intégration.
Trois boutiques peuvent aboutir à des conclusions différentes
Un marchand à l'approche d'une campagne saisonnière
Imaginez une boutique dont le checkout fonctionne et dont le défi immédiat est une grande campagne promotionnelle. L'action utile consiste à maintenir l'environnement stable et à limiter dans le temps un examen séparé de la candidate. La campagne ne devient pas plus sûre parce qu'une interface plus récente existe.
Choisissez un ou deux scénarios critiques pour la première évaluation : le comportement des bons de réduction de la promotion et les moyens de paiement les plus utilisés par les clients. S'ils révèlent des dépendances nécessitant du travail, consignez-les pour un projet ultérieur. L'évaluation a atteint son objectif sans perturber la campagne.
Une agence qui maintient un Back Office personnalisé
Une agence peut avoir davantage de raisons d'enquêter tôt, même si les marchands ne sont pas prêts à adopter la prochaine version. Détecter des dysfonctionnements d'extensions alors que la candidate reste ouverte aux retours laisse le temps de les adapter et de les signaler.
L'avantage est ici la préparation. Reliez chaque personnalisation à ses dépendances de page, formulaire, grille ou route. Testez les parcours candidats concernés et estimez l'effort d'adaptation. La décision peut être : « continuer à assurer la production sous 9.1.5 tout en qualifiant l'extension sous 9.2 RC1 ». C'est un plan technique cohérent.
Un marchand dépendant d'un checkout tiers
Un marchand qui paie pour des personnalisations du checkout peut souhaiter évaluer l'alternative native. Commencez par un inventaire de parité : champs, widgets de transporteurs, comportement des paiements, reprise après erreur et règles des comptes clients.
Si le checkout existant répond à des besoins métier spécialisés, l'option native peut encore nécessiter du développement. Si ces besoins sont modestes, un prototype ciblé pourrait clarifier la viabilité de l'alternative. Aucun de ces résultats ne découle du seul mot « natif ».
Ces scénarios sont illustratifs. Ils ne rapportent pas de résultats de boutiques clientes et ne prétendent pas qu'une version possède un avantage commercial mesuré.
Faire passer les preuves sur les dépendances avant les hypothèses
Posez des questions précises aux fournisseurs. « Votre module prend-il en charge PrestaShop 9 ? » est trop général pour un nouveau checkout ou un parcours de page expérimental. Demandez quelles versions du cœur et des modules ont été testées, quel thème a été utilisé et si la fonctionnalité pertinente pour votre boutique était activée.
Une hiérarchie utile des preuves comprend un résultat de test reproductible, une déclaration de prise en charge documentée avec ses limites de version et une hypothèse non résolue. Gardez ces catégories distinctes dans la comparaison. Le silence d'un fournisseur est une dépendance ouverte, pas un test réussi.
Pour les modules internes, appliquez la même rigueur. Un package qui s'installe correctement peut encore échouer lors de l'enregistrement d'un formulaire, du traitement d'une notification asynchrone ou de l'exécution d'une tâche planifiée. Choisissez les scénarios d'acceptation à partir d'opérations métier réelles.
N'utilisez pas l'existence d'une interface expérimentale pour justifier une promesse de support à long terme. Les notes développeur qualifient explicitement certaines parties du travail sur la version 9.2. Figez l'implémentation utilisée pour l'évaluation et réexaminez le contrat lorsque la version stable est publiée. Notes développeur propres à la version.
Écrire la décision avant de planifier l'étape suivante
Une décision de version doit préciser ce qui se passe maintenant, quelles preuves manquent et ce qui pourrait la changer. Par exemple :
Conserver la production sur sa référence stable maintenue. Évaluer le checkout candidat sur une installation jetable. Réexaminer l'adoption lorsqu'une version stable 9.2 sera disponible et que les scénarios de paiement, retrait et bons de réduction réussiront avec des versions de modules prises en charge.
Cette formulation est plus utile que « attendre que ce soit prêt », car elle nomme les conditions de préparation. Elle évite aussi de s'engager sur une date de sortie inventée.
Estimez le travail en catégories distinctes : étude de compatibilité, changements de code nécessaires, examen des workflows du personnel, préparation du futur déploiement et transfert au support. Un faible écart entre versions du cœur ne garantit pas un petit projet lorsque plusieurs intégrations changent de comportement ensemble.
Si la candidate ne résout aucun problème actuel et que vous ne maintenez pas d'extensions concernées, une brève exploration peut suffire pour l'instant. Si elle introduit une fonctionnalité essentielle à votre feuille de route, investissez dans un prototype plus approfondi. Conservez les résultats et les limites du prototype afin que le prochain examen parte de preuves plutôt que de souvenirs.
Une fiche de décision a aussi besoin d'une condition d'expiration. Réexaminez-la lorsque la version stable officielle paraît, lorsqu'une dépendance critique annonce sa prise en charge ou lorsque le besoin métier change. Sans ce déclencheur, une décision temporaire raisonnable peut devenir une hypothèse indéfinie dont personne n'est responsable.
Les questions qui ne doivent pas décider seules de la comparaison
La version 9.2 est-elle plus récente ? Oui, mais le statut de la version et la préparation des dépendances déterminent sa place. La nouveauté ne garantit pas l'aptitude à la production.
Une installation neuve réussie prouve-t-elle la compatibilité ? Elle prouve qu'une installation s'est terminée. Elle ne prouve pas que votre thème, vos intégrations, vos règles métier ou vos données historiques se comportent correctement.
Faut-il attendre une date stable précise ? Utilisez l'annonce officielle de sortie lorsqu'elle existe. Un plan de préparation doit nommer des conditions et non reposer sur une date non vérifiée.
Le choix pratique aujourd'hui consiste généralement en deux pistes coordonnées : préserver un fonctionnement fiable sur la branche stable et étudier les fonctionnalités de la version 9.2 qui comptent pour votre boutique. Une décision de production ultérieure pourra alors s'appuyer sur une version finale et des preuves propres à la boutique.
Pour le contexte général de la plateforme, consultez notre guide de mise à niveau sûre de PrestaShop 8 vers 9 et appliquez les contrôles propres à la version ci-dessus à l'installation que vous évaluez.