Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests

Table des matières :

1. Cadrer la mise à jour PrestaShop : ce qu’on met à jour (et ce qu’on ne peut pas ignorer)
2. Checklist sauvegarde : RPO/RTO, 3-2-1, base, fichiers, secrets (et surtout tests de restauration)
3. Pré-production fidèle : cloner prod sans embarquer les risques (données, paiements, mails)
4. Plan de tests : fonctionnel, régression, SEO, perf, sécurité (avant ET après)
5. Exécuter la mise à jour : fenêtre, séquence, gel des écritures, rollback réel
6. Stabilisation post-update : observabilité, erreurs silencieuses, et dérives de performance

Une mise à jour PrestaShop n’est pas un “clic dans le back-office”. C’est une opération à périmètre variable (core, thème, modules, PHP, SGBD, reverse proxy, cache) qui casse le plus souvent aux mêmes endroits : compatibilité modules, overrides, templates, règles SEO, et effets de bord sur la perf (OPcache, cache Symfony, index de recherche, facettes).

Sur le terrain, ce qui fait échouer un upgrade n’est pas “PrestaShop” au sens strict : c’est l’écosystème réel d’une boutique (modules paiement/livraison, surcharges accumulées, thème non maintenu, jobs cron, intégrations ERP, tuning PHP/MySQL, CDN/WAF). Traitez donc la mise à jour comme une mise en production complète : périmètre, risques, plan de tests, fenêtre, rollback, puis stabilisation.

Cadrer la mise à jour PrestaShop : ce qu’on met à jour (et ce qu’on ne peut pas ignorer)

Commencez par figer un périmètre technique explicite : version source → version cible (ex. 8.1.x → 9.1/9.2), PHP (8.1/8.2/8.3 selon compat), moteur SQL (MySQL vs MariaDB), et stack d’exécution (Apache/FPM, Nginx/FPM, LiteSpeed, ou serveurs applicatifs type FrankenPHP). Dans la pratique, la “mise à jour PrestaShop” échoue rarement sur le core seul ; elle échoue sur l’écosystème (composer deps, modules tiers, surcharges, JS front, thèmes non maintenus).

Avant même de choisir une date, prenez 30 minutes pour documenter noir sur blanc :

• Votre point de départ exact : version PrestaShop, version PHP, SGBD, et comment l’app est déployée (FTP, Git, CI/CD, image Docker).
• Ce qui change en même temps : “upgrade PrestaShop + upgrade PHP + changement de serveur” est un classique… et un multiplicateur de risques. Si vous pouvez, séparez en lots.
• Les modules “tier 0” (paiement, livraison, taxes, recherche, connecteurs marketplace/ERP) : sans eux, la boutique est inutilisable.
• Les points de non-retour : migrations DB non réversibles, changement de thème, refonte d’URLs, bascule CDN/WAF.

Cartographiez les zones à risque avec une matrice simple :

• Core : changements de schéma, compatibilité Twig/services en PrestaShop 9, comportement des contrôleurs, endpoints.
• Modules : hooks manquants, overrides incompatibles, dépendances composer, comportements de checkout/paiement.
• Thème : templates, assets build, compatibilité du “classic” vs custom.
• Infra : versions PHP, extensions (intl, bcmath, gd, redis), droits fichiers, limites mémoire, OPcache.

Pour rendre cette cartographie opérable, vous pouvez la traduire en tableau “actionnable” :

Zone	Comment vérifier vite	Symptôme typique post-upgrade	Action préventive
Modules paiement	version du module + note de compat	paiement absent / erreur API / retour KO	sandbox + test E2E + rollback module
Overrides	inventaire des classes surchargées	fatal error / comportement incohérent	audit des overrides + suppression des obsolètes
Thème	build/front + compat PrestaShop	JS cassé / panier bloqué	build en pré-prod + tests tunnel
SEO	URLs/canonicals/sitemap	404/duplications/baisses de trafic	crawl comparatif + redirections
DB	taille + index + migration	timeouts BO / lenteurs	staging “volumétrique” + slow log

Sur PrestaShop 9, la modernisation progresse (services, Twig, nouveaux contrôleurs) et la compatibilité “legacy” varie selon les modules. Si vous avez des développements spécifiques, lisez aussi : PrestaShop 9 : adapter modules et thèmes aux contrôleurs services et Twig et, côté versions PHP, PrestaShop 9 : versions PHP recommandées et incohérences de documentation. Pour la provenance des sources (éviter un fork piégé, vérifier tags/releases), gardez un œil sur PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks.

Un réflexe utile côté “gouvernance technique” : lire les notes de version avant d’évaluer le coût (et pas après avoir cassé la prod). La page des releases officielles sur GitHub est un bon point d’entrée.

Deux règles opérationnelles : (1) une mise à jour est un changement, donc on la traite comme un déploiement (plan, validation, rollback) ; (2) une mise à jour est souvent le meilleur moment pour rembourser un bout de dette (désactiver overrides obsolètes, migrer un module critique, nettoyer base/cache). Si vous partez d’une boutique “chargée” (gros catalogue, trafic élevé), connectez cette démarche avec vos contraintes perf : PrestaShop performance : optimiser gros catalogues et Core Web Vitals.

Principe de déploiement continu (très concret en e-commerce) : si une opération est douloureuse, c’est souvent parce qu’elle est trop rare. Plus vous updatez rarement, plus la surface de rupture (diff de versions + modules + infra) augmente, et plus votre rollback devient théorique.

Checklist sauvegarde : RPO/RTO, 3-2-1, base, fichiers, secrets (et surtout tests de restauration)

Avant de toucher au moindre fichier, clarifiez deux métriques : RPO (perte de données acceptable) et RTO (temps acceptable pour revenir en service). Une boutique B2C avec paiements en continu n’a pas le même RPO/RTO qu’un site vitrine. Si votre RPO est “0”, un simple mysqldump pris au début de la fenêtre est insuffisant : il vous faut du PITR (Point-In-Time Recovery) via binlogs MySQL/MariaDB ou sauvegarde physique + journaux.

Pour cadrer rapidement (et éviter les discussions “au feeling”), voici un repère souvent réaliste :

Type de boutique	RPO typique	RTO typique	Implication sauvegarde
Petit e-commerce (faible volume commandes)	1–4 h	2–6 h	dump + restauration testée
Boutique active (commandes toute la journée)	15–60 min	1–2 h	dump + binlogs (PITR) ou snapshot
Fort enjeu (trafic élevé, campagnes)	0–15 min	< 1 h	snapshots + PITR + procédure de bascule

Sur MySQL/MariaDB, opposez sauvegarde logique (dump SQL) et sauvegarde physique (snapshot des fichiers InnoDB). Le dump est portable mais lent et parfois instable sur très grosses bases ; la sauvegarde physique (LVM/ZFS snapshot, mariabackup, Percona XtraBackup) est plus adaptée aux gros volumes et à un RTO court. Si vous êtes en train de préparer un changement d’engine ou de collation, lisez : Prérequis système : migration MySQL vers MariaDB, InnoDB et collation UTF-8.

La checklist minimale de sauvegarde opérable (pas “théorique”) :

1) Base de données

• Dump compressé + checksum + horodatage :

DB=prestashop
TS=$(date +%F_%H%M)
mysqldump --single-transaction --routines --triggers --events \
  --set-gtid-purged=OFF \
  -u $MYSQL_USER -p$MYSQL_PWD $DB \
  | gzip -1 > backup_${DB}_${TS}.sql.gz
sha256sum backup_${DB}_${TS}.sql.gz > backup_${DB}_${TS}.sql.gz.sha256

• Si vous visez un rollback “rapide” : snapshot LVM/ZFS du volume contenant /var/lib/mysql (ou équivalent) + export des binlogs sur une durée >= fenêtre.

2) Fichiers applicatifs

• Code + thème + modules + overrides + app/config/parameters.php (ou .env* selon version) + config/settings.inc.php (legacy) + .htaccess/vhosts.
• img/ et download/ (souvent oubliés) et éventuels médias hors docroot.

3) Secrets & intégrations

• Clés API, webhooks, identifiants SMTP, tokens paiement, credentials Redis/Elasticsearch, etc. Si vos secrets sont externalisés (Vault/ESO/K8s), assurez-vous de la reproductibilité. Exemple côté K8s : External Secrets Operator : synchroniser les secrets Kubernetes avec OVHcloud OKMS.

4) Règle 3-2-1 (et chiffrement)

• 3 copies, sur 2 supports, dont 1 hors site (offsite).
• Si vous stockez hors de votre infra (S3/Swift/objet), chiffrez (au repos et/ou avant envoi) et testez la récupération des clés. C’est particulièrement important si vous opérez en contexte RGPD : une sauvegarde est une donnée personnelle au sens opérationnel (elle contient des PII), donc votre politique de rétention et d’accès doit être cohérente.

Le point non négociable : restaurer en pré-prod avec ces sauvegardes, avant la mise à jour. Une sauvegarde non testée n’est qu’un fichier. Un test minimal et rapide consiste à :

• restaurer dans une base “stagingrestoretest” ;
• lancer un mysqlcheck (ou équivalent) ;
• ouvrir le back-office et vérifier au moins : liste commandes, fiche produit, recherche, génération d’images.

Pour cadrer une politique complète (chiffrement, rotation, rétention, offsite), vous pouvez recouper avec : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées.

Pré-production fidèle : cloner prod sans embarquer les risques (données, paiements, mails)

Une pré-production utile n’est pas “un clone qui s’affiche”. C’est un environnement fidèle sur les invariants (versions PHP, extensions, cache, config serveur, cron, workers, CDN/headers), et décorrélé sur les effets externes (paiements réels, emails clients, ERP/WMS, SMS). Dans l’idéal, votre pré-prod est créée via infra-as-code (Terraform/Ansible) ou via images/compose, pas à la main ; sinon vous testez surtout… vos écarts de configuration.

Commencez par reproduire la stack : Redis (sessions/cache), OPcache, et éventuellement Varnish/CDN. Des écarts sur OPcache ou Redis masquent des bugs (cache invalidation, sérialisation, classes manquantes après upgrade).

Ensuite, gérez la donnée. La pré-prod doit être proche en volumétrie (catalogue, commandes, clients) pour exposer les lenteurs SQL, les index manquants, les timeouts et les problèmes de memory limit. En revanche, vous ne devez pas propager des PII en clair si l’accès pré-prod est large (agences, freelances, multiples comptes). Minimum : anonymisation des emails, téléphones, adresses, et neutralisation des jetons. À défaut d’outils internes, faites une post-migration SQL (ex. remplacer @ → +staging@) et supprimez/regenérez les secrets (cookies key, tokens API).

Deux garde-fous simples qui évitent des incidents très “réels” :

• Bloquer l’indexation de la pré-prod (Basic Auth + X-Robots-Tag: noindex, nofollow + robots.txt). L’objectif : éviter que Google indexe des URLs de staging et crée du contenu dupliqué.
• Éviter l’envoi de mails par erreur : même si vous “pensez” avoir désactivé, forcez une redirection SMTP vers un bac à sable.

Profitez-en pour nettoyer ce qui pollue les tests (tables volumineuses de logs, cache, paniers abandonnés) : MedCleanMyShop PrestaShop : nettoyage base de données et fichiers automatisé. Sur certaines boutiques, ce simple nettoyage en staging permet aussi d’anticiper un sujet “surprise” : le temps de migration DB (si vos tables de log font plusieurs Go, le temps de dump/restore explose, et votre RTO n’est plus réaliste).

Enfin, neutralisez les intégrations :

• Paiement : bascule vers environnements sandbox (PSP) + désactivez les callbacks réels.
• Emails : redirigez SMTP vers un serveur de capture (MailHog/Mailpit) ou une règle de réécriture.
• ERP/WMS/TMS : endpoints de test, ou mock (à documenter) ; voir : Portail client : intégration ERP/WMS/TMS via API, fichiers et webhooks.

Sur les shops à fort trafic, la pré-prod doit aussi servir à valider la stratégie de release. Si vous pouvez faire du blue/green (ou au moins un switch DNS/LB), formalisez-le : Migration PrestaShop : audit technique et plan incrémental blue/green.

Plan de tests : fonctionnel, régression, SEO, perf, sécurité (avant ET après)

Une mise à jour PrestaShop sans plan de tests, c’est du hasard. On n’a pas besoin de “tout automatiser”, mais on doit couvrir les flux à risque : navigation catalogue, recherche/facettes, panier, checkout, paiement, création compte, retours, back-office (commandes, stock), exports, et tâches cron. Sur PrestaShop, la régression la plus fréquente vient des modules de paiement et des overrides (méthodes signatures qui changent, classes renommées, injection de dépendances).

Structurez les tests en 3 couches :

• Smoke (5–10 min) : site up, login BO, ajout panier, passage commande (sandbox), page catégorie, page produit, recherche.
• Régression ciblée (30–90 min) : promos, transporteurs, règles taxes, multi-boutique, déclinaisons, import/export, webservice.
• Non-fonctionnel (perf/sécu/SEO) : Lighthouse, erreurs JS, slow queries, scans basiques.

Une façon simple d’éviter les “oublis” : préparer une matrice de tests qui colle à vos revenus (ce qui vend, ce qui encaisse, ce qui expédie). Exemple minimal :

Domaine	Test concret	Ce que vous cherchez	Quand
Paiement	commande sandbox + retour OK	erreurs API, pages blanches, statuts	avant/après
Livraison	calcul frais + transporteur	règles cassées, zones, TVA	avant/après
Promotions	code promo + règle panier	priorités, cumul, arrondis	avant/après
Recherche/facettes	requête + filtre	index non reconstruit, lenteur	après
BO commandes	ouvrir/éditer commande	timeout, erreurs PHP	après
Cron	exécuter jobs clés	imports, stocks, mails, exports	après

Pour le debug côté PHP en pré-prod, gardez un environnement où vous pouvez activer un pas-à-pas sur CLI et web : Xdebug : installer et activer Xdebug 3 pour PHP CLI et web et Xdebug VS Code : configurer le débogage PHP en local. Pour la perf SQL (souvent révélée par une mise à jour qui change des requêtes), activez un slow query log en staging : Requêtes MySQL lentes PrestaShop : activer slow query log.

Côté SEO, ne vous contentez pas de “ça rankera pareil”. Vérifiez :

• génération des URLs (réécriture, trailing slashes, redirections) ;
• canonicals, paginations, facettes et noindex ;
• sitemap et statut HTTP sur un crawl interne (200/301/404/500) ;
• données structurées product/breadcrumb/review ;
• poids images (WebP), et Core Web Vitals.

Un “truc” très efficace (et souvent oublié) : faites une liste des 20 pages SEO les plus importantes (catégories top, produits top, pages marques, pages CMS) et comparez avant/après :

• code HTTP ;
• canonical ;
• meta title/description ;
• présence du balisage schema.org produit ;
• présence (ou absence) d’une redirection.

Les mises à jour peuvent modifier des comportements de modules comme ps_facetedsearch (indexation, URLs à paramètres). Pour cadrer, lisez : Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne et, sur l’indexation/sitemap : Plan de site : optimiser l’indexation Google avec un sitemap clair ainsi que SEO PrestaShop : optimiser fiches produits, schema.org et images WebP.

Enfin, la sécurité : une mise à jour est souvent motivée par un patch. Mais le jour où vous changez de version est aussi le jour où vous introduisez de nouvelles dépendances et où vous “remettez à plat” des configs. Faites au minimum : scan vulnérabilités deps (Composer/NPM), vérification des permissions, test XSS basique, et durcissement WAF si présent (sans casser le checkout). En complément : XSS : checklist de durcissement PrestaShop, CSP et encodage contexte et WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Exécuter la mise à jour : fenêtre, séquence, gel des écritures, rollback réel

La séquence “safe” dépend de votre architecture, mais il y a des invariants : geler les écritures, garantir une sauvegarde “juste avant”, déployer le code, exécuter les migrations, purger/rechauffer les caches, et valider via une checklist post-déploiement. Si vous ne pouvez pas geler (commandes en continu), vous devez au minimum isoler le trafic (maintenance + file d’attente) ou basculer via blue/green.

Pour une boutique en France/Europe, pensez aussi “opérations” : cut-off transporteurs, heures de support PSP, horaires équipe (tech + métier). Une mise à jour “à 23h” sans personne côté métier pour valider le tunnel de commande… finit souvent en stress inutile.

Checklist d’exécution (exemple générique, à adapter PrestaShop 8/9) :

1) Avant la fenêtre

• Désactiver tâches cron qui écrivent (imports, synchro stocks, relances, webhooks).
• Mettre le site en maintenance (ou basculer le LB).
• Dernière sauvegarde DB + snapshot fichiers.
• Exporter un inventaire : liste modules actifs, overrides présents, version PHP/SQL (utile si rollback et support).

2) Déploiement

• Déployer le code (git tag/release) et vendor (composer install en build, pas en prod si possible).
• Mettre à jour modules critiques un par un si nécessaire (paiement, transport, taxes).
• Lancer l’upgrade (outil officiel ou procédure manuelle selon contraintes), et surveiller les logs.

3) Post-déploiement

• Vider cache Symfony/Smarty selon version, vérifier permissions var/.
• Reconstruire index (recherche, facettes) si nécessaire.
• Repasser la checklist smoke + 1 commande de bout en bout (sandbox).
• Réactiver progressivement les crons (pas tout d’un coup), en surveillant erreurs et temps d’exécution.

Le rollback doit être exécutable en moins de 30 minutes sur un shop à enjeu, sinon ce n’est pas un rollback mais un projet. Le pattern le plus fiable reste blue/green + DB versionnée (ou snapshot + restore). Sur PrestaShop 9, avec des migrations DB potentiellement non réversibles, le rollback “code only” est souvent impossible : vous devez restaurer DB + fichiers. Pour formaliser ce plan : Migration PrestaShop 9 : sécurité, tests et plan de rollback.

En pratique, un rollback “réel” se juge à une seule chose : avez-vous un runbook minute par minute ? Exemple de structure (très simple) :

• seuils de déclenchement (ex. paiement KO > 5 min, 500 sur checkout, BO inaccessible) ;
• qui décide (tech + e-commerce) ;
• comment remettre l’ancienne version (bascule LB/DNS ou redeploy) ;
• comment restaurer DB/fichiers ;
• comment valider (smoke test).

Principe de résilience popularisé chez Amazon : tout finit par tomber. L’objectif n’est pas de “ne jamais avoir de problème”, mais de rendre l’échec prévisible, détectable, et réversible.

Stabilisation post-update : observabilité, erreurs silencieuses, et dérives de performance

La majorité des incidents “post mise à jour PrestaShop” ne sont pas des 500 immédiats. Ce sont des erreurs silencieuses : JS cassé sur un tunnel, module paiement qui n’appelle plus un endpoint, panier qui perd une option, règles de taxes incohérentes, ou BO qui timeoute sur une liste. Il vous faut de l’observabilité, pas seulement un uptime check.

Mettez en place (ou renforcez) : logs PHP (FPM), logs PrestaShop, logs JS (Sentry/équivalent), et alertes sur pics d’erreurs.

Sur la perf, surveillez TTFB, taux de cache hit (Varnish/CDN), latence Redis, et temps moyen des requêtes SQL.

Ajoutez une routine de stabilisation (souvent suffisante sur 48–72h) :

• H+1 : vérifier paiement, mails transactionnels, génération facture/avoir, stock.
• J+1 : vérifier exports/imports, webhooks/ERP, tâches cron, pics d’erreurs JS.
• J+2/J+3 : analyser lenteurs BO/front (slow queries), taux de cache, et Core Web Vitals (au moins via un échantillon Lighthouse + monitoring réel si vous en avez).

Enfin, bouclez la mise à jour par une vérification “ops” : purge contrôlée des caches (et pas en continu), réglages OPcache cohérents, et validation de la capacité en charge si vous avez un événement à venir (soldes, campagne, TV). Pour les architectures cache/CDN/Varnish en contrainte forte, recoupez avec : PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé et, si vous êtes sur des stacks alternatives, évaluez la compatibilité et la stabilité (workers, HTTP/3) : FrankenPHP : stabilité des workers et compatibilité PrestaShop en pratique.

Une mise à jour bien menée se termine quand (1) les métriques reviennent à la normale (ou mieux), (2) les erreurs applicatives sont sous contrôle, et (3) vous avez documenté les écarts et le runbook. Si vous devez gérer un incident pendant la stabilisation, gardez une procédure : Sécurité PrestaShop : plan de réponse à incident et containment immédiat.