Migration PrestaShop : guide complet pour les versions 1.7, 8 et 9

Publié le 20/03/2026 — PrestaShop

Migrer une boutique PrestaShop est un projet technique à part entière. Entre la compatibilité des modules, l'adaptation du thème, la migration de la base de données et la préservation du référencement naturel, les risques d'une migration mal préparée sont réels : perte de données, chute du trafic SEO, interruption des ventes. Ce guide couvre les migrations de PrestaShop 1.7 vers 8 et de PrestaShop 8 vers 9, avec les bonnes pratiques pour chaque étape.

Pourquoi migrer votre boutique PrestaShop ?

Le support de sécurité de PrestaShop 1.7 a pris fin en 2024. Rester sur une version non maintenue expose la boutique à des failles de sécurité non corrigées et à l'incompatibilité progressive avec les versions récentes de PHP. Les versions 8.x et 9.x apportent :

• Performances améliorées — +25 à 40 % sur les requêtes catalogue grâce à l'optimisation du core et au support de PHP 8.1+.
• Back-office modernisé — Interface d'administration migrée vers Symfony, plus rapide et plus ergonomique.
• Sécurité — Correctifs réguliers, headers de sécurité, meilleures pratiques de chiffrement.
• Nouvelles fonctionnalités — Admin API (PrestaShop 9), thème Hummingbird 2.0, multi-transporteurs, refonte des promotions dans la version 9.1.
• Compatibilité PHP — PrestaShop 8 supporte PHP 8.1, PrestaShop 9.0 supporte PHP 8.1 à 8.4, et PrestaShop 9.1 supporte PHP 8.5.

Migration PrestaShop 1.7 vers 8 : la priorité

Si votre boutique tourne encore sur PrestaShop 1.7, la migration vers la version 8.2 est la première étape recommandée. La version 8 offre un excellent compromis entre stabilité, compatibilité des modules et modernité technique.

Les étapes clés

1. Audit complet — Inventaire de chaque module installé, thème personnalisé et intégration tierce (ERP, CRM, transporteurs). Vérification de la compatibilité de chaque module avec PrestaShop 8 sur le marketplace officiel. L'audit représente souvent 30 à 50 % du temps total de la migration.
2. Sauvegarde — Export de la base de données MySQL complète (tables ps_orders, ps_customer, ps_product et leurs relations). Archive des fichiers : thèmes, modules, images produits et documents joints. Test de restauration pour valider l'intégrité.
3. Environnement staging — Installation de PrestaShop 8 sur un sous-domaine ou un serveur de test. Configuration PHP 8.1+, MySQL 8.0+ et extensions requises (intl, curl, gd, zip).
4. Mise à jour du core — Remplacement des fichiers core (tout sauf /modules/, /themes/votretheme/, /img/, /upload/). Mise à jour des dépendances via Composer. Exécution des scripts de migration SQL.
5. Adaptation des modules — Environ 35 % des modules 1.7 nécessitent une mise à jour. Vérification des hooks (certains renommés ou dépréciés entre 1.7.8 et 8.x) et des contraintes de version dans les fichiers composer.json des modules.
6. Adaptation du thème — Le thème 1.7 n'est pas compatible avec PrestaShop 8. Les changements technologiques (Symfony, Twig, Bootstrap 5) imposent un travail d'adaptation ou une refonte du thème.
7. Nettoyage technique — Remplacement des overrides par des hooks et services Symfony. Nettoyage du cache et des fichiers de classe compilés.
8. Tests complets — Simulation d'un parcours client complet (recherche → panier → paiement). Vérification des intégrations tierces (paiement, transporteurs, ERP).
9. Mise en production — Basculement en période creuse, mode maintenance, bascule DNS, soumission du nouveau sitemap.xml à Google Search Console.

Migration PrestaShop 8 vers 9 : la nouvelle génération

PrestaShop 9.0, sorti en juin 2025, est une refonte technique en profondeur. La version 9.1, dernière en date, apporte le thème Hummingbird 2.0, le multi-transporteurs et la refonte des promotions. Le passage de Symfony 4.4 à Symfony 6.4 LTS impacte l'ensemble de l'écosystème : modules, thèmes, overrides et intégrations.

Ce qui change techniquement

• Symfony 6.4 LTS — Tous les contrôleurs doivent être définis comme des services. L'injection de dépendances change. Le container passé aux contrôleurs n'est plus le container global.
• Back-office 100 % Symfony — Le layout est entièrement géré par des composants Twig. Le code est plus lisible mais les modules qui personnalisaient l'admin doivent être adaptés.
• Thème Hummingbird 2.0 — Nouveau thème par défaut : Bootstrap 5, convention BEM pour le CSS, SCSS avec @layer, TypeScript, dark mode natif, lazy loading, WebP/AVIF natif. Plus de 95 % de conformité avec l'European Accessibility Act (EAA) : HTML sémantique, attributs ARIA, navigation clavier et contrastes intégrés dès la conception. Les thèmes existants ne sont pas compatibles.
• Admin API — API REST basée sur API Platform pour connecter PrestaShop à des ERP, CRM ou outils d'automatisation.
• Hooks modifiés — Certains hooks admin ont été dépréciés ou supprimés. De nouveaux hooks Symfony ont été ajoutés.

L'Update Assistant (ex 1-Click Upgrade)

L'Update Assistant v7 est le module officiel de migration, entièrement refondu pour PrestaShop 9 :

• Interface redessinée avec suggestions intelligentes de version cible
• CLI pour les développeurs et les migrations automatisées
• Vérifications de prérequis détaillées, logs et rapports d'erreurs améliorés
• Initialisation du kernel Symfony pendant les scripts de migration des modules
• Compatible hébergement mutualisé (pas de CLI obligatoire pour les assets)

Risques spécifiques à la migration vers PrestaShop 9

Environ 60 % des problèmes post-migration constatés en 2026 concernent des incompatibilités de modules. Les modules qui utilisent des classes dépréciées, des overrides du back-office ou des hooks supprimés sont les plus impactés. Un audit module par module est indispensable avant de lancer la migration.

Les erreurs à éviter

Oublier les redirections 301

Si la structure des URLs change lors de la migration, chaque ancienne URL doit être redirigée vers la nouvelle via une redirection 301 permanente. Sans cela, le référencement naturel construit sur plusieurs années peut s'effondrer en quelques jours : pages en erreur 404, perte de positions, chute du trafic organique.

Négliger l'audit des modules

Croire qu'une mise à jour automatique suffira est une erreur coûteuse. Chaque module doit être vérifié individuellement : compatibilité avec la version cible, hooks utilisés, overrides, dépendances PHP. Les modules custom développés sur mesure nécessitent souvent une réécriture partielle.

Sauter l'environnement de staging

Migrer directement en production est un risque majeur. Un environnement de staging permet de tester la migration complète sans impacter la boutique en ligne. Les problèmes de base de données, d'affichage ou de tunnel d'achat sont détectés et corrigés avant la mise en production.

Oublier la synchronisation des stocks

Pendant la fenêtre de migration, les commandes continuent d'arriver sur l'ancien site. Sans synchronisation en temps réel des stocks, des ventes peuvent être validées sur des produits en rupture, des doublons de commande peuvent apparaître et la logistique peut être désorganisée.

Checklist de migration PrestaShop

Avant la migration

• Audit complet des modules (compatibilité version cible)
• Audit du thème (compatibilité Symfony / Bootstrap)
• Inventaire des overrides et hooks personnalisés
• Sauvegarde complète (BDD + fichiers) stockée hors serveur
• Vérification PHP, MySQL, HTTPS sur le serveur cible
• Plan de rollback opérationnel (retour en arrière en moins d'1h)

Pendant la migration

• Environnement staging dédié
• Migration de la base de données (structure + données)
• Adaptation / mise à jour des modules
• Adaptation / refonte du thème
• Configuration des redirections 301
• Test du tunnel d'achat complet (recherche → panier → paiement)
• Test des intégrations tierces (paiement, transporteurs, ERP)

Après la migration

• Basculement DNS en période creuse (fenêtre de 2 à 4h)
• Soumission du nouveau sitemap.xml à Google Search Console
• Surveillance des erreurs 404 pendant 48h
• Vérification Analytics / tracking
• Changement des mots de passe administrateur
• Conservation de l'ancien serveur actif 30 jours minimum

Quelle version choisir en 2026 ?

• Boutique PrestaShop 1.7 en production → Migrer vers PrestaShop 8.2 en priorité. C'est la version la plus stable avec le meilleur écosystème de modules.
• Boutique PrestaShop 8.x stable → Évaluer la migration vers PrestaShop 9 après un audit de compatibilité des modules. Si vos modules clés ne sont pas encore compatibles, attendre la version 9.1.
• Nouvelle boutique en 2026 → Partir directement sur PrestaShop 9 pour bénéficier de Symfony 6.4, du thème Hummingbird et de l'Admin API.
• Projet e-commerce complexe (B2B, marketplace) → Considérer Sylius, le framework e-commerce headless du même groupe que PrestaShop (Cyber_Pixel).

Questions fréquentes

Combien de temps dure une migration PrestaShop ?

La durée est très variable selon la complexité de la boutique existante : nombre de modules, personnalisations du thème, volume de données, intégrations tierces (ERP, CRM, transporteurs). L'audit de compatibilité des modules représente souvent 30 à 50 % du temps total. Chaque migration est un projet sur mesure.

Peut-on migrer directement de PrestaShop 1.7 vers 9 ?

C'est techniquement possible mais risqué. La recommandation officielle est de passer d'abord par la version 8.2 (stabilité, écosystème de modules mature) puis d'évaluer la migration vers la 9. Un saut direct de la 1.7 à la 9 cumule les ruptures de compatibilité et multiplie les risques.

Mes modules PrestaShop 1.7 fonctionneront-ils sur la version 8 ?

Environ 35 % des modules 1.7 nécessitent une mise à jour pour fonctionner sur PrestaShop 8. Les modules qui utilisent des overrides ou des hooks dépréciés sont les plus impactés. L'audit de compatibilité module par module représente souvent 30 à 50 % du temps total de migration.

Est-ce que je vais perdre mon référencement lors d'une migration ?

Pas si la migration est bien préparée. Les clés : mettre en place des redirections 301 pour chaque URL qui change, conserver les balises canoniques, soumettre le nouveau sitemap.xml à Google Search Console et surveiller les erreurs 404 pendant les 48 heures suivant la mise en production.