Migration PrestaShop 9 : checklist complète sécurité, SEO, performance

Table des matières :

1. Périmètre d’une migration PrestaShop 9 : ce qui change vraiment (et ce qui casse)
2. Préflight infra et prérequis système : PHP, extensions, DB, filesystem
3. Inventaire code & modules : compatibilité, overrides, CI de validation
4. Sécurité : durcissement, secrets, WAF, headers, sauvegardes chiffrées
5. SEO : cartographie d’URL, redirections 301, contenu, données structurées
6. Performance : baseline, profiling, caches multi-niveaux, SQL, recherche
7. Bascule contrôlée : tests, go-live, rollback, monitoring post-migration

Périmètre d’une migration PrestaShop 9 : ce qui change vraiment (et ce qui casse)

Une migration PrestaShop 9 n’est pas un “simple update” : c’est un changement d’exécution (versions PHP, dépendances Symfony), de conventions (services, routes, overrides), et souvent de surface d’attaque (API, back-office modernisé). Le piège classique consiste à ne regarder que le front et à découvrir après coup que le back-office, les jobs cron, les webservices, ou l’index de recherche ne suivent plus.

PrestaShop 9 renforce l’alignement avec l’écosystème Symfony et son outillage. Ça a un impact direct sur les modules qui bricolent des contrôleurs legacy, sur les overrides non maîtrisés, et sur les intégrations “à la volée” (scripts qui appellent init.php depuis un répertoire exposé). Si votre code dépend de comportements non contractuels du core, une migration devient un projet de refactor.

Pour cadrer ce qui change “vraiment”, pensez en “surfaces” plutôt qu’en pages :

• Front-office : thème, JS/CSS, surcharge de templates, compatibilité des modules d’affichage (avis, cross-sell, tracking).
• Back-office : parcours opérateurs (création produit, commandes, avoirs), rôles/permissions, modules de gestion (export, SAV).
• Flux & intégrations : ERP, PIM, transporteurs (ex. Colissimo/Mondial Relay), PSP (ex. PayPlug/Stripe), webhooks, import/export, connecteurs marketplace.
• Opérations : crons, indexation recherche, caches, logs, supervision, jobs “hors PrestaShop” (scripts maison, ETL).

Mini-scénario réaliste : vous avez un script d’import nocturne posé dans /import/ qui fait un require('../config/config.inc.php') et appelle un contrôleur legacy. Le jour de la bascule, le script tourne encore… mais il déclenche des erreurs fatales (autoload, droits, dépendances) ou expose des endpoints sensibles. Résultat : import cassé + dérive stock/prix, alors que le front semble “OK”.

Le point de départ rationnel est de découper le chantier en trois axes, chacun avec ses critères de succès : sécurité (pas de régression, surface minimisée, secrets gérés), SEO (0 perte d’URL indexées stratégiques + redirections propres), performance (TTFB stable ou en baisse, CPU/IO maîtrisés, latence DB sous contrôle). Pour cadrer la partie rollback et tests, vous pouvez vous appuyer sur la démarche déjà détaillée dans l’article : Migration PrestaShop 9 : sécurité, tests et plan de rollback.

Préflight infra et prérequis système : PHP, extensions, DB, filesystem

La première checklist est bêtement “système”, mais elle évite 80% des migrations ratées : la prod doit pouvoir exécuter PrestaShop 9 dans des conditions strictement identiques à votre staging (mêmes versions, mêmes extensions, même configuration PHP-FPM/LSAPI, mêmes limites OS). En juillet 2026, les écarts PHP 8.2 vs 8.3, ou des extensions manquantes (bcmath, intl, gd, opcache) sont encore des causes de comportements divergents (validation, génération PDF, calculs, etc.). Les détails de compatibilité et de prérequis sont à recouper avec : Exigences système : compatibilités PHP, MariaDB et Elasticsearch minimales et Exigences système : prérequis mod_rewrite, bcmath et GeoIP nouveau format.

Sur la base de données, n’êtes pas “MySQL compatible” parce que ça démarre : vous devez prouver que le schéma, les index, et les requêtes passent avec un coût acceptable. Activez un slow_query_log sur votre clone de prod et profilez les routes critiques (catégorie, recherche, panier, checkout) : Requêtes MySQL lentes PrestaShop : activer slow query log et, côté optimisation, Développeur MySQL : optimiser requêtes, schémas et performances en production. Si vous migrez aussi d’hébergement, verrouillez le couple stockage+IO (NVMe vs SATA), sinon vous comparez des métriques non comparables.

Points DB à ne pas laisser “par défaut” (surtout si vous changez de serveur ou de distribution MariaDB/MySQL) :

• Collation/charset : cohérence utf8mb4 partout (tables historiques, tables modules, tables de recherche).
• Modes SQL : le sql_mode peut faire émerger des insert/update auparavant “tolérés” (valeurs invalides, dates).
• Time zone : utile pour les exports, logs, et certains connecteurs (PIM/ERP). Vérifiez @@time_zone.
• Taille des index et champs : certains modules créent des index trop longs si le charset change.

Enfin, la couche runtime PHP est un multiplicateur de perf ou un frein : OPcache correctement dimensionné, gestion du cache applicatif (Redis/Memcached), et éventuellement Varnish/CDN en amont. Les paramètres OPcache et la surveillance des files d’attente côté serveur (LiteSpeed/LSAPI, PHP-FPM) doivent être vérifiés avant la bascule, pas après : OPcache PHP : activer et vérifier l’extension dans cPanel et Performances PHP LiteSpeed : cache opcode, LSAPI et suivi WaitQ.

Checklist infra (à valider en staging puis re-valider en prod) :

• Versions : PHP, MariaDB/MySQL, moteur web (Apache/Nginx/LiteSpeed), OpenSSL, libc.
• Extensions PHP : opcache, intl, gd/imagick, curl, mbstring, bcmath, zip.
• Modes : display_errors=0 en prod, limites mémoire réalistes, max_execution_time adapté aux imports.
• Filesystem : droits, open_basedir si utilisé, stockage des logs hors webroot.
• Cache : OPcache + cache objet (Redis) + cache HTTP (Varnish) si présent.

Ajout utile (très concret) : faites une “photo” de staging et de prod, pour comparer.

php -v
php -m | sort
php -i | egrep -i "memory_limit|max_execution_time|opcache.enable|opcache.memory_consumption|date.timezone"
mysql --version

Objectif : éviter le cas classique où un staging “passe” parce que memory_limit=1024M, mais la prod “casse” à 256M sur un rebuild d’index ou une génération PDF.

Inventaire code & modules : compatibilité, overrides, CI de validation

La migration échoue rarement “à cause de PrestaShop”, mais plutôt à cause de votre périphérie : modules qui patchent le core, overrides en cascade, thèmes non maintenus, et scripts métiers qui dépendent d’un comportement legacy. Avant toute tentative d’upgrade, faites un inventaire exhaustif : liste des modules, versions, origine (Marketplace vs private), dépendances Composer, et tables SQL créées. La checklist dédiée est déjà cadrée ici : Compatibilité modules PrestaShop 9 : checklist avant migration sécurisée.

Pour transformer l’inventaire en décisions, une grille simple (et actionnable) évite les débats sans fin :

Élément	Criticité business	Compat PS9	Risque (override / patch core)	Plan
Module paiement	Haute	À vérifier	Moyen	Mise à jour + tests PSP
Module transport	Haute	À vérifier	Faible	Mise à jour + tests étiquettes
Module SEO	Moyenne	À vérifier	Élevé	Remplacer ou refactor
Module interne	Variable	N/A	Variable	Refactor + CI + doc

L’idée : rendre visible ce qui peut bloquer le go-live (paiement, stock, transport, TVA, factures), surtout dans un contexte France/UE où la facturation, la TVA, et la conformité peuvent dépendre de modules (et où une régression peut coûter très cher en support et en avoirs).

Les overrides sont le point noir historique : ils donnent l’illusion d’une extension “simple” mais créent des collisions silencieuses au moment où le core évolue. Priorité : détecter et réduire. Un premier scan basique (à adapter selon votre arborescence) :

# Sur un clone du projet
find override -type f -name '*.php' -print
# Repérer les classes surchargées le plus souvent
grep -R "class .* extends" -n override | head

Ensuite, basculez ce qui peut l’être vers des hooks/services. Pour retrouver des points d’extension propres côté PS9, l’article Hooks PrestaShop : rechercher et identifier les hooks dynamiques est un bon point d’entrée, et pour la structure Symfony des modules PS9 : Module PrestaShop 9 : structure, services et bonnes pratiques Symfony.

Un test très “rentable” en staging : désactiver temporairement les overrides non indispensables (ou les neutraliser sur une branche) et comparer :

• stabilité BO (création commande, création produit, avoir),
• stabilité FO (panier, comptes, paiement),
• volume d’erreurs dans les logs.

Vous obtenez vite la liste des overrides “toxiques” (ceux qui masquent un comportement legacy cassant) vs ceux qui sont réellement nécessaires.

Dernier verrou : industrialiser la validation. Une migration PS9 sans pipeline CI (lint, tests, build reproductible, scan dépendances) revient à faire du déploiement “à la main” en 2026. Si vous avez une base Git propre, mettez en place un contrôle d’intégrité des modules (provenance, SBOM, validation) : CI PrestaShop : provenance, SBOM et validation automatique des modules et, si vous êtes sur GitHub Actions/BuildKit : Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible.

Sécurité : durcissement, secrets, WAF, headers, sauvegardes chiffrées

Sur une migration PrestaShop 9, la sécurité ne se “rajoute” pas : elle se revalide. Commencez par les bases : rotation des secrets (cookies, tokens), suppression des comptes admin inutiles, contrôle des permissions SQL (compte applicatif non root), et audit des endpoints exposés (webservice, API). Si vous activez/renforcez l’API, traitez la problématique comme un service internet : clés, quotas, journaux, révocation. Référence utile : API : sécuriser apikey, limiter le débit et renforcer la conformité.

Deux points souvent sous-estimés pendant un upgrade :

• Secrets et configuration : évitez que des clés (PSP, SMTP, API) traînent dans un repo, un export, ou un zip de debug. À minima : inventaire, rotation, et séparation “staging vs prod”.
• Back-office : c’est une cible. Après migration, vérifiez les URL BO, le contrôle d’accès, et les comptes (dont ceux des prestataires). Si vous travaillez avec plusieurs intervenants (agence, freelance, infogérance), documentez “qui a accès à quoi” et supprimez les accès non justifiés.

Sur la couche HTTP, imposez des en-têtes de sécurité réalistes (pas un copier-coller destructeur). MDN définit la CSP sans ambiguïté : « Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks » (MDN Web Docs, Content-Security-Policy : https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Une CSP stricte peut casser des modules (scripts inline, tags tiers). Travaillez en mode report-only puis durcissez. Pour une mise en œuvre PHP pragmatique (CSP, HSTS, X-Frame-Options), suivez : HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options.

Astuce opérationnelle : validez vos headers et votre TLS comme un client (pas seulement via un plugin navigateur) :

curl -s -I https://votre-domaine.tld | egrep -i "strict-transport-security|content-security-policy|x-frame-options|x-content-type-options|referrer-policy"

Enfin, protégez-vous des faux positifs qui tuent le checkout. Un WAF mal réglé bloque les add-to-cart, les webhooks PSP, ou la validation d’adresses. La bonne approche est de corréler règles WAF, logs applicatifs, et patterns de trafic légitime : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout. Et côté opérations, ne migrez jamais sans sauvegardes testées (restauration prouvée, chiffrage au repos), cf. Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées.

Checklist sécurité “migration” (rapide, mais utile) :

• Rotation des clés (cookie, webservice/API, tokens modules sensibles).
• Revue des comptes BO : suppression/rotation, privilèges minimaux, logs d’accès.
• Revue des droits DB : compte applicatif limité, pas de privilèges d’admin.
• Headers en mode progressif : CSP report-only → CSP enforcing.
• Sauvegardes : chiffrement + test de restauration documenté (fichiers + DB).

SEO : cartographie d’URL, redirections 301, contenu, données structurées

Le SEO sur une migration PrestaShop 9 se joue sur un artefact : la cartographie d’URL. Si vous ne savez pas exactement quelles URLs existent, lesquelles convertissent, lesquelles sont indexées, vous ne pouvez pas garantir une bascule propre. Travaillez à partir de trois sources : crawl (Screaming Frog / équivalent), exports PrestaShop (liens produits/catégories/CMS), et logs serveur (URLs réellement demandées). Pour la partie “méthode + mapping + 301”, l’approche est similaire à celle décrite ici (même si la cible n’est pas PS9) : Migration PrestaShop WooCommerce : redirections 301 et cartographie d’URL SEO.

Pour que ce travail soit exploitable le jour J, votre mapping doit contenir au minimum :

• ancienne URL,
• nouvelle URL (ou statut : supprimée / fusionnée),
• type (produit/catégorie/CMS/filtre),
• priorité (trafic, conversions, backlinks),
• règle (exact match vs pattern) et responsable de validation.

Les redirections doivent être “RFC-compliant” et testables. Le RFC 9110 (HTTP Semantics) est clair : « The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. » (RFC 9110, section 15.4.2 : https://www.rfc-editor.org/rfc/rfc9110). Concrètement : 301 pour les URLs définitivement déplacées, pas de chaînes de redirections, et un statut HTTP visible dans les logs et via curl -I.

PrestaShop ajoute sa couche de complexité via la génération d’URL (legacy + routes Symfony). Si vos règles SEO (slug, réécriture) changent en PS9, vérifiez comment les liens sont produits pour éviter les surprises et les canoniques incohérents : Génération d’URL PrestaShop : Link, routes Symfony et legacylink. Ensuite, revalidez la couche contenu : pages vides, Hn cassés, templates qui retirent du texte utile. Deux méthodes complémentaires : Audit SEO technique : contrôle qualité avant publication des pages web et Page vide : méthodologie d’analyse SEO et reprise éditoriale structurée.

À ne pas oublier sur une boutique FR/UE multilingue : cohérence des hreflang, des sélecteurs de langue/devise, et des URLs par langue. Une migration qui “réécrit” les chemins (ex. /fr/ vs /) peut faire apparaître des duplications si les canonicals ne sont pas maîtrisés.

Exemple minimal de validation des redirections (à automatiser) :

# Vérifier une liste d'URLs critiques
while read -r url; do
  echo "\n== $url ==";
  curl -s -I "$url" | egrep -i 'HTTP/|location:';
done < urls_critiques.txt

Enfin, pensez “données structurées” de façon pragmatique : si votre thème ou module change, re-testez Product, Breadcrumb, Organization (et éventuellement FAQ si vous l’utilisez). Une régression ici ne “casse” pas le site, mais peut impacter l’affichage dans les résultats de recherche.

Performance : baseline, profiling, caches multi-niveaux, SQL, recherche

Une migration PrestaShop 9 est un moment idéal pour sortir des impressions et poser une baseline. Mesurez avant/après : TTFB, LCP, taux d’erreurs 5xx, et temps moyen de requêtes SQL sur les routes clés. Pour cadrer LCP, web.dev le définit précisément : « Largest Contentful Paint (LCP) reports the render time of the largest image or text block visible within the viewport » (web.dev, LCP : https://web.dev/lcp/). Ça vous donne une métrique front corrélée à l’expérience, à confronter au back (TTFB, CPU, IO).

Une baseline utile tient sur une page (et sert ensuite de garde-fou) :

• Front : LCP, CLS, poids page, nombre de requêtes, cache headers sur assets.
• Back : TTFB, temps PHP, temps SQL, taux de cache hit (Redis/Varnish si présents).
• Stabilité : 4xx/5xx, erreurs JS (checkout), erreurs PHP fatales, saturation (CPU/IO/WaitQ).

Côté back, ne devinez pas : profilez. Si vous avez de la dette Symfony, la mesure (Blackfire, flamegraphs, comparaisons) permet de prioriser les fixes rentables : Dette technique Symfony : profiling Blackfire et refactoring mesurable et, dans PrestaShop lui-même, PrestaShop debug profiling : activer et analyser performances SQL. Objectif : identifier les N+1, les requêtes sans index, et les modules qui font du “work” sur chaque page (hooks globaux).

Ensuite, appliquez une stratégie de cache multi-niveaux cohérente : OPcache (bytecode), cache objet (Redis), cache HTTP (Varnish), cache CDN (assets). Le cœur PrestaShop ne vous “offre” pas une architecture cache parfaite, il faut la configurer et la tester (hit ratio, invalidation). Pour la synthèse et les choix : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur et, si vous partez sur Redis : Redis PrestaShop : configurer le cache sur VPS ou serveur dédié.

Point “terrain” : le cache ne sert à rien si l’invalidation est mal comprise. Sur une boutique avec beaucoup de mises à jour (prix, stocks), préférez des purges ciblées et mesurez le hit ratio, sinon vous payez le coût du cache… sans bénéficier de ses gains.

Enfin, n’oubliez pas la recherche interne : index, pondérations, temps de réponse et impact conversion. Comprendre les tables et pondérations vous évite de “réparer au hasard” : Index de recherche PrestaShop : fonctionnement, tables SQL et pondérations.

Bascule contrôlée : tests, go-live, rollback, monitoring post-migration

La bascule ne se joue pas le jour J : elle se prépare avec un staging clone de prod (données anonymisées si nécessaire), un plan de tests reproductible, et un plan de retour arrière qui ne dépend pas de “on verra”. Si vous n’avez pas de checklist tunnel/checkout, utilisez une liste structurée et exécutable : Contrôle PrestaShop post-modification : checklist tunnel de commande et règles panier. Ajoutez des tests d’intégrations (PSP, ERP, transporteurs) et des tests de mails (DNS, SPF/DKIM si vous gérez l’envoi).

Si vous changez d’infrastructure (ou même de reverse proxy), ajoutez un point souvent oublié : DNS et certificats.

• Baissez le TTL DNS (ex. 300s) 24–48h avant si vous changez d’IP.
• Vérifiez le certificat TLS (chaîne complète, renouvellement, redirections HTTP→HTTPS).
• Validez le comportement “avec” et “sans” www (et la cohérence des canonicals).

La partie opérationnelle doit être scriptée : mise en maintenance, backup, migration DB, déploiement du code, warmup caches, purge CDN si nécessaire, revalidation robots/sitemaps, et ouverture progressive. Et si votre plateforme est dimensionnée pour des pics, testez la haute charge avant, pas après : PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé.

Après migration, le monitoring devient votre filet de sécurité. Logguez PHP, JS, MySQL, et mettez des alertes sur les métriques “qui comptent” (erreurs checkout, 5xx, latence DB, saturation file descriptors). Vous avez des guides pratiques pour instrumenter : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et pour bâtir des tableaux de bord/alerting : Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes. En cas de dégradation, ne restez pas au niveau applicatif : une migration peut faire remonter une limite OS (FDs, backlog) et déclencher des 503, à diagnostiquer proprement : Erreur HTTP 503 : diagnostic serveur, logs et ressources.

Checklist go-live (version courte, mais exécutable) :

• Freeze contenu + modules, tag Git, artefact buildé.
• Backup DB + fichiers + test restauration (au moins en staging).
• Déploiement en maintenance + exécution migrations/upgrade.
• Warm caches (OPcache, Redis, Varnish) + purge ciblée.
• Validation SEO : 200/301/404 sur top URLs + sitemap + robots.
• Smoke tests : recherche, panier, checkout, paiement, emails, webhooks.
• Monitoring renforcé 24–72h : erreurs, latence, conversion, indexation.

---