Table des matières :
- Figer l’état initial avant de toucher à la migration (versions, périmètre, risques)
- Audit thème : templates Smarty/Twig, assets, compat front et dette CSS/JS
- Audit modules : compat PHP 8.3, Symfony 6.4, schéma DB, sécurité et dépendances
- Audit hooks : mapping DB hook_module, hooks dynamiques, ordre d’exécution et régressions
- Audit overrides : inventaire, collisions, stratégie de suppression/remplacement (PS9)
- Croiser thème + modules + hooks : matrice d’impact et tests ciblés (pas “testons tout”)
- Checklist d’audit “migration PrestaShop” (opérationnelle, orientée remédiation)
Figer l’état initial avant de toucher à la migration (versions, périmètre, risques)
Une migration PrestaShop qui part sans inventaire finira presque toujours en chasse aux régressions : le cœur a bougé, vos modules ont des hypothèses implicites, et votre thème masque des dettes techniques. Visez un état “gelé” reproductible : version PrestaShop exacte, version PHP, extensions, configuration serveur, et surtout liste exhaustive des composants qui modifient le rendu ou le comportement (thème, modules, hooks, overrides). Sur PrestaShop 8.x/9.x, la variance la plus coûteuse en temps n’est pas le core, c’est l’écosystème installé.
Contexte de référence pour la suite : cible PrestaShop 9.1/9.2 (pile Symfony 6.4) avec PHP 8.3 (compatibilité couramment visée dans les projets 2026). Adaptez si vous migrez vers 8.1/8.2, mais gardez en tête que les incompatibilités PHP (types, warnings, libs) se payent au runtime, souvent en prod si vous n’avez pas de pipeline de tests. Pour le cadrage technique global de la montée vers PS9 (Symfony 6.4, PHP 8.3), voir l’article interne : PrestaShop 9 : guide de migration Symfony 6.4 et PHP 8.3.
Pré-requis non négociables : snapshot DB + fichiers, staging fidèle, et journalisation activable (Monolog / logs PHP-FPM / Nginx) sans redéployer. Ne sous-estimez pas le risque de manipuler la base : une migration implique souvent des scripts d’upgrade et des modules qui “patchent” le schéma. Si vous n’avez pas de discipline backup/restore, commencez par là (et documentez un rollback). Côté infra, avoir une stack reproductible (Docker/compose ou images) réduit mécaniquement les “ça marche sur mon serveur” ; cf. Staging PrestaShop : créer un environnement Docker fidèle à la production.
Deux points “terrain” (souvent oubliés) à figer dès J0, surtout dans un contexte France/UE :
- Paramètres fiscaux : règles TVA, arrondis, écotaxes, prix affichés TTC/HT, et comportements B2B (numéro de TVA intracom, exonérations). Une montée de version + modules de paiement peut changer la manière dont les totaux sont recalculés.
- Contraintes légales et parcours : gestion du consentement (bannières, tags), mentions sur le checkout (CGV, RGPD), double opt-in si utilisé. Même si ce n’est pas “dans le core”, ce sont des régressions très visibles.
Commandes et requêtes utiles pour figer l’état :
php -v
php -m
# si composer est utilisé par des modules/une surcouche
composer --version
composer show --direct 2>/dev/null | head
# inventaire fichiers
ls -la themes
ls -la modules | wc -l
find override -type f -name '*.php' 2>/dev/null | wc -l
-- modules installés/enregistrés
SELECT name, version, active
FROM ps_module
ORDER BY active DESC, name;
Ajout pratique : capturez aussi la taille et la “forme” de la base pour anticiper les temps de migration (et les surprises sur staging). Par exemple :
-- volumétrie (MySQL/MariaDB)
SELECT table_name,
ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 20;
Cela vous évite de découvrir trop tard qu’une table de logs (ou un module d’export) représente 60% du poids DB… et que vos scripts d’upgrade “semblent bloqués” alors qu’ils scannent des millions de lignes.
Audit thème : templates Smarty/Twig, assets, compat front et dette CSS/JS
Le thème est votre “surface de contact” : il concentre le plus de modifications invisibles (templates copiés, overrides de templates de modules, scripts legacy). En migration PrestaShop, l’audit thème consiste à cartographier précisément ce qui est surchargé par rapport au thème parent et au core : templates dans themes/<theme>/templates, overrides de modules via themes/<theme>/modules/<module>/..., et fichiers assets (JS/CSS) qui patchent le comportement (checkout, panier, facettes, tracking).
Sur PS8/PS9, un point concret : la multiplication de snippets JS qui hookent des classes CSS “du core” (ex: .js-cart, .js-product-miniature) casse dès qu’un module ou un thème cible (Hummingbird, modernisation FO) change les sélecteurs. Votre audit doit donc détecter :
- les scripts qui utilisent des sélecteurs fragiles (querySelector sur classes non contractuelles),
- les dépendances à jQuery (présence, versions, plugins),
- les surcharges de templates de modules stratégiques (paiement, livraison, recherche, facettes).
Un audit efficace n’est pas “lire le CSS”, c’est mesurer l’impact. Sortez des métriques : nombre de templates surchargés, poids des bundles, nombre de requêtes, et TTFB/INP/LCP sur les pages clés (home, catégorie, produit, panier, checkout). Si vous cherchez une base méthodo perf côté PrestaShop (cache natif, CCC, Smarty, CDN), vous pouvez chaîner avec PrestaShop : optimiser performance via cache Smarty, CCC et CDN et, côté réseau, CDN 2026 : critères techniques pour choisir le meilleur fournisseur.
À ce stade, gardez en tête l’évolution des indicateurs web : INP (Interaction to Next Paint) est devenu un Core Web Vital à la place de FID (Google Search Central, 2024). Concrètement, si votre checkout dépend d’un JS “historique” (plugins jQuery, handlers globaux, gros bundles), une migration qui modifie l’ordre de chargement peut dégrader l’INP sans casser “fonctionnellement”.
Mini-scenario typique (et coûteux) : après migration, le panier fonctionne mais le clic “Ajouter au panier” semble parfois “ne rien faire” sur mobile. En réalité, un script tiers de tracking intercepte l’événement, se charge plus tard, et bloque le thread principal. Sans mesure (Lighthouse/WebPageTest + observabilité JS), vous perdez des heures à chercher un bug back.
Un moyen simple d’objectiver l’état initial est de compiler un tableau de “pages cibles” + indicateurs (même si les chiffres varient selon device/réseau, l’important est le delta avant/après) :
| Page | Mesure | Objectif | Remarques d’audit |
|---|---|---|---|
| Accueil | TTFB | stable | cache/redis, modules header |
| Catégorie | LCP | stable | images, facettes, lazyload |
| Produit | INP | stable | scripts “add to cart”, variations |
| Panier | erreurs JS | 0 | hooks display, promos, cross-sell |
| Checkout | taux d’échec | stable | paiement/livraison, conditions |
Checklist thème (fichiers) à automatiser :
THEME=themes/votre_theme
# 1) templates surchargés
find "$THEME/templates" -type f | wc -l
# 2) templates de modules surchargés
find "$THEME/modules" -type f | wc -l
# 3) JS/CSS custom
find "$THEME/assets" -type f \( -name '*.js' -o -name '*.css' -o -name '*.scss' \) | wc -l
# 4) détection de jQuery et plugins
grep -R "jquery" -n "$THEME/assets" | head
Ajout utile : repérez les surcharges “invisibles” via diff (souvent, un fichier copié depuis PS 1.7 n’a jamais été remis à jour). Si votre thème est versionné dans Git, faites un git blame/git log sur les templates checkout et panier : un fichier non touché depuis 3–4 ans est un candidat quasi certain à la régression lors d’une montée majeure.
Audit modules : compat PHP 8.3, Symfony 6.4, schéma DB, sécurité et dépendances
Les modules sont le principal vecteur de rupture lors d’une migration PrestaShop : beaucoup sont “compatibles” au sens marketing, mais pas au sens runtime (warnings PHP 8.3, services Symfony cassés, contrôleurs legacy, appels deprecated). Concrètement, l’audit doit classifier chaque module en : core/native, édité par PrestaShop, tiers, sur-mesure. Les sur-mesure et les modules tiers non maintenus sont à haut risque.
Pour PS9, vous devez vérifier la compatibilité avec l’écosystème Symfony 6.4 (container, autowiring, contrôleurs admin modernisés, routing) et la trajectoire “Admin API” si vous exposez des intégrations. Sur ce sujet précis, l’article interne pertinent est : PrestaShop modules : optimiser la compatibilité Symfony 6.4 et Admin API. Le signal faible à repérer : modules qui touchent à admin*/ en legacy, qui injectent du JS global en BO, ou qui patchent le container sans respecter le chargement par environnement.
Ensuite, traitez le risque “base de données” : modules qui créent des tables, triggers, cron, ou qui stockent des données sérialisées/JSON. Une migration de version + modules est un moment privilégié pour supprimer les modules morts et leurs tables (sinon vous transportez un legacy inutile). Sur la partie hygiene DB + cache, voir Optimisation PrestaShop : nettoyer la base et configurer le cache natif.
Dans un contexte e-commerce FR, faites une attention particulière aux catégories de modules qui “touchent au chiffre” et aux parcours critiques :
- Paiement (CB, wallets, BNPL) : modules qui manipulent l’état de commande, les statuts, ou le callback (webhooks/retours banque). Une incompatibilité PHP peut ne se voir que lors d’un retour asynchrone.
- Transporteurs (Colissimo, Mondial Relay, relais, express) : modules qui injectent des points relais, recalculent le panier, ou modifient les règles de livraison.
- Connecteurs (ERP, PIM, marketplaces) : jobs cron, imports, et synchronisation stock/prix (souvent sensibles aux changements de schéma et aux timeouts).
Audit “dépendances” : identifiez les modules qui embarquent des librairies (vendor, autoload custom) ou qui tirent des packages via Composer. Ce sont des zones de conflit fréquentes (versions de Guzzle, Symfony components, PSR). Un indicateur simple : présence d’un composer.json dans le module, ou d’un dossier vendor/ volumineux.
Enfin, sécurité : l’audit de migration doit inclure une lecture “attaque” des modules exposés (search/facettes, import, endpoints front, webhooks). Exemple : les failles liées à des usages dangereux de unserialize() reviennent périodiquement dans des modules historiques ; cf. Vulnérabilité PrestaShop ps_facetedsearch : analyse RCE via unserialize(). Pour un cadrage plus large de l’audit sécu PrestaShop (SBOM, WAF, CI), voir Audit sécurité PrestaShop : méthodologie, livrables et durcissement et PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.
Référence externe utile (à garder en tête pendant l’audit) :
- OWASP Top 10 (risques applicatifs majeurs, utile pour cadrer uploads, injections, auth, exposition d’API) : OWASP Top 10
Conseil concret : faites une fiche par module “à risque” avec 3 champs obligatoires (sinon vous perdez le fil) :
1) Ce que le module modifie (hooks, overrides, endpoints, BO)
2) Ce qui casse le business si le module casse (paiement, TVA, stock, SEO…)
3) Comment valider (test E2E précis + log attendu)
Audit hooks : mapping DB hook_module, hooks dynamiques, ordre d’exécution et régressions
Dans une migration PrestaShop, le système de hooks est souvent la cause des “bugs fantômes” : rien ne plante, mais un comportement disparaît (tracking, surcharge prix, modifications du panier) parce qu’un hook a changé, qu’un module n’est plus greffé au bon endroit, ou que l’ordre a été modifié. Votre audit doit sortir un inventaire des hooks réellement utilisés (pas juste “disponibles”), et lier chaque hook à ses modules et à l’ordre d’exécution.
Commencez par extraire l’état réel via SQL. C’est la base factuelle qui évite les discussions interminables :
SELECT h.name AS hook,
m.name AS module,
hm.position,
hm.id_shop
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
ORDER BY h.name, hm.position, m.name;
Ajoutez une vue “par module” (utile quand vous cherchez pourquoi un module pèse sur le TTFB ou sur le checkout) :
SELECT m.name AS module,
COUNT(*) AS nb_hooks,
SUM(CASE WHEN h.name IN ('displayHeader','displayTop','displayFooter') THEN 1 ELSE 0 END) AS hooks_structurels
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
GROUP BY m.name
ORDER BY nb_hooks DESC, m.name;
Ensuite, identifiez les hooks “sensibles” (panier, checkout, pricing, stock, paiement, tracking, SEO). En pratique, ce sont ceux qui modifient Cart, Product, Order, Carrier, ou qui injectent du contenu FO/BO. Faites un tri par criticité : un module greffé sur actionProductUpdate ou actionValidateOrder a un risque supérieur à un module greffé sur un hook purement visuel.
Point d’attention multi-boutique : l’audit doit vérifier id_shop (et pas seulement la présence du hook). Un module greffé sur la boutique A mais pas sur la boutique B produit des comportements incohérents (ex : un tracking ou une règle panier active uniquement sur un shop). Lors d’une migration, c’est une source classique de “ça marche sur une boutique mais pas l’autre”.
Dernier point : les hooks dynamiques et leurs regex. Beaucoup d’équipes les découvrent seulement quand un module ne s’exécute pas sur un template précis. Si vous utilisez des hooks dynamiques (ex: variations de displayHeader contextualisées, ou hooks “à la volée” par nom), relisez la mécanique et les implications (matching, fallback) dans : Hooks PrestaShop : comprendre les hooks dynamiques et les regex. En migration, c’est typiquement ce qui casse quand un thème change sa stratégie d’appel de hooks.
Audit overrides : inventaire, collisions, stratégie de suppression/remplacement (PS9)
Les overrides sont un levier puissant… et une dette massive. En migration PrestaShop, ils doivent être traités comme du code critique : ils modifient le comportement du core, peuvent entrer en collision avec un module, et rendent les mises à jour non déterministes. Sur PS9, l’objectif réaliste n’est pas “zéro override” (certaines boutiques legacy en ont besoin), mais zéro override non justifié et zéro override non testé.
Commencez par l’inventaire brut et la détection des collisions. Les collisions les plus courantes : deux modules qui posent un override sur la même classe, ou un override core + un override module. Un inventaire minimaliste :
# overrides core
find override/classes -type f -name '*.php' 2>/dev/null
find override/controllers -type f -name '*.php' 2>/dev/null
# overrides modules
find modules -path '*/override/*' -type f -name '*.php' 2>/dev/null
# classes surchargées
grep -R "class .* extends" -n override 2>/dev/null | head -n 50
Ajout concret : faites une liste “classe → fichiers override” pour repérer les collisions sans inspection manuelle. Par exemple (commande simple, suffisante pour un audit) :
grep -R "class .* extends" -n override 2>/dev/null \
| sed -E 's/.*class ([A-Za-z0-9_]+).*/\1/' \
| sort | uniq -c | sort -nr | head -n 20
Puis, qualifiez chaque override : bugfix core, custom business, perf, workaround module. Les “workarounds” doivent être éliminés en priorité (souvent obsolètes après upgrade). Si vous devez conserver, isolez et testez. Sur le cadre PS9 et les tests de compatibilité, vous avez un article interne dédié : PrestaShop 9.2 : bonnes pratiques d’override et tests de compatibilité.
Stratégies de remplacement (ordre de préférence) : (1) configuration/hook natif, (2) décoration de services Symfony côté modules quand applicable, (3) surcharge via module (éviter l’override global), (4) override core en dernier recours. L’idée de refactoring sous-jacente (popularisée par Kent Beck, notamment dans ses écrits récents) est simple : rendre d’abord la modification possible “proprement”, puis effectuer la modification. En migration, ça se traduit par : réduire la surface d’override avant de monter de version, pas après.
Croiser thème + modules + hooks : matrice d’impact et tests ciblés (pas “testons tout”)
Une checklist d’audit utile ne s’arrête pas à des listes. Le vrai travail est de croiser : un module peut être sain isolément mais casser via le thème (template surchargé), ou via un hook (ordre), ou via un override. Construisez une matrice d’impact : lignes = fonctionnalités business (recherche, panier, paiement, promo, transport, compte, B2B), colonnes = thème/modules/hooks/overrides, et pointez les composants impliqués.
Exemple réel (pattern fréquent) : un marchand a 45 modules, 1 thème custom, 14 overrides. Pendant la migration vers PS9, 6 régressions majeures viennent uniquement de 3 zones : checkout (2 modules + surcharge template), promotions (1 override Cart::getOrderTotal()), et facettes (module + JS custom). Le gain de la matrice : vous testez 15 scénarios bien choisis au lieu de “tout tester partout”, et vous identifiez les responsabilités (module vs thème vs core) en quelques heures.
Vous pouvez formaliser la matrice sur un format très opérationnel (extrait) :
| Fonction | Thème | Modules | Hooks | Overrides | Test de validation |
|---|---|---|---|---|---|
| Checkout | template surchargé | paiement X, transport Y | displayPayment, actionValidateOrder |
override Order |
E2E paiement + logs callback |
| Promos | affichage panier | promo Z | actionCartSave |
override Cart |
5 paniers types (TTC/HT, remise, livraison) |
| SEO | balises/fil d’Ariane | SEO A | displayHeader |
— | crawl 50 URLs + canonical |
Côté tests, soyez pragmatiques :
- Tests PHP (unitaires/func) pour la logique business sur-mesure (pricing, stock, connecteurs).
- Tests E2E (Cypress/Playwright) pour les parcours critiques (ajout panier, paiement, création compte, retour produit).
- Tests de perf ciblés (k6, artillery) sur les endpoints FO, car les hooks/overrides peuvent multiplier les requêtes.
Astuce simple “anti-angle-mort” : ajoutez au moins un scénario E2E qui combine plusieurs contraintes réelles (ex : livraison en point relais + code promo + paiement CB + produit avec déclinaisons). Ce sont ces combinaisons qui déclenchent les bugs d’intégration hooks/modules.
Si vous avez déjà une chaîne d’intégration, capitalisez dessus. Sinon, vous pouvez industrialiser rapidement la création d’environnements démo/staging pour valider chaque lot : PrestaShop CI/CD : générer des démos à la demande en minutes.
Checklist d’audit “migration PrestaShop” (opérationnelle, orientée remédiation)
Cette checklist est volontairement orientée “résolution”, pas “documentation”. L’objectif : sortir une liste d’actions avec un propriétaire, un risque, et un test de validation. Chaque point doit produire un artefact vérifiable : export SQL, diff git, capture de logs, ticket Jira/YouTrack.
1) Inventaire (J0)
- Export
ps_module,ps_hook_module, et liste des overrides (core + modules). - Liste des templates surchargés (thème +
themes/<theme>/modules/*). - Versions : PrestaShop, PHP, MariaDB/MySQL, Redis/ES/Meilisearch le cas échéant.
- Volumétrie DB (top tables) et état “fichiers” : taille
img/,download/,themes/(utile pour estimer temps de sync sur staging).
2) Qualification (J1–J3)
- Modules : classer (core/PS/tiers/custom), noter compat PS9/PHP8.3, repérer ceux qui touchent checkout/paiement/prix.
- Hooks : repérer ceux utilisés sur parcours critiques, figer ordre et présence par shop (multiboutique = piège classique).
- Overrides : justifier ou supprimer ; pour chaque override conservé, associer un test (au minimum E2E de non-régression).
- Thème : lister les surcharges “à forte inertie” (checkout/panier/produit) et identifier les JS “fragiles” (sélecteurs core, plugins jQuery).
Pour ne pas rester au niveau “liste”, forcez un format de décision par item. Par exemple :
| Élément | Décision | Risque | Action | Validation |
|---|---|---|---|---|
| Module paiement X | garder/MAJ | élevé | MAJ + test callback | E2E + vérif statut commande |
Override Cart |
remplacer | élevé | redev via hook/service | 5 paniers types |
| Template checkout | refactor | moyen | réduire surcharge | diff visuel + E2E |
3) Remédiation (par lots)
- Remplacer les overrides “workaround” par hook/service quand possible.
- Mettre à jour ou remplacer les modules non maintenus (et prévoir la migration de données si le module stocke des états).
- Nettoyer les surcharges de templates de modules obsolètes (souvent des copies de fichiers datant de PS 1.7).
- Verrouiller la configuration (feature flags, mode debug, CCC, cache) pour que les tests soient comparables d’un run à l’autre.
4) Validation (staging)
- Activer logs PHP + profiler si possible, capturer les erreurs/déprecations.
- Benchmark comparatif avant/après : TTFB, nombre de requêtes, erreurs 500/404, et quelques pages clés.
- Tester le plan de rollback (restauration DB + fichiers) au moins une fois.
- Contrôler les points “business FR” : TVA/arrondis, transporteurs, paiements, emails transactionnels (souvent affectés par SMTP/headers après changement d’infra).
Le piège classique : considérer la migration comme un “upgrade technique”. En réalité, c’est un projet de compatibilité entre 4 couches (core, thème, modules, personnalisation). Si vous voulez réduire le risque, l’audit doit aboutir à une décision binaire pour chaque élément : on garde et on teste / on remplace / on supprime. Tout le reste, c’est du bruit.
