Désolé, vous n’avez pas l’autorisation d’accéder à cette page : la solution 🔧

Que signifie « Désolé, vous n’avez pas l’autorisation d’accéder à cette page » ?

Ce message veut dire que WordPress a vérifié vos droits et a conclu que vous ne pouviez pas ouvrir la page demandée : vous êtes bien connecté, mais votre compte ne possède pas la « capacité » (un droit précis, comme manage_options pour les réglages ou activate_plugins pour les extensions) exigée par cette page.

Le message s’affiche sur une page blanche, sans menu, avec le texte exact « Désolé, vous n’avez pas l’autorisation d’accéder à cette page. » (en anglais : Sorry, you are not allowed to access this page.). Il est produit par WordPress lui-même (fichier wp-admin/includes/menu.php) avec un code HTTP 403, à ne pas confondre avec la page « Forbidden » du serveur, traitée dans notre fiche erreur 403 Forbidden.

Si vous n’arrivez même pas à vous connecter, notre guide impossible de se connecter à l’administration WordPress est plus adapté. Si le blocage vous empêche de travailler, notre service de résolution des erreurs WordPress peut prendre la main à distance.

Pourquoi WordPress vous refuse l’accès alors que vous êtes administrateur ?

WordPress refuse presque toujours l’accès parce que la page n’existe plus ou parce que les rôles stockés en base ne sont plus lus correctement. Les causes, de la plus fréquente à la plus rare :

• Un favori ou un lien vers la page d’une extension désactivée. L’adresse ressemble à /wp-admin/admin.php?page=nom-extension. L’extension a été désactivée, supprimée ou a renommé sa page de réglages.
• Un préfixe de tables modifié après une migration ou un changement d’hébergeur. Le préfixe est le début du nom des tables (wp_ par défaut). WordPress range la liste des rôles dans l’option {préfixe}user_roles et le rôle de chaque utilisateur dans la métadonnée {préfixe}capabilities. Si le préfixe change dans wp-config.php sans que ces clés suivent, plus personne n’a de droits : le tableau de bord est presque vide et toutes les pages renvoient le message.
• Un rôle modifié ou retiré. Votre compte est passé en « Éditeur » ou « Abonné », ou une extension de gestion des rôles (User Role Editor, Members, etc.) a retiré une capacité au rôle Administrateur.
• Une extension de sécurité qui restreint l’administration. Certaines bloquent des pages par rôle ou par adresse IP. Le refus apparaît souvent juste après sa configuration.
• Un site multisite. Les pages du réseau (/wp-admin/network/) sont réservées aux super administrateurs. Un administrateur d’un sous-site reçoit le message.
• Un piratage. Plus rare, mais à ne pas écarter : un attaquant a pu retirer vos droits et créer son propre administrateur.

Comment réparer l’erreur pas à pas ?

On part de l’adresse refusée, puis on vérifie le rôle, les extensions et la base de données. Avant toute manipulation de fichiers ou de base, faites une sauvegarde complète : les fichiers par FTP (ou le gestionnaire de fichiers de l’hébergeur) et la base de données par phpMyAdmin (onglet Exporter) ou avec la commande wp db export.

1. Regardez l’adresse de la page refusée

L’adresse vous dit déjà presque tout. Si elle contient admin.php?page=, c’est la page d’une extension : allez dans Extensions et vérifiez que l’extension correspondante est bien active. Si elle vient d’être mise à jour, ouvrez ses réglages depuis le menu plutôt que depuis un ancien lien : l’adresse a pu changer.

Si l’adresse est une page de base de WordPress (options-general.php, plugins.php, users.php), le problème vient de vos droits : passez aux étapes suivantes.

2. Vérifiez le rôle de votre compte

Si vous accédez encore à Utilisateurs, regardez la colonne Rôle de votre compte. Sinon, avec WP-CLI (l’outil en ligne de commande de WordPress, disponible en SSH chez la plupart des hébergeurs), listez les comptes et leurs rôles depuis le dossier du site :

wp user list --fields=ID,user_login,user_email,roles

Si votre compte n’a pas le rôle administrator, ou si la colonne des rôles est vide pour tout le monde, notez-le : une colonne vide pour tous les comptes oriente fortement vers un problème de préfixe (étape 4).

3. Désactivez les extensions de sécurité et de gestion des rôles

Pour savoir si une extension bloque l’accès, désactivez-la sans passer par l’administration. Par FTP, ouvrez wp-content/plugins et renommez le dossier de l’extension suspecte (par exemple user-role-editor en user-role-editor-off). WordPress la désactive aussitôt. À défaut, renommez le dossier plugins entier en plugins-off, testez, puis remettez son nom et réactivez les extensions une par une.

En WP-CLI, la même chose se fait ainsi :

wp plugin list --status=active
wp plugin deactivate user-role-editor
# ou, pour tester sans aucune extension :
wp plugin deactivate --all

Attention, wp plugin deactivate --all désactive vraiment tout : notez la liste affichée par la première commande pour pouvoir tout réactiver ensuite avec wp plugin activate suivi des noms.

4. Vérifiez le préfixe des tables après une migration

Ouvrez wp-config.php à la racine du site et repérez la ligne du préfixe :

$table_prefix = 'wp_';

Ouvrez ensuite phpMyAdmin et regardez le nom des tables. Elles doivent toutes commencer par ce même préfixe (par exemple wp_options, wp_users). Puis lancez ces deux requêtes, en remplaçant wp_ par le préfixe indiqué dans wp-config.php :

SELECT option_name FROM wp_options WHERE option_name LIKE '%user_roles';
SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE meta_key LIKE '%capabilities';

Si la première requête renvoie ancien_user_roles alors que vos tables s’appellent nouveau_options, ou si les clés de la seconde commencent par un autre préfixe que celui des tables, vous avez trouvé la cause. Avec WP-CLI, wp db prefix affiche le préfixe utilisé par le site.

5. Renommez les clés qui stockent les rôles

Dans l’exemple suivant, l’ancien préfixe est wp_ et le nouveau nouveau_ : adaptez les deux à votre cas, et ne lancez ces requêtes qu’après avoir exporté la base.

UPDATE nouveau_options
SET option_name = 'nouveau_user_roles'
WHERE option_name = 'wp_user_roles';

UPDATE nouveau_usermeta
SET meta_key = REPLACE(meta_key, 'wp_', 'nouveau_')
WHERE meta_key IN ('wp_capabilities', 'wp_user_level', 'wp_user-settings', 'wp_user-settings-time', 'wp_dashboard_quick_press_last_post_id');

Nous limitons la seconde requête à des clés connues pour ne pas toucher aux données des extensions.

6. Rendez le rôle administrateur à votre compte

Si le préfixe est bon mais que votre compte a perdu son rôle, WP-CLI règle le problème en une commande (remplacez 1 par l’identifiant de votre compte, vu à l’étape 2) :

wp user set-role 1 administrator

Si c’est le rôle Administrateur lui-même qui a été vidé de ses capacités par une extension, la commande wp role reset lui rend ses capacités d’origine. wp cap list administrator doit ensuite afficher manage_options.

wp role reset administrator
wp cap list administrator

Sans accès SSH, la même réparation se fait dans phpMyAdmin, table wp_usermeta (avec votre préfixe) : la ligne wp_capabilities de votre compte doit contenir exactement la valeur ci-dessous, et la ligne wp_user_level la valeur 10.

a:1:{s:13:"administrator";b:1;}

Le chiffre 13 correspond au nombre de caractères du mot « administrator » : si vous tapez la valeur à la main, la moindre faute rend le rôle illisible.

7. Sur un multisite, vérifiez les super administrateurs

Si le refus ne concerne que les pages du réseau, votre compte n’est simplement pas super administrateur. Avec WP-CLI, wp super-admin list affiche la liste et wp super-admin add votre-identifiant ajoute votre compte.

8. Videz le cache objet

Si le site utilise un cache objet (Redis ou Memcached, souvent activé par l’hébergeur ou une extension de cache), WordPress peut continuer à lire les anciens rôles après votre correction. Videz-le avec wp cache flush puis reconnectez-vous.

Si rien ne suffit, activez le journal de débogage dans wp-config.php (au-dessus de la ligne « C’est tout, ne touchez pas à ce qui suit »), rechargez la page refusée et lisez wp-content/debug.log :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Pensez à repasser WP_DEBUG à false une fois le diagnostic terminé.

Comment vérifier que c’est réparé ?

La réparation est réussie quand le menu complet de l’administration réapparaît et que la page qui était refusée s’ouvre. Testez Réglages, Extensions et Utilisateurs, puis vérifiez avec wp user list --fields=ID,user_login,roles que chaque compte a retrouvé le bon rôle.

Comment éviter que l’erreur revienne ?

• Après une migration, vérifiez toujours que le préfixe de wp-config.php correspond aux tables, et que les clés user_roles et capabilities ont été renommées.
• Ne gardez pas en favori les pages de réglages des extensions : passez par le menu, dont les liens suivent les mises à jour.
• Modifiez les rôles avec prudence et notez ce que vous changez.
• Gardez au moins deux comptes administrateur nominatifs, avec des mots de passe forts, pour ne jamais être bloqué par un seul compte.
• Faites des sauvegardes régulières de la base : c’est elle qui contient les rôles. Une maintenance WordPress suivie s’en charge pour vous.

Quand faire appel à un professionnel ?

Il vaut mieux vous arrêter si vous n’avez ni accès SSH ni phpMyAdmin, si la requête de l’étape 4 montre des préfixes mélangés entre plusieurs tables, ou si vous découvrez un administrateur inconnu. Dans ce dernier cas, corriger les droits ne suffit pas : il faut trouver la faille, comme dans l’affaire des administrateurs cachés créés via Ninja Forms, et notre scanner de sécurité gratuit donne un premier état des lieux.

Pour retrouver d’autres messages et leur signification, consultez notre décodeur d’erreurs WordPress, ainsi que la fiche courte « Sorry, you are not allowed to access this page ». Tous nos guides pas à pas sont regroupés sur la page Résoudre une panne.