La “protection WordPress” ne se limite pas à un plugin de sécurité et à un mot de passe bien choisi. Dans beaucoup de sites, le maillon faible se trouve ailleurs: dans la liste des utilisateurs. Comptes oubliés, rôles trop élevés, anciennes adresses encore valides, intégrations qui utilisent des comptes de service, et utilisateurs qui ne se connectent plus depuis des mois ou des années. Tant qu’un compte existe, il peut être ciblé, même si le site “n’a pas l’air” d’être attaqué.
Gérer les utilisateurs, https://gardewp.fr/securite-wordpress/ puis supprimer proprement les comptes devenus inutiles, revient à réduire la surface d’attaque. Mais c’est aussi un travail qui demande du discernement, car un utilisateur “inactif” peut rester indispensable à un historique, à des médias, ou à des workflows spécifiques.
Je vous propose une méthode pragmatique, celle que j’ai fini par appliquer systématiquement sur des sites de taille variée, avec des garde-fous pour éviter les dégâts collatéraux.
Pourquoi la gestion des utilisateurs protège vraiment
Sur WordPress, l’accès ne dépend pas seulement du mot de passe. Il dépend aussi de ce que l’utilisateur est autorisé à faire: rôle, capacité à modifier des thèmes ou des plugins, accès à l’édition d’articles, droits d’administration. Un compte administrateur, même “inactif”, reste un objectif réaliste pour quelqu’un qui cherche des entrées faciles.
Ce n’est pas une question de peur générale. C’est une question de statistiques internes à votre propre site: chaque compte ajoute un ensemble de secrets potentiels (identifiants, cookies, jetons de session, méthodes d’authentification). Même si vous appliquez une politique solide, plus il y a de comptes, plus vous multipliez les angles morts.
J’ai déjà vu des situations où tout était “verrouillé” côté firewall, et où l’audit des utilisateurs a révélé un compte admin créé pour un prestataire, jamais retiré après la fin de mission. Le compte n’avait pas été utilisé pendant une longue période. Il a pourtant servi de point d’entrée après une tentative de réutilisation d’identifiants sur d’autres services. Ce genre d’incident ne tient pas à une faiblesse technique du site, mais à la durée de vie des accès.
Comprendre les rôles, avant de vouloir “nettoyer”
Avant de supprimer, il faut comprendre ce que vous risquez de casser. WordPress utilise des rôles et des capacités. En pratique, le point critique est la différence entre un compte qui ne fait “que publier” et un compte qui peut tout administrer.
Un compte auteur, éditeur ou contributeur peut avoir besoin d’exister pour un historique d’articles, ou parce que des auteurs continuent de contribuer. À l’inverse, un rôle administrateur doit être réservé à très peu de personnes. Si vous avez plusieurs admins, la question n’est pas seulement “est-ce qu’ils sont inactifs ?”, mais “pourquoi ont-ils ce niveau de pouvoir ?”.
Deux habitudes simples changent tout:
1) Réduire les privilèges au minimum nécessaire, surtout pour les comptes qui ne gèrent plus la maintenance. 2) Définir une règle claire sur la suppression: un compte est supprimé quand il n’a plus de raison d’être, et quand les contenus attribués à ce compte ont été transférés.
Le nettoyage des utilisateurs doit être un acte de gouvernance, pas un réflexe.
Faire l’inventaire: ce que vous devez savoir sur chaque compte
Le premier travail est rarement “supprimer”. C’est “comprendre”. Sur beaucoup de sites, l’équipe se rend compte qu’elle ne sait plus exactement qui a créé quoi, ni pourquoi certains comptes existent.
Commencez par regarder, pour chaque utilisateur:
- le rôle exact (administrateur, éditeur, auteur, contributeur, abonné), la date de dernière connexion (ou un indicateur équivalent dans l’interface), l’email, qui peut révéler une ancienne structure (ancienne entreprise, ancienne boîte mail, domaine fermé), l’appartenance à des workflows (par exemple, compte utilisé pour des publications programmées, ou pour un plugin spécifique), et le volume de contenus attribués (articles, pages, médias, commentaires).
Si votre site a plusieurs contributeurs, vous pouvez aussi repérer des modèles: comptes créés pour “test”, comptes créés pour “passer la validation”, comptes créés pour un prestataire. Souvent, ce sont ces catégories qui finissent par accumuler des comptes inactifs.
Je vous conseille de documenter rapidement vos constats dans un fichier interne (ou un ticket): “à conserver”, “à rétrograder”, “à transférer puis supprimer”. Pas besoin d’un système lourd, juste une trace pour éviter de replonger dans la confusion deux semaines plus tard.
Définir ce qu’est un compte “inutilisé” sur votre site
Un piège classique consiste à fixer une règle trop rigide. Si vous décidez “tout ce qui n’est pas connecté depuis 90 jours est supprimé”, vous risquez de toucher:
- un utilisateur qui se connecte seulement lors de mises à jour ponctuelles, un rédacteur qui travaille par lots (il peut s’absenter pendant des mois), un compte technique utilisé par un processus interne qui n’apparaît pas dans l’interface comme une “connexion humaine”.
La solution la plus efficace est de définir plusieurs niveaux de décision, plutôt qu’une seule date.
Voici une grille raisonnable à adapter à votre réalité. Elle n’a pas besoin d’être compliquée, mais elle doit être cohérente dans le temps.
- Un compte a encore un rôle actif si la personne (ou l’équipe) publie, relit, valide ou maintient régulièrement. Un compte est suspect si l’email appartient à un domaine expiré, si le rôle est trop élevé, ou si aucune activité ne correspond aux besoins actuels. Un compte est supprimable si vous pouvez transférer les contenus et si aucun processus connu n’en dépend.
Si vous manquez d’information, partez du principe que le risque vient de la suppression trop rapide. Mieux vaut rétrograder un rôle trop puissant et garder une trace, que supprimer et découvrir ensuite une dépendance cachée.
Le plan d’action: auditer, rétrograder, transférer, puis supprimer
Une fois votre inventaire fait, la démarche la plus sûre se déroule en quatre temps. Je l’utilise comme séquence car elle limite le risque et rend le résultat vérifiable.
Première étape: sauvegarder et préparer le terrain
Avant toute opération significative, prenez une sauvegarde fonctionnelle. Pas une sauvegarde “théorique” qui n’a jamais été testée. Idéalement, vous devez être capable de restaurer, au moins sur un environnement de test, ou via un point de restauration de votre hébergeur.
Sur certains projets, j’ai aussi prévu une fenêtre courte pour réaliser l’action, puis vérifier rapidement le front, l’admin, et quelques pages clés.
Deuxième étape: rétrograder avant de supprimer
Souvent, le meilleur compromis consiste à retirer les privilèges avant d’envisager la suppression.
Un compte admin peut être rétrogradé en éditeur si la personne doit continuer à gérer des contenus, ou en auteur si elle doit uniquement écrire. Cette étape réduit immédiatement la surface d’attaque, même si le compte reste temporairement en place.
Troisième étape: transférer la propriété des contenus
WordPress attribue les contenus à un auteur. Si vous supprimez un utilisateur sans transférer les contenus, vous risquez de vous retrouver avec des posts orphelins ou un historique désagréable à gérer. Dans l’interface, WordPress demande généralement ce type de décision, mais il faut la faire avec méthode.
L’important est d’assigner les contenus à un utilisateur crédible, celui qui gérera réellement l’historique. Sur un site éditorial, cela peut être un éditeur en charge. Sur un site vitrine, cela peut être le compte “principal” du site.
Si vous avez des médias attachés et des pages créées par ce compte, le transfert doit rester cohérent pour éviter des surprises lors de l’édition.
Quatrième étape: supprimer uniquement après vérification
Une fois les contenus transférés et les rôles adaptés, la suppression devient une action logique.
Je préfère supprimer par petites vagues, plutôt qu’en une seule opération sur des dizaines de comptes. Cela permet de vérifier les impacts au fur et à mesure, et de revenir en arrière si quelque chose cloche.
Checklist rapide (celle qui évite 80% des erreurs)
Quand je fais un nettoyage sur un site réel, je garde cette séquence sous les yeux. Elle ne dépasse pas cinq points, parce qu’au-delà, on finit par la contourner.
- Vérifier la sauvegarde et s’assurer qu’on peut restaurer, même rapidement. Identifier les comptes administrateurs et les réduire en priorité. Vérifier la dernière activité et les contenus attribués à chaque compte. Prévoir un transfert de contenus vers un utilisateur cible avant suppression. Faire une vérification après opération: connexion admin, édition de contenus, pages clés.
Si vous respectez ces cinq étapes, vous limitez énormément les effets secondaires.
Où regarder l’activité des utilisateurs, et quoi interpréter
Dans l’administration WordPress, l’écran de gestion des utilisateurs vous donne souvent des indices sur l’activité, et l’interface liste les rôles. Selon votre configuration, vous aurez plus ou moins de visibilité sur les connexions récentes.
Ce que j’interprète comme “signal fort”:
- comptes avec rôle élevé (administrateur) et faible activité, comptes dont l’email appartient à un ancien acteur (domaine fermé, adresse qui n’existe plus), comptes créés sur une période courte, puis jamais réutilisés, comptes qui ont une quantité de contenus importante, mais qui ne sont plus liés à l’équipe actuelle.
À l’inverse, un compte qui a très peu d’articles mais qui a des droits d’admin est souvent un faux ami: il n’a probablement pas besoin d’être au niveau administrateur.
Cas particuliers: quand supprimer est risqué (et quand ça ne l’est pas)
Certaines situations exigent une décision plus fine.
1) Comptes “techniques” ou utilisés pour des intégrations
Certains plugins ou intégrations s’appuient sur un compte WordPress pour accéder à des fonctionnalités. Dans ce cas, l’utilisateur n’apparaît pas “comme un humain qui se connecte”, mais il est utilisé par un flux. Supprimer le compte peut casser l’intégration sans avertissement immédiat.
Si vous suspectez ce scénario, cherchez les paramètres des plugins, les webhooks, les connexions vers des services externes, et tout usage d’API configuré. Une fois la dépendance confirmée, vous pouvez remplacer le compte par un compte “de service” contrôlé, puis supprimer l’ancien.
2) Sites multisites ou réseaux
Dans un multisite, les comptes peuvent exister à différents niveaux, et les rôles peuvent être définis par le réseau. Le nettoyage devient plus délicat, car une suppression au mauvais niveau peut avoir des effets plus larges.
Si vous êtes en multisite, traitez le réseau comme une entité séparée: auditez au niveau approprié, et assurez-vous que les contenus et rôles sont cohérents.
3) Historique éditorial et signatures
Dans des sites éditoriaux, l’auteur d’un article peut porter une valeur de marque, même si l’auteur ne “publie plus”. Supprimer le compte peut donner un rendu moins propre, selon votre thème et vos affichages.
Dans ce cas, je privilégie la rétrogradation du rôle, et je conserve le compte comme entité historique, tout en renforçant la sécurité autour (mot de passe robuste, suppression d’accès admin, et si nécessaire, désactivation de certaines capacités).
4) Comptes qui ne sont pas inactifs, mais dont le rôle est trop large
C’est un cas fréquent. La dernière connexion peut être récente, mais le rôle est disproportionné. Ici, vous n’avez pas besoin de supprimer. Rétrograder et limiter les capacités est déjà une vraie victoire.
Supprimer les comptes inutiles: risques et garde-fous
La suppression elle-même n’est que la dernière étape. Le vrai risque vient de ce qui se passe avant: rôle trop haut, transfert mal fait, dépendances cachées.
Deux garde-fous que j’applique systématiquement:
- Toujours choisir un utilisateur “cible” pour le transfert, et s’assurer qu’il a les droits nécessaires. Faire une validation rapide après suppression, pas sur un scénario hypothétique. Par exemple, connecter un compte administrateur, ouvrir l’éditeur d’un contenu transféré, vérifier la liste des médias, et tester une page typique.
Une fois, sur un site, le transfert de contenu avait été fait correctement, mais un plugin de newsletter était configuré en interne sur l’ancien utilisateur. La détection n’a pas été immédiate. La vérification post-édition a révélé un comportement différent côté back-office. Rien de dramatique, mais la correction a demandé un réajustement de configuration.
C’est pour ça que je préfère une petite vérification après chaque vague, plutôt que “nettoyage massif, puis on verra”.
Réduire durablement le besoin de “nettoyage”
Le nettoyage des utilisateurs est utile, mais l’idéal est d’éviter d’accumuler des comptes inutiles.
La manière la plus durable de protéger WordPress consiste à encadrer la création des accès:
- Procédure de création de compte avec justification du rôle. Durée de vie d’accès pour les prestataires, avec une date de fin planifiée. Revue périodique des comptes (tous les 3 à 6 mois selon la taille de l’équipe). Normalisation des comptes, par exemple un compte unique pour l’édition et un autre pour la maintenance.
Une fois que ces règles sont en place, la liste des utilisateurs devient plus “propre”, et la protection WordPress devient plus continue, moins événementielle.
Stratégies selon la taille de l’équipe
Les choix ne sont pas les mêmes pour un site personnel, une TPE ou une équipe marketing avec plusieurs contributeurs.
Sur un petit site, je vois souvent un équilibre simple: un ou deux comptes administrateurs maximum, un compte éditeur pour le contenu, et des auteurs si nécessaire.
Sur une organisation plus grande, la règle change: davantage de granularité de rôles, et un processus de revue régulier. Dans ces environnements, la suppression brute est rarement la première option. La rétrogradation et la limitation des privilèges font gagner du temps et réduisent le risque.
Voici trois scénarios typiques, et comment je tranche dans les faits:
- Prestataire qui a fini sa mission: rétrograder en auteur (ou supprimer après transfert si aucun besoin éditorial), puis supprimer après confirmation des contenus. Ancien salarié ou interne parti: transférer les contenus à l’équipe actuelle, retirer les privilèges admin, puis supprimer si aucune intégration ne dépend du compte. Compte à usage incertain: conserver temporairement, investiguer la dépendance via plugins et configurations, puis décider suppression ou rétrogradation.
Ce que j’éviterais absolument
Pour rester concret, il y a quelques erreurs courantes que j’ai vues revenir trop souvent:
- Supprimer des comptes sans vérifier la propriété des contenus. Laisser plusieurs comptes administrateurs “par confort”. Rétrograder un compte admin en espérant que tout ira bien, sans tester les fonctionnalités liées (édition, plugins, formulaires, exports). Multiplier les comptes “pour faire un test” puis oublier.
La sécurité n’est pas seulement une question de correction, c’est une question d’hygiène opérationnelle.
Sécuriser les utilisateurs qui restent
Nettoyer ne suffit pas si les comptes conservés restent fragiles. Pour les utilisateurs légitimes, vous pouvez renforcer la sécurité sans transformer votre équipe en gardiens de coffre-fort.
Les leviers classiques sont:
- des mots de passe solides et renouvelés pour les comptes à risque, la restriction des rôles, en particulier pour les admins, l’utilisation de contrôles additionnels si votre environnement le permet (selon vos contraintes internes), et la surveillance des connexions, via les journaux fournis par votre stack, ou par les fonctionnalités natives de votre hébergement.
Je ne recommande pas d’empiler des mesures sans vérifier leur impact, notamment sur l’authentification des équipes et sur les intégrations. Une “protection WordPress” efficace est celle qui reste en place et qui ne casse pas le travail.
Une dernière question à vous poser avant de cliquer
Avant chaque suppression, je reviens à une seule question simple: “Si je supprime ce compte, qu’est-ce qui peut casser, et comment je le vérifie ?”
Cette manière de penser force à anticiper les dépendances. Elle pousse aussi à documenter. Et quand vous faites le ménage par vagues contrôlées, vous gagnez rapidement la confiance de votre équipe, parce que les changements sont maîtrisés.
Gérer les utilisateurs et supprimer les comptes inutiles n’est pas une tâche glamour. Mais c’est un levier concret, rapide à mesurer, et très souvent négligé. Quand la liste des accès devient cohérente, la protection WordPress se voit dans le temps, pas seulement dans des audits ponctuels.