PrestaShop 9.2 : l’hébergement et les modules à vérifier avant la mise à jour

PrestaShop 9.2 est disponible en version stable depuis le 30 septembre 2026, comme Frontend l’a détaillé au moment de sa sortie. Pour une boutique qui fonctionne encore sous PrestaShop 9.0 ou 9.1, la question n’est plus de savoir si la mise à jour viendra, mais quand l’engager et avec quelles précautions. Avant de lancer l’opération, l’hébergement et les modules installés méritent une vérification précise, appuyée sur les prérequis publiés par l’éditeur.

Pourquoi contrôler l’hébergement avant la mise à jour

PrestaShop 9.2 reprend la plage de compatibilité PHP de la branche 9 : la version 8.1 reste le minimum accepté, mais l’éditeur recommande désormais PHP 8.5. Côté base de données, MySQL 5.7 ou MariaDB 10.2 constituent le plancher, avec une version récente conseillée. Le réglage de mémoire par script (memory_limit) doit atteindre 512 Mo au minimum, et l’option allow_url_fopen doit rester activée. Un hébergement dimensionné pour une version plus ancienne de PrestaShop ne respecte pas forcément ces seuils : c’est le premier point à vérifier auprès de l’hébergeur, avant toute autre opération, sous peine d’un installeur qui refuse de se lancer ou d’un écran blanc après la mise à jour.

• PHP : 8.1 minimum, 8.5 recommandé par l’éditeur
• Base de données : MySQL 5.7 minimum ou MariaDB 10.2 minimum
• Mémoire : memory_limit réglé à 512 Mo minimum par script
• Extensions PHP actives : CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO (avec son pilote MySQL), SimpleXML, Zip
• Réglage allow_url_fopen activé sur le serveur

Les modules et le thème à tester avant de basculer

La version 9.2 intègre nativement un tunnel de commande en une page (One Page Checkout), construit sur le thème Hummingbird. Les modules de paiement, les modules de transporteur et le thème de la boutique doivent être testés contre ce nouveau parcours avant la bascule en production : un module de paiement qui ne s’affiche pas correctement dans ce tunnel bloque directement les commandes.

La version ajoute aussi trois nouvelles valeurs à l’état des produits : « reconditionné », « endommagé » et « neuf avec défauts ». Tout module qui lit, écrit ou affiche l’état d’un produit doit être vérifié pour savoir s’il gère ces trois cas sans erreur. Les données structurées (JSON-LD) peuvent désormais être fournies directement par le cœur du logiciel : un module qui injectait déjà ces données en modifiant les templates du thème peut entrer en doublon avec cette nouvelle source, ce qui se traduit par des balises dupliquées visibles dans le code source des pages produit. Enfin, plusieurs pages d’administration (pays, retours de marchandise, accroche d’un module, accès rapide, traduction des corps d’e-mail, règles de taxe) ont été migrées vers une nouvelle interface, activable par des indicateurs de fonctionnalité. Un module qui modifie ces pages par des hooks de grille ou de formulaire doit être rejoué sur ces versions migrées avant la mise en production.

La méthode en quatre étapes

Une migration de version majeure sur une boutique active ne se traite jamais directement en production. La méthode décrite par Frontend pour appliquer une mise à jour de sécurité sans casse s’applique de la même façon à une mise à jour de version : copie, test, puis bascule planifiée.

1. Vérifier l’hébergement. Comparer la version PHP, la version MySQL ou MariaDB et le réglage de mémoire actuels aux prérequis de la 9.2, auprès de l’hébergeur ou via l’outil de vérification de l’éditeur.
2. Lister les modules et le thème. Contacter chaque éditeur de module payant pour connaître sa date de compatibilité 9.2, et vérifier le thème sur le nouveau tunnel de commande en une page.
3. Dupliquer la boutique sur un environnement de test. Appliquer la mise à jour sur cette copie, puis dérouler un parcours de commande complet, de la fiche produit au paiement.
4. Planifier la bascule en production. Choisir une plage de faible trafic, prévenir les équipes concernées et conserver une sauvegarde récente avant de lancer la mise à jour réelle.

Ce qui reste expérimental dans cette version

Deux fonctionnalités de la 9.2 restent à traiter avec prudence. Le système de propriétés étendues (Extra Properties) est marqué expérimental par l’éditeur, qui prévient qu’il peut encore changer avant une future version mineure. Le mode B2B amélioré est, lui, désactivé par défaut et placé derrière un indicateur de fonctionnalité : l’éditeur indique que son schéma de données et ses interfaces de programmation sont encore susceptibles d’évoluer. Une boutique qui dépend d’une logique B2B personnalisée a intérêt à laisser ce mode désactivé jusqu’à ce qu’il quitte ce statut, plutôt que de construire des développements sur une base appelée à changer. Pour une boutique venant d’une version antérieure à la 8, le chemin de migration détaillé par Frontend reste la référence pour ne pas sauter d’étape intermédiaire.

Ce qu’il faut retenir

• PrestaShop 9.2 est stable depuis le 30 septembre 2026 ; PHP 8.1 reste le minimum, 8.5 est recommandé.
• Le tunnel de commande en une page, les nouveaux états de produit et les données structurées imposent de tester modules et thème avant la bascule.
• Les propriétés étendues et le mode B2B amélioré restent expérimentaux : à laisser désactivés en production.
• La méthode reste la même qu’une mise à jour de sécurité : copie de test, parcours de commande vérifié, puis bascule planifiée.