Qui, sur le site WordPress d’un client, devrait pouvoir installer un plugin ? Sur les 5 rôles natifs de WordPress, un seul le peut par défaut : l’Administrateur. Chaque rôle accordé au-dessus du strict nécessaire élargit la surface d’attaque exploitable : Patchstack chiffre à 20,6% la part des vulnérabilités WordPress 2025 exploitables depuis un simple compte Contributeur et 11,5% depuis un compte Abonné. Distribuer les rôles utilisateurs WordPress correctement évite l’incident qui vous tombera dessus 6 mois plus tard, sur un site que vous ne surveillez plus au quotidien.
Les 5 rôles WordPress et ce qu’ils peuvent vraiment faire
Un rôle regroupe des capacités (capabilities) : des permissions unitaires comme publish_posts et install_plugins, plus rarement delete_users. WordPress assemble ces capacités en 5 rôles par défaut, plus un 6e (Super Admin) réservé au multisite. Le tableau ci-dessous détaille la répartition réelle des capacités par rôle, telle qu’assignée par défaut dans le core.
| Capacité | Administrateur | Éditeur | Auteur | Contributeur | Abonné |
|---|---|---|---|---|---|
| Publier son propre contenu | Oui | Oui | Oui | Non | Non |
| Modifier le contenu d’autrui | Oui | Oui | Non | Non | Non |
| Installer plugins et thèmes | Oui | Non | Non | Non | Non |
| Gérer les autres utilisateurs | Oui | Non | Non | Non | Non |
| Accéder au Site Editor (FSE) | Oui | Non | Non | Non | Non |
| Créer un Application Password | Oui | Oui | Oui | Oui | Oui |
Regardez la dernière ligne du tableau. Elle s’applique à tous les rôles sans exception, y compris les deux plus bas de la hiérarchie : Contributeur et Abonné.
Pourquoi un compte Contributeur n’est pas un compte sans risque
32,1% des vulnérabilités WordPress recensées en 2025 sont exploitables depuis un compte Contributeur ou Abonné, d’après le rapport mi-année 2025 sur les vulnérabilités WordPress de Patchstack. Le rôle le plus bas de la hiérarchie devient alors le point d’entrée le plus probable, largement devant l’Administrateur. Le raisonnement classique, protéger en priorité le compte admin, rate la moitié du problème.
« 20,6% des vulnérabilités WordPress recensées en 2025 nécessitent uniquement un compte de niveau Contributeur pour être exploitées, contre 11,5% pour un compte Abonné. » (Patchstack, rapport mi-année 2025 sur les vulnérabilités WordPress)
Les extensions concentrent 91% des failles découvertes sur l’année, contre 6 dans le core lui-même. Un compte Contributeur qui active un plugin vulnérable ouvre une porte que l’Administrateur du site ne verra pas venir. Il en va de même pour un compte qui exploite une faille de désérialisation (object injection PHP) dans une extension mal codée. Chaque faille de ce type est documentée sous un identifiant CVE dès sa divulgation publique. Le rôle bas concentre une bonne part du risque et reste largement sous-surveillé face à l’Administrateur.
Qui doit avoir quoi sur un site que vous gérez pour un client
Un classement de plugins de gestion des rôles n’aiderait pas ici. La décision se prend au niveau des capacités natives de WordPress, avant l’installation de la moindre extension. Sur un parc de 5 à 30 sites clients, la question revient à chaque nouveau projet : le community manager du client, l’assistant qui poste 2 fois par semaine, le consultant SEO externe, le stagiaire d’été.
- Community manager qui publie et corrige ses propres articles : rôle Auteur, jamais Éditeur par défaut
- Assistant qui rédige mais ne doit rien publier sans relecture : rôle Contributeur
- Consultant SEO externe qui modifie meta, contenu et catégories : rôle Éditeur, sans capacité list_users ni promote_users
- Développeur ou agence tierce en intervention ponctuelle : compte Administrateur nominatif, désactivé après la mission
Un point compte autant que la distribution initiale : la révocation. Un compte Administrateur créé pour un besoin ponctuel et resté actif 8 mois après la fin de la mission est une porte laissée ouverte sur un site que plus personne ne surveille activement. Sur un parc de sites clients, ce contrôle se fait au moment de la facturation finale, jamais après : une fois le projet clos dans le CRM, la révocation d’accès WordPress passe systématiquement à la trappe.
Un rôle, une responsabilité : c’est la règle qui manque le plus souvent sur les sites hérités d’un autre prestataire. On y trouve régulièrement 3 comptes Administrateur actifs, dont 2 appartiennent à des personnes qui ne se souviennent plus avoir eu accès au site. Résultat concret : vous passez une partie de votre temps à patcher un thème custom que WP 6.x ou un compte mal calibré vient de casser en activant une extension incompatible.
Application Passwords : la faille que les rôles ne couvrent pas
Depuis WordPress 5.6, n’importe quel rôle, y compris Abonné, peut générer un Application Password depuis son profil. Ce mot de passe applicatif contourne le CAPTCHA et la double authentification. Aucune alerte ne se déclenche. Le rate limiting de connexion ne s’applique pas non plus, puisqu’il sert justement à s’authentifier sans passer par l’écran de login classique. Le core WordPress n’offre aucune capacité native pour restreindre cette fonction à un rôle donné. Un WAF (Web Application Firewall) filtre le trafic malveillant en amont sans jamais corriger une distribution de rôles trop généreuse en interne.
Attention : sur un site multi-auteurs, un compte Abonné compromis peut donc générer un accès API persistant, invisible dans les journaux de connexion classiques. La parade reste un plugin de gestion fine des capacités ou un filtre PHP sur le hook wp_is_application_passwords_available_for_user.
Ce que l’Éditeur ne peut pas toucher malgré son statut
Un Éditeur publie et modifie tout le contenu du site, y compris celui des autres auteurs. La suppression fait aussi partie de ses droits. Il ne touche pourtant jamais au Site Editor (FSE) des thèmes de blocs. La capacité edit_theme_options, qui contrôle l’accès aux templates de blocs et aux styles globaux, reste réservée à l’Administrateur par défaut dans le core. Un Éditeur frustré de ne pas pouvoir ajuster un template suit simplement le fonctionnement prévu du rôle.
Auditer les rôles existants avec WP-CLI
Sur un site repris d’un autre prestataire, l’audit démarre en ligne de commande. La commande wp user list –role=administrator liste tous les comptes Administrateur actifs, souvent plus nombreux que ce que le client imagine. wp core verify-checksums vérifie ensuite que les fichiers core n’ont pas été altérés, une étape utile quand un compte à privilèges a été compromis. Le diagnostic initial s’arrête là.
Pour créer une capacité sur mesure sans distribuer le rôle Administrateur complet, 2 extensions couvrent l’essentiel du terrain : User Role Editor et PublishPress Capabilities. Members fait aussi l’affaire si l’interface des deux premières ne convient pas. Chacune retire une capacité précise d’un rôle standard ou en crée un qui n’existe pas nativement. Sur les sites que nous auditons, cette vérification des rôles fait partie du premier passage, avant même le diagnostic de performance.
Rôles personnalisés et types de contenu ACF
Un custom post type créé pour un client (fiches produits, études de cas, portfolios) hérite par défaut des capacités génériques edit_posts et publish_posts, sauf si le paramètre capability_type a été précisé à la déclaration. Sans ce réglage, un Contributeur qui ne devrait gérer que des articles standards peut se retrouver à modifier un type de contenu construit avec ACF et jamais destiné à son rôle. Le correctif se joue à la déclaration du CPT : activer map_meta_cap et nommer explicitement chaque capacité associée.
Vérifiez ce point à chaque migration de site ou reprise de projet. Deux minutes suffisent avec WP-CLI, contre plusieurs heures de reprise si l’oubli n’est découvert qu’après un incident.
Un rôle mal distribué ne se voit jamais avant l’incident.
