Une extension de gestion d’adhérents pour clubs sportifs est retirée du site d’une association après le changement de prestataire informatique du club. Le nouvel administrateur clique sur « Supprimer » depuis l’écran des extensions, sans réaliser que cette action déclenche également l’exécution du fichier uninstall.php de l’extension, qui supprime intégralement les tables personnalisées contenant huit ans d’historique de cotisations et de présences aux entraînements. Aucun écran de confirmation spécifique n’avertit l’administrateur de cette conséquence, au-delà du message générique de WordPress qui prévient simplement que les fichiers du plugin seront supprimés.
Ce scénario, loin d’être rare, pousse à repenser l’expérience de désinstallation d’une extension qui accumule des données métier significatives, au-delà de la simple question technique du choix entre uninstall.php et register_uninstall_hook(), déjà largement traitée par ailleurs.
Le problème d’expérience, pas seulement de code
Techniquement, un fichier uninstall.php bien écrit fonctionne parfaitement : il supprime proprement les tables, les options et les métadonnées créées par l’extension, sans rien laisser traîner en base après coup, ce qui est en soi une bonne pratique d’hygiène pour ne pas polluer indéfiniment la base d’un site qui n’utilise plus l’extension. Le problème n’est pas la propreté de la suppression, mais l’absence totale de garde-fou avant qu’elle ne se déclenche, pour des données qui, contrairement à un simple réglage d’affichage, représentent un travail de saisie de plusieurs années.
Construire un écran de confirmation adapté
Plutôt que de laisser uninstall.php s’exécuter silencieusement dès le clic sur « Supprimer » dans l’écran natif des extensions, la solution consiste à intercepter ce moment plus tôt, en désactivant d’abord l’extension normalement, puis en proposant, avant toute suppression effective, un écran dédié accessible depuis les réglages de l’extension elle-même :
