Vous tapez l'adresse de votre tableau de bord et vous n'entrez pas. Le formulaire se recharge sans rien dire, le navigateur affiche une erreur, ou la page de connexion ne s'ouvre plus du tout. Pendant ce temps, le site public continue parfois de tourner comme si de rien n'était.
Les guides qui traitent cette panne alignent des méthodes à essayer dans l'ordre, du renommage du dossier des extensions à la suppression du .htaccess. Presque aucun ne pose la question qui trie vraiment : qu'est-ce qui s'affiche à l'écran, exactement ? Il y a six écrans possibles, ils désignent six causes distinctes, et celui que vous avez sous les yeux élimine les cinq autres.
Pour chacun : la manipulation exacte, le fichier à ouvrir, la vérification, et la façon de revenir en arrière.
Ce que vous voyez, et ce que ça désigne
Ouvrez https://votre-domaine.fr/wp-login.php plutôt que /wp-admin. La première adresse est le formulaire lui-même, la seconde y mène par une redirection qui brouille le diagnostic.
| L'écran que vous avez | Ce que ça désigne |
|---|---|
| Le site public s'affiche normalement, la page de connexion ne se charge pas ou renvoie ailleurs | Un désaccord d'adresse entre WordPress et ce que le serveur sert réellement |
ERR_TOO_MANY_REDIRECTS, ou « Cette page ne fonctionne pas, elle vous a redirigé à de trop nombreuses reprises » |
Deux couches qui se renvoient la requête, presque toujours autour du HTTPS |
| Le formulaire se recharge, sans message d'erreur, avec des identifiants pourtant bons | Un cookie de session qui ne se pose pas : cache serveur, clés de sécurité, base saturée |
| Un message qui parle de cookies bloqués | Une sortie parasite avant les en-têtes, provoquée par une extension |
| La connexion passe, puis « Désolé, vous n'avez pas l'autorisation d'accéder à cette page » | Le compte a perdu son rôle d'administrateur |
| Une erreur 403 ou une page vide, sur l'administration et sur le site public | La panne n'est pas dans l'administration, elle est devant ou dessous |
Regardez aussi, dans un autre onglet, si le site public répond : un site debout avec une administration morte n'a pas les mêmes causes qu'un site entièrement hors service.
En trente secondes
1. Notez l'écran exact et l'adresse dans la barre. Si elle contient ?redirect_to=...%2Fwp-admin%2F&reauth=1, vous êtes dans le cas de la boucle après authentification, et pas dans celui du mot de passe refusé. La différence vous fait gagner une heure.
2. Ouvrez le site sur les données mobiles de votre téléphone, wifi coupé. S'il s'affiche depuis le réseau mobile alors qu'il refuse tout depuis chez vous, le site n'a rien : c'est votre adresse IP qui est bloquée. Ce test ne touche à rien et il tranche en dix secondes.
3. Essayez une fois en navigation privée. Non parce que c'est souvent la cause, mais parce que cela distingue une panne qui suit l'appareil d'une panne qui suit le site.
La question à poser n'est pas « qu'avez-vous fait juste avant »
Sur notre banc d'essai, un fichier PHP rendu illisible a continué d'être servi normalement, en 200, tant que le pool PHP n'avait pas redémarré. Le cache d'opcode gardait la version compilée. La panne, un 403, n'est apparue qu'après le redémarrage du pool.
C'est l'explication d'une famille entière de discussions où le site « est tombé tout seul, sans que personne ne touche à rien ». Personne n'y a touché dans l'heure, en effet. La bonne question est donc : qu'est-ce qui a été modifié, installé ou mis à jour dans les vingt-quatre dernières heures ? Une mise à jour faite la veille au soir peut très bien casser l'administration le lendemain matin.
Écran 1 : le site fonctionne, la page de connexion ne s'ouvre pas
C'est le cas le plus mal traité du corpus français, et sa signature est très nette.
Nous avons mis siteurl et home en https sur un serveur qui ne sert que du http. Résultat mesuré : la page d'accueil répond 200 et le site est parfaitement normal, tandis que wp-login.php renvoie un 302 vers une adresse qui n'aboutit pas. Rien d'autre ne bouge. Quelqu'un qui dit « mon site marche mais je ne peux plus me connecter » a donc très probablement ce problème-là, et pas un conflit d'extension.
Le déclencheur habituel est un clic sur « Enregistrer » dans Réglages puis Général, après avoir modifié l'un des deux champs d'adresse, ou l'ajout d'un www d'un côté et pas de l'autre. Variante : /wp-admin vous renvoie sur la page d'accueil. Cherchez alors une extension qui masque l'adresse de connexion, une extension de redirection, ou une redirection posée en amont, comme dans ce fil du forum OVH où la zone du domaine pointait vers un service de redirection au lieu de l'hébergement.
La correction. Ouvrez wp-config.php à la racine du site, par FTP ou par le gestionnaire de fichiers de l'hébergeur, et ajoutez deux lignes :
define( 'WP_HOME', 'https://votre-domaine.fr' );
define( 'WP_SITEURL', 'https://votre-domaine.fr' );
Respectez le protocole réellement servi, et pas de barre oblique à la fin. Ces deux constantes priment sur ce que contient la base, ce qui vous fait rentrer sans toucher à phpMyAdmin.
La vérification. Rechargez wp-login.php, le formulaire doit s'afficher. Laissez passer trois secondes entre l'enregistrement du fichier et le rechargement : là où le cache d'opcode revalide toutes les deux secondes, un essai trop rapide lit encore l'ancienne version du fichier, et nous nous sommes fait piéger nous-mêmes de cette façon.
Le retour arrière. Gardez une copie de wp-config.php sur votre ordinateur avant de le modifier. Une fois connecté, corrigez les deux champs dans Réglages puis Général, et retirez les deux lignes : tant qu'elles sont là, les champs restent grisés.
Pour corriger directement en base : phpMyAdmin, table wp_options, le préfixe wp_ peut être différent chez vous, lignes siteurl et home, colonne option_value. Notez l'ancienne valeur avant de la remplacer. Et si la correction en base ne change rien, c'est que wp-config.php définit déjà ces constantes : le fichier gagne toujours contre la base.
Écran 2 : ERR_TOO_MANY_REDIRECTS
Le navigateur affiche ERR_TOO_MANY_REDIRECTS, ou « Cette page ne fonctionne pas, elle vous a redirigé à de trop nombreuses reprises ». Parfois seule la connexion boucle, parfois l'administration entière après authentification.
Le mécanisme est toujours le même : deux couches ne sont pas d'accord sur le protocole. Le cas le plus courant est un proxy ou un service de protection placé devant le site, qui parle https au visiteur et http au serveur d'origine. WordPress voit arriver du http, redirige vers https, le proxy redemande la page en http, et ça tourne. C'est le comportement du mode SSL dit « Flexible ».
Nous l'avons reproduit. Le proxy annonçait pourtant la bonne information dans un en-tête X-Forwarded-Proto: https, mais le cœur de WordPress ne lit cet en-tête nulle part, vérification faite dans le code. Il faut donc le lui traduire soi-même, dans wp-config.php :
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
&& $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
$_SERVER['HTTPS'] = 'on';
}
Avec ces quatre lignes, la boucle mesurée en 302 sans fin est passée en 200. Mesure faite deux fois, le bloc placé avant la ligne That's all, stop editing, puis après : 200 dans les deux positions.
Deux tests qui ne cassent rien, avant de coller quoi que ce soit. Si votre domaine passe par un service de protection, basculez son enregistrement en mode direct quelques minutes : si la boucle disparaît, la cause est devant WordPress. Regardez ensuite les en-têtes de la réponse, dans l'onglet Réseau des outils de développement ou avec curl -I. Une redirection émise par WordPress porte l'en-tête X-Redirect-By: WordPress, et dans ce cas le proxy est hors de cause.
Le piège à éviter. Ajouter une redirection http vers https dans le .htaccess pour forcer les choses élargit la panne au lieu de la réduire. Un cas raconté sur Reddit le résume : la boucle ne touchait que la page de connexion, elle a fini par toucher le site entier.
Le retour arrière. Retirez le bloc et enregistrez, le fichier revient à son état précédent. Si vous avez touché au .htaccess, renommez-le plutôt que de le supprimer, en htaccess-ancien par exemple. Sous Nginx, LiteSpeed ou OpenLiteSpeed, ce fichier n'est d'ailleurs pas lu, ou seulement en partie, et tout ce qu'on vous conseillera d'y écrire restera sans effet.
Si vous n'avez ni FTP, ni accès au panneau de l'hébergement, ni le mot de passe de phpMyAdmin, aucune de ces manipulations n'est à votre portée, et c'est la situation la plus fréquente chez les gens qui nous appellent. Faire reprendre la main sur un WordPress bloqué coûte 149 € HT, remis en ligne ou remboursé.
Écran 3 : le formulaire se recharge, sans le moindre message
Vous saisissez vos identifiants, vous cliquez, et vous revenez sur le même formulaire. Pas d'erreur de mot de passe, pas d'avertissement.
Le symptôme dit une chose précise : la connexion a peut-être réussi côté serveur, mais le cookie de session n'a pas été posé, ou pas relu. Trois causes produisent ça, et elles sont absentes des articles français.
Un cache serveur qui met en cache les pages d'administration. C'est la cause la plus sous-documentée du sujet. Une discussion sur WordPress Stack Exchange se termine par une phrase courte : réglé en désactivant le cache du serveur sur les pages d'administration. Le signe qui ne trompe pas, dans ce même fil, c'est qu'en ouvrant le site depuis un autre appareil la personne se retrouvait connectée avec le compte de quelqu'un d'autre.
Correction : dans les réglages de l'extension de cache, cherchez le champ d'exclusion d'URL et ajoutez-y wp-admin et wp-login. Pour vérifier que c'est bien elle, renommez son dossier dans wp-content/plugins en lui ajoutant un tiret, testez, puis remettez le nom d'origine. Si le cache est celui de l'hébergeur, la demande au support tient en une ligne : désactiver le cache sur /wp-admin/ et /wp-login.php.
Les clés de sécurité de wp-config.php. Le fichier contient huit lignes de clés et de sels qui servent à signer les cookies d'authentification. Périmées, dépareillées, ou recopiées d'une autre installation lors d'une migration, elles produisent ce rechargement silencieux. Le générateur officiel de WordPress fournit un bloc neuf à coller à la place des huit lignes existantes, sans toucher à rien d'autre.
Sachez ce que vous déclenchez : remplacer ces clés invalide toutes les sessions ouvertes, la vôtre, celle de vos rédacteurs et celle des clients connectés à une boutique. Faites-le en heure creuse, et gardez la copie de l'ancien fichier, qui est votre retour arrière.
La base de données arrivée à son quota. Sur le forum d'OVH, une personne qui bouclait sur sa page de connexion avait une base à 200,07 Mo pour 200 Mo autorisés, avec le message SQL qui le disait en clair, INSERT, UPDATE command denied ... for table 'wp_options'. WordPress ne pouvait plus écrire la session, donc la connexion ne s'établissait jamais. Regardez la taille de votre base dans le panneau de l'hébergement, ça prend dix secondes. Le nettoyage, lui, demande de la prudence : une table altérée et WordPress ne fonctionne plus du tout.
Écran 4 : un message qui parle de cookies
Deux libellés circulent, et ils ne disent pas la même chose.
« Les cookies sont bloqués ou ne sont pas pris en charge par votre navigateur. Vous devez activer les cookies pour utiliser WordPress. » Celui-là peut effectivement venir du navigateur, et une navigation privée le lève parfois.
« Erreur : les cookies sont bloqués à cause d'une sortie inattendue. » Celui-là n'a rien à voir avec votre navigateur, et le conseil universel « videz vos cookies » ne peut rien pour vous. Un fichier a écrit quelque chose, un espace, un avertissement PHP, une ligne de texte, avant que WordPress n'ait pu poser l'en-tête du cookie. Un cas relevé sur Reddit montre les deux avertissements affichés au-dessus du formulaire, et ils désignent le coupable :
Warning: Creating default object from empty value in
/wp-content/plugins/<nom-de-l-extension>/.../fichier.php on line 29
Warning: Cannot modify header information - headers already sent
(output started at .../fichier.php:29) in .../wp-login.php on line 462
Le chemin de la première ligne est celui de l'extension fautive. Renommez son dossier dans wp-content/plugins, rechargez, et le formulaire redevient utilisable. Pour revenir en arrière, remettez le nom d'origine : une extension désactivée ainsi garde ses réglages, qui sont en base et pas dans le dossier.
Si rien ne s'affiche, activez le journal en ajoutant dans wp-config.php :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Rechargez la page de connexion, puis ouvrez wp-content/debug.log : le chemin du fichier fautif y est écrit. Vous pouvez retirer ces trois lignes ensuite, ou les garder, WP_DEBUG_DISPLAY à false n'affiche rien aux visiteurs.
Écran 5 : « Désolé, vous n'avez pas l'autorisation d'accéder à cette page »
Cas particulier, parce que tout marche : la page de connexion s'ouvre, le mot de passe est accepté, et la porte se ferme ensuite. Le site public, lui, est intact.
La piste la plus solide relevée dans les discussions est la perte du rôle : un compte dont les capacités ont été vidées ou écrasées se connecte sans problème et n'a plus le droit d'ouvrir quoi que ce soit. Ça se vérifie en lecture seule, sans rien casser. Dans phpMyAdmin, table wp_users, notez l'ID de votre compte, puis table wp_usermeta, filtrez sur cet user_id et cherchez la clé wp_capabilities. Un administrateur porte la valeur a:1:{s:13:"administrator";s:1:"1";}. Si le préfixe de vos tables n'est pas wp_, la clé le porte aussi, monprefixe_capabilities.
Avant de corriger, copiez la valeur actuelle dans un fichier texte : votre retour arrière tient en un copier-coller.
Deux causes rendent la chose crédible, une extension de gestion de rôles mal réglée, ou une migration qui a changé le préfixe des tables sans mettre à jour les clés de wp_usermeta. Dans ce second cas, corriger un seul compte ne suffit pas, tous les utilisateurs sont dans le même état.
Écran 6 : 403, page blanche, ou erreur sur tout le site
Vérifiez si le site public répond. S'il tombe lui aussi, votre panne n'est pas une panne d'administration.
Un 403 partout, apparu juste après une action lourde dans l'administration. Supprimer mille commentaires indésirables, afficher deux cents éléments d'un coup, importer un gros fichier : ce genre de requête est lu comme une attaque par les pare-feu applicatifs de type mod_security, qui bloquent alors votre adresse IP. Tout ce qui part de chez vous reçoit un 403, page d'accueil comprise. D'où le test des données mobiles, plus haut. La question naïve au support reçoit toujours la même réponse inutile, « rien n'a changé sur votre hébergement » : demandez plutôt si telle adresse IP est bloquée dans le pare-feu du serveur ou dans mod_security, et réclamez la ligne de journal de l'heure de votre test.
Un 403 qui ne touche que la page de connexion. Sur notre banc d'essai, une règle laissée par un durcissement de sécurité a mis wp-login.php en 403 pendant que l'accueil restait en 200. Nous y avons appliqué le chmod que tout le monde conseille, 644, puis 755, puis 777 : trois mesures, trois fois 403. Le chmod ne peut rien contre une règle de configuration. Il répare autre chose, un dossier privé de son droit d'exécution, où 644 donne un 403 et 755 rétablit l'accès.
Une page blanche sur l'administration seule, ou le message « Il y a eu une erreur critique sur ce site » : c'est une erreur fatale de PHP et non un problème d'accès. Voyez le guide de l'écran blanc, ou celui de l'erreur 500 si le serveur renvoie ce code.
Un 404 nu sur /wp-admin et sur les articles publics, alors que l'accueil s'affiche : la réécriture d'URL est morte. Nous avons mesuré ce tableau, l'accueil tient parce qu'il n'a besoin d'aucune règle de réécriture, tout le reste tombe. C'est le guide de l'erreur 404 généralisée.
Toutes les portes fermées d'un coup, avec un message de maintenance. Une mise à jour interrompue laisse à la racine un fichier .maintenance, invisible tant que le client FTP n'affiche pas les fichiers cachés. WordPress cesse de le lire au bout de dix minutes : si votre panne dure depuis des heures, ce fichier n'est plus ce qui vous bloque.
Vous ne connaissez plus le mot de passe
Le lien « Mot de passe oublié » est la première chose à essayer. Voici la suite quand il échoue.
L'e-mail de réinitialisation n'arrive jamais
Le test qui oriente tout : envoyez-vous un message par le formulaire de contact du site. S'il n'arrive pas non plus, ce n'est pas la réinitialisation qui est cassée, c'est l'envoi de courrier du site entier. Les serveurs mutualisés expédient souvent depuis une adresse que les messageries refusent, et le message part dans le vide sans erreur visible. La solution durable passe par un envoi authentifié. Si WordPress affiche « Erreur : l'e-mail n'a pas pu être envoyé. Votre site n'est peut-être pas correctement configuré pour envoyer des e-mails », vous avez la confirmation à l'écran.
Deux vérifications complémentaires. L'adresse enregistrée est peut-être une boîte que personne ne relève plus : elle se lit et se corrige dans wp_options, ligne admin_email. Et si une extension masque votre adresse de connexion, méfiez-vous, un cas du forum officiel montre ce type d'extension bloquant au passage l'envoi du courrier de réinitialisation.
Regardez aussi vos messages reçus. Quand une extension provoque une erreur fatale, WordPress envoie un courrier intitulé « Votre site rencontre un problème technique », avec le nom du fichier fautif et un lien de récupération qui ouvre le tableau de bord, extension coupable mise en pause.
Forcer le mot de passe depuis phpMyAdmin
C'est la méthode des deux vidéos les plus vues du sujet, en français et en espagnol. On pouvait la croire périmée, puisque WordPress stocke désormais un haché moderne de 63 caractères. Nous l'avons vérifiée de bout en bout sur WordPress 7.1 : elle fonctionne toujours, formulaire envoyé, cookie de session obtenu, connexion réussie.
Dans l'ordre :
- Ouvrez phpMyAdmin depuis le panneau de votre hébergeur. Le nom de la base est dans
wp-config.php, lignedefine('DB_NAME', ...). - Ouvrez la table qui se termine par
_users. - Copiez la valeur actuelle de
user_passdans un fichier texte. C'est votre retour arrière, et personne ne le dit jamais. - Modifiez la ligne de votre compte, écrivez le nouveau mot de passe en clair dans
user_pass. - Dans la colonne Fonction, à gauche du champ, choisissez
MD5. Sans cette étape, vous enregistrez votre mot de passe en clair et la connexion échouera. - Exécutez, puis connectez-vous.
Le détail qu'aucune des deux vidéos ne mentionne, et qui lève une inquiétude légitime : dès la première connexion réussie, WordPress réécrit tout seul le haché moderne. Le MD5 ne reste pas dans votre base, nous l'avons observé sur le banc d'essai.
Pour revenir en arrière, recollez l'ancienne valeur dans user_pass en laissant la colonne Fonction vide.
Si rien n'a marché
Vous n'avez ni FTP ni panneau d'hébergement. C'est le vrai mur, bien plus que la technique. Cherchez dans votre messagerie les mots « hébergement », « renouvellement » ou « cPanel » : une facture retrouve l'hébergeur plus vite que n'importe quel outil, et votre registraire de domaine n'héberge pas toujours les fichiers.
Vous ne trouvez pas wp-config.php là où il devrait être. Avant d'en conclure qu'il a disparu, vérifiez que vous regardez bien le serveur qui sert réellement le site : une discussion s'est terminée après huit messages de recherche, les fichiers étaient ailleurs.
Votre prestataire est injoignable et détient seul les accès. Ce n'est pas une panne technique mais un problème de propriété : le domaine et l'hébergement se récupèrent auprès des sociétés concernées, en prouvant que le compte est à vous.
Vous avez déjà collé trois bouts de code trouvés sur des blogs. Retirez-les tous, en commençant par le dernier. Un site sur lequel quinze modifications ont été empilées n'est plus diagnosticable.
Ce que nous ne faisons pas. Le forfait couvre la panne, remettre l'accès en état et documenter la cause. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème.
Comment éviter que ça recommence
Créez un second compte administrateur, avec une autre adresse e-mail, relevée par quelqu'un d'autre si le site appartient à une entreprise. Beaucoup des situations décrites plus haut se règlent en trente secondes quand il existe un deuxième jeu de clés.
Notez où sont vos accès pendant que tout va bien. Hébergeur, identifiants FTP, adresse de phpMyAdmin, adresse e-mail de l'administrateur, et vérifiez que cette boîte est relevée, c'est là qu'arrive le message de récupération. Le jour de la panne, cette feuille vaut une heure.
Excluez les pages d'administration de vos caches, celui de l'extension comme celui de l'hébergeur. Trois minutes de réglage qui suppriment une cause entière.
Ne mettez pas quarante extensions à jour dans la même minute. Et gardez en tête le décalage du cache d'opcode : la panne peut apparaître le lendemain, ce qui rend le lien avec la mise à jour bien moins évident.
Surveillez la taille de votre base si votre offre impose un quota. Une base pleine ne prévient pas, elle bloque l'écriture, et le premier symptôme est souvent une connexion qui n'aboutit plus.
Questions fréquentes
Pourquoi ma page admin WordPress est-elle inaccessible ?
L'écran affiché dit laquelle des six familles de causes est en jeu. Un site public normal avec une page de connexion morte désigne un désaccord d'adresse. Une boucle de redirection désigne un conflit de protocole, souvent un proxy en SSL flexible. Un formulaire qui se recharge en silence désigne un cookie de session qui ne se pose pas, un message d'autorisation après connexion un rôle perdu, et un 403 sur tout le site un blocage de votre adresse IP.
Comment puis-je accéder à l'admin WordPress ?
L'adresse est https://votre-domaine.fr/wp-login.php, ou https://votre-domaine.fr/wp-admin. Si elle renvoie une page introuvable, une extension a peut-être remplacé cette adresse : son dossier apparaît dans wp-content/plugins, et le renommer par FTP rétablit l'adresse par défaut.
Comment débloquer un site WordPress ?
Déterminez d'abord si le site public répond. S'il répond et que seule l'administration est fermée, regardez les adresses de WordPress, les caches et les cookies de session. Sinon, lisez le code d'erreur et le journal du serveur avant de toucher à quoi que ce soit.
Quel est mon identifiant WordPress ?
Il se lit dans la base, table wp_users, colonne user_login. L'adresse e-mail du compte fonctionne aussi comme identifiant sur le formulaire, ce qui dépanne quand vous ne vous souvenez que d'elle.
Comment changer le mot de passe WordPress dans phpMyAdmin ?
Table wp_users, ligne de votre compte, colonne user_pass. Copiez l'ancienne valeur pour pouvoir revenir en arrière, écrivez le nouveau mot de passe en clair, puis choisissez MD5 dans la colonne Fonction avant d'exécuter. La méthode fonctionne encore sur les versions récentes, nous l'avons vérifiée, et le haché moderne est réécrit dès votre première connexion.
L'e-mail de réinitialisation n'arrive jamais, que faire ?
Testez d'abord si le site envoie du courrier tout court, avec son formulaire de contact. Si rien ne part, le problème est l'envoi du serveur et non la réinitialisation, et il faudra passer par un envoi authentifié. Si le courrier part mais que ce message-là n'arrive pas, vérifiez l'adresse enregistrée dans wp_options, ligne admin_email, et regardez vos indésirables.