Chapitre 2.2 — Utilisateurs, rôles & capabilities

⏱️ TL;DR — WordPress gère les permissions par un modèle à deux niveaux : les rôles (Administrateur, Éditeur, Auteur, Contributeur, Abonné) sont des paquets de capabilities, et les capabilities sont les droits atomiques (edit_posts, publish_posts, manage_options…). En code, on ne teste jamais un rôle, on teste une capability : current_user_can('edit_posts'). Comprendre ce modèle maintenant vous évitera les pires failles de sécurité de vos plugins (Partie 7) — c’est le fondement de l’autorisation dans WordPress.

🎯 Objectifs

• Connaître les rôles natifs et ce que chacun peut faire.
• Comprendre le modèle rôle = ensemble de capabilities.
• Savoir pourquoi on teste une capability, pas un rôle.
• Appliquer le principe de moindre privilège à la gestion des comptes.

1. Les rôles natifs

WordPress fournit cinq rôles par défaut (du plus puissant au plus limité) :

⚠️ Piège — Ne donnez pas le rôle Administrateur par facilité. Un admin peut installer des plugins, éditer du code (thème/plugin depuis l’admin), gérer les autres comptes — donc compromettre tout le site. Un rédacteur n’a besoin que d’Auteur ou Éditeur. C’est le moindre privilège (§4).

2. Le vrai modèle : les capabilities

Un rôle n’est qu’une étiquette attachée à une liste de capabilities. Une capability est un droit atomique et nommé :

Un Éditeur, c’est simplement : read + edit_posts + edit_others_posts + publish_posts + delete_others_posts + moderate_comments + … (mais pas manage_options). Un Auteur a publish_posts mais pas edit_others_posts.

💡 Pour un dev React — Oubliez « admin/user » binaire. Pensez permissions granulaires (comme des scopes OAuth ou un RBAC fin) : chaque action sensible exige une capability précise. Un rôle = un preset de scopes. Et surtout : côté serveur, l’autorisation se vérifie toujours par la capability, jamais par « est-ce que c’est un admin ? ».

3. La règle d’or : tester une capability, pas un rôle

En développement (Partie 7), la vérification d’autorisation se fait avec current_user_can() :

// ✅ BON : on teste le DROIT
if ( current_user_can( 'edit_posts' ) ) {
    // afficher le bouton / exécuter l'action
}
 
// ❌ MAUVAIS : on teste le RÔLE
if ( in_array( 'editor', wp_get_current_user()->roles, true ) ) {
    // fragile, contournable, faux
}

Pourquoi ? Parce que :

• les rôles sont personnalisables : un site peut renommer, créer, ou modifier des rôles ; « editor » n’a pas partout les mêmes droits ;
• des plugins (adhésion, e-commerce) ajoutent leurs propres rôles et capabilities ;
• tester la capability exprime l’intention réelle (« cette personne a-t-elle le droit de faire ça ? ») et reste correct quels que soient les rôles en place.

Retenez cette phrase, elle reviendra : on autorise par capability. Oublier un current_user_can() (ou un nonce) sur une action est la faille classique des plugins (Partie 7 & 11).

4. Le principe de moindre privilège

Donnez à chaque compte le rôle le plus faible qui lui permet de faire son travail :

• Un rédacteur externe qui ne doit pas publier sans relecture → Contributeur.
• Un rédacteur autonome → Auteur.
• Un responsable éditorial → Éditeur.
• Administrateur : réservé à vous / au responsable technique, comptes rares et nommément identifiés.

Bénéfices : moins de risques d’erreur, surface d’attaque réduite (un compte peu privilégié compromis fait moins de dégâts), conformité.

📚 Aller plus loin — Sur un multisite (Partie 11), un niveau supplémentaire existe : le Super Admin, qui gère l’ensemble du réseau (tous les sites, plugins réseau, etc.). Les rôles ci-dessus s’appliquent alors par site. On peut aussi créer des rôles sur mesure en code (add_role()) ou avec un plugin de gestion des rôles.

5. Gérer les utilisateurs (côté admin)

• Utilisateurs → Tous les utilisateurs : liste, filtres par rôle.
• Ajouter : e-mail, identifiant, rôle. WordPress peut envoyer un lien de définition de mot de passe.
• Modifier son profil : chaque utilisateur gère ses infos ; l’admin peut changer le rôle des autres.
• Sécurité des comptes : mots de passe forts (WordPress en génère), et pour les comptes sensibles, activer une double authentification (via plugin) — voir Partie 11.

✏️ Exercices

1. Un client veut que trois stagiaires rédigent des articles soumis à validation avant publication. Quel rôle leur donnez-vous ?
2. Pourquoi current_user_can('publish_posts') est-il préférable à if ($role === 'author') ?
3. Reliez chaque capability à ce qu’elle autorise : manage_options, edit_others_posts, upload_files.

🧠 Quiz de révision

Chapitre suivant : Contenus : articles, pages, médias.