En 2026, une part significative des boutiques PrestaShop tourne encore sous version 1.7 — sortie en 2016, déclarée en fin de support officiel par PrestaShop SA en 2024, et désormais sans correctifs de sécurité depuis fin 2025. Ces boutiques accumulent les risques : incompatibilités PHP récents, modules 1.7 abandonnés, vulnérabilités non patchées, performance plombée par des hooks legacy, et impossibilité d’utiliser le catalogue moderne PS8 (cross-sell intelligent, FAQ IA, AEO, multi-pays propre).
La migration vers PrestaShop 8 n’est plus une option en 2026 — c’est une obligation à terme. Mais c’est un projet à part entière, pas un clic dans le back-office. Cet article détaille la checklist complète de migration 1.7 → 8 : l’audit préalable, les modules à remplacer, la gestion des données, la critique du SEO et des redirections, et l’opportunité de moderniser le stack technique au passage.
Pourquoi migrer en 2026 (et pourquoi attendre devient risqué)
Trois forces convergent en 2026 pour rendre la migration 1.7 → 8 inévitable.
Fin du support sécurité. PrestaShop SA n’émet plus de correctifs de sécurité pour la branche 1.7 depuis fin 2025. Toute faille découverte après cette date reste exploitable, et la quantité de boutiques 1.7 encore en ligne en fait une cible privilégiée pour les attaquants. Sur les audits récents, plusieurs boutiques 1.7 ont été compromises via des modules tiers vulnérables qui ne sont plus maintenus — admin défacé, tunnel de paiement détourné, données clients exfiltrées.
Incompatibilité PHP. PrestaShop 1.7 ne supporte officiellement que PHP 7.4 et certaines versions de PHP 8.0. Or PHP 7.4 est en fin de vie depuis novembre 2022, et la majorité des hébergeurs ont retiré ou retirent PHP 7.4 de leurs offres. Les boutiques 1.7 forcées de tourner en PHP 8.1 ou 8.2 expérimentent des bugs aléatoires (warnings, deprecated, casts implicites cassés) qui dégradent le fonctionnement.
Catalogue moderne PS8 inaccessible. Tous les modules e-commerce 2026 modernes (FAQ IA, AEO via llms.txt, cross-sell pondéré avec analytics, marquage Schema.org étendu, multi-pays propre avec hreflang automatique) sont développés pour PrestaShop 8. Les versions 1.7 de ces modules, quand elles existent, sont des portages dégradés — fonctions limitées, performance moindre, support arrêté.
L’arbitrage économique est simple : le coût d’une migration sérieuse en 2026 (typiquement 5 000 à 25 000 € selon la taille de la boutique et la complexité) est inférieur au coût cumulé de rester sur 1.7 — failles de sécurité, perte de modules modernes, dégradation de performance, perte de clients à cause de bugs PHP.
L’audit préalable : ce qu’il faut savoir avant de migrer
Avant tout devis ou planning de migration, un audit complet de votre boutique 1.7 actuelle. Sans cet audit, vous découvrez les complications en cours de projet et le budget explose.
Inventaire des modules installés. Listez tous les modules activés sur la boutique. Pour chacun : la version, le statut (actif / désactivé / orphelin), l’auteur, la date de dernière mise à jour, et la disponibilité d’une version PrestaShop 8. Sur les boutiques 1.7 mature, on trouve typiquement 30 à 80 modules dont 20 à 40 % sont en réalité abandonnés ou orphelins — désactivés depuis longtemps, sans usage actif. Ceux-là disparaissent automatiquement à la migration.
Inventaire des modifications custom. Override de classes core dans override/classes/, override de controllers, modifications de templates Smarty, mods directs dans le code core (pratique anti-pattern fréquente sur les boutiques 1.7 anciennes). Toutes ces modifications sont à recenser et à documenter — elles ne survivront pas à la migration sans intervention manuelle.
Audit du thème. Si vous utilisez un thème custom (et non un thème classic-rocket ou Hummingbird natif), vérifiez sa compatibilité PS8. Beaucoup de thèmes 1.7 commerciaux ne sont jamais portés sur PS8 — votre choix est alors entre acheter une nouvelle licence PS8 du même thème (si disponible), choisir un nouveau thème PS8, ou faire porter le thème custom par un développeur (cher).
Audit des données. Volumétrie des produits, des commandes, des clients, des avis. Une migration de boutique avec 500 produits et 5 000 commandes prend quelques jours de travail. Une migration de boutique avec 50 000 produits et 500 000 commandes prend plusieurs semaines avec coordination logistique (gel de la prod, fenêtre de bascule).
Audit SEO. Top 100 des pages avec trafic organique, top 100 des pages avec backlinks, structure des URL actuelles. Cette donnée est critique pour planifier les redirections 301 (sujet d’une section dédiée plus bas).
Les modules 1.7 cassés à remplacer
Sur les migrations que nous avons accompagnées, voici les catégories de modules qui posent systématiquement problème.
Modules de cross-sell 1.7. Les modules de produits associés en version 1.7 (pscrosssellsproducts, blockcategories enrichi, certains modules tiers) ne marchent pas en PS8 et leurs équivalents PS8 sont souvent rebrandés. Profitez de la migration pour passer à un cross-sell moderne avec analytics et stratégies pondérées — sujet traité dans notre article sur les 7 stratégies de cross-sell 2026. Module recommandé : DataFirefly Cross-Sell.
Modules d’avis 1.7. Les modules d’avis natifs PS 1.7 (productcomments) et les modules tiers anciens ne génèrent pas de marquage Schema.org AggregateRating + Review propre — donc pas d’étoiles dans la SERP, pas de citation dans les Answer Engines (sujet AEO traité dans notre article dédié). À remplacer par un module moderne comme DataFirefly Avis Vérifiés qui couvre le marquage complet.
Modules de FAQ produit 1.7. La majorité des modules FAQ 1.7 sont du Smarty hardcodé sans gestion IA ni Schema.org propre. Le passage à PS8 est l’occasion de basculer sur un module FAQ avec génération IA en masse comme DataFirefly FAQ IA Produit — gain de temps massif sur la rédaction et marquage Schema.org valide.
Modules de wishlist 1.7. Les wishlist 1.7 sont généralement basiques (ajouter / supprimer / lister) sans capture d’email anonyme, sans alerte prix, sans analytics. À remplacer par DataFirefly Wishlist Avancée — sujet traité dans notre article sur la wishlist comme levier de conversion.
Modules de panier latéral / sidecart 1.7. Souvent absents en 1.7 (le panier était une page dédiée, sans sidecart). À ajouter en PS8 avec DataFirefly SideCart qui modernise l’expérience post-add-to-cart.
Modules SEO multi-pays 1.7. Les modules hreflang 1.7 sont souvent partiels et ne gèrent pas la réciprocité ou les codes ISO correctement. À remplacer par module Hreflang DataFirefly + Sélecteur de Pays.
Modules paiement 1.7. Les anciens modules de paiement 1.7 sont souvent incompatibles avec les exigences SCA / 3DS2 modernes, ou non conformes PSD2. La majorité des banques et processeurs (Stripe, Mollie, Adyen, BNP, Société Générale, Crédit Mutuel via Mercanet) ont des modules PS8 modernes à activer en remplacement. À tester rigoureusement avant bascule en prod — un paiement cassé en prod, c’est du CA perdu.
Modules de tracking analytics 1.7. Les modules GA Universal ou GTM legacy 1.7 ne supportent pas le Consent Mode v2 (obligatoire en 2026 pour Google Ads / GA4). À remplacer par Google Tag Pro ou similaire qui gère Consent Mode v2 nativement, plus Cookie Manager Tarteaucitron pour la CMP.
La gestion des données : import / export propre
La migration des données est techniquement la partie la plus risquée. PrestaShop ne fournit pas de migrateur natif 1.7 → 8 fiable — l’outil Module Migration Manager qui existe a des limitations connues sur les catalogues complexes.
L’approche éprouvée :
Étape 1 — Export propre depuis 1.7. Export CSV / XML des produits, catégories, clients, commandes, avis, descripteurs (caractéristiques, attributs). Conserver les ID originaux pour pouvoir mapper les redirections SEO ensuite.
Étape 2 — Installation PS8 propre. Sur un environnement dédié (staging), installer PS8 from scratch avec un thème compatible et les modules de base. Ne pas réinstaller les modules 1.7 — installer les versions PS8 modernes équivalentes.
Étape 3 — Import structuré. Import dans l’ordre : catégories → caractéristiques → produits → images produit → clients → adresses → commandes → avis. L’ordre compte parce que certaines tables référencent d’autres (un produit référence une catégorie qui doit déjà exister).
Étape 4 — Vérification de cohérence. Compter le nombre de lignes par table après import, comparer aux comptes de la 1.7 d’origine. Tester quelques fiches produit, quelques catégories, quelques commandes pour vérifier que tout est cohérent visuellement.
Étape 5 — Tests fonctionnels. Parcours complet sur staging : navigation, ajout panier, checkout, paiement (en mode test), confirmation. Tester aussi les fonctionnalités admin (gestion commandes, gestion produits, gestion clients).
SEO et redirections 301 : la partie qu’on rate le plus souvent
Les URL changent entre PS 1.7 et PS 8, parfois subtilement (structure de slug, gestion des paramètres, ajout du multilingue). Sans plan de redirection 301 systématique, vous perdez toute votre autorité SEO accumulée.
Les types d’URL à mapper :
- URL produit : ancien format
/category/123-slug-produit.htmlvs nouveau format/category/produit-456(ou inverse selon votre config). Mapper produit par produit. - URL catégorie : peuvent changer si la hiérarchie ou les slugs ont été ajustés.
- URL CMS / pages statiques : à mapper individuellement.
- URL fournisseurs / marques : si vous les utilisiez en 1.7.
- URL paramétrées avec filtres : à mapper vers les nouvelles URL faceted search PS8.
Implémentation pratique : un fichier de redirections 301 dans .htaccess ou nginx config, ou un module de redirections PS8 (plusieurs existent au marketplace) qui les gère depuis la base de données. Pour les très gros catalogues (10 000+ produits), automatiser le mapping via script qui lit l’ancien sitemap et génère les redirections vers les nouvelles URL en se basant sur les slugs ou les SKUs.
Et critique : surveiller Search Console pendant 4-8 semaines après la bascule pour détecter les erreurs 404. Chaque 404 révèle une URL ancienne qui n’a pas été redirigée — à ajouter au fichier de redirections au fur et à mesure.
La checklist de migration en 12 étapes
- Audit complet de la boutique 1.7 actuelle (modules, thème, custom code, données, SEO).
- Choix du thème PS8 (réplique du thème actuel ou nouveau choix).
- Choix des modules PS8 de remplacement, avec audit des modules à abandonner.
- Provisioning environnement PS8 (hébergement, PHP 8.2+, MySQL 8 / MariaDB 11, certificats SSL).
- Installation PS8 propre et configuration de base (langues, devises, multilingue, pays).
- Installation des modules PS8 sélectionnés et configuration.
- Import des données depuis l’export 1.7 (catégories, produits, clients, commandes).
- Production des redirections 301 mappant ancien URL → nouveau URL.
- Tests fonctionnels exhaustifs sur staging (navigation, checkout, admin).
- Bascule en production (DNS, certificats, fichier
.htaccessou nginx config avec redirections). - Surveillance post-bascule Search Console, GA4, logs serveur, retours clients.
- Itération corrective sur les bugs détectés en prod (compter 2-4 semaines de polish post-bascule).
Sur les migrations que nous avons accompagnées, le projet complet dure entre 4 et 12 semaines selon la taille de la boutique et la complexité des customisations.
L’opportunité de moderniser le stack au passage
Une migration 1.7 → 8 n’est pas seulement un upgrade technique, c’est aussi l’opportunité de moderniser le stack e-commerce qu’on a accumulé pendant des années sans nettoyage.
Sécurité admin. Profitez de la migration pour activer la 2FA admin via 2FA Google Authenticator pour PrestaShop. C’est une protection essentielle en 2026 que beaucoup de boutiques 1.7 négligent.
Stack AEO. Profitez de la migration pour aligner votre boutique sur les standards AEO 2026 (sujet traité dans notre catégorie AEO). Le combo LLMs.txt PrestaShop + FAQ IA + Avis Vérifiés positionne votre boutique pour le trafic ChatGPT / Perplexity / Google AI Overviews.
Recurring revenue via abonnements. Si votre catalogue le permet (consommables, box, services digitaux), profitez de PS8 pour ajouter le module DataFirefly Subscriptions avec Stripe — sujet traité dans notre guide tunnel d’abonnement. Le récurrent sur PrestaShop 1.7 était particulièrement bricolé ; sur PS8 c’est mature.
Stack de conversion moderne. Au-delà des remplacements modules cassés, profitez de la migration pour ajouter les leviers que vous n’aviez pas en 1.7 : barre de livraison gratuite avec barre de progression, sidecart, wishlist avec alertes, vidéos produit avec CWV propres. Une migration sans modernisation, c’est une refonte technique sans gain business.
Erreurs fréquentes en migration 1.7 → 8
Croire que la migration prend 2 jours. Sur les devis low-cost qui promettent une migration en 2 jours, vous récupérez systématiquement une boutique cassée. Le minimum réaliste est 2-3 semaines pour une boutique simple, plus pour les complexes.
Négliger les redirections 301. La perte de trafic SEO post-migration est typiquement de 30-60 % sans plan de redirection complet. Avec plan, on récupère 90-100 % en 4-8 semaines.
Garder tous les modules 1.7. La migration est l’occasion d’élaguer. Les boutiques qui essaient de tout porter à l’identique se retrouvent avec un PS8 alourdi par 50 modules dont la moitié sont legacy.
Faire la migration en prod direct. Sans staging, sans tests, sans rollback plan. C’est la garantie d’un drama. Toute migration sérieuse passe par staging avec validation exhaustive.
Sous-estimer la formation utilisateurs. L’admin PS8 est différent de PS 1.7 — workflows changés, écrans réorganisés, certaines fonctions déplacées. Les équipes opérationnelles (gestion commandes, support client) doivent être formées avant la bascule, pas découvrir l’admin nouveau le matin du go-live.
Conclusion : un projet structurant qui modernise votre business e-commerce
La migration PrestaShop 1.7 → 8 n’est pas une simple update technique — c’est un projet qui mérite un sponsoring direction, un budget calibré, et un planning rigoureux. Les boutiques qui prennent le sujet au sérieux sortent de la migration avec une boutique moderne, sécurisée, performante, et alignée sur les standards e-commerce 2026. Les boutiques qui le bâclent y perdent du trafic SEO, du chiffre d’affaires pendant des semaines, et accumulent une dette technique qu’il faudra payer plus tard.
L’investissement type pour une migration sérieuse est de 5 000 à 25 000 € selon la taille (PME : 8-15 K€, e-commerce mature : 15-25 K€), plus le coût des nouveaux modules de remplacement (généralement 500-2 000 € selon le stack choisi). Le retour sur investissement est mesurable en 6-12 mois post-migration via la modernisation des leviers de conversion et la libération du potentiel SEO bloqué par les limitations 1.7.
Pour creuser les sujets connexes, parcourez nos catégories Performance & Core Web Vitals et Tutoriels PrestaShop. Et pour assembler le stack moderne PrestaShop 8 post-migration (cross-sell, avis vérifiés, FAQ IA, sidecart, wishlist, free shipping, multi-pays, AEO), l’ensemble du catalogue DataFirefly est aligné sur les patterns 2026 — performance-first, code propre, support francophone, mises à jour régulières.