Terrain 10 — Utilisateurs & rôles (gestion)

Le nom public (display name) peut différer de l’identifiant (login). Bonne pratique sécurité : ne pas exposer l’identifiant de connexion comme nom d’auteur public (terrain 16).

L’admin peut régénérer un mot de passe fort, ou envoyer un lien de réinitialisation. Ne jamais réutiliser un mot de passe partagé : un compte = un mot de passe fort. Encourage les gestionnaires de mots de passe.

Le profil porte bio, site, e-mail, et parfois des champs sociaux (selon thème/extension). Ces données peuvent alimenter l’encart auteur public (terrain 02, jeu 20). Séparation nette donnée ↔ affichage.

Abonné (profil/commente) · Contributeur (rédige, soumet) · Auteur (publie ses posts) · Éditeur (gère tout le contenu) · Administrateur (gère le site). En multisite s’ajoute le Super Admin (réseau). C’est une échelle de privilèges croissants.

Ces extensions exposent la matrice rôle × capability en UI. WordPress stocke les rôles/caps en base (option wp_user_roles) ; nativement, pas d’UI pour les éditer. Indispensable pour des rôles métier.

Via Members : duplique un rôle proche, ajuste les capabilities (ex. gérer les produits mais pas les réglages). En code : add_role('shop_manager_lite', 'Gestionnaire produits', array('read'=>true, ...)). Principe du moindre privilège.

Une capability est un droit atomique (edit_pages, manage_options, upload_files…). Un rôle = un paquet de caps. Ajuster une cap change tous les utilisateurs de ce rôle. Réfléchis avant : l’effet est global.

Le changement de rôle groupé accélère l’administration d’une plateforme à nombreux comptes. Les capabilities suivent immédiatement. Pratique lors d’une réorganisation d’équipe.

Un Application Password authentifie une machine (script, front Next.js) via l’API REST sans livrer ton vrai mot de passe. Base de l’auth headless (terrain 17, Partie 9). Chaque appli a sa clé, révocable indépendamment.

« Révoquer » invalide immédiatement la clé (l’appli perd l’accès) sans toucher ton mot de passe ni les autres clés. Bonne hygiène : une clé par usage, révoquée dès qu’un service est retiré. Réflexe de sécurité d’API.

Utile si un appareil est perdu/compromis : invalide toutes les sessions actives sauf la courante. Sécurité de compte native, souvent ignorée.

À la suppression, WordPress propose de réattribuer le contenu à un autre compte (à préférer) ou de le supprimer. En prod : toujours réattribuer (voir terrain 02, jeu 24).

Pas d’import CSV natif d’utilisateurs → extension. Colonnes typiques : user_login, user_email, role, first_name…. Vérifie l’encodage et les doublons. (Moodle, lui, l’a en natif — comparaison utile.)

Le 2FA (TOTP via appli, ou clé) protège même si le mot de passe fuite — surtout pour les comptes admin. Non natif → extension (Two-Factor, Wordfence Login Security). Fortement recommandé en prod.

Moindre privilège : donne le rôle le plus bas suffisant. Un rédacteur = Auteur, pas Admin. Moins d’admins = moins de cibles. Un compte compromis fait d’autant moins de dégâts que son rôle est bas.

Un compte par personne (jamais partagé) permet de tracer qui a fait quoi et de révoquer un accès sans gêner les autres. Évite aussi le login « admin » générique, cible des attaques.

Un utilisateur ne peut pas modifier son propre rôle ni s’accorder des caps qu’il n’a pas : garde-fou natif contre l’escalade de privilèges. Leçon pour tes plugins : vérifie les capabilities côté serveur (terrain 16).

Nativement limité → on ajoute des champs via les hooks show_user_profile/edit_user_profile (+ personal_options_update pour sauver). C’est du code (terrain 12/15). Ou une extension (ACF, profils étendus). Le profil est extensible.

La vue matricielle révèle des surprises (une cap accordée par une extension à un rôle inattendu). Auditer périodiquement = hygiène de sécurité, surtout après l’ajout d’extensions qui créent leurs propres rôles/caps.

Tu sais administrer les comptes et tu tiens la clé du headless (Application Passwords). Fin du parcours découverte/admin (terrains 01–10). Cap sur le code : environnement de dev (terrain 11).