# DataFirefly Cleanup — Guide complet
> Présentation DataFirefly Cleanup est un module d'administration PrestaShop 8 et 9 qui nettoie votre base de données en toute sécurité : statistiques obsolètes, paniers abandonnés, logs anciens, recherches périmées, métadonnées…
- Page:
- Langue: fr
- Mis à jour le: 2026-07-02
- Autres langues: [en](https://www.datafirefly.com/en/documentation/dfcleanup/index.md), [es](https://www.datafirefly.com/es/documentation/dfcleanup/index.md), [de](https://www.datafirefly.com/de/documentation/dfcleanup/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfcleanup/index.md), [it](https://www.datafirefly.com/it/documentation/dfcleanup/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfcleanup/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfcleanup/index.md)
- Index:
## Présentation
DataFirefly Cleanup est un module d'administration PrestaShop 8 et 9 qui nettoie votre base de données en toute sécurité : statistiques obsolètes, paniers abandonnés, logs anciens, recherches périmées, métadonnées orphelines et images orphelines. Chaque nettoyeur propose trois modes — audit, dry-run et execute — et le module calcule le gain d'espace en MB avant toute action.
Le module ne modifie ni votre thème ni les fichiers du cœur PrestaShop. Il crée une seule table (l'historique des nettoyages) et un onglet d'administration.
## Installation
1. Téléchargez le fichier `dfcleanup.zip` depuis votre compte DataFirefly.
2. Dans votre back-office PrestaShop, allez dans **Modules > Gestionnaire de modules > Téléverser un module**.
3. Glissez le ZIP ou sélectionnez-le. L'installation crée la table d'historique, l'onglet admin et le jeton cron.
4. Ouvrez **Paramètres avancés > DataFirefly Cleanup**.
Prérequis : PrestaShop 8.0+ ou 9.0+, PHP 8.0+, MySQL 5.7+ ou MariaDB 10.3+.
## Le tableau de bord
L'écran principal affiche trois blocs d'information en tête :
- **Taille de la base** — l'espace total occupé par vos tables (données + index), calculé via `information_schema`.
- **Gain potentiel** — l'estimation de l'espace récupérable si tous les nettoyeurs étaient exécutés.
- **Pourcentage récupérable** — le ratio entre les deux.
En dessous, le **top 10 des plus grosses tables** vous montre où part réellement votre espace disque. Les tables de statistiques (`ps_connections`, `ps_page_viewed`) figurent presque toujours en tête sur un store actif.
## Les six nettoyeurs
### Statistiques
Nettoie `ps_connections` (et ses tables enfants `connections_page` et `connections_source`), `ps_page_viewed`, `ps_referrer_cache`, `ps_pagenotfound` et les guests orphelins. Rétention par défaut : 90 jours. C'est généralement le nettoyeur au plus fort gain — les tables de stats croissent à chaque visite.
### Paniers abandonnés
Supprime les paniers sans commande associée plus anciens que la rétention (30 jours par défaut), ainsi que les lignes orphelines de `cart_product` et `cart_cart_rule`, et les règles panier expirées.
Un panier converti en commande n'est **jamais** supprimé : chaque requête vérifie l'absence de commande via une jointure sur `ps_orders`. Vos données de commande sont intouchables.
### Logs application
Élague `ps_log` avec une rétention pondérée par sévérité : les entrées informatives et les avertissements (sévérité 1-2) sont supprimés après la rétention configurée (30 jours par défaut), tandis que les erreurs et erreurs critiques (sévérité 3-4) sont conservées deux fois plus longtemps.
### Recherches obsolètes
Nettoie l'historique `ps_statssearch` (60 jours par défaut) et les lignes orphelines de l'index de recherche (`search_index`, `search_word`) pointant vers des produits supprimés.
### Métadonnées orphelines
Cible les lignes dont le parent n'existe plus : `product_lang`, `product_shop`, `product_attribute`, `category_product`, `stock_available`, `specific_price`, `customization`, adresses soft-deleted sans commande, `image_lang` et `image_shop`. Pas de notion de rétention ici : un orphelin est un orphelin.
### Images orphelines
Deux volets : les entrées `ps_image` dont le produit n'existe plus (toujours actif), et un **scan du système de fichiers** optionnel qui parcourt le dossier des images produits à la recherche de fichiers JPG sans entrée en base. Le scan est plafonné à 200 000 fichiers par sécurité.
## Les trois modes
| Mode | Écriture en base | Usage |
| --- | --- | --- |
| **Audit** | Aucune | Compter les lignes concernées et estimer le gain. À lancer en premier, toujours. |
| **Dry-run** | Historique uniquement | Simuler l'exécution et garder une trace datée du périmètre. |
| **Execute** | Suppression réelle | Supprimer par lots de 5 000 lignes (configurable), avec micro-pauses entre lots. |
**Avant tout Execute : sauvegardez votre base.** Le nettoyage est irréversible. Workflow recommandé : Audit → Dry-run → Backup → Execute → OPTIMIZE TABLE.
## OPTIMIZE TABLE
Supprimer des lignes ne rend pas immédiatement l'espace au système : InnoDB conserve l'espace dans le fichier de table. La case **OPTIMIZE TABLE après exécution** reconstruit les tables nettoyées pour restituer l'espace physique au disque (nécessite `innodb_file_per_table`, activé par défaut sur les installations modernes). À réserver aux heures creuses : l'opération verrouille brièvement chaque table.
## Tâche cron
Le panneau **Nettoyage planifié (cron)** du dashboard vous permet d'automatiser les nettoyages.
### Configuration
- **Activer le cron** — interrupteur global. Désactivé, l'endpoint répond 503 même avec un jeton valide.
- **Mode** — audit, dry-run (défaut, sans risque), execute, ou execute + OPTIMIZE.
- **Nettoyeurs à exécuter** — cases à cocher. Par défaut : stats, cart, log, search. Metadata et image sont opt-in.
### URL et jeton
L'endpoint public est `/module/dfcleanup/cron?token=VOTRE_JETON`. Le jeton (32 caractères hexadécimaux) est généré à l'installation et vérifié en temps constant. Le bouton **Régénérer le jeton** invalide immédiatement l'ancienne URL.
### Planification
Deux options :
1. **Module cronjobs PrestaShop** — si installé, la tâche s'y inscrit automatiquement (hook `actionRetrieveCronJobs`), planifiée à 3h00 chaque jour. Modifiez l'horaire depuis la configuration du module cronjobs.
2. **Crontab système** — copiez la ligne affichée dans l'admin :
```
0 3 * * * /usr/bin/curl -s 'https://votre-boutique.com/module/dfcleanup/cron?token=XXXX' > /dev/null 2>&1
```
### Surcharges ponctuelles
Vous pouvez surcharger le mode et les nettoyeurs pour un appel donné, sans toucher à la configuration :
```
?token=XXXX&mode=audit
?token=XXXX&mode=execute&cleaners=stats,log
```
Le bouton **Lancer le cron maintenant** exécute immédiatement la configuration courante — pratique pour tester sans attendre la prochaine échéance.
## Réglages
- **Taille de lot** — nombre de lignes supprimées par requête (défaut 5 000, min 100, max 100 000). Baissez sur un mutualisé contraint, montez sur un serveur dédié costaud.
- **Rétention de l'historique** — durée de conservation des entrées d'historique du module (180 jours par défaut).
- **Rétention par nettoyeur** — en jours. 0 = désactive le filtre temporel (les nettoyeurs d'orphelins ignorent ce réglage).
## Historique
Chaque action (audit, dry-run, execute — manuelle ou cron) est consignée : nettoyeur, mode, lignes affectées, octets libérés, détail par table en JSON, opérateur (email admin, `cron` ou `cron (manual)`), date. La table d'historique est purgée automatiquement selon la rétention configurée.
## Dépannage
### Timeout sur les grosses suppressions
Le module désactive la limite de temps PHP pendant l'exécution, mais certains hébergeurs imposent des limites au niveau du serveur web. Dans ce cas, réduisez la taille de lot, exécutez cleaner par cleaner, ou passez par le cron en CLI (curl depuis crontab n'est pas soumis aux limites du serveur web).
### L'endpoint cron répond 403
Le jeton fourni ne correspond pas. Vérifiez que l'URL de votre crontab est à jour — un jeton régénéré invalide l'ancienne URL.
### L'endpoint cron répond 503
Le cron est désactivé dans les réglages du module. Activez-le depuis le panneau Nettoyage planifié.
### Le gain affiché diffère de l'espace réellement libéré
Le gain est une estimation proportionnelle (`lignes_supprimées / lignes_totales × taille_table`). L'espace réel restitué au disque dépend d'OPTIMIZE TABLE et de la fragmentation. L'estimation est volontairement conservatrice.
## Notes techniques
- Le module utilise une détection de schéma défensive (`tableExists` / `columnExists` via `information_schema`) : il s'adapte aux différences PS 8 / PS 9 et ignore les tables absentes.
- Les suppressions single-table sont batchées avec `LIMIT` ; les suppressions multi-table (jointures) s'exécutent en un seul ordre, MySQL n'autorisant pas `LIMIT` sur cette syntaxe.
- Le jeton cron est comparé via `hash_equals` (temps constant) pour résister aux attaques par chronométrage.
- Compatible multiboutique. Interface en FR/EN/ES/DE.