Votre site renvoie une erreur 503. Le site public ne répond plus, ou bien c'est le tableau de bord qui refuse de s'ouvrir, et vous avez sous les yeux une page qui parle de maintenance alors que vous n'avez rien mis en maintenance.
Il existe deux erreurs 503 qui n'ont rien à voir l'une avec l'autre, et le texte affiché suffit à les séparer. Presque tous les guides français les traitent comme un seul problème et envoient tout le monde mesurer sa charge processeur. C'est la raison pour laquelle tant de gens perdent des heures sur cette panne.
La procédure qui suit est celle qu'on applique en intervention : lire l'écran, savoir qui a répondu, corriger le bon point, vérifier. Les chemins de fichiers sont donnés en entier.
Ce que vous voyez, et ce que ça dit déjà
Regardez la page en panne et lisez la phrase qui s'y trouve. Une seule des deux ci-dessous s'affiche, et elles désignent deux mondes différents.
L'écran de WordPress
Une page nue, sans le moindre morceau de votre site, avec cette phrase :
Indisponibilité temporaire pour cause de maintenance. Veuillez revenir dans un instant.
C'est le libellé français. Les forums anglophones citent « Briefly unavailable for scheduled maintenance. Check back in a minute. » : c'est la même page, dans l'autre langue, et non pas une autre panne.
Cette page vient de WordPress lui-même, pas du serveur. Elle est déclenchée par un fichier nommé .maintenance, déposé à la racine au début de chaque mise à jour et supprimé à la fin. Si vous la voyez, c'est qu'une mise à jour a commencé et n'a pas fini : onglet fermé, connexion coupée, mise à jour groupée de vingt extensions qui a dépassé le temps alloué.
Deux signes la confirment. Elle pèse 2 518 octets, mesurés sur une installation en français, et la réponse porte un en-tête Retry-After: 600, que curl -sI https://votre-domaine.fr affiche en clair.
L'écran du serveur
Une page anglaise, encore plus dépouillée, avec ce texte :
Service Unavailable. The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Parfois suivi d'une seconde phrase que personne ne pense à recopier en demandant de l'aide : « Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request. » En bas, une signature du type Apache/2.4.58 Server at votre-domaine.fr Port 443.
Celle-ci vient du serveur web. Elle pèse 390 octets sur notre banc d'essai, six fois moins que la précédente, et signifie qu'Apache n'a pas obtenu de réponse de PHP.
| Ce que vous lisez | Qui répond | Ce qu'il faut chercher |
|---|---|---|
| Indisponibilité temporaire pour cause de maintenance | WordPress | le fichier .maintenance, et depuis combien de temps il est là |
| due to maintenance downtime or capacity problems | Apache | les journaux du serveur, l'état de PHP, les limites du compte |
| Une page aux couleurs d'un service tiers | un proxy ou un CDN | le tableau de bord de ce service, pas votre site |
Quand le fichier .maintenance est actif, l'accueil, /wp-admin/ et wp-login.php renvoient les trois exactement la même page. Aucune porte d'entrée, aucune adresse qui passe. C'est ce qui affole, et c'est normal.
En trente secondes
Trois observations, avant de toucher à quoi que ce soit.
1. Notez la phrase affichée. Française et parlant de maintenance, c'est WordPress. Anglaise et parlant de capacity problems, c'est le serveur. Cette seule lecture élimine la moitié des causes possibles et la totalité des mauvais gestes.
2. Notez depuis combien de temps ça dure. Retenez ce nombre, il commande tout ce qui suit. Si l'écran de WordPress est là depuis plus de dix minutes, le fichier .maintenance n'est plus ce qui bloque votre site, pour la raison expliquée juste en dessous.
3. Essayez /wp-admin/ et le site public. Les deux dans le même état, c'est une panne globale. Le site public qui s'affiche normalement pendant que seule l'administration renvoie 503, c'est un cas à part, traité plus bas.
Le fichier .maintenance cesse de bloquer au bout de dix minutes
Aucun des articles français que nous avons lus ne dit ce qui suit, et c'est pourtant ce qui décide de la suite des opérations.
Le fichier .maintenance ne contient pas d'interrupteur. Il contient une date, sous la forme d'un horodatage, et il pèse 33 octets :
<?php $upgrading = 1757183940; ?>
La fonction wp_is_maintenance_mode(), dans wp-includes/load.php, lit cette variable et compare sa valeur à l'heure courante. Au-delà de 600 secondes, elle cesse d'en tenir compte et laisse le site répondre normalement. C'est écrit dans le cœur de WordPress, et nous l'avons vérifié au laboratoire en modifiant le contenu du fichier :
| Contenu du fichier | Site public | Administration |
|---|---|---|
| Horodatage courant | 503, page de maintenance | 503, page de maintenance |
| Horodatage vieux de 601 secondes | 200, site normal | accès rétabli |
| Fichier vide | 200, site normal | accès rétabli |
| Horodatage dans le futur | 503, page de maintenance | 503, page de maintenance |
Dans les deux cas où le site remonte, le fichier est toujours là, intact, ses 33 octets à la racine. WordPress a cessé de le lire, voilà tout.
Ce que ça change pour vous. Un site bloqué en mode maintenance depuis plus de dix minutes n'est pas retenu par le fichier .maintenance. Vous pouvez le supprimer, le site restera dans le même état, parce que ce fichier ne jouait déjà plus aucun rôle. Tout le corpus explique comment le supprimer sans jamais préciser cette limite : celui qui suit ce conseil trois heures après sa mise à jour efface un fichier inoffensif et croit avoir réparé quelque chose. Il ne cherchera pas la vraie cause, qui est ailleurs.
Si la panne date de moins de dix minutes, la meilleure manœuvre est de ne rien faire : la mise à jour est peut-être encore en cours et se termine sans vous. Rechargez au bout d'un quart d'heure.
L'exception, et c'est la seule. Un horodatage situé dans le futur bloque indéfiniment, puisque la fenêtre de dix minutes ne s'ouvre jamais. Nous l'avons mesuré. C'est le cas rare où supprimer le fichier des heures après la panne est bien la réparation, et où le site remonte à la seconde. Allez donc voir le fichier de toute façon, ça ne coûte rien.
Trouver le fichier, ce que presque personne n'arrive à faire
Le geste est simple. L'obstacle est que le fichier est invisible : son nom commence par un point, ce qui suffit à le masquer dans presque tous les clients FTP et gestionnaires de fichiers. En ligne de commande, ls ne le montre pas, ls -a oui. Les fils de forum où quelqu'un le cherche pendant une heure, force l'affichage, et finit par appeler son hébergeur, sont innombrables.
Le nom exact est .maintenance, avec le point devant, sans extension. Un conseil très répandu parle de maintenance.php : ce fichier n'existe pas.
Afficher les fichiers cachés. Dans FileZilla, menu Serveur, puis « Forcer l'affichage des fichiers cachés ». Dans un gestionnaire de fichiers en ligne, l'option se trouve dans les réglages d'affichage sous une formulation du type « afficher les fichiers cachés » ou « dotfiles ». Sans ce réglage, le dossier vous paraîtra parfaitement normal.
La racine du site, c'est le dossier qui contient wp-config.php et le dossier wp-content. Selon l'hébergeur, il s'appelle public_html, www, htdocs, ou porte le nom de votre domaine. Ne cherchez pas ailleurs : .maintenance est toujours à côté de wp-config.php.
Supprimez-le, puis rechargez le site. S'il remonte, retournez dans Tableau de bord, Mises à jour, et relancez celle qui a échoué, une par une cette fois : une mise à jour coupée à mi-chemin laisse parfois une extension à moitié remplacée.
S'il réapparaît après chaque suppression, ce n'est pas un résidu : c'est une mise à jour qui échoue en boucle et redépose le fichier à chaque tentative. Le supprimer ne réglera jamais rien, il faut trouver laquelle échoue. Relancez les mises à jour une par une pour repérer celle qui bloque, puis remplacez cette extension à la main, en déposant sa dernière version par FTP dans wp-content/plugins/.
Si le site ne remonte pas après la suppression, la mise à jour interrompue a cassé autre chose. Deux suites sont documentées. Toutes les pages passent en 404 sauf l'accueil, ce qui désigne des règles de réécriture mortes et se traite dans le guide de l'erreur 404 sur WordPress. Ou bien une phrase apparaît sur fond gris, « Il y a eu une erreur critique sur ce site », et c'est le guide de l'erreur 500 qui donne la marche à suivre.
Quand c'est l'écran du serveur : PHP n'a pas répondu
Vous avez la page anglaise, celle de 390 octets avec la signature d'Apache en bas. Oubliez .maintenance, il n'est pour rien là-dedans. Le serveur web a reçu votre requête, il a essayé de la passer à PHP, et PHP n'a rien renvoyé.
Un résultat de laboratoire éclaire le reste. Nous avons arrêté PHP-FPM sur une installation branchée en parallèle sur Apache et sur nginx, puis interrogé les deux dans la même seconde : Apache renvoie 503, nginx renvoie 502, pour exactement la même panne. Apache 2.4 ne produit d'ailleurs jamais de 502 sur une défaillance de PHP-FPM, quelle qu'en soit la forme. Le code affiché vous dit donc sur quel serveur web vous êtes, avant même que vous n'appeliez votre hébergeur. Si c'est un 502 que vous avez sous les yeux, la cause est la même mais la lecture des journaux diffère : le dépannage de l'erreur 502 reprend le sujet du côté de nginx.
Les causes, dans l'ordre où il vaut la peine de les regarder :
- Le pool PHP saturé : trop de requêtes simultanées, souvent un robot d'indexation agressif ou une extension qui appelle
admin-ajax.phpen boucle. Le 503 va et vient, et une page qui échoue passe au deuxième ou au troisième essai. - La limite de processus du compte atteinte : tous les mutualisés en imposent une. Même intermittence, mais calée sur les heures de pointe.
- PHP tombé ou redémarré : le 503 est alors permanent et toutes les pages sont concernées, y compris les 404 du site.
- Un incident chez l'hébergeur : sa page d'état coûte trente secondes à consulter.
Le test qui tranche en une minute. Déposez à la racine un fichier test.txt contenant un mot quelconque, puis appelez https://votre-domaine.fr/test.txt. Le texte s'affiche : le serveur web fonctionne, seul PHP est en cause. Vous obtenez encore un 503 : PHP n'est même pas atteint, la panne est dans la configuration du serveur ou chez l'hébergeur, et rien de ce que vous ferez dans wp-content n'y changera quoi que ce soit. Supprimez le fichier ensuite.
Les journaux, et la ligne qu'il faut y chercher
Aucune page du corpus que nous avons dépouillé, dans aucune des cinq langues, ne donne le chemin des journaux avec la ligne à y chercher. Ils contiennent pourtant la réponse dans la plupart des cas.
Où ils se trouvent. Sur un mutualisé, le panneau expose une rubrique Journaux ou Logs, avec un fichier error.log ou <votre-domaine>-error.log, souvent accessible aussi en FTP dans un dossier logs placé à côté de la racine et non dedans. Sur un serveur que vous administrez, c'est /var/log/apache2/error.log sous Debian et Ubuntu, /var/log/httpd/error_log sous AlmaLinux, Rocky et CentOS. Le journal de PHP-FPM est à côté, sous un nom qui contient le numéro de version, php8.3-fpm.log par exemple.
Quoi y chercher. Notez d'abord l'heure exacte à laquelle vous rechargez la page en panne, à la minute près, puis cherchez cette minute-là dans le fichier. Les termes utiles :
grep -nE "proxy_fcgi|AH01079|max_children|Connection refused" \
/var/log/apache2/error.log | tail -n 20
proxy_fcgi et le code AH01079 accompagnent les lignes où Apache dit qu'il n'a pas réussi à joindre PHP. max_children apparaît dans le journal de PHP-FPM quand le pool a atteint son plafond de processus, traduction technique de « trop de monde en même temps ». Sans terminal, ouvrez le fichier depuis le panneau et cherchez ces mêmes mots.
Et si le journal ne contient rien à l'heure exacte de votre test, alors que le 503 s'affiche bien, c'est que la requête n'est jamais arrivée jusqu'à votre serveur. Le code vient d'une couche placée devant, proxy, CDN ou pare-feu applicatif. C'est de ce côté qu'il faut aller regarder, et pas dans WordPress.
L'erreur 503 seulement sur /wp-admin
Le site public s'affiche parfaitement, les visiteurs ne voient rien d'anormal, et vous seul restez à la porte avec un 503 sur /wp-admin ou wp-login.php. Ce cas revient souvent dans les forums, il n'y est presque jamais résolu, et les gens y restent des semaines.
La dissymétrie vous apprend l'essentiel : le serveur répond, PHP fonctionne, WordPress démarre. Ce qui casse est propre à l'administration, plus gourmande que le site public. Vérifiez tout de même quelle page s'affiche : si c'est celle de WordPress, revenez à la section sur .maintenance, puisque pendant la fenêtre de dix minutes l'administration est fermée elle aussi.
Les pistes utiles, dans l'ordre où il faut les prendre. Une extension dont le code lourd ne se charge que sur les écrans d'administration. La limite mémoire de l'administration, qui n'est pas celle du site public. Une règle de pare-feu applicatif chez l'hébergeur, enfin, reconnaissable entre toutes : le 503 est reproductible à volonté sur une action précise, et le journal PHP reste vide, parce que le blocage est écrit dans un journal auquel les mutualisés ne donnent pas accès. C'est un des rares cas où il faut passer par le support, en lui demandant les règles déclenchées à l'heure de votre test.
La fausse piste la plus coûteuse
Renommer wp-content/plugins et wp-content/themes est le premier geste que montrent les vidéos les plus vues sur l'erreur 503. La plus regardée d'entre elles, plus de cent quarante mille vues, ne mentionne pas une seule fois le fichier .maintenance.
Sur l'écran de WordPress, ce geste ne peut rien donner : la vérification du mode maintenance a lieu au tout début du chargement, avant que la moindre extension ou le thème ne soient lus. Renommez les deux dossiers, la page affichée ne changera pas.
Il coûte même quelque chose : renommer le dossier plugins marque toutes les extensions comme désactivées, et il faudra les réactiver une par une même après avoir remis le nom d'origine, en retrouvant leurs réglages.
Sur l'écran du serveur, ce même geste a du sens, une fois les journaux lus. Renommez alors wp-content/plugins en wp-content/plugins-off, testez, remettez le nom, et réactivez par moitiés : avec quarante extensions, la dichotomie demande six essais au lieu de quarante.
Si rien n'a marché
Le 503 est intermittent et suit les heures de pointe. Vous êtes à l'étroit sur votre hébergement. Regardez la consommation du compte, et cherchez ce qui la fait grimper avant de payer une offre supérieure : un robot mal élevé, une extension qui interroge le serveur en permanence, une sauvegarde programmée en pleine journée.
Le message parle d'un serveur indisponible pour traiter la requête. La formulation « no server is available to handle this request » ne vient ni de WordPress ni d'Apache, mais d'un répartiteur de charge placé devant. La réponse est chez celui qui exploite cette couche.
Vous n'avez accès à aucun journal. Demandez au support les lignes correspondant à l'horaire exact d'un test que vous venez de faire, et formulez la demande en « aidez-moi à comprendre ce qui se passe » plutôt qu'en « réparez mon site ». La première obtient beaucoup plus souvent une réponse utile.
Le fichier .maintenance est introuvable et l'écran est bien celui de WordPress. Vérifiez la racine, celle qui contient wp-config.php, et que l'affichage des fichiers cachés est réellement actif. Certaines extensions de mode maintenance produisent une page de ce genre : sans mise à jour récente, cherchez du côté d'une extension activée par erreur.
Ce que nous ne faisons pas. Notre forfait couvre la panne : remettre le site en ligne et documenter la cause. Il ne couvre pas la reconstruction d'une mise en page abîmée dans un constructeur, ni la refonte d'un thème, ni le développement de fonctionnalités.
Si vous préférez ne pas y toucher, ou si vous avez déjà passé une heure dessus, c'est exactement le genre de panne qu'on traite en intervention. Le dépannage d'un site WordPress qui ne répond plus coûte 149 € HT, remis en ligne ou remboursé.
Comment éviter que ça recommence
Ne lancez pas vos mises à jour depuis une machine qui va se mettre en veille. Les blocages en maintenance viennent presque tous d'un onglet fermé ou d'une connexion coupée pendant l'opération. Laissez l'onglet ouvert et attendez que la mise à jour rende la main.
Ne cochez pas les quarante extensions d'un coup. La mise à jour groupée dépasse facilement le temps d'exécution alloué par l'hébergeur, et c'est là que le fichier .maintenance reste en place. Par paquets de cinq, l'opération est plus longue et ne casse rien.
Repérez à froid où votre hébergeur expose ses journaux, et notez le chemin exact de la racine de votre site. Chercher ces deux informations sous pression, avec un site hors ligne, coûte une heure.
Surveillez la consommation du compte. Un 503 de saturation prévient toujours : le site ralentit d'abord, parfois pendant des semaines. Le ralentissement est le signal, la page d'erreur n'est que la fin de l'histoire.
Questions fréquentes
Comment corriger l'erreur 503 ?
Commencez par lire la phrase affichée. « Indisponibilité temporaire pour cause de maintenance » vient de WordPress : supprimez le fichier .maintenance à la racine, après avoir activé l'affichage des fichiers cachés, sauf si la panne dure depuis plus de dix minutes, auquel cas ce fichier n'est déjà plus ce qui bloque. « due to maintenance downtime or capacity problems » vient du serveur : déposez un test.txt à la racine pour savoir s'il répond encore, puis lisez le journal d'erreurs à l'heure exacte de votre test. Désactiver ses extensions à l'aveugle avant ce tri ne sert à rien dans le premier cas.
C'est quoi l'erreur 503 ?
Un code de réponse HTTP qui signifie « le service est indisponible pour le moment ». Il ne dit rien de la cause, et il est renvoyé aussi bien par WordPress, qui s'en sert pour signaler une mise à jour en cours, que par le serveur web quand PHP ne lui répond pas. Deux pannes sans rapport derrière un même nombre.
Comment enlever le mode maintenance sur WordPress ?
Connectez-vous en FTP ou au gestionnaire de fichiers de l'hébergeur, activez l'affichage des fichiers cachés, placez-vous dans le dossier qui contient wp-config.php, et supprimez le fichier nommé .maintenance. Il commence par un point et n'a pas d'extension : ce n'est pas maintenance.php, nom qui circule dans les forums et qui n'existe pas. Rechargez ensuite le site, puis relancez la mise à jour interrompue depuis Tableau de bord, Mises à jour.
Pourquoi Service Unavailable ?
Parce que le serveur web n'a pas obtenu de réponse de PHP au moment où vous avez demandé la page. Pool saturé, limite de processus du compte atteinte, service PHP arrêté, incident chez l'hébergeur. C'est une panne de disponibilité, jamais un problème de contenu : votre base de données et vos fichiers sont intacts.
C'est quoi Error 503 Back-end Fetch failed ?
Ce message ne vient ni de WordPress ni d'Apache, mais de Varnish, un cache placé devant le site chez certains hébergeurs. Il signale que ce cache n'a pas réussi à récupérer la page auprès du serveur situé derrière lui. La panne est réelle et se trouve en dessous, mais le texte affiché vient d'une couche intermédiaire, et le journal de votre site peut rester vide pendant ce temps.