Migrer vos modules PrestaShop vers PS 9 : ce qui change vraiment

PrestaShop 9 est un tournant technique majeur : passage à Symfony 6.4, PHP 8.1 minimum, refonte du système de hooks, et abandon progressif des overrides. Pour les e-commerçants, ça veut dire une chose : vos modules existants ne fonctionneront pas tels quels sur PS 9. Voici ce qui casse, pourquoi, et comment s'y prendre pour migrer.

Pourquoi migrer vers PrestaShop 9 ?

Avant de parler migration, la question légitime : est-ce que ça vaut le coup ? La réponse courte est oui, et voici pourquoi.

Performances — Symfony 6.4 apporte un gain de performance significatif sur le rendu des pages back-office et sur les API. Les benchmarks montrent un gain de 20 à 40% sur les temps de réponse par rapport à PS 8.x.

Sécurité — PHP 8.1+ corrige des vulnérabilités critiques qui ne seront plus patchées sur PHP 7.x. Rester sur PS 8.x avec PHP 7.4, c'est s'exposer à des failles connues.

Pérennité — PrestaShop concentre désormais ses efforts de développement sur PS 9. Les corrections de bugs sur PS 8.x seront de plus en plus rares. Migrer maintenant, c'est éviter une dette technique qui ne fera que grandir.

Ce qui casse dans PrestaShop 9

PHP 8.1 minimum — les types stricts

PHP 8.1 est plus strict sur les types. Un module qui passait null là où une chaîne était attendue fonctionnait en PHP 7.4 — il crashe en PHP 8.1 avec un TypeError. Les constructeurs de vos classes, les signatures de méthodes et les retours de fonctions doivent être revus pour gérer correctement les types nullable (?string, int|null).

Symfony 6.4 — les services et l'injection de dépendances

PrestaShop 9 pousse à fond l'architecture Symfony. Concrètement, les modules doivent déclarer leurs services dans un fichier config/services.yml et utiliser l'injection de dépendances plutôt que d'appeler des méthodes statiques ou d'instancier des classes directement. L'accès au container via $this->get() dans les contrôleurs est déprécié.

Hooks modifiés et supprimés

Certains hooks historiques ont été renommés ou remplacés. Par exemple, les hooks liés à l'ancien système de templates Smarty évoluent vers des hooks Twig pour le back-office. Un module qui s'accroche à un hook supprimé ne s'affiche tout simplement plus — sans message d'erreur. C'est le piège le plus sournois.

Les overrides : la fin annoncée

PrestaShop 9 renforce la politique anti-overrides. Les overrides de classes core (comme Cart, Order, Product) sont toujours techniquement possibles mais fortement découragées et susceptibles de casser à chaque mise à jour mineure. La bonne pratique est de tout passer en hooks et en services.

Les 5 étapes de migration d'un module

Étape 1 : Audit de compatibilité

Avant de toucher au code, on fait un inventaire complet : version PHP utilisée, hooks accrochés, overrides éventuels, dépendances externes, accès à la base de données (requêtes SQL directes vs ObjectModel). Cet audit produit une liste de points de rupture classés par criticité.

Étape 2 : Mise à niveau PHP 8.1+

On passe le code au crible des analyseurs statiques (PHPStan, Psalm) pour détecter les incompatibilités de type. On corrige les signatures, on ajoute les types nullable, on remplace les fonctions dépréciées. Cette étape est souvent la plus longue — mais c'est aussi celle qui rend le code plus robuste.

Étape 3 : Refactoring des hooks

On remplace les hooks supprimés ou renommés par leurs équivalents PS 9. On en profite pour migrer les overrides vers des hooks quand c'est possible. Le fichier config/services.yml est créé si le module n'en avait pas.

Étape 4 : Tests sur environnement PS 9

On installe le module sur une instance de test PrestaShop 9 avec un jeu de données réaliste (catalogue, commandes, clients). On teste chaque fonctionnalité, front-office et back-office. On vérifie les performances et les logs d'erreur.

Étape 5 : Déploiement progressif

Si vous migrez aussi votre boutique de PS 8 vers PS 9, le module migré est déployé dans la foulée. Si vous êtes déjà sur PS 9, le module est installé en parallèle de l'ancien et basculé après validation.

Faut-il migrer ou réécrire ?

Pour un module simple (moins de 1000 lignes de code, 2-3 hooks, pas d'override), la migration est souvent l'affaire de 1 à 2 jours. Pour un module complexe avec des overrides massifs, un back-office personnalisé et des requêtes SQL directes, il est parfois plus rapide et plus propre de réécrire from scratch en suivant les conventions PS 9 dès le départ.

Mon conseil : si plus de 50% du code doit être modifié, la réécriture est souvent le meilleur choix. Vous repartez sur des bases saines et vous éliminez la dette technique accumulée.