# Désinstaller un module sans laisser de traces

> Retirer un module semble être l’opération la plus simple du monde. En réalité, désactiver, désinstaller et supprimer sont trois choses différentes, et aucune des trois ne garantit que le module n’a plus aucune trace dans votre boutique.

- Source canonique : [https://allaux.fr/modules/desinstaller-un-module-proprement](https://allaux.fr/modules/desinstaller-un-module-proprement)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Lancez la désinstallation prévue par le module avant de supprimer son dossier : retirer les fichiers d’abord empêche le code de nettoyage de s’exécuter. Vérifiez ensuite ce qui subsiste : lignes du module dans ps_configuration et ps_hook_module, tables portant son nom, fichiers laissés dans override/, et tâches cron encore enregistrées côté serveur.

## Désactiver, désinstaller, supprimer : trois opérations distinctes

Désactiver arrête l’exécution du module mais ne touche à rien : ses fichiers restent, ses tables restent, ses réglages restent, et ses tâches planifiées peuvent continuer de tourner si elles ont été enregistrées côté serveur. C’est utile pour un test, pas pour un retrait.

Désinstaller déclenche la procédure de désinstallation prévue par le module. Un module bien écrit y supprime ses tables, ses réglages et ses points d’accroche. Un module mal écrit ne fait rien du tout, ou échoue en silence. Sur WordPress, la nuance est encore plus marquée : la procédure de désinstallation ne s’exécute qu’à la suppression définitive de l’extension, pas à sa désactivation, ce que presque personne ne sait.

Supprimer efface les fichiers. Si la désinstallation n’a pas eu lieu avant, les données restent en base sans plus aucun code pour les lire ni les nettoyer : ce sont elles qu’on retrouve des années après.

## Ce qui survit à une désinstallation bâclée

- Des tables de base de données qui grossissent encore, sans plus rien pour les lire
- Des lignes de configuration chargées à chaque requête, qui pèsent sur toutes les pages
- Des tâches planifiées enregistrées côté serveur, qui appellent un fichier disparu
- Des entrées de menu ou des onglets d’administration qui pointent vers rien
- Des fichiers déposés hors du dossier du module : surcharges, ressources, images
- Une clé d’accès à un service tiers restée enregistrée quelque part

## Comment je retire un module proprement

1. **Sauvegarder d’abord, fichiers et base** — La désinstallation est destructive par nature : elle supprime des tables. Si ces tables contiennent un historique utile, il faut l’exporter avant, parce qu’après il n’y a plus rien à exporter.
2. **Désinstaller avant de supprimer** — Dans cet ordre, jamais l’inverse. Supprimer les fichiers d’abord rend la désinstallation impossible et condamne les données à rester.
3. **Chercher ce qui a été posé ailleurs** — Surcharges de classes, ressources ajoutées au thème, tâches planifiées, entrées d’administration. Ces éléments-là sont rarement gérés par la procédure de désinstallation.
4. **Vider les caches et revérifier le front** — Un module retiré laisse souvent une trace visuelle jusqu’au vidage du cache, et une erreur peut n’apparaître que sur une page peu visitée. Je passe une commande de test après tout retrait.

## Ne retirez jamais un module de paiement à la légère

> Les commandes déjà passées gardent une référence au moyen de paiement utilisé. Retirer complètement un module de paiement peut empêcher l’affichage correct des anciennes commandes et compliquer un remboursement. Dans ce cas, la désactivation est souvent le bon choix, précisément parce qu’elle ne supprime rien.

## Le cas particulier des tables restées derrière

C’est ce que je rencontre le plus souvent sur une boutique reprise : une base qui contient les tables de modules retirés depuis longtemps, parfois volumineuses, parfois pleines de journaux qui n’ont jamais été purgés. Elles ne ralentissent pas directement les pages, puisque plus rien ne les lit, mais elles alourdissent les sauvegardes, les restaurations et les migrations, et elles brouillent la lecture de la base pour toute intervention future.

Le nettoyage n’est pas compliqué mais il demande de la prudence : il faut identifier avec certitude à quel module appartenait chaque table avant d’y toucher. Un préfixe de table qui ressemble à celui d’un module retiré peut appartenir à un module encore actif. Je fais ce tri sur une copie de la base, et je conserve un export complet avant toute suppression.

## Pages liées

- **Nettoyer la base de données WordPress** — La procédure côté WordPress, y compris les réglages restés en place. ([/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees](/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees))
- **Audit du parc de modules** — Pour savoir ce qui est encore utilisé avant de décider ce qui part. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))
- **Sauvegarder la boutique avant intervention** — La sauvegarde à faire avant toute désinstallation, sans exception. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Les tâches cron ne s’exécutent pas** — Quand un module retiré laisse une tâche planifiée qui échoue en boucle. ([/prestashop/problemes/taches-cron-ne-sexecutent-pas](/prestashop/problemes/taches-cron-ne-sexecutent-pas))

## FAQ

### Désactiver suffit-il si je ne veux plus du module ?

Pour un test, oui. Pour un retrait durable, non : les fichiers restent chargeables et les données restent en base. En revanche, la désactivation est parfois le bon choix pour un module de paiement, dont les données servent encore aux commandes passées.

### Comment savoir quelles tables appartenaient à un module supprimé ?

Par leur préfixe, qui reprend en général le nom technique du module, et par leur date de dernière écriture. Je croise les deux avant de conclure, parce qu’un préfixe seul n’est pas une preuve suffisante.

### Un module supprimé peut-il encore ralentir le site ?

Sur WordPress, oui : les réglages laissés en base peuvent être chargés à chaque requête, quel que soit leur nombre. C’est un des cas où le nettoyage a un effet mesurable sur l’administration.

### Faut-il désinstaller les modules non utilisés ?

Oui, et pas seulement pour la performance : un module inutilisé mais présent reste exécutable et continue de porter ses failles éventuelles. Retirer ce qui ne sert plus est la mesure la moins coûteuse pour réduire la surface exposée.