Nettoyer un compte utilisateur avant de le désactiver, sans rien perdre au passage

Le départ d’un collaborateur qui quitte un projet est un moment où l’on va vite : on ferme l’accès, on supprime le compte, et on passe à autre chose. C’est précisément ce genre de précipitation qui a coûté cher à une coopérative culturelle où le compte d’un chargé de communication parti avait été supprimé sans réattribution préalable — plusieurs dizaines d’articles se sont retrouvés attribués à « Utilisateur supprimé », brisant au passage l’affichage des pages auteur du site.

Avant de désactiver ou supprimer un compte, une vérification méthodique de ce qui lui est réellement rattaché évite ce genre de mauvaise surprise. Voici, dans l’ordre où elles doivent être traitées, les cinq catégories à passer en revue.

1. Les contenus publiés, à réattribuer explicitement

La fonction native wp_delete_user() accepte un second paramètre $reassign, l’identifiant de l’utilisateur vers qui transférer tous les contenus du compte supprimé. Sans ce paramètre, les contenus restent attribués à un compte qui n’existe plus, ce qui casse potentiellement l’affichage de la page auteur et certains widgets liés à l’auteur :

$reussite = wp_delete_user( $id_utilisateur_sortant, $id_utilisateur_destinataire );

Sur un réseau multisite, la fonction équivalente est wpmu_delete_user(), qui ne propose pas nativement ce paramètre de réattribution : il faut alors traiter la réattribution manuellement, site par site, avant d’appeler cette fonction de suppression.

2. Les commentaires laissés en tant qu’utilisateur connecté

Contrairement aux articles, les commentaires ne sont jamais réattribués automatiquement par wp_delete_user() : ils conservent l’identifiant de l’utilisateur en base même après suppression du compte, ce qui affiche encore son nom d’affichage figé au moment du commentaire, mais rompt le lien vers un profil réel. Si les commentaires du collaborateur sortant doivent rester visibles avec son nom, aucune action n’est nécessaire ; s’ils doivent être réattribués à un compte générique, une requête dédiée est indispensable :

global $wpdb;

$wpdb->update(
    $wpdb->comments,
    array( 'user_id' => $id_utilisateur_destinataire ),
    array( 'user_id' => $id_utilisateur_sortant )
);

3. Les rôles et capacités personnalisées attribués individuellement

Si le collaborateur avait reçu, en plus de son rôle standard, des capacités individuelles ajoutées directement sur son compte via WP_User::add_cap() (un cas fréquent pour des accès ponctuels à une fonctionnalité spécifique), ces capacités disparaissent avec la suppression du compte sans laisser de trace exploitable ailleurs. Il vaut mieux documenter, avant suppression, la liste exacte des capacités individuelles attribuées, pour savoir si un autre collaborateur doit en hériter :

$utilisateur = get_userdata( $id_utilisateur_sortant );
$capacites_individuelles = array_keys( array_filter( $utilisateur->caps ) );

4. Les tâches planifiées (wp-cron) rattachées à ce compte

Une tâche planifiée programmée via wp_schedule_event() peut avoir été configurée pour envoyer un rapport par email à l’adresse personnelle du collaborateur sortant, ou pour exécuter une action en son nom via un identifiant stocké dans les arguments de la tâche. Un rapide passage en revue des tâches planifiées actives, via _get_cron_array(), permet de repérer ce genre de dépendance oubliée avant qu’elle ne continue silencieusement de s’exécuter vers une adresse email qui n’est plus consultée.

5. Les mots de passe d’application et clés d’accès externes

Un point souvent négligé : les mots de passe d’application générés depuis le profil de l’utilisateur (utilisés par exemple pour connecter un outil tiers à l’API REST du site) ne sont pas automatiquement révoqués à la suppression du compte dans toutes les configurations, selon les extensions de sécurité en place. Une vérification explicite depuis l’écran Utilisateurs > Profil > Mots de passe d'application avant la suppression garantit qu’aucun accès externe ne reste actif après le départ du collaborateur.

Le bon ordre d’exécution

1. Documenter les capacités individuelles et les mots de passe d’application actifs, avant toute autre action.
2. Révoquer les mots de passe d’application et les clés API externes liées au compte.
3. Décider du sort des commentaires (réattribution ou conservation en l’état) et l’exécuter si nécessaire.
4. Vérifier les tâches planifiées qui référencent ce compte, et les réattribuer ou supprimer.
5. Supprimer le compte avec wp_delete_user() en précisant explicitement l’utilisateur de réattribution des contenus.

• Ne supprimez jamais un compte sans avoir d’abord vérifié la liste de ses contenus publiés via l’écran Articles filtré par auteur.
• Préférez, si le contexte le permet, une désactivation temporaire (changement de mot de passe et retrait du rôle vers Aucun rôle) à une suppression immédiate, le temps de vérifier qu’aucune dépendance n’a été oubliée.
• Consignez chaque départ de collaborateur dans un journal interne, avec la date et les actions effectuées : cette trace évite de refaire l’enquête plusieurs mois plus tard en cas de question.

Un principe que j’applique à chaque hors-bord de collaborateur, quelle que soit la taille du site : jamais de suppression le jour même du départ. Un compte désactivé (rôle retiré, mot de passe changé) pendant une à deux semaines laisse le temps de repérer une dépendance oubliée avant que la suppression ne devienne définitive.

Le résultat sur le terrain

Cette checklist en cinq points ne demande aucun outil supplémentaire : uniquement de la rigueur et le bon ordre d’exécution. Sur la coopérative culturelle mentionnée plus haut, l’incident des pages auteur cassées aurait été évité par la seule application du premier point — un rappel utile que la majorité des problèmes liés au départ d’un collaborateur viennent d’une réattribution de contenu oubliée, pas d’un bug technique du cœur de WordPress.