Une boutique PrestaShop en production depuis cinq ans pèse rarement moins de 6 Go en base de données. Beaucoup dépassent les 12 Go. Ce n’est pas le catalogue qui explose — un catalogue de 10 000 produits avec déclinaisons, images et SEO complet tient sous le gigaoctet. Ce qui gonfle, ce sont les tables ballast : des tables techniques que PrestaShop alimente en continu et qu’aucun process natif ne nettoie. Au bout de cinq ans, elles représentent souvent 70 à 90 % du poids total de la BDD.
Cet article cartographie les tables coupables, donne les requêtes SQL pour mesurer le gain potentiel, et explique comment mettre en place une politique de rétention durable sans casser la boutique. Pas une checklist de magazine — la version qu’on applique réellement en production.
Pourquoi une base PrestaShop gonfle sans bruit
PrestaShop n’a pas de garbage collector. Toutes les tables qui enregistrent des événements — recherches internes, connexions, paniers abandonnés, logs, métadonnées orphelines — grossissent linéairement, parfois exponentiellement, sans qu’aucun mécanisme natif ne déclenche un nettoyage.
Concrètement, sur une boutique avec 2 000 visiteurs/jour :
ps_statssearchreçoit 300 à 800 lignes par jour (chaque recherche interne, même vide).ps_connectionsetps_connections_pageenregistrent chaque visite et chaque page vue. Comptez 5 000 à 15 000 lignes par jour.ps_guestcrée un enregistrement pour chaque visiteur non authentifié.ps_cartgarde tous les paniers — abandonnés inclus — pour toujours. Sur certaines boutiques, on trouve 90 % de paniers vides datant de 2018.ps_logcapture toutes les erreurs et événements admin.
Multipliez par 365 jours et 5 ans : on parle de dizaines de millions de lignes pour un volume métier nul. Le poids brut n’est pas le pire problème. Le vrai coût est ailleurs.
Le coût caché des tables ballast
1. Performance des requêtes
InnoDB charge les index en mémoire (buffer pool). Quand des tables techniques de plusieurs Go monopolisent le buffer, vos requêtes catalogue, panier et commande deviennent plus lentes. Le LCP d’une fiche produit peut prendre 200 à 400 ms supplémentaires uniquement à cause de la pression mémoire MySQL.
2. Sauvegardes et restaurations
Un dump mysqldump de 12 Go prend 30 à 60 minutes selon le disque. La restauration peut prendre 2 à 4 heures. Si la sauvegarde automatique de votre hébergeur dépasse une fenêtre horaire, elle se met à échouer en silence. Beaucoup de boutiques découvrent qu’elles n’ont plus de sauvegarde valide le jour d’un incident.
3. Migrations bloquées
Migrer une boutique 12 Go en PHP 8.2 vers un nouveau serveur, ou en PrestaShop 9, demande de transférer le dump par rsync, de restaurer, de tester. Le poids démultiplie chaque opération. Les migrations « simples » deviennent des projets de plusieurs jours.
4. Modules tiers qui s’alourdissent
Certains modules de statistiques, de marketing, de connecteurs ERP créent leurs propres tables et les laissent grossir indéfiniment. ps_netreviews_, ps_advancedstats_, ps_mailchimp_ sont des suspects fréquents. Un audit révèle souvent une table de 2 Go laissée par un module désinstallé il y a deux ans.
Audit : combien pèse vraiment votre base
Avant tout nettoyage, on mesure. Cette requête liste les tables de votre base classées par taille décroissante :
SELECT
table_name AS 'Table',
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)',
table_rows AS 'Rows'
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 30;Vous obtenez en général un palmarès qui ressemble à :
ps_statssearch— 1,8 Gops_connections_page— 1,2 Gops_pagenotfound— 800 Mops_connections— 600 Mops_log— 400 Mops_cart— 350 Mops_guest— 300 Mops_cart_rule+ps_cart_cart_rule— 250 Mo
Notez que ps_product, ps_product_lang, ps_orders apparaissent rarement dans le top 10. La donnée métier réelle est minoritaire dans une base PrestaShop ancienne.
Cartographie des tables ballast et politique de rétention
ps_statssearch — les recherches internes
Cette table enregistre chaque mot saisi dans la barre de recherche. Garder l’historique au-delà de 90 jours n’a aucun intérêt analytique : les tendances de recherche sur 2019 n’éclairent rien en 2026. Politique recommandée : rétention 90 jours.
-- Audit
SELECT COUNT(*) AS total, MIN(date_add) AS plus_ancien
FROM ps_statssearch;
-- Suppression au-delà de 90 jours
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_connections et ps_connections_page — l’historique de visite
Si vous utilisez GA4 ou Matomo, ces tables sont redondantes. PrestaShop les remplit pour son propre module de statistiques que personne ne consulte. Politique : rétention 30 jours, ou 0 si vous avez un outil externe.
ps_pagenotfound — les 404
Utile pour identifier les liens cassés et programmer des redirections 301. Mais après traitement, l’historique ne sert plus. Politique : rétention 60 jours, après extraction des 404 récurrentes.
ps_cart — les paniers abandonnés
Subtil. Les paniers récents servent au retargeting et aux relances. Au-delà de 90 jours, un panier abandonné est statistiquement perdu. Politique : conserver 90 jours, mais ne pas toucher aux paniers liés à des commandes (table jointe ps_orders.id_cart).
-- Suppression sûre : uniquement les paniers SANS commande associée
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_guest — les visiteurs non authentifiés
Liée à ps_customer et ps_connections. Nettoyage avec précaution : un guest converti en customer doit être préservé. Politique : supprimer les guests sans customer et sans connexion récente.
ps_log — les logs admin
Utile pour le débogage récent, sans valeur passé un mois. Politique : rétention 30 jours.
Métadonnées orphelines
Quand vous supprimez un produit, certaines tables liées gardent des lignes orphelines : ps_image, ps_feature_product, ps_specific_price, ps_product_attachment. Idem pour les catégories, les fabricants, les fournisseurs supprimés. Ces lignes ne servent à rien et faussent les jointures.
-- Exemple : ps_image orphelines
SELECT i.id_image FROM ps_image i
LEFT JOIN ps_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;Le piège du DELETE en production
Supprimer un million de lignes en une seule requête sur une table InnoDB lockée par votre admin et votre front, c’est la garantie d’un crash. Le binary log explose, la réplication décroche, le serveur peut partir en swap.
La règle absolue : supprimer par lots de 5 000 à 10 000 lignes maximum, avec une pause de 100 ms entre chaque lot.
-- Boucle de suppression batchée (pseudo-code)
DO WHILE rows_affected > 0:
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 5000;
SLEEP 0.1;
END DO;Et systématiquement : dry-run avant execute. Vous voulez savoir combien de lignes vont disparaître et combien d’espace vous récupérez avant de cliquer.
Automatiser la rétention : la stratégie correcte
Faire le nettoyage à la main une fois et l’oublier ne sert à rien — la base regonflera. La rétention doit être continue et automatique :
- Cron quotidien qui exécute la politique de rétention de chaque table.
- Token de sécurité pour que le cron ne soit pas déclenchable depuis l’extérieur.
- Logs d’exécution pour suivre ce qui a été supprimé.
- Notification en cas d’échec ou d’anomalie (volume anormal de suppression).
- OPTIMIZE TABLE hebdomadaire sur les tables nettoyées pour récupérer l’espace disque (sinon InnoDB conserve l’espace alloué).
Notre module dfcleanup : la méthode packagée
Implémenter cette stratégie à la main demande deux à trois jours de dev et autant de tests. Notre module dfcleanup pour PrestaShop 8 et 9 industrialise toute la méthode décrite ici :
- Six nettoyeurs spécialisés : recherches, paniers, logs, statistiques, métadonnées orphelines, images orphelines. Chacun avec sa propre rétention configurable.
- Trois modes : Audit (lecture seule), Dry-run (simulation tracée), Execute (suppression batchée par lots de 5 000 lignes).
- Gain en MB calculé avant action, par cleaner et au total.
- Tâche cron sécurisée par token, prête à l’emploi.
- Logs détaillés et compatibilité PrestaShop 8 et 9.
Pour 19 €, vous évitez les requêtes DELETE à la main et vous installez une politique de rétention durable. Comparé au temps de dev et au coût d’un incident DBA, c’est un des modules au meilleur ROI du catalogue.
FAQ
Faut-il faire un OPTIMIZE TABLE après chaque DELETE ?
Non, pas après chaque DELETE — c’est coûteux en I/O et lock la table. Une fois par semaine ou par mois, en heure creuse, sur les tables qui ont subi un nettoyage massif. OPTIMIZE TABLE récupère l’espace disque que InnoDB ne libère pas naturellement après suppression.
Le nettoyage peut-il affecter le SEO ou les statistiques ?
Aucun impact SEO : les tables nettoyées sont techniques (recherches internes, connexions, logs), pas le catalogue ni l’URL. Côté stats, si vous utilisez GA4 ou Matomo, vos données sont stockées chez eux — la BDD PrestaShop est redondante. Si vous utilisez les statistiques natives PS, configurez une rétention plus longue (180 jours par exemple).
Quelle rétention pour les paniers abandonnés ?
90 jours suffisent largement. Les outils de relance panier (mail, retargeting) déclenchent dans les 24 à 72 heures. Au-delà de 90 jours, la probabilité de récupération est statistiquement nulle. Et vous ne supprimez jamais un panier converti en commande — la jointure ps_orders.id_cart protège cette donnée.
Combien de gain attendre concrètement ?
Sur une boutique 5 ans, 2 000 visiteurs/jour, nous mesurons en moyenne 60 à 80 % de réduction de la BDD au premier passage. Une boutique à 12 Go redescend à 3 ou 4 Go. Les passages suivants stabilisent la base à un palier proche du « poids métier réel ».
Le module est-il compatible multi-boutique ?
Oui. Les nettoyeurs respectent le périmètre multi-shop quand c’est pertinent (paniers, recherches par boutique). Les tables globales (logs, connexions) sont nettoyées globalement.
Pour aller plus loin
La dette de base est une des trois sources principales de dégradation perfomance long-terme d’une boutique PrestaShop, avec les modules tiers obsolètes et les images mal optimisées. Voir aussi notre checklist Core Web Vitals 2026 pour le reste du tableau, et le guide PrestaShop 9 vs 8 si vous préparez une migration : alléger la BDD avant migration peut diviser par 5 le temps de bascule.