Pourquoi toucher au coeur de PrestaShop ?
Votre boutique en ligne ne fait pas exactement ce que vous voulez. Le calcul des frais de port ne correspond pas a votre logique metier. Le formulaire d'inscription manque un champ essentiel. Le comportement du panier ne colle pas a vos contraintes commerciales. Vous avez cherche dans les reglages, dans les modules disponibles, et rien ne repond precisement a votre besoin.
C'est a ce moment-la que la question se pose : faut-il modifier directement le coeur de PrestaShop ? En tant que developpeur specialise depuis plus de dix ans, je vois cette situation chaque semaine. Et la reponse n'est jamais "oui" ou "non" sans nuance. Il existe un mecanisme prevu pour cela : l'override PrestaShop. Mais mal utilise, il peut transformer chaque mise a jour en cauchemar technique.
Dans cet article, je vais vous expliquer concretement ce qu'est la surcharge PrestaShop, quand l'utiliser, quand l'eviter, et surtout comment proteger votre boutique pour les annees a venir.
Qu'est-ce qu'un override dans PrestaShop ?
Un override PrestaShop est un mecanisme d'heritage oriente objet qui permet de remplacer le comportement d'une classe ou d'un controleur du coeur, sans modifier les fichiers originaux. Concretement, vous creez un fichier dans le dossier /override/ de votre installation, et le systeme de chargement automatique de PrestaShop bascule sur votre version personnalisee.
Par exemple, pour modifier le comportement de la classe Product, vous creez un fichier /override/classes/Product.php qui etend ProductCore. Vous ne reecrivez que les methodes dont vous avez besoin. Le reste du comportement natif est preserve.
Les trois types de surcharges
- Surcharge de classes : vous modifiez la logique metier (calcul de prix, gestion de stock, validation de commande). Le fichier se place dans
/override/classes/. - Surcharge de controleurs : vous changez le comportement d'une page (processus de commande, page produit, page categorie). Le fichier se place dans
/override/controllers/. - Surcharge de templates de modules : vous personnalisez l'affichage d'un module natif en placant un template alternatif dans votre theme. C'est la forme la plus legere et la moins risquee.
Selon la documentation officielle PrestaShop, les overrides sont exclusifs : si un module surcharge une methode, aucun autre module ne pourra surcharger cette meme methode de maniere previsible. C'est une limitation fondamentale a comprendre avant de se lancer.
Les risques concrets d'un override mal gere
Je ne vais pas vous faire peur pour rien. Mais en dix ans de developpement PrestaShop, j'ai recupere des dizaines de boutiques bloquees a cause de surcharges mal maitrisees. Voici les problemes les plus frequents :
1. Blocage des mises a jour
Quand vous surchargez une methode du coeur, votre code "fige" le comportement de cette methode a la version ou vous l'avez ecrite. Si PrestaShop corrige un bug de securite ou ameliore les performances dans cette meme methode lors d'une mise a jour, votre override ignore completement ces changements. Votre boutique reste vulnerable ou sous-performante sans que vous le sachiez.
Le module autoupgrade de PrestaShop desactive d'ailleurs automatiquement les overrides avant toute mise a jour, ce qui peut provoquer des comportements inattendus si votre boutique depend de ces surcharges pour fonctionner normalement.
2. Conflits entre modules
C'est le probleme le plus courant. Deux modules tentent de surcharger la meme classe ou la meme methode. Le second module ne peut tout simplement pas s'installer. Sur le tracker GitHub de PrestaShop, des issues documentent ce probleme recurrent : un module avec un override en conflit peut malgre tout etre uploade dans la boutique sans que le marchand comprenne pourquoi il ne fonctionne pas.
3. Dette technique invisible
Au fil des mois, les overrides s'accumulent. Personne ne documente pourquoi tel override a ete ajoute. Le developpeur initial quitte le projet. Le nouveau prestataire decouvre un dossier /override/ rempli de fichiers dont personne ne connait l'utilite. Chaque intervention technique devient un champ de mines.
4. Incompatibilite avec les versions majeures
PrestaShop migre progressivement vers l'architecture Symfony. Les parties migrees utilisent le conteneur Symfony qui propose la decoration de services, un mecanisme bien plus robuste que les overrides classiques. PrestaShop 9, sorti mi-2025, a retire ou modifie plusieurs hooks du back-office lies a l'ancienne architecture. Les overrides ecrits pour PrestaShop 1.7 peuvent devenir completement inoperants en version 8 ou 9.
Override vs module vs hook : le comparatif
Avant de foncer sur un override, posez-vous cette question : existe-t-il une alternative plus propre ? Voici un comparatif pour vous aider a decider :
| Critere | Override | Module PrestaShop | Hook / Event Symfony |
|---|---|---|---|
| Modification du comportement natif | Oui, remplacement complet | Via hooks ou API | Interception d'evenements |
| Impact sur les mises a jour | Eleve (bloque les correctifs) | Faible (isole dans le module) | Faible (couplage lache) |
| Risque de conflit | Eleve (exclusif par methode) | Faible (priorite geree) | Tres faible |
| Compatibilite future (PS 9+) | Non garantie | Bonne si hooks standards | Excellente |
| Facilite de desactivation | Manuelle (suppression fichier) | Un clic dans le back-office | Un clic dans le back-office |
| Reutilisation sur d'autres boutiques | Non (specifique a la boutique) | Oui (installable partout) | Oui (via module) |
| Complexite de mise en oeuvre | Moyenne | Moyenne a elevee | Elevee (necessite Symfony) |
| Documentation/tracabilite | Faible (fichiers isoles) | Bonne (structure normee) | Bonne (services declares) |
Quand un override est-il justifie ?
Malgre les risques, il existe des situations ou l'override PrestaShop reste la meilleure option. Voici ma regle personnelle, forgee par l'experience :
- Aucun hook disponible pour le point d'extension dont vous avez besoin. Verifiez d'abord la liste officielle des hooks PrestaShop avant de conclure.
- Le besoin est specifique a VOTRE boutique. Si c'est un besoin generique, un module PrestaShop du marketplace (plus de 4 000 modules disponibles selon PrestaShop Addons) couvre probablement deja le cas.
- Vous maitrisez le suivi. Vous avez un processus pour verifier chaque override a chaque mise a jour. Sans cette discipline, ne surchargez pas.
- La modification est minimale. Vous ne surchargez qu'une ou deux methodes, pas une classe entiere.
Les alternatives modernes a l'override
Le developpement PrestaShop a enormement evolue ces dernieres annees. Avant de recourir a un override, explorez ces alternatives :
Les hooks : votre premiere option
PrestaShop propose des centaines de hooks (points d'accroche) repartis dans tout le coeur. Un hook permet a votre module PrestaShop de s'executer a un moment precis du processus sans modifier le code natif. Il existe deux types :
- Hooks d'affichage (
displayHeader,displayFooter,displayProductAdditionalInfo...) : ils permettent d'injecter du contenu HTML a des endroits precis des pages. - Hooks d'action (
actionProductUpdate,actionOrderStatusPostUpdate,actionValidateOrder...) : ils permettent d'executer du code quand un evenement se produit (commande validee, produit modifie, etc.).
En 2025, la communaute PrestaShop a lance une initiative pour enrichir le systeme de hooks, ajoutant de nouveaux points d'extension pour reduire le besoin d'overrides.
La decoration de services Symfony
Pour les parties de PrestaShop migrees vers Symfony (back-office principalement), la decoration de services permet d'envelopper un service existant avec votre propre logique, sans le remplacer. Vous conservez le comportement original et ajoutez le votre par-dessus. C'est l'approche recommandee par la documentation officielle pour les controleurs Symfony.
Les modules custom
Developper un module PrestaShop dedie a votre besoin est souvent plus pertinent qu'un override. Un module :
- Se desactive en un clic si probleme
- Se reinstalle facilement sur une autre boutique
- Dispose de son propre espace de configuration
- Peut etre versionne et maintenu independamment
- Ne bloque jamais l'installation d'un autre module
C'est exactement l'approche que je privilegie pour mes clients. Plutot que de poser des overrides fragiles, je developpe des modules sur mesure qui s'integrent proprement dans l'ecosysteme PrestaShop.
Guide pratique : mettre en place un override proprement
Si apres analyse, l'override reste votre meilleure option, voici comment proceder correctement :
Etape 1 : preparer l'override
- Identifiez precisement la classe et la methode a surcharger.
- Verifiez qu'aucun module existant ne surcharge deja cette methode (inspectez le dossier
/override/). - Creez votre fichier dans
/override/classes/ou/override/controllers/selon le cas. - Etendez la classe Core (ex:
class Product extends ProductCore). - Ne reecrivez que les methodes strictement necessaires.
Etape 2 : activer l'override
Apres avoir place votre fichier, supprimez le fichier /var/cache/prod/class_index.php (ou /cache/class_index.php selon votre version). PrestaShop regenerera automatiquement l'index des classes et prendra en compte votre override.
Etape 3 : documenter et versionner
C'est l'etape que 90 % des developpeurs sautent, et c'est la qu'ils le regrettent. Pour chaque override :
- Ajoutez un commentaire en tete de fichier expliquant POURQUOI cet override existe (pas COMMENT, le code parle de lui-meme).
- Notez la version de PrestaShop sur laquelle il a ete ecrit.
- Versionnez le fichier dans Git.
- Ajoutez une ligne dans un fichier de suivi listant tous vos overrides actifs.
Etape 4 : tester avant chaque mise a jour
Avant toute mise a jour de PrestaShop, comparez chaque methode surchargee avec la nouvelle version du coeur. Si la methode originale a change, adaptez votre override en consequence. Ce travail de verification est indispensable et fait partie integrante de la maintenance PrestaShop.
PrestaShop 9 et l'avenir des overrides
PrestaShop 9, sorti en 2025, marque une etape importante dans la migration vers Symfony. Le back-office est desormais entierement base sur Symfony et Twig. Plusieurs hooks historiques du back-office ont ete retires ou modifies, comme ceux lies a l'ancien controleur de connexion admin.
Ce qu'il faut retenir pour l'avenir :
- Le systeme d'override PrestaShop classique reste fonctionnel pour les classes et controleurs front-office.
- Pour le back-office, la decoration de services Symfony devient la norme.
- L'Event Dispatcher de Symfony coexiste avec les hooks traditionnels via un pont de compatibilite, mais a terme, il remplacera les hooks.
- L'ancien controleur de base avec conteneur global est marque comme deprecie et sera supprime en PrestaShop 10.
Si vous lancez un projet de developpement PrestaShop aujourd'hui, privilegiez les approches Symfony natives. Vos developpements seront compatibles avec les futures versions sans retravail majeur.
Checklist avant de surcharger
Pour vous aider a prendre la bonne decision, voici la checklist que j'utilise systematiquement avec mes clients :
- Ai-je verifie qu'aucun module PrestaShop existant ne repond a mon besoin ?
- Ai-je consulte la liste des hooks disponibles pour ce point d'extension ?
- La partie concernee est-elle migree vers Symfony (auquel cas, la decoration est preferable) ?
- Mon override ne touche-t-il qu'une ou deux methodes maximum ?
- Ai-je un processus de verification systematique a chaque mise a jour ?
- L'override est-il documente et versionne dans Git ?
- Ai-je teste que mon override ne cree pas de conflit avec les modules installes ?
Si vous repondez "non" a une seule de ces questions, reconsiderez votre approche. Un module PrestaShop sur mesure est presque toujours plus sûr a long terme.
FAQ : vos questions sur l'override PrestaShop
Un override peut-il casser ma boutique lors d'une mise a jour ?
Oui. Quand PrestaShop modifie une methode que vous avez surchargee, votre override continue d'utiliser l'ancienne logique. Cela peut provoquer des erreurs, des failles de securite ou des comportements inattendus. Le module autoupgrade desactive les overrides avant la mise a jour, ce qui peut aussi causer des dysfonctionnements si votre boutique en depend.
Quelle est la difference entre un override et un module ?
Un override remplace directement le code du coeur de PrestaShop. Un module PrestaShop s'integre via des hooks (points d'accroche) sans modifier le coeur. Le module est desactivable en un clic, reinstallable et ne cree pas de conflit avec d'autres modules. L'override est exclusif : deux modules ne peuvent pas surcharger la meme methode.
Les overrides sont-ils interdits sur PrestaShop Addons ?
Ils ne sont pas totalement interdits, mais fortement decourages. La documentation officielle precise que les overrides sont interdits dans les modules partenaires et non recommandes pour les modules distribues sur le marketplace. La raison : leur caractere exclusif rend les conflits inevitables a grande echelle.
Comment savoir si mon override est encore compatible apres une mise a jour ?
Comparez la methode originale de la nouvelle version avec celle que vous aviez surchargee. Si la signature ou la logique interne a change, votre override doit etre adapte. C'est un travail technique qui fait partie de la maintenance PrestaShop. Sans cette verification, vous risquez des bugs silencieux.
Puis-je utiliser des overrides avec PrestaShop 9 ?
Le mecanisme d'override classique reste fonctionnel pour le front-office dans PrestaShop 9. Cependant, pour le back-office entierement migre vers Symfony, la decoration de services est desormais l'approche recommandee. Les overrides de controleurs admin traditionnels ne fonctionnent plus sur les pages migrees.
Aller plus loin
- Developpement de modules PrestaShop sur mesure : l'alternative durable aux overrides
- Migration PrestaShop : preparer votre boutique pour les futures versions
Votre boutique a besoin d'une modification du coeur de PrestaShop ?
Avant de poser un override fragile, parlons de la bonne approche. Je developpe des modules PrestaShop sur mesure, compatibles avec les futures mises a jour, desactivables en un clic et sans risque de conflit. Plus de dix ans d'expertise e-commerce au service de votre boutique en ligne.