Compatibilité modules PrestaShop 9 : checklist avant migration sécurisée

Table des matières :

1. Inventorier les modules et leurs dépendances : la base de toute compatibilité PrestaShop 9
2. Fixer la cible technique PrestaShop 9 (et donc le périmètre de compatibilité)
3. Audit code PHP : compatibilité syntaxe, types, dépendances et quality gates
4. Audit d’intégration PrestaShop : hooks, overrides, Symfony, templates et backoffice
5. Sécurité et conformité : contrôler ce que vos modules exposent (et ce qu’ils embarquent)
6. Staging reproductible + protocole de tests : valider la compatibilité au-delà du “ça marche”
7. Industrialiser la migration : CI/CD, observabilité, rollback et critères de go/no-go
8. Checklist synthétique (utilisable en runbook) pour la compatibilité modules PrestaShop 9

Inventorier les modules et leurs dépendances : la base de toute compatibilité PrestaShop 9

Migrer vers PrestaShop 9 sans cartographier précisément le parc de modules, c’est accepter un risque non mesurable : erreurs fatales PHP, hooks non déclenchés, overrides qui cassent le chargement des classes, ou régressions fonctionnelles silencieuses (checkout, taxes, transporteurs). La “compatibilité modules PrestaShop 9” commence donc par un inventaire exhaustif et rejouable, pas par un clic sur un upgrader.

Côté données, ne vous contentez pas du répertoire /modules. Interrogez la base pour sortir la vérité “runtime” (installé/actif) et la surface d’impact (hooks). Exemple minimal (MySQL/MariaDB) :

-- Modules installés + statut
SELECT name, version, active
FROM ps_module
ORDER BY active DESC, name;

-- Modules accrochés à des hooks (points d’injection)
SELECT m.name, h.name AS hook, hm.position
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 m.name, h.name, hm.position;

Deux compléments très utiles en pratique :

• Détecter les modules “présents sur disque” mais pas installés (souvent des reliquats ou des POC) : listez /modules/* et comparez à ps_module.
• Identifier les modules qui injectent du code via overrides (risque de collision maximal) : l’info n’est pas en base, mais un scan de fichiers suffit. Exemple (à adapter) : find modules -type d -name override -print.

Ensuite, récupérez les métadonnées des modules : config.xml (compatibilité déclarative), composer.json (dépendances), présence d’override/, et le nombre de classes legacy vs Symfony. Un indicateur rapide de risque : (1) module avec overrides + (2) module qui touche au checkout + (3) module non packagé avec Composer + (4) absence de tests automatisés.

Pensez aussi “organisation”, pas seulement “technique” : pour chaque module, notez sa source (Marketplace/éditeur, interne, fork), son responsable (owner) et son SLA (qui corrige en cas d’incident). En migration, ce sont souvent ces informations (et pas le code) qui débloquent une décision rapide : mettre à jour, patcher, remplacer ou supprimer.

Si vous n’avez pas déjà une hygiène de désinstallation/maintenance, lisez et appliquez la méthode “désinstallation propre” : Modules PrestaShop : désinstallation propre, performances et sécurité en production.

Fixer la cible technique PrestaShop 9 (et donc le périmètre de compatibilité)

Une checklist de compatibilité n’a de sens qu’avec une cible explicite : version exacte de PrestaShop 9.x, version de PHP, stack serveur (Apache/Nginx), moteur DB et cache. Sur PrestaShop 9, vous êtes dans un monde Symfony plus strict et une base PHP moderne ; la moindre divergence (extension PHP manquante, opcache mal configuré, limite ulimit trop basse) se transforme vite en “bug module”. Référez-vous à la matrice de compatibilité PHP côté PrestaShop, notamment si vous ciblez 9.1+ : PrestaShop 9.1 : compatibilité PHP 8.1–8.5, CLI et nouveautés développeurs.

Définition opérationnelle : un module est “compatible PrestaShop 9” s’il (a) s’installe et se désinstalle proprement, (b) ne déclenche aucune erreur PHP (warning/notice inclus si vous visez un niveau qualité), (c) respecte les points d’extension (hooks, services Symfony, routes, CQRS/Command Bus le cas échéant), (d) ne dépend pas d’APIs supprimées/dépréciées, et (e) n’introduit pas de régressions mesurables (performance, sécurité, SEO technique). Sans cette définition, vous ne pourrez ni trier, ni arbitrer.

Pour cadrer le périmètre, explicitez aussi les “contraintes métier” liées au contexte (souvent EU/France) :

• Paiement : 3-D Secure / SCA (DSP2), parcours mobile, modes CB courants.
• Taxes : TVA multi-taux, exemptions éventuelles, B2B/B2C, ventes intracommunautaires si concerné.
• Transport : transporteurs France (ex. Colissimo, Mondial Relay) + règles de poids/volumétrie + points relais.
• Données personnelles : règles de conservation, consentement, traceabilité (RGPD) — ce qui influence les modules “marketing”, “chat”, “avis”, “A/B testing”, etc.

Côté outillage, assumez Composer comme source de vérité pour les dépendances. La phrase de référence (et une réalité en migration) : « Composer is a dependency manager for PHP. » (Composer, documentation officielle : getcomposer.org). En pratique, ça veut dire : verrouiller une stack reproductible (composer.lock), et refuser les modules qui “téléchargent des libs à la volée” en prod (ou qui embarquent des bibliothèques obsolètes sans suivi).

Pour le socle Symfony, gardez en tête ce que vous embarquez : « Symfony is a set of reusable PHP components and a PHP framework for web projects. » (Symfony, page d’accueil : symfony.com). PrestaShop 9 s’appuie sur ce socle ; si vos modules ignorent les conventions Symfony (services, autowiring, container compilation), le coût de maintenance explose — surtout quand vous devez corriger vite en production.

Audit code PHP : compatibilité syntaxe, types, dépendances et quality gates

La plupart des incompatibilités à la migration vers PrestaShop 9 ne sont pas “PrestaShop”, elles sont “PHP”. Ciblez explicitement la version de PHP choisie (ex. 8.2 ou 8.3) et passez les modules au scanner. Les points qui cassent encore en 2026 : signatures incompatibles (typed properties, union types), méthodes internes devenues strictes, preg_* avec null, count() sur non-countable (selon niveaux), et surtout les erreurs de compatibilité liées aux librairies figées (SDK paiement/transport non maintenu).

Un point très concret : un module peut “sembler OK” tant qu’il n’exécute pas son code (ex. un cron jamais lancé, un hook rarement déclenché, une page BO peu utilisée). D’où l’intérêt de combiner audit statique + tests réels sur staging.

Mettez en place un pipeline de contrôle minimal avant même d’installer les modules sur un staging. À ce stade, vous cherchez des “fails fast” :

• composer validate et composer audit (CVE connues via advisory DB).
• php -l (lint) sur les fichiers critiques si le module n’est pas Composer-ready.
• PHPStan (niveau 5+ réaliste en module legacy) et Rector pour des remédiations mécaniques. Si vous industrialisez ce volet, l’article PHPStan et Rector : industrialiser la qualité du code PHP donne une base praticable.

Ne confondez pas “ça ne plante pas” et “c’est compatible”. Fixez des quality gates : zéro fatal error, zéro deprecated dans les logs en parcours standard, et des tests de non-régression sur les endpoints critiques (API, hooks checkout, génération de facture, etc.).

Action simple qui évite beaucoup de surprises : imposer une baseline de logs. Par exemple, lancez un parcours standard (homepage → catégorie → produit → panier → checkout) et archivez le différentiel de logs entre PrestaShop 8 (baseline) et PrestaShop 9 + modules migrés. Une régression “bruyante” (nouveaux warnings/deprecated) est souvent le signe d’un futur incident lorsqu’un paramètre change (nouvelle version PHP, cache warmup, surcharge trafic…).

En environnement prod-like, activez un niveau de log utile (sans noyer le SIEM) et appliquez des règles de gestion d’erreurs adaptées : Gestion d’erreur PHP : bonnes pratiques et configuration développement/production.

Audit d’intégration PrestaShop : hooks, overrides, Symfony, templates et backoffice

Le point dur en compatibilité modules PrestaShop 9 reste l’intégration dans le cœur : hooks legacy, overrides, controllers, et interactions Back Office. Les overrides sont le premier suspect : ils modifient des classes core et entrent en collision avec d’autres modules, avec des changements de signatures entre versions, ou avec l’autoloading. Règle de survie : si un module dépend d’un override pour une fonctionnalité critique, planifiez une réécriture vers hooks/services ou un remplacement. Et si vous devez en garder temporairement, isolez et documentez précisément quel override et pourquoi.

Checklist rapide “override” à documenter (utile en runbook) :

• Classe(s) surchargée(s) + méthode(s) modifiée(s)
• Motivation fonctionnelle (ex. ajout d’un champ facture, modification pricing, etc.)
• Risque de collision (autres modules touchant la même zone)
• Plan de sortie (remplacement par hook / service / event subscriber, ou suppression)

Deuxième zone rouge : le Back Office et l’écosystème Symfony (services, routes, controllers). Un module réellement PrestaShop 9-ready doit respecter la structure moderne (services, DI, admin controllers Symfony, assets propres) et éviter les bricolages (include de classes, injection “à la main”, usage d’APIs internes non stables). Pour cadrer ça, utilisez comme référence : Module PrestaShop 9 : structure, services et bonnes pratiques Symfony.

Troisième angle souvent négligé : rendu et front. PrestaShop reste très marqué par Smarty, mais l’écosystème pousse de plus en plus vers Twig côté composants/outils. Si un module injecte des templates ou surcharge des blocs, testez le rendu en multi-langue, multi-devise, et sur les pages à fort trafic (catégories, recherche, fiche produit).

Mini-scénario typique en migration : un module “marketing” ajoute un bloc en fiche produit via hook, et surcharge un template pour afficher un badge promo. En PrestaShop 9, ce même module peut rester “installable”, mais casser le cache (fragment non cachable), dégrader le CLS/LCP côté WebPerf, ou générer des erreurs de traduction (domaines mal gérés). Ce ne sont pas des “bugs qui se voient tout de suite” tant qu’on ne mesure pas.

Si vous avez une couche Twig dans vos développements ou thèmes, assurez-vous que l’équipe maîtrise les bases : Twig PHP : syntaxe essentielle, héritage de templates et includes.

Sécurité et conformité : contrôler ce que vos modules exposent (et ce qu’ils embarquent)

La migration est le moment où vous pouvez réellement couper les modules à risque, parce que “on a toujours fait comme ça” n’est pas un argument technique. Faites un audit des surfaces exposées : endpoints front, endpoints BO, webservices, et jobs cron. L’objectif : identifier les modules qui contournent l’authentification BO, qui exposent des tokens en clair, qui écrivent en base sans validation, ou qui ouvrent des routes “admin” sans ACL.

Cadrez votre grille d’analyse sur un standard. OWASP définit clairement l’objectif : « OWASP Top 10 is a standard awareness document for developers and web application security. » (OWASP : owasp.org). Traduction pratique pour PrestaShop : contrôles d’accès, injection SQL (même avec Db::getInstance si mal utilisé), XSS via champs configurables, et surtout secrets (API keys) stockés ou loggés sans précautions.

Concrètement, sur une boutique opérée en France/UE, ajoutez deux préoccupations très opérationnelles :

• Données personnelles : un module peut multiplier les exports, logs, ou synchronisations (CRM, emailing, avis). Vérifiez où les données partent, qui y accède, et si la désinstallation supprime/anonimise ce qui doit l’être.
• Traçabilité : si un module exécute des actions sensibles (remboursement, création d’avoir, changements de statut), vous devez pouvoir corréler qui a fait quoi (logs BO, logs applicatifs, journaux d’audit).

En parallèle, auditez les dépendances tierces (SDK, HTTP clients, libs XML/PDF) via composer audit et/ou un SCA (Software Composition Analysis) dans la CI.

Pour un cadrage “production grade” (moindre privilège, audit logs, RGPD, traçabilité), appuyez-vous sur : Automatisation PrestaShop : sécurité RGPD, moindre privilège et journaux d’audit et, côté vulnérabilités module, gardez un œil sur les avis de sécurité et procédures de mise à jour (notamment pour les briques exposées comme le paiement) : CVE-2025-61922 ps_checkout : mise à jour 5.0.5 et mesures.

Staging reproductible + protocole de tests : valider la compatibilité au-delà du “ça marche”

Tester la compatibilité des modules sur un staging “à peu près” similaire à la prod, c’est produire des faux positifs. Vous voulez un staging reproductible : même version de PHP, mêmes extensions, mêmes limites système, même configuration de cache, même CDN/WAF si possible, et une base de données anonymisée mais réaliste. Sur un poste dev, DDEV peut fournir un environnement cohérent et scriptable : DDEV : outils développeur intégrés, ddev exec/ssh et extensions d’image.

Pour la partie “base réaliste”, évitez le piège classique : importer une prod, masquer trois emails “à la main”, puis tester. Si vos modules touchent au checkout, vous voulez au minimum :

• un panier avec TVA standard + un avec TVA réduite (si applicable),
• un panier avec règle panier (remise, cadeau, livraison offerte),
• un panier multi-transporteur (domicile vs point relais),
• un parcours invité + un parcours compte client,
• un cas de rupture de stock / stock faible,
• un cas de facture/avoir et, si vous vendez en UE, un cas “B2B” si vous le gérez.

Sur ce staging, exécutez une séquence de validation standardisée. Un socle simple mais efficace :

1. Installer/activer les modules par lots (par domaine : paiement, livraison, search, ERP).
2. Rebuild cache + warmup, vérifier les logs (var/logs, web server, PHP-FPM).
3. Parcours de non-régression du tunnel (guest/compte, promotions, transporteurs, paiement, retour). La checklist exécutable existe déjà : Contrôle PrestaShop post-modification : checklist tunnel de commande et règles panier.

Ajoutez une couche de perf/fiabilité. Les migrations cassent souvent sur des limites OS (FD) et non sur du code “métier” : PrestaShop 9 : corriger l’erreur « too many open files ». Côté cache, testez explicitement ce qui est cachable et ce qui ne l’est pas (cookies, ESI, headers). Si vous êtes sur Docker avec Varnish, validez le comportement via headers et hit ratio : PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache.

Astuce très rentable : faites un test “dégradation contrôlée” avant prod. Exemple : désactivez temporairement un module non critique (widget, badge, tracking secondaire) et vérifiez que la boutique reste fonctionnelle. Le jour où un module casse après migration, vous devez savoir quoi couper sans impacter le CA (paiement/livraison/taxes).

Industrialiser la migration : CI/CD, observabilité, rollback et critères de go/no-go

Une migration sécurisée vers PrestaShop 9 ne se “réussit” pas, elle se pilote : build reproductible, artefacts immuables, et capacité de rollback. Si votre déploiement dépend de manipulations manuelles (FTP, écrasement de fichiers, patchs non versionnés), vous ne pouvez pas isoler l’impact d’un module. La trajectoire saine : container buildé (ou package), composer install --no-dev, assets compilés, puis déploiement. Pour la mécanique CI, vous pouvez reprendre une approche build reproductible : Intégration continue PrestaShop : BuildKit, GitHub Actions et build reproductible.

Côté observabilité, posez des métriques avant migration, sinon vous ne saurez pas si un module “compatible” dégrade la boutique. Les indicateurs basiques : TTFB (p95), taux d’erreurs HTTP 5xx, temps de réponse MySQL (slow queries), saturation PHP-FPM, hit ratio cache, et latence du checkout. Sur le blog, vous avez déjà de quoi cadrer la méthode : Audit performance PrestaShop : méthode en 6 étapes reproductibles et, si vous partez sur une stack metrics, une base Grafana côté Ubuntu : Grafana sur Ubuntu : installation APT et configuration initiale.

Sur le rollback, soyez précis : un retour arrière “fonctionnel” implique souvent code + base + cache. Or certains modules appliquent des migrations SQL à l’installation, ajoutent des tables, ou modifient des données (ex. mapping transporteurs, config paiement). Sans procédure testée, vous vous retrouvez avec un core rollbacké mais une base “future” — et des bugs difficiles à diagnostiquer.

Enfin, fixez des critères de go/no-go écrits, et tenez-vous-y. Exemple pragmatique (à adapter) :

• Go si : 0 fatal, 0 régression checkout, p95 TTFB ≤ +10% vs baseline, aucun nouveau deprecated en prod logs, aucun module critique sans mainteneur identifié.
• No-go si : override critique non maîtrisé, module paiement/livraison non compatible PHP cible, vulnérabilité non corrigée sur module exposé, ou crash sous charge.
• Rollback : snapshot DB + artefact versionné + procédure de restauration testée (pas “on verra”). Pour la partie sauvegarde/plan, gardez une procédure structurée : Résiliation hébergement PrestaShop : sauvegarde complète et plan de migration.

Checklist synthétique (utilisable en runbook) pour la compatibilité modules PrestaShop 9

Une checklist utile doit être actionnable et auditable. Commencez par geler l’état initial : liste des modules installés/actifs, versions, sources (marketplace, vendor, interne), et empreinte (hooks + overrides). Ajoutez un “owner” technique par module (interne ou éditeur) : sans responsable, vous n’avez pas de SLA de correction.

Ensuite, appliquez un tri par criticité : bloquant (paiement, livraison, taxes, ERP), important (search, merchandising, SEO), confort (UI backoffice, widgets).

Pour rendre le tout exploitable en migration (et pas juste “un doc”), voici un format de tableau simple qui fonctionne bien en runbook :

Module	Criticité	Source	Owner	Overrides	Zones touchées (checkout/BO/front)	Compat PHP cible	composer audit	Tests staging OK	Plan B
ps_checkout / module paiement	Bloquant	Éditeur	Prestataire paiement	Non	Checkout	Oui/Non	OK/KO	Oui/Non	Passerelle alternative / désactivation impossible
module transport	Bloquant	Éditeur	Équipe Ops	Oui/Non	Checkout	Oui/Non	OK/KO	Oui/Non	Transporteur fallback
module SEO	Important	Interne	Dev	Non	Front	Oui/Non	OK/KO	Oui/Non	Désactivation temporaire

Pour chaque module : (1) compat PHP cible, (2) compat PrestaShop 9 annoncée et vérifiée en staging, (3) dépendances auditées (composer audit), (4) impact perf (profiling rapide), (5) surface d’attaque (endpoints, permissions), (6) plan B (désactivation / alternative / développement).

Enfin, n’oubliez pas le cœur du sujet : ce n’est pas “migration PrestaShop 9”, c’est “migration de votre écosystème”. Si vous cherchez le déroulé global (sans vous mentir sur les points douloureux), utilisez comme fil conducteur : PrestaShop 9 : guide de migration depuis 1.7 et 8 avec 1-Click Upgrade — puis remplacez l’optimisme du “one-click” par votre protocole de compatibilité modules décrit ci-dessus, parce que la majorité des incidents en prod viennent des modules, pas du core.