Migrer vers PrestaShop 9 : comment réussir sa transition sans perdre SEO, commandes ni performances

Migrer vers PrestaShop 9 peut sécuriser et moderniser une boutique, mais la réussite ne dépend pas du bouton de mise à jour. Elle dépend de l’audit, de la compatibilité du thème et des modules, de la préservation des données, du plan SEO et de la recette avant mise en ligne.

Ce guide présente une méthode opérationnelle pour passer à PrestaShop 9.1 sans exposer inutilement les commandes, le chiffre d’affaires ni la visibilité organique. Il s’adresse aux boutiques PrestaShop 1.6, 1.7 ou 8.x, avec un parcours à adapter à la version de départ et aux développements spécifiques.

par Laurent Lacoste – Architecte Web, toonetcreation

1. Pourquoi migrer vers PrestaShop 9 ?

Une migration ne doit pas être décidée parce qu’une nouvelle version existe. Elle devient prioritaire lorsque la version actuelle freine la sécurité, la maintenance, les performances ou les évolutions commerciales de la boutique.

Les apports concrets de PrestaShop 9.1

PrestaShop 9 modernise le socle technique avec Symfony 6.4 LTS et les versions récentes de PHP. La branche 9.1 fait de Hummingbird 2.0 le thème par défaut des nouvelles installations et poursuit la modernisation du back-office, de l’API d’administration et des intégrations.

Pour un marchand, les bénéfices attendus sont surtout indirects : une base plus maintenable, une meilleure compatibilité avec l’écosystème actuel et davantage de marge pour faire évoluer la boutique. La migration ne garantit toutefois ni un site plus rapide ni un meilleur taux de conversion si le thème, les modules et l’hébergement restent mal optimisés.

Les signaux qui justifient de lancer le projet

• la version PHP ou la base de données ne peuvent plus être maintenues correctement ;
• des modules critiques ne reçoivent plus de correctifs ou bloquent les mises à jour ;
• le thème accumule les overrides et les correctifs difficiles à tester ;
• le tunnel de commande, le catalogue ou le back-office deviennent instables ;
• les coûts de maintenance augmentent sans améliorer l’expérience client ;
• une refonte, un nouvel ERP, un PIM ou une évolution logistique exige un socle plus récent.

Faut-il mettre à jour, migrer ou refondre ?

Le bon scénario se choisit après inventaire. Copier l’ancien site dans une version neuve transfère souvent les problèmes au lieu de les résoudre.

Ce qu’une migration ne garantit pas

Une nouvelle version ne fait pas automatiquement progresser le SEO, les Core Web Vitals ou le chiffre d’affaires. Elle crée une occasion de corriger l’architecture, d’alléger le thème, de supprimer des modules inutiles et de fiabiliser les données. Les gains viennent de ce travail, pas du numéro de version seul.

2. Les prérequis techniques et l’audit indispensable avant de migrer

L’audit transforme une question vague — « Est-ce que la migration va fonctionner ? » — en une liste de risques, de décisions et de tests. Il doit couvrir le serveur, le code, les données, les flux métier, le SEO et la mesure.

2.1. Vérifier l’hébergement et les prérequis

La préproduction doit reproduire les composants structurants de la production. Un test effectué avec une autre version de PHP, d’autres règles de cache ou une base de données différente peut donner un faux sentiment de sécurité.

2.2. Classer les modules, le thème et les développements

Pour chaque module, documentez son rôle, son éditeur, sa version, sa compatibilité avec PrestaShop 9.1, ses tables et ses dépendances. Classez ensuite les éléments en quatre catégories :

• conserver : indispensable, maintenu et compatible ;
• mettre à jour : utile, mais une version compatible est nécessaire ;
• remplacer : fonction indispensable sans continuité technique fiable ;
• supprimer : doublon, fonction inutilisée ou dette sans valeur métier.

Appliquez le même inventaire au thème, aux overrides, aux hooks, aux scripts JavaScript, aux templates d’e-mails et aux tâches automatiques. Le nombre de modules ou l’âge du thème ne suffisent pas à décider d’une refonte : c’est leur maintenabilité réelle qui compte.

2.3. Auditer le catalogue, les clients et les commandes

Mesurez les volumes et contrôlez la cohérence des données avant de les déplacer :

• produits, déclinaisons, attributs, caractéristiques, catégories et médias ;
• stocks, entrepôts, prix spécifiques, promotions et règles de panier ;
• clients, adresses, consentements, groupes et historiques ;
• commandes, factures, avoirs, paiements et statuts logistiques ;
• données ajoutées par des modules ou développements sur mesure.

Les doublons, valeurs orphelines et tables abandonnées doivent être traités avant la migration ou explicitement intégrés au script de transformation. Une sauvegarde ne remplace pas un test de restauration.

2.4. Cartographier les flux métier et les dépendances invisibles

Une boutique peut sembler fonctionnelle alors qu’un flux essentiel est interrompu. Listez les échanges avec :

• ERP, CRM, PIM, WMS et outils de facturation ;
• banques, prestataires de paiement et solutions antifraude ;
• transporteurs, génération d’étiquettes et suivi de colis ;
• marketplaces, comparateurs, flux produits et campagnes publicitaires ;
• e-mailing, SMS, avis clients, fidélité et service après-vente ;
• consentement, analytics, gestionnaire de balises et conversions publicitaires.

Pour chaque flux, identifiez un propriétaire métier, un scénario de test, un résultat attendu et une procédure en cas d’échec.

2.5. Établir le référentiel SEO avant migration

Le référentiel SEO sert à prouver que les pages importantes, leurs signaux et leur contenu ont été préservés. Il doit regrouper :

• un crawl complet avec codes HTTP, canonicals, directives robots et profondeur ;
• les URL qui génèrent du trafic, des conversions, des backlinks ou des impressions ;
• les Title, H1, descriptions, contenus, données structurées et hreflang ;
• les sitemaps, règles robots.txt, facettes et paramètres ;
• les performances et indicateurs Search Console avant bascule.

Conservez les URL performantes quand cela est possible. Si une URL doit changer, mappez-la vers la page la plus équivalente et utilisez une redirection permanente côté serveur. Une redirection vers la page d’accueil n’est pas une alternative pertinente à une page produit ou catégorie supprimée.

2.6. Définir les critères de validation et le retour arrière

Avant de commencer, écrivez les conditions qui autorisent la mise en production : absence d’erreur bloquante, commandes de test validées, données réconciliées, redirections contrôlées, mesure opérationnelle et accord des responsables métier. Définissez aussi le seuil qui déclenche un retour arrière et la durée pendant laquelle ce retour reste possible.

3. Le plan complet de migration PrestaShop

Le plan suivant donne l’ordre de travail. Les outils et le chemin technique changent selon la version source, mais les points de contrôle restent les mêmes.

Étape 1 : cadrer le périmètre et figer le référentiel

1. valider la version cible stable et le chemin de migration ;
2. prioriser ce qui est conservé, remplacé, supprimé ou refondu ;
3. définir les KPI de référence et les critères d’acceptation ;
4. planifier les responsabilités, les indisponibilités et la communication.

Étape 2 : créer une préproduction isolée

Clonez les fichiers et la base dans un environnement protégé. Bloquez son indexation et, si possible, son accès public. Neutralisez les e-mails clients, paiements réels, webhooks et exports susceptibles de déclencher des actions en production.

Étape 3 : sauvegarder et tester la restauration

Conservez au minimum les fichiers, la base, les médias, les configurations serveur et les secrets nécessaires à la remise en service. Faites un test de restauration chronométré : l’objectif de retour arrière doit reposer sur une durée observée, pas sur une estimation.

Étape 4 : préparer le cœur, les modules et le thème

Selon le scénario retenu, utilisez le chemin de mise à jour supporté ou préparez une installation propre. Installez uniquement les versions compatibles des modules. Reprenez les personnalisations de façon documentée et testable, sans recopier aveuglément les anciens fichiers.

Étape 5 : migrer et réconcilier les données

Exécutez la migration sur une copie récente, puis comparez les volumes et les montants :

• nombre de produits actifs, catégories, déclinaisons et images ;
• comptes clients, adresses, commandes, factures et avoirs ;
• stocks, prix, taxes, promotions et règles de livraison ;
• données des modules et correspondances d’identifiants.

La comparaison doit porter sur les totaux, mais aussi sur des échantillons complexes : commande multidevise, plusieurs taux de TVA, remboursement partiel, produit avec déclinaisons ou expédition multi-colis.

Étape 6 : appliquer le plan SEO

1. réutiliser les URL existantes quand elles restent cohérentes ;
2. implémenter les redirections permanentes prévues dans le mapping ;
3. mettre à jour liens internes, canonicals, hreflang, données structurées et sitemaps ;
4. contrôler les pages exclues, facettes, filtres et paramètres ;
5. comparer le crawl de préproduction au référentiel source.

Étape 7 : réaliser la recette fonctionnelle et technique

Étape 8 : préparer et exécuter la bascule

Choisissez une période de faible activité avec les équipes nécessaires disponibles. Évitez les soldes, les lancements marketing et les pics logistiques. Le jour J :

1. figez les opérations qui peuvent créer un écart de données ;
2. réalisez une sauvegarde finale ;
3. migrez le delta de données si le projet le nécessite ;
4. basculez l’infrastructure et videz les caches utiles ;
5. retirez les blocages d’indexation prévus uniquement pour la préproduction ;
6. exécutez les tests critiques et vérifiez le monitoring.

Étape 9 : surveiller et stabiliser

Les premières heures servent à traiter les erreurs bloquantes ; les semaines suivantes servent à détecter les écarts plus lents : indexation, conversion, performance réelle, retours clients ou problèmes logistiques. Affectez chaque alerte à une personne et documentez les corrections.

4. Les pièges fréquents et comment les éviter

4.1. Confondre version compatible et ensemble compatible

Le cœur peut accepter une version de PHP alors qu’un module ne l’accepte pas. La compatibilité se valide sur l’ensemble serveur + cœur + thème + modules + développements, avec les versions réellement installées.

4.2. Importer toute la dette de l’ancien site

Recopier des fichiers historiques, des overrides inutilisés et des tables abandonnées réduit l’intérêt de la migration. Chaque élément repris doit avoir un rôle métier, un propriétaire et un test.

4.3. Tester uniquement le parcours nominal

Une commande par carte bancaire ne suffit pas. Testez aussi le refus de paiement, les remboursements, les taxes, les devises, les promotions cumulées, les produits hors stock, les comptes invités et les transporteurs selon plusieurs zones.

4.4. Modifier les URL sans mapping

Une migration technique n’impose pas de réécrire toutes les URL. Si leur modification est justifiée, associez chaque ancienne URL utile à sa destination équivalente, mettez à jour les liens internes et contrôlez les redirections avant la mise en ligne.

4.5. Oublier la mesure et le consentement

Un nouveau thème peut déplacer ou doubler les scripts. Vérifiez les événements e-commerce, les valeurs de commande, les identifiants de transaction, les déclenchements après consentement et les conversions publicitaires.

4.6. Considérer la sauvegarde comme un plan de retour

Le retour arrière exige une procédure, des accès, un responsable et un délai maximum. Sans restauration testée, la sauvegarde peut être incomplète ou trop longue à remettre en service.

4.7. Fermer le projet dès la mise en ligne

Les problèmes d’indexation, de délivrabilité, de flux marketplace ou de logistique peuvent apparaître après plusieurs jours. Le suivi à 48 heures, 7 jours et 30 jours fait partie de la migration.

5. Checklist et KPI post-migration

Comparez les résultats avec une période de référence représentative, en tenant compte de la saisonnalité, des campagnes et des ruptures de stock. Les objectifs absolus complètent cette comparaison, mais ne la remplacent pas.

Dans les premières heures

• passer des commandes réelles de faible montant sur chaque moyen de paiement critique ;
• vérifier les confirmations, factures, e-mails, webhooks et statuts ;
• contrôler transporteurs, étiquettes, stocks et exports ;
• surveiller erreurs 4xx/5xx, logs applicatifs, charge serveur et files d’attente ;
• valider analytics, consentement et conversions ;
• tester les principales pages sur mobile et ordinateur.

Dans les 7 premiers jours

• comparer les crawls avant/après et corriger les écarts inattendus ;
• contrôler sitemap, robots.txt, canonicals, hreflang et données structurées ;
• surveiller Search Console, les 404 et les URL exclues ;
• comparer taux d’ajout au panier, passage au paiement et conversion ;
• vérifier les retours du service client, de la logistique et de la comptabilité.

À suivre pendant 30 jours

Quand peut-on considérer la migration comme réussie ?

La migration est maîtrisée lorsque les commandes et flux métier fonctionnent, que les données sont réconciliées, que la visibilité organique ne présente pas d’anomalie non expliquée, que la mesure est fiable et que l’équipe peut administrer la nouvelle version. Le résultat doit être constaté dans les données, pas seulement dans l’absence de plainte.

FAQ – Migration PrestaShop 9

La migration vers PrestaShop 9 est-elle obligatoire ?

Non. Elle devient pertinente lorsque la version actuelle, l’hébergement ou l’écosystème de modules créent un risque ou bloquent les évolutions. La priorité doit être évaluée selon la sécurité, le support, la dette technique et les objectifs commerciaux.

Quelle version de PrestaShop 9 choisir en août 2026 ?

Pour la production, utilisez une version stable de la branche 9.1 et vérifiez la dernière maintenance disponible au moment du projet. PrestaShop 9.2 étant encore en bêta à la date de mise à jour de cet article, elle convient aux tests, pas à une boutique en production.

Combien de temps dure une migration PrestaShop ?

La durée dépend de la version de départ, du catalogue, des modules, du thème, des développements spécifiques et des flux externes. Une boutique simple peut demander quelques semaines ; un projet avec refonte, ERP et forte personnalisation demande davantage. L’audit doit produire un planning par lots et non une promesse générique.

Peut-on migrer sans perdre de SEO ?

On peut fortement réduire le risque en conservant les URL importantes, en préparant le mapping, en mettant à jour les signaux techniques et en comparant les crawls. Une fluctuation temporaire reste possible ; aucune agence sérieuse ne peut garantir une hausse automatique ou une absence absolue de variation.

Faut-il refaire le thème ?

Pas systématiquement. Conservez-le s’il est compatible, maintenable, performant et correctement testé. Refaites-le si sa dette technique, ses overrides ou ses modules embarqués rendent l’adaptation plus risquée et coûteuse qu’une base propre.

Peut-on conserver les clients, commandes et produits ?

Oui, ces données peuvent être reprises, à condition de définir les correspondances, de nettoyer les incohérences et de réconcilier les volumes et montants après migration. Les données ajoutées par des modules spécifiques demandent une analyse complémentaire.

Peut-on utiliser Update Assistant pour passer à PrestaShop 9.1 ?

PrestaShop indique qu’une boutique 9.0.x peut passer à 9.1 avec une version compatible d’Update Assistant. Pour une version plus ancienne, le chemin doit être vérifié selon la version source et l’état de la boutique. Dans tous les cas, sauvegardez, testez en préproduction et contrôlez les incompatibilités avant la production.

Quel est le meilleur moment pour migrer ?

Choisissez une période de faible activité, hors soldes, lancement ou pic logistique, avec les équipes techniques et métier disponibles. Le vendredi n’est pas interdit par principe, mais une bascule n’a de sens que si le support reste mobilisable pendant toute la fenêtre de surveillance.