Migration PrestaShop 1.7 vers 9 : la méthode sans casser le SEO

La migration PrestaShop 1.7 vers 9 traîne sur votre to-do depuis 18 mois. Votre boutique tourne sur 1.7.8.x depuis 5 ans. Un module de paiement vient encore de planter ce mois-ci. Votre développeur vous dit que sa rustine ne tiendra pas un an de plus. PrestaShop 9 est en production stable depuis plus d'un an et PrestaShop 9.1.1 vient de sortir le 27 avril 2026. Vous repoussez.

Et chaque trimestre, le coût du report grimpe. Plus de mises à jour de sécurité sur la 1.7 depuis fin 2024. Les modules tiers lâchent un par un. Votre PageSpeed est descendu à 28 sur mobile. Sans le dire trop fort, votre trafic organique perd 5 à 8% par trimestre. Pas une chute brutale, juste un saignement lent que personne ne tire à temps.

Le vrai problème, ce n'est pas la mise à jour technique. L'outil Autoupgrade fait la 1.7 vers 8 en quelques heures, et la 8 vers 9 en quelques heures de plus. Le vrai problème, c'est tout ce qui casse autour : modules incompatibles, thème à reprendre, fiches produit qui se désindexent, hreflang qui saute, perte de positions sur les mots-clés qui vous ramènent vos meilleurs clients. Et avec PrestaShop 9, le saut Symfony 4.4 vers 6.4 démultiplie les ruptures côté modules tiers.

Chez Agence BPC, on a migré et repris des migrations PrestaShop sur 6 e-commerces en 2 ans. Les 3 reprises qu'on a faites avaient toutes le même problème : agence focus visuel, SEO sacrifié. Trafic en chute de 30 à 50% trois mois après la "réussite" de la migration. Le même piège qu'on retrouve dans nos reprises de refonte PrestaShop : checklist anti-catastrophe SEO.

Voici la méthode qu'on applique pour migrer 1.7 vers 9 sans casser. Trois phases sur 8 à 10 semaines, une checklist de contrôle à chaque étape, et un seul objectif : que votre Search Console montre la même courbe à J+90 qu'à J-30.

Migration PrestaShop 1.7 vers 9 : ce qu'il faut savoir

La migration PrestaShop 1.7 vers PrestaShop 9 est une mise à jour majeure qui nécessite PHP 8.1 minimum (8.5 recommandé), MySQL 5.7 ou MariaDB 10.2 minimum, et un saut Symfony 3.4 (PrestaShop 1.7) vers Symfony 6.4 LTS (PrestaShop 9). Comptez 8 à 10 semaines de projet réel pour un e-commerce avec 500 à 3 000 produits, 10 à 20 modules personnalisés et un thème custom.

Le risque principal n'est pas la migration elle-même : c'est l'incompatibilité massive des modules tiers (réécrits pour Symfony 6.4 et nouveau Kernel API), la disparition de certaines fonctionnalités natives (Advanced Stock Management, livraison multi-adresses, page produit legacy), et la perte de référencement Google si l'audit SEO n'est pas fait en amont. Un thème PrestaShop 1.7 n'est pas compatible PrestaShop 9 sans reprise quasi totale. Comptez en moyenne 60 à 80% du code à reprendre. La procédure officielle passe par le module Autoupgrade (documentation PrestaShop 9), en deux étapes successives (1.7 → 8 → 9) pour respecter le chemin supporté par PrestaShop.

PrestaShop 1.7 vs PrestaShop 9 : ce qui change techniquement

Pourquoi 80% des migrations PrestaShop ratent le SEO

Quand une migration se fait mal, ce n'est presque jamais à cause d'un bug visible. C'est à cause de ce qui se casse en silence dans les zones que personne ne regarde le jour du lancement.

On voit toujours les mêmes quatre dégâts sur les sites qu'on récupère après migration :

1. Le schema produit qui disparaît. PrestaShop 1.7 injecte par défaut un balisage Product et Offer dans les fiches produit. Au moment du passage en 9, le système de Presenters côté front office a changé : si le thème est ré-importé sans audit, ce balisage tombe ou pointe vers des structures de variables modifiées. Résultat : vos fiches sortent des rich results Google (prix, stock, étoiles). Vous perdez 15 à 30% de CTR sur vos meilleures fiches.

2. Les URLs qui glissent. PrestaShop 9 n'oblige pas à changer les structures d'URL, mais beaucoup de migrations le font "tant qu'on y est". Une URL qui change sans redirection 301 = une page qui se désindexe, perd ses backlinks et ses positions. Multiplié par 2 000 fiches produit, c'est un trafic divisé par deux. La doc officielle Google sur les redirections 301 précise que la prise en compte peut prendre plusieurs semaines.

3. Le hreflang multi-langues qui saute. Si votre boutique a plusieurs langues, le tag hreflang est géré différemment dans la 9 (refonte du back-office multi-boutique). Une mauvaise reprise = Google qui ne sait plus quelle version proposer à quelle audience. La version française tape la version belge dans les SERP, et l'inverse. Cannibalisation interne sur des dizaines de mots-clés.

4. La performance qui dégringole temporairement. PrestaShop 9 est plus rapide quand il est bien configuré (Symfony 6.4, OPcache moderne, Hummingbird 2.0). Mais entre le moment où on bascule et le moment où le cache est purgé, où l'OPcache est rebuild, où le CDN est repluggé, on a typiquement 4 à 8 semaines de Core Web Vitals dégradés (plus long qu'avec une 8 à cause des breaking changes Symfony). Si personne ne surveille, Google rétrograde des positions et personne ne sait pourquoi. À ce moment-là, votre site n'est pas en cause - mais votre site ne convertit pas parce qu'il est devenu invisible.

La clé pour éviter ces quatre pièges : audit complet AVANT la migration, snapshot des positions actuelles, et plan de récupération chiffré sur les 8 à 12 semaines qui suivent. Sans ces trois éléments, vous découvrez les dégâts en lisant votre CA du trimestre suivant.

Les 3 phases d'une migration PrestaShop propre

Phase 1 - L'audit pré-migration (semaines 1-2)

C'est la phase que 80% des prestataires sautent. C'est aussi celle qui détermine si la migration va se passer bien ou pas.

À l'audit, on regarde concrètement :

• Inventaire complet des modules : version installée, compatibilité PrestaShop 9 confirmée par l'éditeur, alternative si non compatible. Sur un PrestaShop 1.7 de 5 ans, il y a typiquement 15 à 25 modules. Comptez qu'au moins 5 à 10 vont nécessiter une mise à jour payante, un remplacement ou une réécriture (la migration Symfony 4.4 vers 6.4 a cassé Guzzle, Swift Mailer, Tactician Bundle, et 30+ hooks).
• Audit du thème custom : si votre thème a été modifié au fil des années (et c'est presque toujours le cas), il faut lister les surcharges, les hooks modifiés, les overrides. C'est cette liste qui détermine le temps de reprise du thème en version 9 (qui passe à Symfony 6.4 et utilise des Presenters côté front office).
• Cartographie des URLs : extraction de toutes les URLs indexées via Screaming Frog et Search Console. On note les fiches produit, les catégories, les pages CMS, les pages auteur si présentes. Cette liste devient la base du plan de redirection.
• Snapshot SEO : positions actuelles sur 50 à 100 mots-clés stratégiques, captures Search Console des impressions et clics, liste des pages qui génèrent 80% du trafic. Sans ce snapshot, vous ne saurez jamais si la migration a fait du mal ou non.
• Backup complet : base de données + fichiers + configuration serveur. En double, sur deux supports différents. C'est l'évidence, et c'est ce qu'on oublie le plus souvent.
• Tests serveur : votre hébergement actuel supporte-t-il PHP 8.1 minimum (8.5 recommandé), MySQL 5.7+ ou MariaDB 10.2+, et memory_limit 512M minimum ? Node.js 20.x pour le build des assets. Si vous êtes sur du mutualisé bas de gamme, c'est l'occasion de basculer sur un VPS dédié. Surcoût de 60 à 120 euros par mois, ROI immédiat en performance.
• Validation du chemin de migration : Autoupgrade ne permet pas le saut direct 1.7 vers 9. Le chemin officiel supporté est 1.7 → 8.x → 9.x, en deux étapes consécutives sur le staging. C'est aussi possible de partir d'un PrestaShop 9 vierge et de réimporter le catalogue, à arbitrer selon la dette technique.

À la fin de la phase 1, vous devez avoir un document chiffré qui dit : voici la durée, voici le budget, voici les risques identifiés, voici le plan de récupération SEO.

Phase 2 - La migration technique (semaines 3-7)

Toujours sur un environnement de staging. Toujours. On ne touche pas la production tant que la version migrée n'a pas tourné une semaine en staging sans erreur.

Le déroulé concret :

1. Clone complet en staging : duplication base + fichiers vers un sous-domaine type staging.votresite.fr, en noindex strict (pour éviter que Google indexe par erreur).
2. Première étape Autoupgrade 1.7 → 8.x sur le staging. Si tout est propre, ça prend 4 à 8 heures. Tests fonctionnels complets : panier, paiement, recherche, filtres, multi-langues.
3. Deuxième étape Autoupgrade 8.x → 9.x. Si modules incompatibles, ça plante. C'est normal et c'est pour ça qu'on est en staging. Comptez 50% des modules tiers à reprendre ou remplacer après ce saut.
4. Reprise du thème : intégration en PrestaShop 9 des templates customs. C'est ici que le gros du temps part. Comptez 30 à 80 heures de développement front selon la complexité (le saut Symfony 4.4 vers 6.4 a transformé les Presenters et la gestion de l'authentification back-office).
5. Réinstallation des modules un par un, version PrestaShop 9 confirmée. Test fonctionnel à chaque étape (panier, paiement, recherche, filtres). Beaucoup de modules tiers utilisaient Guzzle ou Swift Mailer : ils nécessitent réécriture pour utiliser Symfony HTTP client et Symfony Mailer.
6. Vérification du balisage SEO : meta titles, descriptions, schema produit, schema breadcrumb, sitemap.xml, robots.txt. Cette étape doit être validée AVANT la bascule en production.
7. Tests de paiement : Stripe, PayPal, virement, chaque mode de paiement testé pour un panier complet, du clic au mail de confirmation.
8. Bascule en production : choisie un jour calme (typiquement mardi matin), avec un plan de rollback prêt si quelque chose casse.

La règle d'or : on ne lance jamais en production un vendredi. Si ça casse, vous passez le weekend dessus. Toujours du mardi au jeudi matin.

Phase 3 - La récupération SEO (semaines 8-10)

C'est ici que la plupart des prestataires arrêtent leur prestation. C'est aussi ici que les vraies casses arrivent quand personne ne surveille.

Plan de monitoring sur 3 mois :

• J+1 : crawl Screaming Frog complet du site en production, comparaison avec le crawl pré-migration. On vérifie : 0 page en 404, 0 page en 5xx, 100% des URLs critiques répondent.
• J+1 à J+7 : monitoring quotidien Search Console. Apparition de "pages d'erreur de redirection" ou "page exclue" = action immédiate.
• J+7 : soumission du sitemap.xml actualisé dans Search Console. Demande d'exploration des 30 pages les plus importantes.
• J+30 : audit positions vs snapshot pré-migration. Si chute > 15% sur des mots-clés stratégiques : diagnostic en urgence (souvent schema cassé ou contenu modifié sans le savoir). Comptez aussi avec les délais de référencement Google qui peuvent expliquer une partie des écarts mesurés.
• J+60 : audit performance Core Web Vitals. Si Largest Contentful Paint > 2,5 s, optimisation cache + images. Hummingbird 2.0 fournit de bonnes bases mais peut nécessiter du fine-tuning sur les fiches produit complexes.
• J+90 : bilan complet. Trafic organique, positions, leads. Comparaison à 6 mois avec le baseline.

Sans cette phase 3, on a fait une migration. Avec cette phase 3, on a sécurisé un investissement.

7 erreurs qui coûtent du trafic après migration

Sur les 6 migrations qu'on a vues passer (3 menées par nous, 3 reprises après échec), ce sont toujours les mêmes erreurs qui reviennent. Les voici classées par fréquence d'apparition.

1. Garder des modules incompatibles "qui marchent quand même". Si l'éditeur ne déclare pas la compatibilité PrestaShop 9, il y a une raison. Le module tournera peut-être 3 mois sans bug visible, puis cassera après une mise à jour de PHP, un patch de sécurité ou une dépendance Symfony 6.4 réajustée. Le saut Symfony 4.4 vers 6.4 a déprécié de nombreux composants utilisés en sous-main par les modules tiers.

2. Oublier de réintégrer le schema produit. C'est le n°1 des dégâts silencieux. Vérification obligatoire dans Google Rich Results Test sur 10 fiches au hasard avant ET après migration. Le passage aux Presenters PrestaShop 9 change la structure de variables côté thème.

3. Laisser les URLs glisser sans plan de 301. Si une URL change (même un simple changement de format de slug catégorie), il FAUT une redirection 301. Pas une 302, pas une 307 : une 301 propre.

4. Ne pas backuper le hreflang multi-langues. Si vous êtes monolingue, ignorez. Si vous êtes multi-langues, c'est probablement le piège qui vous fera perdre 30% de trafic international.

5. Lancer en production sans staging. Inutile d'expliquer pourquoi. Personne ne le fait deux fois.

6. Ignorer la baisse temporaire de PageSpeed. Le cache met 3 à 6 semaines à se reconstruire complètement (plus long qu'avec une 8 à cause du nouveau Kernel API). Optimisations à faire en parallèle : compression images en WebP, lazy-loading, CDN, OPcache.

7. Pas de monitoring post-migration. Trois mois sans regarder, et quand vous découvrez que les ventes ont baissé, c'est trop tard pour rattraper proprement. Search Console est gratuite, il faut juste s'en servir chaque semaine.

Cas concret : migration d'un e-commerce BTP en 9 semaines

Client B2B sur PrestaShop 1.7.8.7 depuis 2019. Catalogue : 1 200 références, 6 langues (FR, EN, DE, IT, ES, NL), 18 modules tiers dont 4 développés sur-mesure. Trafic organique mensuel avant migration : 14 000 visites, dont 65% sur les pages produit.

Le contexte : module de paiement Stripe en fin de support sur la version 1.7, base de données qui grossit lentement vers les limites de l'hébergement, équipe interne qui ne veut pas refondre le site mais doit absolument se sécuriser pour les 5 ans à venir.

Déroulé réel :

• Semaines 1-2 : audit pré-migration. Découverte qu'un des modules sur-mesure utilise Guzzle 6 directement (cassé en PrestaShop 9) et une API dépréciée dans la nouvelle architecture (gestion stocks magasin). Décision : réécriture du module en Symfony HTTP client pendant la migration. Validation du chemin 1.7 → 8.2 → 9.1.
• Semaines 3-5 : première étape de migration 1.7 → 8.2 en staging. Tests complets. Stabilisation 1 semaine.
• Semaines 6-7 : deuxième étape 8.2 → 9.1 en staging. 7 modules tiers à remplacer ou faire upgrader par leurs éditeurs. Reprise du thème custom (~60 heures dev) pour adapter les Presenters et le multi-langues.
• Semaine 8 : bascule en production le mardi 12 du mois 3.
• Semaine 9 : suivi quotidien Search Console. Détection le J+4 d'une chute de 22% des impressions sur les fiches DE. Diagnostic en 4 heures : hreflang allemand mal repris sur 70 fiches après le passage Presenter. Correctif déployé J+5, retour à la normale J+12.
• Semaines 10 à 14 : monitoring stable.

Résultats à J+90 :

• Trafic organique : +14% par rapport au baseline pré-migration (effet performance Hummingbird 2.0 + reprise schema produit propre)
• Core Web Vitals mobile : 93/100 (vs 47/100 avant)
• Taux de conversion : +21% (effet performance + parcours panier refactorisé en V9)
• 0 perte sur les 30 mots-clés stratégiques

Coût total de la migration : 24 500 euros HT (audit + 2 étapes Autoupgrade + reprise thème + réécriture 1 module + monitoring 3 mois). Plus cher que la même migration vers PrestaShop 8 il y a 18 mois (18 500€) à cause de la double étape Autoupgrade et de l'incompatibilité Symfony 4.4 → 6.4. Sur ce dossier, le gain de trafic à J+90 a remboursé la prestation en 8 mois sur le seul canal organique.

À noter : si votre projet va plus loin qu'une simple migration de version, le sujet déborde alors sur notre page services sites web où on traite la création et la refonte complète.

Pour aller plus loin

• PrestaShop ou Shopify ? Comparatif honnête 2026 : avant ou après une migration, le bon moment pour valider votre choix de plateforme.
• Refonte PrestaShop : checklist anti-catastrophe SEO : la checklist 12 points qu'on applique sur chaque refonte (complémentaire à la migration de version).
• Mon site internet ne convertit pas : 7 erreurs : si vous voyez du trafic mais 0 commande, le problème n'est probablement pas la version PrestaShop.

Questions fréquentes

Combien de temps prend une migration PrestaShop 1.7 vers 9 ?

Une migration PrestaShop 1.7 vers 9 réaliste prend 8 à 10 semaines pour un e-commerce PME avec 500 à 3 000 produits, 10 à 20 modules et un thème custom. Site simple (moins de 200 produits, thème standard, peu de modules) : 5 à 6 semaines. Multi-langues, multi-boutiques ou modules sur-mesure : 10 à 14 semaines. Le saut Symfony 4.4 vers 6.4 et la double étape Autoupgrade (1.7 → 8 → 9) allongent de 2 à 3 semaines vs une migration vers PrestaShop 8.

Combien coûte une migration PrestaShop 1.7 vers 9 ?

Le coût d'une migration PrestaShop 1.7 vers 9 va de 6 500 euros HT pour un site simple (thème standard, peu de modules, monolingue) à 35 000 euros HT pour un e-commerce complexe (thème custom, modules sur-mesure, multi-langues). Le poste qui fait le plus varier le devis : la reprise du thème (60 à 80% du budget total) et le remplacement ou réécriture des modules incompatibles Symfony 6.4. Comptez 30 à 40% plus cher qu'une migration vers PrestaShop 8 à cause de la double étape Autoupgrade et de l'incompatibilité massive des modules tiers.

Peut-on faire la migration directement de 1.7 vers 9 sans passer par 8 ?

Le chemin officiel supporté par PrestaShop Autoupgrade est 1.7 → 8.x → 9.x, en deux étapes consécutives. Le saut direct 1.7 vers 9 n'est pas pris en charge par l'outil Autoupgrade. Alternative : partir d'un PrestaShop 9 vierge installé en propre et réimporter le catalogue via CSV. Cette deuxième approche est recommandée si la dette technique du 1.7 est lourde (thème ultra-personnalisé sur 5 ans, base de données polluée) ou si on profite de la migration pour remettre à plat la structure catalogue.

Faut-il refaire entièrement le thème pour passer en PrestaShop 9 ?

Pas entièrement, mais comptez 60 à 80% du code à reprendre. PrestaShop 9 utilise Symfony 6.4 (vs 3.4 dans la 1.7) et a introduit le pattern Presenter côté front office, modifiant les structures de variables Twig. Un thème custom de PrestaShop 1.7 ne fonctionnera pas tel quel. Soit on adapte (recommandé si vous avez beaucoup de personnalisations), soit on repart de Hummingbird 2.0 (thème officiel par défaut depuis PrestaShop 9.1, mars 2026, optimisé performance et accessibilité EAA).

Que faire si un module critique n'est pas compatible PrestaShop 9 ?

Trois options. Premièrement, vérifier auprès de l'éditeur sa roadmap : environ 50% des modules tiers ont publié leur version 9 ou la prévoient au printemps 2026. Deuxièmement, chercher un module alternatif équivalent compatible 9 : pour 90% des fonctions courantes, plusieurs modules existent. Troisièmement, faire développer un module sur-mesure en version 9 : compter 2 500 à 8 000 euros selon complexité (la réécriture pour Symfony 6.4, suppression Guzzle et Swift Mailer impliquent plus de travail qu'avant), souvent rentable si la fonction est critique pour votre activité.

Va-t-on perdre du référencement Google après la migration ?

Pas si la migration est bien menée. Sur les migrations qu'on a accompagnées avec audit pré-migration et plan de récupération, le trafic organique est stable à J+30 et souvent en hausse à J+90 (effet performance améliorée + Hummingbird 2.0). Sur les migrations sans audit SEO, on observe une perte moyenne de 25 à 45% du trafic organique dans les 3 mois (un peu plus que sur une migration 1.7 vers 8 à cause des Presenters et des breaking changes Symfony). L'écart se joue à 100% sur l'audit pré-migration et le monitoring post-migration.

Peut-on faire la migration soi-même sans agence ?

Techniquement oui si vous avez un développeur senior PHP/Symfony 6 à demeure (le saut Symfony 4.4 vers 6.4 implique de connaître la nouvelle architecture services, les nouveaux composants HTTP Client, Messenger, Mailer) et que votre catalogue est inférieur à 200 produits avec un thème standard. En pratique, sur les e-commerces PME qu'on accompagne, le coût caché du "faire soi-même" (temps interne perdu, bugs en production, pertes SEO) dépasse systématiquement le coût d'une prestation cadrée. Le calcul honnête : si votre CA mensuel dépend de plus de 30% du canal organique, ne migrez pas en interne.

Quand vaut-il mieux refondre complètement plutôt que migrer ?

Quatre cas où une refonte complète bat la migration : thème modifié sans cadre depuis 5 ans (dette technique lourde), structure catalogue qui ne correspond plus au business, design qui fait fuir les visiteurs (conversion sous 1%), changement de plateforme prévu à moyen terme. Dans ces 4 cas, une refonte complète sur PrestaShop 9 neuf (avec Hummingbird 2.0) revient 20% plus cher qu'une migration via 8 intermédiaire, mais résout aussi le problème de conversion en plus de la version. Et vous évitez la double dette technique 1.7 + thème à reprendre.

En résumé : migrer sans casser, c'est possible

Trois choses à retenir si vous préparez une migration PrestaShop 1.7 vers 9.

Un. La phase d'audit avant migration n'est pas optionnelle. C'est elle qui fait la différence entre une migration qui se passe bien et une migration qui vous coûte 30% de trafic organique pendant 6 mois. Inventaire modules, audit thème, snapshot SEO, cartographie URLs, validation du chemin Autoupgrade en deux étapes. 2 semaines de boulot, c'est ce qui sécurise tout le reste.

Deux. Le vrai risque n'est pas technique, il est SEO. PrestaShop 9 est plus rapide, plus sécurisé, plus moderne (Symfony 6.4 LTS, Hummingbird 2.0, kernels séparés). Mais si personne ne vérifie le schema produit, le hreflang et les redirections, le gain technique est mangé par la perte de positions.

Trois. Le monitoring post-migration sur 3 mois n'est pas un luxe, c'est une assurance. Search Console est gratuite, il faut juste savoir lire les bons signaux au bon moment.

Chez Agence BPC, on a accompagné 6 migrations PrestaShop en 2 ans. L'audit pré-migration est gratuit : 30 minutes au téléphone, on regarde votre contexte, on identifie les risques. Si le projet a du sens pour vous, vous recevez un plan PDF chiffré sous 48 heures : durée, budget, modules à reprendre, plan de récupération SEO, validation du chemin Autoupgrade. Vous gardez le plan même si vous ne signez pas avec nous.

Réserver mon audit migration (30 min).

Sans engagement · Plan PDF livré sous 48h · Réponse sous 24h ouvrées