Migrer de PrestaShop 8 vers PrestaShop 9
Passer de PrestaShop 8 à PrestaShop 9 est un changement de version majeure : le back-office bascule intégralement sur Symfony 6.4, les derniers contrôleurs legacy disparaissent, et l’administration s’ouvre à une nouvelle API. Ce n’est pas une mise à jour qu’on lance un vendredi soir sans préparation.
Ce qui change concrètement entre PrestaShop 8 et 9
PrestaShop 8.x repose en partie sur Symfony 4.4 pour les pages déjà migrées, le reste fonctionnant sur des contrôleurs « legacy » hérités. PrestaShop 9.0 change de branche Symfony : passage à Symfony 6.4 LTS. Le back-office est désormais entièrement construit sur des contrôleurs Symfony et Twig : les derniers contrôleurs legacy de la 8.x n’existent plus en 9.0.
Côté PHP, la 9.0 exige au minimum PHP 8.1 et prend en charge PHP 8.2, 8.3 et 8.4, alors que la compatibilité de la branche 8.1 s’arrêtait à PHP 8.1. Sur un hébergement plus ancien, la migration implique donc aussi une montée de version PHP.
La 9.0 introduit aussi l’Admin API, sur API Platform avec authentification OAuth, distincte de l’ancienne Webservice API, ainsi qu’un accès expérimental à un conteneur Symfony en front-office. Côté thème, elle introduit Hummingbird, mais Classic reste le thème par défaut : une boutique restée sur Classic n’a pas besoin d’en changer pour migrer.
Signes qu’un module va poser problème en 9.0
- Le module ajoute un onglet ou un widget dans le back-office en s’appuyant sur un contrôleur legacy.
- Sa fiche ou sa documentation ne mentionne aucune compatibilité 9.0, ni de balise <code><max></code> à jour dans <code>config.xml</code>.
- Une surcharge appelle directement une classe ou un contrôleur legacy plutôt qu’un service Symfony.
- Le module utilise l’ancienne Webservice API pour des intégrations externes (ERP, marketplace, comparateur de prix).
Pourquoi ces éléments cassent précisément
La disparition des derniers contrôleurs legacy est le point le plus direct : un module ou une surcharge qui ciblait l’un d’eux en 8.x n’a plus de cible en 9.0, la route ou la classe appelée n’existant plus. Ce n’est pas une question de compatibilité souple, c’est une absence pure et simple.
Le saut de version majeure de Symfony, de 4.4 à 6.4, est le second point de friction. Un module qui déclare ses propres dépendances Composer, par exemple une bibliothèque tierce épinglée sur une version précise, peut entrer en conflit avec le Symfony 6.4 du cœur de PrestaShop 9.0. Le conflit apparaît en général dès l’installation des dépendances, avant même l’exécution du module.
Enfin, la déclaration de compatibilité doit être à jour : les balises <compatibility><min></min><max></max></compatibility> de config.xml et la propriété $ps_versions_compliancy doivent couvrir la 9.0. Un module jamais mis à jour pour la 9.0 reste, par définition, à risque, même s’il fonctionne encore en 8.x.
Comment je conduis une migration de PrestaShop 8 vers 9
-
Audit des modules et surcharges
Je vérifie, module par module, la compatibilité déclarée dans config.xml et $ps_versions_compliancy, ainsi que les surcharges ciblant des contrôleurs legacy.
-
Sauvegarde complète avant tout essai
Sauvegarde des fichiers et export complet de la base, indépendamment de celle que le module autoupgrade réalise lui-même pendant la migration.
-
Migration sur copie de la boutique
Je lance autoupgrade sur une copie de la boutique, jamais en production, pour observer les erreurs réelles avant de m’engager sur un délai.
-
Exécution du script de migration de base
Le point de non-retour de l’opération : une fois le schéma transformé vers la structure 9.0 par autoupgrade, revenir en arrière suppose de restaurer la sauvegarde complète, pas d’annuler la dernière étape.
-
Correction des modules et surcharges cassés
Je remplace ou réécris les modules ciblant un contrôleur legacy disparu, et résous les conflits Composer identifiés à l’audit.
-
Vérification et bascule
Je contrôle catalogue, commandes, clients et emails transactionnels en test avant de programmer la bascule en production à faible trafic.
Pour aller plus loin
-
Checklist avant toute migration
Les vérifications avant de lancer une migration, quelle que soit la version cible.
-
Modules incompatibles
Comment repérer un module qui ne migrera pas tel quel, et par quoi le remplacer.
-
Conserver son référencement
Ce que je surveille sur les URL pour ne pas perdre le référencement acquis.
-
Passer à PHP 8
La montée de version PHP qui accompagne souvent une migration récente.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.