Migration PrestaShop 1.6/1.7/8 vers PrestaShop 9 sans coupure

Table des matières :

1. Ce que signifie vraiment “sans coupure” sur une migration PrestaShop 9
2. Prérequis PrestaShop 9 : aligner PHP, DB, collation, et système de fichiers avant de parler données
3. Architecture blue/green concrète : load balancer, sessions, cookies, et cache applicatif
4. Stratégie de migration des données : clone, upgrade offline, puis synchronisation des écritures
5. Cas 1.6 vs 1.7/8 : ce qui change réellement dans la méthode (et ce qu’il vaut mieux éviter)
6. Plan de bascule minute par minute : health checks, rollback, observabilité, et SEO sans régression
7. Points de friction spécifiques PrestaShop 9 : index de recherche, performances, sécurité, et “effet module”
8. Checklist opérationnelle minimale (à adapter) pour réussir une migration “sans coupure”

Ce que signifie vraiment “sans coupure” sur une migration PrestaShop 9

Dans l’écosystème PrestaShop, “sans coupure” ne veut pas dire “je clique sur Mettre à jour et rien ne se passe”. Le cœur n’a pas été conçu pour des mises à jour en ligne : la mise à niveau touche à la base (DDL, migrations), au code (autoload, overrides), au cache (Smarty/Twig/Symfony) et au back-office (rebuild d’assets). L’outil AutoUpgrade met d’ailleurs la boutique en maintenance pour une raison simple : la cohérence fonctionnelle n’est pas garantie pendant les phases de transformation.

En pratique, “sans coupure” recouvre au moins 3 réalités différentes (qu’il faut clarifier avant de promettre quoi que ce soit) :

• Sans coupure de navigation : les pages continuent de répondre (au pire avec un message sur le checkout).
• Sans coupure transactionnelle : le tunnel de commande continue et aucune commande n’est perdue.
• Sans coupure de services annexes : ERP/WMS, transporteurs (Colissimo, Mondial Relay…), paiement (PayPlug, Alma, Monetico…), tracking, flux marketplaces continuent sans désynchronisation.

Pour cadrer techniquement, posez des objectifs RTO/RPO : RTO (temps max d’indisponibilité) et RPO (perte de données acceptable). Une migration “sans coupure” au sens e‑commerce réaliste vise généralement RTO ~ 0–30 s (bascule) et RPO = 0 (aucune commande perdue). Dans la pratique, le point dur n’est pas la bascule HTTP, c’est la synchronisation des écritures (commandes, clients, stocks) pendant que vous préparez l’environnement PrestaShop 9.

Pour éviter les discussions “au feeling”, vous pouvez formaliser ça en tableau simple (exemples) :

Objectif métier	RTO cible	RPO cible	Implication technique
Boutique vitrine (pas de checkout)	0–5 min	0	Bascule DNS/LB + tests
E-commerce standard	0–30 s	0	Blue/green + delta d’écritures
Gros volume / promos	0–10 s	0	Réplication + procédure stricte + monitoring renforcé

Martin Fowler résume proprement le principe : « Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. » (Martin Fowler, BlueGreenDeployment, BlueGreenDeployment). PrestaShop n’est pas “cloud native”, mais la stratégie blue/green s’applique très bien si vous acceptez une vérité : vous ne migrez pas “en place”, vous déployez une nouvelle prod et vous basculez.

Dernier point de cadrage : “sans coupure” ne doit pas faire oublier la perception utilisateur. Une boutique qui “répond” mais devient lente peut dégrader la conversion. À titre d’ordre d’idée, Google a popularisé l’idée que la vitesse est un facteur d’abandon sur mobile :

« 53% des visites sont abandonnées si une page mobile met plus de 3 secondes à charger. » (Google/SOASTA, The Need for Mobile Speed, 2017)

Ce chiffre ne remplace pas vos métriques (P95, taux d’erreur paiement), mais rappelle pourquoi la bascule doit inclure performance + stabilité, pas seulement “HTTP 200”.

Prérequis PrestaShop 9 : aligner PHP, DB, collation, et système de fichiers avant de parler données

Le premier piège sur un legacy 1.6/1.7, c’est de confondre migration applicative et migration système. PrestaShop 9 impose un socle moderne (PHP plus récent, extensions, contraintes Symfony) et ne tolère pas les bricolages “ça marche sur mon mutualisé”. Référez-vous aussi à votre propre politique de gestion des versions : en 2026, viser une version PHP maintenue (typiquement 8.2/8.3) n’est pas négociable. Le site contient un point de vigilance utile sur les incohérences de docs : PrestaShop 9 : versions PHP recommandées et incohérences de documentation.

Concrètement, avant même d’importer un dump, faites un “contrôle technique” reproductible (ça évite de découvrir une extension manquante à T‑0) :

php -v
php -m | egrep "intl|zip|gd|imagick|pdo_mysql|mbstring|curl|openssl"
mysql --version

Côté base, les migrations 1.6→9 héritent souvent de schémas hétérogènes : tables MyISAM, collations mixtes, encodages partiels, indexes “fantômes”, champs TEXT sans charset explicite. Avant toute tentative de migration, standardisez : MariaDB/MySQL supportés, InnoDB, UTF‑8 cohérent (idéalement utf8mb4), et corrigez les collations. Pour les prérequis DB, gardez un runbook dédié : Prérequis système : migration MySQL vers MariaDB, InnoDB et collation UTF-8.

Deux détails “qui font perdre une journée” sur des boutiques françaises / UE :

• Tri et collation : une collation incohérente peut casser des recherches (accents, ligatures), des doublons e‑mail, ou des comparaisons SKU.
• Fuseaux horaires / dates : vérifiez le time_zone MySQL/MariaDB, le timezone PHP et la configuration PrestaShop (sinon écarts sur exports comptables, avoirs, ou cut-off transporteur).

Enfin, ne sous-estimez pas le système de fichiers : PrestaShop dépend fortement des répertoires img/, download/, upload/, modules/, et du cache var/cache/ (1.7+). Une migration “sans coupure” exige que vous sachiez reconstruire et revalider ces artefacts sur l’environnement green (thumbnails, images webp si vous les générez, assets compilés). Si votre infra évolue en même temps (Docker, VPS), verrouillez les choix en amont : VPS pour Docker : critères techniques et ressources recommandées.

Astuce terrain : faites un inventaire des “gros volumes disque” à l’avance (souvent img/p/ et img/c/). Si vous basculez sur une infra neuve, vous gagnez beaucoup à pré-synchroniser ces répertoires (rsync) puis ne transférer que le delta juste avant cutover.

Architecture blue/green concrète : load balancer, sessions, cookies, et cache applicatif

La migration PrestaShop 1.6/1.7/8 vers PrestaShop 9 sans coupure se joue au niveau L7 : vous gardez Blue (prod actuelle) et vous préparez Green (PrestaShop 9) en parallèle. La bascule doit être atomique, observable et réversible. En pratique : HAProxy/Nginx/Caddy en frontal, deux backends, et une règle de routage qui permet soit un cutover global, soit un canary (ex : 1% du trafic sur Green). Si vous êtes déjà sur HAProxy, vous pouvez vous inspirer des patterns de reverse proxy (TLS, rate limiting, metrics) : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus.

Dans une boutique PrestaShop, le LB ne sert pas qu’à router : il protège aussi le jour J. Deux exemples concrets utiles :

• Limiter les explosions de trafic (bots, scrapers, affiliates agressifs) pendant le cutover via du rate limiting.
• Tracer les erreurs en isolant les backends (hausse 500/503 côté Green = rollback immédiat).

Le point souvent raté : l’état utilisateur. PrestaShop utilise principalement un cookie applicatif (pas un PHP session store centralisé), mais certains modules (paiement, anti-fraude, SSO) ajoutent du state côté serveur. Si vous basculez brutalement, vous risquez : déconnexions, paniers perdus, erreurs sur le tunnel. Pour limiter, vous pouvez : (1) maintenir des cookie keys compatibles (attention : selon versions, format et champs signés changent), (2) activer des sticky sessions au niveau LB le temps d’une fenêtre, (3) accepter un reset de panier et l’annoncer si vous ne pouvez pas garantir la continuité. Dans les migrations réellement “zéro perte”, la stickiness n’est qu’un sparadrap : le vrai sujet reste la donnée.

Ajoutez aussi un point critique souvent oublié : les callbacks externes (paiement, antifraude, livraison). Même si vous basculez le trafic web, des services tiers peuvent appeler :

• l’URL de notification paiement,
• des endpoints de confirmation,
• des webhooks.

Pendant la transition, décidez clairement : qui (Blue ou Green) doit recevoir ces notifications, et comment vous évitez un double traitement. La solution la plus simple le jour J est de faire en sorte que les URLs callbacks continuent à tomber sur l’environnement qui écrit réellement (souvent Blue jusqu’à T‑0).

Côté cache, le faux bon plan est de “partager” le cache entre Blue et Green. Ne le faites pas : caches Smarty/Twig, container Symfony, class index et overrides diffèrent ; mutualiser déclenche des erreurs non déterministes. En revanche, vous pouvez partager des composants d’infra génériques (Redis pour cache applicatif si vous l’utilisez, CDN pour assets), mais isolez les namespaces et purgez proprement. Si vous devez industrialiser Redis en prod, les bases sont ici : Redis PrestaShop : configurer le cache sur VPS ou serveur dédié.

Stratégie de migration des données : clone, upgrade offline, puis synchronisation des écritures

Le chemin “propre” est : cloner la prod Blue, upgrader le clone vers PrestaShop 9, valider, puis rattraper les écritures générées sur Blue pendant la préparation de Green. C’est là que beaucoup de projets échouent, parce qu’ils découvrent tard que “répliquer” une base PrestaShop n’est pas un simple mysqldump : la prod bouge (commandes, stocks, paniers), et le schéma change fortement entre 1.6/1.7/8 et 9.

Une approche pragmatique (et généralement acceptable) consiste à viser une “non-coupure” côté navigation, avec une fenêtre d’écriture minimale :

1. T‑J : clone complet de Blue (DB + fichiers), construction de Green, upgrade offline.
2. T‑0 : passage Blue en read-only (checkout désactivé, ou paiement bloqué) pendant quelques minutes.
3. Export des deltas : commandes/clients créés depuis le dernier snapshot (par timestamp, auto-increment, ou log applicatif).
4. Injection dans Green via scripts (idéalement par API pour recalculer correctement, sinon SQL maîtrisé).
5. Bascule LB vers Green, retour en read-write.

Ce qui mérite d’être explicité : quelles données sont réellement “écritures critiques” sur une boutique. Selon votre contexte, la liste peut inclure :

• commandes (orders, paiements, statuts, factures/avoirs),
• clients (créations + changements d’adresse),
• stocks (si synchronisés avec ERP/WMS en quasi temps réel),
• paniers (souvent non critiques, sauf si votre conversion dépend de paniers persistants),
• messages SAV / service client.

Dans une boutique française connectée à un ERP, le risque numéro 1 est la désynchronisation stock (survente) pendant la bascule : si vous ne pouvez pas garantir le flux, prévoyez une règle de sécurité (ex : seuil de stock minimal temporaire, ou blocage de vente sur best-sellers 10 minutes).

Le cœur de PrestaShop n’offre pas un mode “read-only” global fiable. Vous devez donc implémenter un verrou applicatif : désactivation des modules de paiement + message contrôlé, ou règle WAF/LB bloquant POST sur /order et endpoints critiques (au risque de faux positifs). C’est précisément le genre de préparation qui doit être testée en pré-prod avec une checklist : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests.

Si vous avez un RPO strict et une volumétrie élevée, vous pouvez aller plus loin : capturer les écritures Blue dans une file (binlog MySQL, triggers, ou instrumentation applicative), puis rejouer sur Green. Attention : rejouer des commandes “à la main” en SQL est dangereux (totaux, TVA, règles panier, stocks, états). Une option plus robuste est d’utiliser l’API (Webservice) comme “contrat” d’insertion, au prix de performances et de gestion d’erreurs. Pour cadrer l’API : API Webservice PrestaShop : accès CRUD, authentification et bonnes pratiques et Webservice PrestaShop : activer l’API et créer une clé d’accès.

Point RGPD (concret) : si vous dupliquez la prod pour construire Green, vous dupliquez aussi potentiellement des données personnelles. Assurez-vous que l’environnement Green est protégé (accès restreint, logs maîtrisés) et que vos prestataires éventuels opèrent dans un cadre conforme (hébergement UE, droits d’accès, durée de conservation du clone).

Cas 1.6 vs 1.7/8 : ce qui change réellement dans la méthode (et ce qu’il vaut mieux éviter)

Depuis PrestaShop 1.6, l’écart n’est pas “une mise à jour”, c’est un changement d’architecture (Symfony, modernisation BO, assets, nouveaux hooks, changements d’ORM interne). Une migration 1.6→9 “sans coupure” est rarement un upgrade in-place crédible : les overrides historiques, modules non maintenus, thèmes Smarty legacy, et patchs core rendent l’opération non déterministe. Dans ce cas, le scénario le plus rationnel est un replatforming : installer PrestaShop 9 propre, migrer les données (catalogue, clients, commandes) et reconstruire le front.

Un bon indicateur pour décider “upgrade vs replatforming” : votre taux de personnalisation non versionnée. Si vous avez (a) des overrides partout, (b) des modifications directes du core, (c) un thème 1.6 très custom, alors une migration “sans coupure” doit être pensée comme un projet applicatif, pas comme une mise à jour.

Pour PrestaShop 1.7 ou 8, vous avez plus d’options : vous pouvez techniquement faire un upgrade du clone (AutoUpgrade ou procédure manuelle) puis basculer. Mais “plus d’options” ne veut pas dire “plus simple”. En 1.7/8, vous avez déjà du Symfony dans le core ; en 9, la couche BO et certains contrôleurs/services changent, et l’écosystème modules/thèmes doit suivre. Le guide interne sur l’adaptation des modules et thèmes aux contrôleurs services/Twig vous évite des heures de débogage : PrestaShop 9 : adapter modules et thèmes aux contrôleurs services et Twig.

Mini-scenario réaliste (sans marque) : une boutique 1.7 qui utilise un module de paiement “France-only” et un module de transporteur avec pickup points. Le front semble OK sur Green, mais le checkout casse sur une route Symfony modifiée, et le BO “Commandes” devient lent à cause d’un override obsolète. Sans matrice de compatibilité, vous le découvrez trop tard. Avec une matrice, vous le détectez en pré-prod :

Composant	Criticité	Test minimal avant bascule
Paiement	Bloquant	paiement OK + IPN/callback OK
Transporteur	Bloquant	calcul frais + sélection point relais
TVA / facturation	Élevée	facture/avoir, arrondis, règles taxe
Export ERP	Élevée	flux commandes + statuts + stocks
SEO	Élevée	URLs, canonicals, redirections, sitemap

Évitez deux anti‑patterns récurrents : (1) upgrader en prod “en direct” puis tenter de réparer sous pression, (2) empiler des “correctifs” non versionnés dans override/ jusqu’à rendre l’environnement incopiable. Si vous avez déjà vécu une mise à jour ratée, vous savez ce que ça donne (erreurs 500, BO inaccessible, classes en conflit). Gardez ce runbook sous la main pour le rollback et le diagnostic : Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement.

Plan de bascule minute par minute : health checks, rollback, observabilité, et SEO sans régression

Une bascule “sans coupure” se prépare comme un déploiement applicatif, pas comme une manipulation d’admin. Définissez un plan chronométré avec responsabilités et critères go/no‑go. Typiquement :

• T‑60 min : warmup Green (cache build, compilation assets, cron, indexation de recherche si nécessaire), tests BO/FO ciblés.
• T‑10 min : activer read-only Blue (ou blocage checkout), capturer métriques d’état.
• T‑5 min : rattrapage delta (commandes/clients), recalculs (stocks, index, caches), smoke tests.
• T‑0 : bascule LB + purge CDN ciblée + vérif santé (HTTP 200, panier, paiement, BO login).
• T+15 min : monitoring renforcé, rollback prêt.

Pour que le plan soit actionnable, remplacez “vérif santé” par une liste de checks (2–3 minutes max) :

• Page catégorie + page produit (images, déclinaisons, prix, TVA affichée).
• Ajout panier + passage commande jusqu’au choix paiement (sans forcément débiter si vous avez un mode sandbox).
• Connexion BO + ouverture “Commandes” + création d’un avoir (si vous en faites souvent).
• Endpoint critique de flux (ERP / tracking) : au moins vérifier que la tâche cron tourne et ne renvoie pas d’erreur.

Le rollback doit être “mécanique” : si Green se dégrade, vous rebasculez vers Blue (et vous savez ce que vous faites des écritures passées sur Green). C’est le point que beaucoup de projets n’osent pas formaliser. Pour cadrer le volet sécurité/tests/rollback, ce guide est aligné avec une approche SRE : Migration PrestaShop 9 : sécurité, tests et plan de rollback et, plus globalement, Migration PrestaShop 9 : checklist complète sécurité, SEO, performance.

Sur l’observabilité, ne vous limitez pas aux logs Apache/Nginx. Vous devez corréler : logs PHP (FPM ou serveur d’app), erreurs JS (front), slow queries, taux d’échec paiement, et 503. En cas de surcharge post-bascule, ayez un protocole de diagnostic clair (CPU, RAM, IO, pool PHP, DB). Pour industrialiser : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et, si vous voyez des 503, Erreur HTTP 503 : diagnostic serveur, logs et ressources.

Enfin, “sans coupure” ne sert à rien si vous cassez le SEO (perte d’indexation, facettes incontrôlées, redirections manquantes). Le minimum : conserver les patterns d’URL, vérifier canonical/hreflang si multi-langue, contrôler la génération de sitemap, et auditer les pages à risque (facettes, pages de recherche interne). Pour cadrer l’indexation : Plan de site : optimiser l’indexation Google avec un sitemap clair et Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne.

Deux contrôles SEO “très opérationnels” à ajouter au runbook :

• Avant bascule : exporter une liste d’URLs qui font du trafic (Search Console / analytics) et vérifier qu’elles répondent en 200 sur Green (ou redirigent proprement).
• Après bascule : surveiller les 404 et soft-404 (logs + Search Console) et corriger les redirections dans les 24–48h, surtout si vous changez un thème ou une structure de catégories.

Points de friction spécifiques PrestaShop 9 : index de recherche, performances, sécurité, et “effet module”

PrestaShop 9 peut améliorer des choses (modernisation BO, trajectoire vers des APIs d’admin, évolutions 9.2) mais ne “répare” pas votre dette historique par magie. Sur gros catalogues, la pression se déplace souvent vers l’indexation (recherche interne), les requêtes de listings, et la génération d’images. Si vous migrez un 1.6, attendez-vous à découvrir des indexes SQL sous-dimensionnés ou des tables encombrées. Travaillez à partir des fondamentaux : Index de recherche PrestaShop : fonctionnement, tables SQL et pondérations et, côté tuning global, PrestaShop performance : optimiser gros catalogues et Core Web Vitals.

Un symptôme classique post-migration : “le back-office va bien, mais les catégories sont lentes”. Souvent, ce n’est pas PrestaShop 9 “qui est lourd”, c’est :

• des requêtes de filtres/facettes qui explosent sur un catalogue plus grand qu’à l’origine,
• une couche cache désactivée (ou mal dimensionnée),
• des modules qui ajoutent des jointures coûteuses.

Le deuxième point de friction, c’est l’“effet module”. Un module peut : modifier le schéma, injecter du JS bloquant, ajouter des overrides, ou intercepter le checkout. En migration blue/green, vous devez traiter les modules comme des dépendances applicatives versionnées, avec une matrice : module × version PrestaShop × PHP × features utilisées. Si vous devez déboguer, faites-le proprement (Xdebug en CLI et web, reproductibilité). Le site a les guides nécessaires : Xdebug : installer et activer Xdebug 3 pour PHP CLI et web et Xdebug VS Code : configurer le débogage PHP en local.

Un conseil de méthode (simple mais efficace) : sur Green, faites une passe de validation “mode dégradé” :

1. thème + core uniquement,
2. puis activation progressive des modules critiques (paiement, transport),
3. puis modules marketing/SEO,
4. puis le reste.

Ça vous permet d’isoler rapidement “le module qui casse tout”, au lieu de déboguer un ensemble.

Enfin, la sécurité n’est pas un “après”. Une migration est un moment où vous changez des dépendances, réexposez des endpoints, et remettez en ligne des modules vieux. Prenez l’habitude d’intégrer les checklists de durcissement et de patching dans le plan de bascule (WAF, CSP, mise à jour modules à risque). Exemple concret : si vous utilisez psfacetedsearch, gardez une procédure de durcissement et de patch (et vérifiez la version du module) : Sécurité PrestaShop : corriger la CVE-2026-54159 et durcir psfacetedsearch.

Checklist opérationnelle minimale (à adapter) pour réussir une migration “sans coupure”

Avant de lancer un quelconque chantier 1.6/1.7/8 vers PrestaShop 9, documentez l’existant : version exacte, patchs core, overrides, modules, cron, intégrations ERP/WMS, moyens de paiement, règles de prix. Cette phase n’est pas du “papier” : elle conditionne la méthode (upgrade vs replatforming) et les risques. Le plan incrémental blue/green détaillé ici sert de base de design : Migration PrestaShop : audit technique et plan incrémental blue/green.

Ensuite, construisez Green comme un artefact reproductible : dépôt Git, build (Composer/NPM si thème), configuration externalisée (env, secrets), et pipeline de déploiement. Si vous changez aussi le runtime PHP (ex : serveur d’app moderne), testez la compatibilité en amont : FrankenPHP : stabilité des workers et compatibilité PrestaShop en pratique et FrankenPHP : serveur d’application PHP avec Caddy, HTTP/3 et HTTPS auto.

Une checklist minimale (volontairement courte) qui évite les angles morts :

• [ ] Objectifs écrits : RTO/RPO, fenêtre de bascule, qui décide le go/no-go.
• [ ] Inventaire modules : critiques (paiement/transport/ERP), puis secondaires, versions et compatibilité PHP/PS9.
• [ ] Pré-prod réaliste : copie DB + un échantillon représentatif des images/modules/config.
• [ ] Procédure read-only testée : comment bloquer les écritures sans casser tout le front.
• [ ] Delta d’écritures : méthode de rattrapage définie (API/SQL maîtrisé) + tests de non-régression.
• [ ] SEO : redirections, URLs, canonical/hreflang, sitemaps, robots.txt, contrôle 404.
• [ ] Observabilité : logs PHP/SQL/JS, métriques (P95, erreurs paiement), alertes pendant 24–48h.
• [ ] Rollback : condition de rollback + procédure + responsable + gestion des écritures post-bascule.

Enfin, ne validez pas uniquement “ça charge”. Validez des parcours : recherche, fiche produit, panier, checkout, paiement, création compte, BO commandes, exports, hooks de tracking. Mettez des métriques : taux d’erreur paiement, temps de réponse P95, nombre de requêtes SQL par page, taille des pages, CWV. Et surtout : préparez votre scénario “ça casse” (rollback + diagnostic). La différence entre une migration sereine et une nuit blanche, c’est rarement un hack : c’est une procédure testée.