Ce guide aide les propriétaires et administrateurs WordPress qui arrivent à se connecter, mais qui voient ensuite « Sorry, you are not allowed to access this page. » au lieu du tableau de bord. En français, WordPress affiche « Désolé, vous n’avez pas l’autorisation d’accéder à cette page. » La connexion fonctionne, donc le mot de passe est bon, mais WordPress traite votre compte comme s’il n’avait aucun droit. La plupart du temps, la cause est un détail de base de données laissé par une migration ou par un changement de préfixe de tables. Le préfixe de tables est le court texte, comme wp_, au début du nom de chaque table WordPress. Quand certaines données de rôles utilisent encore l’ancien préfixe, WordPress ne trouve plus votre rôle. Vous allez vérifier ce point d’abord avec WP-CLI (l’outil WordPress en ligne de commande), le corriger avec quelques requêtes SQL, puis écarter les causes moins fréquentes.
Ce que vous allez accomplir
- Comprendre comment WordPress décide si votre compte peut ouvrir une page d’administration.
- Savoir en quelques minutes si un décalage de préfixe de tables est la cause.
- Renommer les anciennes clés de préfixe de façon sûre, après une sauvegarde de la base de données.
- Rétablir un rôle manquant ou abîmé avec
wp user set-roleetwp role reset. - Écarter les extensions, les signets périmés et les problèmes de multisite, puis confirmer que l’accès complet est revenu.
Prérequis
Il vous faut un accès SSH ou terminal au serveur qui fait rouler le site, et WP-CLI installé. Vérifiez avec wp --info ; toute version 2.x récente convient. Lancez chaque commande depuis le dossier racine de WordPress (celui qui contient wp-config.php), avec le compte propriétaire des fichiers du site. Sur cPanel, c’est l’utilisateur cPanel, pas root. Si vous devez travailler en root, ajoutez --allow-root.
Sans WP-CLI, vous pouvez lancer les mêmes requêtes SQL dans phpMyAdmin, à partir de cPanel. La logique reste la même.
Les exemples utilisent wp_ comme ancien préfixe et sh7_ comme nouveau. Remplacez les deux par vos vraies valeurs partout. Dans un WordPress multisite, les clés d’un site portent aussi son numéro, comme sh7_2_capabilities. La section sur le multisite plus bas couvre ce cas.
Comment ça fonctionne
WordPress ne note pas « administrateur » dans la ligne de l’utilisateur elle-même. Il le note à deux autres endroits, et les deux noms commencent par le préfixe de tables.
D’abord, chaque utilisateur a une ligne dans la table usermeta (les réglages supplémentaires propres à chaque utilisateur) avec la clé <prefix>capabilities. Sa valeur liste les rôles de l’utilisateur, par exemple administrator. Une deuxième clé, <prefix>user_level, garde un ancien niveau numérique que certains codes lisent encore.
Ensuite, la table des options contient une option nommée <prefix>user_roles. Elle définit ce que chaque rôle a le droit de faire, comme manage_options ou edit_posts. Ces droits s’appellent des capacités (capabilities).
Quand vous ouvrez une page d’administration, WordPress lit votre rôle dans usermeta, cherche ce rôle dans l’option, puis vérifie si la capacité exigée par la page figure dans la liste. S’il manque un maillon dans cette chaîne, la vérification échoue et l’erreur s’affiche.
WordPress construit ces noms de clés à partir de $table_prefix dans wp-config.php. Un outil de migration ou un changement manuel de préfixe renomme souvent les tables, mais laisse intacts les noms de clés à l’intérieur. Les tables s’appellent sh7_usermeta, mais la ligne dedans dit encore wp_capabilities. WordPress cherche sh7_capabilities, ne trouve rien, et vous traite comme un utilisateur sans rôle.
Étapes
1. Faites une sauvegarde de la base de données. Chaque correctif ci-dessous modifie la base, alors exportez-la d’abord.
wp db export ~/before-role-fix.sqlUn succès ressemble à Success: Exported to '/home/<user>/before-role-fix.sql'. Si vous voyez une erreur de connexion à la base, vous n’êtes pas dans le bon dossier, ou wp-config.php contient de mauvais paramètres de base de données. Corrigez cela d’abord.
2. Lisez le préfixe de tables actif.
wp db prefixLa commande affiche le préfixe tiré de wp-config.php, par exemple sh7_. Listez ensuite les tables pour confirmer qu’elles utilisent le même préfixe.
wp db tablesToutes les tables principales, comme sh7_options et sh7_usermeta, devraient commencer par ce préfixe. Si les tables utilisent un autre préfixe que wp-config.php, vous verriez en général l’écran d’installation, pas cette erreur. Consultez la dernière section dans ce cas.
3. Vérifiez si un utilisateur a un rôle.
wp user list --role=administrator --fields=ID,user_login,user_emailUn site en bonne santé affiche au moins une ligne. Un tableau vide indique fortement un décalage de préfixe. Vérifiez aussi votre propre compte, avec son ID ou son identifiant.
wp user get 1 --field=rolesUn résultat vide veut dire que WordPress ne voit aucun rôle pour cet utilisateur.
4. Cherchez les clés avec l’ancien préfixe. Cette requête liste toutes les clés de capacités dans usermeta, quel que soit leur préfixe.
wp db query "SELECT user_id, meta_key FROM sh7_usermeta WHERE meta_key LIKE '%capabilities';"Si vous voyez wp_capabilities alors que le préfixe actif est sh7_, vous avez trouvé la cause. Vérifiez maintenant l’option des rôles.
wp option get sh7_user_roles --format=jsonSi la commande affiche Error: Could not get 'sh7_user_roles' option. Does it exist?, cherchez l’ancien nom.
wp db query "SELECT option_name FROM sh7_options WHERE option_name LIKE '%user_roles';"Un résultat wp_user_roles confirme que l’option n’a jamais été renommée.
5. Renommez les anciennes clés avec le nouveau préfixe. Assurez-vous qu’aucune clé portant le nouveau nom n’existe déjà ; les requêtes de l’étape 4 vous le montrent. Lancez ensuite ces requêtes. Elles ne touchent que les clés principales exactes, donc les données d’extensions qui commencent par hasard par wp_ restent intactes.
wp db query "UPDATE sh7_options SET option_name = 'sh7_user_roles' WHERE option_name = 'wp_user_roles';"
wp db query "UPDATE sh7_usermeta SET meta_key = 'sh7_capabilities' WHERE meta_key = 'wp_capabilities';"
wp db query "UPDATE sh7_usermeta SET meta_key = 'sh7_user_level' WHERE meta_key = 'wp_user_level';"
wp db query "UPDATE sh7_usermeta SET meta_key = 'sh7_user-settings' WHERE meta_key = 'wp_user-settings';"
wp db query "UPDATE sh7_usermeta SET meta_key = 'sh7_user-settings-time' WHERE meta_key = 'wp_user-settings-time';"Elles n’affichent rien quand elles réussissent. Videz le cache d’objets (une mémoire que certains sites utilisent pour garder les résultats de la base) afin que WordPress relise les données.
wp cache flushRefaites l’étape 3. Votre compte devrait maintenant afficher administrator. Si c’est le cas, c’est réglé ; passez directement à la validation.
6. Rétablissez un rôle manquant ou abîmé. Sautez cette étape si l’étape 5 a tout réglé. Si les préfixes concordent mais que votre utilisateur n’a toujours pas de rôle, une extension d’édition de rôles ou un attaquant l’a peut-être modifié. Redonnez son rôle au compte.
wp user set-role 1 administratorAttendez-vous à une ligne comme Success: Added admin (1) to https://example.com as administrator. Si le rôle administrateur lui-même a perdu ses capacités, comparez-le avec une installation qui fonctionne.
wp cap list administrator | wc -lSur un WordPress récent, le résultat tourne autour de 60 ou plus. Un nombre très bas indique que la définition du rôle est abîmée. Réinitialisez les rôles par défaut avec leurs capacités par défaut.
wp role reset --allCette commande réécrit les cinq rôles par défaut (administrator, editor, author, contributor, subscriber). Les rôles personnalisés ajoutés par des extensions ne sont pas touchés. Les capacités personnalisées ajoutées aux rôles par défaut sont retirées, alors une extension pourrait devoir être réactivée pour les remettre.
Si le site a peut-être été piraté, listez tous les administrateurs et vérifiez chacun d’eux.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredSupprimez ou rétrogradez tout compte que vous ne reconnaissez pas, et traitez le site comme compromis. Changer les mots de passe n’est que le début de ce nettoyage.
7. Écartez les extensions. Certaines erreurs viennent d’une extension, pas de votre rôle. Le cas classique est un signet vers admin.php?page=<slug> pour une extension désactivée ou supprimée depuis. WordPress affiche le même message, parce qu’aucune page ne porte plus ce nom. Ouvrez /wp-admin/ directement pour tester ce cas.
Les extensions de sécurité peuvent aussi bloquer les pages d’administration selon l’utilisateur, l’adresse IP ou le pays. Désactivez toutes les extensions pour tester.
wp plugin list --status=active --field=name > ~/active-plugins.txt
wp plugin deactivate --allSi le tableau de bord s’ouvre maintenant, réactivez les extensions une à la fois et rechargez la page après chacune.
wp plugin activate <plugin-slug>L’extension qui fait revenir l’erreur est la cause. Le fichier ~/active-plugins.txt garde votre liste d’origine.
8. Vérifiez l’accès en multisite. Dans un réseau multisite, chaque site garde ses rôles sous sa propre clé, comme sh7_2_capabilities pour le site 2, et sa propre option sh7_2_user_roles dans la table sh7_2_options. Refaites l’étape 4 avec ces noms. Les droits sur tout le réseau viennent plutôt de la liste des super administrateurs.
wp super-admin listSi votre identifiant n’y est pas, ajoutez-le de nouveau.
wp super-admin add adminUn utilisateur sans rôle sur un site voit en général « You do not currently have privileges on this site » plutôt que cette erreur. Ajoutez le rôle pour ce site avec wp user set-role admin administrator --url=https://site2.example.com.
Valider le résultat
Faites d’abord les vérifications en ligne de commande.
wp user get 1 --field=roles
wp user list --role=administrator --fields=ID,user_login
wp option get sh7_user_roles --format=json | head -c 200Vous devriez voir administrator, au moins une ligne d’administrateur et le début d’une liste JSON de rôles. Déconnectez-vous ensuite, effacez les témoins (cookies) du site dans votre navigateur, puis reconnectez-vous. Ouvrez ces pages une à une : le tableau de bord, Réglages > Général, Extensions et Utilisateurs. Chacune exige une capacité différente, alors si les quatre s’ouvrent, le rôle est complet.
Enfin, gardez la sauvegarde de l’étape 1 quelques jours. Vous pourrez la supprimer une fois que le site aura roulé normalement un bout de temps.
Dépannage
La requête UPDATE a roulé, mais rien n’a changé. Relancez les requêtes SELECT de l’étape 4 pour voir quels noms de clés existent maintenant. Une faute de frappe dans l’un des préfixes est la raison habituelle. Confirmez aussi que vous avez modifié la table avec le préfixe actif, et non une vieille table restée en place.
wp_user_roles et sh7_user_roles existent tous les deux. Une extension ou une connexion ratée a peut-être créé une nouvelle option vide. Comparez leur taille avec wp db query "SELECT option_name, LENGTH(option_value) FROM sh7_options WHERE option_name LIKE '%user_roles';". Gardez la plus grosse : supprimez la petite nouvelle avec wp option delete sh7_user_roles, puis lancez le renommage de l’étape 5.
WP-CLI affiche le rôle, mais le navigateur montre toujours l’erreur. Un cache de pages ou un cache d’objets sert de vieilles données. Lancez wp cache flush, videz l’extension de cache et testez dans une fenêtre de navigation privée. Si votre réseau de diffusion de contenu (CDN) met les pages d’administration en cache, contournez-le pour /wp-admin/.
Une seule page d’extension donne l’erreur. Votre rôle est correct. La page appartient à une extension désactivée, ou elle exige une capacité que votre rôle n’a pas. Désactivez puis réactivez cette extension, ou vérifiez ses réglages pour une restriction par rôle.
D’autres problèmes étranges après une migration. De mauvais propriétaires de fichiers peuvent bloquer les mises à jour et les téléversements d’une façon qui ressemble à une erreur de permission. Consultez corriger la propriété des fichiers après un déplacement manuel de WordPress. Pour la migration au complet, voyez migrer WordPress vers cPanel depuis un hébergeur générique.
Quand ce n’est pas la bonne approche
Si vous n’arrivez pas du tout à vous connecter, ce guide ne s’applique pas. Une boucle de connexion ou un mauvais mot de passe est un problème distinct.
Si vous voyez l’écran d’installation de WordPress, ou « Error establishing a database connection », le préfixe de wp-config.php ne correspond pas du tout aux noms des tables. Corrigez $table_prefix dans wp-config.php au lieu de renommer des clés.
Si vous trouvez des comptes administrateurs que vous n’avez pas créés, traitez la situation comme un incident de sécurité. Rétablir votre rôle n’est qu’une étape ; il faut aussi trouver par où l’attaquant est entré et nettoyer les fichiers.
Si le site appartient à une plateforme gérée qui contrôle les rôles par authentification unique, consultez d’abord la plateforme. Son propre système de connexion attribue peut-être votre rôle. La documentation des commandes WP-CLI décrit chaque commande utilisée ici.
Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.