Migration PrestaShop : audit technique et plan incrémental blue/green

Un point souvent sous-estimé : les écritures disque. PrestaShop écrit sur disque (cache, images, factures, exports), et certains modules aussi. En green, standardisez :

• le chemin et les permissions (propriétaire/groupe) de var/, img/, download/, upload/
• la stratégie de cache (désactiver les caches “agressifs” tant que vous n’avez pas validé les pages dynamiques)
• les limites de taille upload si vous avez un catalogue géré par import (CSV, images)

La recommandation pragmatique en 2026 : green = même classe d’hébergement que blue, pas une architecture « différente parce que c’est l’occasion ». Une migration PrestaShop + un changement de paradigme infra (VPS → Kubernetes, Apache → Nginx, etc.) est possible, mais multiplie les variables. Si votre objectif est la disponibilité, faites-le en deux lots : d’abord la mécanique blue/green, ensuite l’optimisation infra (Redis/Varnish/CDN). Sur les composants de cache/réseau, alignez-vous sur des configurations déjà documentées et monitorables (ex. HAProxy) : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus et, si vous partez sur HAProxy 3.2 LTS, gardez un déploiement propre : HAProxy 3.2 : déploiement LTS sur Ubuntu/Debian, compilation et systemd.

Ajoutez un garde-fou de rollback “build” : la capacité à redéployer une version connue en quelques minutes. Dans la pratique, ça implique :

• des versions taguées (Git + artefacts)
• un stockage des dépendances (Composer/Node) déterministe
• une procédure de “rebuild green from scratch” testée avant le jour J

Pour cadrer les conventions PrestaShop (et éviter les comportements implicites), une ressource externe utile, reconnue et maintenue, est la doc développeur PrestaShop : https://devdocs.prestashop-project.org/ (ex. conventions modules, overrides, architecture).

Synchronisation des données : réplication MySQL/MariaDB et limites réelles sur PrestaShop

Le nœud du blue/green sur PrestaShop, ce n’est pas le routage : c’est la donnée. MySQL/MariaDB en prod e-commerce, c’est du write-heavy (paniers, sessions, commandes, logs applicatifs). La réplication est l’outil standard, mais elle a des contraintes. La réplication est asynchrone par défaut, ce qui implique un décalage (lag) possible entre source et réplique. Traduction : il y a un lag, donc il y a un risque.

Le pattern le plus robuste (et réaliste) pour une migration PrestaShop :

1. Green en lecture seule au début, alimenté par une réplication depuis blue (ou un dump initial + rattrapage par binlog).
2. Tests fonctionnels sur green avec des données réelles (anonymisées si nécessaire), y compris checkout, paiement en sandbox, webhooks.
3. Gel d’écriture court sur blue (maintenance « read-only » côté front + blocage admin) le temps que green rattrape le dernier binlog.
4. Bascule HTTP vers green.

Attention aux migrations de schéma : si green applique des alter/migrations qui rendent le schéma incompatible avec la réplication en cours, vous devez séquencer : (a) réplication sur schéma identique, (b) cutover, (c) migrations post-cutover. C’est frustrant, mais c’est le prix à payer pour éviter le scénario classique : réplication cassée à cause d’un ALTER, et vous découvrez le problème pendant la fenêtre de bascule.

Quelques limites “terrain” à anticiper spécifiquement en e-commerce :

• Paiement : certaines transactions génèrent des écritures après le retour client (webhooks PSP). Si vous geler les écritures, prévoyez une communication claire et une fenêtre courte, sinon vous créez des paiements “en attente” difficiles à réconcilier.
• Stocks : si votre stock est synchronisé par ERP, vérifiez la direction des flux pendant la bascule (ERP → PrestaShop, ou PrestaShop → ERP). Un flux mal séquencé peut réinjecter de vieux stocks sur le nouvel environnement.
• CRON : stoppez/neutralisez les CRON côté green tant que green n’est pas la prod (sinon : doublons mails, exports, relances paniers). Puis, au cutover, faites l’inverse : basculez proprement les jobs vers green et coupez ceux de blue.

La donnée ne se limite pas au SQL. Les médias (img/, uploads, factures PDF), les exports, et parfois des caches disque doivent être synchronisés. Faites-le comme un flux, pas comme un one-shot : rsync incrémental périodique (toutes les 5–10 minutes), puis un rsync final pendant le gel. Si vous utilisez une recherche externe (Elasticsearch/Solr/Meilisearch), reconstruisez l’index sur green et comparez des métriques (zéro résultat, CTR interne, temps de réponse) : l’index est un composant fonctionnel, pas un « bonus ». Référence utile pour éviter de casser la pertinence : Moteur de recherche interne : Elasticsearch, Solr et bonnes pratiques de pertinence.

Mini-scenario réaliste (utile pour cadrer les tests) : une boutique FR/UE avec pics 12h–14h, beaucoup de mobile, et des transporteurs à points relais. Le jour J, vous basculez en dehors des pics, mais vous testez impérativement :

• sélection point relais + paiement + retour banque,
• e-mails transactionnels (confirmation commande, expédition),
• webhooks PSP reçus après la commande (cas fréquent en 3DS).

Bascule progressive : HAProxy, canary, observabilité et garde-fous SEO

Le routage blue/green propre se fait au niveau reverse-proxy (HAProxy/Nginx) ou au niveau LB cloud. Vous voulez : healthchecks, bascule instantanée, et idéalement un mode canary (1–5% du trafic) avant cutover total. Exemple minimal HAProxy (à adapter) pour router sur un cookie de canary et permettre un rollback rapide :

frontend fe_https
  bind :443 ssl crt /etc/ssl/private/site.pem
  http-request set-header X-Forwarded-Proto https

  acl is_canary cook(canary) -m found
  use_backend be_green if is_canary
  default_backend be_blue

backend be_blue
  option httpchk GET /index.php
  http-check expect status 200
  server blue1 10.0.0.10:80 check

backend be_green
  option httpchk GET /index.php
  http-check expect status 200
  server green1 10.0.0.20:80 check

Deux précautions importantes avec PrestaShop :

• Canary ≠ tests de commande par défaut. Si blue et green n’écrivent pas sur la même base (ce qui est le cas en vraie approche blue/green), un canary “grand public” peut créer des paniers/commandes uniquement visibles sur green, donc impossibles à retrouver en cas de rollback immédiat. La pratique la plus sûre : canary d’abord sur pages non transactionnelles (home, catégories, produits), puis canary transactionnel uniquement sur un panel contrôlé (comptes internes, IP allowlist, ou coupon réservé).
• Healthcheck utile : un GET /index.php peut renvoyer 200 alors que le checkout est KO. Idéalement, ajoutez un check applicatif léger (ex. endpoint “/healthz” côté proxy/app si vous en avez un), ou au minimum un check sur une page dynamique qui touche la DB.

Sur PrestaShop, surveillez immédiatement les points sensibles à la bascule : sessions, panier, checkout, callbacks paiement, webhooks transporteurs, et génération de pages dynamiques (catégorie/produit). Le SRE Book (Google) insiste sur le fait que de nombreux incidents proviennent des changements et que l’observabilité doit être prête avant la mise en production (Site Reliability Engineering, sre.google/sre-book/). Donc vous instrumentez avant de basculer : taux d’erreur HTTP 5xx, exceptions PHP, temps de réponse p95/p99, slow queries, saturation PHP-FPM.

Checklist “observabilité jour J” (simple, mais décisive) :

• Dashboard comparatif Blue vs Green (p95, 5xx, DB connections, CPU/RAM)
• Alerte si erreurs checkout/paiement dépassent votre seuil (défini dans le plan de rollback)
• Log corrélé (request id / trace id si possible) pour relier un 500 à une requête DB ou à une exception module

Côté SEO, un blue/green mal exécuté crée des effets secondaires bêtes : pages en noindex, canonical qui pointe sur une URL de staging, règles de redirection incomplètes, robots.txt divergents, sitemap cassé, variations d’URLs (slash, trailing, rewrite). Pour cadrer la partie SEO technique de la migration, alignez-vous sur une checklist existante et exécutable : Migration PrestaShop 9 : checklist complète sécurité, SEO, performance et, si vous devez renforcer la couche réseau pendant la bascule (pics de requêtes, faux positifs WAF sur checkout), préparez les règles avant le jour J : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Ajout très concret “SEO + canary” : faites en sorte que le trafic canary ne pollue pas vos signaux.

• Si vos tests canary incluent des bots internes/outils, utilisez un User-Agent spécifique et bloquez-le dans analytics si nécessaire.
• Vérifiez que green sert exactement les mêmes hreflang, canonical, robots et sitemaps que blue (sauf si la migration vise à les corriger, auquel cas vous documentez les écarts).

Rollback et plan incrémental : découper la migration en lots qui se vérifient

Le rollback blue/green est trivial tant que vous n’avez pas « consommé » de nouvelles écritures sur green. Dès qu’une commande a été passée sur green, revenir sur blue implique une resynchronisation inverse (souvent non prévue), ou l’acceptation d’une divergence métier. Donc la stratégie réaliste est : bascule réversible tant que la fenêtre de gel n’est pas levée, puis rollback applicatif limité (hotfix) plutôt qu’un retour complet.

Formalisez vos critères de rollback (avant de migrer) :

• taux d’erreur checkout > X% pendant Y minutes,
• augmentation du p95 > Z% vs baseline,
• erreurs paiement (webhooks) ou stock incohérent,
• dérive SEO détectée (canonical/robots),
• saturation ressources (CPU, mémoire, connexions DB) non anticipée.

Pour éviter les seuils arbitraires, définissez-les en vous appuyant sur votre baseline. Exemple pragmatique :

• p95 : rollback si p95_green > p95_blue × 1,5 sur 10 minutes et corrélé à une hausse d’erreurs.
• checkout : rollback si erreurs “validation commande / paiement” dépassent un seuil absolu (ex. > 20 erreurs/5 min), même si le pourcentage est trompeur quand le trafic varie.

Et surtout : documentez et testez votre plan. Une ressource interne dédiée existe sur la partie sécurité/tests/rollback : Migration PrestaShop 9 : sécurité, tests et plan de rollback.

Le « plan incrémental » consiste à séparer ce qui est couplé (et doit basculer ensemble) de ce qui peut migrer en amont. Exemple de découpage qui marche bien en agence/DSI : (1) duplication infra + observabilité, (2) green avec même version PrestaShop que blue (preuve que l’environnement est sain), (3) migration applicative (upgrade core + adaptations modules/thème) en staging, (4) synchronisation data + rehearsal de bascule, (5) bascule canary, (6) cutover total, (7) nettoyage (suppression modules, dette override), (8) optimisation (Redis/Varnish/CDN). Pour la couche CDN, évitez les surprises le jour J (cache de pages sensibles, purge, variations) : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly.

Deux ajouts qui rendent ce plan vraiment “vérifiable” :

• Répétition générale (rehearsal) : vous exécutez une bascule complète en préprod avec chronométrage (temps de gel, temps de rattrapage réplication, temps de purge caches/CDN, temps de warmup). Une migration réussie, c’est souvent une migration déjà “vécue” une fois.
• Critères d’acceptation post-cutover : liste courte (10–15 points) à valider dans l’heure : commande, paiement, e-mails, back-office, indexation (robots/canonical), logs propres, CRON actifs uniquement sur green.

Enfin, imposez-vous une discipline de release : « si ça fait mal, faites-le plus souvent ». La formule est devenue un standard DevOps : “If it hurts, do it more often, and bring the pain forward.” (Jez Humble & David Farley, Continuous Delivery, Addison-Wesley, 2010). Sur PrestaShop, ça se traduit par des migrations répétables en préprod, des scripts d’audit, des tests de non-régression du tunnel de commande, et une capacité à reconstruire green à l’identique. Sans cette répétabilité, blue/green n’est qu’un nom pour une bascule stressante.