MedCleanMyShop PrestaShop : nettoyage base de données et fichiers automatisé

Table des matières :

MedCleanMyShop PrestaShop : périmètre de nettoyage (DB + fichiers) et zones à ne jamais purger

Parler de « nettoyage automatisé » sur PrestaShop sans définir un périmètre précis est une manière fiable de casser un checkout ou d’effacer des données légalement conservées. Dans cet article, MedCleanMyShop PrestaShop désigne un process outillé (module + commandes CLI + cron) visant à réduire l’entropie opérationnelle : tables SQL qui gonflent sans bénéfice, fichiers temporaires non purgés, caches incohérents, résidus de déploiement, logs non rotatés. L’objectif n’est pas « faire de la place » à l’aveugle, mais stabiliser performance, observabilité et sécurité.

Contexte versions (à adapter à votre stack) : les exemples ci-dessous supposent PrestaShop 8.1/8.2 ou PrestaShop 9, avec PHP 8.2/8.3 et MySQL 8.0 ou MariaDB 10.6+. Les chemins de cache et certains schémas de tables varient entre PS 1.7, 8.x et 9 ; ne copiez/collez pas en production sans vérifier. Côté PrestaShop 9, l’usage des commandes Symfony et de l’outillage CLI devient encore plus central (voir aussi : Commandes CLI PrestaShop : liste, catégories et options d’aide).

Le point critique : PrestaShop (historiquement) n’impose presque pas de clés étrangères. Résultat : l’intégrité référentielle repose sur le code applicatif et des conventions, pas sur le SGBD. Un “nettoyage” qui supprime des lignes « orphelines » peut supprimer des données encore nécessaires (ex. un panier utilisé comme base de calcul de promotions), ou créer des incohérences qui ne remontent qu’en front. MedCleanMyShop doit donc fonctionner avec : (1) un mode dry-run, (2) une liste blanche de tables et répertoires, (3) des seuils temporels configurables, (4) des garde-fous (locks, backups, rollback).

Ajoutez un cinquième principe très concret : ne jamais confondre “données techniques” et “données probantes”. En pratique, certaines données “peu utiles” au business (ex. logs d’authentification, traces d’administration) deviennent critiques en cas d’incident (fraude, litige, sécurité). En France/UE, la question se recoupe avec le RGPD (minimisation + limitation de conservation) et avec les besoins de preuve (sécurité, lutte contre la fraude, audit). La CNIL rappelle le principe général de durées limitées et justifiées : voir la page CNIL sur les durées de conservation (https://www.cnil.fr/fr/les-durees-de-conservation-des-donnees) pour cadrer votre politique (à valider avec votre DPO/DPD et votre conseil).

Enfin, un nettoyage “safe” se pilote comme un déploiement : staging → production, et un plan de retour arrière réaliste. Exemple de scénario (simple mais fréquent) : une purge agressive des paniers supprime des lignes qu’un module de relance/promo utilise pour reconstruire des règles ; le bug n’apparaît que 48h plus tard lors d’une campagne. Sans dry-run + journalisation + sauvegarde testée, vous perdez la capacité d’investiguer.

Nettoyage de base de données PrestaShop : ce qui grossit vraiment (et pourquoi)

En production, les tables qui explosent sont rarement celles qu’on croit. Sur beaucoup de boutiques, ce sont les tables de traces et agrégats : connexions, statistiques, recherche interne, logs applicatifs, paniers abandonnés, sessions/“guests”. À cela s’ajoutent des artefacts de modules : tables créées puis oubliées, index non optimisés, doublons et états transitoires jamais purgés.

Exemples classiques (préfixe ps_ à adapter via _DB_PREFIX_) : ps_connections, ps_connections_source, ps_guest, ps_cart, ps_cart_product, certaines tables de stats (ps_statssearch selon versions/modules), tables d’index de recherche (ps_search_index, ps_search_word), et des tables de logs (ps_log selon contexte). Sur PrestaShop, le back-office et des modules peuvent aussi stocker des payloads volumineux (JSON, HTML) dans des champs TEXT/LONGTEXT : c’est invisible tant que vous n’inspectez pas la taille réelle.

Deux causes fréquentes de “gonflement silencieux” :

fonctionnalités non utilisées mais activées : moteur de recherche interne peu pertinent, stats historiques en back-office, modules de tracking qui stockent trop finement ;
sur-collecte : stockage de données redondantes (user agents, referrers, params UTM), parfois en clair, alors qu’un niveau de détail plus faible suffit.

Avant toute purge, mesurez. Une base “grosse” n’est pas forcément “lente” : ce qui tue les performances, ce sont les requêtes non sélectives et les index inadéquats. Utilisez information_schema.tables pour lister les plus gros objets, puis corrélez avec le slow query log (voir : Requêtes MySQL lentes PrestaShop : activer slow query log et, plus globalement, Développeur MySQL : optimiser requêtes, schémas et performances en production).

Pour rendre l’audit actionnable, visez une sortie “priorisée”. Par exemple :

Top 10 tables par taille (data + index) ;
Top 10 tables par croissance (delta sur 7/30 jours, via snapshots) ;
Top 10 requêtes lentes qui touchent ces tables (slow log).

Un mini-tableau de lecture (à adapter à votre contexte modules) aide à cadrer le risque :

Zone	Exemples	Risque de purge	Rétention typique (ordre de grandeur)	Prérequis
Traces techniques	`ps_connections`, `ps_guest`	Faible à moyen	90–180 jours	vérifier modules stats/anti-fraude
Paniers	`ps_cart`, `ps_cart_product`	Moyen	180–365 jours	exclure paniers liés à commandes/paiements
Recherche interne	`ps_search_*`	Faible	rebuild possible	savoir reconstruire l’index
Logs applicatifs	`ps_log`	Moyen à élevé	30–180 jours (si centralisé)	export SIEM/archivage
Données business	commandes, factures	Très élevé	durées légales/contractuelles	politique légale + validation

Purge SQL contrôlée : politiques de rétention, orphelins et transactions

Un nettoyage base de données PrestaShop automatisé doit se baser sur une politique de rétention (par ex. 90/180/365 jours selon les données), documentée et validée côté légal/DPD si des données personnelles sont en jeu (comptes, adresses, logs IP). Ne confondez pas “données inutiles pour le business” et “données non conservables” : en e-commerce, facturation, comptabilité et litiges imposent des durées. On parle ici de purge d’objets techniques (traces, caches, agrégats), pas de suppression d’historique de commandes.

Pour les tables de connexions/guests, une purge par date est généralement safe si vous savez ce que vos modules lisent. Exemple (MySQL/MariaDB) :

-- Prévisualisation (dry-run logique) : compter ce qui sera supprimé
SELECT COUNT(*)
FROM ps_connections
WHERE date_add < (NOW() - INTERVAL 180 DAY);

-- Purge effective : faire par batch pour limiter les locks
DELETE FROM ps_connections
WHERE date_add < (NOW() - INTERVAL 180 DAY)
LIMIT 50000;

La purge doit être batchée (boucle jusqu’à 0 lignes), sinon vous prenez des verrous longs, du lag de réplication et un risque d’“incident 503” pendant les pics (diagnostic : Erreur HTTP 503 : diagnostic serveur, logs et ressources). Ajoutez un timeout applicatif et un mécanisme d’arrêt propre.

Deux détails qui évitent des purges “instables” :

Baser le batch sur une clé (si possible) plutôt que sur la date seule, pour garder un plan d’exécution prévisible. Exemple : supprimer par tranches d’ID si la table a un PRIMARY KEY monotone.
Éviter une transaction géante : sur InnoDB, un DELETE massif augmente l’undo/redo et peut provoquer des effets de bord (I/O, purge lag InnoDB). Les batches réduisent aussi ce risque.

Sur les “orphelins”, soyez encore plus conservateur. Comme il n’y a pas de FK, vous devez prouver la non-référenciation. Exemple typique : images produit “cassées” (fichiers manquants vs DB, ou DB sans fichier). Le nettoyage doit se faire en double sens : (a) détecter des lignes sans fichier, (b) détecter des fichiers sans ligne. Pour (b), on ne supprime jamais sans whitelist et sans journalisation, car un thème/module peut lire des images hors schéma standard.

Un pattern utile (et plus sûr que “supprimer tout ce qui n’a pas de parent”) : marquer puis supprimer.

1) vous insérez les candidats dans une table de travail (ou un log) avec horodatage ;
2) vous attendez une fenêtre (ex. 7 jours) ;
3) vous supprimez uniquement si aucun “signal” n’a montré que c’était finalement utilisé.

Cela permet d’intégrer une validation humaine et de limiter les “faux positifs” (surtout en boutique multi-boutique, ou avec des imports fréquents).

OPTIMIZE/ANALYZE et récupération d’espace : ce que MySQL fait réellement

En InnoDB, l’espace libéré peut rester dans le tablespace et être réutilisé ; il n’est pas automatiquement rendu au système de fichiers dans tous les cas. En pratique, lancer une opération destinée à récupérer de l’espace disque peut entraîner reconstruction, I/O, locks (selon version/engine), et parfois duplication temporaire de la table. Sur une grosse boutique, lancer OPTIMIZE TABLE en pleine journée est une mauvaise idée.

ANALYZE TABLE est souvent plus utile au quotidien : il met à jour les statistiques utilisées par l’optimiseur. C’est moins coûteux qu’une reconstruction complète et peut stabiliser des temps de réponse.

Un point opérationnel souvent oublié : sur MariaDB vs MySQL, le comportement précis et les verrous peuvent différer (ainsi que certaines options d’“online DDL”). D’où l’intérêt de tester sur un clone (snapshot) représentatif avant de planifier une opération lourde.

Garde-fous recommandés pour MedCleanMyShop côté DB :

Vérifier innodb_file_per_table=ON (sinon récupérer de l’espace peut nécessiter des opérations plus lourdes).
Exécuter OPTIMIZE TABLE uniquement sur des tables ciblées, sur fenêtre de maintenance, idéalement après purge.
En environnement avec réplication, tester l’impact sur le lag et planifier avec un throttling.
Sur tables “sensibles” (paniers, stock, commandes), privilégier d’abord : index corrects, requêtes adaptées, stats (ANALYZE) — avant toute reconstruction.

Nettoyage des fichiers PrestaShop : caches, temporaires, résidus de déploiement

Côté filesystem, le vrai problème n’est pas juste le volume : c’est la cohérence. Un cache corrompu, des templates compilés incohérents, des résidus de build, ou un répertoire var/cache non invalidé peuvent provoquer des “pages vides” ou des comportements non déterministes (voir : Page vide : causes fréquentes et impact sur l’indexation Google). En PrestaShop 8/9, une partie du runtime Symfony augmente l’importance d’un cycle propre cache/warmup.

Répertoires généralement concernés (à confirmer selon version) :

var/cache/ (ou app/cache/ sur des versions plus anciennes) : cache Symfony/PS.
img/tmp/ : images temporaires (imports, générations interrompues).
download/ et upload/ : fichiers envoyés (attention aux pièces jointes, fichiers produits numériques).
log/ ou logs dans l’arborescence de l’hébergeur (PHP-FPM, Nginx/Apache).

Ajoutez une vérification simple avant de “nettoyer” : est-ce un problème de disque ou d’inodes ? Sur certains hébergements (mutualisés notamment), on peut saturer les inodes bien avant l’espace disque : des milliers de petits fichiers temporaires suffisent à bloquer des écritures (sessions, cache, uploads).

Deux commandes de diagnostic utiles (non destructives) :

# Taille des dossiers clés (ordre de grandeur)
du -sh var/cache img/tmp log 2>/dev/null

# Top 20 des plus gros sous-répertoires (utile si img/ explose)
du -h -d 2 img 2>/dev/null | sort -h | tail -n 20

Exemple de purge “safe-ish” sur temporaires (à exécuter en utilisateur ayant les droits, et jamais en rm -rf sans filtre) :

# Lister avant de supprimer
find ./img/tmp -type f -mtime +7 -print | head

# Supprimer les temporaires > 7 jours
find ./img/tmp -type f -mtime +7 -delete

Pour les caches, évitez de supprimer à la main en prod sans comprendre le mécanisme de warmup. Préférez une commande contrôlée (CLI) et une vérification post-op (pages clés, checkout, back-office). L’optimisation globale se traite plutôt via caches multi-niveaux (OPcache, reverse proxy, CDN) que par “ménage” régulier ; voir : PrestaShop performance : optimiser gros catalogues et Core Web Vitals et, côté PHP, PHP OPcache : paramètres recommandés pour optimiser les performances.

Dernière nuance : upload/ et download/ ne sont pas “des temporaires” par défaut. Vous pouvez y avoir des pièces jointes SAV, des fichiers de personnalisation, des produits dématérialisés. Un nettoyage automatisé doit donc être ciblé sur des patterns (ex. .tmp, .part, fichiers plus anciens que X jours et non référencés), et consigner quoi a été supprimé (chemin + taille + hash si besoin).

Automatiser MedCleanMyShop : cron, idempotence, locks et mode dry-run

L’automatisation propre, sur PrestaShop moderne, passe par des commandes CLI. Le pattern robuste : un module fournit une ou plusieurs commandes Symfony (bin/console), chacune étant idempotente (réexécutable sans effet de bord), configurable (rétention, batch size), et observable (logs structurés + métriques). Si vous n’êtes pas encore à l’aise avec le CLI, commencez par l’inventaire des commandes et options de debug : Commandes CLI PrestaShop : liste, catégories et options d’aide.

Une commande typique “purge DB” doit implémenter :

dry-run (--dry-run) : ne supprime rien, affiche volumes et SQL.
lock : empêche deux exécutions concurrentes (cron doublé, déploiement, etc.).
batching : supprime par paquets, dort entre les paquets.
journalisation : nombre de lignes, durée, erreurs, version shop.

Pseudo-squelette (conceptuel) :

// PrestaShop 8/9 : Command Symfony dans un module
// Points clés : Lock, dry-run, batch, logs
protected function execute(InputInterface $input, OutputInterface $output): int
{
    $dryRun = (bool) $input->getOption('dry-run');
    $days = (int) $input->getOption('retention-days');
    $batch = (int) $input->getOption('batch');

    // Lock (Symfony Lock component) pour éviter les exécutions concurrentes
    // ...

    // Exemple : purge ps_connections en batch
    do {
        $sql = 'DELETE FROM '._DB_PREFIX_."connections WHERE date_add < (NOW() - INTERVAL $days DAY) LIMIT $batch";
        if ($dryRun) {
            // log SQL + exit
            break;
        }
        $affected = Db::getInstance()->execute($sql);
        // log métriques
        // sleep(1);
    } while ($affected > 0);

    return 0;
}

Pour le scheduling, évitez le “cron module” si vous avez déjà une discipline DevOps côté serveur. Un crontab (ou mieux : systemd timers si vous êtes sur Debian/Ubuntu) donne des logs système, des alertes, et une observabilité plus propre. En hébergement mutualisé, vous aurez parfois uniquement un cron “panneau” : dans ce cas, documentez clairement les contraintes, comme vous le feriez pour la supervision et les quotas (référence utile sur la couche hébergeur : Hébergement e-commerce : mutualisé, VPS, cloud ou SaaS comparés).

Exemple de cron “sobre” (à adapter) : exécuter la purge en dehors des pics, avec logs et code retour exploitable.

# Tous les jours à 03:20, avec log horodaté
20 3 * * * cd /var/www/boutique && php bin/console medclean:purge --retention-days=180 --batch=50000 >> /var/log/medclean/medclean-$(date +\%F).log 2>&1

Deux points qui font la différence en exploitation :

idempotence réelle : si le job s’interrompt au milieu, une relance doit reprendre sans casser (pas de “double suppression” non maîtrisée, pas de table temporaire laissée en plan).
lock robuste : le verrou doit survivre aux crons qui se chevauchent et expirer proprement si un process meurt (sinon vous “bloquez” votre maintenance).

Sécurité et conformité : purger sans effacer les preuves ni exposer des données

Nettoyer, c’est aussi un sujet de sécurité. Les logs et traces sont nécessaires pour diagnostiquer une compromission, un webskimmer, une élévation de privilèges, etc. Si votre “nettoyage automatisé” supprime trop vite des logs applicatifs/serveur, vous vous tirez une balle dans le pied au moment où vous devez faire un containment et reconstituer une timeline. Dans un plan mature, la purge fait partie du cycle “collecte → centralisation → rétention → suppression”, pas d’un rm -rf périodique (voir : Sécurité PrestaShop : plan de réponse à incident et containment immédiat et Sécurité PrestaShop 2026 : webskimmers et infostealers côté serveur).

OWASP insiste (dans sa Logging Cheat Sheet) sur le fait que la journalisation est un composant de sécurité, au même titre que l’authentification et le contrôle d’accès : https://cheatsheetseries.owasp.org/cheatsheets/LoggingCheatSheet.html. Traduction opérationnelle pour MedCleanMyShop : on purge en base locale si (et seulement si) les logs ont été exportés (SIEM, stockage objet, archivage chiffré), et on garde une rétention cohérente.

Quelques garde-fous concrets, souvent négligés :

Ne pas purger trop court les logs d’admin (connexions back-office, actions sensibles) : en cas de fraude, c’est votre piste la plus directe.
Éviter de stocker des données sensibles dans les logs (tokens, secrets, payloads contenant des données perso). Le “nettoyage” ne doit pas compenser une mauvaise hygiène de logging.
Séparer rétention “technique” et “conformité” : une boutique peut garder 30 jours de logs applicatifs en local si elle archive 6–12 mois ailleurs, selon ses besoins de sécurité et obligations internes.

Enfin, ne mélangez pas sécurité et performance. Purger var/cache peut masquer temporairement un bug, mais ne corrige pas la cause (override toxique, module instable, dette technique). Si vous avez des régressions récurrentes, traitez-les comme de la qualité logicielle : profiling, refactoring mesuré, réduction de dette (référence : Optimisation code PHP : réduire la dette technique sans refonte).

Mesurer l’impact : KPI, garde-fous et cas d’usage réalistes

Un nettoyage automatisé qui n’est pas mesuré est juste un script qui “supprime des trucs”. Définissez des KPI avant/après : taille des tables ciblées, durée des requêtes top N, TTFB sur pages clés, taux d’erreur 5xx, lag réplication, temps de cron, taille des répertoires temporaires. Sur PrestaShop, vous pouvez corréler avec les métriques infra (CPU, I/O, wait, memory) et les erreurs PHP/JS. Pour l’outillage de monitoring et l’alerting, référez-vous à : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et, côté supervision plus large, Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes.

Astuce pratique : mesurez aussi les coûts du nettoyage, pas seulement les gains.

Durée du job et variabilité (p95/p99 si vous historisez).
Impact sur I/O (pics) et sur la réplication (si applicable).
Taux d’erreurs applicatives pendant la fenêtre (5xx, timeouts).

Cas d’usage typique observé sur des boutiques à trafic moyen/fort (ordre de grandeur, dépend fortement des modules) :

ps_connections et tables associées : purge à 180 jours → réduction de plusieurs millions de lignes, moins d’I/O lors de requêtes d’admin/stats.
tables de paniers : purge des paniers inactifs > 365 jours → baisse du volume + meilleure stabilité des exports.
img/tmp : suppression des temporaires > 7 jours → réduction de bruit et de risques de saturation inode.

Le gain performance le plus stable vient rarement de “supprimer” : il vient de réduire la variance (moins de bloat, stats à jour, jobs batchés, caches cohérents). Si vous cherchez des gains Web Vitals, le nettoyage n’est qu’un prérequis ; le gros du travail se situe sur la perf applicative et front (ressources, images, rendu). Voir : SEO PrestaShop : optimiser fiches produits, schema.org et images WebP et, pour le chantier “gros catalogue”, ce guide sur les Core Web Vitals côté PrestaShop : optimiser gros catalogues et Core Web Vitals.

Checklist de déploiement production (sans folklore)

Avant d’activer MedCleanMyShop en cron, appliquez une discipline minimale : backup, test, rollback. Un nettoyage DB est une opération destructive ; sans sauvegarde exploitable, vous êtes en mode “pari”. Si vous êtes sur infra managée, utilisez snapshot + dump logique ; sinon, au minimum : dump chiffré + vérification de restauration. Sur l’organisation globale maintenance/sauvegardes, voir : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées.

Checklist exécutable :

Inventaire DB : top 20 tables par taille, top 20 par croissance (30 jours), et dépendances modules.
Règles de rétention : documentées, validées (tech + legal si données perso).
Mode dry-run : sortie JSON/log structurés, estimation volumes, durée.
Batching + locks : aucune requête monolithique qui supprime 20M de lignes d’un coup.
Fenêtre de maintenance : OPTIMIZE TABLE uniquement si besoin réel de récupération disque.
Observabilité : alertes sur durée job, erreurs SQL, pics 5xx.
Smoke tests post-nettoyage (10–15 minutes, scriptés si possible) : page catégorie, fiche produit, ajout panier, paiement (sandbox), connexion BO, génération facture/PDF si utilisé.
Journal de purge : conserver un log (date, tables, volumes, version module) pour expliquer un changement de comportement a posteriori.

Après mise en place, auditez au bout de 2–4 semaines : les seuils sont rarement corrects du premier coup. Ajustez en fonction de la saisonnalité (soldes, campagnes, pics) et du comportement réel des modules. Et si vous découvrez que “nettoyer” corrige temporairement un bug, traitez la cause : instrumentation, profiling, correction durable — pas un cron qui masque la dette.