Migration vers PrestaShop 9 : Guide complet de mise à jour

Pourquoi nous traitons PrestaShop 9 comme une plateforme différente, et non comme une simple montée de version

Nous avons migré l'intégralité de notre catalogue de plus de 140 modules vers PrestaShop 9 et avons accompagné des boutiques clientes dans le même exercice. Le résumé honnête : PS 9 est la plus grande rupture depuis le passage de 1.6 à 1.7. Le numéro de version augmente d'une unité, mais la plateforme sous-jacente change de génération. Prévoyez en conséquence. Pour suivre l'actualité de ce qui est arrivé avec 9.1, consultez nos notes de version de PrestaShop 9.1.

Dernière révision : 24 mai 2026. Les prérequis serveur ont été vérifiés par recoupement avec le guide officiel de configuration serveur de PrestaShop et les notes de mise à jour cœur des modules 9.0. Les captures d'écran de ce guide proviennent d'une véritable boutique de développement PrestaShop 9.1.0 que nous exploitons pour tester nos modules, et non de maquettes.

Voici ce que vous ressentirez réellement après la mise à niveau :

Symfony 6.4 LTS remplace Symfony 4.4

PS 8 fonctionnait sur Symfony 4.4. PS 9 passe à 6.4 LTS, avec des correctifs de sécurité jusqu'en novembre 2027. L'effet concret : un cycle de requête plus rapide, un conteneur d'injection de dépendances moderne, et l'accès aux composants Symfony sur lesquels le reste de l'écosystème PHP s'est standardisé. Pour nous, en tant qu'auteurs de modules, c'est la différence entre écrire du PHP au goût de 2018 et écrire du PHP au goût de 2026.

Plancher à PHP 8.1, mais ne vous arrêtez pas là

PS 9.0 exige PHP 8.1 au minimum et prend en charge 8.2, 8.3, 8.4. PS 9.1 ajoute 8.5. Le minimum est le plancher de compatibilité, pas la recommandation. Sur chaque nouvelle installation PS 9 que nous avons réalisée en 2026, nous avons visé PHP 8.4 (PS 9.0) ou 8.5 (PS 9.1), mais seulement après que chaque module installé a été validé sur cette version de PHP en préproduction. Lire « PHP 8.1+ » comme « régler la préproduction sur PHP 8.1 » laisse de vraies performances sur la table.

Twig prend le contrôle de l'administration (mais ce n'est pas terminé)

La majeure partie du back-office s'affiche désormais via Twig, mais la migration n'est pas achevée. Les nouveaux contrôleurs d'administration basés sur Symfony utilisent Twig nativement. Les contrôleurs d'administration historiques fonctionnent toujours, mais ils sont enveloppés par un LegacyController Symfony qui injecte leur sortie Smarty dans la mise en page Twig. Cet emballage est responsable de la plupart des signalements du type « la page d'administration de mon module s'affiche mais les boutons ont disparu » que nous avons rencontrés lors des migrations vers PS 9. Le simple fait que cet emballage existe vous indique que la migration est encore en cours.

Hummingbird est la direction prise, mais Classic n'a pas encore disparu

Hummingbird est le thème de front-office moderne de PrestaShop. Sur PS 9.1, c'est le thème par défaut pour les nouvelles installations. Sur les boutiques PS 9.0 mises à niveau, votre thème existant reste en place, et certaines distributions PS 9 livrent encore Classic comme thème disponible. La vraie question n'est donc pas « Classic est-il installé ? », c'est « vos templates, vos hooks, vos assets et votre stratégie de thème enfant sont-ils prêts pour Hummingbird ? » Car c'est là que vous vous dirigez, quel que soit votre point de départ.

Hummingbird repose sur Bootstrap 5.3, s'appuie sur les propriétés personnalisées CSS et est sensiblement plus léger que Classic. Nous l'utilisons comme base pour nos nouvelles réalisations depuis sa sortie, et c'est une meilleure fondation pour les Core Web Vitals que tout ce que PrestaShop a proposé jusqu'ici. Associez-le à Performance Revolution et un score PageSpeed moderne devient atteignable sur une vraie boutique, pas seulement sur une démo.

Refonte de la sécurité

Symfony 6.4 apporte un composant de sécurité entièrement remanié. Le hachage des mots de passe utilise bcrypt/argon2 via le MigratingPasswordHasher de Symfony. La protection CSRF est plus stricte. L'authentification passe par le bundle de sécurité de Symfony plutôt que par le chemin de cookie historique de PrestaShop. Plusieurs failles d'injection SQL et de XSS dans d'anciens chemins de code ont été colmatées. Pour nous, cela signifie moins de tickets « merci de corriger cette méthode précise » de la part des clients lors des audits de conformité. Après la mise à niveau, Security Revolution est la couche au niveau module que nous utilisons pour le durcissement de l'administration, la politique de 2FA et les contrôles d'intégrité des fichiers.

PS 9 n'est pas cosmétique. La plateforme sous votre boutique a été reconstruite. La récompense est réelle (plus rapide, plus sécurisée, plus maintenable) mais uniquement si la migration est menée méthodiquement. Nous avons vu des mises à niveau PS 9 précipitées mettre des boutiques hors service pendant des jours. Nous en avons aussi vu de bien préparées s'achever en un après-midi. Toute la différence se joue dans la préparation.

Prérequis : ne touchez pas à la production tant que chaque case n'est pas cochée

La cause la plus fréquente des mises à niveau ratées sur lesquelles on nous appelle est « j'ai simplement lancé le 1-Click Upgrade et tout a cassé ». Presque toujours, la mise à niveau elle-même n'a pas échoué. Ce sont les prérequis qui ont échoué, quelques heures plus tôt, et personne n'a vérifié.

Mettez la boutique en mode maintenance avant les travaux à risque

Back-office > Paramètres de la boutique > Général > Maintenance est l'endroit où vous désactivez la boutique, ajoutez votre IP à la liste blanche et rédigez le message de maintenance. Utilisez-le pour les répétitions en préproduction et pour la courte fenêtre de bascule en production, et non comme substitut aux tests.

Il s'agit d'un véritable écran de boutique de développement PS9.1. C'est le flux de travail qui compte ici ; ne recopiez pas aveuglément l'IP ou le texte d'exemple.

Prérequis serveur

• PHP 8.1+ : confirmez avec php -v. Pour un environnement de préproduction PS 9.1 en 2026, testez sur PHP 8.4 ou 8.5 uniquement une fois que chaque module est validé.
• MySQL 5.7+ ou MariaDB 10.2+ : confirmez avec mysql --version. Pour une infrastructure neuve, MySQL 8.0 ou MariaDB 10.11 est la cible réaliste.
• Extensions PHP : intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x
• memory_limit d'au moins 256 Mo : augmentez-le temporairement à 512 Mo pour l'exécution de la mise à niveau elle-même si vous avez un grand catalogue
• max_execution_time de 600+ secondes : les grandes bases de données entraînent des migrations longues

Vérification rapide depuis la ligne de commande :

# Version de PHP
php -v

# Extensions requises
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Limites de mémoire et d'exécution
php -i | grep -E "(memory_limit|max_execution_time)"

# Base de données
mysql --version

Cibles d'exécution réalistes

Vérifiez l'environnement d'exécution réel, pas la brochure de l'hébergeur

Sous PS 9, Paramètres avancés > Informations indique exactement ce que la boutique exécute : version de PHP, version de la base de données, limite de mémoire, version de la boutique, thème actif. Faites une capture de cette page avant de commencer. Quand la mise à niveau part de travers et que vous échangez des tickets d'hébergement à 2 h du matin, disposer de la référence d'avant-mise à niveau vous fait gagner des heures.

La capture ci-dessous provient d'une boutique de développement PS 9.1.0 exécutant PHP 8.5, MySQL 8.0, 512 Mo, Hummingbird.

Prérequis de version PrestaShop

• Vous devez être sur PS 8.1 ou 8.2 avant de pouvoir passer à 9. Les mises à niveau directes depuis 1.7.x ou antérieur ne sont pas prises en charge. Point final.
• Sur PS 1.7.x ? Passez d'abord à 8.2, stabilisez pendant une semaine ou deux, puis passez à 9.
• Sur PS 1.6.x ? Arrêtez de lire le chemin de mise à niveau. Il vous faut une reconstruction propre. Nous n'avons jamais vu une mise à niveau sur place de 1.6 vers 9 réussir, voyez la section Installation propre.

Compatibilité des modules : la partie qui décide si la mise à niveau réussit

C'est ici que la plupart des mises à niveau que nous traitons ont déraillé. Avant de toucher au bouton de mise à niveau, vous devez savoir quels modules survivront à PS 9 et lesquels non. Pas « probablement », le savoir réellement.

1. Récupérez la liste complète des modules depuis le Gestionnaire de modules.
2. Pour chaque module tiers, contactez l'éditeur et obtenez une réponse précise pour PS 9. « Ça marchait sur PS 8 » n'est pas la réponse dont vous avez besoin.
3. Pour tout ce qui n'est pas confirmé : décidez de mettre à niveau, de remplacer ou de retirer. N'embarquez pas d'inconnue.
4. Les modules de paiement d'abord. Une passerelle de paiement non confirmée après la mise à niveau, c'est zéro chiffre d'affaires tant que vous ne l'avez pas corrigée.

Ne revendiquez pas la compatibilité PS 9 pour un module sous prétexte que la catégorie se ressemble ou qu'un module frère la prend en charge. Nous avons vu des modules qui tournaient sans problème sur 8.2 planter brutalement sur 9.0 parce qu'ils appellent Tools::displayPrice(), une méthode qui a été supprimée, et non dépréciée. Testez, n'espérez pas.

Auditez les modules installés dans le véritable Gestionnaire de modules

Back-office > Modules > Gestionnaire de modules vous donne les noms des modules installés, leurs versions, leurs éditeurs, leur statut et les signaux de mise à jour. Construisez votre tableur de migration à partir de l'état réel de la boutique, pas de mémoire ni d'une ancienne copie FTP.

Les modules de paiement, de checkout, de transport, d'ERP et de flux, y compris les outils de flux comme Smart Google Merchant Feed Manager, méritent la priorité absolue car une défaillance à ce niveau stoppe le chiffre d'affaires ou le traitement des commandes.

Signaux de tri des modules que nous vérifions réellement

Compatibilité du thème

• Vous utilisez Classic ? Considérez-le comme une dette de migration. Vérifiez si votre distribution PS 9 l'inclut encore, mais prévoyez Hummingbird ou un thème PS 9 tiers quoi qu'il arrive.
• Vous utilisez un thème acheté ? Écrivez à l'éditeur avant toute chose. Pas de version PS 9, pas d'échéance claire, commencez le portage dès maintenant.
• Thème sur mesure construit sur Classic ? Travail conséquent. La structure des templates a suffisamment changé pour que « rechercher-remplacer les classes Bootstrap » ne vous y mène pas.
• Pour tout travail sur mesure à venir, un thème enfant Hummingbird est la voie. Modifiez le parent et vous perdrez vos changements à la prochaine mise à jour du thème.

Quand le faire

• Jamais pendant un pic de ventes. Nous avons vu des gens tenter. Ça finit mal.
• En milieu de semaine, tôt le matin, sur la fenêtre de trafic la plus basse dont vous disposez.
• Accordez-vous au moins 48 heures de surveillance avant le prochain pic.
• Plan de retour arrière prêt et testé : couvert plus loin dans ce guide.

Sauvegardez tout. Oui, vraiment.

C'est l'étape que tout le monde survole. Ne la survolez pas. Le nombre d'appels de récupération « on ne pensait pas avoir besoin d'une sauvegarde » que nous avons pris est la seule raison pour laquelle cette section est aussi directe. Si la mise à niveau échoue et que vous n'avez pas de sauvegarde, vous n'avez plus de boutique.

Base de données

La base de données est la partie que vous ne pouvez pas reconstruire. Produits, clients, commandes, configurations, réglages de modules : tout cela y réside. Utilisez mysqldump avec les bons drapeaux :

# Fonctionne sur n'importe quel serveur
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# Grande base de données (>1 Go) : compressez à la volée
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Pour les boutiques basées sur Docker :

docker exec <your-shop>-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Ce que font ces drapeaux, et pourquoi nous les utilisons à chaque fois :

• --single-transaction : instantané cohérent sans verrouiller les tables. Essentiel pour InnoDB sur une boutique en production.
• --quick : diffuse les lignes au lieu de les mettre en tampon. Sans lui, de grandes tables de produits ou de commandes peuvent saturer la mémoire du dump.
• --lock-tables=false : maintient la boutique en ligne pendant le dump.

Maintenant, vérifiez que la sauvegarde fonctionne réellement. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas une sauvegarde :

# Restaurez dans une base jetable et comptez les lignes
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Fichiers

Sauvegardez l'intégralité de l'arborescence PrestaShop, PHP, thèmes, modules, images téléversées :

# Archive complète
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# Ignorer les caches et les journaux (régénérés de toute façon)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Pour Docker, le volume monté :

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Stockez les sauvegardes à deux endroits. Le serveur lui-même plus un emplacement hors site, votre machine locale, un bucket S3, un autre serveur, n'importe où sauf sur le même disque que la boutique en production. Une sauvegarde sur le même disque que la mise à niveau vient de corrompre n'est pas une sauvegarde.

La configuration dont vous aurez besoin plus tard

Notez-les avant de commencer. Quand la mise à niveau est à moitié terminée et que le back-office est inaccessible, vous ne voulez pas avoir à deviner :

• app/config/parameters.php : identifiants de base de données, configuration du mailer, clé de cookie
• .htaccess : en particulier les règles de réécriture personnalisées que vous avez ajoutées
• Réglages SMTP / e-mail depuis le back-office
• Clés d'API des passerelles de paiement et URL de webhook
• Entrées de tâches cron (exécutez crontab -l et sauvegardez le résultat)
• Toute configuration serveur sur mesure : blocs Nginx, réglages de pool PHP-FPM, règles Cloudflare

Faites des captures des pages de réglages critiques du back-office tant qu'elles fonctionnent encore. Une référence visuelle de « à quoi cela ressemblait avant » vaut son pesant de tickets de support.

La mise à niveau elle-même

Deux chemins légitimes : le module officiel 1-Click Upgrade, ou une installation propre avec migration des données. Chacun a sa place. Nous avons fait les deux. Aucun n'est « le bon », cela dépend entièrement de la forme de la boutique que vous mettez à niveau.

Chemin 1 : 1-Click Upgrade (module autoupgrade)

Le chemin officiel. Le module autoupgrade gère le remplacement des fichiers, la migration de la base de données et le nettoyage post-mise à niveau. Malgré son nom, ce n'est pas littéralement un clic. C'est un clic plus une liste de contrôle.

Préparation

1. Installez ou mettez à jour le module 1-Click Upgrade vers la dernière version depuis la Marketplace.
2. Ouvrez Modules → 1-Click Upgrade. Le module affiche votre version actuelle et les cibles disponibles.
3. Lancez la liste de contrôle de pré-mise à niveau. Elle vérifie la compatibilité du serveur et signale les problèmes. Ne passez pas outre les avertissements, corrigez-les d'abord.

Mode maintenance activé

Depuis le back-office : Paramètres de la boutique → Général → Maintenance → Activer. Ajoutez votre propre IP à la liste blanche. Vous ne voulez pas qu'un client passe une commande pendant que la migration de la base de données réécrit ps_orders.

Lancez-la

1. Dans le module 1-Click Upgrade, choisissez votre version cible PS 9.x.
2. Choisissez « Mise à niveau majeure » comme canal.
3. Cochez ces options :
   • Sauvegarder les fichiers et la base de données : oui, même si vous l'avez déjà fait. Ceinture et bretelles.
   • Désactiver les modules non natifs : oui. C'est l'option qui prévient la plupart des signalements « le module X a fait planter la mise à niveau en cours de route ».
   • Régénérer les modèles d'e-mail : uniquement si vous ne les avez pas personnalisés.
4. Cliquez sur « Mettre à niveau PrestaShop maintenant ».
5. Ne fermez pas l'onglet. Ne quittez pas la page. N'actualisez pas. Le module dialogue avec lui-même via la session du navigateur, l'interrompre laisse une base de données à moitié migrée dont la récupération est franchement pénible.

Cela prend de 5 minutes (petite boutique, peu de modules) à plus de 30 minutes (grand catalogue, nombreux modules). Le journal de progression montre chaque étape. S'il reste sur la même étape plus de 10 minutes, vérifiez les journaux d'erreurs PHP dans un autre onglet, mais ne fermez pas le navigateur.

Une fois terminé

# Videz les caches : à chaque fois, sans exception
rm -rf var/cache/*

# Via la CLI (préféré)
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Permissions : la mise à niveau s'exécute souvent sous un utilisateur différent
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Réactivez les modules méthodiquement

Si vous avez laissé l'outil de mise à niveau désactiver les modules non natifs (vous l'avez fait, n'est-ce pas ?), ne les réactivez pas en masse. Activez-les un par un :

1. Activez le module.
2. Vérifiez le front-office et le back-office pour détecter des erreurs.
3. S'il fonctionne, passez au suivant. S'il casse quelque chose, désactivez-le et notez exactement ce qui a cassé.

C'est lent. C'est aussi le seul moyen de savoir quel module a causé le problème quand quelque chose casse. Regarder une boutique en panne avec 30 modules activés en essayant de deviner lequel est le coupable est une façon de perdre tout un après-midi.

Chemin 2 : Installation propre avec migration des données

Parfois, le geste le plus propre est de repartir de zéro. Installez PS 9 à neuf dans un nouveau répertoire ou serveur et migrez vos données dedans. Plus de travail en amont, mais vous obtenez au final une boutique qui ne traîne pas des années de dette accumulée.

Quand l'installation propre est le bon choix

• Vous êtes sur PS 1.6.x. La mise à niveau sur place n'est pas prise en charge. N'essayez pas.
• La boutique actuelle accumule des années d'overrides, de modules à moitié retirés et de tables de base de données orphelines. Le genre de boutique où chaque développeur qui la regarde dit « je repartirais de zéro ».
• Vous changez de thème de toute façon.
• La base de données est gonflée de paniers abandonnés, de vieux journaux, de données mortes.
• Vous avez déjà tenté des mises à niveau sur place et elles ont échoué.

Le processus

1. Installez PS 9 à neuf dans un nouveau répertoire ou un serveur de préproduction.
2. Configurez le thème (Hummingbird, ou un thème tiers compatible PS 9).
3. Installez les modules : uniquement les versions compatibles PS 9.
4. Migrez les données, soit par import CSV, soit par SQL direct.
5. Reconfigurez les paiements, le transport, les taxes, l'e-mail.
6. Testez tout sur la nouvelle installation pendant que l'ancienne boutique reste en ligne.
7. Basculez le DNS ou permutez la racine du document quand vous êtes satisfait.

Import CSV

L'import intégré de PrestaShop (Paramètres avancés → Import) gère les catégories, les produits avec déclinaisons et stock, les clients, les adresses, les fabricants, les fournisseurs. Exportez depuis l'ancienne boutique, nettoyez les CSV, importez dans la nouvelle. Fastidieux pour les grands catalogues, mais le résultat est propre.

Migration SQL directe

Pour les jeux de données plus importants, le SQL direct est plus rapide, mais seulement si vous connaissez vraiment le schéma de PrestaShop :

# Exportez les tables dont vous avez besoin depuis l'ancienne base
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# Puis relisez et ajustez selon les changements de schéma entre versions
# Les noms de colonnes, structures de tables et clés étrangères diffèrent entre versions majeures

La migration SQL suppose que vous savez lire et corriger le schéma de PrestaShop en toute confiance. Si vous ne le pouvez pas, utilisez l'import CSV ou engagez quelqu'un qui le peut. Nous avons nettoyé suffisamment de migrations SQL bâclées pour savoir que le temps gagné ne vaut pas le risque quand les clés étrangères se contredisent en silence.

Quel chemin ?

Pour la plupart des boutiques PS 8.x dotées de modules raisonnablement maintenus, la mise à niveau automatique est le bon choix. L'installation propre est la réponse quand vous venez d'une version très ancienne ou quand vous voulez profiter de la reconstruction pour faire le ménage.

Ce qui casse dans PS 9 (le point de vue du développeur)

Si vous maintenez des modules ou avez du code sur mesure, c'est la section à lire attentivement. Le reste relève de l'exploitation ; c'est ici que vit la véritable casse de code.

Les templates d'administration Smarty sont en cours de remplacement

La plus grande rupture à elle seule. Sur PS 8, les contrôleurs d'administration historiques affichaient directement les templates Smarty. Sur PS 9, les nouveaux contrôleurs Symfony utilisent Twig nativement, et les contrôleurs historiques sont enveloppés par LegacyController qui injecte leur sortie Smarty dans la mise en page Twig. La migration n'est pas achevée (l'emballage existe parce que les contrôleurs historiques affichent toujours du Smarty en interne), mais l'habillage environnant est en Twig, et c'est ce qui casse les templates de modules qui supposaient un contrôle Smarty complet de la page.

Ce que nous avons rencontré en migrant nos propres contrôleurs d'administration :

• AdminController + les modules Smarty fonctionnent toujours, mais sont affichés à l'intérieur de la nouvelle mise en page Twig via la couche de compatibilité. La plupart des signalements « la page se charge mais le formulaire est absent » remontent à cela.
• Les overrides de templates d'administration dans override/controllers/admin/templates/ ne fonctionnent souvent pas comme prévu. L'emballage ne les prend pas toujours en compte.
• Les variables Smarty assignées dans initContent() peuvent disparaître, LegacyController enveloppe le rendu différemment, et la variable Smarty content doit dans certains cas être réassignée explicitement.
• display() sur AdminController n'est plus appelée. L'emballage la contourne. Si vous avez personnalisé display(), ce code est mort sur PS 9.

Les overrides deviennent peu à peu moins viables

PrestaShop décourage les overrides depuis 1.7. PS 9 resserre encore l'étau :

• Les overrides de classes fonctionnent encore techniquement pour les classes historiques de type ObjectModel, mais la surface se réduit à mesure qu'une plus grande partie du cœur passe aux services Symfony.
• Les overrides de contrôleurs sont peu fiables : la couche de routage Symfony ne les charge pas toujours.
• Les overrides de templates dans override/ pour les pages d'administration sont dépréciés.
• Les alternatives prises en charge sont les hooks, les décorateurs de services Symfony et les abonnés aux événements. Nous remplaçons chaque override que nous possédons par l'un d'eux.

Si un module repose fortement sur les overrides, c'est l'élément le plus susceptible de votre environnement de casser lors de la mise à niveau vers PS 9. Vérifiez toujours le répertoire override/ de chaque module installé avant d'appuyer sur la gâchette.

Changements des hooks

• Plusieurs hooks d'administration historiques sont supprimés ou renommés à mesure que ces pages d'administration migrent vers Symfony.
• De nouveaux hooks existent pour les pages d'administration basées sur Symfony, couverts dans notre guide des hooks.
• La plupart des hooks de front-office fonctionnent toujours, mais Hummingbird modifie ou supprime certaines hypothèses de balisage. Les modules qui injectent du contenu dans les résultats de recherche, les pages de détail de commande, les modales, les blocs produit ou le checkout, retestez-les tous.
• L'ordre d'exécution des hooks peut se déplacer dans des cas limites. Si votre module dépend de s'exécuter avant ou après un autre module sur le même hook, vérifiez-le.

Changements des contrôleurs d'administration historiques

Plusieurs motifs qui fonctionnaient sur PS 8 se comportent différemment sur PS 9 :

• $this->l() est supprimée des contrôleurs d'administration. Utilisez $this->module->l('string', 'ControllerClassName') à la place.
• Tools::displayPrice() est supprimée. Utilisez Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode). Nous l'avons enveloppée dans notre paquet prestashop-compat afin de ne corriger cela qu'une seule fois sur plus de 140 modules.
• $this->meta_title, $this->fields_list, $this->bulk_actions doivent désormais être assignées après parent::__construct(). La référence au module n'est pas disponible avant cet appel.
• Arrêtez de coder en dur le répertoire du back-office. Les boutiques le renomment, les jetons changent, et les routes Symfony devraient être générées plutôt qu'assemblées comme des chaînes de caractères.

Auditer un module pour vérifier sa préparation à PS 9

Pour chaque module installé, dans l'ordre des vérifications les plus rapides d'abord :

1. Déclaration de compatibilité de l'éditeur. Cherchez une revendication PS 9 explicite, la version, pas la catégorie.
2. Overrides. Inspectez l'intérieur de modules/yourmodule/override/. Tout ce qui s'y trouve est un drapeau jaune.
3. Appels de fonctions supprimées. Cherchez les plus évidents dans le PHP du module :
   • Tools::displayPrice(
   • $this->l( dans tout fichier de contrôleur d'administration
   • les classes AdminController qui personnalisent display()
   • les chemins de répertoire d'administration codés en dur
4. ps_versions_compliancy dans le fichier PHP principal du module, la borne supérieure inclut-elle réellement 9.x ?

# À exécuter depuis l'intérieur du répertoire du module

# Y a-t-il des overrides ?
find override/ -type f 2>/dev/null && echo "WARNING: module uses overrides"

# Appels de fonctions supprimées
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Compatibilité déclarée
grep -A2 "ps_versions_compliancy" *.php

Traitez les mises à jour de modules disponibles comme du travail de migration

L'écran des mises à jour de modules indique quels modules réclament déjà de l'attention avant la mise à niveau du cœur. Mettez-les à jour d'abord en préproduction, puis exécutez les tests de checkout, de paiement, de transport et de commande avant de toucher à la production.

Évitez un clic « tout mettre à jour » en production pendant la migration. Les mises à jour de modules ont leur place dans la même matrice de tests contrôlée que la mise à niveau de PrestaShop elle-même.

Migration du thème : Hummingbird est la direction

PS 9.1 fait de Hummingbird le thème par défaut pour les nouvelles installations PS 9.1. Les boutiques PS 9.0 conservent ce qu'elles avaient. Certaines distributions PS 9 livrent encore Classic en option. Planifiez donc à partir de l'état réel de la boutique, et non d'une hypothèse universelle.

Commencez par Thème et logo

Sur une véritable boutique de développement PS 9.1, Apparence > Thème et logo affiche Hummingbird comme thème actuel, Classic toujours disponible, et notre thème enfant Hummingbird installé. C'est pourquoi le seul conseil sûr est « auditez d'abord la boutique actuelle, puis décidez ». Nous avons vu des plans de migration bâtis sur l'hypothèse de boutiques uniquement Hummingbird s'effondrer parce que Classic était encore actif.

Si vous maintenez des templates sur mesure, travaillez dans un thème enfant Hummingbird. Ne modifiez pas le parent.

Ce qui distingue Hummingbird

• Bootstrap 5.3 au lieu de Bootstrap 4. Les noms de classes, le système de grille et les classes utilitaires ont changé. Un portage de thème n'est pas un rechercher-remplacer.
• Propriétés personnalisées CSS pour la mise en thème. Couleurs, espacements, typographie. Tout est en variables, pas en partiels SCSS.
• Moins de JavaScript. Des fonctionnalités natives du navigateur plutôt que des plugins jQuery quand c'est possible. Des pages plus légères.
• Système de build moderne. Webpack avec tree shaking. Des bundles plus petits.
• Mobile-first. Le mobile est la mise en page de base, le bureau est l'amélioration. Classic faisait l'inverse. Le modèle mental est différent.

Si vous êtes encore sur Classic

1. Passez à Hummingbird. Le plus simple. Créez un thème enfant pour vos personnalisations.
2. Achetez un thème compatible PS 9. De nombreux éditeurs ont livré des versions PS 9.
3. Portez vos personnalisations Classic vers un thème enfant Hummingbird. Le plus de travail, mais le meilleur résultat à long terme.

Construire un thème enfant Hummingbird

Un thème enfant vous permet de personnaliser Hummingbird sans toucher au parent, vos changements survivent ainsi aux mises à jour du thème :

mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

themes/my-child-theme/config/theme.yml :

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Déposez vos styles personnalisés dans themes/my-child-theme/assets/css/custom.css. Hummingbird charge custom.css depuis le thème enfant avec la priorité la plus basse, de sorte que vos règles prennent le pas sur le parent.

Pour surcharger un template, copiez-le depuis themes/hummingbird/templates/ vers le même chemin relatif à l'intérieur de votre thème enfant. Ne copiez que les fichiers que vous avez besoin de modifier. Tout le reste retombe automatiquement sur le parent.

Si vous avez acheté votre thème

Écrivez à l'éditeur avant toute autre chose. Les questions qui comptent :

• Existe-t-il une version compatible PS 9 ?
• Est-elle basée sur Hummingbird ou autonome ?
• Votre licence existante couvre-t-elle la version PS 9 ?
• Quel est le chemin de migration depuis la version actuelle ?

Si l'éditeur ne peut pas vous fournir de version PS 9 ni de date, commencez à planifier votre passage à Hummingbird dès maintenant. Attendre six mois pour découvrir que la réponse est toujours « non » est une position encore pire.

Liste de contrôle post-mise à niveau

La mise à niveau est terminée, le back-office se charge, vous pouvez vous connecter. Ne la mettez pas encore en service. Chaque fonction critique doit être vérifiée avant de retirer la page de maintenance.

Front-office

Back-office

Passerelles de paiement

Cela mérite son propre paragraphe parce que c'est la partie qui décide si le chiffre d'affaires redémarre. Pour chaque mode de paiement :

1. Passez une vraie commande de test (ou en bac à sable si la passerelle en propose un).
2. Vérifiez que le paiement est capturé dans le tableau de bord de la passerelle.
3. Vérifiez que le statut de la commande se met à jour correctement dans PrestaShop.
4. Testez les remboursements si votre flux les utilise.
5. Vérifiez les URL de webhook / IPN : la mise à niveau peut déplacer la structure des URL et vous manquerez silencieusement les rappels.

Transport

• Vérifiez que les transporteurs affichent les tarifs corrects par zone.
• Testez les seuils de livraison gratuite.
• Pour la consultation de tarifs en temps réel via l'API d'un transporteur, confirmez que l'intégration s'authentifie toujours.
• Saisie du numéro de suivi, e-mails de notification, impression d'étiquettes : tout cela.

Tâches cron

Chaque tâche planifiée, relance de panier abandonné, synchronisation de stock, génération de flux, plan du site, taux de change, scripts personnalisés. PS 9 peut renommer les URL de cron :

# Inspectez les tâches actuelles
crontab -l

# Appelez chaque URL de cron et confirmez un code 200
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

SEO

• Les URL simplifiées se résolvent toujours.
• Le plan du site se génère correctement.
• robots.txt intact.
• Les pages d'atterrissage clés pour le référencement existent toujours aux mêmes URL.
• Si quelque chose a bougé, mettez en place des redirections 301 le jour même. La Search Console n'accorde pas de période de grâce.

Problèmes courants de mise à niveau

Écran blanc

Le plus courant. Page vierge, aucune erreur.

1. Activez le mode débogage dans config/defines.inc.php :

   define('_PS_MODE_DEV_', true);

2. Rechargez. La véritable erreur devrait maintenant apparaître.
3. Si c'est toujours blanc, l'erreur est avalée avant l'affichage. Vérifiez les journaux :

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # Journal propre à PrestaShop
   tail -50 /var/www/html/var/logs/prod.log

4. Les suspects habituels :
   • Mémoire PHP épuisée : augmentez memory_limit à 512M.
   • Extension PHP manquante : installez-la, redémarrez PHP-FPM/Apache.
   • Permissions de fichiers : chown -R www-data:www-data /var/www/html/var/.

Désactivez le mode débogage dès que vous avez trouvé le problème. Les pages de débogage de PS 9 exposent les identifiants de la base de données. Ce n'est pas un exercice.

Erreur 500 Internal Server Error

Généralement le .htaccess ou la configuration PHP après la mise à niveau.

# Contournez le .htaccess pour isoler le problème
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# Si la boutique se charge, régénérez-le depuis le back-office :
# Paramètres de la boutique → Trafic & SEO → Générer le fichier .htaccess

Confirmez également :

• Apache mod_rewrite activé : a2enmod rewrite && systemctl restart apache2
• Le vhost autorise AllowOverride All
• Le PHP web est bien en 8.1+. La CLI est souvent plus récente que le pool web, confirmez les deux.

Conflits de modules

Le back-office se charge partiellement, des erreurs dans certaines sections, des erreurs JS en console. Le correctif est la méthode d'isolation :

1. Désactivez chaque module non natif. Si le back-office est cassé lui aussi, faites-le via SQL :

   UPDATE ps_module SET active = 0 WHERE name NOT IN (
     'ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts',
     'ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar',
     'ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment'
   );

2. Videz le cache : rm -rf var/cache/*
3. Confirmez que la boutique fonctionne avec uniquement les modules natifs.
4. Activez les modules un par un, en vidant le cache entre chacun.
5. Celui qui la casse est celui à mettre à jour, remplacer ou remonter à l'éditeur.

Traductions manquantes

Certaines chaînes disparaissent ou s'affichent sous forme de clés brutes comme Modules.YourModule.SomeString.

• Exportez/importez votre pack de langue depuis International → Traductions.
• Pour les traductions de modules, réinstaller le module corrige le problème, mais la réinstallation peut réinitialiser la configuration, alors sauvegardez d'abord la config.
• PS 9 s'appuie davantage sur le système de traduction de Symfony. Les fichiers à l'ancienne dans modules/yourmodule/translations/ doivent parfois être convertis au nouveau format.

Cache

Le cache périmé est à l'origine d'un nombre surprenant de signalements « la mise à niveau est cassée » qui ne sont pas réellement des mises à niveau cassées. En cas de doute, videz tout :

# Effacer et reconstruire
rm -rf var/cache/*
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Propriété des fichiers
chown -R www-data:www-data var/

# Et videz le cache de votre navigateur : un vieux CSS/JS vous hantera sinon

Images qui ne s'affichent pas

• Régénérez les miniatures : Apparence → Réglages des images → Régénérer les miniatures.
• Confirmez que les permissions de img/ sont correctes.
• Si vous utilisez un CDN, purgez-le.
• Vérifiez que le format d'URL des images correspond à ce que votre thème attend, Hummingbird et Classic ne s'accordent pas sur chaque chemin.

Connexion à l'administration cassée

PS 9 a remplacé le hacheur de mots de passe par le MigratingPasswordHasher de Symfony (bcrypt/argon2). Dans la plupart des cas, les mots de passe existants fonctionnent, le hacheur migre automatiquement à la première connexion. Si vous êtes verrouillé dehors :

# Réinitialiser le mot de passe admin : PS 9 exige le hacheur de mots de passe de Symfony
# N'utilisez PAS de MD5 brut ni d'UPDATE SQL direct sur le champ du mot de passe

# À la place, utilisez la CLI de PrestaShop (si disponible) :
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Ou créez un script PHP temporaire pour réinitialiser correctement le mot de passe
# (supprimez ce fichier immédiatement après usage !)

Ne laissez jamais de scripts de réinitialisation de mot de passe sur votre serveur. Créez-les, utilisez-les, supprimez-les, tout dans une même session. Un script de réinitialisation oublié est une vulnérabilité de sécurité.

Le faire soi-même ou engager quelqu'un

Soyez honnête sur votre place dans l'échelle technique. Une mise à niveau ratée peut coûter plus cher en chiffre d'affaires perdu et en confiance client que l'ensemble du travail n'aurait coûté en heures de développement.

Vous pouvez probablement le faire vous-même si

• Vous passez de PS 8.2 à 9.x : un seul saut de version.
• Moins de 10 modules tiers, tous confirmés compatibles PS 9.
• Thème standard : Classic vers Hummingbird, ou un thème acheté qui dispose déjà d'une version PS 9.
• Vous êtes à l'aise en ligne de commande et avec les opérations de base de données.
• Vous disposez d'un environnement de préproduction fonctionnel pour tester d'abord.
• Aucun override personnalisé ni modification du cœur.

Engagez quelqu'un si

• Vous venez de PS 1.6.x ou des débuts de 1.7.x.
• Vous avez une boutique chargée en modules, surtout avec des overrides.
• Thème sur mesure à porter.
• Modifications du cœur ou fichiers d'override où que ce soit.
• La ligne de commande et les opérations de base de données ne sont pas votre métier quotidien.
• Le chiffre d'affaires journalier est suffisamment important pour qu'une journée d'arrêt représente une somme conséquente.
• Vous avez déjà essayé en préproduction et vous êtes resté bloqué.

Ce qu'il faut rechercher chez un développeur

• Expérience spécifique à PrestaShop. Pas « PHP » ni « e-commerce ». Un développeur PHP généraliste passera des heures facturables à apprendre ce qu'un spécialiste PS connaît déjà.
• Travail PS 9 récent. Demandez les boutiques qu'il a réellement migrées vers 9.x. Symfony 6.4 a ses propres pièges ; vous voulez quelqu'un qui les a déjà rencontrés.
• Un plan écrit. Audit → mise à niveau en préproduction → tests → mise à niveau en production → surveillance. Pas « je me débrouillerai ».
• Un support post-mise à niveau. Des cas limites font surface 1 à 2 semaines plus tard, quand un flux jusqu'alors silencieux s'exécute enfin. Assurez-vous que cette fenêtre est couverte.

Coûts approximatifs (marché 2025-2026)

• Mise à niveau simple : PS 8.x vers 9.x, peu de modules, thème standard : 500-1500 EUR.
• Mise à niveau moyenne : PS 1.7.x vers 9.x, portage de thème sur mesure, nombre de modules modéré : 2000-5000 EUR.
• Mise à niveau complexe : PS 1.6.x vers 9.x, modules sur mesure, reconstruction complète : 5000-15000+ EUR.

Si quelqu'un vous chiffre une mise à niveau de PS 1.6 à PS 9 à 200 EUR, soit il ne comprend pas l'ampleur de la tâche, soit il prévoit de couper des coins que vous paierez plus tard dans une autre monnaie. Une mise à niveau de version majeure n'est pas une affaire de clic-et-c'est-fini.

Plan de retour arrière

Vous avez fait des sauvegardes. Voici comment les utiliser quand la mise à niveau échoue suffisamment gravement pour qu'aller de l'avant ne soit pas le bon choix.

Retour arrière depuis la mise à niveau automatique

Si vous avez utilisé 1-Click Upgrade et l'avez laissé créer sa propre sauvegarde :

1. Modules → 1-Click Upgrade.
2. Cliquez sur Retour arrière et sélectionnez la sauvegarde d'avant-mise à niveau.
3. Le module restaure les fichiers et la base de données.

Si le back-office est totalement inaccessible, vous le faites à la main :

Retour arrière manuel de la base de données

# Supprimer et recréer
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Restaurer
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Docker
docker exec -i <your-shop>-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i <your-shop>-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Retour arrière manuel des fichiers

# Supprimer les fichiers mis à niveau
rm -rf /var/www/html/*

# Restaurer depuis la sauvegarde
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Permissions
chown -R www-data:www-data /var/www/html/

# Cache
rm -rf /var/www/html/var/cache/*

Vérifiez le retour arrière

1. Le front-office se charge.
2. La connexion au back-office fonctionne.
3. Les commandes récentes paraissent intactes.
4. Passez une vraie commande de test via le checkout.
5. Désactivez le mode maintenance une fois satisfait.

Après un retour arrière, ne relancez pas immédiatement la mise à niveau. Diagnostiquez d'abord. Lisez les journaux de mise à niveau, identifiez l'étape exacte en échec, reproduisez en préproduction, corrigez la cause racine là-bas. Relancer la production avec les mêmes prérequis est la façon dont les retours arrière se transforment en dommages permanents.

Aucune sauvegarde : le cas d'urgence

Cela arrive. Pas souvent, mais cela arrive. Les options quand il n'y a aucune sauvegarde :

• Sauvegardes de l'hébergeur. De nombreux hébergeurs conservent des instantanés quotidiens 7 à 30 jours. Ouvrez un ticket immédiatement, ils expirent.
• Journaux binaires MySQL. Si les binlogs sont activés, une récupération à un instant précis est possible. Cela demande un DBA compétent.
• La sauvegarde propre du module autoupgrade. Regardez dans /admin/autoupgrade/backup/. Souvent oubliée parce que le back-office est cassé.
• En avant, pas en arrière. Si la récupération est réellement impossible, concentrez-vous sur la réparation de la boutique mise à niveau plutôt que sur la restauration de l'ancienne. Parfois, c'est le seul chemin.

Le chemin de mise à niveau, condensé

1. Auditer : prérequis serveur, chaque module, compatibilité du thème.
2. Sauvegarder : base de données via mysqldump, fichiers via tar, configuration notée.
3. Préproduire : exécutez d'abord toute la mise à niveau sur un environnement de préproduction. Pas « je vais filer droit en production ».
4. Planifier : fenêtre à faible trafic avec une vraie marge pour les choses qui partiront de travers.
5. Mettre à niveau : mode maintenance activé, lancez-la, videz les caches.
6. Tester : front-office, back-office, checkout, paiements, transport, e-mails. Chacun.
7. Surveiller : les journaux d'erreurs pendant 48 heures d'affilée après la mise en ligne.
8. Nettoyer : mode débogage désactivé, fichiers temporaires supprimés, documentation mise à jour pour la personne suivante.

PS 9 est sincèrement meilleur que ce qui l'a précédé. Symfony 6.4, plancher PHP 8.1+, administration Twig, la direction de l'AdminAPI, Hummingbird comme cible de front-office, c'est la plateforme contre laquelle nous voulons livrer des modules depuis des années. Le hic, c'est qu'y arriver depuis une vraie boutique PS 8 ou PS 1.7 demande de la préparation. Sautez la préparation et vous écrirez la section sur le retour arrière. Faites la préparation et la mise à niveau elle-même est la partie facile.

Lectures complémentaires

• La compatibilité PrestaShop 9 sur l'ensemble de nos modules : statut module par module, utile pour planifier le risque lié aux tiers.
• PrestaShop 9.1, Hummingbird et le checkout multi-transporteurs : le contexte PS 9.1 actuel pour les marchands.
• Paquet PrestaShop Compatibility : comment notre couche de compatibilité partagée gère les différences de version sur plus de 140 modules.
• Guide de dépannage PrestaShop : étapes de récupération pour les écrans blancs, les erreurs 500 et les modules cassés.
• Guide des performances PrestaShop et Performance Revolution : quoi faire après la mise à niveau quand vous réglez les Core Web Vitals.
• Réglage des performances sur de vraies boutiques PrestaShop : nettoyage de base de données, de cache et de cache pleine page après la migration.
• Guide des hooks et overrides : ce qu'il faut utiliser à la place des overrides que PS 9 rend plus difficiles à conserver.
• Guide de l'API Webservice : pour vérifier les autorisations d'ERP et d'intégration après la mise à niveau.
• Thèmes enfants PrestaShop : le motif sûr face aux mises à jour pour les personnalisations Hummingbird.

Questions liées

• Le module affiche « This module requires PHP X.Y », puis-je quand même l’installer ?
• Comment activer le mode debug dans PrestaShop ?
• J’ai cassé mon fichier .htaccess par accident. Comment le réparer ?
• La traduction du module ne fonctionne pas. Le texte reste en anglais.
• Override non pris en compte. Mon template personnalisé est ignoré.
• Configurer des redirections 301 dans PrestaShop après une migration