Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

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.

Décrire mon problème Discuter sur WhatsApp

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>&lt;max&gt;</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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

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.

Quelle est la version actuelle ?
Vers quelle version souhaitez-vous aller ?
Quelle est la taille du catalogue ?

C’est le premier facteur de durée d’une migration, avant même le nombre de modules.

La boutique utilise-t-elle beaucoup de modules tiers ou personnalisés ? (facultatif)

Chaque module non natif doit être vérifié, remplacé ou réécrit pour la version cible.

Qu’est-ce qui doit impérativement être conservé ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Dois-je aussi changer de version de PHP pour passer en 9.0 ?
Si votre hébergement tourne sur une version antérieure à 8.1, oui : la 9.0 exige PHP 8.1 minimum et prend en charge jusqu’à PHP 8.4. Je vérifie la version disponible chez votre hébergeur avant de planifier la migration.
Le nouveau thème Hummingbird est-il obligatoire en 9.0 ?
Non. Hummingbird est introduit avec la 9.0 mais Classic reste le thème par défaut à sa sortie. Une boutique déjà sur Classic n’a pas besoin d’en changer pour migrer.
Mes modules vont-ils tous fonctionner après la migration ?
Pas automatiquement. Je vérifie module par module la compatibilité déclarée dans config.xml avant de migrer, et je remplace ou réécris ceux qui ciblent des contrôleurs legacy disparus en 9.0.
Que se passe-t-il si la migration échoue en cours de route ?
Avant la mise à jour de la base, je dispose d’une sauvegarde complète des fichiers et de la base, en plus de celle d’autoupgrade. Si l’étape échoue avant validation, la restauration reste possible.