Quand on parle de durcissement WordPress, on pense souvent en premier aux mises à jour, aux plugins “sécurité” et aux pare-feu. Tout ça compte. Mais, sur le terrain, la vraie différence se fait presque toujours au niveau des droits. Un site WordPress bien protégé avec des comptes trop permissifs reste une cible facile, même si les défenses techniques sont correctes.
Limiter les droits des utilisateurs et des administrateurs, ce n’est pas une affaire de “tout ou rien”. C’est un travail d’ajustement continu: qui peut publier, qui peut installer, qui peut modifier des thèmes, qui peut toucher aux options sensibles, et comment empêcher qu’un compte trop large devienne, au fil du temps, une porte d’entrée.
Je vais détailler une méthode réaliste, celle que j’applique dans les environnements où la continuité de service est cruciale, où il y a des équipes (marketing, technique, prestataires) et où l’on doit concilier sécurité et agilité.
Le problème n’est pas seulement “qui a le rôle d’admin”
WordPress a des rôles bien identifiés, administrateur, éditeur, auteur, contributeur, abonné. Mais dans la pratique, le risque surgit quand on accumule les droits “administratifs” sur trop de comptes, ou quand on laisse des utilisateurs inactifs en place pendant des années.
Un compte administrateur, c’est la capacité de faire exploser la surface d’attaque en quelques clics:
- installer et activer des plugins, modifier des thèmes, toucher aux options du site, créer d’autres comptes, et surtout, effectuer des changements qui ne laissent pas toujours de traces évidentes pour une équipe non technique.
Je me souviens d’un site d’entreprise où le DSI avait insisté pour “garder les admins en interne seulement”. Sur le papier, tout était propre. En réalité, cinq personnes avaient le rôle d’administrateur, dont deux départements qui n’avaient jamais la charge du site. Quand un prestataire a été remplacé, l’un des comptes admins de l’ancien prestataire était resté actif. Le jour où un identifiant a été réutilisé sur une autre plateforme, le site a servi de point d’atterrissage. Aucun pare-feu ne compense une chaîne d’accès trop large.
Le durcissement commence donc avant même de parler de technique. Il commence par la cartographie des tâches et des responsabilités.
Commencer par un inventaire des accès, pas par des réglages
La première étape que je fais en durcissement WordPress, c’est un inventaire simple: liste des comptes, rôle attribué, activité récente, appartenance à une équipe, raison du droit.
Dans beaucoup d’organisations, on découvre vite deux choses:
Des comptes administrateur qui ne sont là que “par confort”, Des comptes dont personne ne sait plus pourquoi ils existent.Il faut aussi penser aux accès indirects. Un utilisateur peut être admin, mais il peut aussi être “à côté” du site via:
- un accès à la base de données, un compte d’hébergement, une clé SSH partagée, une console d’administration chez le fournisseur.
Même si l’article se concentre sur WordPress, ce que je recommande est cohérent: on réduit d’abord les permissions là où on a le contrôle direct, sur WordPress lui-même, puis on alignera le reste.
Un point de méthode: faites l’inventaire un jour où personne ne modifie le site. Vous évitez de capturer des états incohérents, et vous repérez mieux ce qui était déjà “dans le rouge”.
Diminuer les administrateurs: le principe du moindre privilège
L’idée de base est simple: si quelqu’un n’a pas besoin de créer, d’installer, ou de modifier des composants critiques, il ne doit pas être administrateur. Dans WordPress, la différence concrète entre éditeur et administrateur se ressent immédiatement dans ce que la personne peut faire sans validation.
Une ligne directrice pratique:
- l’administrateur est réservé à la gestion globale et aux actions à fort impact, l’éditeur gère la publication et l’organisation éditoriale, les auteurs et contributeurs écrivent, soumettent, sans manipuler les paramètres sensibles.
En durcissement WordPress, le meilleur levier est souvent de réduire le nombre d’administrateurs à un noyau très court. Sur un petit site, je vise idéalement 1 à 2 comptes administrateur “humains” qui gardent la charge technique. Sur des organisations plus structurées, on peut monter, mais rarement au-delà de 3 à 5, et seulement si les responsabilités sont clairement séparées.
Il y a des exceptions, et il faut les gérer avec soin. Par exemple, si une équipe marketing doit régulièrement modifier des thèmes ou installer des plugins, c’est un signe que le processus n’est pas clair ou que l’architecture n’est pas adaptée. La correction la plus saine n’est pas de multiplier les admins, c’est de créer une voie sécurisée: validation avant publication, plugins installés par le noyau admin, ou un environnement de préproduction.
Rôles WordPress: ce que vous pouvez vraiment limiter
WordPress ne protège pas chaque micro-action avec une finesse parfaite, mais les rôles restent une base utile pour compartimenter. Le point clé n’est pas d’apprendre par cœur toutes les capacités, c’est de comprendre la logique.
Un utilisateur “éditeur” est généralement capable de gérer le contenu, publier, modifier des pages et des articles, gérer des catégories selon les droits disponibles. Il peut aussi souvent administrer certains aspects liés à l’édition. À l’inverse, l’administrateur a accès à des zones où un changement peut compromettre le site: extensions, thèmes, options globales.
Un “auteur” peut publier ses propres contenus (selon configuration), un “contributeur” soumet, un “abonné” lit et gère son profil. Le durcissement devient efficace quand chaque profil correspond à un besoin réel, avec le moins de pouvoir possible.
Quand le rôle ne suffit pas
Il arrive que le rôle “éditeur” donne trop d’autonomie sur des sites où des pages sensibles sont manipulées. Par exemple, si l’équipe éditoriale doit modifier un modèle de page, ou toucher à des champs qui déclenchent des actions externes, vous pouvez réduire l’ampleur de l’autonomie en imposant un circuit de validation.
Le circuit de validation, ce n’est pas seulement un réglage de workflow. C’est un processus. Il faut, dans l’outil de contenu, empêcher la publication directe de certaines zones. Dans WordPress, cela passe par des choix de rôles et par la façon dont vous gérez le statut, brouillon, relecture, validation.
Désactiver les comptes inutiles et contrôler les comptes “fantômes”
Un site WordPress accumule vite des comptes, surtout si vous utilisez des prestataires et des équipes qui changent.
Je regarde toujours trois catégories:
- les comptes actifs qui ont un vrai besoin, les comptes actifs mais trop permissifs, les comptes inactifs ou sans justification.
Sur ces derniers, la tentation est de “laisser au cas où”. Le cas “au cas où” est aussi le cas “au risque”. Un compte inactif peut être compromis via une fuite d’identifiants ailleurs, via un mot de passe réutilisé, ou via des sessions qui n’ont pas expiré comme prévu.
La bonne pratique, dans un cadre gérable, est de faire une revue périodique. Sur des sites à faible activité, une revue trimestrielle ou semestrielle peut suffire, sur des environnements où beaucoup d’intervenants tournent, je recommande au moins mensuellement. L’objectif n’est pas de tout supprimer immédiatement. L’objectif est de réduire la taille du “champ d’attaque”.
Voici une règle simple que j’applique: si une personne n’a pas touché le site depuis une période donnée, vous devez soit expliquer pourquoi elle garde un accès, soit réduire son rôle, soit désactiver.
Gestion des mots de passe et des sessions: un autre volet du durcissement
Limiter les droits ne suffit pas si les identifiants sont faibles. Les droits réduits limitent l’impact d’une compromission, mais ils ne l’empêchent pas.
Je recommande de traiter l’accès comme un produit, avec une hygiène minimale:
- mots de passe robustes et uniques, gestion centralisée via un coffre sécurisé si possible, rotation uniquement quand il y a un signal (compromission suspecte, départ d’employé, fuite probable), et un contrôle des sessions actives.
WordPress permet de vérifier et gérer certaines sessions selon la configuration, mais l’implémentation dépend aussi de l’hébergement et des plugins de sécurité. Si vous avez un SSO ou un proxy d’accès, c’est un point à aligner, car il peut neutraliser ou compliquer la logique des sessions WordPress.
Là encore, je privilégie la cohérence plutôt que la multiplication de “mécaniques”. Une organisation peut se retrouver avec trois systèmes différents de déconnexion et de contrôle, et au final personne ne sait ce qui est effectif.
Séparer les environnements: éviter d’exposer l’administration en production
Beaucoup d’incidents viennent d’un mélange entre développement et production. Si vous laissez des utilisateurs admin agir sur la production, vous payez le prix en surface d’attaque, en risques de configuration, et en difficulté de rollback.
Une alternative réaliste consiste à utiliser un environnement de préproduction, où les droits élevés sont limités au strict nécessaire et où les changements sont testés avant d’entrer en production. Dans ce modèle:
- les éditeurs valident la publication, l’équipe technique admin teste plugins et thèmes en préprod, puis on promeut en production via un processus contrôlé.
Même si vous ne faites pas de CI/CD complet, le simple fait d’avoir une préprod gérée avec un petit noyau d’administrateurs réduit drastiquement la probabilité qu’un compte “large” mette réellement en danger le site.
Politiques concrètes de rôles selon les profils
Le plus efficace est d’attribuer des rôles basés sur une grille simple de responsabilités. Pas besoin d’un modèle théorique, il faut un usage quotidien.
Je vous donne un exemple de distribution que j’ai souvent vue (et que j’adapte ensuite à votre contexte):
- Une personne technique (ou un binôme) en administrateur, pour plugins, mises à jour, configurations. L’équipe éditoriale en éditeur, pour gérer contenus, catégories, relectures. Des contributeurs ou auteurs pour l’écriture, selon qu’ils peuvent publier directement ou non.
Le point d’attention ici, c’est la capacité à publier. Si vous autorisez des auteurs à publier directement, vous devez être sûr que leurs contenus ne déclenchent pas de comportements risqués (liens externes, intégrations, shortcodes sensibles). Si ce n’est pas maîtrisé, on repasse au workflow de validation, c’est plus lent, mais l’impact est bien plus faible en cas d’erreur.
Une petite checklist pour un durcissement par étapes
Quand je dois le faire vite, sans casser l’activité, je préfère une séquence courte. Voici la seule liste que je recommande, parce qu’elle tient dans la tête et qu’elle sert vraiment.
- Relever tous les comptes WordPress, leur rôle, et leur dernière activité. Réduire le nombre d’administrateurs au noyau strict (1 à 2 si possible). Remplacer les “admins” excédentaires par des rôles adaptés (éditeur, auteur, contributeur). Désactiver les comptes sans besoin actuel, surtout ceux liés à des prestataires terminés. Planifier une revue régulière des droits et des comptes.
Ce qui compte, c’est que la démarche soit traçable. Si vous réduisez des droits et que, trois jours après, un service réclame une capacité qui “était possible avant”, vous devez savoir si le problème vient du réglage de rôle ou d’une dépendance à un plugin.
Vérifier que les plugins n’ouvrent pas des chemins “contournant” le modèle de rôles
On pourrait penser que limiter les rôles WordPress suffit. En réalité, certains plugins créent leurs propres capacités, parfois via des rôles additionnels, parfois en s’appuyant sur l’accès admin.
Deux pièges fréquents:
Un plugin qui expose une interface de gestion avancée à trop de rôles, Un plugin qui “s’aligne” sur l’administrateur WordPress sans granularité.Le durcissement, ici, consiste à examiner les plugins installés et à vérifier qui peut les utiliser. Selon les plugins, vous pouvez:
- restreindre les pages d’administration, limiter qui peut modifier les réglages, ou empêcher des actions sensibles.
Je fais souvent un test simple en local ou sur un compte de test: je crée un compte avec le rôle le plus faible possible pour le besoin réel, puis je vérifie ce qui se passe. Si l’utilisateur voit des menus “sécu”, “plugin”, “thèmes” ou “outils globaux”, ce n’est pas forcément un problème, mais ça doit être justifié.
Edge cases: droits minimaux sans casser la production
Il y a des situations où “réduire les droits” peut casser des routines légitimes. Quelques exemples concrets, tirés de cas rencontrés:
- un site utilise un constructeur de pages avec des droits particuliers, et certains éditeurs doivent éditer des modèles globaux, un plugin de formulaire nécessite la configuration de champs et options spécifiques par une équipe non technique, un outil de traduction dépend de rôles pour administrer les chaînes de langue.
Dans ces cas, la solution n’est pas de revenir en arrière en multipliant les administrateurs. On cherche plutôt:
- à affecter un rôle plus permissif mais pas au niveau admin, à isoler la gestion plugin à un petit noyau technique, ou à externaliser la configuration via un workflow validé.
Vous pouvez aussi segmenter le rôle en combinant des droits WordPress et un processus d’approbation. Le bon compromis est celui qui réduit le risque sans bloquer l’organisation.
Le rôle “Super Admin” en multisite: attention à la granularité
Si votre site est en WordPress multisite, la logique change. Un super admin peut gérer le réseau, donc la surface est plus vaste.
Dans ce contexte, limiter les droits des administrateurs devient un sujet encore plus critique. La règle pratique: super admins très rares, et idéalement uniquement des personnes responsables du réseau. Les admins de sites doivent être gérés avec un modèle de responsabilité clair. Si vous avez un multisite pour des besoins marketing avec plusieurs équipes, le risque vient de la confusion entre “administrer un site” et “administrer tout le réseau”.
Si vous êtes dans ce cas, adaptez votre audit à la structure réseau, pas uniquement à la liste des rôles standard.
Ce que je recommande pour la revalidation après changements
Quand vous modifiez les rôles, vous devez vous donner une période de vérification. Sinon, vous ne saurez pas si vous avez:
- introduit une friction, bloqué une tâche, ou laissé un accès trop large.
Dans la pratique, je fais une courte boucle de revalidation:
- une journée d’observation avec les équipes concernées, un point à froid pour les actions “impossibles”, une correction fine, pas une remise en cause totale.
C’est un détail, mais je l’ai vu empêcher des erreurs graves. Par exemple, si un éditeur n’a plus accès à certaines fonctions, il peut contourner en demandant un accès temporaire admin. Si vous n’avez pas anticipé, vous re-créez le problème que vous essayiez de résoudre.
Mesurer l’amélioration: moins de comptes, moins de privilèges, même capacité
La réussite d’un durcissement WordPress sur les droits ne se mesure pas uniquement à “on a désactivé des comptes”. Elle se mesure à un ensemble d’indicateurs simples:
- nombre d’administrateurs réduit, nombre de comptes inactifs supprimés ou désactivés, séparation claire entre technique et édition, absence de demandes récurrentes de “droit temporaire admin”, diminution des incidents liés aux erreurs de configuration ou aux modifications non maîtrisées.
Je privilégie aussi la qualité des processus: quand la séparation des rôles est bonne, les demandes deviennent plus précises. On ne dit plus “il faut admin”, on dit “il faut pouvoir X dans l’interface de contenu”. Cette précision est un signe que le durcissement devient une routine, pas un événement ponctuel.
Mettre en place une politique de départ d’employé ou de prestataire
Le dernier point, celui qui sauve le plus souvent, est la politique de départ. Dans beaucoup d’entreprises, le départ est géré côté RH, mais l’accès WordPress reste oublié.
Je recommande un protocole très concret, même si vous n’avez qu’une petite équipe:
- à la date de départ, on retire immédiatement les comptes, on réattribue si nécessaire (mais pas en conservant les anciens identifiants), on vérifie aussi les rôles escaladés, admin et super admin si multisite.
Ce protocole est une mesure de durcissement WordPress très efficace, parce qu’il réduit la probabilité de compromission par réutilisation de mots de passe ou accès partagé.
Si vous avez un prestataire externe, je conseille aussi de limiter la durée d’accès et d’utiliser un compte dédié. Quand le prestataire part, vous supprimez le compte, vous ne gardez pas un “compte de service” qui dort.
Garder l’équilibre: sécurité, maintenance et confiance
Réduire les droits des utilisateurs et des administrateurs est une démarche de responsabilité. Cela touche à la confiance, parce que https://gardewp.fr/securite-wordpress/ vous faites une promesse implicite: les gens qui ont besoin de travailler pourront le faire, et ceux qui n’ont pas besoin n’auront pas accès.
Sur le long terme, cela implique un effort de maintenance des rôles. Le site évolue, les équipes changent, de nouveaux plugins arrivent. Les droits doivent suivre ces changements.
Le bon indicateur est simple: lorsque vous observez que la plupart des utilisateurs gèrent leur périmètre sans vous solliciter pour des droits admin, et que l’équipe technique a une vision claire de la configuration, vous avez atteint le bon équilibre.
La sécurité WordPress ne se joue pas seulement dans les logs et les pare-feu. Elle se joue dans les habitudes, dans la réduction du pouvoir inutile, et dans le fait qu’un compte compromis ne peut pas transformer rapidement une simple erreur en incident majeur. En durcissement WordPress, c’est souvent là que se trouve la vraie marge de manœuvre.