Votre boutique ralentit. Le back-office met 8 secondes à charger. Les sauvegardes plantent en timeout. Et un matin, c’est l’erreur 500 — ou pire, votre hébergeur suspend le site parce que le quota disque est dépassé.
Le coupable ? Presque toujours le même. Une base de données qui a triplé de volume en deux ans. Sans que personne ne s’en rende compte.
Chez CYBERIAL, c’est la cause de ralentissement qu’on diagnostique le plus souvent quand on reprend une boutique PrestaShop. Et pourtant, c’est la plus simple à corriger ! Encore faut-il savoir quoi nettoyer, quoi ne surtout pas toucher, et comment faire pour que le problème ne revienne pas tous les six mois.
C’est exactement ce qu’on va voir dans cet article. Pas une liste de requêtes SQL à copier-coller (ça, il y en a partout). Un vrai guide qui explique pourquoi votre base grossit, quelles tables vous pouvez vider sans risque, lesquelles sont piégées, et comment automatiser le nettoyage pour ne plus y penser.
Pourquoi la base de données PrestaShop grossit ?
PrestaShop enregistre tout. Chaque visite sur votre site crée une ligne dans ps_connections. Chaque page vue : une ligne dans ps_connections_page. Chaque visiteur non connecté : une ligne dans ps_guest. Chaque source de trafic : ps_connections_source. Chaque erreur 404 : ps_pagenotfound. Chaque recherche interne : ps_statssearch. Chaque email envoyé : ps_mail. Chaque action dans le back-office : ps_log.
Et PrestaShop ne nettoie jamais.
Faisons le calcul. Votre boutique reçoit 500 visites par jour — c’est modeste pour un e-commerce actif. Chaque visite alimente 4 à 5 tables. Sur un an, ça fait environ 900 000 lignes rien que pour le suivi des connexions. Sur deux ans sans nettoyage, vous dépassez facilement les 2 millions de lignes — et votre base passe de 200 Mo à 2 ou 3 Go. J’ai vu des boutiques à 8 Go et plus de 20 millions de lignes.
Ce qui est pervers, c’est que ça ne se voit pas au quotidien. Le ralentissement est progressif — 1 seconde de plus tous les trimestre. Vous vous habituez. Jusqu’au jour où une sauvegarde qui prenait 2 minutes en met maintenant 20. Ou que votre hébergeur mutualisé vous coupe parce que vous avez explosé votre quota MySQL.
Au passage : le module officiel « PrestaShop Cleaner » (aussi appelé « Database Cleaner ») a été abandonné par PrestaShop en mars 2021. Abandonné, pas remplacé. Si vous le cherchez encore sur Addons, vous ne le trouverez plus. Les marchands sont livrés à eux-mêmes — et la plupart ne le savent même pas.
Et c’est cette même base de données gonflée qui est derrière les erreurs 500 quand MySQL timeout, les pages blanches quand le disque est plein, et les ralentissements progressifs que tout le monde met sur le dos de l’hébergeur !
Mon conseil : avant d’acheter un serveur plus cher, vérifiez la taille de votre base de données. Ouvrez phpMyAdmin, sélectionnez votre base, triez les tables par taille. Si ps_connections ou ps_guest pèsent plus de 100 Mo, vous tenez votre coupable.
Quelles tables vider dans la base de données PrestaShop ?
C’est LA question que tout le monde se pose et à laquelle aucun site et aucune vidéo Youtube ne répond jamais. Les articles que vous trouvez en ligne vous donnent une liste de TRUNCATE à exécuter. Mais ils ne vous disent pas que certaines tables sont piégées — et qu’un TRUNCATE brutal peut casser des fonctionnalités de votre boutique.
On va faire autrement. Voici le classement qu’on utilise en interne chez CYBERIAL. Trois catégories, trois couleurs. Pas d’ambiguïté pour vous aider à nettoyer votre base de données PrestaShop.
Les tables qu’on peut vider sans risque 🟢 TRUNCATE direct
Ces tables ne contiennent que des données de suivi et de statistiques. Elles n’ont aucun lien avec vos commandes, vos clients ou votre catalogue. Si vous utilisez Google Analytics ou Matomo pour vos statistiques (et vous devriez), ces données ne vous servent strictement à rien.
| Table | Ce qu’elle contient | Taille typique après 2 ans |
|---|---|---|
ps_connections | Une ligne par visite | 500 Mo à 2 Go |
ps_connections_page | Pages vues par visite | 500 Mo à 3 Go |
ps_connections_source | Source de chaque visite | 100 à 500 Mo |
ps_guest | Sessions visiteurs anonymes | 200 Mo à 1 Go |
ps_pagenotfound | Chaque erreur 404 (les bots en génèrent des tonnes) | 50 à 500 Mo |
ps_statssearch | Recherches internes des visiteurs | 10 à 100 Mo |
ps_log | Logs système du back-office | 50 à 300 Mo |
ps_mail | Historique de chaque email envoyé | 20 à 200 Mo |
Action : ouvrez phpMyAdmin, sélectionnez ces tables, et cliquez sur « Vider » (TRUNCATE). C’est fait en 30 secondes. Zéro risque si vous avez fait une sauvegarde avant (et vous devez en faire une avant, toujours).
Ne soyez pas surpris par le résultat. Sur les boutiques qu’on nettoie pour la première fois, la base diminue de 60 à 90 %. Car les données de statistiques représentent souvent 80 % du volume total de la base.
Les tables qu’on vider avec précaution 🟠 DELETE conditionnel
Ces tables contiennent des données qui peuvent être liées à des fonctionnalités actives. Un TRUNCATE brutal peut casser des choses. Il faut un DELETE ciblé, pas un nettoyage aveugle.
ps_cart et ps_cart_product — Les paniers.
Attention : PrestaShop garde tous les paniers, y compris ceux qui n’ont jamais abouti à une commande. Sur une boutique active, ça se compte en centaines de milliers de lignes. Mais on ne peut pas tout supprimer — les paniers liés à des commandes doivent rester (ils sont référencés dans ps_orders), et les paniers récents de visiteurs en cours de navigation aussi.
La règle : supprimer uniquement les paniers de plus de 30 jours qui ne sont liés à aucune commande. En SQL, ça donne :
DELETE FROM ps_cart WHERE id_cart NOT IN (SELECT id_cart FROM ps_orders) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
ps_guest (en mode ciblé)
J’ai classé ps_guest en vert pour le TRUNCATE, mais il y a un piège que je dois mentionner (c’est documenté sur GitHub par des développeurs). ps_guest est lié à ps_cart pour les visiteurs non connectés.
Si vous faites un TRUNCATE brutal pendant que des visiteurs anonymes ont des paniers en cours, ces paniers perdent leur lien. En pratique, ça ne casse pas la boutique — mais les visiteurs en cours de navigation perdent leur panier.
Si votre boutique a beaucoup de trafic, préférez un DELETE conditionnel qui ne touche que les guests de plus de 7 jours.
ps_specific_price — Les prix spécifiques
Ce sont lespromotions, prix par client, par groupe, etc. Vous pouvez supprimer les prix expirés :
DELETE FROM ps_specific_price WHERE `to` != '0000-00-00 00:00:00' AND `to` < NOW();
Les tables à ne jamais toucher 🔴
ps_orders,ps_order_detail— Vos commandes.ps_customer,ps_address— Vos clients.ps_product,ps_product_attribute,ps_category— Votre catalogue.ps_configuration— La config de votre boutique.ps_layered_filter_block— Les filtres de navigation. Cette table peut être grosse, mais elle est utilisée en permanence par le front-office. Si vous la videz = ça casse la navigation à facettes.
La tentation de vider ps_layered_filter_block revient souvent dans les forums parce qu’elle peut peser lourd. Ne le faites pas — ou alors, régénérez les index de filtres juste après (Catalogue → Attributs et caractéristiques → Indexer tout). Mais franchement, sur ce sujet, mieux vaut ne pas y toucher si vous ne maîtrisez pas.
Focus sur ps_cart_rule_combination
C’est la table dont aucun guide de nettoyage ne parle. Et c’est potentiellement la plus grosse de votre base.
Voici comment ça fonctionne. Quand vous créez un code promo dans PrestaShop et que vous le rendez « non cumulable » avec d’autres promotions, PrestaShop insère une ligne dans ps_cart_rule_combination pour chaque combinaison possible avec les autres règles. Si vous avez 100 règles de panier : 100 × 100 = 10 000 lignes. 1 000 règles : 1 000 × 1 000 = 1 million de lignes. C’est une croissance mathématique exponentielle facile à comprendre.
Un forum PrestaShop rapporte 167 millions de lignes. Et le pire ? C’est un bug de conception connu depuis 2011. Il n’a jamais été corrigé dans le cœur du logiciel.
Vous êtes particulièrement exposé si vous utilisez des modules marketing qui créent des règles de panier « à la volée » — parrainage, affiliation, codes promo automatiques par email. Ces modules peuvent générer des centaines de règles par semaine. Et chaque nouvelle règle multiplie les combinaisons.
Comment vérifier : dans phpMyAdmin, cherchez ps_cart_rule_combination et regardez sa taille. Si elle pèse plus de 100 Mo, vous avez un problème. Si elle pèse plus de 1 Go, c’est une urgence.
Comment nettoyer : commencez par supprimer les règles de panier expirées ou inutilisées (dans le back-office : Catalogue → Réductions → Règles panier). Chaque règle supprimée devrait aussi supprimer ses combinaisons. Si ça ne suffit pas (parce que les combinaisons orphelines restent), certains modules de nettoyage comme celui de Comonsoft gèrent spécifiquement cette table. Attention, nous ne l’avons pas testé sur PS 8 et 9.
Comment éviter le problème : quand vous créez un code promo, ne cochez pas « non cumulable » par défaut. Ne le faites que si c’est vraiment nécessaire. Et pensez à supprimer les règles de panier expirées régulièrement — PrestaShop ne le fait pas automatiquement.
Comment nettoyer la base de données PrestaShop ?
Méthode 1 — phpMyAdmin (pour ceux qui sont à l’aise)
C’est la méthode gratuite et directe.
- Sauvegardez votre base — phpMyAdmin → votre base → Export → SQL → Go. Gardez le fichier précieusement.
- Identifiez les tables volumineuses — Cliquez sur le nom de votre base, puis triez les tables par la colonne « Taille ». Les coupables sautent aux yeux.
- Nettoyez les tables vertes — Cochez-les, puis en bas de page : « Pour la sélection : Vider ».
- Nettoyez les tables oranges — Onglet SQL, collez les requêtes DELETE conditionnelles que j’ai données plus haut. Adaptez le préfixe si le vôtre n’est pas
ps_.
Le tout prend 5 à 10 minutes. Le résultat est immédiat — retournez sur votre back-office et vous sentirez la différence. Les sauvegardes aussi seront beaucoup plus rapides.
Méthode 2 — Un module de nettoyage (pour tout le monde)
Si le SQL vous fait peur (et c’est tout à fait normal pour un marchand), utilisez un module :
- mypresta.eu Database Optimization (gratuit) — Le plus simple. Interface basique, mais il gère les 5 tables principales et ne supprime que les paniers non liés à une commande. Supporte PS 1.6 à 9.x.
- Comonsoft Optimisation BDD (payant, ~20 €) — Déjà évoqué dans l’article, complet et pas cher. Gère
ps_cart_rule_combination, permet de planifier un nettoyage automatique par cron. Compatible PS 8.x et 9.x. - Mediacom87 Optimisation et nettoyage (payant, sur Addons) — Trop cher. Gère le nettoyage + la restauration en cas d’erreur. Interface détaillée avec statistiques avant/après.
- PrestaToolbox (payant) — Le plus avancé. Propose des « scénarios » de nettoyage (paniers, prix expirés, adresses orphelines, etc.) et l’automatisation par cron.
Mon avis : si vous ne faites le nettoyage qu’une fois et que vous êtes à l’aise avec phpMyAdmin, la méthode 1 suffit. Si vous voulez automatiser, investissez dans un module avec cron intégré — c’est 20 à 50 € pour des années de tranquillité.
⚠️ Dans les deux cas, sauvegarde avant. Je sais, je me répète. Mais on a vu des marchands vider la mauvaise table parce qu’ils avaient confondu ps_cart et ps_category. Une sauvegarde, c’est 2 minutes. Une restauration de catalogue depuis zéro, c’est des jours.
Comment automatiser le nettoyage de votre base de données PrestaShop ?
Nettoyer une fois, c’est bien. Mettre en place un nettoyage automatique, c’est ce qui fait la différence entre une boutique qui tient dans le temps et une qui retombe dans le même piège tous les 6 mois.
Option 1 — Un module avec tâche cron
Les modules Comonsoft et PrestaToolbox permettent de configurer une URL de cron que vous ajoutez dans le planificateur de tâches de votre hébergeur (cPanel → Tâches Cron, ou Plesk → Tâches planifiées). Vous définissez une fréquence (une fois par mois suffit) et le module se charge du nettoyage. Aucune intervention manuelle.
Option 2 — Un event MySQL planifié (pour les VPS)
Si vous avez un VPS ou un serveur dédié avec un accès MySQL direct, vous pouvez créer un event planifié qui nettoie automatiquement les tables. C’est une solution propre et gratuite :
CREATE EVENT `nettoyage_ps_connections`
ON SCHEDULE EVERY 1 MONTH
DO TRUNCATE TABLE ps_connections;
Vous créez un event par table à nettoyer. C’est propre, c’est natif MySQL, et ça tourne tout seul. Par contre, ça demande les privilèges EVENT sur votre serveur MySQL — ce que les hébergements mutualisés ne donnent généralement pas.
Option 3 — Le forfait maintenance
C’est la solution qu’on propose chez CYBERIAL. Dans le cadre du forfait maintenance et support PrestaShop à 69 €/mois, on inclut le nettoyage mensuel de la base de données, la surveillance des tables critiques (y compris ps_cart_rule_combination que personne ne surveille). Vous n’y pensez plus, on s’en occupe.
Une routine de maintenance BDD en 3 points
Pour ceux qui veulent gérer le nettoyage de leur base de données PrestaShop eux-mêmes, voici la routine minimale :
Une fois par mois — Connectez-vous à phpMyAdmin, triez les tables par taille. Si une table dépasse 100 Mo et qu’elle est dans la liste verte, nettoyez-la. Ça prend 30 secondes.
Une fois par trimestre — Nettoyez les tables oranges (paniers abandonnés, prix expirés). Et vérifiez la taille de ps_cart_rule_combination si vous utilisez des codes promo.
Tout de suite — Si vous utilisez Google Analytics ou Matomo (et vous devriez), allez dans votre back-office PrestaShop, Modules → cherchez « Data mining for statistics » et désactivez-le. C’est ce module natif qui alimente les tables ps_connections et ps_guest. En le désactivant, vous coupez le robinet à la source. Les données arrivent dans GA/Matomo de toute façon — PrestaShop n’a pas besoin de les stocker en double.
Pour une vue d’ensemble sur les pannes PrestaShop et les bonnes pratiques de maintenance, consultez notre page dépannage PrestaShop.
Votre base de données PrestaShop pèse plusieurs Go ? Notre équipe nettoie, optimise et met en place l’automatisation. Forfait dépannage à 150 €. On intervient 7j/7. Ligne directe : 09 72 03 59 17.
Et si vous ne voulez plus jamais vous poser la question : le forfait maintenance CYBERIAL à 69 €/mois inclut le nettoyage mensuel de la base de données, la surveillance des tables critiques, les sauvegardes quotidiennes et l’intervention prioritaire.
