# Override ou module PrestaShop : comment choisir

> PrestaShop offre deux façons de modifier son comportement sans toucher au cœur du logiciel : l’override, qui étend une classe existante depuis le dossier override/, et le module, qui s’accroche à des points prévus par le système de hooks. Le choix n’est pas une question de préférence, il dépend de ce que PrestaShop permet réellement de faire à cet endroit précis.

- Source canonique : [https://allaux.fr/guides/override-ou-module-prestashop](https://allaux.fr/guides/override-ou-module-prestashop)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Réponse directe

> Privilégiez toujours un module quand un hook existe pour le besoin visé : c’est la méthode prévue, la plus stable dans le temps. Réservez l’override aux cas où aucun hook ne permet d’intervenir, en sachant qu’il devra être revérifié à chaque montée de version majeure.

## Comment trancher

1. **Chercher d’abord un hook adapté** — PrestaShop expose des dizaines de hooks à des points précis du cycle d’affichage et de traitement des commandes. S’il en existe un qui correspond au besoin, un module suffit.
2. **Évaluer si le comportement natif doit être modifié** — Un hook permet d’ajouter du comportement à un endroit donné, pas de remplacer une logique existante. Si le besoin est de changer un calcul ou une règle déjà codée dans le cœur, aucun hook ne le permet, et l’override devient la seule option native.
3. **Mesurer l’impact d’un override sur les mises à jour** — Un override ne remplace aucun fichier du cœur : PrestaShop charge depuis le dossier override/ une classe qui étend la classe d’origine — Product étend ProductCore — et n’en redéfinit que les méthodes visées. À chaque montée de version, ces méthodes doivent être recomparées à celles de la classe d’origine, qui a pu changer entre-temps.
4. **Documenter tout override créé** — Un override non documenté, découvert des mois plus tard lors d’une mise à jour, coûte un temps de diagnostic largement supérieur au temps qu’aurait pris sa documentation initiale.

## Ce qui distingue réellement les deux approches

Un module s’installe et se désinstalle proprement : il s’accroche à des hooks (par exemple displayHeader ou actionValidateOrder) via la méthode registerHook(), et chaque hook auquel il souscrit correspond à une méthode nommée sur le même modèle, comme hookDisplayHeader(). Désactiver ou supprimer le module retire proprement son comportement, sans laisser de trace dans le cœur.

Un override, lui, vit dans le dossier override/ (par exemple override/classes ou override/controllers) : PrestaShop y charge une classe qui étend la classe …Core du cœur — class Product extends ProductCore — et n’en redéfinit que les méthodes voulues, les autres continuant de venir du cœur. Aucun fichier natif n’est modifié ni remplacé. C’est plus puissant, parce que ça permet de changer un comportement que le système de hooks ne permettrait jamais d’atteindre, mais aussi plus fragile : si le cœur PrestaShop modifie la classe d’origine à une version ultérieure, l’override peut devenir incompatible, voire provoquer une erreur bloquante.

Dans la pratique, la plupart des modules distribués sur le marché n’utilisent que des hooks, précisément parce que c’est la méthode qui garantit la compatibilité la plus longue. Les overrides restent réservés aux besoins réellement impossibles à couvrir autrement.

## Les erreurs courantes

- Créer un override alors qu’un hook existant aurait suffi, ce qui complique inutilement les futures mises à jour.
- Compter sur la superposition de plusieurs overrides de la même méthode provenant de modules différents : PrestaShop refuse. Module::addOverride lève une exception et l’installation du second module échoue avec un message explicite du type « Unable to install override: The method … in the class … is already overridden ». C’est le premier override installé qui reste en place.
- Oublier qu’un override survit à la désinstallation du module qui l’a créé, s’il n’a pas prévu de le retirer proprement lors de sa désinstallation.
- Modifier un override sans avoir conservé une trace de la classe d’origine, rendant impossible la comparaison lors d’une mise à jour.

## Le cas intermédiaire des services et des événements Symfony

Sur PrestaShop 1.7 et plus, une troisième voie existe pour certains besoins avancés : le système d’événements et de services de Symfony, sur lequel repose désormais une partie du back-office. Un module peut y écouter un événement Symfony plutôt qu’un hook PrestaShop classique, ce qui reste plus proche dans l’esprit du module que de l’override, mais demande une connaissance plus poussée du framework sous-jacent.

Cette option reste réservée à des besoins spécifiques au nouveau back-office ; pour la grande majorité des modifications côté front ou côté logique métier classique, le choix se limite bien à hook contre override.

## FAQ

### Un thème personnalisé compte-t-il comme un override ?

Non, la personnalisation de thème passe par des fichiers de template (.tpl) et parfois du CSS ou du JavaScript, un mécanisme distinct des overrides qui concernent les classes PHP du cœur.

### Peut-on avoir plusieurs overrides sur des classes différentes sans risque ?

Oui, tant que chaque override cible une classe différente, il n’y a pas de conflit entre eux. Le risque de conflit apparaît uniquement quand deux overrides ciblent la même classe.

### Comment savoir si un module utilise des overrides ou seulement des hooks ?

Le dossier du module contient un sous-dossier override/ si celui-ci en crée. L’absence de ce dossier indique un module qui repose entièrement sur le système de hooks.