WordPress bloqué en mode maintenance : le supprimer en toute sécurité et éviter les récidives

Le message « Briefly unavailable for scheduled maintenance » de WordPress est l’équivalent logiciel d’un portier qui sort prendre une cigarette et verrouille le bâtiment derrière lui.

Parfois, ça disparaît en quelques secondes. D’autres fois, ça reste pendant des heures parce qu’une mise à jour a échoué en cours d’exécution, PHP a expiré, le disque s’est rempli, ou un modèle de permissions a été « durci » au point de ne plus fonctionner. La bonne nouvelle : la réparation est souvent simple. La mauvaise : vous pouvez empirer la situation si vous la traitez comme une réparation précipitée.

Ce qu’est réellement le mode maintenance (et ce que ce n’est pas)

Le mode maintenance de WordPress n’est pas un « mode » sophistiqué. C’est un fichier. Plus précisément, un fichier nommé .maintenance dans le répertoire racine de WordPress. Pendant les mises à jour du cœur/des plugins/du thème, WordPress crée ce fichier comme indicateur et le vérifie à chaque requête. S’il existe et que son horodatage est suffisamment récent, WordPress affiche le message de maintenance et s’arrête.

Cette simplicité est à la fois un avantage et un piège. Si une mise à jour se termine normalement, WordPress supprime le fichier. Si la mise à jour est interrompue — expiration, erreur fatale, worker PHP tué, problème de permissions, disque plein, bref — le fichier peut rester. Et votre site reste « brièvement indisponible » aussi longtemps que votre entreprise accepte l’embarras.

Le mode maintenance est aussi souvent confondu avec :

• Un CDN ou un proxy inverse qui met en cache la page de maintenance longtemps après la suppression du fichier.
• Une fonctionnalité « maintenance » d’un plugin qui n’a rien à voir avec le mécanisme core .maintenance.
• Une mise à jour cassée où le site est réellement en panne (erreurs fatales), et la page de maintenance n’était que le premier symptôme remarqué.

Opérationnellement, traitez le mode maintenance comme un fichier de verrouillage. Votre travail est de répondre à deux questions avant de le supprimer : (1) une mise à jour est-elle encore en cours, et (2) a-t-elle échoué d’une manière qui a laissé le système incohérent ?

Mode d’analyse rapide (premier/deuxième/troisième)

Si vous avez cinq minutes et que quelqu’un regarde votre écran, faites cela dans l’ordre. L’objectif est d’identifier rapidement le goulot : mise à jour bloquée, état du système de fichiers cassé, ou un cache de bord qui vous ment.

Premier : confirmez ce que voient réellement les utilisateurs

1. Récupérez les en-têtes et le contenu depuis l’origine (contournez le CDN si possible). Si vous voyez le HTML de maintenance depuis l’origine, c’est réel. Si seul le CDN l’affiche, c’est mis en cache.
2. Vérifiez l’existence de .maintenance et son horodatage. S’il est ancien, il est presque certainement obsolète.

Deuxième : décidez si une mise à jour est encore en cours

1. Cherchez des processus PHP actifs consommant CPU/temps, et vérifiez les logs du serveur web pour des requêtes longues autour de update.php ou admin-ajax.php.
2. Vérifiez l’état des mises à jour WordPress avec WP-CLI si disponible.

Troisième : validez que le site ne plantera pas après suppression

1. Vérifiez l’espace disque libre (les mises à jour écrivent beaucoup de petits fichiers et décompressent des archives).
2. Vérifiez la propriété/les permissions pour wp-content et les répertoires du core.
3. Recherchez des artefacts de mise à jour incomplète comme wp-content/upgrade et des répertoires de plugins partiellement extraits.

C’est tout. Ne commencez pas à supprimer au hasard des dossiers de plugins comme si vous jouiez à un jeu de tape-taupe avec le système de fichiers.

Supprimer le mode maintenance en toute sécurité : la méthode disciplinée

Oui, le conseil courant est « supprimez .maintenance ». Parfois, cela suffit. Mais en production, « suffisant » est la façon dont vous obtenez une panne qui dure plus longtemps que la bannière de maintenance.

Voici le flux discipliné que j’utilise sur des systèmes réels :

1. Identifiez la racine WordPress (ne devinez pas ; sur un hébergement mutualisé il est facile de se tromper).
2. Confirmez que le fichier existe et lisez-le. Il contient un horodatage et indique parfois quelle mise à jour l’a déclenché.
3. Vérifiez si des mises à jour sont encore en cours (liste des processus, logs, état WP-CLI).
4. Faites un snapshot ou une sauvegarde avant toute modification si votre système permet des retours en arrière (snapshot VM, snapshot ZFS, sauvegarde d’hébergement). Si vous n’avez pas de rollback, soyez encore plus prudent.
5. Effacez le verrou en supprimant .maintenance uniquement après vous être assuré qu’aucune mise à jour n’est active.
6. Validez le site (page d’accueil, wp-admin, une page déconnectée, une action connectée).
7. Terminez ou relancez proprement la mise à jour pour revenir à un état cohérent.

Une citation à garder en tête quand vous êtes tenté de « juste supprimer le fichier et partir » :

« L’espoir n’est pas une stratégie. » — attribué à de nombreux responsables ops ; couramment utilisé en ingénierie de la fiabilité

Maintenant, passons au travail pratique.

Tâches pratiques : commandes, sorties, décisions (12+)

Hypothèses pour les exemples :

• Hôte Linux avec Nginx ou Apache
• WordPress situé dans /var/www/html
• WP-CLI peut être installé ou non

Si vos chemins diffèrent, adaptez-les. Ne « faites pas marcher » des commandes en les copiant aveuglément.

Tâche 1 : Vérifier que vous touchez l’origine (pas un cache)

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,20p'
HTTP/2 503
date: Sat, 27 Dec 2025 10:18:02 GMT
content-type: text/html; charset=UTF-8
cache-control: no-cache, must-revalidate, max-age=0
server: nginx

Ce que ça signifie : Un 503 suggère que le gestionnaire de maintenance (ou quelque chose en amont) renvoie une erreur. Le cache-control laisse penser que c’est dynamique, mais n’en soyez pas sûr.

Décision : Si vous voyez des en-têtes provenant d’un CDN (par ex. via ou des en-têtes spécifiques à un CDN), testez l’origine directement (header Host vers l’IP d’origine, ou adresse du LB interne). Si l’origine est correcte mais le CDN non, vous traitez un problème de cache, pas WordPress.

Tâche 2 : Confirmer le contenu de la page de maintenance

cr0x@server:~$ curl -sS https://example.com/ | sed -n '1,5p'
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Briefly unavailable for scheduled maintenance. Check back in a minute.</title>

Ce que ça signifie : C’est le message canonique de maintenance de WordPress.

Décision : Passez aux vérifications du système de fichiers. Si le contenu diffère, vous êtes peut-être face à une page de maintenance de plugin, un blocage WAF, ou une page d’erreur personnalisée.

Tâche 3 : Trouver la racine WordPress (ne devinez pas)

cr0x@server:~$ sudo find /var/www -maxdepth 4 -name wp-config.php -print
/var/www/html/wp-config.php

Ce que ça signifie : Le répertoire contenant wp-config.php est généralement la racine WordPress.

Décision : Utilisez ce répertoire pour toutes les opérations suivantes. Si plusieurs résultats existent, associez-les aux vhosts avant de modifier quoi que ce soit.

Tâche 4 : Vérifier si .maintenance existe et son ancienneté

cr0x@server:~$ cd /var/www/html && sudo ls -la .maintenance
-rw-r--r-- 1 www-data www-data 114 Dec 27 09:01 .maintenance

Ce que ça signifie : Le fichier existe, possédé par l’utilisateur web. L’horodatage suggère qu’il est là depuis plus que « brièvement ».

Décision : S’il est plus vieux que quelques minutes et qu’aucune mise à jour n’est en cours, il est probablement obsolète et sûr à supprimer après validation.

Tâche 5 : Lire le fichier .maintenance pour contexte

cr0x@server:~$ sudo cat /var/www/html/.maintenance
<?php $upgrading = 1766826061; ?>

Ce que ça signifie : Il enregistre un timestamp Unix dans $upgrading. WordPress l’utilise pour décider si le mode maintenance doit s’appliquer.

Décision : Convertissez-le en heure lisible. S’il est ancien, vous n’interromprez pas une mise à jour active en le supprimant.

Tâche 6 : Convertir l’horodatage upgrading

cr0x@server:~$ date -d @1766826061
Sat Dec 27 09:01:01 UTC 2025

Ce que ça signifie : La maintenance a commencé à 09:01 UTC.

Décision : Si vous êtes bien au-delà de ce créneau, supposez qu’une mise à jour a échoué ou a été tuée.

Tâche 7 : Chercher des processus de mise à jour actifs (PHP-FPM / PHP)

cr0x@server:~$ ps aux | egrep 'php-fpm|php.*wp-admin|php.*update' | head
www-data  21314  0.0  0.6 373400 53324 ?        S    10:12   0:00 php-fpm: pool www
www-data  21315  0.0  0.6 373400 53288 ?        S    10:12   0:00 php-fpm: pool www

Ce que ça signifie : Vous voyez des workers PHP-FPM, mais rien qui crie « exécution d’une mise à jour ». C’est du trafic normal.

Décision : Si vous voyez un long processus PHP lié à un endpoint de mise à jour, attendez ou examinez les logs avant de supprimer le verrou.

Tâche 8 : Vérifier les logs d’erreur du serveur web pour des échecs de mise à jour

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 09:01:32 [error] 21001#21001: *188 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function ..." while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /wp-admin/update.php?action=update-plugin&plugin=foo/bar.php HTTP/2.0"

Ce que ça signifie : Une requête de mise à jour a déclenché une erreur fatale en cours d’exécution. C’est une façon classique de laisser .maintenance derrière.

Décision : Attendez-vous à un plugin/thème/core partiellement mis à jour. Prévoyez de réparer en réinstallant proprement le composant affecté après restauration de l’accès.

Tâche 9 : Vérifier l’espace disque (les mises à jour échouent silencieusement quand le stockage est serré)

cr0x@server:~$ df -h /var/www/html
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   39G  420M  99% /

Ce que ça signifie : 99% d’occupation. Ce n’est pas « un peu serré », c’est « votre prochaine écriture échouera ». Les mises à jour décompressent des archives et créent des fichiers temporaires ; elles perdront ce combat.

Décision : Libérez de l’espace avant de relancer les mises à jour. Supprimer .maintenance peut restaurer le site brièvement, mais vous le re-casserez la prochaine fois que WordPress essayera d’écrire.

Tâche 10 : Inspecter le répertoire de travail upgrade

cr0x@server:~$ sudo ls -la /var/www/html/wp-content/upgrade
total 12
drwxr-xr-x  3 www-data www-data 4096 Dec 27 09:01 .
drwxr-xr-x 11 www-data www-data 4096 Dec 27 09:01 ..
drwx------  4 www-data www-data 4096 Dec 27 09:01 plugin-temp-ABcD12

Ce que ça signifie : WordPress utilise wp-content/upgrade pour l’extraction temporaire. Des répertoires laissés en place peuvent indiquer une mise à jour interrompue.

Décision : Ne supprimez pas à l’aveugle. Restaurez d’abord la disponibilité du site, puis nettoyez après avoir confirmé ce qui a échoué.

Tâche 11 : Valider la propriété et les permissions des fichiers (cassure courante après un « renforcement »)

cr0x@server:~$ sudo stat -c '%U:%G %a %n' /var/www/html/wp-content /var/www/html/wp-content/plugins
root:root 755 /var/www/html/wp-content
root:root 755 /var/www/html/wp-content/plugins

Ce que ça signifie : Possédé par root, pas par l’utilisateur web. Si WordPress s’exécute en www-data, il peut ne pas pouvoir écrire les mises à jour, supprimer .maintenance, ou créer des fichiers temporaires.

Décision : Corrigez la propriété pour correspondre à votre modèle d’exécution (souvent www-data:www-data sur Debian/Ubuntu). Si vous utilisez un utilisateur de déploiement avec écriture de groupe + setgid, faites-le intentionnellement—ne le faites pas à l’aveugle.

Tâche 12 : Supprimer .maintenance (uniquement après vérifications)

cr0x@server:~$ sudo rm -f /var/www/html/.maintenance && sudo ls -la /var/www/html/.maintenance
ls: cannot access '/var/www/html/.maintenance': No such file or directory

Ce que ça signifie : Le fichier de verrouillage a disparu.

Décision : Retestez immédiatement le site depuis l’origine. S’il affiche toujours la maintenance, vous avez affaire à du cache ou à un mécanisme différent.

Tâche 13 : Confirmer que le site est de retour (et s’il est réellement sain)

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,10p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:19:44 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que ça signifie : HTTP 200. La bannière de maintenance n’est plus servie.

Décision : Vérifiez maintenant wp-admin et les logs. Un 200 peut quand même être un thème cassé rendant un squelette HTML triste.

Tâche 14 : Vérifier la santé de WordPress avec WP-CLI (si disponible)

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp core version
6.4.3

Ce que ça signifie : WP-CLI peut s’exécuter et le core est lisible. Bon signe.

Décision : Utilisez WP-CLI pour terminer les mises à jour proprement plutôt que de cliquer dans wp-admin pendant un incident.

Tâche 15 : Voir si des mises à jour core/plugin/thème sont en attente ou à moitié faites

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin status | sed -n '1,12p'
Plugin name  Status   Update  Version
akismet      active   none    5.3
foo-plugin   active   available 2.1.0
bar-plugin   inactive none    1.9

Ce que ça signifie : Au moins un plugin a une mise à jour disponible ; peut-être est-ce celui qui a échoué.

Décision : Si une mise à jour a causé l’incident, mettez à jour de façon contrôlée (WP-CLI, un plugin à la fois), en surveillant les logs et l’espace disque.

Tâche 16 : Tenter une mise à jour contrôlée d’un plugin (un à la fois)

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin update foo-plugin
Downloading update from https://downloads.wordpress.org/plugin/foo-plugin.2.1.0.zip...
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.

Ce que ça signifie : Le chemin de mise à jour fonctionne bout en bout : téléchargement, décompression, remplacement, nettoyage.

Décision : Si cela échoue (permissions, disque, réseau), corrigez la cause sous-jacente avant de réessayer. Répéter une mise à jour échouée, c’est accumuler des répertoires de plugins à moitié extraits et des regrets.

Tâche 17 : Si wp-admin est cassé, désactivez rapidement le plugin coupable

cr0x@server:~$ cd /var/www/html && sudo -u www-data wp plugin deactivate foo-plugin
Plugin 'foo-plugin' deactivated.

Ce que ça signifie : Vous avez retiré le plugin de l’exécution sans supprimer les fichiers.

Décision : Utilisez la désactivation comme levier de sécurité. Supprimer des dossiers de plugins sous pression provoque des erreurs si des autoloaders attendent des fichiers qui disparaissent en cours de requête.

Tâche 18 : Si vous n’avez pas WP-CLI, faites une vérification minimale du système de fichiers pour plugins à moitié installés

cr0x@server:~$ sudo find /var/www/html/wp-content/plugins -maxdepth 2 -type f -name '*.php' | head
/var/www/html/wp-content/plugins/akismet/akismet.php
/var/www/html/wp-content/plugins/foo-plugin/foo-plugin.php
/var/www/html/wp-content/plugins/bar-plugin/bar.php

Ce que ça signifie : Les fichiers principaux des plugins existent. Si un répertoire de plugin manque son fichier principal, c’est probablement une installation cassée.

Décision : Si un plugin est à moitié installé, réinstallez-le proprement depuis une source fiable (ou restaurez depuis une sauvegarde). Ne « patchez » pas des fichiers manquants au hasard.

Pourquoi ça se bloque : modes de défaillance prouvables

Le mode maintenance bloqué est un symptôme. La maladie est généralement l’un de ces cas :

1) Mise à jour interrompue (expirations, processus tués, redémarrages)

Les mises à jour WordPress sont une séquence d’écritures : télécharger le zip, décompresser dans temp, remplacer les fichiers, exécuter les routines d’update, supprimer .maintenance. Si PHP expire, FPM redémarre, le conteneur est redéployé, ou l’hôte redémarre au mauvais moment, le nettoyage peut ne jamais se produire. Le site reste verrouillé car le fichier de verrou est toujours présent.

Points de preuve : logs d’erreur montrant des fatals/expirations sur update.php, restes dans wp-content/upgrade, et un horodatage de .maintenance correspondant à la fenêtre du dernier déploiement/redémarrage.

2) Disque plein (ou exhaustion d’inodes)

Les mises à jour sont intensives en écritures. Pas de grosses écritures — beaucoup de petites. Un système de fichiers presque plein provoque des échecs imprévisibles : extraction de zip échoue, création de répertoires temporaires impossible, et WordPress peut ne pas pouvoir supprimer .maintenance même si la mise à jour « a presque » réussi.

Points de preuve : df -h à 95%+, erreurs ENOSPC dans les logs, et parfois le cousin ennuyeux : inodes épuisés sur des FS avec des millions de petits fichiers.

3) Mismatch de permissions / propriété

Le processus web doit pouvoir écrire dans certains chemins pendant les mises à jour. Certaines équipes verrouillent les permissions après une revue de sécurité, puis oublient que WordPress n’est pas un générateur de site statique. Si wp-content est possédé par root et non écrivable par l’utilisateur runtime, WordPress peut créer .maintenance dans un contexte et échouer à le supprimer plus tard.

Points de preuve : stat montre des propriétaires discordants, erreurs comme « Could not create directory », et l’interface de mise à jour demandant des identifiants FTP (un reliquat qui apparaît quand les écritures directes échouent).

4) Couches de cache servant une maintenance obsolète

Vous avez supprimé .maintenance, vous avez rafraîchi, et la bannière est toujours là. C’est alors que vous vous souvenez que vous avez : CDN, cache proxy inverse, cache d’objet, plugin de cache de page, cache navigateur, et peut‑être un worker edge « optimisant » le HTML. L’un d’eux peut mettre en cache un 503 et continuer à le servir.

Points de preuve : l’origine renvoie 200 tandis que le bord renvoie 503 ; les en-têtes diffèrent entre origine et edge ; purger le cache corrige immédiatement.

5) La mise à jour a « réussi » mais le runtime est cassé

Parfois le mode maintenance est bien supprimé, mais le site est toujours en panne à cause d’une erreur fatale introduite par la mise à jour : version PHP incompatible, extensions manquantes, conflits de plugins, problème de thème. La bannière de maintenance n’était que le signe que vous étiez sur le chemin de mise à jour.

Points de preuve : erreurs fatales PHP après suppression du fichier, wp-admin inaccessible, et logs montrant fonctions/classes manquantes liées au code d’un plugin/thème.

Petite blague #1 : Le mode maintenance de WordPress, c’est comme un post‑it sur la porte « De retour dans 1 minute. » Ça ne dure jamais une minute.

Erreurs courantes : symptôme → cause → correction

Cette section existe parce que les gens continuent de faire les mêmes trois erreurs : deviner, se précipiter, et « optimiser » sans plan de retour en arrière.

La bannière de maintenance persiste même après suppression de .maintenance

• Symptôme : .maintenance a disparu, mais les utilisateurs voient toujours la page de maintenance.
• Cause : Réponse mise en cache (CDN, proxy inverse, plugin de cache) ou vous avez supprimé le .maintenance du mauvais site (mauvaise racine).
• Correction : Vérifiez la réponse de l’origine avec curl, confirmez la racine correcte via la config vhost, purgez le cache en bord si nécessaire.

Le site renvoie 500 après suppression de .maintenance

• Symptôme : Le mode maintenance a disparu, mais c’est maintenant un 500 ou une page blanche.
• Cause : La mise à jour a laissé un plugin/thème à moitié mis à jour ; version PHP incompatible ; extension manquante ; autoload corrompu.
• Correction : Vérifiez les logs d’erreur ; désactivez les plugins suspects (WP-CLI ou renommez le répertoire) ; réinstallez proprement le plugin/thème affecté ; confirmez la version PHP et les extensions requises.

Le mode maintenance revient immédiatement après la suppression

• Symptôme : Vous supprimez .maintenance, vous rafraîchissez, et il revient.
• Cause : Un processus de mise à jour est toujours en cours (cron, auto-updates, quelqu’un d’autre dans wp-admin) et recrée le fichier.
• Correction : Arrêtez l’activité de mise à jour (mettez en pause le pipeline de déploiement, désactivez temporairement les mises à jour automatiques, enquêtez sur cron), puis supprimez le fichier une fois le système stable.

Les mises à jour échouent toujours et laissent le mode maintenance

• Symptôme : C’est un schéma, pas un cas isolé. Chaque mise à jour risque une indisponibilité.
• Cause : Système de fichiers non écrivable par l’utilisateur runtime ; pression disque ; egress réseau bloqué vers les sources de téléchargement WordPress ; outils de sécurité réécrivant les permissions.
• Correction : Corrigez le modèle d’exécution : utilisateur/groupe cohérents, chemins d’upgrade écrits, marge disque adéquate, autoriser les sorties vers les sources de mise à jour, et arrêtez le « durcissement » par roulette chmod.

wp-admin demande des identifiants FTP pendant les mises à jour

• Symptôme : L’interface de mise à jour exige des identifiants FTP/SSH.
• Cause : WordPress ne peut pas écrire directement sur le système de fichiers (permissions/propriété ou système monté en lecture seule).
• Correction : Corrigez la propriété/les permissions et les options de montage. Si vous devez impérativement utiliser une infrastructure immuable, faites les mises à jour via le pipeline de build, pas via wp-admin.

Seules certaines pages affichent le mode maintenance

• Symptôme : La page d’accueil fonctionne, certaines pages affichent la maintenance (ou inversement).
• Cause : Incohérence de cache (un nœud de cache a un 503 obsolète), ou une page de maintenance générée conditionnellement par un plugin.
• Correction : Purgez les caches globalement ; vérifiez plusieurs POPs ; confirmez si un plugin « maintenance » est activé.

Trois mini-récits du terrain en entreprise

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exécutait WordPress derrière un load balancer avec deux nœuds applicatifs. Les mises à jour étaient « simples » : se connecter à wp-admin, cliquer sur update, attendre que le spinner s’arrête, et passer à autre chose. Un matin, le marketing a tenté de mettre à jour un plugin cinq minutes avant le lancement d’une campagne. Le site est passé en mode maintenance et y est resté.

Le responsable a supprimé .maintenance sur le nœud A. Aucun changement. Ils l’ont supprimé à nouveau. Toujours rien. Ils ont alors conclu que WordPress était « bloqué ailleurs » et ont commencé à redémarrer des services.

La mauvaise hypothèse : qu’il n’y avait qu’un seul système de fichiers. En réalité, le nœud A et le nœud B avaient des disques locaux séparés (pas de stockage partagé). Le load balancer continuait d’envoyer la moitié du trafic au nœud B, où .maintenance existait toujours. Les utilisateurs vivaient à la roulette : rafraîchir et peut‑être vous obtenez le site ; rafraîchir et peut‑être la maintenance.

Une fois qu’ils ont compris qu’il s’agissait d’un problème de cohérence multi‑nœuds, la correction fut peu glamour : supprimer .maintenance sur les deux nœuds, puis arrêter de faire des mises à jour in‑place sur des « pets ». Ils ont déplacé les mises à jour de plugins dans une étape de build d’artefact et déployé de façon cohérente sur tous les nœuds.

La leçon n’est pas « utilisez un stockage partagé ». La leçon est : connaissez votre topologie avant d’appliquer une correction mono‑hôte sur un système multi‑hôte. Les systèmes distribués ne récompensent pas l’optimisme.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait des pages plus rapides. Ils ont ajouté un cache agressif en bord et l’ont configuré pour mettre en cache « les erreurs pour un court laps » afin de protéger l’origine lors des pics. Objectif sensé. Paramètre par défaut risqué.

Pendant une mise à jour du core WordPress, le site a renvoyé une page de maintenance 503 pendant environ 20 secondes. Le bord l’a mise en cache. Les utilisateurs ont continué de recevoir la réponse de maintenance bien plus longtemps que la fenêtre réelle de mise à jour, même après la suppression de .maintenance. En interne, l’équipe voyait le site fonctionner (car ils contournaient le CDN depuis le réseau corporate). À l’extérieur, les clients voyaient « Briefly unavailable ». Les tickets support ont commencé à se multiplier comme des lapins avec un plan de projet.

Ils ont purgé le bord et tout est revenu instantanément. Puis ils ont dû expliquer pourquoi une mise à jour de 20 secondes a causé une indisponibilité beaucoup plus longue. L’action post‑incident n’a pas été « ne pas mettre en cache ». Ce fut : ne pas mettre en cache la réponse de maintenance, ne pas mettre en cache les 503 sur les chemins WordPress, et configurer des règles de contournement pour /wp-admin/ et les endpoints liés aux updates.

Les optimisations de performance sont super tant qu’elles ne rendent pas votre mode de défaillance collant. En production, « défaillance collante » est une catégorie spéciale de coûteux.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe d’entreprise exécutait WordPress comme partie d’une plateforme plus large. Rien d’exotique : Nginx, PHP-FPM, MariaDB, plus un pipeline de déploiement qui construisait un artefact pour le core WordPress et les plugins approuvés. Les rédacteurs utilisaient toujours wp-admin pour le contenu, mais les mises à jour de code passaient par CI/CD uniquement.

Un après‑midi, une mise à jour automatique a été activée accidentellement sur un plugin (un paramètre a dérivé lors d’une migration). Le plugin a essayé de se mettre à jour pendant un pic de trafic. Il a créé .maintenance puis a échoué car le système de fichiers était en lecture seule par conception (déploiement seulement).

Le site est passé en mode maintenance, mais l’équipe avait deux filets de sécurité : (1) un artefact en lecture seule et versionné garantissait une base de code cohérente, et (2) des snapshots horaires leur permettaient de revenir instantanément si le système de fichiers avait été modifié. Ils ont supprimé .maintenance, confirmé qu’aucun fichier n’avait été modifié (parce que c’était impossible), désactivé les mises à jour automatiques du plugin, et ouvert une demande de changement pour éviter cette dérive de paramètre.

Pas d’héroïsme. Pas de fouille SSH frénétique. Juste des frontières propres : le runtime sert, le pipeline écrit. Ce n’est pas excitant, et c’est le but.

Prévention : rendre ça ennuyeux et ça cesse

Le mode maintenance bloqué est généralement un problème de processus déguisé en problème de système de fichiers. Vous l’empêchez en rendant les mises à jour prévisibles et récupérables.

Privilégiez les mises à jour contrôlées (WP-CLI ou pipeline), pas le click‑ops

Cliquer « Update now » dans wp-admin depuis un laptop en Wi‑Fi de café n’est pas une stratégie de déploiement. C’est un exercice de confiance. Utilisez WP-CLI sur le serveur ou exécutez les mises à jour dans un pipeline pouvant être réessayé, journalisé et rollbacké.

Gardez une marge d’espace disque dont vous avez besoin

Pour les hébergeurs WordPress, j’aime garder au moins quelques Go libres sur les petits volumes et plus sur les grands. Mises à jour, caches, logs, uploads d’images et sauvegardes se disputent l’espace. La pression disque provoque des symptômes bizarres bien avant 100%.

Rendez la propriété/les permissions cohérentes

Choisissez un modèle opérationnel et appliquez‑le :

• Modèle serveur mutable : WordPress peut écrire les mises à jour. Alors l’utilisateur runtime doit posséder ou avoir l’accès en écriture aux chemins pertinents. Idéal pour les petits sites ; risqué pour les grands.
• Modèle de déploiement immuable : Le runtime est en lecture seule ; les mises à jour se font dans une étape de build. Excellent pour la fiabilité ; demande de la discipline.

Mélanger les deux modèles produit la situation classique où WordPress peut créer .maintenance mais ne peut pas le supprimer. Ce n’est pas de la « sécurité ». C’est un piège que vous vous êtes posé.

Garde‑fous : monitors et alertes pour le mode maintenance

Ajoutez une vérification synthétique qui demande la page d’accueil et échoue si le titre de maintenance apparaît. C’est une alerte à fort signal et peu d’effort. Vos clients ne devraient pas être votre système de surveillance.

Règles de cache : n’entrez pas « brièvement indisponible » dans le cache permanent

Au niveau du CDN ou proxy inverse, définissez un comportement sensé pour les réponses 503 et pour les chemins d’admin WordPress. Le mode maintenance est une réponse transitoire qui ne doit pas être largement mise en cache.

Petite blague #2 : Rien ne crie « niveau entreprise » comme mettre en cache une page d’erreur sur 200 points dans le monde.

Listes de contrôle / plan étape par étape

Checklist A : Sortir le site du mode maintenance en toute sécurité (10–15 minutes)

1. Confirmer ce que voit l’utilisateur (origine vs cache).
2. Localiser la racine WordPress correcte via wp-config.php.
3. Vérifier l’existence et l’horodatage de .maintenance.
4. Vérifier les mises à jour actives (processus, logs).
5. Vérifier l’espace disque et les inodes.
6. Vérifier wp-content/upgrade pour des dossiers temporaires restants.
7. Faire un snapshot/sauvegarde si disponible.
8. Supprimer .maintenance.
9. Valider : page d’accueil, quelques liens profonds, connexion wp-admin.
10. Consulter les logs pour confirmer l’absence de fatals/expirations persistants.

Checklist B : Réparer la défaillance de mise à jour sous-jacente (30–90 minutes)

1. Corriger la pression disque (vider anciens logs, dossiers de cache, sauvegardes inutiles).
2. Corriger la propriété/les permissions pour correspondre à votre modèle.
3. Mettre à jour via WP-CLI un composant à la fois.
4. Si un plugin/thème est corrompu, réinstallez‑le proprement.
5. Vérifier la version PHP et les extensions requises par les plugins.
6. Faire un smoke test rapide et surveiller les logs.

Checklist C : Prévenir les récidives (voici où les adultes gagnent leur paie)

1. Décidez : WordPress mutable ou déploiement d’artefacts immuable. Mettez‑le par écrit.
2. Ajoutez une surveillance synthétique pour la réponse de maintenance.
3. Ajoutez alertes d’espace disque et d’inodes avant d’atteindre des seuils critiques.
4. Définissez des règles CDN/proxy pour éviter de mettre en cache les pages 503 de maintenance.
5. Planifiez les mises à jour en période de faible trafic avec des chemins de rollback clairs.
6. Maintenez les sauvegardes/snapshots testés, pas seulement configurés.

Faits intéressants et contexte historique

• Le mode maintenance de WordPress est implémenté comme un simple fichier de verrou (.maintenance) plutôt qu’un flag en base de données, ce qui le rend rapide et indépendant de l’état DB.
• Le message « Briefly unavailable… » remonte à de nombreuses versions majeures et perdure car il est fiable en conditions de mise à jour partielle : si PHP peut lire un fichier, il peut afficher un message.
• WP-CLI a démarré comme projet communautaire et est devenu le standard de facto parce que les mises à jour par clic ne tiennent pas à l’échelle opérationnelle.
• Les mises à jour automatiques en arrière-plan ont été introduites pour réduire le délai de patch des correctifs de sécurité, mais elles ont aussi introduit un nouveau mode de défaillance : mises à jour non supervisées sur des systèmes de fichiers mal configurés.
• Les mises à jour WordPress fonctionnent en extrayant des archives ZIP dans des répertoires temporaires, ce qui les rend sensibles à l’espace disque et à la disponibilité des inodes.
• Beaucoup d’hébergeurs proposaient historiquement le flux de mise à jour via identifiants FTP parce que PHP tournait souvent en tant qu’utilisateur non privilégié incapable d’écrire dans le répertoire du site.
• Certaines couches de cache mettent en cache les 503 par défaut comme mesure de résilience, ce qui peut involontairement prolonger la fenêtre visible de maintenance bien au‑delà de la mise à jour réelle.
• L’écosystème de plugins ajoute de la complexité opérationnelle : une seule mise à jour de plugin peut changer les exigences runtime (version PHP, extensions), transformant une mise à jour routinière en panne.

FAQ

1) Est‑ce toujours sûr de supprimer le fichier .maintenance ?

Généralement oui — si aucune mise à jour n’est activement en cours. Si une mise à jour est encore en cours, la supprimer peut exposer le trafic à un code à moitié mis à jour. Vérifiez les processus/logs et l’horodatage d’abord.

2) Où se trouve le fichier .maintenance ?

Dans le répertoire racine WordPress (le même répertoire qui contient wp-config.php). Si vous avez plusieurs sites, chacun a sa propre racine et son propre .maintenance.

3) Pourquoi le mode maintenance revient‑il après l’avoir supprimé ?

Parce que quelque chose le recrée : une réessai d’auto‑mise à jour, un cron, ou une autre session admin tentant une mise à jour. Arrêtez le déclencheur de mise à jour, puis supprimez le fichier.

4) J’ai supprimé .maintenance et maintenant j’ai un écran blanc. Que s’est‑il passé ?

La mise à jour a probablement introduit une erreur fatale (incompatibilité de plugin/thème, extension PHP manquante, autoload cassé). Consultez les logs PHP/Nginx/Apache, puis désactivez le plugin suspect ou changez de thème.

5) Un cache peut‑il donner l’impression que WordPress est toujours en maintenance ?

Absolument. Les CDNs et les proxies inverse peuvent mettre en cache la réponse de maintenance. Comparez les réponses origine vs edge ; purgez les caches si l’origine est saine.

6) Quelle est la méthode la plus rapide pour désactiver des plugins si wp-admin est indisponible ?

WP-CLI est la plus rapide : wp plugin deactivate --all (puis réactivez sélectivement). Sans WP-CLI, renommer le répertoire du plugin peut fonctionner, mais c’est plus brutal et moins traçable.

7) Le mode maintenance WordPress n’affecte‑t‑il que le frontend ?

Il peut affecter à la fois le frontend et l’administration, selon le chemin de requête et le timing. Pendant les mises à jour, vous ne pouvez souvent pas utiliser wp-admin de façon fiable tant que la mise à jour n’est pas terminée ou que le verrou n’est pas supprimé.

8) Comment prévenir cela lors de futures mises à jour ?

Corrigez les causes racines : assurez un espace disque suffisant, des permissions cohérentes, et une méthode de mise à jour contrôlée (WP-CLI ou pipeline). Configurez aussi les caches pour éviter de mettre en cache les 503 de maintenance.

9) Dois‑je supprimer le contenu de wp-content/upgrade ?

Après avoir rétabli le service et confirmé qu’aucune mise à jour n’est en cours, vous pouvez supprimer d’anciens dossiers temporaires dans wp-content/upgrade. Si vous avez un doute, laissez‑les jusqu’à la réparation complète ; ils peuvent faire office de preuve.

10) Et si je suis sur une configuration multi‑nœud ?

Vérifiez chaque nœud qui peut servir le site. Si le stockage n’est pas partagé, chaque nœud peut avoir son propre .maintenance. Assurez‑vous aussi que les mises à jour ne sont pas tentées indépendamment sur plusieurs nœuds.

Conclusion : prochaines étapes pour réduire les temps d’arrêt

Quand WordPress est bloqué en mode maintenance, la réparation mécanique est de supprimer .maintenance. La réparation professionnelle consiste à s’assurer que vous n’interrompez pas une mise à jour active, puis à réparer la cause sous‑jacente qui l’a bloquée.

Faites ceci ensuite :

1. Vérifiez origine vs cache et purgez seulement après avoir prouvé que le cache est en cause.
2. Vérifiez l’espace disque et les permissions — deux problèmes ennuyeux qui causent la plupart des drames.
3. Terminez les mises à jour avec WP-CLI (un composant à la fois) ou déplacez les mises à jour dans un pipeline.
4. Ajoutez une surveillance pour la réponse de maintenance afin d’en être informé avant vos clients.

Rendez les mises à jour ennuyeuses, répétables et observables. WordPress trouvera toujours des moyens de vous surprendre — mais moins souvent à 09:01 le jour du lancement.