Mise à jour PrestaShop : procédure de migration manuelle 1.6/1.7 vers 8.x

Table des matières :

Stratégie de migration : mise à jour en chaîne vs réinstallation

Sur PrestaShop, « migrer de 1.6/1.7 vers 8.x » recouvre deux réalités. La mise à jour en place (in-place upgrade) consiste à conserver le même jeu de données et à faire évoluer le cœur, les modules et le thème, version après version. La réinstallation + reprise de données (replatform/forklift) consiste à déployer une boutique PrestaShop 8.x neuve, puis à réimporter ce qui est utile (catalogue, clients, éventuellement commandes) via ETL SQL/API, avec mapping.

La voie “mise à jour en chaîne” est généralement la seule option si vous devez conserver l’historique des commandes dans la même instance (mêmes IDs, mêmes tables, mêmes relations) et éviter des réécritures massives d’URL ou de références externes (ERP, WMS, PIM). En revanche, elle expose aux limites historiques du core : overrides hérités, modules non maintenus, schémas MySQL pollués, et scripts d’upgrade qui partent du principe que l’instance n’a pas dérivé. Dans la pratique, sur une 1.6 très custom, c’est souvent un “upgrade par attrition” : on coupe des modules, on supprime des overrides, on répare des données.

La voie “réinstallation + reprise” est souvent plus rapide à sécuriser, plus simple à tester et plus propre techniquement, notamment quand le thème 1.6 est obsolète et que la dette est trop élevée. Le revers est que vous devez accepter une stratégie de conservation (par exemple : catalogue + clients + adresses + avoirs, mais commandes archivées ailleurs), et traiter les sujets SEO (301, canonical, facettes) de manière systématique. Pour cadrer le scope avant d’écrire la moindre ligne, partez de la checklist d’audit (thème/modules/hooks/overrides) : Migration PrestaShop : checklist d’audit thème, modules, hooks et overrides.

Pour décider rapidement (et éviter les “on verra après”), une matrice simple aide à arbitrer :

Critère	Mise à jour en chaîne	Réinstallation + reprise
Conservation des commandes dans la même base	✅ Très favorable	⚠️ Possible mais coûteux/risqué
Dette technique (overrides, modules abandonnés)	❌ Défavorable	✅ Favorable
Risque d’effet domino (modules/overrides)	❌ Élevé	✅ Plus maîtrisable
Effort SEO (301, facettes, canonical)	⚠️ Modéré à élevé	❌ Élevé si URLs changent
Time-to-market (si catalogue simple)	⚠️ Variable	✅ Souvent meilleur
Besoin de “faire propre” (stack, perf, sécurité)	⚠️ Plus difficile	✅ Naturel

Mini-scénario réaliste : une boutique 1.6 avec un ERP qui pointe sur id_order et des exports compta basés sur les IDs doit souvent privilégier la mise à jour en chaîne (sinon, il faut re-concevoir l’intégration). À l’inverse, une boutique 1.6 sans intégrations fortes mais avec 40 modules non maintenus et un thème sur-mesure ancien gagne presque toujours à partir sur une réinstallation + reprise avec un périmètre data clair.

Pré-requis d’environnement : staging, versions, sauvegardes et reproductibilité

La procédure ci-dessous est décrite pour une cible PrestaShop 8.2.6 (patchs sécurité inclus) sur PHP 8.2.x, avec MariaDB 10.6 LTS ou MySQL 8.0.x, Nginx + PHP-FPM. Ne mélangez pas “migrer l’applicatif” et “migrer l’infra” au dernier moment : une 1.6 tourne parfois encore sur PHP 5.6/7.0 et MySQL 5.6/5.7 ; une 8.x propre exige un socle moderne, et vous gagnerez du temps en provisionnant un staging cible dès le départ. Pour le socle MySQL, la procédure de staging et de tests de charge est très proche d’une upgrade SGBD classique : MySQL migration 5.7 vers 8 : procédure, staging et tests de charge.

Staging n’est pas “optionnel”. La documentation officielle PrestaShop recommande de tester l’upgrade sur une copie (environnement de staging) avant de toucher à la production : devdocs.prestashop-project.org (rubrique “Keeping up-to-date / Upgrade”, selon version). Prenez ça au pied de la lettre : clone des fichiers et de la base, isolation DNS (hosts/URL temporaire), SMTP de test, et désactivation des webhooks/flux sortants si votre boutique est intégrée à un ERP.

Deux points souvent oubliés, mais critiques en staging :

Conformité & données personnelles (RGPD) : si des prestataires externes accèdent au staging, anonymisez au minimum emails/téléphones/adresses (ou restreignez l’accès). En France, ce n’est pas une “bonne pratique”, c’est une mesure de réduction de risque évidente.
Parité technique : staging = même version PHP, mêmes extensions (intl, gd/imagemagick selon votre stack, opcache), mêmes limites (memory_limit), même reverse proxy/CDN si vous en avez un. Sinon, vous débuggez des problèmes qui n’existent qu’en test… ou l’inverse.

Sur la partie sauvegarde, votre baseline minimale avant chaque saut de version :

dump logique cohérent (InnoDB) :

  mysqldump --single-transaction --routines --triggers --events \
    --default-character-set=utf8mb4 \
    -u USER -p DBNAME > db.sql

snapshot fichiers (rsync + checksum, ou snapshot stockage), en excluant éventuellement var/cache/.
plan de rollback écrit : “je remets quels fichiers, quelle base, quel vhost, dans quel ordre”.

Ajoutez un contrôle simple mais décisif : tester la restauration. Un dump qui ne se restaure pas (droits, collation, manque de place disque, timeouts) n’est pas une sauvegarde exploitable.

Pour que tout soit rejouable, mettez le staging sous Git (au moins la conf infra : vhosts, .env/secrets, scripts), et fixez vos versions (PHP, extensions, OS, DB). Si vous êtes sur un hébergement géré, l’approche “migration sans coupure + staging + fenêtre de maintenance” est détaillée ici : Hébergement PrestaShop géré : migration sans coupure, staging et maintenance.

Checklist “prête à migrer” (rapide, mais utile) :

[ ] Staging cloné fichiers + base, accès BO/FO OK
[ ] SMTP de test + destinataires de test (éviter les emails réels)
[ ] CRONs désactivés en staging (import, relances, flux)
[ ] Sauvegarde testée (restauration sur une base vide)
[ ] Inventaire des modules & overrides exporté (CSV simple)
[ ] Mesure initiale : erreurs PHP, temps de réponse, taille DB (pour comparer après)

Chemin “mise à jour en chaîne” : 1.6 → 1.7.8.x → 8.2.x (sans magie)

Une 1.6 ne passe pas “directement” en 8.x de manière fiable. Le chemin pragmatique est : 1.6 (dernière patch-level) → 1.7.8.x → 8.x. Chaque saut est un projet en soi : tests de régression, nettoyage d’overrides, compat modules, et correction des données. Si votre 1.6 est déjà multiboutique et lourde, commencez par stabiliser les caches et comportements multi-shop avant d’upgrader (vous éviterez les faux positifs pendant la migration) : Cache PrestaShop : erreurs fréquentes et bonnes pratiques multiboutique.

Dans cette voie, le point de friction n’est pas “le core”, mais l’écosystème : modules et overrides. Faites un inventaire avant upgrade :

modules non natifs + versions + sources (évitez les ZIPs douteux ; voir GitHub PrestaShop : dépôts officiels, sécurité et checklist d’authenticité).
overrides : sur 1.6/1.7, un override qui passe “par chance” peut casser en 8.x à cause de signatures modifiées, de classes déplacées, ou de dépendances Symfony.
SQL custom : tables ps_xxx créées par modules, colonnes ajoutées sur des tables core, triggers.

Ajoutez un contrôle “base saine” avant d’upgrader, sinon vous empilez les problèmes :

encodage/collation homogènes (idéalement utf8mb4 côté base cible),
pas de tables MyISAM résiduelles,
pas de colonnes dupliquées ou de valeurs incohérentes sur les tables pivot (ex. associations produit/catégorie).

Le déroulé opérationnel “propre” ressemble à ça : (1) geler la prod, (2) cloner sur staging, (3) désactiver modules non indispensables, (4) supprimer/neutraliser overrides (au minimum ceux qui touchent Product, Cart, Order, Carrier, PaymentModule), (5) exécuter la mise à jour vers 1.7.8.x, (6) valider front + BO, (7) répéter vers 8.2.x, (8) réintroduire modules compatibles.

Deux conseils “terrain” pour limiter les surprises :

Procéder par lots : réactivez les modules 5 par 5, avec un test checkout à chaque lot (panier → paiement → confirmation). C’est plus lent, mais vous identifiez immédiatement le module fautif.
Tester les fonctions “invisibles” : génération PDF facture/avoir, envoi email (commande, réinitialisation mot de passe), recherche, navigation à facettes, exports (si vous en avez). Ce sont des points de rupture fréquents après upgrade.

Attendez-vous à du dépannage Symfony côté BO (cache, permissions, var/), même si PrestaShop 8 n’est pas sur Symfony 7 : les symptômes (500, cache corrompu, env mal détecté) sont similaires. Gardez un guide de debug sous la main : Symfony 7 : dépannage erreurs 500, var/cache, Composer et variables d’environnement.

Chemin “réinstallation + reprise de données” : ETL contrôlé et dette technique sous contrôle

Ce chemin part du principe que vous acceptez une approche “clean install” : vous installez PrestaShop 8.2.6 sur un stack propre, vous configurez les fondamentaux (pays, devises, taxes, transporteurs, moyens de paiement), puis vous injectez les données nécessaires. Techniquement, c’est souvent plus robuste : vous ne transportez pas 8 ans de fichiers override/, de modules abandonnés et de colonnes parasites. Côté exploitation, vous obtenez une base plus lisible, et vous pouvez documenter clairement ce qui a été migré vs reconstruit.

Le point clé est la définition du périmètre data. Sur des boutiques avec fort historique, migrer les commandes peut coûter plus cher que les conserver en lecture seule (export BI / archive HTML / base “legacy”). Un compromis courant : migrer catalogue + clients + adresses + règles de prix (si elles sont cohérentes), et laisser commandes/avoirs dans l’ancien système avec une URL d’archive protégée. Si vous avez des intégrations (ERP, PIM, marketplaces), mettez-les en pause et préparez une bascule par “double écriture” (nouvelle boutique qui reçoit mais n’émet pas, puis inversion).

Pour cadrer, voici une liste “périmètre & risques” typique :

Catalogue (produits, déclinaisons, stocks, images) : indispensable, mais attention aux associations (catégories, caractéristiques, attributs) et aux règles de prix.
Clients : soit vous migrez les comptes (en conservant les champs nécessaires à l’authentification), soit vous forcez une réinitialisation de mot de passe au premier login (plus simple mais impact support).
Commandes & factures : côté France/UE, l’archivage peut avoir des implications comptables et de preuve. Souvent, on garde un accès “lecture seule” à l’ancien BO ou on exporte en PDF/ZIP + index.
SEO : récupération des link_rewrite, métas, contenus CMS, et surtout stratégie 301.

Implémentation ETL : deux approches, à combiner selon volumétrie.

1) SQL direct (rapide, mais exigeant) : vous dumppez la base source, vous chargez dans une base de travail, vous nettoyez, puis vous insérez dans la base cible en respectant les contraintes (langues, id_shop, id_lang, id_currency). Pour la volumétrie, automatisez les contrôles (comptage par table, checksum, contraintes FK implicites).
2) API/Webservice (plus lent mais plus “business-safe”) : utile pour laisser PrestaShop recalculer certains invariants (URLs réécrites, associations, hooks). Si vous êtes dans une logique de synchro forte volumétrie, vous avez déjà les patterns (retry, idempotence, files) ici : Intégration API : synchronisation bidirectionnelle et automatisation pour forte volumétrie.

Un exemple de “sanity check” SQL typique après import catalogue :

-- produits sans traduction FR
SELECT p.id_product
FROM ps_product p
LEFT JOIN ps_product_lang pl
  ON pl.id_product = p.id_product AND pl.id_lang = 1
WHERE pl.id_product IS NULL;

-- catégories orphelines
SELECT c.id_category
FROM ps_category c
LEFT JOIN ps_category_lang cl
  ON cl.id_category = c.id_category
WHERE cl.id_category IS NULL;

Enfin, ne négligez pas la migration des médias : beaucoup de reprises de données “semblent OK” en base, puis se révèlent incomplètes parce que les images produits/catégories ne sont pas synchronisées (ou que les droits/chemins ont changé). Prévoyez explicitement : copie des répertoires d’images, régénération des miniatures si nécessaire, et un crawl FO pour détecter les 404 sur médias.

Modules, thème, overrides : compatibilité 8.x et refactoring inévitable

Sur une migration 1.6 → 8.x, le thème 1.6 est à considérer comme jetable : templates, hooks, assets, conventions, tout a divergé. Même sur 1.7, un thème custom ancien doit être ré-audité (Smarty, partials, dépendances JS, surcharge de templates core). Si l’objectif est de livrer vite et stable, partez du thème Classic 8.x, puis rebranchez vos besoins (checkout, header, performance) par incréments. Pour une trajectoire front plus moderne, gardez en tête que la vraie rupture front arrive côté 9.x (ex. thèmes plus récents, réduction des dépendances historiques), mais ce n’est pas le scope ici.

Côté modules, vous devez traiter trois catégories : (a) modules officiels à mettre à jour, (b) modules marketplace à revalider (PHP/Symfony, hooks, overrides), (c) modules sur mesure à refactor. La dette la plus sous-estimée : les modules qui injectent du JS legacy (jQuery global, plugins), les modules qui touchent au panier/commande, et ceux qui écrivent directement en base.

Pour éviter un “big bang”, fixez une règle de décision par module :

Critique pour vendre (paiement, transport, taxes, stock) → validé très tôt, sur staging, avec scénarios de commande réels (annulation, remboursement, retour).
Marketing (relance panier, avis, tracking) → réintroduit après stabilisation, car ce sont des sources fréquentes de régressions et de scripts tiers.
Confort BO (exports, champs custom) → souvent à refactor car la dette technique est élevée.

Pour industrialiser la compat, intégrez ps-validator en CI (sur vos modules custom) : ps-validator : intégration CI/CD du Validator PrestaShop en terminal.

Les overrides sont votre point de rupture principal. En 1.6, c’était le réflexe “rapide”. En 8.x, ça reste possible, mais beaucoup plus risqué car vous êtes sur un cœur plus structuré (et un back-office largement Symfony). Le pattern recommandé en 2026 : minimiser les overrides, préférer hooks, services, décorateurs, et tests. Pour un rappel des bonnes pratiques (même si l’article vise 9.2, les principes s’appliquent) : PrestaShop 9.2 : bonnes pratiques d’override et tests de compatibilité.

Astuce très concrète avant migration : faites une “cartographie” des overrides et de leur criticité (checkout, prix, stock). Même un simple classement P0/P1/P2 (bloquant / important / cosmétique) accélère énormément le tri : vous savez quoi neutraliser en priorité, et quoi ré-implémenter proprement ensuite.

SEO, URLs et performances : ne pas “réussir” la migration en cassant le trafic

La migration applicative qui passe en QA mais perd 30% du trafic organique n’est pas une réussite. Le point dur est la stabilité des URLs : sur PrestaShop, vous jouez avec link_rewrite, la présence/absence d’ID dans l’URL, les suffixes, et surtout les facettes (catégories filtrées). Si vous changez de stratégie (ex. activer/désactiver l’ID dans l’URL), préparez une table de redirections. Google explique clairement que lorsqu’un contenu change d’URL, une redirection 301 est le mécanisme standard pour signaler un déplacement permanent : Google – 301 redirects.

Concrètement, faites un export exhaustif des URLs indexées (Search Console + crawl), mappez vers la cible, puis implémentez des 301 au plus proche de l’edge (Nginx/Apache/CDN).

Deux niveaux de mapping existent :

Mapping “pattern” (rapide) : si vos IDs/slug restent compatibles.
Mapping “table” (fiable) : une liste ancienne_url → nouvelle_url, indispensable si les slugs, catégories, ou la structure changent.

Exemple Nginx (à adapter, et à tester sur un sous-domaine avant prod) :

# Exemple : rediriger un ancien endpoint vers une nouvelle route
# (cas réel : liens historiques qui traînent dans des emails/partenaires)
location = /product.php {
  return 301 /;
}

# Redirection par pattern (uniquement si votre schéma d'URL reste cohérent)
rewrite ^/([0-9]+)-(.+)\.html$ /$1-$2.html permanent;

Sur les facettes, verrouillez votre budget de crawl : une migration est le moment où les URLs de filtres explosent si ps_facetedsearch est mal piloté. Lisez et appliquez : Budget de crawl PrestaShop : maîtriser URLs de filtres et facettes. Et pour l’hygiène des balises (H1/H2/canoniques/hreflang) après bascule : Référencement PrestaShop : optimiser fiches produits, catégories, canonical et hreflang.

Checklist SEO “post-bascule” (courte, mais à faire dans les 48h) :

[ ] Vérifier les codes HTTP sur un crawl (200/301/404/500)
[ ] Comparer le volume de pages indexables (sitemaps, robots, canonicals)
[ ] Contrôler pages catégories et produits : title/H1, canonical, pagination
[ ] Valider les pages transactionnelles (panier/commande) en noindex si c’était votre règle
[ ] Re-soumettre sitemap(s) et surveiller les erreurs d’exploration

La performance ne se corrige pas “après”. Un PrestaShop 8.x propre doit sortir avec une stratégie de cache claire (OPcache, cache Symfony BO, cache front, Redis si utile, CDN si médias lourds). Si vous migrez et que vous laissez var/cache/ instable, des permissions bancales ou un cache multi-shop mal isolé, vous allez débugger des 500 et des pages incohérentes en prod. Pour une stratégie 2026 structurée : Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN et, côté tuning global : PrestaShop performance : optimiser cache, images WebP et base MySQL.

Bascule en production : gel, fenêtre de maintenance, contrôles sécurité et monitoring

La bascule doit être scriptée et chronométrée. Pattern simple et efficace : (1) abaisser TTL DNS 24h avant, (2) passer la prod en maintenance (et couper CRONs, imports, webhooks), (3) faire un dernier dump + rsync, (4) rejouer sur la cible, (5) exécuter vos checks (front, BO, paiement, emails), (6) ouvrir au trafic, (7) surveiller logs + métriques. Si vous avez une infra où le TTFB est déjà limite, ne basculez pas sans avoir validé le stack (PHP-FPM, Redis, HTTP/2/3, etc.) : Hébergement PrestaShop Suisse : performance TTFB, cache Redis, PHP 8.x.

Pour éviter le stress le jour J, préparez une checklist de validation “go/no-go” qui ne dépend pas d’une seule personne :

commande test (mode paiement réel ou environnement de sandbox) ;
génération facture/avoir ;
email “commande” + “mot de passe oublié” ;
back-office : création produit, mise à jour stock, création règle panier ;
tâches planifiées (CRON) en mode dry-run si possible ;
logs Nginx/PHP : absence de 500 sur les pages clés.

Côté sécurité, migrez en intégrant les patchs récents, pas “la version que vous aviez sous la main”. À date (2026-08), vérifiez notamment les correctifs back-office liés aux Stored XSS et gardez un process de mise à jour régulière : CVE-2026-44212 PrestaShop : correctifs Stored XSS back-office 8.2.6/9.1.1. Sur un environnement durci, faites aussi un scan boîte noire ciblé (auth, BO, uploads) avant ouverture : Wapiti : scanner open source de vulnérabilités web en boîte noire.

Enfin, prévoyez le monitoring dès le jour 0 : erreurs PHP (fatal/notice), latences DB, saturation CPU/FPM, et métriques applicatives (taux de conversion checkout, erreurs paiement). Un outil de supervision temps réel type Netdata permet d’identifier immédiatement un goulot (IO, swap, connexions MySQL) pendant les premières heures de prod : Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller.

Dernier point, très opérationnel : définissez dès l’avance vos points de non-retour. Typiquement, dès que vous rouvrez la boutique et que des paiements passent, un rollback “simple” devient difficile (sinon, vous perdez des commandes). Si vous n’avez pas de plan de rollback testé, vous n’avez pas de plan : répétez une bascule complète sur staging (y compris restauration), chronométrez-la, et documentez précisément les “points de non-retour” (paiements, emails, synchronisations externes).