Back-office PrestaShop lent sur gros catalogue : diagnostic, solutions et prévention

Votre PrestaShop tourne très bien côté front, mais le back-office met 8 secondes à charger la liste des produits ? Si vous avez plus de 10 000 références, vous connaissez le problème. Ce n’est pas votre serveur. Ce n’est pas vraiment PrestaShop. C’est une combinaison de causes très identifiables — et heureusement, très solvables.

C’est l’un des sujets qu’on traite le plus en audit. Une boutique tourne nickel côté front, les clients passent commande sans ralentissement perceptible… mais dès que l’équipe ouvre le back-office pour gérer le catalogue, c’est une autre histoire.

👉 Liste produits : 8 secondes.
👉 Édition fiche produit : 5 secondes pour charger.
👉 Recherche commande : « merci de patienter… » pendant 15 secondes.

Et personne ne comprend vraiment pourquoi.

Un back-office PrestaShop lent, ce n’est jamais « normal » passé un certain volume. C’est le symptôme d’un problème mesurable, identifiable, et corrigeable.

Chez Mintfull, on a fait ce diagnostic des dizaines de fois. Voici ce qu’on trouve concrètement, et comment on règle le problème.

Pourquoi le back-office PrestaShop devient lent

Le back-office n’est pas qu’une interface d’administration. C’est une application complète qui exécute :

• Des requêtes SQL souvent plus lourdes que celles du front
• Des appels à des modules qui se branchent sur les hooks admin
• Du rendu Symfony complet sur PrestaShop 8 et 9
• Des opérations de calcul (stocks, prix multi-boutique, taxes)

👉 Sur une petite boutique, on ne le voit pas. Sur un catalogue de 20 000 produits, chaque maillon faible devient visible.

Les 5 vrais coupables qu’on identifie à chaque audit

Sur 9 audits sur 10, on retrouve la même combinaison de causes :

1. Requêtes SQL non optimisées : SELECT *, jointures abusives, absence d’index, recalculs systématiques
2. Modules mal codés branchés sur les hooks admin : un module qui charge tout le catalogue à chaque ouverture du BO
3. Table ps_search_index obèse : plusieurs millions de lignes non purgées
4. Logs et debug actifs en production : _PS_MODE_DEV_ = true oublié
5. OPcache désactivé ou mal configuré côté serveur

👉 Aucun de ces points n’est dramatique pris isolément. C’est leur cumul qui rend le back-office inutilisable.

Comment identifier le vrai coupable chez vous

Avant de tout optimiser à l’aveugle, il faut mesurer. Sinon on perd du temps sur des chantiers qui n’apporteront rien.

1. Activer le profiler PrestaShop temporairement

Sur un environnement de staging (jamais en prod), activez le mode debug et le profiler PrestaShop :

• Ouvrez config/defines.inc.php
• Passez _PS_DEBUG_PROFILING_ à true
• Rechargez les pages problématiques du back-office

Vous obtenez en bas de page :

• Temps total d’exécution
• Nombre de requêtes SQL exécutées
• Mémoire consommée
• Modules chargés

👉 Si vous voyez plus de 500 requêtes SQL pour afficher la liste des produits, vous avez trouvé un coupable.

2. Identifier les requêtes lentes côté MySQL

Activez le slow query log MySQL sur 24 à 48 heures, avec un seuil à 1 seconde. Analysez ensuite avec un outil comme pt-query-digest (Percona Toolkit) :

• Quelles requêtes reviennent le plus souvent ?
• Quelles requêtes consomment le plus de temps cumulé ?
• Y a-t-il des full table scans visibles dans EXPLAIN ?

👉 9 fois sur 10, on isole 3 à 5 requêtes qui pèsent à elles seules 70 % du problème.

3. Auditer les modules branchés sur les hooks admin

Les hooks à surveiller en priorité :

• actionAdminControllerSetMedia
• displayBackOfficeHeader
• actionDispatcher
• actionAdminProductsListingFieldsModifier

👉 Listez les modules qui s’y branchent, désactivez-les un par un dans un environnement de test, et mesurez l’impact. Vous trouverez souvent un module qui pèse à lui seul 2 à 3 secondes.

Notre méthode pour récupérer 70 à 80 % de temps de chargement

Une fois le diagnostic posé, on intervient dans cet ordre précis. L’ordre compte : commencer par le bas du stack donne des gains immédiats sans toucher au code applicatif.

Étape 1. Le socle serveur

• PHP 8.4 activé avec OPcache correctement tuné (memory à 256 Mo minimum, validation timestamps à off en prod)
• MySQL/MariaDB avec InnoDB buffer pool à 60-70 % de la RAM disponible
• Désactivation du mode debug en production (_PS_MODE_DEV_ à false)

👉 Gain typique observé : 30 à 40 % de temps de chargement BO récupéré.

Étape 2. La base de données

On intervient sur :

• L’ajout d’index sur les requêtes lentes identifiées (toujours mesurer avant/après avec EXPLAIN)
• Le nettoyage de la table ps_search_index (suppression et reconstruction)
• La purge des connexions clients obsolètes (ps_connections, ps_connections_source)
• L’archivage des commandes anciennes si la volumétrie l’exige

👉 Sur une boutique avec 5 ans d’historique non purgé, c’est souvent 20 % supplémentaires de récupérés.

Notre guide d’optimisation SQL PrestaShop détaille les requêtes les plus rentables à traiter.

Étape 3. Les modules problématiques

Pour chaque module identifié comme lourd :

1. Demander à l’éditeur s’il existe une version optimisée
2. Désactiver le module si la fonctionnalité n’est plus utilisée
3. Refactorer en interne si c’est un module custom maintenu par votre équipe
4. Le remplacer si aucune des trois premières options n’est viable

👉 Gain typique : 10 à 20 %.

Étape 4. Le cache applicatif

• Activation et tuning de Redis ou Memcached pour le cache PrestaShop
• Vérification que le cache « Smart cache for CSS/JS » est activé
• Configuration du cache Symfony en production

👉 Souvent négligé, ce dernier réglage peut représenter 5 à 10 % supplémentaires.

Comment anticiper et ne plus jamais en arriver là

Corriger un back-office lent, c’est important. Ne plus jamais en arriver là, c’est mieux. Voici ce qu’on met en place chez les clients en TMA.

1. Une surveillance proactive plutôt que réactive

Mettre en place un monitoring de :

• Temps de réponse des principales pages du back-office
• Nombre et durée des requêtes SQL lentes
• Volume des tables qui grossissent dangereusement (ps_search_index, ps_log, ps_connections)
• Erreurs PHP et Symfony loggées (via Monolog + Sentry/Bugsnag)

👉 L’objectif : détecter la dérive avant qu’elle ne devienne handicapante.

2. Une revue trimestrielle des modules actifs

Tous les 3 mois, on passe en revue :

• Quels modules sont encore vraiment utilisés ?
• Lesquels n’ont pas été mis à jour depuis 12 mois ?
• Lesquels ont un impact mesurable sur les performances BO ?

👉 Un module désactivé proprement, c’est toujours du temps gagné.

3. Un budget de maintenance préventive dédié

C’est tout l’intérêt d’un contrat TMA bien pensé. Quelques heures par mois consacrées à la performance évitent les « campagnes d’optimisation d’urgence » à plusieurs milliers d’euros.

4. Une politique de purge automatique

Programmer des tâches cron qui :

• Purgent les tables de logs régulièrement
• Reconstruisent l’index de recherche selon une fréquence raisonnable
• Suppriment les sessions et paniers expirés
• Archivent les commandes au-delà d’un seuil défini

👉 C’est du quasi-gratuit côté coût, et ça évite que la base devienne ingérable.

Notre avis chez Mintfull

Un back-office lent, c’est rarement un problème technique isolé. C’est le symptôme visible d’un défaut de maintenance préventive sur plusieurs mois ou années.

On peut toujours corriger en urgence. Mais le vrai gain, c’est de mettre en place une hygiène de maintenance qui empêche le problème de revenir.

Quand on prend une boutique en charge, l’optimisation du back-office figure presque toujours dans les 30 premiers jours. Pas parce que c’est urgent. Parce que c’est l’outil de travail quotidien de vos équipes, et qu’un BO rapide, c’est plusieurs heures gagnées par semaine, par utilisateur.

👉 Faites le calcul : 5 utilisateurs × 30 minutes perdues par jour × 220 jours ouvrés, ça fait plus de 500 heures de productivité par an. Le ROI de l’optimisation est rarement contestable.

Conclusion : un back-office rapide, c’est une décision, pas un hasard

Un PrestaShop bien configuré, bien maintenu et bien surveillé reste rapide même sur de gros volumes. La lenteur du back-office n’est pas une fatalité, c’est un signal.

👉 Le bon ordre des choses :

1. Mesurer avant d’optimiser
2. Corriger du bas du stack vers le haut (serveur, base, modules, cache)
3. Surveiller en continu pour ne plus subir
4. Anticiper avec une maintenance préventive sérieuse

Vos équipes méritent un outil de travail rapide. Vos données aussi.

FAQ : back-office PrestaShop lent

À partir de quel volume de produits le back-office devient-il lent ?

Il n’y a pas de seuil universel, mais on observe des ralentissements significatifs dès 5 000 à 10 000 références sur une configuration non optimisée. Au-delà de 50 000 produits, l’optimisation devient indispensable, peu importe l’infrastructure.

Faut-il changer d’hébergeur pour résoudre un back-office lent ?

Rarement. Dans 80 % des cas, le problème vient de la configuration logicielle (PHP, MySQL, cache, modules), pas du matériel. Changer d’hébergeur sans corriger ces causes ne donne qu’un répit temporaire.

Le mode debug PrestaShop ralentit-il vraiment le back-office ?

Oui, et significativement : entre 30 et 50 % de surcoût selon les pages. Le mode debug doit être strictement réservé aux environnements de développement et de test, jamais activé en production.

Combien de temps prend une optimisation complète du back-office ?

Sur une boutique standard avec un diagnostic clair, comptez 2 à 5 jours de travail effectif réparti sur 2 à 3 semaines (le temps des tests et validations). Sur une boutique très chargée ou avec beaucoup de modules custom, le chantier peut s’étaler sur 1 à 2 mois.

Le passage à PrestaShop 9 améliore-t-il les performances du back-office ?

Oui, principalement grâce à Symfony 6.4 et à PHP 8.4. Mais une migration ne corrige pas magiquement un back-office mal optimisé : si la base, les modules et le cache restent négligés, la lenteur reviendra rapidement.

Votre back-office PrestaShop est devenu inutilisable et vos équipes perdent du temps chaque jour ?

👉 Notre agence PrestaShop intervient avec une méthode rodée : diagnostic mesuré, optimisations priorisées par impact, mise en place d’une surveillance pérenne. Le tout sans toucher au front ni perturber vos ventes.

Parce qu’un back-office rapide, ce n’est pas du confort. C’est de la productivité.