PrestaShop 1.7 a longtemps été le socle de nombreuses boutiques françaises. PrestaShop 8 a servi de pont. PrestaShop 9 change encore le runtime, les modules et une partie des APIs. Si votre boutique tourne encore en 1.7.x, attendre « que ça se fasse tout seul » n'est plus une stratégie : le PHP vieillit, les modules premium lâchent, les failles restent ouvertes. Cet article explique ce que signifie réellement migrer de PrestaShop 1.7 vers PrestaShop 9, ce qu'on préserve (commandes, clients, URLs, avis), ce qu'on réécrit (thème, modules morts), et comment basculer sans casser le tunnel de vente ni perdre une journée de ventes.
🔎 Pourquoi on ne « met pas à jour » PrestaShop 1.7 vers 9
Entre PrestaShop 1.7 et PrestaShop 9, le cœur a changé plusieurs fois. Le passage par PrestaShop 8 a déjà cassé des modules, déplacé des hooks, imposé un PHP plus récent. PrestaShop 9 continue dans cette voie. Une mise à jour en un clic sur une boutique 1.7.8 avec vingt modules marketplace, un thème sur-mesure et des overrides, c'est la garantie d'un tunnel de vente blanc un vendredi soir.
On parle donc de migration : on installe une PrestaShop 9 propre, on y verse les produits, les clients, les commandes, les règles, et on reconstruit ce qui ne traverse pas. Cette phrase déçoit ceux qui espéraient un bouton. Elle protège le chiffre d'affaires. Une boutique qui fait du chiffre d'affaires ne se « met pas à jour ». Elle se bascule.
🛠️ Ce que PrestaShop 9 change pour une boutique 1.7
PrestaShop 9 impose un PHP moderne, un socle Symfony plus récent, et une discipline plus stricte sur les modules. Beaucoup d'extensions écrites pour 1.7 n'existent plus, ou existent en version payante incompatible. Les overrides dans /override, déjà fragiles en 1.7, deviennent une dette à inventorier un par un. Le thème 1.7 classique ne se pose pas tel quel sur 9.
Côté métier, l'admin change, le flux de commande aussi par endroits, le back-office n'est plus exactement le même. Les équipes livraison et SAV doivent être formées avant le jour J, pas le lundi matin après la bascule. Une migration PrestaShop 1.7 vers PrestaShop 9 qui oublie la vérification métier réussit techniquement et échoue commercialement.
- PHP et runtime à jour, souvent un changement d'hébergement en même temps
- Modules 1.7 à recenser : natifs, premium, sur-mesure, morts
- Thème 1.7 à reconstruire ou à remplacer, rarement à « porter »
- Overrides et classes locales à documenter avant d'y toucher
✅ L'inventaire avant d'écrire une ligne
On liste les modules, leur éditeur, leur compatibilité PrestaShop 9, et ce qu'ils font vraiment (souvent moins que leur nom). On liste les règles panier, les transporteurs, les moyens de paiement, les webhooks (ERP, compta, marketplaces). On liste les URLs qui travaillent : pages produits, catégories, CMS, landing pages publicitaires. Sans cet inventaire, la migration est une copie aveugle.
On exporte aussi un échantillon de commandes récentes, de clients B2B s'il y en a, de stocks, de déclinaisons. Le jour où les produits « ont l'air bons » mais que les packs et les attributs sont faux, c'est trop tard pour le découvrir en production. L'inventaire prend deux à cinq jours. Il évite six semaines de surprise.
⚠️ Préserver commandes, clients et historique
Les commandes ne sont pas décoratives. SAV, comptabilité, garanties, relances : elles doivent arriver dans PrestaShop 9 avec IDs stables ou une table de correspondance. Les clients aussi, avec leurs adresses, groupes, bons de réduction encore valides. Une migration qui « recrée les comptes » casse la confiance et le support.
Je migre l'historique, pas seulement les produits actifs. Un client qui rouvre une commande de 2023 doit la retrouver. Si un ERP s'appuie sur l'identifiant PrestaShop, on le dit avant : soit on conserve les IDs, soit on prévoit le mapping. C'est un point à trancher avant de développer, pas un détail d'import.
📌 Modules : ce qui traverse, ce qu'on réécrit, ce qu'on jette
Un module natif ou un module premium à jour pour PrestaShop 9 se réinstalle, on reteste le flux. Un module 1.7 abandonné se remplace, ou on réécrit la fonction utile (souvent 20 % du module d'origine). Un module « fourre-tout » qui touche le tunnel de vente, le prix et le mail se découpe : on ne le porte pas tel quel.
Les paiements et les transporteurs se vérifient sur un staging qui parle aux sandboxes, pas en production le jour J. Un module de paiement qui « marchait en 1.7 » n'est pas compatible par magie. C'est souvent lui qui fait échouer la bascule, pas les produits.
🧭 Thème et front : ne pas copier-coller le 1.7
Le thème PrestaShop 1.7, même « premium », n'est pas un thème PrestaShop 9. On reprend le design system, les templates produit, le header, le tunnel. On ne copie pas les TPL. C'est plus difficile à vendre qu'à dire, et c'est le seul moyen d'avoir un front maintenable après la migration.
Si le thème 1.7 était déjà un empilement de surcharges, la migration est l'occasion de revenir à un thème enfant mince. Moins de fichiers, plus de hooks, moins de peur à la prochaine version. Une boutique PrestaShop 9 livrée avec le même spaghetti 1.7 n'a fait que changer de numéro de version.
💡 SEO : URLs, redirections, pages produits qui travaillent
Les pages produits et les catégories qui positionnent doivent garder leur URL, ou avoir une 301 dès la première requête. PrestaShop a une histoire chargée avec les IDs dans les URLs, les réécritures et les pages filtres. On exporte le plan d'URLs 1.7, on le rejoue en 9, on vérifie dans Search Console après la bascule.
On ne « profite pas » de la migration pour tout renommer. Le relooking des slugs se fait plus tard, mesuré, URL par URL. Le jour de la bascule, l'objectif est zéro 404 sur le top 200 des pages qui amènent du trafic ou des conversions.
🧪 La bascule : staging, gel, jour J, rollback
On construit PrestaShop 9 sur un staging. On y verse une copie, on vérifie produits, tunnel de vente, paiements sandbox, mails, transporteurs, back-office. Puis on gèle les écritures (ou on prévoit un delta de commandes), on rejoue l'import, on bascule le DNS ou le vhost. Un rollback est écrit : revenir à la 1.7 en moins d'une heure si le tunnel de vente casse.
Le gel n'est pas une journée entière si on sait rejouer le delta. Mais quelqu'un doit être disponible : client, livraison, moi. Une migration PrestaShop 1.7 vers PrestaShop 9 un dimanche sans vérification métier, c'est un lundi de commandes fantômes. On planifie. On ne « profite pas d'un creux » sans script de retour.
🔎 Après PrestaShop 9 : TMA, pas abandon
Le lendemain, on surveille les commandes, les mails, les 404, les paiements. La première semaine est de la TMA intensive, pas de la clôture de projet. Ensuite on pose un forfait : mises à jour, monitoring, tickets. Une boutique PrestaShop 9 sans maintenance redevient une 1.7 dans deux ans : peur des mises à jour, modules morts, PHP périmé.
Si votre boutique est encore en 1.7.x, le bon moment n'est pas « quand PrestaShop 9 sera stable depuis trois ans ». Le bon moment est avant que le PHP de production ne soit plus patché, et avant qu'un module de paiement lâche. Un audit de migration tient en quelques jours. Il dit ce qui se porte, ce qui se réécrit, et ce que ça coûte vraiment.
Sauter de 1.7 à 9 sans inventaire, c'est changer d'étage en emportant les fuites.
