Reconnaissez une boucle de connexion
Vous saisissez vos identifiants, le formulaire se recharge et l’administration ne s’ouvre pas. Parfois WordPress affiche un message sur les cookies ; parfois le navigateur annonce trop de redirections. Ces symptômes peuvent empêcher l’accès malgré un mot de passe correct. Recommencer la même saisie dix fois ne permet pas de distinguer leurs causes et peut déclencher une limitation des tentatives.
Notez l’adresse affichée avant et après l’envoi du formulaire. Regardez si le domaine, le protocole ou le chemin change. Un passage répété entre deux adresses est un indice différent d’un simple formulaire qui reste à la même adresse. Conservez le texte exact du message et l’heure de l’essai.
Si WordPress indique explicitement un mot de passe incorrect, suivez d’abord la récupération du compte. Si une demande de code à usage unique apparaît, il s’agit de l’étape de double authentification. Une page refusant l’accès pour des raisons de droits constitue encore un autre cas. Ce guide vise principalement une session qui n’aboutit pas ou n’est pas conservée.
Avant de toucher aux cookies ou à la configuration, préservez les contenus non enregistrés dans les autres onglets. Une session encore ouverte sur un autre appareil peut aussi permettre de consulter les réglages : gardez-la disponible pendant le diagnostic au lieu de déconnecter immédiatement tous les appareils.
Choisissez votre parcours de dépannage
Commencez par le navigateur lorsque vous êtes la seule personne concernée et qu’aucun changement du site n’a précédé la panne. Comparez avec un autre profil ou un autre navigateur, puis nettoyez uniquement les données nécessaires. Cela fournit rapidement un indice sans modifier la production.
Passez aux adresses et au HTTPS lorsque la panne suit une migration, un changement de domaine, l’installation d’un certificat ou l’ajout d’un proxy. Vérifiez l’organisation attendue avant d’éditer les valeurs. Des adresses différentes peuvent être intentionnelles dans certaines installations.
Examinez enfin le cache et les composants si le problème touche plusieurs comptes, suit une mise à jour ou dépend d’un formulaire personnalisé. Préparez une sauvegarde et, si possible, une copie de test. Faites une seule modification à la fois et recommencez le même essai pour pouvoir attribuer le résultat à cette modification.
Ces trois parcours peuvent se rejoindre. Par exemple, un changement d’adresse corrigé sur le serveur peut laisser d’anciens cookies dans le navigateur. Terminez donc chaque correction par une connexion propre, sans accumuler simultanément des modifications de fichiers, de comptes et de règles de sécurité.
Approche 1 : repartir d’un navigateur propre pour ce site
Ouvrez l’adresse habituelle du site dans un autre profil de navigateur, sans utiliser un ancien lien de récupération. Pour une installation indépendante, /wp-admin/ renvoie normalement vers la connexion lorsque vous n’êtes pas connecté. Si une adresse de connexion personnalisée a été définie volontairement, utilisez celle fournie par l’administrateur du site.
Essayez une seule connexion avec votre compte. Si elle fonctionne dans ce nouveau contexte, le site sait au moins créer une session dans ces conditions. Revenez au navigateur initial et examinez ses données et ses extensions. Le test ne prouve pas que tous les autres utilisateurs rencontrent la même cause.
Dans Chrome, ouvrez les paramètres de confidentialité et de sécurité, puis recherchez les données enregistrées pour le domaine. La rubrique des cookies tiers permet notamment d’accéder à la liste des données et autorisations des sites. Recherchez le domaine concerné, vérifiez l’entrée et supprimez ses données après avoir préservé votre travail. Cette action peut vous déconnecter et effacer des préférences locales.
Fermez les anciens onglets de connexion, rouvrez l’adresse officielle et essayez de nouveau. Il n’est pas nécessaire d’effacer les données de tous les sites ni les mots de passe enregistrés. Si le domaine a changé récemment, examinez aussi l’ancien domaine, sans supprimer indistinctement toutes les données de votre navigateur.
Distinguez les cookies du site et les cookies tiers
WordPress utilise des cookies pour reconnaître une connexion entre deux chargements de page. Un cookie de test permet aussi de vérifier que le navigateur peut recevoir les informations attendues. Un bandeau de consentement destiné aux visiteurs n’est pas, à lui seul, le réglage qui décide si la session administrative fonctionne.
Pour une installation indépendante ouverte directement sur son domaine, commencez par vérifier que le navigateur autorise ce site à enregistrer ses données. Vous n’avez pas besoin d’autoriser tous les cookies tiers sur l’ensemble du Web pour effectuer ce contrôle. Une règle gérée par une entreprise peut nécessiter l’intervention de son administrateur informatique.
Les services intégrés et certaines fonctions WordPress.com peuvent faire intervenir plusieurs domaines. Dans ce cas, les restrictions sur les cookies tiers peuvent jouer un rôle. Une exception limitée aux sites nécessaires peut être pertinente si le diagnostic le confirme. Une fenêtre privée n’est pas une preuve définitive : elle peut appliquer des restrictions différentes et bloquer les cookies tiers par défaut.
Si une extension de navigateur intervient dans la connexion, comparez son effet sur ce seul site. Conservez le réglage initial et remettez-le après l’essai. L’objectif est d’identifier un blocage précis, pas de laisser toutes les protections désactivées parce qu’un test a réussi une fois.
Examiner les cookies quand le message reste ambigu
Pour un diagnostic plus précis, ouvrez les outils de développement du navigateur et la rubrique Application, puis Cookies. Sélectionnez le domaine du site. Regardez les noms, les domaines, les chemins et les éventuels motifs de refus. Vous pouvez relever ces caractéristiques sans copier la valeur des cookies.
Un cookie limité à un domaine ou à un chemin inadapté peut ne pas accompagner la demande suivante. Un cookie réservé à une connexion sécurisée ne doit pas être traité comme un moyen de se connecter durablement en HTTP. Si le navigateur explique pourquoi il refuse un cookie, transmettez ce motif au support avec l’adresse concernée.
Ne modifiez pas les valeurs pour fabriquer une session. Elles sont vérifiées par WordPress et contiennent des informations d’authentification qu’il faut garder privées. N’envoyez pas non plus un export complet du navigateur sur un forum. Un nom de cookie, ses attributs et une capture nettoyée suffisent souvent pour commencer l’analyse.
Si les cookies sont présents mais que la connexion disparaît aussitôt, poursuivez côté serveur. Leur présence montre seulement qu’ils ont été enregistrés ; elle ne garantit pas que WordPress les accepte ou qu’ils sont envoyés à la bonne adresse.
Approche 2 : vérifier le domaine et les deux adresses WordPress
Lorsqu’un autre administrateur possède encore une session, consultez Réglages, puis Général. Comparez l’adresse de WordPress et l’adresse du site avec l’installation prévue. Recherchez un ancien domaine, un sous-domaine de test ou une différence entre HTTP et HTTPS qui ne correspond plus à l’hébergement.
Ces deux adresses ne sont pas forcément identiques. Le cœur de WordPress peut se trouver dans un sous-répertoire tandis que le site public est servi à la racine. Effacer ce sous-répertoire pour rendre les champs semblables peut casser une installation correcte. Confirmez la disposition des fichiers et l’historique de la migration avant de décider quelle valeur changer.
Si le tableau de bord est inaccessible, la configuration peut être examinée depuis l’hébergement. Repérez le bon répertoire et gardez une copie privée de wp-config.php. Les constantes WP_HOME et WP_SITEURL, lorsqu’elles sont définies, peuvent imposer les adresses utilisées par WordPress. Ne les ajoutez pas une seconde fois sans lire les définitions déjà présentes.
Dans une installation gérée, ces valeurs peuvent provenir de variables d’environnement ou d’un fichier fourni par le prestataire. Corrigez la source réellement utilisée. Modifier la base alors qu’une constante impose encore l’ancienne adresse peut donner l’impression qu’une correction a été ignorée.
Lire et corriger les adresses avec WP-CLI
Avec un accès SSH autorisé et WP-CLI disponible, placez-vous dans le répertoire de la bonne installation. Les commandes ci-dessous lisent les valeurs obtenues par WordPress. Comparez le résultat avec le domaine attendu et avec les constantes de configuration. Une valeur imposée par un filtre ou une constante peut différer de celle stockée directement dans la base.
Ne lancez pas une correction générale tant que vous n’avez pas établi la valeur erronée. Conservez une sauvegarde de la base et les anciennes adresses. Sur multisite, faites sélectionner explicitement le site visé par une personne qui connaît le réseau : une commande exécutée sans le bon contexte peut concerner un autre site.
wp option get home
wp option get siteurlAppliquer une correction d’adresse limitée et réversible
Lorsque l’erreur de valeur stockée est confirmée, wp option update peut modifier l’option concernée. L’exemple ci-dessous corrige uniquement home ; remplacez l’adresse d’exemple par celle vérifiée pour votre site. Il ne demande pas de modifier siteurl automatiquement. Si une constante impose la valeur, faites corriger cette constante dans sa configuration plutôt que de multiplier les changements.
Après la correction, ouvrez la connexion sur l’adresse attendue et recommencez avec des cookies propres pour ce domaine. Si le changement aggrave le problème, revenez à la valeur relevée et réexaminez l’organisation du site. Une modification ciblée doit rester compréhensible et facile à annuler.
Un changement de domaine complet peut aussi demander une migration des liens et des données sérialisées. Ne remplacez pas toutes les occurrences au moyen d’une requête SQL improvisée. Cette opération dépasse la simple correction de deux options et nécessite une méthode de migration avec sauvegarde et aperçu des remplacements.
wp option update home 'https://votre-domaine.example'Contrôler le HTTPS et les redirections du serveur
Si le navigateur passe continuellement de HTTP à HTTPS, de www à une adresse sans www, ou d’un domaine à un autre, relevez ce parcours. Le panneau Réseau des outils de développement peut montrer les réponses de redirection et leurs destinations. Partagez seulement les adresses nécessaires, sans les paramètres contenant des jetons de connexion.
Faites comparer les règles de l’hébergeur, du proxy et de WordPress. Deux couches peuvent imposer des destinations contradictoires. L’objectif est d’obtenir une adresse finale cohérente, avec un certificat valide, puis de vérifier que le formulaire et l’administration l’utilisent. N’effacez pas l’ensemble des règles du serveur pour supprimer une seule redirection mal configurée.
Avec un proxy qui termine le HTTPS, WordPress doit recevoir une information fiable sur le protocole utilisé par le visiteur. Une mauvaise transmission peut produire une boucle. La correction dépend de la chaîne réelle de serveurs : faites configurer les en-têtes par le prestataire et ne faites pas confiance à un en-tête fourni arbitrairement par un visiteur.
Désactiver durablement le HTTPS de l’administration n’est pas une solution de connexion. Conservez la protection des identifiants et des cookies, puis corrigez la détection du protocole et les redirections. Après cela, testez l’accès depuis l’adresse normale du site et depuis un ancien lien que les utilisateurs emploient encore.
Vérifier les constantes de cookies et les particularités du multisite
Recherchez dans la configuration les éventuelles définitions de COOKIE_DOMAIN, COOKIEPATH, SITECOOKIEPATH et ADMIN_COOKIE_PATH. Une valeur ajoutée pour un ancien domaine ou une ancienne organisation peut être devenue inadaptée. Leur absence n’est pas une anomalie : WordPress définit lui-même des valeurs lorsqu’aucune surcharge n’est fournie.
Ne copiez pas automatiquement un domaine de cookie trouvé dans un tutoriel. Un partage entre sous-domaines, un réseau multisite et plusieurs sites indépendants sur un même compte ne constituent pas la même situation. Une règle trop large peut créer des interactions entre installations qui ne devaient pas partager leur connexion.
Sur multisite, faites vérifier le domaine associé au site, le chemin de l’administration et les réglages du réseau par son administrateur. Une sous-partie du réseau peut échouer alors que le site principal fonctionne. La correction doit préserver les autres sites et tenir compte du mécanisme de connexion prévu.
Si vous retirez ou corrigez une surcharge devenue inutile, conservez sa valeur précédente et sa raison d’être. Recommencez ensuite le test avec les anciennes données du domaine supprimées dans le navigateur. Garder des cookies créés avant la correction peut brouiller l’interprétation du résultat.
Approche 3 : examiner le cache et les composants de connexion
Un cache destiné aux pages publiques ne doit pas servir indistinctement une réponse de connexion ou d’administration à tous les visiteurs. Faites vérifier les exclusions de la page de connexion, du chemin administratif et des sessions authentifiées. Une purge peut éliminer une réponse ancienne, mais elle ne corrige pas une règle qui la remettra aussitôt en cache.
Reconstituez les changements récents : extension de connexion, authentification unique, changement d’adresse administrative, redirection selon le rôle ou réglage de sécurité. Commencez par le composant lié au symptôme. Si le site utilise un fournisseur d’identité, vérifiez aussi le retour vers la bonne adresse après la connexion à ce fournisseur.
Sur une copie de préproduction, désactivez normalement le composant suspect, testez puis réactivez-le avant d’en essayer un autre. La copie doit utiliser sa propre base et une configuration de connexion adaptée à son domaine. Une copie mal configurée peut reproduire une autre panne et conduire à une conclusion erronée.
En production, une désactivation liée à l’authentification doit être préparée avec un accès administratif de secours et une fenêtre d’intervention. Ne coupez pas l’authentification unique ou la double authentification sans savoir comment les utilisateurs pourront se connecter. La réparation doit conserver le niveau de protection prévu une fois le diagnostic terminé.
Si vous n’avez plus du tout accès à l’administration
Utilisez l’accès à l’hébergement pour consulter les journaux et identifier les fichiers ou réglages concernés. Avant de renommer le dossier d’une extension, notez son nom exact et préparez le retour arrière. Une telle opération peut interrompre une fonction importante pour les visiteurs ; privilégiez une copie ou l’assistance du prestataire lorsque le composant gère les accès.
Renommer tout le dossier des extensions d’un site actif peut désactiver bien plus que le formulaire de connexion. Une boutique, un espace membres ou un formulaire commercial peut être affecté. Si une isolation globale devient nécessaire, préparez-la comme une intervention sur le site et vérifiez ensuite les composants réellement réactivés.
Examinez aussi les composants qui ne figurent pas parmi les extensions ordinaires : extensions obligatoires, cache fourni par l’hébergeur ou code spécifique. Ne les supprimez pas à l’aveugle. Leur présence explique parfois pourquoi un test avec les extensions visibles désactivées ne change rien.
Pour un thème ou du code personnalisé, travaillez sur la copie avec un thème compatible et une configuration connue. Si la connexion revient, cherchez la fonction responsable avant de remplacer durablement tout l’environnement. Conservez les versions et les résultats de chaque essai afin de pouvoir transmettre un cas reproductible.
Lire les erreurs PHP et vérifier la cohérence des sessions
Un message indiquant que les en-têtes ont déjà été envoyés peut signaler une sortie de texte trop tôt dans le traitement. Cette sortie peut perturber l’envoi des cookies ou des redirections. Le fichier cité et la ligne indiquée aident à chercher un avertissement, une modification de code ou un contenu ajouté accidentellement.
Consultez les journaux privés du prestataire à l’heure de l’essai. Si un débogage temporaire est nécessaire, gardez les erreurs hors des pages publiques et protégez le fichier de journal. Évitez de modifier le cœur de WordPress pour masquer le message : corrigez le composant ou le fichier qui produit la sortie, puis vérifiez le résultat.
Sur une infrastructure répartie entre plusieurs serveurs, une session acceptée puis refusée peut demander un contrôle de cohérence des configurations, des clés d’authentification et de l’horloge système. Faites réaliser ce contrôle par l’administrateur de l’infrastructure. Changer simplement le fuseau horaire d’affichage dans WordPress ne corrige pas l’heure du serveur.
WordPress vérifie notamment la validité et l’expiration des informations d’authentification. Un cookie visible n’est donc pas une preuve d’accès valide. Ne prolongez pas artificiellement toutes les sessions pour masquer des déconnexions immédiates et ne partagez jamais leurs valeurs avec un forum ou un interlocuteur non autorisé.
Valider une connexion durable après la correction
Ouvrez une nouvelle session, connectez-vous puis naviguez entre plusieurs écrans de l’administration. Enregistrez une petite modification dans un brouillon et rouvrez-le. Le fait d’apercevoir le tableau de bord une fois ne suffit pas si la demande suivante renvoie déjà au formulaire.
Déconnectez-vous normalement et vérifiez que l’administration demande de nouveau une connexion. Reconnectez-vous ensuite avec les protections habituelles, y compris la double authentification lorsqu’elle est utilisée. Un test concluant ne doit pas dépendre d’une exception de sécurité laissée active uniquement pour le dépannage.
Si plusieurs rôles ou plusieurs sites du réseau étaient concernés, faites vérifier les parcours représentatifs avec les comptes autorisés. Comparez aussi le navigateur initial après nettoyage avec celui utilisé pour le diagnostic. Rétablissez les composants nécessaires et retirez les réglages temporaires dont la correction n’a plus besoin.
Notez enfin la cause identifiée et la valeur corrigée : domaine de cookie obsolète, mauvaise adresse, règle de cache ou redirection contradictoire, par exemple. Cette trace sera plus utile lors d’une prochaine migration qu’une liste de suppressions faites au hasard. Le bon résultat est une session normale, conservée pendant le travail et fermée correctement à la déconnexion.
