Changer l'url de wp-admin sans plugin

Q: Méthode 3 : mu-plugin pour masquer la page de connexion

Les deux méthodes précédentes bloquent l'accès à wp-admin mais ne changent pas l'URL de connexion. Si vous souhaitez que /wp-login.php renvoie une erreur 404 et que la connexion se fasse depuis une URL personnalisée (par exemple /connexion-prive/), vous avez besoin d'un mu-plugin.

Changer l’url de wp-admin sans plugin se fait par deux approches complémentaires : bloquer l’accès direct à /wp-admin/ et /wp-login.php via le fichier .htaccess (restriction par IP ou authentification HTTP Basic), ou masquer la page de connexion avec un mu-plugin PHP qui filtre les hooks login_url et admin_url. Ces méthodes ne nécessitent aucun plugin WordPress et survivent aux mises à jour du cœur. Ce guide couvre les quatre méthodes dans l’ordre du plus simple au plus avancé, avec les blocs de code prêts à copier et coller.

Le répertoire /wp-admin/ est utilisé par des centaines de bots automatisés chaque jour pour des tentatives de brute-force sur la page de connexion WordPress. Selon les données de Wordfence, plus de 90 000 attaques par minute ciblent les installations WordPress à l’échelle mondiale. Masquer ou restreindre l’URL d’administration est la contre-mesure la plus efficace avant même d’envisager un pare-feu applicatif.

Pourquoi changer l’URL de wp-admin est une priorité de sécurité

WordPress installe par défaut deux points d’entrée connus de tout bot : /wp-login.php (formulaire de connexion) et /wp-admin/ (redirection vers le formulaire pour les utilisateurs non connectés). Ces adresses sont identiques sur les 800 millions de sites WordPress dans le monde. Un attaquant n’a pas besoin de découvrir votre URL de connexion : il la connaît d’avance.

Les conséquences d’une page de connexion exposée sont multiples. Les attaques par dictionnaire et par force brute consomment des ressources serveur, ralentissent le site et peuvent aboutir à une compromission totale si le mot de passe est faible. Les journaux d’accès d’un site WordPress standard montrent en moyenne 200 à 500 tentatives de connexion infructueuses par heure, sans aucune protection particulière.

Changer ou masquer l’URL de wp-admin sans plugin présente un avantage supplémentaire : aucun plugin n’est en mesure de désactiver la protection en cas de mise à jour conflictuelle. Le code que vous placez dans le fichier .htaccess, dans wp-config.php ou dans un mu-plugin (must-use plugin) reste actif indépendamment de l’état des extensions installées.

Méthode 1 : restriction par adresse IP dans .htaccess (Apache)

La méthode la plus rapide et la plus robuste consiste à bloquer /wp-admin/ pour tout le monde sauf votre adresse IP. Cette configuration Apache ne nécessite aucune modification de PHP et s’applique au niveau du serveur web, avant même que WordPress ne soit chargé.

Ouvrez le fichier .htaccess à la racine de votre site WordPress (via FTP ou le gestionnaire de fichiers cPanel) et ajoutez ce bloc avant les règles WordPress existantes :

# Protection de wp-admin par IP
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-admin [NC]
RewriteCond %{REMOTE_ADDR} !^123.456.789.0$
RewriteRule ^ - [F,L]
</IfModule>

# Bloquer aussi wp-login.php depuis les IPs non autorisées
<FilesMatch "^wp-login.php$">
    Order deny,allow
    Deny from all
    Allow from 123.456.789.0
</FilesMatch>

Remplacez 123.456.789.0 par votre adresse IP publique réelle. Pour la connaître, rendez-vous sur ifconfig.me. Si votre IP change régulièrement (ADSL, VDSL sans IP fixe), ajoutez plusieurs lignes Allow from ou passez à la méthode HTTP Basic Auth décrite ci-dessous.

Pour vérifier que la protection fonctionne, accédez à https://votresite.com/wp-admin/ depuis un autre réseau (partage de connexion mobile par exemple) : vous devez obtenir une erreur 403 Forbidden.

Méthode 2 : double verrou avec HTTP Basic Authentication

Si votre IP n’est pas fixe, l’authentification HTTP Basic ajoute un second formulaire de connexion devant wp-admin, indépendant de WordPress. Un attaquant doit alors franchir deux barrières : le formulaire HTTP Basic et le formulaire WordPress. Les bots automatisés abandonnent au premier obstacle.

Créez d’abord le fichier .htpasswd avec la commande Apache htpasswd (disponible sur tous les hébergeurs cPanel) :

# Générer le fichier .htpasswd (à exécuter depuis SSH ou via un outil en ligne)
htpasswd -c /home/wami5543/.htpasswd adminwpal
# Entrez et confirmez le mot de passe quand il est demandé

# Vérifier que le fichier contient bien une ligne hash
cat /home/wami5543/.htpasswd
# adminwpal:$apr1$xyz...$hashcomplet

Ensuite, ajoutez ce bloc dans le fichier .htaccess du répertoire /wp-admin/ (créez-en un spécifique à ce répertoire, pas celui de la racine) :

# /wp-admin/.htaccess
AuthType Basic
AuthName "Zone privée"
AuthUserFile /home/wami5543/.htpasswd
Require valid-user

# Autoriser les requêtes AJAX WordPress (admin-ajax.php doit rester accessible)
<Files admin-ajax.php>
    Satisfy Any
    Allow from all
</Files>

La ligne Satisfy Any pour admin-ajax.php est indispensable : les fonctionnalités AJAX de votre thème et de vos plugins appellent cet endpoint sans session HTTP Basic. Sans cette exception, des erreurs JavaScript apparaîtront dans le frontend.

Méthode 3 : mu-plugin pour masquer la page de connexion

Les deux méthodes précédentes bloquent l’accès à wp-admin mais ne changent pas l’URL de connexion. Si vous souhaitez que /wp-login.php renvoie une erreur 404 et que la connexion se fasse depuis une URL personnalisée (par exemple /connexion-prive/), vous avez besoin d’un mu-plugin.

Les must-use plugins (répertoire wp-content/mu-plugins/) sont chargés automatiquement par WordPress avant tous les plugins ordinaires, ne peuvent pas être désactivés depuis l’interface d’administration et survivent à toutes les mises à jour. C’est l’endroit idéal pour placer du code de sécurité critique.

Créez le fichier wp-content/mu-plugins/custom-login-url.php avec le contenu suivant :

<?php
/**
 * Masquer wp-login.php et wp-admin, rediriger vers une URL personnalisée
 */

define( 'CUSTOM_LOGIN_SLUG', 'connexion-prive' );

// Filtrer l'URL de connexion retournée par WordPress
add_filter( 'login_url', 'wpal_custom_login_url', 10, 3 );
function wpal_custom_login_url( $login_url, $redirect, $force_reauth ) {
    $base = trailingslashit( home_url() );
    if ( $redirect ) {
        return $base . CUSTOM_LOGIN_SLUG . '/?redirect_to=' . urlencode( $redirect );
    }
    return $base . CUSTOM_LOGIN_SLUG . '/';
}

// Bloquer l'accès direct à wp-login.php pour les utilisateurs non connectés
add_action( 'init', 'wpal_block_direct_login' );
function wpal_block_direct_login() {
    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? $_SERVER['REQUEST_URI'] : '';
    $is_login    = strpos( $request_uri, 'wp-login.php' ) !== false;
    $is_admin    = strpos( $request_uri, '/wp-admin' ) !== false;
    $is_ajax     = defined( 'DOING_AJAX' ) && DOING_AJAX;
    $is_cron     = defined( 'DOING_CRON' ) && DOING_CRON;
    $is_cli      = defined( 'WP_CLI' ) && WP_CLI;

    if ( ( $is_login || $is_admin ) && ! is_user_logged_in() && ! $is_ajax && ! $is_cron && ! $is_cli ) {
        // Récupérer le slug personnalisé depuis l'URL entrante
        if ( strpos( $request_uri, CUSTOM_LOGIN_SLUG ) === false ) {
            wp_redirect( home_url( '/' ), 302 );
            exit;
        }
    }
}

// Intercepter le slug personnalisé et charger wp-login.php
add_action( 'parse_request', 'wpal_handle_custom_login_slug' );
function wpal_handle_custom_login_slug( $wp ) {
    $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? $_SERVER['REQUEST_URI'] : '';
    if ( strpos( $request_uri, CUSTOM_LOGIN_SLUG ) !== false ) {
        require_once ABSPATH . 'wp-login.php';
        exit;
    }
}

Uploadez ce fichier via FTP dans /wp-content/mu-plugins/. Créez le répertoire s’il n’existe pas. Après l’upload, la page de connexion WordPress est désormais accessible uniquement depuis https://votresite.com/connexion-prive/. L’ancienne URL /wp-login.php redirige vers la page d’accueil avec un code 302.

Modifiez la constante CUSTOM_LOGIN_SLUG pour définir votre propre slug. Choisissez quelque chose d’imprévisible : évitez connexion, login, admin ou signin que les bots testent systématiquement.

Méthode 4 : configuration Nginx pour restreindre wp-admin

Si votre hébergement utilise Nginx au lieu d’Apache (ou en combinaison avec Apache via un proxy inverse), les fichiers .htaccess ne s’appliquent pas. La restriction s’effectue dans le fichier de configuration du virtual host, généralement dans /etc/nginx/sites-available/votresite.conf :

# Restriction de wp-admin et wp-login.php par IP dans Nginx
location ~* ^/(wp-admin|wp-login.php) {
    # Remplacer par votre IP réelle
    allow 123.456.789.0;
    deny  all;

    # Continuer le traitement normal pour les requêtes autorisées
    try_files $uri $uri/ /index.php?$args;

    # Paramètres PHP (adapter au pool PHP-FPM)
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

# Autoriser admin-ajax.php sans restriction IP
location = /wp-admin/admin-ajax.php {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Après modification, testez la configuration avant de la recharger :

nginx -t && systemctl reload nginx

Les hébergements mutualisés (o2switch, PlanetHoster, OVH mutualisé) utilisent Apache avec modules mod_rewrite et mod_authn_file activés par défaut. La méthode .htaccess s’applique dans la quasi-totalité de ces cas. Nginx est plus courant sur les VPS et les serveurs dédiés gérés manuellement.

Changer l’URL de wp-admin après une migration WordPress

Une migration de domaine ou de serveur peut invalider les règles de protection wp-admin, en particulier si les chemins absolus ont changé. Voici les points à vérifier après une migration :

Pour la méthode .htpasswd, le chemin dans la directive AuthUserFile est absolu et doit être mis à jour. Connectez-vous en SSH et obtenez le nouveau chemin avec la commande pwd depuis la racine cPanel, puis mettez à jour le fichier /wp-admin/.htaccess en conséquence.

Pour le mu-plugin, vérifiez que le répertoire wp-content/mu-plugins/ a bien été transféré. Certains outils de migration (Duplicator, All-in-One WP Migration) omettent ce répertoire par défaut. Vérifiez également que la constante CUSTOM_LOGIN_SLUG ne entre pas en conflit avec un slug de page ou de catégorie existant dans la nouvelle installation.

Si vous avez modifié WP_SITEURL ou WP_HOME dans wp-config.php pour la migration, les URLs générées par home_url() dans le mu-plugin refléteront automatiquement les nouvelles valeurs. Aucun ajustement n’est nécessaire de ce côté. Pour en savoir plus sur les erreurs fréquentes lors d’une migration, consultez notre guide sur l’erreur de connexion à la base de données WordPress.

Récupérer l’accès si on est bloqué hors de wp-admin

C’est le risque principal de ces méthodes : vous pouvez vous enfermer hors de votre propre administration. La procédure de récupération dépend de la méthode utilisée.

Si vous avez utilisé .htaccess, connectez-vous via FTP ou le gestionnaire de fichiers cPanel et ouvrez le fichier .htaccess de la racine (ou du répertoire /wp-admin/). Supprimez ou commentez le bloc de restriction, enregistrez, puis accédez à nouveau à /wp-admin/. Votre adresse IP a peut-être changé (déconnexion FAI, bascule 4G) : c’est la cause la plus fréquente de blocage involontaire.

Si vous avez utilisé le mu-plugin et oublié votre slug personnalisé, connectez-vous via FTP et renommez ou supprimez le fichier wp-content/mu-plugins/custom-login-url.php. WordPress cessera immédiatement de charger ce code et l’URL standard /wp-login.php redeviendra accessible. Aucun rechargement de service n’est nécessaire.

Si vous êtes bloqué par la HTTP Basic Auth (mot de passe oublié), supprimez le fichier /wp-admin/.htaccess via FTP. Vous pourrez ensuite vous reconnecter et recréer le mot de passe avec la commande htpasswd.

Pour éviter ce type de situation, testez toujours votre règle de protection depuis un autre onglet de navigateur ou un autre appareil avant de fermer votre session WordPress active. Les erreurs de configuration .htaccess peuvent aussi provoquer une erreur critique WordPress si la syntaxe Apache est incorrecte. Consultez les logs d’erreur Apache (disponibles dans cPanel sous Métriques) pour diagnostiquer rapidement.

Combiner les méthodes : la configuration recommandée en 2026

Les quatre méthodes ne sont pas mutuellement exclusives. La configuration la plus solide combine restriction IP (.htaccess ou Nginx), HTTP Basic Auth et filtre de l’URL de connexion via mu-plugin. Voici l’ordre recommandé pour un site WordPress en production :

Étape 1 : activez la restriction IP dans .htaccess ou Nginx pour bloquer les bots au niveau serveur. C’est le filtre le moins coûteux en ressources (aucun PHP n’est chargé).

Étape 2 : ajoutez l’authentification HTTP Basic sur /wp-admin/ pour couvrir les cas de connexion depuis une IP différente (déplacement, télétravail) tout en maintenant une barrière supplémentaire.

Étape 3 : déployez le mu-plugin pour masquer /wp-login.php avec un slug imprévisible. Cette couche protège également contre les scanners qui contournent les restrictions IP via des proxies.

Cette combinaison réduit à zéro les tentatives de brute-force visibles dans les logs, sans aucun impact sur la performance WordPress : le code PHP n’est chargé que pour les requêtes légitimes. Pour aller plus loin sur la sécurisation de WordPress, consultez notre guide complet WAF, headers de sécurité et CSP WordPress et notre article sur vider le cache WordPress sans plugin pour maîtriser votre environnement serveur sans dépendances tierces.

Sources et références

FAQ : changer l’url de wp-admin sans plugin

Est-il possible de changer wp-admin en une autre URL sans toucher au code PHP ?

Oui, via le fichier .htaccess uniquement. Une règle RewriteRule peut rediriger toutes les requêtes vers /wp-admin/ vers une URL 404 ou la page d’accueil pour les visiteurs non autorisés. Cependant, sans modification PHP, WordPress continuera à générer des liens internes pointant vers /wp-admin/ dans les emails de notification et les pages de connexion. Le mu-plugin est nécessaire pour une redirection complète de l’URL.

La restriction par IP dans .htaccess bloque-t-elle aussi les requêtes AJAX ?

Si la restriction porte sur tout le répertoire /wp-admin/, oui, elle bloque aussi admin-ajax.php. C’est problématique car de nombreux plugins et thèmes utilisent cet endpoint pour des fonctionnalités frontend (recherche, formulaires, paniers WooCommerce). Ajoutez toujours une exception explicite pour admin-ajax.php dans votre règle .htaccess ou Nginx, comme montré dans les exemples ci-dessus.

Le mu-plugin est-il désactivé si je désactive tous les plugins depuis wp-admin ?

Non. Les must-use plugins (dossier wp-content/mu-plugins/) ne peuvent pas être désactivés depuis l’interface d’administration WordPress. Ils n’apparaissent pas dans la liste des plugins désactivables. La seule façon de les désactiver est de supprimer ou renommer le fichier directement sur le serveur via FTP ou SSH.

Mon hébergeur utilise Nginx en frontal et Apache en backend : quelle méthode choisir ?

Dans une configuration Nginx devant Apache (courante sur les hébergements mutualisés modernes), les règles .htaccess sont lues par Apache mais pas par Nginx. Si Nginx gère les requêtes statiques et ne passe à Apache que les requêtes PHP, vos règles .htaccess s’appliquent correctement pour PHP, y compris pour wp-login.php et /wp-admin/. Vérifiez auprès de votre hébergeur si Nginx lit ou ignore les fichiers .htaccess (sur o2switch, Apache est le serveur web principal : .htaccess est pleinement actif).