# Utilisateur connecté

> Compte actuellement authentifié sur le site, dont WordPress conserve les informations et les permissions accessibles tout au long de la requête en cours.

- Auteur : Clément Hadrot
- Publié le : 2026-09-25
- Mis à jour le : 2026-09-25
- URL : https://wpmoderne.dev.wordpress-developpement.fr/lexique/utilisateur-connecte/

Afficher un menu différent selon qu'on est visiteur anonyme ou membre connecté, réserver un contenu aux abonnés, personnaliser un message d'accueil avec un prénom : la quasi-totalité des logiques de personnalisation d'un site part de cette même question, posée à chaque chargement de page.

## Un objet global reconstruit à chaque requête

WordPress détermine l'identité de la personne connectée en lisant les cookies d'authentification, puis expose le résultat via l'objet retourné par `wp_get_current_user()`, une instance de `WP_User`. La fonction booléenne `is_user_logged_in()` permet une vérification rapide sans manipuler cet objet, et `current_user_can( 'capacite' )` reste la manière recommandée de contrôler des permissions plutôt que de comparer des rôles directement.

## Exemple

```
<?php
if ( is_user_logged_in() ) {
    $utilisateur = wp_get_current_user();
    echo 'Bonjour ' . esc_html( $utilisateur->display_name );
} else {
    echo 'Connectez-vous pour accéder à ce contenu.';
}
```

## Bon à savoir

- Cet objet n'est fiable qu'à partir du hook `init` : l'appeler trop tôt dans le cycle de chargement, par exemple directement dans `functions.php` hors de tout hook, renvoie un utilisateur non identifié.
- Dans le contexte de l'API REST, la notion d'utilisateur courant reste identique côté PHP, mais l'authentification passe généralement par les cookies du navigateur associés à un nonce, ou par une application password pour un accès externe.
- Toujours préférer une vérification par capacité (`edit_posts`, `manage_options`…) à une vérification par nom de rôle, car les capacités restent cohérentes même si les rôles sont personnalisés.