Une maintenance correctement posée laisse passer les administrateurs connectés, la page wp-login.php, l’administration, admin-ajax.php, l’API REST, les tâches planifiées et WP-CLI. Si l’un de ces chemins reçoit la page temporaire, vous travaillerez à l’aveugle — ou pas du tout.
Le test des deux fenêtres
C’est le seul contrôle qui compte, et il prend trente secondes. Gardez votre session d’administration ouverte dans une fenêtre. Ouvrez une navigation privée dans une autre. Activez la maintenance.
- La fenêtre privée doit voir la page temporaire.
- Votre session doit continuer à voir le vrai site.
Si les deux fenêtres montrent la même chose, quelque chose ne va pas — et il vaut mieux le découvrir maintenant qu’après avoir fermé l’onglet.
Ce que WordPress regarde, exactement
Un mécanisme de maintenance bien écrit ne teste pas « est-ce que l’utilisateur est connecté », mais une capacité précise : manage_options. C’est celle des administrateurs. Un contributeur ou un abonné connecté verra donc la page temporaire, ce qui est le comportement attendu — ce sont des visiteurs comme les autres pendant l’intervention.
Testez-la ainsi plutôt que par le rôle : un site multisite ou un rôle personnalisé rendrait un test sur administrator faux.
Les six chemins à ne pas couper
| Chemin | Ce qui casse s’il est bloqué |
|---|---|
wp-login.php | Vous ne pouvez plus vous reconnecter du tout |
/wp-admin/ | Plus d’administration, donc plus d’interrupteur |
admin-ajax.php | L’administration se met à échouer par endroits |
| API REST | L’éditeur de blocs refuse d’enregistrer |
| WP-Cron | Les tâches s’accumulent et repartent d’un coup |
| WP-CLI | Plus de secours en ligne de commande |
À cette liste s’ajoutent robots.txt et favicon.ico, pour des raisons qui n’ont rien à voir avec l’accès mais qui comptent au moins autant : un 5xx prolongé sur robots.txt fait cesser l’exploration de tout le site.
Vérifier sans se fier à son navigateur
Votre navigateur est le pire témoin possible : il a une session, un cache et parfois des extensions. Les trois commandes suivantes, elles, ne mentent pas.
curl -I https://votre-site.fr/ # attendu : 503
curl -I https://votre-site.fr/wp-login.php # attendu : 200
curl -I https://votre-site.fr/robots.txt # attendu : 200curl arrive toujours sans session : il voit exactement ce que voit un visiteur anonyme.
Si vous vous êtes enfermé dehors
Ça arrive, en général avec une règle serveur filtrant sur l’adresse IP, qui a changé depuis. Trois portes de sortie, par ordre de simplicité :
- Par FTP ou le gestionnaire de fichiers — renommez le dossier de l’extension dans
wp-content/plugins/. WordPress la désactive automatiquement au chargement suivant. Si c’est une mu-extension, déplacez le fichier hors dewp-content/mu-plugins/. - Par la règle serveur — commentez les lignes ajoutées dans
.htaccess, ou remplacez l’adresse IP filtrée par la vôtre, que vous trouverez en cherchant « mon adresse IP ». - Par WP-CLI, si vous avez un accès SSH :
wp plugin deactivate --allrouvre tout en une commande.
Avant d’activer une maintenance, ouvrez une seconde session d’administration dans un autre navigateur. Si la première tombe, la seconde reste. C’est la version informatique de la clé sous le paillasson.
Le cas des aperçus
Vouloir regarder sa page de maintenance en tant qu’administrateur pose un problème amusant : puisque vous êtes exempté, vous ne la verrez jamais. Trois solutions, par qualité croissante : une navigation privée, un second navigateur, ou une fonction d’aperçu prévue par l’outil.
Un aperçu bien fait exige deux choses : la capacité manage_options et un jeton à usage unique. Sans le second, l’adresse d’aperçu devient un moyen pour n’importe qui d’afficher la page — ce qui est sans gravité ici, mais révèle une négligence sur le reste.
La procédure complète d’une intervention, de la sauvegarde à la réouverture, est détaillée dans le guide mettre WordPress en maintenance proprement.