wp-admin : guide de connexion à WordPress

Pour accéder à wp-admin, ouvrez https://votre-domaine.fr/wp-admin/, puis saisissez votre identifiant ou votre adresse e-mail et votre mot de passe. La page /wp-login.php mène au même formulaire. Si la connexion échoue, commencez par tester l’URL exacte, les cookies et les adresses home et siteurl, avant de désactiver temporairement une extension suspecte. Cette méthode rétablit l’accès dans la majorité des cas sans modifier les fichiers au hasard.

Dans WordPress, wp-admin désigne l’espace d’administration qui permet de gérer les articles, les pages, les médias, les extensions, le thème, les utilisateurs et les réglages. Ce guide explique comment ouvrir le tableau de bord, récupérer un accès perdu, diagnostiquer les erreurs 404, 403 et les boucles de connexion, puis protéger durablement la page de login.

Qu’est-ce que wp-admin dans WordPress ?

Wp-admin est à la fois le chemin public qui ouvre le tableau de bord et le répertoire technique contenant une grande partie des fichiers de l’administration. Un visiteur non authentifié qui demande /wp-admin/ est redirigé vers /wp-login.php. Après validation des identifiants, WordPress le renvoie vers le tableau de bord, généralement /wp-admin/index.php.

Ne confondez pas le dossier wp-admin avec la page de connexion. Le dossier sert les écrans d’administration, tandis que le fichier wp-login.php affiche le formulaire, crée la session et gère notamment la récupération du mot de passe. Une extension de sécurité peut masquer ou modifier l’URL de login, mais le fonctionnement interne reste fondé sur ces deux éléments.

# Installation WordPress à la racine
https://votre-domaine.fr/wp-admin/
https://votre-domaine.fr/wp-login.php

# Installation dans un sous-répertoire
https://votre-domaine.fr/blog/wp-admin/
https://votre-domaine.fr/blog/wp-login.php

Comment se connecter à wp-admin

Commencez par saisir l’adresse complète avec https et le slash final. Utilisez l’adresse du site réellement configurée, avec ou sans www. Sur le formulaire, l’identifiant peut être le nom d’utilisateur ou l’adresse e-mail associée au compte. La case « Se souvenir de moi » prolonge la session sur un navigateur de confiance, mais évitez-la sur un ordinateur partagé.

Une fois connecté, le menu latéral donne accès aux Articles, Pages, Médias, Commentaires, Apparence, Extensions, Utilisateurs, Outils et Réglages. Les menus visibles dépendent du rôle du compte. Un Auteur peut publier ses articles, tandis qu’un Administrateur gère aussi les extensions, les thèmes et les comptes.

Si vous ne connaissez plus l’adresse de votre installation, consultez la valeur du site dans le panneau de votre hébergeur. Avec WP-CLI, la commande suivante affiche l’URL enregistrée dans WordPress :

# Depuis le répertoire de l’installation WordPress
wp option get siteurl
wp option get home

# Vérifier la version du cœur
wp core version

Évitez de chercher la page de login en ajoutant des chemins inventés. Une installation dans /wordpress/, /blog/ ou un sous-domaine conserve le même suffixe, mais le préfixe dépend de la configuration du site.

Mot de passe oublié ou identifiant perdu

Sur /wp-login.php, cliquez sur « Mot de passe oublié ? », puis saisissez votre identifiant ou votre adresse e-mail. WordPress envoie un lien temporaire de réinitialisation. Vérifiez les courriers indésirables et attendez quelques minutes. Si aucun message n’arrive, le problème peut venir de l’adresse enregistrée, de la délivrabilité du serveur ou d’un plugin qui bloque l’envoi.

Avec un accès SSH et WP-CLI, réinitialisez le mot de passe sans écrire directement dans la base de données. Remplacez l’identifiant par celui du compte concerné et ne mettez jamais un mot de passe réel dans un script conservé sur le serveur.

# Afficher les comptes existants
wp user list --fields=ID,user_login,user_email,roles

# Définir un nouveau mot de passe de manière interactive
wp user update administrateur --prompt=user_pass

# Vérifier le compte après la réinitialisation
wp user get administrateur --fields=ID,user_login,user_email

Si vous n’avez ni accès à l’e-mail ni accès à SSH, demandez à l’hébergeur une procédure sécurisée ou utilisez phpMyAdmin avec une sauvegarde préalable. Ne remplacez pas aveuglément le champ user_pass par une valeur inventée. Une mauvaise manipulation de la base peut verrouiller le compte ou endommager d’autres données.

wp-admin renvoie une erreur 404

Une erreur 404 sur /wp-admin/ signifie que l’URL demandée n’est pas résolue comme prévu. Vérifiez d’abord que WordPress est installé à cette adresse et que vous n’avez pas oublié un sous-répertoire. Si la page d’accueil fonctionne mais que les chemins internes sont cassés, les règles de réécriture ou les permaliens sont les premiers suspects.

Si vous avez encore accès à l’administration, ouvrez Réglages, Permaliens, puis cliquez sur « Enregistrer les modifications » sans changer le réglage. WordPress régénère ses règles. Si wp-admin est totalement inaccessible, faites une sauvegarde du fichier .htaccess avant de le renommer temporairement, puis testez à nouveau.

# Sauvegarder puis renommer le fichier depuis le dossier WordPress
cp .htaccess .htaccess.bak
mv .htaccess .htaccess.test

# Rétablir le fichier si le test ne change rien
mv .htaccess.test .htaccess

Sur Apache, le module de réécriture et l’autorisation AllowOverride doivent être actifs. Sur Nginx, le fichier .htaccess n’est pas utilisé et la correction relève de la configuration du serveur. Une extension de sécurité qui change l’URL de connexion peut aussi renvoyer une 404 volontairement. Consultez alors sa documentation et son réglage de chemin personnalisé.

Erreur 403 ou accès interdit à wp-admin

Une erreur 403 indique que le serveur comprend la demande mais refuse de la servir. Les causes courantes sont une règle .htaccess, un pare-feu applicatif, une restriction d’adresse IP, des permissions incorrectes ou un plugin de sécurité. Comparez le moment d’apparition de l’erreur avec la dernière modification effectuée.

Ne rendez pas tout le serveur accessible avec des permissions en 777. Les dossiers WordPress sont généralement en 755 et les fichiers en 644, mais le réglage exact dépend de l’utilisateur PHP et de l’hébergement. Si un WAF bloque votre adresse, consultez ses journaux et autorisez uniquement l’action légitime. Une restriction sur admin-ajax.php peut aussi casser le front-end, car ce point d’entrée sert de nombreux formulaires.

Pour isoler un plugin sans entrer dans wp-admin, renommez uniquement son dossier avec SFTP ou le gestionnaire de fichiers, puis testez. Faites une sauvegarde et restaurez le nom dès que le diagnostic est terminé. Si le blocage disparaît, réactivez les extensions une par une afin d’identifier la cause.

# Depuis le dossier wp-content/plugins
mv extension-suspecte extension-suspecte.off

# Après le test, restaurer le nom attendu par WordPress
mv extension-suspecte.off extension-suspecte

Boucle de connexion et cookies refusés

C’est le symptôme qui génère le plus de recherches et le moins de descriptions utiles. Sur les 83 requêtes Google qui ont affiché ce guide entre le 1er juin et le 23 août 2026, soit 567 impressions, 29 viennent de « wp-admin ne fonctionne pas » et « wordpress connexion admin impossible ». Aucune ne mentionne un cookie, un proxy ou HTTPS : la personne décrit ce qu’elle voit, jamais la cause. L’assistant du site a reçu la même question dès ses premiers jours, « Impossible de me connecter à l’admin WordPress ». Ce chapitre part donc du symptôme et remonte à la cause, dans l’ordre où je les rencontre réellement.

Dans les installations que j’administre, l’ordre de fréquence est stable : d’abord un écart entre l’URL réellement servie et les options home et siteurl, en HTTPS ou en www ; ensuite un cache ou un CDN qui sert la page de connexion ou avale le cookie ; enfin un cookie refusé par le navigateur ou un COOKIE_DOMAIN hérité d’une migration. Le reste est rare et se voit dès la première commande.

Ce que renvoie réellement /wp-admin/ : test du 11 septembre 2026

Avant de toucher à la base ou à wp-config.php, je lis les redirections depuis un terminal, jamais depuis le navigateur. Le navigateur garde les 301 en cache et affiche un résultat déjà pollué par la tentative précédente. Voici ce que renvoie notre propre installation, sans session ouverte, pour trois façons d’écrire l’adresse :

$ curl -sI https://wpadminlab.com/wp-admin/
HTTP/2 302
location: https://wpadminlab.com/wp-login.php?redirect_to=https%3A%2F%2Fwpadminlab.com%2Fwp-admin%2F&reauth=1
x-redirect-by: WordPress

$ curl -sI http://wpadminlab.com/wp-admin/
HTTP/1.1 302 Found
location: https://wpadminlab.com/wp-admin/
x-redirect-by: WordPress

$ curl -sI https://www.wpadminlab.com/wp-admin/
HTTP/2 302
location: https://wpadminlab.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.wpadminlab.com%2Fwp-admin%2F&reauth=1
x-redirect-by: WordPress

Deux redirections avant le formulaire, c’est normal. La première ramène en HTTPS, la seconde envoie vers wp-login.php avec reauth=1, ce qui signifie simplement que WordPress n’a trouvé aucun cookie de session. L’en-tête x-redirect-by: WordPress dit qui a décidé la redirection. Tapez la même adresse sans le slash final et vous obtenez un 301 sans cet en-tête : celui-là vient du serveur web, pas de WordPress. Ce détail indique où chercher. Une boucle, c’est quand la réponse suivante ramène à la première adresse ; le navigateur finit par afficher ERR_TOO_MANY_REDIRECTS ou « Les cookies sont bloqués ou ne sont pas pris en charge par votre navigateur ».

Lire la boucle : trois signatures

La commande à lancer est curl -sI -L --max-redirs 5 https://votre-domaine.fr/wp-admin/. Elle s’arrête au bout de cinq sauts, ce qui suffit pour voir le motif se répéter.

Ce que montre curl	Cause réelle	Correctif
http et https alternent	WordPress reçoit du http derrière un proxy ou un CDN alors que siteurl est en https	Déclarer HTTP_X_FORWARDED_PROTO dans wp-config.php
www et domaine nu alternent	home et siteurl imposent un hôte, une règle serveur impose l’autre	Aligner les deux options sur la règle serveur, puis purger les caches
wp-login.php renvoie vers wp-admin, qui renvoie vers wp-login.php avec reauth=1	Le cookie de session n’est jamais conservé	Purger le cache de page, contrôler COOKIE_DOMAIN, tester en navigation privée

Pour la deuxième signature, la correction se fait sur les deux options, après avoir confirmé quelle version le serveur impose :

# Lire les deux URLs
wp option get home
wp option get siteurl

# Exemple de correction, à adapter à votre domaine
wp option update home 'https://votre-domaine.fr'
wp option update siteurl 'https://votre-domaine.fr'

Cas HTTPS : le proxy qui parle en http à WordPress

C’est la boucle la plus fréquente depuis que tout le monde place un CDN ou un reverse proxy devant PHP. Le visiteur est en HTTPS, le proxy termine le chiffrement et transmet la requête en http au serveur d’origine. WordPress compare avec siteurl en https, conclut que la connexion n’est pas sécurisée et redirige vers https. Le proxy renvoie du http, et ainsi de suite. Le correctif tient en trois lignes, à placer dans wp-config.php avant la ligne « C’est tout, ne touchez plus à rien » :

// Faire confiance à l'en-tête posé par le proxy ou le CDN
if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Ajoutez ce bloc uniquement si votre hébergeur ou votre CDN pose réellement cet en-tête, sinon vous acceptez une requête qui se déclare en https sans l’être. Mon avis : je ne définis jamais FORCE_SSL_ADMIN tant que home et siteurl ne sont pas tous les deux en https et que la boucle n’est pas résolue. Cette constante force la redirection, elle ne corrige rien, et sur un proxy non déclaré elle transforme un simple avertissement en boucle. Sur un mutualisé comme o2switch, le chiffrement est en règle générale terminé sur le serveur lui-même, WordPress voit déjà du https et ce bloc n’a aucun effet : si vous bouclez là, cherchez du côté de siteurl ou d’une règle de réécriture.

Cas cookies : le test que fait wp-login.php

À l’ouverture du formulaire, WordPress dépose un cookie nommé wordpress_test_cookie. À la soumission, il vérifie que ce cookie est revenu. S’il manque, vous obtenez le message sur les cookies bloqués, même avec le bon mot de passe. Le cookie de session posé ensuite, wordpress_logged_in_ suivi d’une empreinte, obéit aux mêmes règles : il est limité à l’hôte et au chemin calculés par WordPress. Trois raisons pour qu’il ne revienne jamais :

• Un cache de page, un CDN ou une règle LiteSpeed Cache sert wp-login.php depuis le cache et supprime l’en-tête Set-Cookie. Vérifiez avec curl -sI https://votre-domaine.fr/wp-login.php : sans ligne set-cookie: wordpress_test_cookie, cherchez le cache, pas le navigateur.
• Une constante COOKIE_DOMAIN définie pour un autre hôte, souvent oubliée après une migration ou une copie de préproduction. Le navigateur refuse un cookie pour un domaine qui n’est pas celui de la page.
• Le navigateur lui-même : cookies tiers bloqués quand l’administration est ouverte dans une iframe, extension de confidentialité, profil corrompu. Une fenêtre privée sans extension tranche la question en dix secondes.

Dans wp-config.php, la ligne fautive ressemble à define('COOKIE_DOMAIN', 'www.ancien-domaine.fr');. Supprimez-la plutôt que de la corriger : WordPress calcule la bonne valeur tout seul quand la constante est absente.

Cas sous-domaine et sous-répertoire

Un WordPress installé sur blog.votre-domaine.fr pose ses cookies sur cet hôte uniquement, ce qui est correct. Les ennuis commencent quand une règle serveur ou une extension redirige vers votre-domaine.fr, ou l’inverse : le cookie posé sur l’un n’est jamais présenté à l’autre et la session semble disparaître. Même logique avec www : un cookie déposé sur wpadminlab.com n’est pas envoyé à www.wpadminlab.com. Dans le test ci-dessus, WordPress garde l’hôte www dans redirect_to tout en envoyant le formulaire sur le domaine nu ; après connexion, la fonction wp_safe_redirect refuse cette destination étrangère et retombe sur le tableau de bord du bon hôte, ce qui évite la boucle. Ce garde-fou n’existe pas côté serveur : une règle .htaccess qui contredit siteurl bouclera sans fin.

Pour un WordPress dans un sous-répertoire, l’adresse d’administration suit siteurl, pas home : avec siteurl sur https://votre-domaine.fr/wp et home sur https://votre-domaine.fr, le tableau de bord est sur /wp/wp-admin/, et taper /wp-admin/ renvoie un 404, pas une boucle. En multisite avec sous-domaines, ne définissez jamais COOKIE_DOMAIN à la main : le réseau calcule le domaine des cookies lui-même.

Après toute correction de home, de siteurl ou de wp-config.php, purgez le cache de page et celui du CDN avant de retester, sinon vous diagnostiquez l’ancienne configuration. Pour les lenteurs du back-office qui ressemblent à une boucle sans en être une, consultez notre guide du back office WordPress lent.

Page blanche ou erreur critique après connexion

Une page blanche dans wp-admin signale souvent une erreur PHP fatale provoquée par une extension, le thème ou une incompatibilité de version. Activez temporairement le journal WordPress avec l’affichage désactivé, reproduisez le problème une seule fois, puis consultez wp-content/debug.log. Le nom du fichier et le numéro de ligne donnent un premier axe d’enquête.

Désactivez l’extension mentionnée dans la trace, testez à nouveau, puis réinstallez une version officielle compatible. Si aucune extension n’est responsable, activez temporairement un thème natif installé. Pour un parcours complet, notre guide explique comment corriger une erreur critique WordPress sans perdre le contenu du site.

# Diagnostic rapide avec WP-CLI
wp plugin list --status=active
wp theme list --status=active
wp core verify-checksums

# Vérifier la syntaxe d’un fichier PHP modifié
php -l wp-content/themes/mon-theme/functions.php

Après le diagnostic, désactivez le mode debug public, supprimez les traces sensibles et purgez le cache. Ne modifiez pas directement un plugin tiers si une mise à jour existe, car votre correction serait écrasée lors du prochain déploiement.

Sécuriser la connexion à wp-admin

L’URL standard n’est pas un secret et la masquer ne remplace pas une authentification solide. Utilisez un mot de passe unique, activez la double authentification pour les comptes privilégiés et limitez les tentatives répétées au niveau de l’hébergeur ou du pare-feu. Supprimez les comptes Administrateur inutilisés et donnez à chaque personne le rôle minimal nécessaire.

Pour mesurer ce que subit réellement cette page, nous avons analysé un mois de journaux serveur : wp-login.php, 31 jours d’attaques réelles et ce qui les bloque.

Changer l’URL de connexion peut réduire le bruit des robots, mais faites-le avec une méthode réversible et documentée. N’ajoutez pas une règle serveur qui bloque votre propre adresse sans prévoir un accès de secours. Notre tutoriel détaille comment changer l’URL de wp-admin sans plugin.

Conservez le cœur, le thème et les extensions à jour, sauvegardez avant une mise à niveau et surveillez les connexions inhabituelles. La double authentification protège même si un mot de passe fuit, tandis qu’une sauvegarde testée permet de revenir à un état sain. Vous pouvez compléter cette base avec notre guide sur l’authentification multi-facteurs WordPress.

# Contrôles utiles avant une mise à jour
wp core check-update
wp plugin update --all --dry-run
wp user list --role=administrator

Que peut-on faire depuis le tableau de bord

Le tableau de bord centralise les tâches quotidiennes. Articles et Pages servent au contenu éditorial, Médias gère les fichiers, Apparence contrôle le thème, Extensions gère les plugins et Réglages contient les paramètres du site. Outils donne accès à l’état de santé, aux importations et exportations, ainsi qu’à certaines fonctions de confidentialité.

Avant de modifier un réglage sensible, notez sa valeur et faites une sauvegarde. Les permaliens, l’adresse du site, les extensions de cache et les réglages de sécurité peuvent rendre plusieurs pages indisponibles en une seule action. Travaillez de préférence sur une copie de test pour les changements importants.

FAQ sur wp-admin

Quelle est l’URL de wp-admin WordPress ?

L’URL par défaut est https://votre-domaine.fr/wp-admin/. Elle redirige vers /wp-login.php si vous n’êtes pas connecté. Ajoutez le sous-répertoire éventuel, par exemple /blog/wp-admin/.

Comment accéder à wp-admin sans connaître le mot de passe ?

Vous ne devez pas contourner l’authentification. Utilisez « Mot de passe oublié ? », demandez une réinitialisation à l’administrateur ou passez par une procédure vérifiée de l’hébergeur, WP-CLI ou phpMyAdmin avec sauvegarde.

Pourquoi wp-admin affiche-t-il une erreur 404 ?

Vérifiez l’URL d’installation, les permaliens, les règles de réécriture et une éventuelle extension qui a modifié le chemin de connexion. Sur Apache, régénérez prudemment les règles après avoir sauvegardé .htaccess.

Pourquoi la connexion wp-admin tourne-t-elle en boucle ?

Suivez les redirections avec curl -sI -L : http et https qui alternent désignent un proxy non déclaré, www et domaine nu qui alternent désignent un conflit entre siteurl et une règle serveur, un retour vers wp-login.php avec reauth=1 désigne un cookie jamais conservé. Chaque cas a son correctif dans la section sur la boucle de connexion ci-dessus.

Que signifie « Les cookies sont bloqués ou ne sont pas pris en charge par votre navigateur » ?

WordPress dépose un cookie de test à l’ouverture du formulaire et exige de le retrouver à la soumission. Le message apparaît quand il manque : cache ou CDN qui sert wp-login.php sans en-tête Set-Cookie, constante COOKIE_DOMAIN héritée d’une migration, ou navigateur qui refuse les cookies. Testez en navigation privée, puis contrôlez la réponse de wp-login.php avec curl.

Sources

Documentation WordPress sur les écrans d’administration, WordPress.org sur la réinitialisation du mot de passe, WP-CLI, commande user update, WordPress Developer, déboguer WordPress, WordPress Developer, renforcer la sécurité, OWASP, bonnes pratiques d’authentification.

Si l’administration reste inaccessible avec un code 503, utilisez notre méthode de diagnostic de WordPress erreur 503 avant de réinitialiser les identifiants.

Vous hésitez encore sur la plateforme ? Notre comparatif WordPress ou Webflow vous aide à trancher.

Besoin d’un fichier propre ? Utilisez notre générateur de .htaccess en quelques clics.

Nous détaillons ce point dans notre analyse sur À propos de WP Admin Lab.

Diagnostic rapide : que faire quand wp-admin ne répond pas

Symptôme	Cause la plus fréquente	Solution en 1 ligne
Page blanche après connexion	Plugin ou mémoire PHP insuffisante	Ajouter define('WP_MEMORY_LIMIT', '256M') dans wp-config.php
Boucle de redirection infinie	siteurl ou home en désaccord avec le proxy ou la règle serveur	Suivre les redirections avec curl, puis corriger les deux options ou déclarer HTTP_X_FORWARDED_PROTO
Erreur 403 Forbidden	Règle .htaccess ou permission de dossier	Réinitialiser le .htaccess WordPress par défaut
Erreur 500 après mise à jour	Plugin ou thème incompatible	Renommer le dossier /wp-content/plugins/ en FTP
Identifiants refusés alors qu’ils sont corrects	Cache de navigateur ou cookie corrompu	Vider le cache et utiliser une session privée
URL wp-admin redirige vers une page inconnue	Malware ou changement d’URL dans la base	Vérifier siteurl en base et scanner le site