# « Vous n’avez pas l’autorisation d’accéder à cette page »

> « Désolé, vous n’avez pas l’autorisation d’accéder à cette page » dans wp-admin : rôle, préfixe de tables, extension ou multisite. Diagnostic et correctifs.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/acces-refuse-page/

> Votre compte n’a pas la capacité requise par cette page d’administration. Connectez-vous avec un administrateur, ou, si c’était déjà le cas, vérifiez que les rôles n’ont pas été perdus (préfixe de tables modifié, migration).

Vous cliquez sur un menu de l’administration, ou vous ouvrez le lien d’un collègue, et WordPress répond par une page quasi vide : « Désolé, vous n’avez pas l’autorisation d’accéder à cette page. » Vous êtes pourtant connecté. L’erreur n’apparaît que dans l’administration (ou dans l’administration réseau d’un multisite), jamais sur le site public, et elle s’accompagne d’un code HTTP 403.

**Bon à savoir :** sur WordPress 7.1, cette chaîne n’est pas encore traduite dans le paquet de langue français (version du 20 août 2026). Sur un site en français, l’écran peut donc afficher la version anglaise, *« Sorry, you are not allowed to access this page. »*, au lieu de la formulation française historique. Les causes et les solutions sont exactement les mêmes.

Le plus souvent, c’est normal : le rôle du compte n’est pas assez élevé pour cette page. Mais si vous êtes administrateur et que tout se bloque après une migration, un changement de préfixe de tables ou l’installation d’une extension de sécurité, c’est un vrai problème de droits à corriger.

## Ce que signifie cette erreur

Au chargement de chaque écran de l’administration, `wp-admin/includes/menu.php` construit le menu en retirant les entrées pour lesquelles l’utilisateur n’a pas la capacité requise, puis appelle `user_can_access_admin_page()` (définie dans `wp-admin/includes/plugin.php`). Cette fonction refuse l’accès dans deux cas principaux :

- la page demandée a été retirée du menu parce que la capacité exigée manque à l’utilisateur ;
- une page d’extension est appelée avec un paramètre `?page=` qui n’est pas enregistré (extension désactivée, slug erroné, lien périmé).

Dans ces cas, WordPress déclenche l’action `admin_page_access_denied`, puis appelle `wp_die()` avec le message de l’erreur et le code 403 (`wp-admin/includes/menu.php`, ligne 384). Le même message est utilisé directement, avec le même code 403, par les écrans de `wp-admin/network/` (réservés aux super-administrateurs) et, sans code explicite, par `my-sites.php`. Les capacités d’un utilisateur viennent de son rôle, stocké dans l’option `{préfixe}user_roles`, et de la métadonnée `{préfixe}capabilities` de la table des métadonnées utilisateur. Si le préfixe de vos tables ne correspond plus à ces clés, WordPress ne trouve plus aucun rôle et refuse tout.

## Diagnostic rapide

| Symptôme / constat | Cause probable | À vérifier |
| --- | --- | --- |
| Seule une page précise est refusée (Réglages, Extensions…), le reste fonctionne | Rôle insuffisant (éditeur, auteur, contributeur) | Rôle du compte dans Utilisateurs, ou `wp user get` |
| Toute l’administration est refusée, même pour l’administrateur historique | Rôles perdus : préfixe de tables modifié, base partiellement restaurée | Clés `user_roles` et `capabilities` en base |
| Le refus ne touche qu’un lien venant d’une extension ou d’un e-mail | Extension désactivée ou page supprimée, `?page=` inconnu | Extensions actives, adresse exacte du lien |
| Le refus concerne `/wp-admin/network/` | Compte administrateur de site, pas super-administrateur | Liste des super-administrateurs du réseau |
| Le problème apparaît après l’installation d’une extension de sécurité ou de rôles | Capacités retirées ou renommées par l’extension | Désactivation temporaire de l’extension |

## Les causes les plus fréquentes

1. Un compte au rôle trop faible : un éditeur ne peut pas ouvrir les Réglages, un auteur ne gère pas les extensions.
2. Un changement de préfixe de tables (`$table_prefix` dans `wp-config.php`) ou une migration qui n’a pas renommé `wp_user_roles`, `wp_capabilities` et `wp_user_level` avec le nouveau préfixe.
3. Une extension de sécurité, de rôles ou de simplification de l’administration qui masque des écrans ou retire des capacités.
4. Un lien vers une page d’extension qui n’existe plus (extension désactivée, supprimée ou renommée).
5. Un accès à l’administration réseau d’un multisite avec un compte qui n’est pas super-administrateur.
6. Une session ouverte avec le mauvais compte (compte secondaire, compte de test).

## Solutions pas à pas

### 1. Vérifier le compte et le rôle

Déconnectez-vous, reconnectez-vous avec un compte administrateur et ouvrez de nouveau la page. Si cela fonctionne, le rôle du premier compte était trop faible : demandez à un administrateur de l’ajuster dans **Utilisateurs**, en préférant un rôle adapté à la tâche plutôt qu’un passage systématique en administrateur (voir l’article sur les [rôles dédiés plutôt qu’un compte administrateur partagé](https://www.wpmoderne.fr/securite/role-dedie-plutot-que-compte-administrateur-partage/)). Si la page de connexion elle-même vous renvoie en boucle, voyez plutôt la fiche [cookies bloqués à la connexion](https://www.wpmoderne.fr/erreurs-wordpress/cookies-bloques/). Avec WP-CLI, vous pouvez lister les droits réels :

```
wp user list --fields=ID,user_login,roles
wp user list-caps 1
```

Remplacez 1 par l’identifiant du compte. Une liste vide signifie que WordPress ne retrouve aucun rôle pour ce compte : passez à la solution 2.

### 2. Réparer des rôles perdus après un changement de préfixe

À appliquer lorsque même l’administrateur est refusé. **Sauvegardez la base avant toute modification** (voir notre article sur les [sauvegardes et plans de reprise](https://www.wpmoderne.fr/securite/sauvegardes-plan-de-reprise-wordpress/)). Repérez d’abord le préfixe défini dans `wp-config.php` (`$table_prefix`), puis les clés présentes en base :

```
SELECT option_name FROM nouveau_options WHERE option_name LIKE '%user\_roles';
SELECT user_id, meta_key FROM nouveau_usermeta
 WHERE meta_key LIKE '%capabilities' OR meta_key LIKE '%user\_level';
```

Si les clés portent encore l’ancien préfixe (par exemple `wp_`) alors que les tables s’appellent `nouveau_`, renommez-les :

```
UPDATE nouveau_options SET option_name = 'nouveau_user_roles'
 WHERE option_name = 'wp_user_roles';
UPDATE nouveau_usermeta SET meta_key = 'nouveau_capabilities'
 WHERE meta_key = 'wp_capabilities';
UPDATE nouveau_usermeta SET meta_key = 'nouveau_user_level'
 WHERE meta_key = 'wp_user_level';
```

Reconnectez-vous ensuite. D’autres métadonnées d’utilisateur préfixées (réglages d’interface) peuvent aussi devoir être renommées, mais ce sont les trois ci-dessus qui conditionnent les droits.

### 3. Redonner le rôle d’administrateur sans accès à l’administration

Avec WP-CLI et un identifiant connu :

```
wp user set-role 1 administrator
```

Sans WP-CLI ni accès à la base, ajoutez temporairement un fichier dans `wp-content/mu-plugins/` (créez le dossier s’il n’existe pas), en remplaçant `votre_identifiant` :

```
<?php
// Fichier temporaire : à supprimer dès la reconnexion réussie.
add_action( 'init', function () {
    $user = get_user_by( 'login', 'votre_identifiant' );
    if ( $user && ! user_can( $user, 'manage_options' ) ) {
        $user->set_role( 'administrator' );
    }
} );
```

Chargez une page du site, reconnectez-vous, puis **supprimez immédiatement ce fichier** : il donne les pleins pouvoirs à ce compte à chaque chargement.

### 4. Désactiver l’extension qui retire les droits

Si l’erreur est apparue après l’installation ou la mise à jour d’une extension, renommez son dossier dans `wp-content/plugins` par SFTP, ou utilisez `wp plugin deactivate nom-de-l-extension`. Si l’accès revient, ouvrez les réglages de l’extension pour retrouver la règle qui masque la page, ou contactez son éditeur. Notre article sur la [restriction de l’éditeur de site par rôle](https://www.wpmoderne.fr/fse/restreindre-editeur-site-par-role/) montre comment des capacités volontairement retirées produisent ce message.

### 5. Corriger le lien ou l’accès réseau

Pour une page d’extension, ouvrez-la depuis le menu plutôt que par un ancien favori : le paramètre `?page=` doit correspondre à une page enregistrée par une extension active. Sur un multisite, seule la liste des super-administrateurs donne accès à `wp-admin/network/` : consultez-la avec `wp super-admin list` et ajoutez le compte au besoin avec `wp super-admin add identifiant`.

Si le refus vient en réalité du serveur (page « 403 Forbidden » sans habillage WordPress), il ne s’agit pas de cette erreur : reportez-vous à la fiche [erreur 403 Forbidden](https://www.wpmoderne.fr/erreurs-wordpress/erreur-403/).

## Prévenir l’erreur

- Attribuez à chaque personne le rôle strictement nécessaire, et créez un rôle dédié plutôt que de partager un compte administrateur.
- Avant un changement de préfixe ou une migration, sauvegardez la base et renommez aussi `user_roles`, `capabilities` et `user_level`.
- Conservez toujours au moins deux comptes administrateurs de confiance, comme le recommande notre article sur la [suppression accidentelle du dernier compte administrateur](https://www.wpmoderne.fr/securite/empecher-suppression-accidentelle-dernier-compte-administrateur/).
- Testez les extensions de sécurité ou de rôles sur une préproduction avant de les activer en production.
- Partagez des liens vers des pages stables, et pas vers des écrans d’extension susceptibles d’être désactivés.

## FAQ