Toutes les ressources
Ressource Agence BPC

Checklist migration PrestaShop 1.7 vers 9 en 30 points

30 contrôles cochables organisés en 5 phases, conçus pour une migration de version PrestaShop 1.7 vers 9 sans perdre de trafic organique. Le chemin officiel passe par PrestaShop 8 intermédiaire (Autoupgrade ne supporte pas le saut direct 1.7 vers 9). Différent d'une refonte complète : on garde la structure, on sécurise le passage technique et SEO sur les deux étapes.

Imprimez la page, posez-la à côté de votre clavier, cochez au fur et à mesure. Si un point est ignoré ou survolé, c'est typiquement le moment où vous perdrez 25 à 45% de trafic organique dans les 3 mois qui suivent la bascule (un peu plus que sur une migration vers 8 à cause du saut Symfony 4.4 vers 6.4).

Phase 1 - Audit pré-migration (semaines 1-2)
  1. Inventorier les modules tiers installés : version actuelle, compatibilité PrestaShop 9 confirmée par l'éditeur, alternative disponible si non compatible. Sur 5 ans, comptez 15 à 25 modules, dont 5 à 10 à reprendre (Symfony 4.4 vers 6.4 a cassé Guzzle, Swift Mailer, Tactician Bundle, et 30+ hooks).
  2. Lister les surcharges du thème custom : overrides, hooks modifiés, templates Twig customisés, usage des Presenters. Cette liste donne le temps de reprise estimé (30 à 80 heures de dev front pour PrestaShop 9, vs 20 à 60 heures pour la 8).
  3. Extraire toutes les URLs indexées via Screaming Frog ET Google Search Console. Distinguer : fiches produit, catégories, pages CMS, pages auteur. Cette liste sert de base au plan de redirection 301.
  4. Snapshot SEO complet : positions sur 50 à 100 mots-clés stratégiques, captures Search Console (impressions, clics, CTR moyens des 12 derniers mois), liste des pages qui génèrent 80% du trafic.
  5. Backup complet en double : dump MySQL, tarball des fichiers, copie de la configuration serveur. Stocké sur 2 supports différents (pas sur le même serveur que la prod).
  6. Vérifier que l'hébergement supporte PHP 8.1 minimum (8.5 recommandé, non supporté ≥ 8.6), MySQL 5.7+ ou MariaDB 10.2+, et `memory_limit` 512M minimum. Node.js 20.x requis pour le build des assets PrestaShop 9. Si mutualisé bas de gamme : bascule sur VPS recommandée (60 à 120 €/mois, ROI immédiat en performance).
  7. Vérifier les modules de paiement actifs : Stripe, PayPal, virement, CB. Récupérer les versions confirmées compatibles PrestaShop 9 chez chaque éditeur (le saut Symfony 4.4 vers 6.4 a cassé pas mal d'intégrations basées sur Guzzle).
  8. Document chiffré de sortie d'audit : durée totale estimée (8 à 10 semaines pour un site PME), budget par poste, risques identifiés, plan de récupération SEO détaillé, validation du chemin Autoupgrade en deux étapes (1.7 → 8.x → 9.x).
Phase 2 - Préparation environnement (semaine 3)
  1. Provisionner l'environnement de staging sur un sous-domaine dédié (ex : staging.votresite.fr), avec mêmes spécifications serveur que la prod cible (PHP 8.1 minimum, MySQL 5.7+/MariaDB 10.2+, RAM, CPU, Node.js 20.x).
  2. Activer `noindex` strict sur le staging via robots.txt (`Disallow: /`) ET header `X-Robots-Tag: noindex`. Double protection contre l'indexation accidentelle.
  3. Cloner la base de données et les fichiers de la prod vers staging. Vérifier que les URLs sont bien réécrites pour pointer vers le sous-domaine staging (pas d'URL prod résiduelle).
  4. Configurer un système de versioning pour les modifications (Git sur les fichiers thème, sauvegarde régulière de la base). Toute modif doit pouvoir être annulée en quelques minutes.
  5. Préparer le plan de redirection 301 : ancien_url → nouvelle_url au format CSV. Pour chaque URL gardée à l'identique : tester que la nouvelle structure ne casse pas (trailing slash, casse).
  6. Documenter la procédure de rollback : si la bascule explose, comment revient-on à l'état initial en moins de 30 minutes ? DNS TTL abaissé à 300s 48h avant bascule.
Phase 3 - Double migration en staging (semaines 3-7)
  1. **Étape 1 : Autoupgrade 1.7 → 8.x** sur le staging. Si tout est propre : 4 à 8 heures. Tests fonctionnels complets après stabilisation : panier, paiement, recherche, filtres, multi-langues. Laisser tourner une semaine.
  2. **Étape 2 : Autoupgrade 8.x → 9.x** sur le même staging. C'est ici que les modules tiers cassent en masse (Symfony 4.4 vers 6.4). C'est normal et c'est pour ça qu'on est en staging. Comptez 50% des modules à reprendre ou remplacer après ce saut.
  3. Reprise du thème custom en PrestaShop 9. Symfony 6.4 a introduit les Presenters côté front office, modifié l'authentification back-office (100% Symfony Security), changé la structure des variables Twig. Comptez 60 à 80% du code thème à reprendre.
  4. Réinstaller les modules un par un, version PrestaShop 9 confirmée. Test fonctionnel à chaque étape : panier, paiement, recherche, filtres, multi-devises si applicable. Réécriture des modules qui utilisaient Guzzle (vers Symfony HTTP client) ou Swift Mailer (vers Symfony Mailer).
  5. Vérifier le balisage SEO dans Google Rich Results Test : schema Product, Offer, Breadcrumb sur 10 fiches au hasard. Comparer avec un crawl pré-migration. Le changement de Presenters a typiquement modifié les structures variables.
  6. Tester les meta titles et descriptions sur 20 pages clés (top trafic organique). Vérifier qu'elles n'ont pas été écrasées par les defaults PrestaShop 9 ou Hummingbird 2.0 (thème par défaut depuis 9.1).
  7. Tester chaque mode de paiement pour un panier complet : Stripe, PayPal, virement, CB. Du clic au mail de confirmation reçu. Vérifier que les modules de paiement utilisent bien Symfony HTTP client (pas Guzzle, retiré dans PrestaShop 9).
  8. Test multi-langues si applicable : hreflang correctement injecté sur chaque page traduite, URLs des versions traduites cohérentes, balisage `<link rel="alternate" hreflang=>` présent. Le système de Presenters peut avoir cassé certaines réécritures.
Phase 4 - Bascule en production (semaine 8)
  1. Choisir le créneau : mardi, mercredi ou jeudi matin. JAMAIS un vendredi. JAMAIS la veille d'un jour férié. Toute l'équipe disponible pendant 48h après.
  2. Bascule en suivant le plan horodaté : maintenance activée, déploiement code, bascule DNS, vérif redirections (échantillon 20 URLs), désactivation maintenance, soumission nouveau sitemap.
  3. Surveillance temps réel pendant les 4 heures qui suivent : Search Console (erreurs), GA4 (trafic en temps réel), logs serveur (codes 4xx/5xx anormaux). Tout pic d'erreur = diagnostic immédiat.
  4. Vérifier l'échantillon de redirections 301 : prendre 50 anciennes URLs au hasard, vérifier que chacune renvoie une 301 (pas 302, pas 307) en 1 saut vers la nouvelle URL. Si une seule rate, plan B.
HeureActionResponsable
8:30Activation maintenance + dernier backupDev
8:45Déploiement code PrestaShop 9 en prodDev
9:00Bascule DNS (TTL 300s)Hébergeur
9:30Vérif redirections (échantillon 20 URLs)SEO
9:45Désactivation maintenanceDev
10:00Re-vérif tracking GA4 + Ads + Schema produit (Presenters)Marketing
10:15Soumission nouveau sitemap dans Search ConsoleSEO
Phase 5 - Monitoring 90 jours
  1. J+1 à J+7 : Search Console quotidien. Pic de 404, « page d'erreur de redirection », « page exclue » = action immédiate. Logs Googlebot consultés tous les jours.
  2. J+30 : audit positions vs snapshot pré-migration. Chute > 15% sur les mots-clés stratégiques = diagnostic urgent (souvent schema cassé par les Presenters PrestaShop 9 ou hreflang mal repris). Audit Core Web Vitals à mi-parcours.
  3. J+60 : audit performance complet. Largest Contentful Paint < 2,5 s, Cumulative Layout Shift < 0,1, Interaction to Next Paint < 200 ms. Hummingbird 2.0 fournit de bonnes bases mais peut nécessiter du fine-tuning sur les fiches produit complexes.
  4. J+90 : bilan complet. Trafic organique, positions sur les 50 mots-clés stratégiques, leads, taux de conversion. Comparaison à 6 mois avec le baseline pré-migration. Présentation finale et clôture du dossier.
Règle d'or

Une migration 1.7 vers 9 réussie se voit à J+90 : trafic stable ou en hausse, positions intactes, Core Web Vitals améliorés par Hummingbird 2.0. Si vous êtes encore en chute à J+90, ce n'est plus un retard d'indexation : c'est un dégât structurel (souvent Presenter mal repris ou hreflang cassé) à corriger en urgence.