Sur PrestaShop, les modules sont à la fois la force et la faiblesse de la plateforme. Ils permettent presque tout — et ils peuvent presque tout casser, parce qu’ils ont le droit de surcharger des classes du cœur, de se greffer sur n’importe quel point d’accroche et d’ajouter leurs propres tables.
Quand une boutique se met à mal fonctionner après une installation ou une mise à jour, le module est le premier suspect. Encore faut-il désigner le bon, et le neutraliser sans supprimer au passage une fonctionnalité dont dépend l’activité.
Voici la démarche que j’applique, et les pièges qui coûtent le plus cher.
Réponse rapide
Isolez d’abord : désactivez le module suspect depuis le back-office, ou renommez son dossier dans modules/ si le back-office est inaccessible, puis videz var/cache/. Si la boutique revient, vous tenez le responsable. Vérifiez ensuite s’il pose un conflit d’override (dossier override/), s’il est compatible avec votre version de PrestaShop et de PHP, et s’il ne fait pas doublon avec un autre module. Pour retirer définitivement un module, désinstallez-le depuis le back-office avant de supprimer ses fichiers — sinon il laisse des overrides, des tables et des greffes orphelines.
Pourquoi un module peut casser toute une boutique
Un module PrestaShop n’est pas une simple extension isolée. Il dispose de quatre leviers, et chacun est une source de panne potentielle.
Les greffes (hooks). Le module s’accroche à des points précis de l’exécution : affichage d’une page, validation d’une commande, mise à jour d’un stock. Si son code échoue à cet endroit, c’est toute la page — voire tout le processus de commande — qui s’arrête.
Les surcharges (overrides). Un module peut réécrire le comportement d’une classe du cœur en déposant un fichier dans override/. Deux modules qui surchargent la même classe entrent en conflit : le second installé écrase le premier, ou l’installation échoue silencieusement.
Les tables et champs en base. Un module crée ses propres tables. Supprimer ses fichiers sans le désinstaller laisse ces tables derrière lui, parfois avec des déclencheurs qui continuent de s’exécuter.
Les ressources chargées en façade. Un module peut ajouter son CSS et son JavaScript sur toutes les pages, même celles où il ne sert à rien. C’est une cause majeure de lenteur — j’en parle plus en détail dans l’article sur les boutiques PrestaShop lentes.
Isoler le module fautif
Si le back-office est accessible
Désactivez le module suspect (ne le désinstallez pas : la désactivation est réversible sans perte de configuration), videz le cache, testez la boutique en navigation privée.
Si vous ne savez pas lequel accuser, procédez par dichotomie : désactivez la moitié des modules récemment installés, testez, puis affinez. C’est plus rapide qu’un par un dès que la liste dépasse la dizaine.
Si le back-office est inaccessible
Par FTP, renommez le dossier du module : modules/monmodule devient modules/monmodule_off. PrestaShop ne le trouve plus et cesse de l’exécuter. Supprimez ensuite le contenu de var/cache/ et rechargez.
Attention : la boutique peut afficher une erreur si un gabarit du thème appelle explicitement ce module. C’est justement l’information que vous cherchez — elle vous dit où le module était utilisé.
Confirmer avant de conclure
Une fois le module identifié, réactivez-le pour vérifier que le problème revient. Cela peut sembler contre-intuitif, mais c’est la seule façon d’être certain d’avoir trouvé la cause plutôt qu’une coïncidence. Faites-le à un moment creux de votre activité.
Les quatre situations les plus fréquentes
Le module invisible
Il est installé, activé, configuré — et rien ne s’affiche. Dans la quasi-totalité des cas, il n’est pas greffé au bon endroit, ou le thème n’appelle pas le point d’accroche attendu. Vérifiez dans Apparence → Positions que le module est bien greffé, et que le hook existe dans votre thème.
Point important : un module inactif ou mal greffé ne produit aucun message d’erreur. Le bloc disparaît en silence, et on peut chercher longtemps du côté du CSS avant de penser à la greffe. Réflexe utile : compter les éléments réellement rendus plutôt que de se fier à l’impression visuelle.
Le conflit d’overrides
Deux modules surchargent la même classe. Symptôme : l’un des deux cesse de fonctionner après l’installation de l’autre, sans erreur. Ouvrez override/classes/ et override/controllers/ : les fichiers y sont nommés d’après la classe surchargée. Si un fichier contient du code manifestement issu de deux modules différents, vous avez trouvé.
La résolution demande de fusionner les deux surcharges à la main, ou de faire passer l’une des deux fonctionnalités par une greffe plutôt que par un override. C’est du travail de développeur, mais c’est la seule issue propre.
Le module incompatible
Acheté pour PrestaShop 1.7, installé sur une 8, ou conçu pour PHP 7.4 et exécuté en PHP 8.2. Les messages typiques mentionnent une méthode indéfinie ou une erreur de syntaxe. Vérifiez la compatibilité annoncée par l’éditeur avant d’acheter, et exigez une version compatible plutôt que de bricoler la sienne.
Le module orphelin
Ses fichiers ont été supprimés sans désinstallation préalable. Résultat : PrestaShop garde en base la trace d’un module qui n’existe plus. Cela peut bloquer la page des modules, celle des moyens de paiement, ou l’inscription client — avec des symptômes qui n’ont aucun rapport apparent avec le module disparu.
C’est un cas que je rencontre souvent sur les boutiques reprises après plusieurs prestataires. Le nettoyage passe par la base de données, avec une sauvegarde préalable obligatoire.
Désinstaller proprement
L’ordre compte, et il n’est pas intuitif :
- Sauvegardez fichiers et base.
- Désinstallez depuis le back-office. C’est cette étape qui déclenche la routine de nettoyage du module : retrait des greffes, suppression des overrides qu’il a déposés, suppression éventuelle de ses tables.
- Vérifiez
override/: certains modules mal écrits ne retirent pas leurs surcharges. Le fichier restant peut casser la boutique après la suppression des fichiers du module. - Supprimez le dossier dans
modules/. - Videz
var/cache/. - Testez une commande complète, pas seulement l’affichage de la page d’accueil.
Supprimer le dossier avant de désinstaller est l’erreur la plus fréquente — et celle qui crée les modules orphelins évoqués plus haut.
Limiter le risque à l’avenir
Testez en préproduction. Un module s’installe d’abord sur une copie de la boutique. C’est le seul moyen de découvrir un conflit avant vos clients.
Installez un module à la fois. Trois modules installés le même jour, et une panne le lendemain : vous n’avez plus de coupable évident.
Préférez les modules maintenus. Regardez la date de la dernière mise à jour et les versions de PrestaShop supportées. Un module abandonné depuis trois ans est une dette technique qui vous rattrapera à la prochaine montée de version.
Tenez un journal des modifications. Une simple ligne par intervention, avec la date. Quand quelque chose casse, savoir ce qui a changé la veille fait gagner des heures.
Questionnez l’accumulation. Un besoin très spécifique couvert par un module générique et lourd mérite souvent un développement sur mesure : moins de code chargé, aucune dépendance à un éditeur tiers, et un comportement exactement conforme à votre besoin.
Checklist
- Sauvegarder fichiers et base avant toute manipulation
- Noter ce qui a été installé ou mis à jour récemment
- Désactiver plutôt que désinstaller pour isoler
- Vider
var/cache/après chaque changement - Inspecter
override/pour repérer les conflits - Vérifier les greffes dans Apparence → Positions
- Confirmer la cause en réactivant le module suspect
- Désinstaller depuis le back-office avant de supprimer les fichiers
- Tester une commande complète après nettoyage
Questions fréquentes
Puis-je supprimer un dossier de module par FTP ?
Pour isoler temporairement, renommez-le plutôt que de le supprimer : c’est réversible. Pour un retrait définitif, désinstallez toujours depuis le back-office d’abord, sinon vous laissez des greffes, des overrides et des tables orphelines qui causeront des problèmes plus tard.
Comment savoir quel module ralentit ma boutique ?
En regardant ce que chaque page charge réellement : les scripts et feuilles de style ajoutés, et par quel module. Le profilage intégré de PrestaShop, activé sur un environnement de test, indique aussi le temps consommé par chaque greffe. J’en détaille la méthode dans l’article sur les lenteurs PrestaShop.
Un module gratuit est-il plus risqué ?
Pas nécessairement. Ce qui compte, c’est la qualité du code et la régularité de la maintenance, pas le prix. J’ai vu des modules payants écrits avec une désinvolture surprenante, et des modules gratuits très bien tenus.
Le module fonctionne chez l’éditeur mais pas chez moi. Pourquoi ?
Parce qu’une boutique en production n’est jamais une installation neuve : thème modifié, overrides existants, autres modules greffés aux mêmes endroits, version de PHP différente. La démonstration de l’éditeur tourne sur un environnement propre — c’est rarement le vôtre.
Faut-il faire développer un module sur mesure ?
Quand un besoin précis est mal couvert par les modules du marché, oui : vous chargez moins de code, vous ne dépendez d’aucun éditeur, et le comportement correspond exactement à ce que vous voulez. Pour un besoin standard, un bon module du marché reste plus économique.