Changer l'URL d'administration WordPress (wp-admin / wp-login.php) est un classique des plugins de sécurité. L'intérêt est réel : moins de tentatives sur l'adresse par défaut, moins de charge, moins de faux positifs dans les logs. La limite l'est aussi : un attaquant ciblé trouvera la nouvelle URL, et une mauvaise manip vous enferme dehors. Cet article pose l'intérêt, les méthodes, les pièges (WooCommerce, prestataires, apps), et comment combiner ce geste avec la 2FA et la coupure de XML-RPC.
🔎 Ce que changer l'URL d'admin apporte vraiment
Les bots tapent /wp-login.php et /wp-admin/ en continu. Déplacer le login fait chuter ce trafic d'un cran. Sur un petit hébergement, la différence de charge se voit. Dans les logs, on respire. C'est de la réduction de surface opportuniste, pas de la confidentialité militaire.
Ça n'empêche pas une attaque ciblée, une faille de plugin, un XSS qui vole une session. Présentez le geste pour ce qu'il est : un filtre à bots, un confort de TMA. Pas « notre WordPress est devenu introuvable ».
🛠️ Ce que ça n'apporte pas
Un mot de passe admin faible reste faible. Sans 2FA, la nouvelle URL est juste un secret de plus, souvent écrit dans le même pad que le mot de passe. Les extensions malveillantes n'ont pas besoin de wp-login. La sécurité par l'obscurité seule est un slogan, pas une TMA.
Je refuse de vendre le changement d'URL comme pièce unique d'un « pack sécurité ». Je l'ajoute après comptes revus, 2FA, XML-RPC. Dans cet ordre. Sinon le client croit qu'il a fini.
✅ Méthodes : plugin, constantes, serveur
La voie la plus courante est un plugin tenu qui réécrit le slug de login. Simple, réversible, parfois trop magique (on oublie le slug). La voie serveur (restriction IP sur /wp-admin, autre vhost) est plus solide pour une équipe fixe, moins pour une TMA nomade.
On évite les snippets obscurs copiés d'un blog 2014 qui cassent au prochain core. On teste en préprod. On écrit le nouvel URL dans le coffre de l'équipe, pas dans un e-mail « tiens c'est devenu /espace-prive-92/ ».
⚠️ Lockout : le risque réel
Mal configuré, vous perdez l'admin. Le plugin se désactive mal, le cache sert encore l'ancienne règle, WooCommerce a une page mon-compte qui se mélange. Avant de toucher la prod : préprod, compte de secours, accès SFTP / WP-CLI pour désactiver le plugin les yeux fermés.
Documentez la procédure de rollback en dix lignes. Le jour où ça arrive, ce n'est pas l'heure d'poser une question sur Stack Overflow. C'est l'heure de suivre la page.
- Préprod d'abord, puis prod
- WP-CLI ou SFTP pour désactiver le plugin de slug
- Nouveau chemin dans le coffre équipe, pas seulement dans la tête du prestataire
- Cache et CDN à vider, sinon l'ancien login « marche encore » par moments
📌 WooCommerce, prestataires, apps
Les clients boutique se connectent souvent via /mon-compte/, pas via wp-admin. Vérifier que changer le login admin ne casse pas l'espace client. Les prestataires (ads, SEO, comptable qui « entre dans WordPress ») doivent recevoir le nouveau chemin et un compte à leur rôle, pas admin.
Les apps et certains outils de publication tapent wp-login. On les prévient. On les teste. On ne découvre pas trois semaines plus tard qu'une routine de planning est morte.
🧭 Restreindre plutôt que cacher, parfois
Pour une équipe aux IPs stables, limiter /wp-admin au bureau et au VPN est plus fort qu'un slug secret. Pour une TMA et un gérant en déplacement, c'est trop raide. On choisit selon les gens, pas selon le plugin à la mode.
HTTP auth devant wp-login en plus de WordPress est un second facteur pauvre mais efficace contre les bots. Combinable avec un slug custom. Attention aux mots de passe HTTP oubliés dans un wiki public.
💡 Après le changement : habitudes
Favoris mis à jour. Documentation interne. Monitoring : on s'attend à voir monter les 404 sur /wp-login.php. Si le bruit reste identique, le cache ou le plugin n'a rien fait. On vérifie.
On ne change pas le slug tous les mois « pour plus de sécu ». Chaque changement est un risque de blocage et de prestataire perdu. On le fait une fois, on le documente, on passe à la 2FA si ce n'est pas déjà fait.
🧪 Place dans le pack de durcissement
URL d'admin custom + XML-RPC off + 2FA + moins de comptes admin : voilà une base que je peux défendre. URL custom seule : un confort. Si vous n'avez qu'une heure, je pose la 2FA avant le slug. Si vous avez une demi-journée, je pose les quatre.
Ensuite la TMA continue : mises à jour, préprod, monitoring. L'URL neuve n'exempte de rien. Elle fait seulement taire une partie du bruit pour qu'on entende les vraies alertes.
🔎 Communiquer le nouveau chemin sans le publier
L'URL d'admin n'est pas un secret d'État, mais ce n'est pas non plus un slug à mettre en footer. On la range dans le coffre, dans le mail interne chiffré ou le gestionnaire, pas dans la documentation publique du site, pas dans un ticket Zendesk indexé. Les prestataires ponctuels la reçoivent le temps de la mission, puis on la change si le prestataire était trop large.
Changer l'URL d'admin WordPress trop souvent pour « plus de sécu » fatigue et blocage. Une fois, bien, documenté. Ensuite on passe à ce qui compte : 2FA et mots de passe.
🛠️ Ce que disent les logs après deux semaines
Les 404 sur /wp-login.php explosent (les bots), les 401 sur le nouveau chemin restent rares (les humains). C'est le schéma sain. Si les 401 suivent le nouveau chemin en masse, le slug a fuité ou il est trop prévisible (/connexion, /admin, /backend). On évite les mots du dictionnaire.
On ne se sert pas de ces 404 comme vanité (« 10 000 attaques bloquées »). On s'en sert comme preuve que le geste filtre le bruit. Puis on lit les vraies alertes monitoring.
Cacher wp-admin n'est pas une politique de sécurité. C'est un rideau.
