WordPress : boucle de connexion sur wp‑admin, la corriger

Boucle de connexion sur wp‑admin : ce qui se passe

Une boucle de connexion WordPress se produit quand le mot de passe est accepté mais que le cookie d’authentification n’est pas reconnu à la page suivante, ce qui renvoie vers wp-login.php. Les causes les plus fréquentes sont des URL incohérentes (http/https, www), des cookies périmés, un cache ou un CDN, et une extension de sécurité.

Vos contenus, votre base de données et vos comptes sont intacts. Seule la reconnaissance de votre session est bloquée. Chaque correction ci‑dessous est réversible si vous sauvegardez avant de modifier : suivez‑les dans l’ordre, du plus simple au plus technique.

Ne confondez pas ce cas avec l’erreur affichée par le navigateur « trop de redirections » : si la page de connexion ne s’affiche même plus, lisez plutôt ERR_TOO_MANY_REDIRECTS sur WordPress.

Pourquoi la connexion boucle

Un cookie d’authentification est un petit fichier que WordPress dépose dans votre navigateur après une connexion réussie et relit à chaque page de l’administration. Si ce cookie n’est pas renvoyé, ou si la page est servie sans passer par WordPress, vous êtes traité comme un visiteur anonyme et renvoyé vers la connexion.

Les causes, de la plus courante à la plus rare :

• URL incohérentes : l’adresse de WordPress et celle du site diffèrent (http contre https, avec ou sans www), donc le cookie est émis pour une adresse et lu sur une autre.
• Cookies périmés ou corrompus : un ancien cookie du même domaine entre en conflit avec le nouveau.
• Cache ou CDN : la page de connexion, ou une redirection de /wp-admin/, est mémorisée puis resservie à des utilisateurs déjà connectés.
• Extension de sécurité ou de masquage de connexion : des règles mal configurées bloquent le retour après authentification.
• Fichier .htaccess : des règles de redirection erronées interceptent la requête.

Un détail évite une fausse alerte : pour un visiteur non connecté, /wp-admin/ renvoie normalement vers wp-login.php avec un paramètre redirect_to source : MalCare, 2026. Ce comportement n’est une boucle que si vous restez bloqué après avoir saisi le bon mot de passe.

1. Tester en navigation privée et nettoyer les cookies

Ouvrez la page de connexion dans une fenêtre de navigation privée, ou dans un autre navigateur, ou sur un autre réseau (partage de connexion du téléphone). Le résultat oriente le diagnostic :

• Ça fonctionne en navigation privée : le problème vient des cookies ou du cache de votre navigateur habituel.
• Ça échoue partout : le problème est côté site (URL, cache, extension.htaccess).

Pour nettoyer, supprimez uniquement les cookies du domaine concerné, pas tous les cookies : sinon vous vous déconnectez de vos autres sites source : Liquid Web, 2026. Dans Chrome : Paramètres > Confidentialité et sécurité > Cookies > Afficher toutes les données, puis recherchez votre domaine. Rechargez la page de connexion et testez.

2. Purger le cache et contourner le CDN

Un CDN est un réseau de serveurs répartis qui sert vos fichiers depuis le point le plus proche du visiteur. S’il mémorise la page de connexion, vous recevez une version qui ne correspond pas à votre session.

Pour tester :

1. Désactivez temporairement l’extension de cache (WP Rocket, LiteSpeed Cache, etc.) ou, sans accès à l’admin, renommez son dossier dans wp-content/plugins.
2. Dans Cloudflare ou votre CDN, passez en mode développement ou purgez tout le cache.
3. Purgez le cache serveur depuis le panel de l’hébergeur (Varnish, cache de l’hébergeur).
4. Retestez en navigation privée.

Si la connexion fonctionne sans cache, la cause est trouvée : il faut exclure les pages de connexion du cache source : Liquid Web, 2026. Le cas est documenté : sur un WordPress multisite, Varnish avait mis en cache une redirection 302 de /wp-admin/ vers wp-login.php, légitime pour un anonyme mais resservie à des utilisateurs authentifiés source : discussion GitHub CloudPanel, n° 762. Les cookies étaient pourtant bien émis. Pour choisir et régler un CDN proprement, voyez notre comparatif des CDN WordPress.

3. Désactiver l’extension de sécurité par FTP

Sans accès à l’administration, passez par FTP ou le gestionnaire de fichiers de l’hébergeur (si la connexion FTP échoue, voyez Connexion FTP refusée sur FileZilla).

1. Allez dans wp-content/plugins.
2. Renommez le dossier de l’extension suspecte (par exemple une extension de masquage de connexion ou de pare‑feu) en ajoutant -off à la fin. L’extension se désactive sans rien supprimer source : WP Formation, 2026.
3. Retestez la connexion.

Si vous ignorez laquelle est en cause, renommez le dossier plugins entier en plugins-off, connectez‑vous, puis remettez le nom d’origine et réactivez les extensions une par une. Renommez toujours au lieu de supprimer : vous gardez la possibilité de revenir en arrière. Ne déposez jamais un fichier de contournement d’authentification trouvé en ligne : c’est une porte d’entrée ouverte.

4. Régénérer le fichier .htaccess

Dans la racine du site, renommez .htaccess en .htaccess.old (jamais de suppression) source : Liquid Web, 2026. Connectez‑vous, puis allez dans Réglages > Permaliens et cliquez sur Enregistrer : WordPress recrée un fichier propre. Si les règles de redirection www ou https étaient dans l’ancien fichier, reportez‑les ensuite avec la méthode de Forcer HTTPS et www.

5. Fixer les URL dans wp-config.php

C’est la correction la plus efficace pour les boucles liées à http/https ou à www. Dans Réglages > Général, deux champs existent : « Adresse web de WordPress (URL) » et « Adresse web du site (URL) », qui correspondent aux valeurs siteurl et home source : Handbook WordPress, Migrating WordPress. Quand elles diffèrent, ou que l’une est en http et l’autre en https, le cookie émis ne correspond plus à l’adresse visitée.

1. Sauvegardez wp-config.php (téléchargez une copie en local).
2. Ouvrez‑le et ajoutez, avant la ligne « That’s all, stop editing! », avec votre vraie adresse canonique :

define( 'WP_HOME', 'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );

3. Enregistrez et testez en navigation privée.

Ces constantes priment sur la base de données sans la modifier : si WP_SITEURL est définie, sa valeur est toujours retournée et celle de la base est ignorée (fonction présente depuis WordPress 2.2.0) source : Code Reference WordPress. Un slash final dans la constante ne pose pas de problème. Si les lignes semblent ignorées, certains utilisateurs ont dû placer WP_HOME tout en haut du fichier, juste après le commentaire d’en‑tête source : Codex WordPress, Editing wp-config.php.

Piège : si vous retirez ces lignes plus tard, l’adresse revient à l’ancienne valeur de la base source : Codex WordPress, Editing wp-config.php. Corrigez donc aussi la base (étape suivante) ou les Réglages > Général une fois connecté.

6. Corriger les URL directement dans la base

Si wp-config.php ne suffit pas, ou pour rendre la correction définitive :

1. Exportez la base depuis phpMyAdmin (onglet Exporter). C’est votre filet de sécurité.
2. Ouvrez la table wp_options (le préfixe wp_ peut être différent sur votre site).
3. Modifiez les valeurs des lignes siteurl et home pour qu’elles soient identiques : même protocole, même présence ou absence de www.

En SQL, la requête équivalente :

UPDATE wp_options SET option_value = 'https://www.example.com'
WHERE option_name IN ('siteurl', 'home');

Le Handbook propose aussi la constante RELOCATE dans wp-config.php en dépannage d’urgence, mais prévient qu’elle est dangereuse si on la laisse : dans certaines configurations, un attaquant peut alors changer l’URL du site. Retirez‑la dès que la connexion fonctionne source : Handbook WordPress, Migrating WordPress.

7. Derniers recours : HTTPS derrière un proxy et COOKIE_DOMAIN

Si votre site est derrière Cloudflare ou un proxy et que WordPress croit recevoir du http alors que le visiteur est en https, la session peut boucler. Réglez d’abord le mode SSL du CDN sur « Full (strict) » avec un certificat valide sur le serveur d’origine. Si le problème persiste, ce bloc (à placer dans wp-config.php) indique à WordPress que la requête est sécurisée :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

En tout dernier recours, quand la boucle vient d’un décalage www / non‑www que rien d’autre n’a résolu, define( 'COOKIE_DOMAIN', 'example.com' ); peut aider source : Liquid Web, 2026. Testez après chaque modification, une seule à la fois.

Tableau récapitulatif : cause, symptôme, solution

Cause	Indice	Solution
Cookies périmés	Ça marche en navigation privée	Supprimer les cookies du domaine
Cache ou CDN	Ça marche cache désactivé	Purger, exclure wp-login.php et /wp-admin/
Extension de sécurité	Boucle après une installation ou une mise à jour	Renommer son dossier en FTP
.htaccess erroné	Boucle sur toutes les pages admin	Renommer en .htaccess.old, régénérer les permaliens
URL incohérentes	http/https ou www différents	WP_HOME et WP_SITEURL, puis base
Proxy ou CDN en https	Site derrière Cloudflare	SSL Full (strict), en‑tête X‑Forwarded‑Proto

Questions fréquentes

Pourquoi WordPress me redemande le mot de passe alors qu'il est bon ?

Parce que le cookie posé après votre connexion n’est pas relu à la page suivante. Les causes habituelles sont des URL incohérentes, un cookie périmé ou un cache qui sert la page de connexion.

Puis‑je me verrouiller dehors en modifiant wp-config.php ?

Seulement si vous saisissez une mauvaise adresse. Sauvegardez le fichier avant, vérifiez que l’adresse correspond exactement à votre version canonique, et gardez l’accès FTP ouvert pour annuler.

Dois‑je supprimer .htaccess ou les extensions ?

Non, renommez‑les. Un fichier renommé se restaure en une seconde, un fichier supprimé non.

La boucle revient après quelques jours, pourquoi ?

Souvent un cache ou un CDN qui remémorise la page de connexion, ou des constantes retirées de wp-config.php alors que la base contient encore l’ancienne adresse. Corrigez les deux et excluez wp-login.php du cache.

Quand passer la main à un pro

Faites‑vous aider si la boucle persiste après les sept étapes, si vous suspectez un piratage (comptes administrateurs inconnus, redirections étranges : voyez Mon site WordPress a‑t‑il été piraté ?), ou si vous n’avez ni accès FTP ni accès à la base. Un site en abonnement avec maintenance incluse évite la plupart de ces blocages : mises à jour testées, cache configuré, règles de sécurité vérifiées. Notre guide sur la maintenance d’un site web détaille ce qu’elle doit couvrir.