wp role list affiche par défaut cinq rôles sur une installation WordPress standard, et aucun d’eux ne convient vraiment à un auditeur externe chargé de vérifier la conformité RGAA d’un site avant sa mise en production. Administrateur donne bien trop de pouvoir pour la durée d’une mission ponctuelle. Éditeur ou Auteur ne permettent pas d’accéder aux réglages nécessaires pour inspecter la structure des gabarits. La solution la plus propre consiste à créer un rôle sur mesure, avec exactement les capacités requises.
Ce tutoriel construit ce rôle pas à pas, dans un fichier du thème enfant ou d’une extension maison, en s’appuyant uniquement sur l’API des rôles et capacités du cœur de WordPress.
Étape 1 : lister les besoins réels de l’auditeur
Avant d’écrire la moindre ligne de code, il faut cadrer précisément ce que la mission exige. Dans le cas présent, l’auditeur doit pouvoir consulter le contenu publié et les brouillons en cours, inspecter la structure de l’éditeur de blocs pour vérifier la hiérarchie des titres, et parcourir la configuration des menus pour contrôler l’ordre de navigation. Il n’a en revanche aucun besoin de modifier les utilisateurs, les extensions ou les réglages généraux du site.
Étape 2 : créer le rôle avec add_role()
La fonction add_role() du cœur de WordPress crée un rôle avec un identifiant, un nom affiché et un tableau de capacités. Elle s’utilise généralement à l’activation d’une extension, pour garantir que le rôle est créé une seule fois.
function creer_role_auditeur_accessibilite() {
add_role(
'auditeur_accessibilite',
'Auditeur accessibilité',
array(
'read' => true,
'edit_posts' => false,
'upload_files' => false,
)
);
}
register_activation_hook( __FILE__, 'creer_role_auditeur_accessibilite' );
Le rôle démarre volontairement avec des droits minimaux. La lecture, read, suffit à accéder au tableau de bord et à consulter les contenus déjà publiés.
Étape 3 : ajouter une capacité personnalisée avec add_cap()
Pour autoriser la consultation des brouillons et de la structure des blocs sans donner de droit d’édition, une capacité personnalisée, propre à ce projet, est ajoutée au rôle via la méthode add_cap() exposée par l’objet retourné par get_role().
function ajouter_capacite_audit_structure() {
$role = get_role( 'auditeur_accessibilite' );
if ( $role ) {
$role->add_cap( 'consulter_structure_blocs' );
}
}
add_action( 'init', 'ajouter_capacite_audit_structure' );
Cette capacité n’existe nulle part ailleurs dans le cœur de WordPress : elle sert uniquement de condition dans le code du thème ou de l’extension, par exemple pour afficher un panneau d’inspection réservé à ce rôle.
Étape 4 : conditionner un accès sur cette capacité
La fonction current_user_can() vérifie ensuite cette capacité exactement comme n’importe quelle capacité native, sans distinction de traitement.
if ( current_user_can( 'consulter_structure_blocs' ) ) {
echo '<p>Panneau d\'inspection de la structure des titres, réservé à l\'audit.</p>';
}
Étape 5 : créer le compte de l’auditeur via WP-CLI
Plutôt que de passer par l’écran d’administration, WP-CLI permet de créer le compte et de lui attribuer directement le rôle en une seule commande, pratique pour tracer l’opération dans un historique de déploiement.
wp user create audit-rgaa audit@cabinet-exemple.fr \
--role=auditeur_accessibilite \
--user_pass='un-mot-de-passe-genere-aleatoirement'
La commande wp user list --role=auditeur_accessibilite permet ensuite de vérifier que le compte a bien été créé avec le rôle attendu, sans avoir à se connecter à l’interface graphique.
Étape 6 : retirer l’accès une fois la mission terminée
Une fois le rapport d’audit livré, deux commandes suffisent à révoquer proprement l’accès, sans laisser de compte orphelin actif sur le site.
wp user delete audit-rgaa --reassign=1
wp role delete auditeur_accessibilite
Supprimer également le rôle, et pas seulement le compte utilisateur, évite qu’un rôle vide traîne indéfiniment dans la base de données, une négligence fréquente qui complique les audits de sécurité ultérieurs.
Ce que cette méthode évite
- Créer un compte administrateur temporaire, avec le risque d’oubli de sa désactivation
- Partager un identifiant existant, ce qui casse toute traçabilité des actions effectuées
- Donner accès à des réglages sensibles (utilisateurs, extensions, base de données) sans besoin réel
Un principe à garder en tête au-delà de ce cas précis : chaque rôle créé pour un besoin ponctuel devrait être accompagné, dès sa création, du code qui le supprime proprement. Un rôle sans procédure de retrait devient, tôt ou tard, une dette de sécurité oubliée.
En résumé
Une capacité personnalisée, ajoutée à un rôle créé pour l’occasion, donne à un auditeur externe exactement l’accès dont il a besoin, ni plus ni moins, avec une traçabilité complète et une révocation propre en fin de mission. Cette approche ne demande aucune extension tierce : l’API des rôles et capacités du cœur de WordPress suffit entièrement à la mettre en œuvre.
