Sommaire
Votre boutique PrestaShop 1.7 approche ou a déjà dépassé la limite du support officiel. La migration et refonte PrestaShop doit alors être préparée avec méthode, du choix de la version cible jusqu’à la stabilisation post-lancement. L’objectif est de préserver vos données, votre référencement et votre chiffre d’affaires.
Pourquoi lancer une refonte de PrestaShop 1.7
PrestaShop 1.7.8.11 est la dernière version publiée de la branche 1.7. Son support officiel a pris fin en 2024. Depuis, les failles de sécurité découvertes ne bénéficient plus de correctifs. Maintenir une boutique en ligne sur cette base en 2026 expose donc vos clients et votre activité à des risques croissants.
Les risques pour votre boutique
La première étape consiste à définir la bonne articulation entre ces deux projets. La refonte et la migration répondent à des besoins différents : la première modernise l’interface, la seconde change la version technique.
- Failles de sécurité non corrigées : sans mise à jour de sécurité officielle depuis 2024, toute nouvelle vulnérabilité reste ouverte sur votre site actuel.
- Incompatibilités PHP croissantes : les hébergeurs déploient couramment PHP 8.3, tandis que PrestaShop 1.7 présente des limites avec cette version. Des alertes techniques, des lenteurs et des erreurs peuvent alors apparaître.
- Modules critiques défaillants : Stripe, PayPal, Mondial Relay, Colissimo et Chronopost font évoluer leurs extensions en priorité pour les branches récentes. Un module non maintenu peut bloquer le tunnel de commande ou figer le panier sans avertissement visible.
- Performance dégradée : un score PageSpeed mobile inférieur à 50, un back-office qui met plus de cinq secondes à charger ou plus de vingt modules installés signalent une dette technique importante.
Ces problèmes n’apparaissent pas toujours en même temps. Ils peuvent toutefois se renforcer mutuellement. Un module ancien peut déclencher une erreur 500, casser le JavaScript du front-office ou provoquer des abandons de panier, sans cause immédiatement identifiable. Le coût d’un incident critique dépasse presque toujours celui d’une migration anticipée et correctement préparée.
Refonte ou migration du site
Ces deux démarches répondent à des besoins différents. Une refonte graphique seule actualise le thème, le design et l’ergonomie, tout en conservant la base de données et la branche de version existantes. Elle convient lorsque la plateforme reste techniquement saine et à jour. L’agence Webapic accompagne ce type de projet en travaillant l’expérience utilisateur, le SEO et les fonctionnalités marketing dans la refonte PrestaShop sur-mesure.
Une migration implique, quant à elle, un changement de version de PrestaShop, de serveur ou d’architecture technique. Depuis PrestaShop 1.7, elle devient nécessaire, car cette branche n’est plus maintenue. Les deux démarches peuvent être menées ensemble, ce qui est souvent pertinent : le chantier technique permet aussi de moderniser l’expérience utilisateur, d’exploiter les nouvelles fonctionnalités et d’améliorer la performance globale du site. L’Agence 123, certifiée PrestaShop, illustre cette approche pour la refonte de boutiques PrestaShop 1.7, notamment pour des marques comme Cornilleau et K-Way.
PrestaShop 8 ou 9 : quelle cible choisir ?
Le choix de la version cible détermine la compatibilité des modules, l’effort de développement, les prérequis serveur et les bénéfices attendus. Pour les marchands qui quittent PrestaShop 1.7, deux options se présentent : la version 8, stable et largement adoptée, ou la version 9, plus récente et techniquement plus ambitieuse.
Les atouts de PrestaShop 8
Un changement de version PrestaShop vers la branche 8 constitue souvent l’approche la plus maîtrisée depuis PrestaShop 1.7. La version 8.2, stable en production depuis 2022, s’appuie sur PHP 8.0 et 8.1 ainsi que sur Symfony 4.4 LTS.
Son écosystème de modules est mature. La compatibilité des modules de paiement, de transport et de marketing est généralement assurée sans refonte lourde. Les temps de chargement progressent, la compatibilité mobile est renforcée et la sécurité est améliorée par rapport à la branche 1.7.
Quand migrer vers PrestaShop 9
Réaliser une mise à jour majeure de PrestaShop vers la version 9 représente un investissement plus important. En contrepartie, cette cible apporte des perspectives techniques plus larges. Publiée officiellement en 2025, la version 9.1.3 repose sur Symfony 6 modernisé. Elle prend nativement en charge PHP 8.3 et introduit le thème Hummingbird, plus léger et plus performant. Les Core Web Vitals y sont sensiblement meilleurs que sur la branche 8, notamment sur les pages catégories et produits.
- Refonte complète du thème : si votre projet prévoit une refonte de site e-commerce intégrale, PrestaShop 9 avec Hummingbird constitue une base plus solide pour les prochaines années.
- Compatibilité avec PHP 8.3 : les boutiques hébergées sur une infrastructure récente peuvent tirer pleinement parti des performances de cette version de PHP.
- Back-office amélioré : la gestion quotidienne gagne en fluidité grâce à un cache optimisé et à une navigation plus réactive pour vos équipes.
- Modules à contrôler : certains modules PrestaShop 1.7 ou 8 doivent être adaptés ou remplacés pour fonctionner sur la version 9. Cette vérification peut allonger l’audit et le développement.
Si votre boutique dépend de nombreuses extensions tierces ou d’un thème fortement personnalisé, vérifiez leur compatibilité avant de migrer. Dans certains cas, commencer par PrestaShop 8 reste plus prudent.
Comparer les prérequis techniques
Avant de choisir la version cible, vous devez valider précisément votre infrastructure. Vous multiplieriez les sources d’erreur et rendriez le diagnostic plus difficile. PrestaShop 8 et 9 partagent plusieurs exigences, avec des différences selon la sous-version retenue. La documentation PrestaShop 8 indique que les versions 8.0 à 8.2 ne prennent pas en charge PHP 8.2 ou une version supérieure. Votre configuration doit donc correspondre exactement à la sous-version choisie.
Le tableau ci-dessous récapitule les principaux prérequis techniques de chaque cible :
| Critère | PrestaShop 8.2 | PrestaShop 9 |
| Version PHP | PHP 8.1 (recommandé) | PHP 8.1 ou 8.2 minimum, 8.3 natif |
| Base de données | MySQL 5.7+ ou MariaDB 10.2+ | MySQL 5.7+ ou MariaDB 10.3+ |
| Memory limit | 256 Mo minimum | 256 Mo minimum |
| Max execution time | 300 secondes minimum | 300 secondes minimum |
| Extensions PHP requises | intl, curl, zip, gd | intl, curl, zip, gd |
| Framework Symfony | Symfony 4.4 LTS | Symfony 6 |
| Core Web Vitals | Bons | Sensiblement meilleurs |
Préparer la migration PrestaShop sans risque
La migration PrestaShop sans audit préalable provoque des données corrompues, des modules défaillants ou un retour arrière difficile. Une erreur à ce stade peut entraîner des données corrompues, des modules défaillants ou un retour arrière difficile. Prévoyez deux à trois semaines pour auditer, nettoyer et sécuriser votre environnement.
Auditer les modules et les données
Avant de lancer un PrestaShop upgrade, vérifiez la compatibilité de votre parc de modules avec la version cible. La commande officielle update:check-modules distingue les modules compatibles, incompatibles et incertains. Les développements maison et les modules retirés du marketplace exigent toutefois une migration manuelle ou une analyse approfondie.
L’audit doit aussi recenser les hooks spécifiques, les overrides, les flux externes ainsi que les connecteurs ERP, CRM ou PIM qui structurent le fonctionnement quotidien de votre boutique.
- Inventaire des modules : listez chaque extension, vérifiez sa compatibilité avec la version cible et recherchez une alternative pour les modules abandonnés ou incompatibles.
- Analyse de la base de données : contrôlez les tables personnalisées, les doublons clients, les adresses incomplètes, les statuts de commandes incohérents et les anomalies laissées par d’anciens modules.
- Cartographie des URL et des paramètres métier : documentez les règles de livraison, les déclinaisons de produits, les promotions actives et les configurations fiscales avant toute intervention.
Réalisez une sauvegarde complète avant toute manipulation. Elle doit inclure les fichiers de la boutique, les thèmes, les modules, les images et les configurations, ainsi qu’une exportation intégrale de la base de données. Celle-ci doit couvrir les clients, les commandes, les paniers, les statuts et les paramètres métier.
Testez ensuite cette sauvegarde par une restauration dans un environnement isolé.
Sécuriser l’environnement de staging PrestaShop
Un environnement de staging dédié est indispensable. Hébergez le staging sur un sous-domaine protégé par mot de passe. Sa configuration doit se rapprocher au maximum de la future infrastructure de production. Activez également les logs applicatifs pour faciliter l’analyse des erreurs.
C’est dans cet environnement que vous conduirez le développement, la migration et les tests avant la bascule finale. La configuration technique doit correspondre aux prérequis de la version cible : version de PHP, extensions, paramètres MySQL ou MariaDB, memory_limit et max_execution_time.
Une différence entre le staging et la production provoque fréquemment des incidents lors du transfert. Validez donc l’infrastructure avant le début des travaux.
Sur le staging, migrez les données selon leur dépendance : catégories d’abord, puis produits avec leurs attributs et déclinaisons, ensuite clients et adresses, enfin commandes et historiques. Cette séquence limite les ruptures de liens relationnels dans la base de données. Après la migration, testez les modules par ordre de criticité : paiement, transport, puis connecteurs secondaires.
Choisir la méthode pour migrer
Trois approches sont possibles. Pour une boutique standard de moins de 500 produits, sans override ni développement spécifique, l’Update Assistant natif ou un outil de mise à niveau automatique peut suffire. Cette option suppose que les modules soient majoritairement compatibles et que le thème ne repose pas sur des personnalisations profondes. Elle est rapide, mais elle nécessite tout de même un audit préalable sérieux.
Pour une configuration intermédiaire, multiboutique, multilingue ou dotée d’un catalogue de taille moyenne, un module spécialisé comme Migration Pro peut convenir. Son coût indicatif est de l’ordre de 300 € HT. Il automatise le transfert des données entre instances PrestaShop et limite les erreurs de saisie. Vous devez néanmoins vérifier chaque module et tester le résultat sur l’environnement de staging. Cet outil facilite la migration, mais ne remplace pas la validation technique.
Pour une boutique comportant des développements spécifiques importants, une dette technique ancienne, de nombreux modules tiers ou des connecteurs critiques, la migration manuelle reste généralement la plus fiable. Elle consiste à déployer une nouvelle instance PrestaShop, puis à réintégrer progressivement les données et les fonctionnalités en contrôlant chaque étape.
Webapic recommande cette démarche pour les projets à fort enjeu, notamment dans le cadre de la migration de PrestaShop 1.7 vers 8 avec une refonte associée.
Réussir la mise en ligne de la boutique
Le travail réalisé sur le staging n’a de valeur que si la bascule en production est maîtrisée. La mise en ligne intervient alors que les données évoluent, que les clients passent des commandes et que les stocks changent. Préparez donc un plan précis, choisissez une fenêtre de maintenance adaptée et documentez un plan de rollback. Vous réduirez ainsi le risque d’incident visible pour vos clients.
Préserver le SEO pendant la migration
Une erreur lors de la montée de version PrestaShop, notamment dans la gestion des redirections, peut effacer des mois, voire des années, de travail de référencement. Aucune agence ne peut garantir l’absence totale de fluctuation de trafic. En revanche, un protocole bien appliqué limite généralement l’impact à quelques semaines de réajustement, sans perte de positionnement durable.
Avant la bascule, explorez le site actuel avec un outil comme Screaming Frog. Établissez ensuite un mapping complet entre chaque ancienne URL et sa nouvelle destination. Les produits, les catégories, les pages CMS, les images et les fichiers qui reçoivent du trafic ou des liens entrants doivent être inclus. Chaque URL à fort potentiel doit avoir une destination explicite.
- Redirections 301 : chaque URL modifiée doit pointer vers son équivalent direct au moyen d’une redirection permanente dans le fichier.htaccess ou via les fonctions SEO de la version cible. Évitez les chaînes intermédiaires.
- Vérification des statuts HTTP : testez chaque redirection avec un outil comme httpstatus.io. Une page supprimée sans équivalent pertinent doit répondre 404 ou 410, et non rester en erreur silencieuse.
- Balises et données structurées : après la bascule, contrôlez les balises title, les meta descriptions et les données structurées schema.org des fiches produits et des catégories.
- Sitemap et Search Console : régénérez immédiatement le sitemap XML et soumettez-le à Google Search Console. Surveillez ensuite les pages indexées, les erreurs HTTP et les journaux serveur.
Le suivi post-lancement doit durer au moins deux à quatre semaines. Surveillez les erreurs 404, le trafic organique, les temps de chargement et les Core Web Vitals dans Google Search Console. Un pic d’erreurs 404 non anticipé révèle souvent une lacune dans le mapping des redirections. Corrigez-la rapidement. Limitez ainsi l’impact sur le référencement.
Éviter les erreurs après PrestaShop
Dans les 48 premières heures suivant la mise en ligne, testez le tunnel d’achat complet sur ordinateur et mobile, avec tous les moyens de paiement actifs. Vérifiez les modules de paiement et d’expédition, ainsi que les connecteurs ERP ou CRM. Contrôlez aussi un échantillon de commandes, de clients et de produits migrés. Vous pourrez ainsi repérer d’éventuels doublons, des statuts incohérents ou des données manquantes.
La mise à jour de votre e-commerce sous PrestaShop ne s’achève pas avec la bascule DNS. La stabilisation constitue une phase à part entière. Mettez les équipes internes à jour sur les changements du back-office et ajustez les intégrations qui fonctionnent différemment sur la nouvelle version de PrestaShop.
La propagation DNS prend généralement une à deux heures après le changement de pointage. Pendant ce délai, certains utilisateurs peuvent encore accéder à l’ancienne boutique. Prévoyez la synchronisation des dernières commandes passées avant la bascule. Maintenez aussi le plan de rollback disponible et opérationnel jusqu’à la validation formelle de la nouvelle instance.
Avant de considérer la bascule comme terminée, validez chaque point de stabilisation. Pour approfondir la planification de la montée de version vers PrestaShop 9, Webapic propose un accompagnement structuré, de la sauvegarde au suivi post-lancement.
Estimer budget et calendrier
Une migration standard de PrestaShop 1.7 vers une version récente prend entre cinq et neuf semaines. Comptez une à deux semaines pour l’audit et la préparation, deux à quatre semaines pour le développement et la migration, puis une à deux semaines pour les tests sur staging, la mise en production et la stabilisation.
La durée dépend directement de la complexité de votre boutique : nombre de produits et de déclinaisons, présence d’une multiboutique ou d’un environnement multilingue, modules tiers, overrides et connecteurs ERP, CRM ou PIM.
Les budgets indicatifs incluent l’audit, l’adaptation ou la refonte du thème, les tests sur staging et la stabilisation post-migration. Ils se situent entre 5 000 et 15 000 € HT pour une boutique de moins de 500 produits, entre 15 000 et 20 000 € HT pour un catalogue de 500 à 5 000 produits, et au-delà de 30 000 € HT pour un environnement très spécifique ou relié à un système d’information complexe.
Ces fourchettes correspondent à un projet complet avec accompagnement. Migrer seul à l’aide d’un outil automatique réduit le coût initial, mais augmente le risque de corrections ultérieures, parfois bien plus coûteuses.
Foire aux questions
Pourquoi est-il urgent de migrer depuis PrestaShop 1.7 en 2026 ?
PrestaShop 1.7.8.11, dernière version de la branche 1.7, n’est plus supportée depuis 2024. Les failles découvertes depuis cette date ne font l’objet d’aucun correctif de sécurité. Les hébergeurs déploient également PHP 8.3, incompatible avec PrestaShop 1.7. Cette évolution peut entraîner des alertes et des ralentissements progressifs.
Les modules critiques, notamment ceux liés au paiement, à la livraison et à la fiscalité, sont désormais développés en priorité pour les branches récentes. Le tunnel de commande devient donc plus vulnérable. En 2026, maintenir un site PrestaShop 1.7 en production expose votre activité à un risque opérationnel et sécuritaire qui augmente chaque mois.
Quelle est la différence entre une refonte et une migration PrestaShop ?
Une refonte actualise le thème graphique d’une boutique : design, ergonomie et performance front-end. Elle conserve généralement la base de données et la branche de version. Cette solution convient lorsque la plateforme reste techniquement à jour.
Une migration implique un changement majeur de version, de serveur ou d’architecture. Depuis PrestaShop 1.7, elle est devenue nécessaire, car cette branche n’est plus maintenue. Les deux opérations peuvent toutefois être menées ensemble. Vous modernisez ainsi l’expérience utilisateur tout en sécurisant la base technique, une approche souvent plus rentable à long terme.
Quel budget prévoir pour une migration ou une refonte PrestaShop 1.7 ?
Le budget dépend de la taille et de la complexité de votre boutique. Pour un catalogue de moins de 500 produits, prévoyez entre 5 000 et 15 000 € HT. Entre 500 et 5 000 produits, la fourchette va de 15 000 à 20 000 € HT. Au-delà, ou pour un environnement connecté à un ERP, un CRM ou un PIM avec de nombreux overrides, le budget dépasse généralement 30 000 € HT.
Ces montants incluent l’audit, l’adaptation ou la refonte du thème, les tests sur staging et la stabilisation après migration pendant deux à quatre semaines. Le délai moyen d’un projet complet est de cinq à neuf semaines.
