WordPress bloqué en mode maintenance : comment débloquer le site ?

Vous lancez une mise à jour depuis le tableau de bord, vous partez prendre un café, et à votre retour le site n’affiche plus qu’une ligne de texte en anglais sur fond blanc. Votre site WordPress est bloqué en mode maintenance. L’administration est fermée elle aussi, et recharger la page cinquante fois n’y change rien.

J’ai rencontré ce cas chez des clients comme sur mes propres sites. C’est l’une des pannes WordPress les plus simples à réparer, à condition de savoir quel fichier chercher et où il se cache. Je détaille ma méthode dans l’ordre, y compris les cas où supprimer ce fichier ne suffit pas.

Que signifie « Briefly unavailable for scheduled maintenance » sur un site WordPress ?

La réponse courte : WordPress a volontairement mis votre site en pause pendant qu’il met à jour le noyau, une extension ou un thème. Pour cela, il crée à la racine du site un petit fichier nommé .maintenance. Tant que ce fichier est présent et récent, tous les visiteurs voient « Briefly unavailable for scheduled maintenance. Check back in a minute. », ce qui donne en français « Brièvement indisponible pour cause de maintenance planifiée. Revenez dans une minute. »

Cette pause protège le site. Pendant qu’une extension est remplacée, une partie de ses fichiers est ancienne et l’autre est neuve. Afficher le site dans cet état risquerait de produire des erreurs, voire d’enregistrer des données de travers. Le fichier joue donc le rôle d’une barrière provisoire. Dès que la mise à jour se termine, WordPress retire la barrière et le site réapparaît.

Pour une mise à jour ordinaire, tout se joue en quelques secondes. Vous ne voyez le message que si vous visitez le site au mauvais moment. Ce n’est donc pas une panne en soi. Il en devient une quand la mise à jour s’arrête en route et que personne ne retire la barrière.

Un détail qui compte pour la suite : le mode maintenance concerne le site public et l’administration. Impossible de « retourner dans le tableau de bord » pour annuler quoi que ce soit. Il faut passer par les fichiers du site, c’est-à-dire par un accès SFTP ou par le gestionnaire de fichiers de l’hébergeur. Si vous n’avez aucun de ces deux accès, retrouvez-les avant d’aller plus loin.

Pourquoi WordPress reste-t-il bloqué en mode maintenance après une mise à jour ?

Le blocage vient presque toujours d’une mise à jour qui n’a pas pu aller au bout. WordPress crée le fichier au début de l’opération et le supprime à la fin. Si quelque chose coupe le processus entre les deux, le fichier reste. L’interruption la plus courante : l’onglet du navigateur fermé en pleine mise à jour, ou une connexion internet qui lâche.

Viennent ensuite les causes côté serveur. Un hébergement mutualisé qui impose un temps d’exécution court peut stopper le script en plein travail. Une mémoire PHP trop juste produit le message « Allowed memory size of X bytes exhausted » pendant la décompression de l’archive. Et la cause que je vois le plus souvent chez mes clients : un clic sur « tout mettre à jour » avec beaucoup d’extensions en attente, sur un serveur modeste.

Les mises à jour automatiques en arrière-plan passent aussi par ce mécanisme, y compris quand vous n’êtes pas connecté. Vous pouvez donc découvrir le blocage un matin sans avoir rien cliqué la veille.

Le fichier .maintenance ne se bloque jamais tout seul : quelque chose a interrompu la mise à jour, et c’est cette interruption qu’il faut comprendre.

Ce point change la façon de réparer. Supprimer le fichier remet le site en ligne, mais ne dit pas pourquoi la mise à jour a échoué. Si la même coupure se reproduit à la prochaine tentative, vous reviendrez au même écran. Je regarde donc toujours ce qui s’est passé avant de relancer.

HTTP 503, HTTP 504, HTTP 500 : que disent les codes affichés autour du blocage ?

Selon la documentation que j’ai consultée, la page de maintenance de WordPress renvoie un code HTTP 503, « Service Unavailable », qui signale aux moteurs de recherche que l’interruption est temporaire. Voilà pourquoi un outil de supervision vous alerte avec un 503 quand le fichier traîne. D’autres codes peuvent s’afficher si la mise à jour a échoué plus tôt, et chacun oriente vers une cause différente.

Le plus important dans ce tableau : le 503 et le message anglais vont ensemble, alors que le 500 et le message sur la mémoire pointent vers une mise à jour qui a planté en cours de route. Dans ce second cas, supprimer le fichier ne suffira pas, et j’y reviens plus bas.

Faut-il attendre ou intervenir tout de suite ?

La réponse courte : attendez 10 minutes, pas davantage. Selon la fonction de WordPress qui contrôle le mode maintenance, le fichier est ignoré dès qu’il date de 10 minutes ou plus. Si votre mise à jour a été interrompue, le site peut donc se débloquer tout seul. Les extensions volumineuses prennent parfois plus d’une minute, et la page affiche alors le message un peu plus longtemps que prévu sans que rien ne soit cassé.

Concrètement, je procède ainsi. Étape 1 : je me demande si la mise à jour peut encore tourner. Si l’onglet est resté ouvert et que le lancement date de quelques minutes, je patiente. Si j’ai fermé l’onglet, ou si la mise à jour a été lancée il y a plus de dix minutes, plus rien ne tourne et inutile d’attendre.

Étape 2 : j’ouvre le site dans une fenêtre de navigation privée, pour écarter le cache du navigateur. Étape 3 : si le message est toujours là, j’agis sur les fichiers. Ce que je ne fais jamais, c’est recharger la page en boucle ou relancer la mise à jour depuis un autre appareil : on risquerait de lancer deux opérations en même temps sur les mêmes fichiers.

Pour une boutique WooCommerce, dix minutes sans site, c’est dix minutes sans vente. Dans ce cas je préfère vérifier tout de suite l’heure de lancement de la mise à jour et supprimer le fichier plus tôt, une fois certain que plus rien ne s’exécute.

Comment débloquer WordPress en supprimant le fichier .maintenance ?

C’est la solution qui règle la grande majorité des cas. Le fichier se trouve à la racine de votre site, au même niveau que wp-config.php, les dossiers wp-admin, wp-content et wp-includes. Voici ma procédure.

1. Je me connecte en SFTP avec un client comme FileZilla, ou j’ouvre le gestionnaire de fichiers de l’espace client de l’hébergeur.
2. Je vais à la racine du site, le dossier qui contient wp-config.php.
3. Je repère le fichier .maintenance, en forçant l’affichage des fichiers cachés si besoin.
4. Je le supprime.
5. Je recharge le site dans une fenêtre de navigation privée, puis je me connecte à l’administration.

Un fichier d’une seule ligne, donc.

Ce fichier est minuscule. Il ne contient qu’une ligne PHP avec un horodatage, l’heure à laquelle la mise à jour a démarré, et c’est cette valeur que WordPress compare à l’heure actuelle pour décider s’il doit encore bloquer le site.

<?php $upgrading = 1234567890; ?>

Si vous avez un accès SSH, il existe un raccourci : la commande wp maintenance-mode deactivate de WP-CLI, décrite dans la documentation officielle de WP-CLI, désactive le mode maintenance sans que vous cherchiez le fichier à la main. Je l’utilise surtout sur les serveurs où je travaille déjà en ligne de commande.

Où trouver le fichier .maintenance quand il n’apparaît pas dans FileZilla ?

Le nom commence par un point. Sur un serveur Linux, cela en fait un fichier caché, que beaucoup de clients SFTP n’affichent pas par défaut. Dans FileZilla, je passe par le menu « Serveur » puis « Forcer l’affichage des fichiers cachés ». Les gestionnaires de fichiers des hébergeurs ont un réglage équivalent, souvent une case à cocher ou une icône d’engrenage en haut de la liste.

Deuxième piège : le mauvais dossier. Si WordPress est installé dans un sous-dossier, par exemple pour un site en cours de refonte, la racine de WordPress n’est pas la racine du compte d’hébergement. Je cherche toujours wp-config.php d’abord : le fichier .maintenance doit être juste à côté de lui.

Troisième cas : le fichier n’existe pas alors que le message s’affiche. Ce n’est plus le mode maintenance automatique. Il s’agit alors d’un plugin de maintenance activé, ou d’un fichier wp-content/maintenance.php, dont je parle dans la partie suivante.

Que faire si le site reste bloqué même après suppression du fichier .maintenance ?

Premier réflexe : le cache. Un plugin de cache, le cache de l’hébergeur ou un CDN peuvent continuer à servir la page de maintenance à vos visiteurs plusieurs minutes après la suppression. Je vide chaque couche l’une après l’autre, puis je teste en navigation privée.

Deuxième piste : un plugin de mode maintenance resté actif, ou un fichier wp-content/maintenance.php, que le cœur de WordPress charge de lui-même pour afficher votre propre page à la place du message standard. Si vous en trouvez un, renommez-le temporairement pour voir si le site revient.

Troisième piste, la plus délicate : la mise à jour a planté en laissant une extension incomplète, et vous obtenez un HTTP 500 ou un écran blanc. Dans ce cas, je renomme le dossier de l’extension concernée dans wp-content/plugins, ce qui la désactive, et je regarde le journal d’erreurs. Mon article sur l’écran blanc de WordPress détaille cette démarche. Si le journal parle de mémoire, augmentez WP_MEMORY_LIMIT ou demandez à l’hébergeur de relever la limite PHP.

Comment vérifier qu’une mise à jour interrompue n’a rien abîmé ?

Un site qui s’affiche de nouveau n’est pas forcément un site en bon état. La mise à jour a été coupée au milieu, et certains fichiers peuvent être anciens pendant que d’autres sont neufs. Je commence donc par ouvrir Tableau de bord, puis Mises à jour. Si l’extension ou le thème proposent encore une mise à jour, c’est qu’elle n’a pas abouti.

Je relance alors cette mise à jour seule, sans toucher aux autres, et je surveille le résultat. En pratique, une extension à la fois change tout : si le blocage revient, je sais exactement laquelle est en cause. Si la mise à jour refuse de s’exécuter, je télécharge l’archive de l’extension depuis le dépôt officiel et je remplace le dossier à la main en SFTP.

Ensuite je teste les pages qui rapportent de l’argent : l’accueil, le formulaire de contact, et sur une boutique, un passage de commande jusqu’à l’avant-dernière étape. J’ouvre aussi Outils, puis Santé du site, qui signale les problèmes détectés par WordPress. Si le noyau lui-même était en cours de mise à jour, je compare la version affichée en bas de l’administration avec la dernière version disponible.

Quand plusieurs fichiers semblent abîmés et que je n’arrive pas à les remettre d’aplomb, je restaure la dernière sauvegarde saine plutôt que de bricoler. C’est précisément le jour où une sauvegarde WordPress automatisée prouve son utilité.

Mode maintenance WordPress : plugin ou page personnalisée, que choisir ?

Il faut distinguer deux choses que l’on confond souvent. Le mode maintenance natif, celui du fichier .maintenance, est automatique, très court et non personnalisable. Le mode maintenance volontaire sert à fermer le site pendant une refonte ou un chantier plus long, avec une page « de retour bientôt » à votre image. Les deux n’ont aucun lien technique, même si les visiteurs voient un écran semblable.

Pour le volontaire, il y a deux voies. Un plugin de mode maintenance se règle en quelques clics, avec un titre, un texte, parfois un compte à rebours. C’est le choix le plus simple pour un dirigeant qui gère son site seul. L’inconvénient : une extension de plus, qui doit elle-même être mise à jour.

L’autre voie est le fichier wp-content/maintenance.php, que WordPress charge de lui-même quand il existe. C’est plus léger, mais cela demande d’écrire un peu de PHP et d’avoir un accès aux fichiers. Je l’utilise quand je veux une page très sobre, sans extension.

Dans les deux cas, je vérifie que la page renvoie bien un code HTTP 503, comme le fait la maintenance native : c’est le signal qui indique aux moteurs de recherche que l’interruption est temporaire. Pour un chantier de plusieurs jours, mon choix par défaut reste un plugin. Pour de simples mises à jour, je n’en installe aucun et je les fais hors des heures de forte fréquentation.

Comment éviter que WordPress reste bloqué en mode maintenance ?

En pratique, quatre habitudes suffisent. D’abord, mettre à jour les extensions une par une, ou par petits groupes, plutôt que d’un seul clic sur toutes. Une mise à jour courte a moins de chances de dépasser le temps d’exécution du serveur, et si elle échoue, le coupable est identifié tout de suite.

Ensuite, ne jamais fermer l’onglet pendant la mise à jour et ne pas la lancer depuis un téléphone en réseau mobile instable. Cela paraît évident, mais c’est la cause la plus fréquente que je rencontre. Troisième habitude : prendre une sauvegarde juste avant, et la tester au moins une fois. J’ai détaillé ma façon de faire dans mon article sur les mises à jour WordPress sans casser le site.

Quatrième habitude : regarder du côté de l’hébergement. Si le blocage revient à chaque mise à jour importante, la limite de temps ou de mémoire PHP est trop basse pour votre site, et il faut en discuter avec l’hébergeur. Une vérification mensuelle de la maintenance WordPress aide à repérer ces limites avant qu’elles ne coupent une mise à jour.

Si le problème revient malgré tout, ou si vous préférez ne pas toucher aux fichiers de votre site, je peux regarder le contexte, trouver ce qui interrompt vos mises à jour et les planifier à un moment où elles ne gênent personne. Gardez au moins ce réflexe : avant toute grosse mise à jour, notez l’heure de lancement.

Questions fréquentes