Comment gérer les conflits entre overrides et modules sur PrestaShop ?

Un override PrestaShop remplace entièrement une classe du cœur (par exemple ProductController ou Customer) pour en modifier le comportement. Lorsqu'un module tiers tente de faire la même chose sur la même classe, ou qu'une mise à jour de version touche ce fichier, la boutique peut afficher une page blanche, une erreur fatale de type "Cannot redeclare class" ou un comportement métier incohérent (remise non appliquée, redirection cassée, champ manquant). Ce type d'incident touche surtout les boutiques avec plusieurs développeurs successifs ou de nombreux modules installés sans documentation centralisée.

Identifier la source du conflit

La première étape consiste à lister tous les fichiers présents dans le dossier override/ (controllers, classes, models) et à les comparer avec les hooks déclarés par les modules actifs. En mode debug (variable _PS_MODE_DEV_ à true dans config/defines.inc.php), PrestaShop affiche généralement le nom du fichier et la ligne à l'origine de l'erreur, ce qui permet de cibler rapidement la classe concernée.

• Vérifier les logs : dossier var/logs/ et les logs serveur (Apache/Nginx) pour les erreurs PHP fatales.
• Comparer les versions : un override écrit pour PrestaShop 1.6 peut casser une installation 1.7 ou 8.x si la signature de la méthode a changé.
• Repérer les doublons : deux modules ou un module et un override manuel qui redéfinissent la même méthode sans appeler le parent.

Privilégier les hooks aux overrides

PrestaShop propose un système de hooks (displayHeader, actionProductUpdate, actionValidateOrder, etc.) justement pour éviter de toucher au cœur du code. Un module bien conçu s'accroche à un hook plutôt que de surcharger une classe entière. Quand un développement sur mesure est nécessaire, il faut d'abord vérifier s'il existe un hook natif permettant d'obtenir le même résultat sans override. La documentation officielle (devdocs.prestashop-project.org) liste l'ensemble des hooks disponibles par version.

Si l'override reste la seule option (modification profonde d'une méthode existante), il faut toujours appeler parent::methode() quand c'est possible, plutôt que de réécrire la méthode entière, afin de limiter la casse en cas de mise à jour du cœur ou d'un autre module qui interviendrait sur la même classe.

Mettre en place une documentation technique

Chaque override doit être tracé dans un fichier de suivi interne ou un commentaire en tête de fichier indiquant : la date de création, l'auteur, la raison métier, et la version de PrestaShop ciblée. Cette discipline simple évite qu'un override oublié bloque une mise à jour deux ans plus tard. Pour une boutique gérant plusieurs centaines de commandes par mois, un incident de ce type peut immobiliser le site plusieurs heures, avec un impact direct sur le chiffre d'affaires.

• Un tableau de suivi (fichier partagé ou outil de ticketing) recensant tous les overrides actifs.
• Un commentaire standardisé en en-tête de chaque fichier override.
• Une revue annuelle des overrides pour supprimer ceux devenus obsolètes.

Tester avant chaque mise à jour

Avant toute montée de version (mineure ou majeure) ou installation d'un nouveau module touchant au catalogue, aux commandes ou aux clients, un passage en environnement de recette est indispensable. Ce clone de la production (base de données + fichiers) permet de détecter les conflits sans risquer l'arrêt du site principal. La checklist de test doit couvrir :

• Le tunnel de commande complet, du panier à la confirmation.
• Les pages produit avec options, déclinaisons et prix dégressifs.
• Le back-office : création de commande manuelle, export catalogue, gestion des clients.

Résoudre un conflit déjà présent

Quand le conflit est avéré, plusieurs options existent selon le contexte :

• Fusionner le code : intégrer dans l'override les deux logiques métier (celle du module et celle d'origine) en les rendant compatibles, plutôt que de choisir l'une au détriment de l'autre.
• Convertir l'override en hook : si le module propose une alternative par hook, migrer vers cette solution plus pérenne.
• Isoler via un module maison : créer un module léger qui s'accroche aux hooks nécessaires plutôt que de multiplier les overrides, ce qui facilite la maintenance future.

Dans tous les cas, la résolution doit être documentée et testée en recette avant déploiement en production, avec une sauvegarde complète (fichiers + base de données) réalisée juste avant l'intervention.

S'entourer d'un prestataire compétent

La gestion des overrides demande une bonne connaissance de l'architecture PrestaShop et de l'historique des modules installés sur la boutique. Si votre équipe interne n'a pas cette visibilité, ou si plusieurs prestataires sont intervenus sans documentation laissée, un audit technique ciblé permet de clarifier la situation avant qu'un incident ne survienne. Performeer PrestaShop met en relation les dirigeants de TPE et PME avec des prestataires spécialisés, sans engagement, pour sécuriser ce type d'intervention technique sur mesure.