Rôles WordPress : qui peut faire quoi, et quel rôle donner à chacun

Cinquante capacités pour l’administrateur. Une seule pour l’abonné. Entre les deux, les rôles WordPress découpent ce que chaque compte a le droit de faire sur votre site : publier, corriger le travail des autres, installer une extension, toucher aux réglages… ou simplement lire.

Connaître ces listes par cœur ne sert pas à grand-chose. Au moment de créer un compte, une seule question compte : qui laissez-vous toucher à quoi ? Ma propre règle, quand je livre un site, est simple. Le client dont j’assure la maintenance reçoit le rôle Éditeur. Celui dont je ne m’occupe pas reçoit le rôle Administrateur, contre une décharge signée.

Pour cette nouvelle version, j’ai fait relever les capacités de chaque rôle sur un WordPress 7.1.2 vierge, en français. Puis une seconde fois, après l’activation de WooCommerce, Yoast SEO et bbPress. Les chiffres qui suivent viennent de ce relevé et du code de WordPress : ils corrigent au passage plusieurs affirmations de la première version de cet article.

Qui a le droit de quoi sur WordPress ?

Un rôle WordPress est une étiquette posée sur une liste de capacités. Une capacité est une autorisation élémentaire, comme publish_posts pour publier un article ou install_plugins pour installer une extension. Avant d’agir, le code de WordPress vérifie une capacité, avec la fonction current_user_can(). Pas le nom d’un rôle.

Le code de cette fonction le précise lui-même. Tester un rôle à la place d’une capacité est "déconseillé", car cela "peut produire des résultats peu fiables". La documentation officielle en français, elle, parle de "permissions" : le mot change, l’objet reste le même.

Voici ce que contiennent les cinq rôles natifs de WordPress sur un site unique, avec les droits qui comptent pour un responsable de site.

Ce que le compte peut faire	Capacité vérifiée	Administrateur	Éditeur	Auteur	Contributeur	Abonné
Nombre de capacités relevées	toutes	50	26	7	3	1
Publier un article	publish_posts	oui	oui	oui	non	non
Créer ou modifier des pages	edit_pages	oui	oui	non	non	non
Modifier les contenus des autres	edit_others_posts	oui	oui	non	non	non
Téléverser des médias	upload_files	oui	oui	oui	non	non
Publier du HTML non filtré, JavaScript compris	unfiltered_html	oui	oui	non	non	non
Gérer les catégories	manage_categories	oui	oui	non	non	non
Modérer les commentaires	moderate_comments	oui	oui	sur ses articles	non	non
Installer une extension	install_plugins	oui	non	non	non	non
Voir et gérer les comptes	list_users, edit_users	oui	non	non	non	non
Modifier les réglages du site	manage_options	oui	non	non	non	non

Ce que le relevé compte, et ce qu’il laisse de côté

Activez trois extensions courantes, et les compteurs s’envolent. Avec WooCommerce, Yoast SEO et bbPress, l’administrateur passe de 50 à 105 capacités. Le gestionnaire de boutique de WooCommerce en compte 83, bien plus que l’éditeur du même site (28). J’y reviens avec les rôles ajoutés par les extensions.

Le relevé met à part jusqu’à 11 anciens "niveaux", de level_0 à level_10. Ce sont des reliquats des niveaux d’utilisateur d’avant WordPress 2.0, que le code ajoute toujours aux rôles natifs. Aucun chiffre de cet article ne les compte.

À noter, enfin : les capacités stockées des cinq rôles n’ont pas bougé depuis WordPress 3.0. Ce qui a changé depuis, et qui vous concerne, se passe autour des rôles. Le rôle proposé par défaut, les mots de passe d’application, les agents IA…

Ce que l’administrateur a de plus que l’éditeur

Entre l’éditeur et l’administrateur, l’écart tient en 24 capacités. Presque aucune ne concerne le contenu : hors import et export, toutes touchent au site lui-même.

• Extensions : install_plugins, activate_plugins, update_plugins, delete_plugins, edit_plugins ;
• thèmes : install_themes, switch_themes, update_themes, delete_themes, edit_themes, edit_theme_options ;
• comptes : list_users, create_users, edit_users, promote_users, remove_users, delete_users ;
• cœur de WordPress et fichiers : update_core, edit_files ;
• réglages et tableau de bord : manage_options, edit_dashboard ;
• import, export et envoi de fichiers sans filtre : import, export, unfiltered_upload.

La dernière est un leurre. unfiltered_upload figure bien dans le rôle Administrateur, mais elle ne fonctionne qu’avec la constante ALLOW_UNFILTERED_UPLOADS. En multisite, elle reste réservée au super admin. Même chose côté éditeur avec manage_links : elle ne sert que si l’ancien gestionnaire de liens est activé, par l’option link_manager_enabled.

Les cinq rôles de WordPress, un par un

WordPress crée cinq rôles. Vous lirez parfois qu’il y en a six, Super Admin compris : la documentation officielle elle-même parle de "six rôles prédéfinis". Le code n’en crée pourtant que cinq, et Super Admin est un statut propre au multisite.

Dans l’administration de WordPress en français, les rôles s’affichent au masculin et au féminin : "Administrateur/administratrice", "Éditeur/éditrice", "Auteur/autrice", "Contributeur/contributrice" et "Abonné / abonnée". Je les appelle ici par leur forme courte.

Le rôle Administrateur

L’administrateur a les 50 capacités du cœur sur un site unique. Il installe, met à jour et supprime extensions et thèmes. Il met à jour WordPress, crée et supprime des comptes, change les réglages, importe et exporte le contenu. Le compte créé pendant l’installation de WordPress reçoit ce rôle.

Il peut aussi modifier le code PHP du thème et des extensions depuis l’administration, sauf si une constante l’en empêche. Et sur un site unique, un administrateur peut en supprimer un autre. WordPress ne protège que le compte qui agit : personne ne peut supprimer son propre compte.

La première version de cet article conseillait "un seul administrateur par WordPress". Aucune règle officielle ne fixe ce nombre. La documentation pose un principe, le moindre privilège. Et sa page sur le durcissement rappelle l’enjeu : quiconque prend la main sur un compte administrateur "peut installer des scripts malveillants" susceptibles de compromettre tout le serveur.

À qui donner ce rôle ? À la personne qui répond du site et de ses mises à jour.

Le rôle Éditeur

L’éditeur règne sur le contenu, et sur lui seul. Ses 26 capacités couvrent les articles et les pages, les siens comme ceux des autres, en brouillon, publiés ou privés. Il les crée, les publie, les modifie, les supprime. À lui aussi les catégories, la modération de tous les commentaires et l’envoi de médias.

Il ne voit pas le menu "Comptes". Ce menu n’apparaît qu’avec la capacité list_users, que seul l’administrateur possède parmi les rôles natifs. L’éditeur n’a que son "Profil". La première version de cet article affirmait le contraire.

Ce rôle revient à la personne qui tient la ligne éditoriale du site, comme le disait déjà la première version de cet article. C’est aussi celui que je donne au client dont j’assure la maintenance.

Le rôle Auteur

L’auteur publie lui-même ses articles. Avec ses 7 capacités, il rédige, publie, modifie et supprime ses propres articles, même une fois en ligne. Il téléverse aussi des médias. Les commentaires laissés sous ses articles, il peut les approuver ou les rejeter : le code ramène ce droit à celui de modifier l’article concerné.

Pas de page, en revanche, faute de edit_pages. Les articles des autres lui sont fermés. Il peut créer des étiquettes en écrivant, mais pas de catégories, réservées à l’éditeur et à l’administrateur.

Comme il publie sans relecture, je maintiens le conseil de la première version de cet article. N’accordez ce rôle qu’à des personnes de confiance, qui écrivent régulièrement pour vous.

Le rôle Contributeur

Le contributeur écrit et soumet. Ses 3 capacités se résument à lire, rédiger des articles et supprimer ceux qui ne sont pas publiés. Quand son texte est prêt, il le soumet à la relecture. Un éditeur ou un administrateur décide alors de le publier.

Il ne peut téléverser aucune image, faute de upload_files : il faudra ajouter les médias à sa place. Et une fois l’article publié, il ne peut plus le modifier. Le code exige alors edit_published_posts, que l’auteur possède et que le contributeur n’a pas.

Il crée des étiquettes, comme l’auteur, mais pas de catégories. C’est le rôle de la personne qui vous propose un article de temps en temps.

Le rôle Abonné

L’abonné n’a qu’une capacité, read. La documentation le décrit comme "quelqu’un qui ne peut que gérer son profil".

Vous lirez parfois que l’abonné "peut commenter". Commenter ne dépend pourtant d’aucune capacité de rôle : cela relève des réglages de discussion du site. Le rôle Abonné ouvre surtout l’accès à un espace de membres sur WordPress ou à une zone réservée aux inscrits.

C’est aussi le rôle à donner par défaut à tout nouveau compte. La première version de cet article le disait déjà : c’est bien moins risqué. WordPress 7.0 a fini par aller dans ce sens, à sa façon.

Super Admin : le rôle de plus en multisite

Le Super Admin n’existe que sur un réseau multisite WordPress. Et il n’est pas stocké comme les cinq autres rôles de WordPress. Le code tient une simple liste d’identifiants dans une option du réseau, site_admins, et accorde tout aux comptes qui y figurent.

Sur un site unique, la même fonction répond "oui" pour tout compte capable de supprimer des comptes. La documentation le formule autrement : sur une installation simple, les administrateurs sont, de fait, des Super Admins.

En multisite, le partage change du tout au tout. Le super admin garde pour lui l’installation, la mise à jour et la suppression des extensions et des thèmes, la mise à jour de WordPress, l’éditeur de fichiers, le HTML non filtré, la modification et la suppression des comptes.

L’administrateur d’un site du réseau ne peut même activer une extension que si le réseau a ouvert le menu des extensions aux administrateurs.

Le super admin dispose enfin de capacités propres au réseau, que personne d’autre n’a : créer et supprimer des sites, gérer les comptes, les extensions, les thèmes et les options du réseau, le mettre à niveau. Seul un super admin peut modifier un autre super admin.

Pour savoir qui détient ce statut, une commande WP-CLI suffit : wp super-admin list.

Quels rôles WordPress vos extensions ajoutent-elles ?

Une extension WordPress peut créer ses propres rôles et glisser des capacités dans les rôles existants. Refait après l’activation de WooCommerce 11.1.2, Yoast SEO 28.6 et bbPress 2.6.19, le relevé fait apparaître neuf rôles de plus.

Les rôles natifs de WordPress bougent aussi. L’administrateur gagne 55 capacités : 54 viennent de WooCommerce, une de Yoast SEO. L’éditeur en gagne deux, apportées par Yoast SEO. Auteur, contributeur et abonné restent tels quels.

WooCommerce : Client et Gestionnaire de boutique

À l’installation de WooCommerce, l’extension de boutique en ligne, deux rôles apparaissent dans WordPress : "Client" et "Gestionnaire de boutique".

Le Client n’a qu’une capacité, read, exactement comme l’abonné. Vous lirez parfois qu’il reçoit des capacités liées aux commandes. Le code de WooCommerce n’en ajoute aucune : le client suit ses commandes depuis l’espace "Mon compte" de la boutique, sans capacité particulière.

La documentation de WooCommerce le dit d’ailleurs elle-même : un accès limité, "semblable à celui d’un abonné WordPress standard".

Le Gestionnaire de boutique joue dans une autre catégorie. Le relevé lui compte 83 capacités, contre 28 pour l’éditeur du même site. Il reprend presque tout l’éditeur. S’y ajoutent 54 capacités de WooCommerce (produits, commandes, codes promo, rapports, création de clients) et quatre capacités d’administrateur : list_users, export, import et edit_theme_options.

Presque, car il lui manque unfiltered_html. Vous lirez parfois que le gestionnaire de boutique "a toutes les capacités d’un éditeur". Le code dit le contraire sur ce point précis, celui qui compte le plus.

Il peut aussi modifier des comptes, mais seulement ceux des clients. WooCommerce lui accorde ce droit à la volée, puis un filtre le réserve aux comptes clients : il voit tous les comptes, mais ne modifie que ceux-là. Toucher à un administrateur lui reste interdit dans tous les cas. Ce rôle est donc plus large qu’un éditeur côté boutique et comptes, plus étroit côté code.

Yoast SEO : SEO Manager et SEO Editor, deux copies de l’Éditeur

Yoast SEO ajoute à WordPress deux rôles, "SEO Manager" et "SEO Editor", apparus avec sa version 5.5 en septembre 2017. Leurs noms sont écrits en dur, en anglais, dans le code de l’extension. Le paquet de traduction française ne les contient pas : votre administration les affichera très probablement en anglais.

Vous lirez parfois que ces rôles délèguent le référencement sans ouvrir le reste du site. Le code de Yoast SEO 28.6 dit autre chose. Les deux rôles sont créés sur le modèle du rôle Éditeur, dont ils recopient toutes les capacités.

Un SEO Editor peut donc modifier et supprimer les contenus des autres, publier des pages et insérer du JavaScript. Exactement comme un éditeur. Rien dans leur nom ne le laisse deviner…

Ce qui les sépare tient à Yoast. Le SEO Editor reçoit wpseo_bulk_edit et wpseo_edit_advanced_metadata, que Yoast SEO donne aussi à l’éditeur : 28 au relevé, comme lui. Le SEO Manager y ajoute encore wpseo_manage_options pour les réglages de Yoast SEO, et view_site_health_checks pour la Santé du site : 30 capacités. Sur un site unique, Yoast lui ouvre aussi les réglages de confidentialité.

La page de Yoast sur ses rôles résume la différence. Le SEO Manager a "toutes les capacités SEO", réglages compris. Le SEO Editor accède aux fonctions de la boîte Yoast SEO, mais à "aucun des réglages" du menu de l’extension. En version Premium, il gère aussi les redirections. Cette page date de 2019.

Donner le rôle SEO Editor à un prestataire de référencement revient donc à lui confier un compte Éditeur, ni plus ni moins : sur un site équipé de Yoast SEO, les deux rôles ont les mêmes 28 capacités.

bbPress : cinq rôles de forum, en plus du rôle du site

Les rôles d’un forum bbPress sur WordPress fonctionnent autrement : ils ne remplacent pas le rôle du site, ils s’y ajoutent. Un compte peut ainsi être Abonné sur le site et Modérateur sur le forum.

Le relevé en compte cinq, que le paquet de traduction de bbPress nomme ainsi : "Maître des clés" (30 capacités), "Modérateur" (26), "Participant" (8), "Visiteur" (1) et "Bloqué" (0). D’après la documentation de bbPress, le Maître des clés crée, modifie et supprime les forums, sujets et réponses des autres. Il dispose aussi des outils de modération.

Le Participant crée et modifie ses propres sujets et réponses. Le Visiteur ne peut que lire. Pour le Bloqué, toutes les capacités sont explicitement refusées. Le rôle de forum attribué par défaut est Participant. Cette documentation n’a pas bougé depuis sept ans ; le code de la version 2.6.19 contient bien ces cinq rôles.

bbPress n’ajoute aucune capacité aux rôles natifs de WordPress. Ses rôles sont calculés à la volée, à côté de celui du site.

L’éditeur face aux rôles des extensions

Voici, côte à côte, les rôles WordPress qui ressemblent à l’éditeur, sur un même site équipé des trois extensions.

Rôle	Capacités	HTML non filtré	Liste des comptes	Réglages de Yoast SEO	Santé du site
Éditeur	28	oui	non	non	non
SEO Editor (Yoast SEO)	28	oui	non	non	non
SEO Manager (Yoast SEO)	30	oui	non	oui	oui
Gestionnaire de boutique (WooCommerce)	83	non	oui, modifie les seuls clients	non	non
Administrateur	105	oui	oui	oui	oui

Quel rôle donner à un client, un rédacteur, un prestataire ?

Quand je livre un site WordPress, ma règle pour le compte du client dépend d’une seule chose : qui s’occupe de la maintenance une fois le site en ligne.

Si je m’en charge, le client reçoit le rôle Éditeur. Si je ne m’en charge pas, il reçoit le rôle Administrateur, et je lui fais signer une décharge. À partir de ce moment-là, il est 100 % responsable de son site.

Le relevé montre ce que cela change pour lui. En Éditeur, il garde ses 26 capacités sur tout le contenu, pages comprises. Les 24 capacités qui touchent aux extensions, au thème, aux comptes et aux réglages restent du côté de la maintenance. Il ne voit pas non plus les tests de la Santé du site : WordPress les réserve aux comptes capables d’installer des extensions.

En Administrateur, il a les 50 capacités du cœur. Toutes, y compris celles qui touchent au fonctionnement du site : lancer une mise à jour, supprimer une extension, effacer un compte. La décharge dit simplement qui en répond. Ce qu’un contrat doit prévoir côté maintenance, je l’ai détaillé dans mon article sur le contenu d’un contrat de maintenance WordPress.

Si vous voulez rester Éditeur sur votre site et me confier la maintenance, mon forfait Vigilance coûte 590 € HT par mois.

Passer la main : l’adresse e-mail d’administration

Le rôle du compte ne suffit pas à rendre un site à son propriétaire. Dans "Réglages", puis "Général", un champ compte autant que lui : l'"Adresse e-mail d’administration".

La documentation de cet écran, dont cette section a été réécrite en juillet 2026, est limpide. Si le site a été monté par un développeur ou une agence, vérifiez que cette adresse pointe vers une boîte à laquelle votre organisation a accès, puisque les avis du mode de récupération et des erreurs critiques y arrivent.

Cette adresse n’a rien à voir avec celle du compte du client. Et la changer ne prend pas effet tout de suite. WordPress envoie un e-mail de confirmation à la nouvelle adresse, qui ne devient active qu’après un clic sur le lien.

La même question se pose, en plus grave, le jour où le propriétaire disparaît. J’en parle dans ce que devient un site WordPress après un décès.

Rédacteur, stagiaire, prestataire : des cas types

Les situations qui suivent sont des cas d’école, construits pour l’exemple.

Prenons un rédacteur ponctuel, qui vous propose un article par trimestre. Le rôle Contributeur lui suffit : il écrit, vous relisez, vous publiez. Prévoyez d’ajouter ses images vous-même, et de corriger l’article à sa place une fois en ligne.

Imaginez maintenant une stagiaire chargée des actualités pendant six mois. Rôle Auteur si vous acceptez qu’elle publie sans relecture, Contributeur sinon. Dans les deux cas, elle ne touchera à aucune page. À la fin du stage, changez son rôle, ou supprimez son compte en attribuant ses articles à quelqu’un d’autre.

Autre cas : un prestataire de passage, appelé pour installer et régler une extension. Aucun rôle natif ne donne install_plugins sans donner tout le reste. Il lui faut donc un compte Administrateur. Créez-lui un compte à son nom plutôt que de prêter le vôtre, et supprimez-le en fin de mission. Si vous le gardez en le rétrogradant, pensez à ses mots de passe d’application.

Dernier cas, une agence de référencement qui réclame un compte "SEO Editor". Vous venez de le voir : ce rôle est un éditeur, JavaScript compris. Donnez-le en connaissance de cause.

Comment ajouter un utilisateur et changer son rôle ?

Dans WordPress 7.1 en français, le menu s’appelle "Comptes", même si plusieurs tutoriels écrivent encore "Utilisateurs". Parmi les rôles natifs, seul l’administrateur le voit. Pour ajouter un utilisateur, le chemin est court.

1. Ouvrez "Comptes", puis "Ajouter un compte".
2. Saisissez l’identifiant, en le choisissant bien : personne ne pourra le modifier ensuite, pas même un administrateur.
3. Saisissez l’adresse e-mail, qui doit être unique pour chaque compte.
4. Cochez "Envoyer un e-mail à la personne à propos de son nouveau compte."
5. Choisissez le rôle, puis validez le formulaire.

Depuis WordPress 4.3, cet e-mail ne contient plus le mot de passe : il donne un lien pour le définir. Vous lirez encore que le nouveau venu reçoit son mot de passe par e-mail… ce n’est plus vrai depuis cette version.

Changer un rôle, supprimer un compte

Pour changer le rôle d’un compte existant, ouvrez "Tous les comptes" et cochez une ou plusieurs lignes. Choisissez ensuite le nouveau rôle dans le menu "Changer de rôle pour…". Les listes de rôles de WordPress proposent aussi "Aucun rôle sur ce site", qui laisse exister le compte sans lui donner de rôle.

Le code de cet écran réserve une surprise : WordPress ne prévient pas la personne, ce changement groupé n’envoie aucun e-mail. Et un administrateur ne peut pas se retirer son propre rôle. WordPress lui répond : "Désolé, vous ne pouvez pas supprimer votre propre rôle."

Et quand on supprime un compte, que deviennent ses articles ? WordPress laisse le choix : "Supprimer tout le contenu.", ou attribuer articles et liens à un autre compte. Pour un rédacteur parti, la seconde option garde ses articles en ligne. Seul le compte avec lequel vous êtes connecté échappe à la suppression.

Avec un accès SSH, WP-CLI fait tout cela en ligne de commande, et un peu plus. Lister les administrateurs, afficher les capacités réelles d’un compte ou d’un rôle, changer un rôle sans ouvrir l’administration :

wp user list --role=administrator --format=csv
wp user list-caps <compte>
wp cap list editor
wp user set-role <compte> author

Remplacez <compte> par le compte visé. Sans rôle indiqué, wp user set-role applique le rôle par défaut du site.

Rôle par défaut : ce que WordPress 7.0 a changé

Dans "Réglages", puis "Général", la case "Tout le monde peut s’inscrire" et le menu "Rôle par défaut de tout nouveau compte" décident du sort des inscriptions. Depuis WordPress 7.0, ce menu ne propose plus ni Administrateur ni Éditeur.

La note de version de WordPress 7.0 l’annonce en une phrase. Les rôles Administrateur et Éditeur "ont été retirés" du sélecteur du rôle par défaut de WordPress. La Santé du site alerte désormais si l’un d’eux était choisi avant la mise à jour. Les développeurs disposent d’un filtre, default_role_dropdown_excluded_roles, pour changer la liste exclue.

Le code du réglage ajoute une précision que la note ne donne pas. Un site déjà réglé sur Éditeur ou Administrateur garde son réglage : le rôle reste affiché tant qu’il est sélectionné. WordPress ne le change pas en silence.

Autre précision, côté Santé du site WordPress : l’alerte ne se déclenche que si l’inscription est ouverte. Elle s’affiche alors en statut critique, sous le titre "Inscription ouverte avec un rôle par défaut ayant des privilèges".

Le scénario visé est simple. N’importe quel visiteur crée un compte et reçoit d’office le droit de publier et de modifier tout le contenu. Voire, en Administrateur, celui d’installer des extensions.

Créer un rôle sur mesure : extension ou code ?

En formation, je m’en tiens aux rôles natifs de WordPress. Quand un site a besoin d’un rôle entre deux, il reste une extension de gestion des rôles, ou quelques lignes de code.

Les extensions de gestion des rôles

Les extensions WordPress de gestion des rôles qui suivent sont présentées d’après leur fiche officielle, avec les chiffres relevés le 1er octobre 2026.

Sa fiche annonce la création de rôles, de zéro ou par copie d’un rôle existant. Elle cite aussi le changement du rôle par défaut, des capacités attribuées compte par compte et plusieurs rôles sur un même compte. L’extension retire les capacités laissées par des extensions désinstallées. La gestion depuis l’administration d’un réseau multisite relève de la version Pro.

Members édite, crée et supprime rôles et capacités. Il donne plusieurs rôles à un même compte, clone un rôle, importe et exporte des rôles, restreint l’accès à des contenus. Il sait aussi refuser explicitement une capacité à un rôle.

Sa fiche décrit enfin un secours, pour le jour où une modification de rôles vous ferme la porte de l’administration. Vous demandez par e-mail un lien sécurisé, limité dans le temps, qui vous rend votre rôle d’administrateur. Qu’une extension prévoie ce cas en dit long sur la facilité avec laquelle on peut se l’infliger…

PublishPress Capabilities règle les rôles et chaque capacité "sans écrire de code". Chaque changement de permissions est sauvegardé, pour revenir en arrière en cas d’erreur. L’extension propose aussi de tester le compte d’un utilisateur sans changer son mot de passe. Son ancien nom, Capability Manager Enhanced, survit dans l’adresse de sa fiche.

Le code : add_role() à l’activation d’une extension

Pour un besoin simple et stable, une petite extension maison suffit. L’exemple ci-dessous crée un rôle "Modérateur", capable de lire, d’ouvrir l’écran des commentaires et de modérer ceux des articles publiés.

<?php
/**
 * Plugin Name: Rôle Modérateur
 */

register_activation_hook( __FILE__, 'wpf_ajouter_role_moderateur' );
function wpf_ajouter_role_moderateur() {
	add_role(
		'moderateur',
		'Modérateur',
		array(
			'read'                 => true,
			'edit_posts'           => true, // nécessaire pour ouvrir l'écran Commentaires
			'edit_others_posts'    => true, // modérer exige de pouvoir modifier l'article
			'edit_published_posts' => true,
			'moderate_comments'    => true,
		)
	);
}

register_deactivation_hook( __FILE__, 'wpf_retirer_role_moderateur' );
function wpf_retirer_role_moderateur() {
	remove_role( 'moderateur' );
}

// Vérifier une capacité (jamais un nom de rôle), sur un objet précis :
// if ( current_user_can( 'edit_post', $post_id ) ) { ... }

Pourquoi passer par l’activation ? Parce que add_role() écrit le rôle dans la base de données dès son premier appel, dans l’option user_roles. La documentation développeur prévient que les appels suivants "ne feront rien", y compris pour modifier la liste des capacités. La désactivation retire le rôle avec remove_role().

Attention à edit_posts : indispensable pour atteindre l’écran des commentaires, cette capacité autorise aussi ce modérateur à rédiger des brouillons.

Les deux capacités suivantes ont un prix. Sur cet écran, WordPress ramène la modération d’un commentaire au droit de modifier l’article qui le porte, comme pour l’auteur. Sans edit_others_posts et edit_published_posts, ce modérateur ne toucherait qu’aux commentaires de ses propres articles. Avec elles, il peut aussi modifier les articles publiés des autres.

J’ai fait essayer ce code sur un WordPress 7.1.2 local. Les deux points ci-dessus s’y vérifient, et un troisième s’y ajoute : une fois l’extension désactivée, un compte qui portait ce rôle n’en a plus aucun, pas même la capacité read. Changez donc le rôle de ces comptes avant de la désactiver.

Dans votre propre code, vérifiez toujours une capacité sur l’objet concerné, comme dans le dernier commentaire de l’exemple.

Une capacité de trop, et le rôle change de nature

Un rôle sur mesure se juge à sa capacité la plus forte. Ajoutez edit_plugins à un rôle, et ses comptes peuvent modifier le code PHP des extensions depuis l’administration. La documentation de durcissement rappelle que l’éditeur de fichiers est "souvent le premier outil" d’un attaquant connecté : il ouvre l’exécution de code. Ajoutez unfiltered_html, et ils publient du JavaScript.

Avant de confier un rôle modifié, je vous invite à le tester avec les yeux de la personne qui le recevra. Se connecter en tant qu’un autre utilisateur prend un clic avec User Switching. D’après sa fiche, aucun mot de passe n’est révélé. Seuls les comptes capables de modifier les autres comptes peuvent basculer, par défaut les administrateurs.

Si les rôles natifs de WordPress ont trop été retouchés, wp role reset les remet dans l’état d’une installation neuve : les capacités ajoutées disparaissent, celles retirées reviennent, et les rôles sur mesure ne sont pas touchés. Attention toutefois : les capacités ajoutées par vos extensions disparaissent avec les autres.

Rôles et sécurité : le moindre privilège

Le manuel des développeurs de WordPress pose le principe en une phrase.

WordPress applique le principe du moindre privilège, qui consiste à ne donner à un utilisateur que les privilèges indispensables au travail qu’il doit faire.

Manuel des extensions de WordPress, chapitre Utilisateurs

Appliqué à vos comptes, ce principe se traduit en gestes très concrets, à refaire de temps en temps.

Combien d’administrateurs sur votre site ?

Comptez-les : wp user list --role=administrator donne la liste en une commande. Un administrateur que personne ne reconnaît fait partie des signes d’un site WordPress piraté.

La FAQ officielle sur le piratage cite en effet la création de nouveaux comptes parmi les comportements à repérer. Pour la remise en état, elle conseille de commencer par réinitialiser les mots de passe de tous les comptes, "surtout" ceux des administrateurs.

Ensuite, faites le tri. Un prestataire parti, un ancien salarié, un compte de test oublié… Chaque administrateur qui ne sert plus garde toutes ses capacités. Supprimez-le en attribuant ses contenus à un compte actif, ou rétrogradez-le au rôle dont il a réellement besoin.

Sur les comptes Administrateur et Éditeur, activez une authentification à deux facteurs. WordPress ne la propose pas de base : sa documentation sur le sujet renvoie à des extensions. Elle prévient au passage que le SMS "n’est pas un canal de communication sûr".

Deux constantes à poser dans wp-config.php

Posées dans le fichier wp-config.php de votre installation, ces lignes retirent des capacités à tout le monde, administrateurs compris.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_UNFILTERED_HTML', true );

La première supprime l’éditeur de fichiers de l’administration. D’après la documentation, elle équivaut à retirer edit_themes, edit_plugins et edit_files à tous les comptes. Sa cousine DISALLOW_FILE_MODS bloque en plus l’installation et les mises à jour depuis l’administration. Elle est à réserver aux sites dont les mises à jour passent par un autre chemin.

La seconde retire le HTML non filtré à tous, super admins compris. Revers à connaître : la même règle retire aussi le CSS additionnel. Plus personne ne pourra publier de JavaScript dans un contenu, vous non plus.

Mots de passe d’application : tous les droits du compte

Les mots de passe d’application existent depuis WordPress 5.6, sorti en décembre 2020. Ils servent aux programmes qui parlent à votre site par l’API REST de WordPress. Jamais à se connecter à l’administration : la documentation précise qu’ils ne fonctionnent pas sur la page de connexion.

Vous les créez sur l’écran de profil d’un compte, dans la section "Mots de passe d’application". Par défaut, ils ne fonctionnent que sur un site servi en HTTPS.

Le point qui compte : un mot de passe d’application est lié à un compte, et l’API REST vérifie les mêmes capacités que l’administration. En 2020, le guide d’intégration annonçait pour de "futures versions" un moyen de restreindre le rôle sous lequel une application agit. Le code de WordPress 7.1 n’en contient aucune trace.

Pour chaque mot de passe, WordPress garde la date de dernière utilisation et la dernière adresse IP. En ligne de commande, la documentation donne cet exemple pour le compte numéro 123 :

wp user application-password list 123 --fields=uuid,name,created,last_used,last_ip
wp user application-password delete 123 <uuid>

Agents IA : le rôle du compte reste la vraie barrière

Et un agent IA, il a quel rôle ? Aucun à lui. Branché sur WordPress, il agit avec le compte dont il utilise le mot de passe d’application. Et avec toutes les capacités de ce compte.

WordPress 6.9 a introduit l’API Abilities, qui décrit des actions que des programmes peuvent appeler. Chaque ability exige une fonction de contrôle des permissions, en pratique un appel à current_user_can(). Par défaut, elles restent privées. Un drapeau public les expose à des clients comme l’API REST, MCP ou les agents IA.

WordPress 7.1 n’en embarque que trois. Deux exigent manage_options. La dernière, core/get-user-info, qui renvoie notamment les rôles du compte courant, ne demande qu’une connexion. L’adaptateur MCP officiel suit la même logique : par défaut, son serveur exige seulement un compte connecté. Les contrôles fins reposent sur les capacités.

Si vous connectez un assistant IA à votre site par MCP, donnez-lui un compte dédié, à son nom, avec le rôle le plus bas qui suffit à sa tâche, et un mot de passe d’application à lui seul. Un agent qui rédige des brouillons, par exemple, n’a besoin que d’un compte Contributeur.

Humain ou programme, chaque compte arrive sur votre site avec sa liste de capacités, et WordPress la consulte avant de le laisser agir. Choisir un rôle revient à choisir qui pourra casser quoi.

Questions fréquentes

Comment gérer les rôles et les permissions des utilisateurs dans WordPress ?

Depuis un compte Administrateur, ouvrez "Comptes", puis "Tous les comptes". Cochez les comptes visés et choisissez un rôle dans le menu "Changer de rôle pour…". Pour modifier les permissions d’un rôle existant, il faut une extension de gestion des rôles, la méthode add_cap() de l’objet renvoyé par get_role() ou la commande wp cap add : add_role() ne fait que créer un rôle.

Qu’est-ce que le rôle SEO Editor de WordPress ?

Un rôle ajouté par Yoast SEO. Son code le crée sur le modèle du rôle Éditeur, dont il recopie toutes les capacités, puis lui donne les deux mêmes capacités de Yoast que l’éditeur. Un SEO Editor a donc exactement les droits d’un éditeur : modifier les contenus des autres, publier du JavaScript.

Quelle différence entre un éditeur et un auteur sur WordPress ?

L’éditeur a 26 capacités, l’auteur 7. L’éditeur gère tout le contenu, celui des autres compris, ainsi que les catégories et les commentaires. L’auteur ne publie et ne modifie que ses propres articles, et ne crée aucune page.

Un éditeur peut-il ajouter un compte sur WordPress ?

Non. Le menu "Comptes" n’apparaît qu’avec la capacité list_users, que seul l’administrateur possède parmi les rôles natifs. L’éditeur ne voit que son "Profil".

Quel rôle par défaut choisir pour les nouveaux comptes ?

Abonné, qui n’a que la lecture. Depuis WordPress 7.0, le menu du rôle par défaut ne propose plus Administrateur ni Éditeur. La Santé du site signale en critique une inscription ouverte avec l’un de ces rôles.

Combien y a-t-il de rôles dans WordPress ?

Cinq : Administrateur, Éditeur, Auteur, Contributeur et Abonné. Super Admin n’existe qu’en multisite, et n’est pas un rôle stocké. WooCommerce, Yoast SEO ou bbPress en ajoutent d’autres.

Sources

Toutes relues le 1er octobre 2026 ; citations anglaises traduites en français pour cet article. Le code de WordPress cité est celui de la branche 7.1.

• Relevé : WordPress 7.1.2 en français dans WordPress Playground, capacités lues avec wp_roles(), cœur seul puis avec trois extensions actives
• Code de WordPress : création des rôles, capacités, menus, écran des comptes, rôle par défaut
• Code de WordPress, suite : Santé du site, mots de passe d’application, API Abilities, abilities natives
• Documentation WordPress : rôles et capacités, réglages généraux, écran des comptes, écran de profil
• Sécurité : durcissement, mots de passe d’application, double authentification, API REST
• Développeurs : utilisateurs, rôles et capacités, WP-CLI (wp user list, wp user set-role)
• Notes de version : WordPress 7.0, mots de passe d’application, API Abilities
• WooCommerce 11.1.2 : rôles, gestionnaire de boutique, documentation
• Yoast SEO 28.6 : rôles, capacités, page sur les rôles
• bbPress 2.6.19 : capacités, documentation ; adaptateur MCP ; fiches des extensions via l’API de WordPress.org