Supprimer un compte Linux - Le guide complet pour éviter les pièges

Supprimer un compte Linux ne se résume pas à effacer un nom dans `/etc/passwd`. Il faut aussi décider quoi faire du répertoire personnel, des tâches planifiées, des fichiers encore possédés par cet utilisateur et des accès qui peuvent exister ailleurs dans l’infrastructure. Dans un contexte DevOps, je traite cette opération comme un changement sensible: elle doit être propre, vérifiable et, si possible, précédée d’une phase de verrouillage plutôt que d’une suppression immédiate.

Quand supprimer un compte Linux et quand le verrouiller d’abord

Je distingue toujours deux cas: le compte humain et le compte technique. Pour un collaborateur qui quitte l’équipe, je préfère souvent commencer par verrouiller le compte, couper les sessions actives et attendre une courte fenêtre de rétention avant de le supprimer. Ce délai évite les suppressions trop rapides, notamment si le compte sert encore à lire des archives, récupérer des clés SSH ou valider une ancienne automatisation.

Pour un compte de service, la logique est différente. Avant de le supprimer, je vérifie s’il est encore référencé dans un service systemd, un job cron, un conteneur, un dépôt applicatif ou une configuration d’agent de déploiement. Si le compte pilote encore une tâche, je remplace d’abord son usage par un autre compte technique ou par un mécanisme de rôle, sinon je risque un arrêt silencieux plusieurs heures plus tard.

Dans les environnements centralisés, la question n’est pas seulement locale. Si l’authentification passe par un annuaire, supprimer l’utilisateur sur une machine ne retire pas forcément ses droits à la source. C’est là que beaucoup d’équipes se trompent: le poste est nettoyé, mais le compte reste actif dans l’identité centrale.

Cette distinction entre désactivation et suppression me sert de base pour choisir la commande adaptée, surtout quand la distribution ou l’annuaire imposent leurs propres outils.

Choisir la bonne commande selon votre distribution

La commande dépend surtout de la famille de distribution et du mode de gestion des identités. Sur Debian et Ubuntu, je privilégie souvent `deluser`, car l’outil est plus explicite pour les suppressions usuelles. Sur RHEL, Fedora, AlmaLinux, Rocky Linux et les systèmes proches, `userdel` reste la référence de bas niveau. Et si l’utilisateur est géré par FreeIPA ou un autre annuaire, il faut utiliser l’outil du domaine, pas un simple effacement local.

Deux détails méritent d’être retenus. D’abord, le compte root ne doit pas être supprimé, et les outils sérieux s’en protègent. Ensuite, l’option forcée -f n’est pas une solution de confort: elle contourne des garde-fous et peut laisser des processus ou des fichiers dans un état incohérent. Je ne la considère qu’en dernier recours, après analyse.

Dans une équipe Linux un peu sérieuse, je conseille aussi de documenter quelle commande est l’outil de référence selon la distribution. Cela évite les habitudes improvisées entre un serveur Debian et un nœud RHEL.

Supprimer proprement le compte pas à pas

Quand je dois effectuer la suppression, je suis toujours le même ordre. Cette séquence limite les erreurs et me donne un point de contrôle à chaque étape.

1. Vérifier l’identité et le périmètre du compte
   Je commence par identifier l’utilisateur, son UID, son groupe primaire et ses éventuels groupes secondaires. Les commandes id alice et getent passwd alice sont souvent les plus rapides pour ça.
2. Contrôler les sessions et les processus actifs
   Si l’utilisateur est encore connecté ou exécute des tâches, la suppression peut échouer. Sur une machine avec systemd, loginctl terminate-user alice peut aider; sinon, je vérifie avec ps -u alice -f et j’arrête les processus de façon propre.
3. Sauvegarder ce qui doit l’être
   Si le compte contient des données utiles, je fais une archive avant suppression. Sur Debian/Ubuntu, deluser --backup peut produire une archive, ce qui est pratique quand on veut garder une trace rapide sans bricoler un script à part.
4. Verrouiller puis supprimer
   Pour un compte humain, je préfère souvent verrouiller d’abord avec passwd -l alice, puis supprimer ensuite. La suppression finale peut ensuite se faire avec userdel -r alice ou deluser --remove-home alice.
5. Vérifier les restes
   Je termine par une recherche de fichiers encore possédés par l’ancien UID, par exemple find / -xdev -uid 1001. C’est souvent là qu’on découvre les oublis, surtout sur des serveurs avec volumes montés ou répertoires applicatifs hors du home.

# Exemple minimal sur une distribution de type RHEL
id alice
ps -u alice -f
sudo passwd -l alice
sudo userdel -r alice

# Variante Debian / Ubuntu
id alice
sudo deluser --backup --remove-home alice

Ce que j’apprécie dans cette approche, c’est qu’elle garde l’opération lisible. On sait ce qui a été arrêté, ce qui a été sauvegardé et ce qui a été supprimé. En exploitation, cette traçabilité vaut souvent plus qu’une suppression rapide.

La suite logique consiste à regarder ce que ces commandes ne nettoient pas elles-mêmes, parce que c’est précisément là que se cachent les incidents post-suppression.

Ce que la suppression ne nettoie pas automatiquement

Une erreur fréquente consiste à croire que l’outil va tout effacer partout. En pratique, ce n’est pas le cas, et c’est même sain qu’il ne le fasse pas aveuglément.

• Les tâches cron, at et print peuvent rester si vous n’avez pas mis en place un nettoyage dédié. Sur certains systèmes, USERDEL_CMD dans /etc/login.defs sert justement à brancher un script de nettoyage.
• Les fichiers en dehors du home restent souvent sur le disque, surtout s’ils vivent dans /srv, /var/www, un partage NFS ou un volume monté pour une application.
• Les ACL et les fichiers sudoers ne disparaissent pas toujours avec le compte. Si le nom de l’utilisateur figure dans une règle d’accès, il faut la retirer manuellement.
• Les groupes partagés demandent une vérification séparée. Si le groupe porte le même nom que l’utilisateur, il peut être supprimé automatiquement sur certains systèmes, mais pas dans tous les cas.
• Les caches d’annuaire peuvent encore exposer l’identité pendant un certain temps sur les machines membres d’un domaine.

Je regarde aussi les services qui tournent sous ce compte. Un unit file systemd, un conteneur lancé avec un utilisateur dédié ou un agent de déploiement peuvent conserver des références au compte supprimé. Supprimer l’utilisateur sans corriger ces points crée des erreurs de démarrage qui n’apparaissent qu’au prochain redémarrage.

Sur les systèmes Debian-like, `deluser --remove-all-files` peut aller plus loin que la simple suppression du home, mais je le considère avec prudence. Effacer tous les fichiers possédés par l’utilisateur peut être exactement ce qu’il faut dans un environnement jetable, mais c’est trop agressif si des données partagées vivent sur le même serveur.

Les erreurs que je vois le plus souvent

Dans les environnements que j’audite, ces erreurs reviennent presque toujours pour une raison simple: l’équipe pense à la commande, mais pas au cycle de vie complet du compte. Pourtant, le risque n’est pas seulement technique. Une suppression mal préparée peut couper un accès nécessaire à une archive, briser une chaîne de déploiement ou laisser des autorisations résiduelles sur des fichiers sensibles.

C’est pour cette raison que je sépare toujours la phase d’analyse de la phase d’effacement. En pratique, ce découpage réduit les surprises et simplifie aussi les revues de changement.

Industrialiser la suppression sans perdre le contrôle

Dans un contexte DevOps, la bonne pratique n’est pas d’industrialiser la suppression brute, mais d’industrialiser la décision. Je recommande une séquence en deux temps: d’abord désactiver, puis supprimer après validation. Cette approche marche bien dans les équipes qui gèrent des serveurs, des VM ou des nœuds éphémères, parce qu’elle laisse une fenêtre de contrôle sans multiplier les risques.

Concrètement, j’aime bien automatiser quatre choses: la vérification des sessions, la sauvegarde éventuelle, la suppression elle-même et le contrôle final des restes par UID. Le script ou le playbook doit aussi journaliser l’heure, l’opérateur ou le pipeline qui a lancé l’action, et la méthode utilisée. Sans ça, une suppression réussie techniquement reste difficile à auditer.

J’ajoute souvent un garde-fou simple: si le compte appartient à une infrastructure centralisée, le job d’automatisation refuse la suppression locale et renvoie vers l’outil d’identité adéquat. Ce petit contrôle évite les faux positifs, surtout quand un poste Linux fait partie d’un parc hybride avec SSO, LDAP ou FreeIPA.

La logique est la même pour les environnements à forte rotation, comme les serveurs de build ou les machines de test. On préfère des comptes temporaires bien tracés, puis une suppression propre après usage, plutôt qu’une accumulation de comptes dormants que personne n’ose toucher.

En pratique, la bonne séquence reste simple: identifier le type de compte, couper l’accès, sauvegarder si nécessaire, supprimer avec l’outil adapté, puis vérifier les traces résiduelles. C’est cette discipline qui évite les incidents de permissions, les sessions oubliées et les suppressions trop brutales sur les serveurs de production.