Pourquoi un module PrestaShop désactivé peut-il continuer à ralentir le back-office ?

Un dirigeant constate que son back-office PrestaShop reste lent malgré la désactivation de plusieurs modules jugés inutiles. Ce phénomène, fréquent sur les boutiques actives depuis plusieurs années, s'explique par le fonctionnement interne de PrestaShop : désactiver un module via l'interface ne supprime ni son code, ni ses données, ni forcément toutes ses connexions au système.

La désactivation ne désinstalle pas le module

Dans PrestaShop, il existe une différence fondamentale entre désactiver et désinstaller un module. La désactivation (bouton toggle) se contente de modifier un champ active dans la table ps_module. Le code du module reste présent dans le dossier /modules/, ses tables SQL restent en base, et certains hooks peuvent rester enregistrés dans ps_hook_module selon la façon dont le module a été développé.

Concrètement, un module mal conçu peut continuer à exécuter des requêtes SQL ou des appels à des API externes même désactivé, si son code vérifie mal l'état active avant de s'exécuter sur certains hooks (notamment actionAdminControllerSetMedia ou displayBackOfficeHeader).

Les tâches CRON indépendantes de l'état du module

De nombreux modules installent des tâches planifiées (CRON) qui s'exécutent via une URL dédiée, indépendamment du statut actif/inactif du module dans l'admin. Un module de synchronisation d'export marketplace ou de calcul de statistiques peut ainsi continuer à tourner en arrière-plan, consommant des ressources serveur partagées avec le back-office et ralentissant les pages d'administration lors des pics d'exécution.

Les hooks et classes toujours chargés en mémoire

PrestaShop charge l'ensemble des classes des modules installés au démarrage de l'admin, via l'autoloader, même si le module est désactivé. Si le module compte de nombreuses classes, des overrides de classes core, ou des services enregistrés dans le conteneur Symfony (PrestaShop 1.7 et 8), cette charge de chargement s'ajoute au temps de réponse de chaque page admin, avant même toute vérification du statut actif.

Les overrides sont particulièrement problématiques : un module peut surcharger une classe native (Product, Order, Customer) et cette surcharge reste active tant que le fichier override n'est pas supprimé du dossier /override/, indépendamment de l'état du module dans l'admin.

Les tables et données orphelines qui alourdissent les requêtes

Un module désactivé laisse ses tables en base de données. Si ces tables sont volumineuses (journaux de logs, historiques de synchronisation, files d'attente non vidées) et qu'elles sont jointes dans des requêtes communes du back-office (listing produits, commandes, tableau de bord), elles continuent à peser sur les temps de réponse SQL, même sans lien direct avec le module lui-même.

• Tables de logs : certains modules de tracking ou d'emailing écrivent des milliers de lignes par jour, jamais purgées.
• Files d'attente : modules de synchronisation marketplace ou ERP avec des tables de queue non vidées après désactivation.
• Index manquants : tables ajoutées par le module sans index adapté, ralentissant les jointures du core.

Comment identifier et traiter le problème

Pour diagnostiquer précisément l'impact d'un module désactivé, plusieurs vérifications s'imposent :

• Consulter la table ps_hook_module pour vérifier si le module reste enregistré sur des hooks malgré sa désactivation.
• Vérifier le dossier /override/classes/ et /override/controllers/ pour repérer d'éventuels fichiers laissés par le module.
• Lister les tâches CRON actives (menu Paramètres avancés > Tâches planifiées ou crontab serveur) pour identifier celles liées au module désactivé.
• Activer le mode debug SQL (Paramètres avancés > Performance) pour repérer les requêtes lentes impliquant des tables du module.

La solution la plus propre reste la désinstallation complète plutôt que la simple désactivation, lorsque le module n'est plus utilisé. PrestaShop propose une procédure de désinstallation qui supprime en principe les hooks, les tables et les données associées, à condition que le développeur du module ait correctement implémenté la méthode uninstall(). Il est recommandé de sauvegarder la base avant toute désinstallation, certains modules mal codés ne nettoyant pas totalement leurs données.

Point de vigilance avant toute suppression

Avant de désinstaller un module, il convient de vérifier qu'aucune donnée critique n'y est liée (configurations de paiement, historiques comptables, paramètres de connecteurs ERP). Un test en environnement de préproduction permet de valider l'absence d'effet de bord sur le front-office ou les processus de commande.

Si le ralentissement persiste après ces vérifications, ou si l'audit technique dépasse les compétences internes, un prestataire PrestaShop qualifié peut réaliser un diagnostic complet (hooks, overrides, requêtes SQL, CRON) pour cibler précisément les causes. Performeer PrestaShop met en relation les dirigeants de boutiques avec des prestataires spécialisés, sans engagement, pour ce type d'intervention technique.