PrestaShop 9 : guide de migration depuis 1.7 et 8 avec 1-Click Upgrade

Table des matières :

1. Pré-requis réels pour viser PrestaShop 9 (et ce que le cœur ne vérifie pas pour vous)
2. Cartographier l’existant : modules, thème, overrides et dette technique (là où les migrations cassent vraiment)
3. Préparer un environnement de migration reproductible (staging, Git, snapshots, et tests de restauration)
4. Exécuter la migration avec 1‑Click Upgrade (autoupgrade) sans se mentir sur les limites
5. Après upgrade : validation technique, perf, SEO, et plan de rollback (parce que “ça s’affiche” ne suffit pas)
6. Stratégies de migration 1.7 → 9 et 8 → 9 : chemins recommandés, cas limites, et décisions irréversibles

Pré-requis réels pour viser PrestaShop 9 (et ce que le cœur ne vérifie pas pour vous)

La migration vers PrestaShop 9 n’est pas un “clic magique” : c’est une opération de mise en cohérence entre le cœur, la stack serveur et vos surcouches (modules/thème/overrides). Avant même d’ouvrir 1‑Click Upgrade, verrouillez les versions : PrestaShop source (1.7.x ou 8.x), PrestaShop cible (9.x), PHP, MySQL/MariaDB, Apache/Nginx, et la politique de cache (OPcache, reverse proxy). Le module d’upgrade peut échouer tardivement (au moment des migrations SQL) si une seule brique est hors matrice.

Côté PHP, partez du principe que PrestaShop 1.7 et PrestaShop 8 n’ont pas les mêmes contraintes, et que PrestaShop 9 impose généralement un saut supplémentaire (au minimum sur les versions de PHP et de dépendances Symfony). Ne “devinez” pas la compatibilité : vérifiez la matrice officielle de la version cible et de votre hébergeur, ainsi que la politique de support PHP (EOL) sur le site PHP : liste des versions supportées de PHP. Sur un projet e‑commerce, migrer vers une version PHP en fin de vie revient à empiler de la dette de sécurité dès J+0.

Enfin, rappelez-vous que le module 1‑Click Upgrade (historiquement autoupgrade) n’a aucune visibilité sur votre infra (quotas disque, IOPS, latence DB, timeout FPM, règles WAF). Sur des bases volumineuses, les migrations peuvent dépasser les timeouts HTTP/Proxy et donner une impression de “blocage” alors que le serveur travaille. Avant migration, mesurez espace disque libre (package + backups + dump), temps de dump/restore, et ajustez max_execution_time, memory_limit, request_terminate_timeout (PHP‑FPM) et les timeouts reverse-proxy.

Pour rendre ces prérequis actionnables, utilisez une checklist “infra” (à adapter à votre hébergement) :

Point à valider	Pourquoi c’est critique en upgrade	Comment le vérifier rapidement
Version PHP + extensions	Incompatibilités + erreurs fatales sur dépendances	php -v, php -m, logs PHP-FPM
MySQL/MariaDB + mode SQL	Migrations SQL sensibles (strict, triggers)	SELECT VERSION(); + SELECT @@sql_mode;
Espace disque libre	Téléchargement + extraction + backups + images	df -h + taille img/ + taille dump
Timeouts (proxy/FPM)	Upgrade “bloqué” en HTTP alors qu’il tourne	config Nginx/Apache + request_terminate_timeout
Permissions fichiers	Échec d’extraction/écriture (cache/, var/)	user web (www-data) + owner/group
OPcache / cache reverse-proxy	Anciennes classes servies après déploiement	purge OPcache, purge proxy/CDN

Contexte France / UE : si votre boutique sert des clients européens, ne négligez pas l’aspect sécurité et conformité “non-fonctionnelle” au moment de l’upgrade (durcissement PHP, certificats TLS, politiques de cookies, journalisation). Une migration est souvent l’occasion de réduire le risque, pas seulement de changer un numéro de version.

Cartographier l’existant : modules, thème, overrides et dette technique (là où les migrations cassent vraiment)

La cause n°1 d’un upgrade raté n’est pas le cœur, mais votre custom. Faites un inventaire exploitable : liste des modules actifs, modules non‑natifs, overrides, surcharge de templates, scripts CRON, webservices, et toute intégration externe (ERP/PIM/PSP). Un audit rapide mais factuel consiste à extraire :

• modules actifs via la table ps_module et ps_hook_module (en filtrant active=1) ;
• overrides présents dans /override/ (classes, controllers) ;
• surcharges front dans votre thème (templates .tpl, assets, et overrides de modules).

Si vous voulez quelque chose de “copiable” pour objectiver l’inventaire (et pouvoir comparer staging vs prod), voici des requêtes SQL simples et peu intrusives :

-- Modules actifs (nom technique + version)
SELECT name, version, active
FROM ps_module
WHERE active = 1
ORDER BY name;

-- Où vos modules sont accrochés (hooks), utile pour repérer le checkout/SEO
SELECT m.name, hm.id_hook, h.name AS hook_name
FROM ps_hook_module hm
JOIN ps_module m ON m.id_module = hm.id_module
JOIN ps_hook h ON h.id_hook = hm.id_hook
WHERE m.active = 1
ORDER BY m.name, h.name;

Sur PrestaShop, les overrides sont une arme à double tranchant : un changement de signature de méthode, de namespace ou de comportement interne suffit à provoquer un fatal error. Dans un contexte de migration vers une major, partez du principe que les overrides doivent être réévalués un par un (et idéalement supprimés au profit d’events/hooks quand c’est possible). Pour objectiver, faites un diff de vos overrides par rapport au core actuel, puis vérifiez l’existence des classes/méthodes dans la cible (en lisant le code, pas au feeling).

Un tri pragmatique consiste à classer vos éléments “risque migration” :

• Risque élevé : overrides sur Cart, Order, PaymentModule, Customer, Product, surcharges checkout, modules de paiement/livraison, modules qui modifient la DB (tables propres + triggers).
• Risque moyen : modules SEO (réécriture, canonicals), recherche/facettes, import/export, connecteurs ERP/PIM, modules qui ajoutent des champs dans BO.
• Risque faible : widgets de contenu, bannières, avis (si non bloquants), tracking (à condition de ne pas casser le front).

Pour le SEO et l’indexation, l’upgrade n’est pas neutre : une réécriture d’URLs, un changement de routes côté front/back, ou un module SEO incompatible peut produire des 404/500. Pour cadrer, rappelez la sémantique des redirections permanentes telle que définie par le standard HTTP : « The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI… » (RFC 7231, section 6.4.2) RFC 7231. Traduction opérationnelle : si vos URLs changent, vous devez fournir des 301 propres, testées et monitorées.

Mini-scénario (fréquent en e‑commerce FR) : une boutique qui a historiquement “nettoyé” ses URLs à la main (sans stratégie de redirection) et utilise un module SEO vieillissant. Après migration, le module n’est plus compatible, les routes changent, et des fiches produits se retrouvent en 404. Résultat : perte de trafic sur la longue traîne + campagnes Shopping qui se dégradent. D’où l’intérêt de pré-calculer un mapping (au moins pour catégories, produits et CMS à fort trafic) et de prévoir des tests automatiques (liste d’URLs à vérifier) avant bascule.

Préparer un environnement de migration reproductible (staging, Git, snapshots, et tests de restauration)

Une migration sérieuse se fait hors production, sur un staging qui reproduit la prod : mêmes versions (PHP, DB), même volumétrie (au moins un dump réaliste), mêmes paramètres (cache, CDN, reverse-proxy), et idéalement mêmes contraintes réseau. Si vous n’avez pas de staging, la priorité n’est pas 1‑Click Upgrade, mais de mettre en place une copie isolée (VM, conteneurs, ou environnement PaaS) avec un DNS ou /etc/hosts. Sans staging, vous transformez la prod en sandbox.

Versionnez votre code. Le principe “12‑factor” est basique mais implacable : « One codebase tracked in revision control, many deploys. » (The Twelve‑Factor App – Codebase) Twelve‑Factor – Codebase. Concrètement : vous devez pouvoir tagger l’état avant migration, rejouer les changements, et comparer les diffs. Sur PrestaShop, ça inclut le thème, vos modules maison, et toute conf d’infra (IaC si vous en avez). Si vous migrez “à la main” sur un FTP sans historique, le rollback se résume à prier.

Les backups ne se discutent pas : faites un dump SQL + une copie des fichiers (notamment img/, modules/, themes/, override/, app/config/ ou config/ selon version), et testez une restauration sur staging. Une procédure simple (à adapter) : mysqldump --single-transaction --routines --triggers pour limiter le verrouillage côté InnoDB, et une archive incrémentale côté fichiers. Sur du gros catalogue, préférez un snapshot LVM/ZFS ou un snapshot au niveau storage (si votre infra le permet), parce que le temps de copie peut exploser.

Deux points souvent oubliés, mais très concrets :

• RGPD / CNIL (contexte France) : si vous externalisez un staging (prestataire, cloud), évitez de dupliquer des données personnelles “en clair”. Une bonne pratique consiste à anonymiser emails, noms, téléphones et adresses dans la base de staging, ou à restreindre drastiquement l’accès (IP allowlist + authentification).
• Drill de restauration : validez non seulement “le dump se fait”, mais “le dump se restaure et la boutique démarre”. Tant que vous n’avez pas chronométré une restauration, votre RTO (délai de retour en ligne) est une hypothèse.

Check-list de staging (rapide, mais efficace) :

• même version de PHP + mêmes extensions ;
• même moteur DB et réglages importants (charset/collation, sql_mode) ;
• même configuration mail (ou mail “désactivé” pour éviter d’envoyer des emails clients) ;
• accès aux logs (web, PHP, DB) ;
• données représentatives (catalogue + commandes) ;
• scénario de tests écrit (même minimal) pour “avant / après”.

Exécuter la migration avec 1‑Click Upgrade (autoupgrade) sans se mentir sur les limites

Le module 1‑Click Upgrade / autoupgrade automatise trois choses : récupération du package cible, déploiement des fichiers, exécution des migrations (PHP/SQL) et nettoyage. Il ne remplace pas votre stratégie : vous devez choisir un chemin de montée de version. En pratique, un saut direct 1.7 → 9 peut être plus risqué qu’un chemin incrémental (1.7 → 8 → 9), car vous réduisez l’écart entre schémas DB et dépendances applicatives à chaque étape. Vérifiez la documentation et les releases du module : autoupgrade sur GitHub.

Avant de lancer l’upgrade :

1. passez la boutique en maintenance (et vérifiez qu’un cache/proxy ne sert pas encore du front) ;
2. désactivez les modules non essentiels (surtout ceux qui touchent au checkout, à la réécriture d’URL, ou aux imports) ;
3. repassez temporairement sur un thème le plus proche possible du “natif” si votre thème est ancien ;
4. supprimez (ou désactivez) les overrides à risque, au minimum ceux qui touchent à Cart, Order, Customer, Product.

Ajoutez une étape “anti-piège” avant clic : notez noir sur blanc ce qui est censé se passer et ce qui est acceptable. Exemple de garde-fous simples :

• si la migration dépasse X minutes, vous stoppez et vous allez lire les logs (plutôt que relancer) ;
• si vous voyez des erreurs SQL répétées, vous figez l’état (copie du dossier + dump de la DB à l’instant T) avant toute manipulation ;
• vous ne faites jamais deux tentatives “in-place” consécutives sans repartir d’une restauration propre (sinon vous déboguez sur un état hybride).

Pendant l’exécution, surveillez les logs serveur (PHP‑FPM, nginx/apache, MySQL) en plus du log du module. Un pattern fréquent : la page web “timeout” mais le script continue côté serveur, ce qui pousse à relancer et à casser l’état (fichiers partiellement déployés, migrations déjà jouées). À ce stade, le bon réflexe est de figer, d’identifier si une migration tourne toujours (process PHP, requêtes longues MySQL via SHOW PROCESSLIST), puis de reprendre sur base d’un état cohérent. Pour le core, gardez sous la main les releases officielles (notes de version, changements cassants) : releases PrestaShop sur GitHub.

Sur des infrastructures avec reverse-proxy (fréquent), un bon “minimum” est de vérifier les timeouts suivants avant migration, car c’est souvent eux qui font croire à une panne :

• Nginx : proxy_read_timeout, fastcgi_read_timeout
• PHP-FPM : request_terminate_timeout
• Apache : Timeout, ProxyTimeout (si utilisé)
• MySQL : requêtes longues + verrous (à détecter via processlist)

Enfin, gardez en tête que la compatibilité réelle se joue aussi sur les modules “métier” : paiement, livraison, facturation, connecteurs. Par exemple en France, si votre PSP impose 3‑D Secure/SCA côté parcours de paiement, un module mal maintenu peut “fonctionner” sur le front… tout en cassant l’étape d’authentification bancaire. D’où l’intérêt d’un test de paiement complet sur staging (en mode sandbox) avant bascule.

Après upgrade : validation technique, perf, SEO, et plan de rollback (parce que “ça s’affiche” ne suffit pas)

La validation post‑migration doit être structurée, sinon vous allez découvrir les régressions en prod via les clients. Côté fonctionnel : commande complète (guest + compte), paiement, création facture, remboursement, transporteurs, règles panier, avoirs, retours, mails transactionnels, et génération PDF. Côté back‑office : indexation, recherche, import/export, et tous les écrans liés à votre métier (B2B, multi‑boutique, prix spécifiques). Faites ces tests sur staging, puis rejouez un sous‑ensemble sur prod après bascule.

Pour éviter le “tout tester / rien tester”, utilisez une matrice simple (critique vs probable) :

• Critique & probable : création panier, commande, paiement, email de confirmation, BO commandes.
• Critique & moins probable : remboursement, retours, génération facture PDF, avoirs.
• Non critique mais visible : pages CMS, formulaires, compte client, moteurs de recherche internes.
• Technique : cron, webservices, exports, tâches ERP/PIM.

Côté performance, l’upgrade peut déplacer le goulot d’étranglement (ex. requêtes plus coûteuses, caches invalidés, templates recompilés). Mesurez avant/après : TTFB, temps SQL moyen, hit ratio OPcache, et taille/rotation des logs. Si vous utilisez Redis/Memcached, validez la cohérence de cache et forcez une purge contrôlée. Sur PrestaShop, un symptôme classique après migration est une dégradation du BO due au cache Symfony (selon versions) ou à des assets recompilés ; planifiez une fenêtre technique pour reconstruire et stabiliser.

Quelques vérifications rapides qui évitent des heures de “ça rame” non expliquées :

• taille du dossier de cache qui grossit anormalement (symptôme d’un cache non purgé / permissions) ;
• erreurs répétées en logs (même si la page s’affiche) ;
• requêtes SQL lentes sur tables volumineuses (clients, commandes, déclinaisons) ;
• tâches CRON qui tournent deux fois (ancien + nouveau job) après migration.

Enfin, côté SEO : générez un crawl (Screaming Frog, Sitebulb ou équivalent), comparez les statuts HTTP, titles, canonicals, hreflang, et le maillage interne. Utilisez les logs d’accès pour repérer les 404/500 sur les pages à trafic. Si vous avez dû changer des patterns d’URLs, appliquez les 301 au niveau serveur (Nginx/Apache) quand c’est possible plutôt qu’au niveau applicatif, et gardez une table de mapping. Pour tester votre maillage interne ou vos règles de réécriture sur une URL “neutre”, vous pouvez vous appuyer sur une page simple du site (exemple) : Page d’exemple.

Point souvent sous-estimé : après migration, prévoyez une courte phase de monitoring (même basique) :

• pic de 404 (nouvelles URLs / anciennes URLs externes) ;
• pic de 500 (modules incompatibles, erreurs PHP) ;
• erreurs sur endpoints critiques (checkout, paiement, login BO) ;
• comparaison du taux de conversion et du taux d’abandon panier (si vous avez l’analytics en place).

Stratégies de migration 1.7 → 9 et 8 → 9 : chemins recommandés, cas limites, et décisions irréversibles

Depuis PrestaShop 1.7, la migration vers une major moderne est souvent un projet de refacto déguisé : le checkout, les hooks, la structure des controllers et la compatibilité modules font que “monter le numéro” n’est pas l’objectif, c’est la conséquence. Une approche robuste consiste à : (a) migrer d’abord vers la dernière 1.7.x supportée, (b) nettoyer overrides/modules obsolètes, (c) passer en 8.x, stabiliser, puis (d) passer en 9.x. Ce chemin coûte plus de temps, mais réduit la surface d’incertitude à chaque étape.

Depuis PrestaShop 8, le point critique est surtout l’écosystème : vérifiez que vos modules clés (paiement, livraison, ERP, recherche) annoncent une compatibilité 9.x et qu’ils la tiennent réellement (tests réels sur staging). Méfiez-vous des modules qui “supportent” via une contrainte de version large, sans tests sur le cœur : c’est un anti‑pattern courant. Dans le doute, testez avec un jeu de données représentatif : par exemple 30 000 produits, 200 000 déclinaisons, 500 000 clients, et un historique de commandes suffisant pour faire tourner les écrans de stats et de service client.

Cas limites à décider avant de vous engager (car ce sont des décisions coûteuses à changer ensuite) :

• Rester sur le thème historique vs replatforming du front : si votre thème est très custom (et ancien), la migration peut devenir une refonte déguisée. Dans ce cas, séparer “upgrade technique” et “refonte front” peut réduire le risque (d’abord stabiliser le cœur, ensuite refondre).
• Réduire les overrides : c’est souvent l’occasion de remplacer des surcharges par des modules propres, ou de revenir à des hooks standards. C’est moins “rapide” sur le moment, mais plus durable en maintenance.
• Nettoyage DB : certaines boutiques accumulent des tables de modules désinstallés, des données de logs gigantesques, des paniers abandonnés à l’infini. Sans tomber dans l’optimisation prématurée, un nettoyage contrôlé (sur staging, documenté) peut rendre l’upgrade plus fiable et plus rapide.

Dernier point : une migration major est irréversible au sens où le downgrade est rarement réaliste (migrations DB non symétriques). Votre vrai rollback, c’est votre capacité à restaurer un snapshot complet (code + DB + médias) et à remettre en ligne vite, sans bricolage. Si votre fenêtre de maintenance est courte, prévoyez une stratégie “blue/green” (nouvelle stack à côté, bascule DNS/Load Balancer) plutôt qu’un upgrade in‑place. 1‑Click Upgrade reste utile, mais uniquement dans un dispositif d’exploitation qui tolère l’échec et sait revenir en arrière proprement.

Un détail opérationnel qui change tout en blue/green : baissez le TTL DNS avant la fenêtre (si vous contrôlez la zone), et préparez une checklist de bascule (certificats, webservices, CRON, tâches de paiement, règles firewall/WAF). Le plus grand risque n’est pas de “ne pas savoir upgrader”, mais de ne pas savoir revenir proprement quand un module critique (paiement, transporteur, ERP) se comporte différemment sur la version cible.