Migrer de PrestaShop 1.7 vers 8 : ce qu'il faut vraiment savoir

Sommaire

• Pourquoi migrer : PrestaShop 1.7 ne reçoit plus aucun correctif de sécurité depuis fin 2024. Rester dessus, c’est exposer votre boutique à des failles non corrigées et risquer une coupure forcée par votre hébergeur (incompatibilité PHP 8).
• Combien ça coûte : entre 1 000 € et 5 000 € avec un freelance pour une boutique standard (500–3 000 produits, 20–30 modules). Plus si intégrations ERP/CRM sur mesure.
• Combien de temps : comptez 3 à 9 semaines selon la complexité du travail : audit, migration, tests, corrections et mise en production.

---

PrestaShop 1.7 : pourquoi rester est devenu risqué

Fin de support officiel et failles de sécurité

PrestaShop 1.7.8.11 est la dernière version publiée de la branche 1.7. Elle date de mars 2024. Depuis, plus rien.

La branche 1.7 ne reçoit plus aucun correctif de sécurité. Chaque nouvelle faille découverte restera ouverte indéfiniment. Ce n’est pas théorique : les boutiques e-commerce sont des cibles prioritaires pour le vol de données de paiement.

Depuis mi-2025, PrestaShop affiche même un message « votre version n’est plus maintenue » directement dans le back-office de toutes les boutiques 1.7.x. Le signal est clair.

Et ce n’est pas tout. Les éditeurs de modules majeurs : Stripe, PayPal, Alma, Mondial Relay, Colissimo, Chronopost: mettent progressivement fin au support de leurs modules pour PS 1.7. Les modules de paiement certifiés PCI-DSS ne sont plus mis à jour sur cette branche, ce qui peut poser problème en cas de contrôle de conformité.

Incompatibilité PHP 8+ : ce que ça change concrètement

PrestaShop 1.7 tourne sur PHP 7.4 au maximum. PHP 7.4 est déclaré “End of Life” depuis décembre 2022. Ça fait plus de 3 ans que cette version ne reçoit plus de patchs de sécurité.

Le problème concret : les hébergeurs retirent progressivement les vieilles versions de PHP de leurs serveurs. Si votre hébergeur force la mise à jour vers PHP 8.x, votre boutique 1.7 affiche instantanément une erreur 500 ou une page blanche.

Pourquoi ? Les anciennes versions de Symfony utilisées par PrestaShop 1.7 ne sont pas compatibles avec les fonctions modernes de PHP 8.x. Des fonctions que PrestaShop 1.7 et ses modules utilisent couramment ont été supprimées dans PHP 8.x. Quand le site essaie d’appeler une fonction qui n’existe plus, le serveur s’arrête net.

En 2026, PHP 8.3 est la version recommandée par la majorité des hébergeurs. Rester sur PS 1.7, c’est courir après une incompatibilité inévitable.

---

PS 8 ou PS 9 : quelle version choisir en 2026 ?

PS 8 : stable, éprouvé, recommandé pour la majorité

PrestaShop 8 est sorti en octobre 2022. Depuis, il a été stabilisé et affiné jusqu’à la version 8.2.x. C’est la version la plus mature pour une boutique en production.

Son écosystème de modules est complet : la quasi-totalité des modules majeurs (paiement, logistique, marketing) proposent une version compatible PS 8. La migration depuis PS 1.7 vers PS 8 est bien documentée et les développeurs PrestaShop expérimentés maîtrisent ce chemin.

PS 8 supporte PHP 8.1 nativement, ce qui représente un gain de performance de 15 à 30 % sur le temps de traitement des requêtes par rapport à PHP 7.4.

Mon avis tranché : pour une boutique standard en 2026 : catalogue de quelques centaines à quelques milliers de produits, modules courants, thème personnalisé : PS 8 est le bon choix. Pragmatique, sécurisé, sans surprise.

PS 9 : pour qui c’est pertinent ?

PrestaShop 9 est sorti officiellement le 6 juin 2025. C’est une refonte technique profonde : Symfony 6.4 LTS, PHP 8.1 minimum (jusqu’à 8.4), nouvelle API REST, thème Hummingbird 2.0.

Les performances Core Web Vitals sont sensiblement meilleures qu’en PS 8. L’architecture est plus moderne. Mais l’écosystème de modules est encore en cours de consolidation.

PS 9 est pertinent si :

• Vous lancez un nouveau projet from scratch
• Vous profitez de la migration pour refondre entièrement le design et l’architecture
• Vous avez des besoins d’intégration modernes (API REST, ERP, CRM)
• Votre équipe technique est disponible pour gérer les éventuels ajustements de modules

PS 9 est prématuré si :

• Vous avez de nombreux modules spécifiques ou sur mesure
• Votre priorité est la rapidité et la sécurité, pas la modernisation
• Votre budget est contraint

Mon avis : en 2026, je déconseille PS 9 à la majorité de mes clients PME, même si ses bases techniques sont meilleures. Sur une boutique existante, le vrai sujet n’est pas seulement le core PrestaShop : c’est la compatibilité des modules, du thème, des intégrations et du budget de stabilisation. Pour une PME qui veut sécuriser sans multiplier les inconnues, PS 8 reste généralement le choix le plus pragmatique.

Ma recommandation terrain pour 2026 : si vous êtes encore sur PS 1.7, passez d’abord en PS 8 pour stabiliser et sécuriser. La transition PS 8 → PS 9 sera plus naturelle dans 12 à 18 mois, quand l’écosystème sera encore plus mature.

---

Les 3 méthodes de migration (et celle que je recommande)

1-Click Upgrade : rapide mais risqué

Le module Update Assistant (anciennement “1-Click Upgrade”, nom technique : autoupgrade) est l’outil officiel de PrestaShop, disponible gratuitement sur GitHub. Il automatise une grande partie du processus.

Ce qu’il fait : il télécharge la nouvelle version, sauvegarde votre boutique, met à jour les fichiers et la base de données. Il vérifie même la compatibilité des modules installés avec la version cible avant de démarrer.

Le problème : sur une boutique personnalisée avec des modules tiers, des overrides PHP et un thème sur mesure, ce module peut échouer à mi-parcours. Le nombre d’erreurs et de plantages est significatif dès que la boutique s’éloigne d’une installation standard.

À utiliser si : votre boutique est peu personnalisée, peu de modules tiers, pas d’overrides complexes. Toujours sur un environnement de pré-production, aussi appelé staging, d’abord : c’est une copie de test de votre boutique, séparée du site visible par vos clients. Jamais directement en production.

Migration manuelle : la méthode sûre

La première chose que je fais avant toute migration : un audit complet des modules tiers: c’est là que 80 % des problèmes se cachent.

Sur le terrain, il y a deux cas de figure.

Si la boutique fonctionne bien et qu’elle repose sur plusieurs modules tiers importants, je privilégie souvent un clone du site existant. L’objectif est de partir de la réalité de la boutique, avec son thème, ses modules, ses commandes et ses particularités, puis de tenter la montée de version sur cette copie de pré-production. Cela permet d’identifier précisément ce qui casse, sans toucher au site en ligne.

Si la boutique a déjà des problèmes techniques, peu de modules tiers critiques ou un historique de personnalisation mal maîtrisé, repartir sur une installation PrestaShop 8 propre peut être plus sain. Dans ce cas, la migration consiste à :

1. Installer une instance PS 8 propre sur un environnement de pré-production
2. Migrer la base de données et les fichiers utiles manuellement
3. Réinstaller et reconfigurer chaque module tiers compatible PS 8
4. Mettre à jour, adapter ou remplacer le thème selon sa compatibilité
5. Tester exhaustivement avant bascule en production

C’est la méthode que je recommande pour toute boutique avec des personnalisations, des modules critiques ou un historique de commandes important. Elle prend plus de temps mais elle ne laisse pas de place aux mauvaises surprises.

Attention : cette méthode est réservée aux développeurs qui maîtrisent parfaitement l’architecture PrestaShop. Une erreur dans les fichiers remplacés peut rendre la boutique inaccessible.

Migration Pro module : le compromis

Des modules tiers comme MigrationPro ou PS Migrator proposent une approche intermédiaire : ils migrent les données (produits, clients, commandes) d’une instance PS 1.7 vers une instance PS 8 fraîche, via une connexion entre les deux boutiques.

Avantages : plus fiable que le 1-Click Upgrade sur les données, moins technique que la migration manuelle complète.

Limites : le thème et les modules doivent quand même être gérés séparément. Ce n’est pas une solution clé en main.

---

Budget et délais : ce qu’il faut anticiper

Fourchettes de prix selon la complexité de la boutique

Profil de boutique	Budget freelance	Budget agence
Simple (< 500 produits, modules standards)	1 000 – 2 500 €	3 000 – 6 000 €
Standard (500–3 000 produits, 20–30 modules)	2 500 – 5 000 €	5 000 – 15 000 €
Complexe (ERP, modules sur mesure, multi-boutiques)	5 000 – 15 000 €	15 000 – 50 000 €

À ces montants s’ajoutent les licences de modules mis à jour : comptez entre 500 € et 3 000 € selon le nombre et la criticité des modules à renouveler.

Certains modules très anciens ou édités par des développeurs disparus ne seront jamais compatibles PS 8 : il faudra trouver un équivalent ou développer un remplacement sur mesure.

Durée réaliste d’une migration

3 à 9 semaines pour une boutique standard bien documentée. Pas parce que la migration elle-même prend tout ce temps : mais parce que l’audit, l’attente de compatibilité de certains modules, les tests et les corrections prennent du temps.

Pour un site complexe avec des modules sur mesure ou des intégrations ERP/CRM : 3 à 6 mois.

La durée est souvent allongée par les validations client et la disponibilité des ressources techniques. Anticipez.

---

Les 5 risques à ne pas négliger

1. Modules incompatibles

C’est le risque numéro 1. Il faut lister les modules tiers actifs et vérifier leur compatibilité avec PS 8 sur la marketplace officielle ou auprès des éditeurs. Si vous savez le faire, vous pouvez préparer cette liste de votre côté ; sinon, c’est typiquement un audit que je peux réaliser à votre place. Un module de paiement ou de gestion de stock incompatible peut bloquer votre migration pendant plusieurs semaines.

2. SEO et redirections

Une migration mal préparée peut détruire des années de travail SEO en quelques heures. Le point de vigilance est simple : il faut s’assurer que la structure des URLs existantes sera bien conservée après migration. Si certaines URLs changent malgré tout, les redirections 301 doivent être préparées avant le passage en production. Certains sites ont vu leur trafic chuter de 30 à 60 % pendant plusieurs mois après une migration bâclée.

3. Thème incompatible

Votre thème PrestaShop 1.7 doit être audité avant migration. Beaucoup de thèmes ont une version compatible PS 8 qu’il suffit de mettre à jour proprement. Si aucune version compatible n’existe, il faudra soit l’adapter, soit adopter un nouveau thème compatible. Cette décision a un impact majeur sur le budget global.

4. Intégrité des données

Commandes, clients, historique : tout doit être vérifié après migration. Testez la restauration de votre sauvegarde au moins une fois avant de démarrer. Une sauvegarde non testée n’est pas une sauvegarde.

5. Intégrations ERP/CRM

Si votre boutique est connectée à un ERP, un CRM ou un WMS via des modules ou des web services, ces intégrations doivent être auditées et testées séparément. PrestaShop 9 remplace les anciens web services XML par une API REST moderne : si vous visez PS 9, c’est un chantier à part entière.

---

Checklist avant / après migration

Avant : 8 points à valider

• Sauvegarde complète : fichiers + base de données, stockée sur un serveur externe
• Audit de tous les modules : compatibilité PS 8 vérifiée sur la marketplace ou auprès des éditeurs
• Audit du thème : compatibilité ou plan de refonte défini
• Environnement de pré-production : clone du site actuel ou instance PS 8 installée sur un sous-domaine de test
• Version PHP vérifiée : hébergeur compatible PHP 8.1+ confirmé
• Crawl SEO : export de toutes les URLs actuelles (avec Screaming Frog ou Sitebulb)
• Inventaire des overrides PHP : liste de toutes les personnalisations du core
• Plan de rollback : procédure de retour arrière documentée si la migration échoue

Après : 6 points à vérifier

• Tunnel de commande complet : de l’ajout au panier jusqu’à la confirmation de commande
• Modules de paiement opérationnels : test en mode sandbox + vrai paiement test
• Emails transactionnels : confirmation de commande, expédition, mot de passe
• Redirections 301 : vérification que les anciennes URLs redirigent correctement
• Google Search Console : soumission du nouveau sitemap, surveillance des erreurs d’exploration
• Performances : test Lighthouse / GTmetrix : les scores doivent être au moins équivalents à l’avant

---

Pourquoi confier sa migration à un freelance PrestaShop ?

Migrer une boutique PrestaShop, c’est un projet technique à part entière. Ce n’est pas un simple clic. La question n’est pas si vous avez besoin d’aide, mais à qui vous faites confiance pour le faire.

Freelance vs agence : les vraies différences

Un freelance spécialisé PrestaShop, c’est un interlocuteur unique du début à la fin. Pas de transfert de dossier entre un commercial, un chef de projet et un développeur junior. Vous parlez directement à la personne qui fait le travail.

La réactivité est aussi un avantage concret : si un problème apparaît en production un vendredi soir, vous avez quelqu’un à appeler : pas un ticket de support qui sera traité lundi matin.

Sur le tarif, un freelance expérimenté facture généralement entre 400 € et 700 € par jour. Une agence spécialisée, c’est souvent le double, avec des frais de structure intégrés. Pour une migration standard, la différence peut représenter plusieurs milliers d’euros.

Ce que vous devez vérifier avant de confier votre migration à un freelance :

• Des références de migrations PrestaShop récentes (PS 1.7 → PS 8 ou PS 9)
• Une méthode de travail avec pré-production obligatoire avant production
• Un engagement sur les redirections SEO et les tests post-migration
• Une disponibilité pour le suivi dans les semaines qui suivent la mise en ligne

---

Mon avis d’expert

Quel est le module tiers qui t’a posé le plus de problèmes lors d’une migration 1.7 → 8 ?

Les modules qui posent le plus de problèmes sont souvent les connecteurs ERP ou les modules métier développés sur mesure. Ils peuvent fonctionner correctement en façade, mais dépendre d’anciennes méthodes PrestaShop, d’overrides ou de tâches cron mal documentées.

Comment tu gères le risque SEO le jour J de la bascule en production ?

Je prépare un crawl complet avant migration, puis je relance un crawl juste après la bascule pour contrôler les statuts HTTP, les redirections, les balises canoniques et les pages stratégiques. Le point clé est d’avoir les redirections 301 prêtes avant la mise en ligne, pas après les premières erreurs Search Console.

Quelle est la première chose que tu vérifies quand un client te dit que sa boutique 1.7 ‘fonctionne bien’ ?

Je vérifie d’abord la version PHP, les modules critiques et les logs serveur. Une boutique peut sembler fonctionner côté client tout en accumulant des warnings, des erreurs de paiement ou des incompatibilités silencieuses qui deviendront bloquantes au moment de migrer.

---

FAQ