Migrer vers PrestaShop 8 : méthode et points de vigilance

PrestaShop 1.6 ne reçoit plus aucun correctif de sécurité depuis 2021, et une bonne partie du parc encore en 1.7 tourne sur des versions mineures qui ne supportent plus PHP 8.1 ou 8.2. Résultat concret : votre hébergeur va finir par vous forcer la main en désactivant les vieilles versions de PHP, et ce jour-là, votre boutique plante sans préavis. Migrer vers PrestaShop 8 n’est plus un projet de confort, c’est une opération de maintenance qu’il faut planifier avant d’y être contraint dans l’urgence. Voici la méthode, les pièges classiques, et ce qui fait vraiment dérailler un budget de migration.

Pourquoi la migration n’est plus optionnelle

Trois échéances techniques se cumulent en 2026. PrestaShop 1.6 est en fin de vie depuis plusieurs années : aucun patch de sécurité, aucune compatibilité PHP récente, et des modules du marketplace qui ont cessé d’être maintenus pour cette branche. PrestaShop 1.7 tient encore debout, mais ses dernières versions mineures approchent elles aussi de leur fin de support. Enfin, PHP 7.4 est mort depuis fin 2022, et les hébergeurs mutualisés retirent progressivement cette version de leurs offres — ce qui coupe l’accès à l’admin ou casse le front sans avertissement.

PrestaShop 8 est bâti sur Symfony pour le back-office et supporte PHP 8.1+, ce qui règle ces trois problèmes d’un coup. Mais la migration touche à la fois le cœur applicatif, la structure de la base de données, le thème et l’ensemble des modules installés — ce n’est pas une mise à jour en un clic, même si l’assistant officiel le laisse penser.

Auditer l’existant avant de toucher au code

La première erreur, c’est de lancer une migration sans avoir cartographié ce qui tourne réellement sur le site. Un audit sérieux couvre :

• La liste complète des modules installés, actifs ou non, avec leur version et leur éditeur.
• Les overrides de classes core (souvent le point de rupture numéro un lors d’une montée de version majeure).
• Les hooks personnalisés injectés directement dans le thème ou via des modules maison.
• La taille et la propreté de la base de données (tables orphelines, logs jamais purgés, commandes de test).
• Le niveau de personnalisation du thème : thème du marketplace tel quel, thème modifié, ou développement 100% sur mesure.

Cet audit donne la vraie mesure du chantier. Une boutique avec un thème propre et peu de modules tiers peut basculer en quelques jours. Une boutique avec quinze modules abandonnés et des overrides accumulés depuis 2018 demande une refonte partielle, pas une migration au sens strict.

Module de migration officiel ou refonte contrôlée

PrestaShop propose un module de migration qui automatise le passage 1.6 → 1.7 → 8. Il fonctionne correctement sur des boutiques simples, avec un thème standard et peu de surcouches. Sur une boutique personnalisée, il a trois limites récurrentes : il ne migre pas le thème (qui reste en 1.6, donc incompatible), il ne garantit rien sur les modules tiers non officiellement supportés, et il ne nettoie pas la dette technique accumulée — il la transporte telle quelle vers la nouvelle version.

Pour une boutique avec un historique de plusieurs années, l’approche la plus fiable reste une migration accompagnée d’une reconstruction du thème en natif, sans page builder ni surcouche visuelle, et d’un audit module par module pour décider quoi garder, remplacer ou redévelopper. C’est plus de travail en amont, mais ça évite de découvrir six mois plus tard qu’un module de paiement critique n’a jamais été réellement compatible. Si votre projet sort du cadre d’une simple mise à jour, une agence prestashop spécialisée peut chiffrer les deux scénarios avant que vous ne vous engagiez.

Le thème : le vrai point de friction

C’est là que la majorité des migrations PrestaShop dérapent en temps et en budget. Le back-office de PrestaShop 8 repose sur Symfony, mais le front-office continue d’utiliser Smarty — la compatibilité n’est donc pas automatique dès qu’un thème a été personnalisé au-delà des réglages standards. Un thème acheté sur le marketplace et jamais modifié a de bonnes chances de disposer d’une version 8 fournie par son éditeur. Un thème modifié à la main, avec des templates .tpl réécrits ou des hooks ajoutés en dur, doit être audité fichier par fichier.

Dans les cas les plus lourds — thème construit sur un ancien framework front, dépendances jQuery obsolètes, CSS non responsive au sens Core Web Vitals — la reconstruction complète du thème en natif est souvent plus rapide et plus stable qu’un rafistolage progressif. C’est aussi l’occasion de régler au passage les problèmes de performance mobile qui traînent depuis des années, plutôt que de les transporter vers la nouvelle version.

Modules tiers : la case la plus chronophage

Sur une boutique de trois ou quatre ans d’ancienneté, il n’est pas rare de retrouver dix à vingt modules installés, dont la moitié n’a plus été mise à jour depuis la version 1.6. Chaque module doit passer par la même question : existe-t-il une version PrestaShop 8 maintenue par l’éditeur ? Si oui, à quel coût de licence ? Si non, la fonctionnalité doit-elle être redéveloppée en natif, ou peut-elle être purement et simplement supprimée parce qu’elle n’est plus utilisée ?

Les modules de paiement et de livraison méritent une attention particulière : ce sont eux qui, s’ils cassent, arrêtent net les commandes. Ne testez jamais un module de paiement en production le jour du go-live — les tests doivent se faire en environnement de recette, avec de vraies transactions en mode test, avant toute bascule.

PrestaShop reste-t-il le bon choix pour vous ?

Une migration majeure est aussi le bon moment pour se poser une question qu’on évite d’habitude : PrestaShop est-il toujours la plateforme adaptée à votre activité ? Si votre catalogue est petit et que vous cherchez avant tout de la simplicité opérationnelle, une creation boutique shopify peut réduire la charge de maintenance à long terme. Si vous êtes davantage attaché à l’écosystème WordPress ou à la flexibilité de contenu, passer par une agence woocommerce ou consulter un expert woocommerce paris mérite d’être mis sur la table avant de réinvestir dans PrestaShop. Ce n’est pas le cas de la majorité des boutiques — PrestaShop reste solide pour du catalogue moyen à volumineux avec des besoins de gestion multi-boutiques — mais la question doit être tranchée consciemment, pas par inertie. Dans tous les cas, le sujet de la conversion et du parcours d’achat reste transverse aux plateformes ; notre article sur le tunnel vente woocommerce conversions 2026 détaille des principes qui s’appliquent tout autant à un tunnel de commande PrestaShop.

SEO et redirections : ne pas perdre son classement en cours de route

Une migration mal préparée peut faire chuter un positionnement construit sur plusieurs années, souvent pour des raisons évitables : changement de structure d’URL, pertes de balises canonical, sitemap non régénéré, ou redirections 301 oubliées sur les anciennes URLs de fiches produit et de catégories. Avant la bascule, exportez la liste complète des URLs indexées (Search Console est la source la plus fiable), et vérifiez après migration que chacune répond en 200 ou redirige proprement en 301 vers son équivalent.

Vérifiez aussi les temps de chargement mobile après migration : un passage à PrestaShop 8 mal optimisé peut dégrader le PageSpeed si le thème n’a pas été retravaillé pour le nouveau moteur de rendu. Un score mobile sous 90 après une migration coûteuse serait un signal que l’intégration front n’a pas été soignée.

Tests, recette et mise en production

La bascule ne se joue jamais en direct sur le site en production. La méthode qui fonctionne :

1. Cloner la boutique en environnement de recette isolé, base de données comprise.
2. Exécuter la migration sur ce clone, pas sur le site live.
3. Tester le parcours d’achat complet : ajout panier, codes promo, tunnel de commande, chaque moyen de paiement actif, chaque transporteur.
4. Vérifier le back-office : gestion des commandes, export comptable, synchronisation avec un éventuel ERP ou logiciel de caisse.
5. Planifier la bascule finale à un horaire de faible trafic, avec une procédure de rollback documentée si un blocage critique apparaît.

Sauter l’étape de recette pour gagner quelques jours est le calcul le plus systématiquement perdant que l’on observe sur ce type de projet.

Budget et délai à prévoir

La fourchette varie énormément selon l’ampleur de la personnalisation existante : une migration simple sur thème standard se traite en quelques jours-homme, une refonte accompagnée d’une reconstruction de thème et d’un audit complet des modules s’étale sur plusieurs semaines. Les ordres de grandeur du marché pour un projet e-commerce complet, tous CMS confondus, sont détaillés dans notre comparatif combien coute site ecommerce 2026 tarifs comparatif — utile pour cadrer un budget avant de solliciter des devis. Pour un chiffrage précis sur votre cas, mieux vaut passer par un audit préalable qu’une estimation à l’aveugle : la variable qui fait le plus varier le prix, ce sont les modules à redévelopper, pas la migration du cœur PrestaShop en elle-même.

FAQ

Combien de temps dure une migration vers PrestaShop 8 ?

Pour une boutique avec un thème peu modifié et moins de dix modules à jour, comptez généralement entre une et deux semaines, tests inclus. Pour une boutique avec un thème très personnalisé et des modules abandonnés à redévelopper, le chantier s’étend souvent sur plusieurs semaines, l’essentiel du temps étant consacré à la reconstruction du thème et au remplacement des modules incompatibles plutôt qu’à la migration technique elle-même.

Faut-il redévelopper tous les modules tiers ?

Non, seulement ceux qui n’ont pas de version PrestaShop 8 maintenue par leur éditeur, ou dont la licence n’est plus renouvelable. L’audit préalable sert justement à trier : certains modules peuvent être mis à jour simplement, d’autres remplacés par une fonctionnalité native de PrestaShop 8 qui n’existait pas en 1.6, et une partie peut être purement supprimée si elle n’est plus utilisée.

Peut-on migrer sans perdre son référencement ?

Oui, à condition de traiter le SEO comme une étape du projet et non comme un effet secondaire. Cela suppose de conserver la structure d’URL autant que possible, de mettre en place des redirections 301 systématiques sur toute URL modifiée, de régénérer le sitemap XML, et de vérifier l’indexation dans Search Console dans les semaines qui suivent la bascule.

Si votre boutique PrestaShop tourne encore sur une version non maintenue ou sur PHP obsolète, mieux vaut cadrer le projet avant que l’hébergeur ne vous impose un délai serré. Notre page agence ecommerce paris détaille comment nous chiffrons ce type de migration après audit.