Migrer de PrestaShop 1.7 vers PrestaShop 9 : guide technique

Passer de PrestaShop 1.7 à PrestaShop 9 n'est pas une mise à jour que l'on lance d'un clic depuis le back-office. Entre les deux, il y a un changement de socle technique majeur (Symfony, PHP 8, refonte de l'architecture), une compatibilité de modules à reconstruire et une poignée de pièges précis qui transforment une migration mal préparée en boutique cassée le jour de la bascule. Ce guide décrit la méthode que nous appliquons sur le terrain, et surtout les écueils PrestaShop 9 que l'on ne découvre nulle part dans la documentation officielle.

Pourquoi 1.7 → 9 n'est pas une simple montée de version

PrestaShop 9 repose sur une stack modernisée : PHP 8.1 minimum (PHP 8.2/8.3 recommandés), MySQL 5.7+/MariaDB 10.3+, et une base Symfony bien plus présente que dans la 1.7. Concrètement :

• De nombreux modules conçus pour la 1.7 ne fonctionnent plus tels quels (hooks supprimés, surcharges incompatibles, dépendances Symfony).
• Les thèmes 1.7 personnalisés demandent une reprise : la couche d'administration et certaines logiques de rendu ont évolué.
• La base de données change de schéma. Une bascule directe sans étape intermédiaire est risquée.

La règle d'or : on ne migre jamais en production. On reconstruit une boutique 9 sur un environnement parallèle, on y importe les données, on recette, puis on bascule en quelques minutes.

Étape 1 — L'audit de compatibilité

Avant la moindre ligne de migration, on inventorie ce qui devra survivre à la bascule :

• Modules : lister chaque module, sa version, et vérifier l'existence d'une version compatible PrestaShop 9. Les modules critiques (paiement, transport, marketing) sont à valider en priorité — un module de paiement non compatible bloque la mise en ligne.
• Thème : un thème 1.7 sur-mesure n'est pas plug-and-play en 9. Prévoir un budget de reprise du thème, voire une refonte si le thème d'origine n'est plus maintenu.
• Surcharges et modules maison : tout code custom (overrides, modules internes) doit être relu à la lumière de PHP 8 et des hooks PrestaShop 9.
• Volume et structure : nombre de produits, déclinaisons, catégories, règles de prix, URLs — c'est ce qui dimensionne le mapping de données et le plan de redirection.

Étape 2 — Le chemin de migration

PrestaShop ne garantit pas un saut direct propre de la 1.7 vers la 9. En pratique, deux approches coexistent :

• Mise à jour par paliers (1.7 → 8 → 9) via le module de mise à jour officiel, sur une copie. C'est la voie « historique », mais elle traîne souvent la dette technique de la 1.7 (modules morts, tables obsolètes, données incohérentes).
• Reconstruction + migration de données : on installe une 9 propre et on transfère uniquement les données utiles (produits, clients, commandes, contenus, URLs). C'est l'approche que nous privilégions pour les catalogues anciens : on repart sur une base saine et on ne migre pas les problèmes.

Le choix dépend de l'état de la boutique d'origine. Une 1.7 récente et bien tenue se prête à la mise à jour par paliers ; une boutique ancienne chargée de modules abandonnés gagne à être reconstruite.

Étape 3 — Migration de la base et des données

Quelle que soit l'approche, quelques points techniques reviennent systématiquement :

• Charset et collation : aligner la base en utf8mb4 pour éviter les caractères cassés (accents, emojis) après migration.
• Intégrité des relations : produits ↔ déclinaisons ↔ attributs ↔ images ↔ catégories. Un mapping qui casse une relation produit invisible côté front.
• Images et médias : transférer les fichiers ET régénérer les vignettes. C'est là que se cachent les premiers pièges PrestaShop 9 (voir plus bas).

Étape 4 — Préserver le SEO

C'est l'aspect le plus sensible d'une migration. La structure des URLs PrestaShop évolue selon la configuration ; il faut donc garantir que chaque ancienne URL retombe au bon endroit. Les incontournables :

• Un plan de redirections 301 exhaustif, ancien → nouveau, produit par produit et catégorie par catégorie. C'est la pièce maîtresse : voir notre méthode pour bâtir un plan de redirections 301.
• Vérifier les balises canonical, les balises title et meta description, et la cohérence du maillage interne.
• Régénérer le sitemap.xml et le soumettre dans Google Search Console juste après la bascule.
• Surveiller l'indexation et les erreurs 404 pendant les semaines qui suivent (voir notre checklist migration en 40 points).

Les pièges PrestaShop 9 qui cassent une migration

Voici les problèmes concrets, rencontrés en production, qui ne sont documentés nulle part et qui font échouer une migration « réussie » sur le papier.

Les images WebP ne sont pas générées à l'import par l'API

Lorsqu'on importe des images via l'API PrestaShop, la 9 génère les vignettes JPG mais pas les versions WebP. Or les thèmes modernes utilisent <picture><source srcset="...webp"> en priorité : résultat, des images cassées (404 sur le WebP) en façade alors que le JPG existe. Il faut générer les WebP manquants après import, sinon le catalogue paraît vide.

La colonne ps.sales n'existe plus

La colonne de ventes utilisée pour trier les « meilleures ventes » a été retirée en PrestaShop 9. Tout module, requête SQL ou tri qui s'appuie dessus tombe en erreur. Il faut remplacer la logique (par exemple par un tri sur la date d'ajout ou une autre métrique) avant la bascule.

Le cache qui détruit le conteneur Symfony

Appeler une purge de cache trop brutale (ou supprimer manuellement var/cache/prod/) détruit le conteneur Symfony du front et provoque une erreur 500 à la requête suivante. Pendant une migration, où l'on vide souvent les caches, c'est un classique. Il faut purger proprement (vidage Smarty ciblé, réchauffage du cache via la console) plutôt qu'un effacement sauvage.

Les facettes haute cardinalité font exploser le TTFB

La recherche à facettes (filtres de catégorie) peut faire grimper le temps de réponse origine à plusieurs secondes sur les catégories chargées (beaucoup de valeurs d'attributs et de filtres actifs). Ce n'est pas un problème d'index : c'est la cardinalité des facettes et le rendu. Après migration, il faut réduire les filtres aux plus utiles (marque, prix, disponibilité) pour garder des pages de catégorie rapides.

Derrière un reverse proxy : l'admin en 500

À partir de PrestaShop 9.1, derrière un proxy SSL (Traefik, Nginx, Cloudflare…) mal déclaré, le back-office peut renvoyer une erreur 500 (« Infinite redirection detected ») car PrestaShop ne détecte plus la connexion comme sécurisée. La configuration des proxys de confiance résout le problème — un piège qui n'apparaît qu'après la mise en ligne derrière l'infrastructure de production.

Les images « placeholder » de la 1.7

Les visuels « No image available » hérités de PrestaShop 1.7 ont une signature de poids identifiable. Lors de la migration, mieux vaut les détecter et les exclure plutôt que de les transférer comme de vraies images produit, sous peine de polluer le nouveau catalogue.

Recette et mise en production

Avant la bascule, on déroule une recette complète sur l'environnement de staging : parcours d'achat de bout en bout, paiement (en mode test), tunnel de commande, e-mails transactionnels, comptes clients, contrôle SEO (URLs, redirections, canonical, sitemap), et performance des pages de catégorie. La bascule elle-même se fait à chaud, en quelques minutes, pour viser un downtime nul. Une procédure de rollback testée doit permettre de revenir à l'état initial si un imprévu survient.

Suivi post-migration

Une migration ne s'arrête pas à la mise en ligne. Pendant les semaines qui suivent, on surveille : l'indexation et les 404 dans Search Console, les redirections effectivement servies, les performances, et les éventuelles régressions de conversion. C'est ce monitoring qui garantit que le référencement acquis depuis des années est bien préservé.

En résumé

Migrer de PrestaShop 1.7 vers 9, c'est 20 % de transfert de données et 80 % de préparation : audit de compatibilité, choix du chemin de migration, anticipation des pièges PrestaShop 9 (WebP, cache, facettes, proxys) et plan de redirection 301 rigoureux. Bien menée, la migration devient même une occasion d'améliorer la performance et le SEO de la boutique plutôt que de les dégrader.