Overrides dans PrestaShop : quand ils sont acceptables et comment les éviter

Un override est une classe placée dans le dossier override/ qui étend une classe du cœur (par exemple class Cart extends CartCore) et réécrit certaines de ses méthodes. PrestaShop la charge à la place de l'originale grâce à son autoloader et à l'index des classes (var/cache/prod/class_index.php).

Pourquoi ils posent autant de problèmes

• Des signatures qui changent. Si le cœur modifie les paramètres ou les types d'une méthode dans une nouvelle version, votre override n'est plus compatible et PHP lève une erreur fatale au chargement de la classe. Lors du passage à PrestaShop 9.1, plusieurs méthodes ont adopté des types nullables explicites, et les anciens overrides ont cessé de compiler.
• Deux modules, une méthode. Un seul module peut surcharger une même méthode. Le second qui essaie échoue à l'installation avec le message « the method X in the class Y is already overridden ».
• Ils restent actifs même si vous désactivez le module. L'override vit dans override/, pas dans le dossier du module. Désactiver le module ne l'éteint pas ; il faut le désinstaller.
• Ils se perdent en silence. Si une mise à jour ou un déploiement vide le dossier, la boutique continue de fonctionner, mais sans la logique qui dépendait de l'override.

Comment savoir quels overrides vous avez

Chaque override installé par un module porte un commentaire d'en-tête avec le nom du module :

/*
* module: mimodulo
* date: 2026-09-22 01:12:36
* version: 1.4.0
*/
public function getPackageShippingCost(...)

Un inventaire rapide depuis la racine de la boutique :

grep -rho "module: [a-z0-9_]*" override/ | sort | uniq -c

Les fichiers sans cette marque ont été placés à la main : ce sont les plus dangereux, car personne ne sait pourquoi ils sont là.

Alternatives, de la meilleure à la pire

1. Un hook. Presque tout ce qui se fait avec des overrides dans les anciennes boutiques dispose aujourd'hui d'un hook : afficher quelque chose dans le panier, modifier les options de paiement, réagir à l'enregistrement d'un objet.
2. Décorer un service Symfony. Dans le back-office de PrestaShop 8 et 9, beaucoup de pièces sont des services. Vous pouvez en envelopper un avec le vôtre depuis le services.yml de votre module sans toucher à l'original.
3. Surcharger un template dans le thème, si le changement est visuel.
4. Un override, uniquement quand il n'y a pas d'autre voie, le plus petit possible et documenté.

Notre règle

Quand un client nous demande une fonctionnalité, l'override est le dernier recours. S'il n'y a vraiment pas d'autre solution, c'est le module lui-même qui l'installe (jamais à la main), il porte son en-tête et il figure dans la documentation de la boutique. Ainsi, dans deux ans, la personne qui mettra à jour saura ce qu'il y a et pourquoi.