# Des modules qui ralentissent la boutique

> « J’ai trop de modules » est un diagnostic courant et rarement exact. Une boutique peut en compter beaucoup et rester rapide, ou n’en compter que quelques-uns et ramer. Ce qui pèse, ce n’est pas le nombre : c’est ce que chacun exécute à chaque page vue.

- Source canonique : [https://allaux.fr/modules/modules-qui-ralentissent-la-boutique](https://allaux.fr/modules/modules-qui-ralentissent-la-boutique)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Sur une copie du site, passez _PS_DEBUG_PROFILING_ à true dans config/defines.inc.php : PrestaShop affiche alors en bas de chaque page le temps consommé par chaque hook et le nombre de requêtes SQL, module par module. Le coupable est presque toujours greffé sur actionFrontControllerSetMedia ou sur l’affichage produit ; ce n’est pas le nombre total de modules.

## Les trois façons dont un module coûte du temps

Les requêtes à la base. Un module accroché à l’affichage des produits qui interroge la base une fois par produit transforme une page de catégorie en dizaines de requêtes supplémentaires. Cette erreur de conception, appelée requête en boucle, ne se voit pas sur une boutique de démonstration et devient visible dès que le catalogue grossit.

Les ressources chargées dans la page. Chaque module qui ajoute sa feuille de style et son script alourdit toutes les pages, y compris celles où il ne sert à rien. Un module de comparateur qui charge ses ressources sur la page de paiement en est l’exemple typique.

Les appels vers l’extérieur pendant l’affichage. C’est le plus coûteux et le plus sournois : un module qui interroge un service tiers au moment de construire la page fait attendre le visiteur aussi longtemps que ce service met à répondre. Le jour où le service est lent, votre boutique l’est aussi, sans qu’aucun changement n’ait été fait chez vous.

## Comment j’attribue le temps perdu à un module précis

1. **Activer le profilage de la plateforme** — PrestaShop dispose d’un mode de débogage qui affiche, pour chaque page, le nombre de requêtes SQL, leur durée et le temps consommé par chaque point d’accroche. C’est la mesure la plus directe, et elle nomme le module.
2. **Regarder les requêtes lentes côté serveur** — Le journal des requêtes lentes de la base de données remonte les requêtes coûteuses avec leur texte. On y reconnaît immédiatement le module qui les produit à ses noms de tables.
3. **Séparer le temps serveur du temps navigateur** — Une page longue à afficher n’est pas toujours une page longue à générer. L’onglet réseau du navigateur distingue le temps d’attente de la première réponse du temps de chargement des ressources.
4. **Désactiver et remesurer, sur une copie** — La mesure avant et après est la seule preuve. Je la fais sur une copie du site, jamais en production, et sur les mêmes pages avec le même état de cache.

## Le back-office lent et le front lent n’ont pas les mêmes causes

> Une administration lente vient le plus souvent de requêtes non indexées sur des tables devenues volumineuses, ou d’un module qui recalcule des statistiques à chaque chargement. Le front, lui, souffre surtout du nombre de ressources chargées et des appels extérieurs. Traiter l’un ne corrige pas l’autre, et il faut savoir lequel des deux gêne réellement avant d’engager du travail.

## Ce que je fais une fois le module identifié

Rarement une désinstallation pure et simple : le module rend un service, et le retirer déplace le problème vers l’exploitation quotidienne. Trois corrections donnent des résultats mesurables. Limiter le chargement des ressources aux pages où le module sert réellement, ce qui se règle dans son code sans toucher à sa fonction. Mettre en cache le résultat des appels extérieurs, pour que le service tiers soit interrogé périodiquement plutôt qu’à chaque visite. Remplacer une requête en boucle par une requête unique, ce qui est la correction la plus rentable quand le catalogue est important.

Quand aucune de ces trois pistes n’est possible parce que le module est encodé ou verrouillé par sa licence, la question devient un choix : remplacer le module, ou accepter son coût. Je le dis clairement plutôt que de facturer une optimisation qui ne peut pas aboutir.

## Pages liées

- **Diagnostiquer une boutique lente** — La méthode complète, au-delà des seuls modules. ([/guides/diagnostiquer-boutique-lente](/guides/diagnostiquer-boutique-lente))
- **Boutique PrestaShop lente** — Les causes propres à PrestaShop, dont le cache et les requêtes SQL. ([/prestashop/boutique-lente](/prestashop/boutique-lente))
- **Administration WordPress très lente** — Le cas particulier du back-office, souvent confondu avec la lenteur du site. ([/wordpress-woocommerce/problemes/admin-wordpress-tres-lent](/wordpress-woocommerce/problemes/admin-wordpress-tres-lent))
- **Audit du parc de modules** — L’inventaire qui précède toute décision de retrait ou de remplacement. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### Combien de modules est-ce trop ?

Il n’existe pas de nombre. Une boutique peut en avoir beaucoup et rester rapide si chacun se limite aux pages où il sert. Le bon indicateur est le temps de génération d’une page, pas la longueur de la liste.

### Désactiver un module suffit-il à récupérer la performance ?

Souvent oui pour le temps de génération, mais pas toujours : un module désactivé peut laisser des tables volumineuses et des tâches planifiées actives. La désinstallation complète est différente de la simple désactivation.

### Un module de cache peut-il compenser un module lent ?

Il masque le problème sur les pages mises en cache et le laisse entier ailleurs : panier, compte client, tunnel de commande, back-office. Ce sont précisément les pages où la lenteur coûte le plus cher.

### Comment savoir si la lenteur vient d’un module ou de l’hébergement ?

En comparant le temps de génération de la page avec le temps d’attente réseau. Si la page est générée rapidement mais arrive lentement, la piste est l’hébergement ou le réseau ; si elle met du temps à être générée, la piste est le code exécuté, donc les modules.