PrestaShop 9 : guide de migration Symfony 6.4 et PHP 8.3

Table des matières :

1. Périmètre réel d’une migration PrestaShop 9 (Symfony 6.4 LTS + PHP 8.3)
2. Pré-requis d’infrastructure (Debian/Nginx, PHP-FPM 8.3, MariaDB, Redis) avant même de toucher au code
3. Audit de compatibilité : modules, overrides, thème, hooks… et dette PHP 8.x
4. Migration Symfony 6.4 côté back‑office : container, routing, controllers, dépendances Composer
5. Données, caches et jobs : éviter les régressions invisibles (DB, Redis, index, imports)
6. Déploiement sans coupure : staging fidèle, CI/CD, rollback, monitoring
7. Validation post‑migration : perf, sécurité, SEO technique (les trois axes qui coûtent vraiment)

Périmètre réel d’une migration PrestaShop 9 (Symfony 6.4 LTS + PHP 8.3)

Migrer vers PrestaShop 9 n’est pas une « mise à jour PHP » déguisée. Sur un shop existant (souvent 1.7/8.x), vous migrez simultanément un socle d’exécution (PHP 8.3), un framework de back‑office (Symfony 6.4 LTS) et un ensemble de dépendances Composer qui bougent (Mailer, HttpClient, Validator, Twig, etc.). Le résultat pratique : la majorité des incidents post‑migration viennent du code custom (modules/overrides/thèmes) et de l’infrastructure (FPM, opcache, cache FS, droits), pas du core.

Symfony 6.4 étant une LTS, le choix est rationnel pour une base e‑commerce qui doit tenir plusieurs années. La politique de release Symfony est documentée et claire : Symfony publie une version mineure environ tous les 6 mois, et les versions LTS bénéficient d’un support prolongé (correctifs et sécurité) — cf. la documentation officielle (Symfony Release Process). Concrètement : Symfony 6.4 vous évite de « recaler » votre stack back‑office trop souvent, mais impose une vraie discipline sur les dépréciations (sinon, elles deviennent une dette qui explose au prochain saut).

Côté PHP, 8.3 ajoute des évolutions qui ne cassent pas seules un projet, mais amplifient les problèmes déjà présents (typage strict, dépréciations, erreurs fatales mieux exposées). Le calendrier officiel des branches supportées est public (PHP Supported Versions). La conséquence directe : si votre parc d’hébergement reste sur 8.1/8.2, vous risquez d’être coincé entre compatibilité core et compatibilité modules (et de payer la différence en patchs d’urgence).

Sur PrestaShop, le gros point technique n’est pas « Symfony partout ». Le cœur reste hybride (Legacy + Symfony). Vous devez donc traiter deux mondes :

• le legacy (ObjectModel, overrides, hooks, templates historiques),
• le Symfony back‑office (services, controllers, forms, routing, container).

Pour cadrer les changesets côté admin et l’impact des nouveautés, gardez sous la main les articles PrestaShop 9 : nouveautés Symfony 6.4 et PrestaShop 9 : commerce headless.

Pour éviter les surprises, une manière simple de matérialiser le périmètre est de le poser en matrice « composant → risque → symptômes » :

Zone	Ce qui bouge en PrestaShop 9	Risques typiques	Symptômes en prod
PHP 8.3 / extensions	runtime + extensions	fatal errors, dépréciations, extensions manquantes	pages blanches, 500, erreurs intermittentes CLI
Symfony 6.4 (BO)	container, routing, dépendances	services introuvables, routes cassées, twig/forms	BO inaccessible, actions admin qui échouent
Modules / overrides	compatibilité API + typage	signatures, propriétés dynamiques, hooks	checkout cassé, transporteurs/paiements KO
Infra (FPM/opcache/cache/FS)	config + droits + cache	purge cache, pool saturé, opcache thrash	lenteur « aléatoire », pics CPU, 502/504
Données / jobs	schéma implicite, cron, imports	cron qui tape l’ancien path, jobs en double	stock/prix incohérents, imports incomplets

Pré-requis d’infrastructure (Debian/Nginx, PHP-FPM 8.3, MariaDB, Redis) avant même de toucher au code

La migration Symfony 6.4 + PHP 8.3 est d’abord une migration de runtime. Si vous ne maîtrisez pas votre chaîne HTTP (reverse proxy → PHP‑FPM → FS/cache → DB), vous allez diagnostiquer à l’aveugle. Pour une base stable, partez d’une stack explicitement dimensionnée et reproductible (Nginx + PHP‑FPM + MariaDB + Redis), par exemple le guide Serveur dédié PrestaShop : config Nginx PHP-FPM MariaDB Redis et la mise au point sur le flux d’exécution PHP-FPM : comprendre le flux d’exécution avec Nginx et Apache.

Sur PHP‑FPM 8.3, la configuration la plus fréquente qui casse une migration est triviale : limites mémoire trop basses en CLI (composer, cache warmup), timeouts (maxexecutiontime, requestterminatetimeout), et opcache mal calibré. En pratique sur gros catalogue, un opcache sous‑dimensionné produit des chutes de perf « aléatoires » parce que le cache se purge, le CPU repart en compilation, et les temps de réponse s’envolent.

; php.ini (FPM)
memory_limit=512M
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=60000
opcache.validate_timestamps=0
realpath_cache_size=4096K
realpath_cache_ttl=600

Quelques points « terrain » à valider avant même de lancer la migration applicative :

• Extensions PHP : vérifiez très tôt la présence de ce que votre shop utilise réellement (image, intl, zip, mbstring, etc.). Un module d’export peut dépendre de zip, un connecteur ERP de soap, un thème de manipulation images plus agressive (GD/Imagick).
• Séparation des environnements : staging ≠ prod ne doit pas seulement être « une copie de fichiers ». Il faut aussi isoler Redis, les caches, les clés API, et les webhooks (sinon vous notifiez des clients depuis le staging).
• Localisation / conformité : si vous êtes en France/UE, vérifiez la résidence des données et les flux tiers (paiement, emailing, log shipping) au moment où vous changez d’infra. La migration est souvent l’occasion de standardiser (hébergeurs UE, sauvegardes chiffrées, rotation de clés).

Côté base, évitez les migrations « en aveugle » MySQL → MariaDB au même moment que le passage PrestaShop 9 si vous n’avez pas déjà industrialisé vos dumps/restores, collations et encodages. Si vous devez le faire, posez les prérequis proprement (InnoDB, utf8mb4, collation cohérente) avec Prérequis système : migration MySQL vers MariaDB, InnoDB et collation UTF-8. Et si vous avez des lenteurs historiques, capturez un slow query log avant/après (voir PrestaShop MySQL : analyser slow query log et optimiser index).

Checklist infra (rapide, mais efficace) avant de toucher au code :

• [ ] php -v (CLI) = 8.3.x et php-fpm -v = 8.3.x (pas de décalage)
• [ ] mêmes extensions chargées en CLI et FPM (les builds diffèrent souvent)
• [ ] opcache dimensionné + stable (pas de purge fréquente)
• [ ] www-data (ou user FPM) a les droits cohérents sur var/ (cache/log)
• [ ] Redis isolé par environnement (DB index ou instance dédiée)
• [ ] sauvegardes automatisées + restauration testée (sur un serveur « propre »)

Audit de compatibilité : modules, overrides, thème, hooks… et dette PHP 8.x

Avant l’upgrade, faites un inventaire mécanique :

• modules installés + versions + provenance (Addons, interne, agence) ;
• overrides actifs (classes, controllers, templates) ;
• thèmes et surcharges (TPL, JS, build chain) ;
• jobs cron, scripts CLI, webhooks/ERP.

Si vous n’avez pas déjà une checklist de sauvegarde / pré-prod / tests, reprenez Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests et appliquez-la en version « migration majeure » : 2 sauvegardes (FS + DB), 1 restauration testée, et un plan de rollback qui tient en moins de 30 minutes.

Pour rendre l’audit exploitable (et pas seulement « une liste »), marquez chaque module/thème/override avec un statut :

• OK : compatible confirmé (éditeur + test staging),
• À corriger : patch interne/éditeur requis,
• À remplacer : module abandonné / incompatible,
• À supprimer : non utilisé / redondant.

Un tableau simple suffit pour piloter la migration :

Élément	Criticité (paiement/checkout/ops)	Statut	Action	Date limite
Module paiement	Très élevée	À corriger	patch + recette	J-10
Transporteur	Élevée	OK	tests E2E	J-7
Override Product	Moyenne	À remplacer	refacto en module	J-20
Thème	Très élevée	À corriger	compat + perf	J-15

Le point dur côté code PHP 8.3 est rarement « une feature PHP 8.3 ». C’est plutôt :

• usages de propriétés dynamiques (dépréciées),
• signatures incompatibles (types de retour, paramètres),
• count() sur null, strpos() sur non-string, etc.

Le guide officiel PHP rappelle la logique : les erreurs et dépréciations évoluent au fil des versions (PHP Migration guides). Ne négociez pas ce point : passez votre code custom au minimum via PHPStan ou Psalm + une passe Rector ciblée (PHP 8.1→8.3) pour éviter de découvrir ces erreurs en production.

Mini-scénario (classique en e‑commerce) : un module « maison » ajoute à la volée des propriétés à un objet Legacy pour stocker un état de livraison temporaire. En PHP 8.2+, cela génère des dépréciations, et en environnement strict (logs/monitoring), vous vous retrouvez avec un bruit énorme qui masque les vrais problèmes. Exemple typique de rustine temporaire (pas un vrai fix) quand un module dépend d’attributs dynamiques :

#[\AllowDynamicProperties]
class LegacyAdapter {}

Enfin, côté PrestaShop, beaucoup d’intégrations custom passent par les hooks, et les hooks dynamiques sont une source classique d’incompatibilité (regex, noms de templates, priorités). Si votre migration touche au thème ou aux modules front, relisez Hooks PrestaShop : comprendre les hooks dynamiques et les regex et verrouillez une matrice « hook → module → template » avant de changer quoi que ce soit.

Astuce anti-régression : sur staging, faites une passe « désactivation contrôlée » des overrides non indispensables. Beaucoup de migrations ratent parce qu’un override historique masque une évolution du core : vous “réparez” alors un symptôme, pas la cause.

Migration Symfony 6.4 côté back‑office : container, routing, controllers, dépendances Composer

Symfony 6.4 pousse plus loin l’usage d’attributs PHP et la standardisation du container (autowiring/autoconfigure). Si vous avez des modules qui injectent des services Symfony (ou des contrôleurs admin custom), vous devez vérifier 3 points :

1) la définition des services (YAML/XML/PHP) et les IDs utilisés ;
2) l’autoload Composer (PSR‑4, classmap, files) ;
3) le routing (annotations historiques vs attributs).

Dans Symfony, l’upgrade guide insiste sur la gestion des dépréciations comme mécanisme de migration (Symfony Upgrading). En pratique, sur un module, votre cible est de zéro dépréciation Symfony (en environnement dev/staging) avant de packager pour prod, sinon vous « empilez » des changements à faire plus tard.

Deux leviers concrets qui évitent des heures de debug :

• Tracer les dépréciations en CI : Symfony fournit un mécanisme standard (variable SYMFONY_DEPRECATIONS_HELPER) pour rendre les dépréciations bloquantes pendant les tests. Cela force une migration propre au lieu d’une migration “à l’instinct”.
• Valider les services au boot : un module qui déclare mal un service peut ne casser que certaines pages BO. Sur staging, ouvrez systématiquement les écrans critiques (Commandes, Produits, Transporteurs, Modules) et surveillez var/log/*.

Composer devient non négociable : vous devez figer un composer.lock en pré‑prod, installer en prod avec --no-dev, et aligner la plateforme PHP (sinon vous installez des libs compatibles 8.2 mais pas 8.3). Exemple de routine safe :

# en build / CI
composer validate --strict
composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
php -v
php bin/console cache:clear --no-warmup
php bin/console cache:warmup

Pour éviter les « works on my machine », ajoutez aussi une règle simple : même version de Composer en CI et sur la machine de build (les résolutions peuvent diverger, surtout sur des contraintes permissives).

Enfin, attention au cas particulier du mail : PrestaShop 9 bascule sur Symfony Mailer (fin de SwiftMailer). Si vous aviez des modules qui s’accrochent au transport Swift, vous aurez des envois intermittents ou silencieusement cassés. Le guide dédié existe : PrestaShop 9.0 : migration Swift Mailer vers Symfony Mailer.

Traitez l’email comme un sous‑projet testable, avec une recette minimale :

• [ ] envoi de mail transactionnel (création compte, commande, reset password)
• [ ] validation SMTP (auth, TLS, ports, timeouts)
• [ ] vérification de la délivrabilité (SPF/DKIM/DMARC côté domaine si vous changez de fournisseur)
• [ ] contrôle des logs (erreurs silencieuses = danger)

Données, caches et jobs : éviter les régressions invisibles (DB, Redis, index, imports)

Une migration PrestaShop 9 rate rarement parce que la DB « ne migre pas ». Elle rate parce que des régressions silencieuses s’installent : caches incohérents, index manquants, jobs cron qui tournent sur l’ancien path, ou scripts d’import qui dépendent d’un schéma implicite. Si vous faites des automatisations côté DB (triggers, cohérence), revalidez-les explicitement après migration (voir Triggers MySQL : automatiser la cohérence des données en production).

Côté cache, PrestaShop reste un mix Smarty/legacy + services Symfony + éventuellement Redis. C’est un terrain de bugs de prod : un cache filesystem non nettoyé sur un déploiement bleu/vert, un Redis partagé entre environnements, ou des namespaces qui se télescopent.

Bonnes pratiques simples (et très rentables) :

• Redis : isolez staging/prod (instance dédiée ou DB index dédié) et utilisez un préfixe clair par environnement.
• Déploiement : purgez/renouvelez les caches de manière déterministe (évitez les purges manuelles « au cas où »).
• Warmup : après déploiement, faites un warmup contrôlé (back‑office + front) pour éviter que les premiers vrais clients paient le coût de compilation/cache.

Si vous cherchez un rappel des leviers côté front (Smarty, CCC, CDN), gardez PrestaShop : optimiser performance via cache Smarty, CCC et CDN comme baseline — mais ne mélangez pas optimisation perf et migration le même jour.

Pour les gros catalogues, un scénario classique est l’import qui saturait déjà le serveur et qui devient instable après passage en PHP 8.3 (consommation mémoire différente, exceptions plus strictes, extensions manquantes). Si vous avez industrialisé un pipeline d’import, refaites un run complet en staging en mesurant : durée, pic mémoire, erreurs, timeouts HTTP/CLI. Voir Import catalogue PrestaShop : pipeline API-first automatisé et supervisé pour cadrer l’observabilité (idempotence, reprises, alerting).

Checklist jobs & intégrations (souvent oubliée) :

• [ ] crons système (chemins PHP, chemins projet, utilisateurs, flock)
• [ ] webhooks sortants (ERP, OMS, emailing) : endpoints, tokens, IP allowlist
• [ ] imports/exports : permissions FS, encodages, tailles max, timeouts
• [ ] tâches “métier” : relances panier, flux marketplace, synchro stocks

Déploiement sans coupure : staging fidèle, CI/CD, rollback, monitoring

La seule façon propre de migrer PrestaShop 9 en production est de rendre la migration rejouable. Ça commence par un staging réellement fidèle : même version OS, même PHP‑FPM, mêmes extensions, même config Nginx, mêmes volumes (ou un clone), mêmes variables d’environnement. Si vous ne l’avez pas, construisez‑le (au minimum) via Docker : Staging PrestaShop : créer un environnement Docker fidèle à la production.

Sur la stratégie « sans coupure », vous avez deux patterns sérieux :

• blue/green (deux stacks, bascule DNS/LB, rollback immédiat) ;
• maintenance courte (verrouillage checkout + sync DB + purge cache + warmup).

Si vous avez déjà un process documenté, alignez‑vous sur Migration PrestaShop 1.6/1.7/8 vers PrestaShop 9 sans coupure, et ajoutez des garde‑fous Symfony : warmup du cache, compilation du container, et smoke tests bin/console avant d’ouvrir le trafic.

Un déroulé opérationnel (minimal, mais robuste) en maintenance courte :

1. mettre le shop en mode maintenance (bloquer checkout si possible)
2. snapshot DB + snapshot FS (ou sauvegarde incrémentale + vérification)
3. déployer le nouveau code + vendors (immutable si possible)
4. purge ciblée des caches + warmup
5. smoke tests : BO + checkout + paiement + mails
6. remise en ligne
7. monitoring renforcé (au moins 2 heures) + fenêtre de rollback prête

Le monitoring doit être prêt avant la bascule. En 2026, il n’y a aucune excuse : vous mettez Netdata ou Prometheus, vous tracez erreurs 5xx, temps de réponse, saturation FPM, latence DB, hit ratio opcache, et vous alertez. Références internes : Netdata : activer et configurer les collectors et Prometheus : configuration des alertes. Une migration réussie, c’est une migration où vous voyez l’incident avant que vos clients le voient.

Validation post‑migration : perf, sécurité, SEO technique (les trois axes qui coûtent vraiment)

Après bascule, les tests « ça charge » ne suffisent pas. Mesurez la perf utile : TTFB, temps de génération page, temps checkout, latence DB, et comportement sous concurrence (burst). Si vous êtes sur stack LiteSpeed/LSAPI, les optimisations spécifiques existent, mais elles ne remplacent pas une validation fonctionnelle (voir Performance PHP LiteSpeed : optimiser LSAPI, cache opcode et concurrence). Sur Nginx/FPM, votre boussole reste le pool sizing et l’opcache.

Validation perf (pratique) : faites un comparatif avant/après sur un même scénario (page catégorie, page produit, ajout panier, checkout). L’objectif n’est pas d’être « plus rapide » immédiatement, mais d’être stable (pas de pics) et de ne pas dégrader le checkout.

Sécurité : Symfony 6.4 vous apporte des composants modernes, mais PrestaShop reste exposé via modules et surface legacy. Faites au minimum un audit des headers, des permissions FS, des accès admin, des endpoints API, et une revue des dépendances. Pour cadrer la partie CI/CD et durcissement, référez‑vous à PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD et, côté serveur, à Symfony : sécuriser un serveur PHP avec hardening et gestion CVE. Le point non négociable : vous devez pouvoir répondre « quelles versions exactes de libs tournent en prod ? ».

SEO technique : une migration casse surtout via des détails (canonical, pagination, facettes, performances, erreurs 404/500, redirections). Rejouez une checklist d’indexation et d’accessibilité, et comparez vos logs avant/après (status codes, volumétrie crawl, temps de réponse). Pour la méthode : SEO PrestaShop : checklist technique 2025 pour indexation et performance et, si vous avez du faceted search agressif, Budget de crawl PrestaShop. Si vous changez aussi l’infra TLS, refaites un audit HTTPS complet (HTTPS : bonnes pratiques et audit).

Si votre migration implique aussi des changements d’URL (réécritures, règles Nginx, refonte de catégories), gardez en référence la documentation Google sur les migrations de site et la gestion des redirections : Site move with URL changes — Google Developers.

Enfin, côté exploitation, la migration PrestaShop 9 vers Symfony 6.4 et PHP 8.3 n’est pas un « point final ». C’est un nouveau cycle de maintenance : patchs de sécurité, updates modules, surveillance logs, et test régulier de restauration. Si vous devez formaliser ce périmètre côté run, l’article PrestaShop maintenance : tarifs, niveaux de service et périmètre est utile comme référentiel de ce qui doit exister (même si vous l’opérez en interne).