Vérifiez ce que signifie la page de maintenance
Vous avez lancé une mise à jour et le site affiche désormais un message d’indisponibilité pour maintenance. Quelques minutes plus tard, la page est toujours là. Avant de supprimer un fichier, il faut distinguer deux situations : une mise à jour travaille encore, ou une opération interrompue a laissé le site dans un état incohérent. Retirer le message ne suffit pas à prouver que tous les fichiers ont été correctement installés.
Le mode natif de WordPress utilise un fichier nommé .maintenance dans le répertoire principal de l’installation. Le point placé au début du nom compte. Ce fichier contient un repère temporel utilisé pendant la mise à jour. Il ne contient pas vos articles et n’est pas une sauvegarde du site. En revanche, des extensions et des hébergeurs proposent leurs propres pages de maintenance, qui ne dépendent pas toujours de ce fichier.
Commencez par relever le texte affiché et l’heure à laquelle la mise à jour a commencé. Regardez si la page contient la marque de l’hébergeur, un compte à rebours ou une présentation que vous aviez configurée auparavant. Ce sont des indices sur son origine, mais pas une preuve suffisante : la page native peut elle aussi être personnalisée.
Ce guide concerne surtout une installation WordPress dont vous pouvez consulter l’hébergement. Sur une offre gérée qui ne donne pas accès aux fichiers, utilisez la procédure proposée dans le compte client ou demandez au support de réaliser l’étape correspondante.
Choisissez votre approche et évitez les actions simultanées
Si la mise à jour est confirmée comme terminée ou interrompue et qu’un marqueur natif subsiste, suivez l’approche 1 avec le gestionnaire de fichiers. Si vous utilisez déjà SSH et WP-CLI, l’approche 2 permet la même intervention avec une commande explicite. Si le mode natif est inactif mais que la page demeure, passez à l’approche 3 pour retrouver une maintenance gérée ailleurs ou une réponse conservée en cache.
Ces chemins sont des alternatives, pas trois opérations à appliquer systématiquement. Ne lancez pas plusieurs réparations en parallèle. Une personne peut retirer le marqueur pendant qu’une autre remet des fichiers en place, ce qui expose aux visiteurs une installation encore incomplète. Prévenez les autres administrateurs et convenez d’un seul responsable de l’intervention.
Gardez ouvert l’onglet ayant lancé la mise à jour, s’il existe encore. Relevez son dernier message sans cliquer de nouveau sur le bouton de mise à jour. Fermer le navigateur ne garantit pas l’arrêt du traitement côté serveur ; un écran figé ne garantit pas non plus qu’il continue. Le journal de l’hébergeur ou son outil de gestion des mises à jour permet souvent de trancher.
Pour une boutique, notez aussi la dernière commande connue avant l’incident. Cette information deviendra utile si une restauration est envisagée. L’objectif est de remettre le site dans un état cohérent sans perdre les données reçues depuis la dernière sauvegarde.
Attendez la fin réelle de l’opération avant d’intervenir
Une maintenance de courte durée pendant une mise à jour est normale. Consultez l’écran d’administration ou le panneau de l’hébergeur pour voir si l’opération progresse, s’est achevée ou a échoué. Ne déduisez pas son état uniquement du nombre de secondes écoulées dans votre navigateur.
Dans son fonctionnement natif, WordPress ne considère plus le repère du fichier .maintenance comme actif lorsqu’il date d’au moins dix minutes. Ce délai se rapporte à la valeur enregistrée dans le fichier, pas simplement à l’heure visible dans le gestionnaire. Il n’existe donc pas de garantie selon laquelle n’importe quelle page de maintenance disparaîtra dix minutes après votre première visite.
Si le message persiste longtemps, le fichier peut être recréé par des opérations successives, une autre couche peut afficher sa propre maintenance, ou une ancienne réponse peut être mise en cache. Une horloge serveur incorrecte mérite aussi un contrôle lorsque les dates observées sont incohérentes. Évitez d’effacer le même fichier toutes les minutes sans identifier ce qui le recrée.
Lorsque vous n’avez aucun moyen de savoir si l’installation est encore en cours, demandez à l’hébergeur de vérifier le processus. Fournissez le domaine, l’heure de début et le composant mis à jour. Cette vérification précise est préférable à une demande de réinitialisation générale du site.
Préparez une copie de l’état actuel
Avant de poursuivre, repérez une sauvegarde complète et sa date. Vérifiez qu’elle contient les fichiers et la base de données. Un export des articles seul ne permet pas de reconstituer les thèmes, extensions, médias et réglages d’un site. Si la sauvegarde saine est ancienne, conservez aussi l’état actuel pour ne pas perdre les ajouts intervenus depuis.
Le panneau de l’hébergeur propose parfois un instantané ou une restauration sur une copie distincte. Utilisez cette possibilité quand elle existe. Une sauvegarde faite pendant une mise à jour inachevée peut capturer des fichiers provenant de plusieurs versions : elle sert à préserver l’état observé, mais ne doit pas être appelée sauvegarde saine sans contrôle.
Notez le nom du composant mis à jour, sa version précédente si elle est connue et la version visée. Conservez les messages d’erreur concernant le téléchargement, l’extraction, le stockage ou l’écriture. Ces informations orientent la réparation une fois le message de maintenance retiré.
Ne remettez pas immédiatement toute la base de données à l’état de la veille. Sur un site actif, cette opération peut effacer des commandes ou inscriptions récentes. Une restauration complète n’est appropriée que si ses conséquences sont comprises et si les données à préserver ont été traitées.
Approche 1 : retirer le marqueur natif depuis les fichiers
Ouvrez le gestionnaire de fichiers du compte d’hébergement ou votre accès SFTP habituel. Sélectionnez le domaine concerné et le bon répertoire. Cherchez les dossiers wp-admin, wp-includes et wp-content, qui permettent de reconnaître l’installation. S’il existe plusieurs copies, vérifiez le chemin indiqué dans la configuration du domaine avant de toucher à quoi que ce soit.
Activez l’affichage des fichiers cachés. Le fichier recherché s’appelle exactement .maintenance et se trouve à la racine de WordPress. Ne le confondez pas avec un dossier nommé maintenance, une page HTML ou maintenance.php dans wp-content. Ils n’ont pas le même rôle.
Une fois l’opération de mise à jour confirmée comme arrêtée, téléchargez une copie locale du marqueur pour conserver une trace, puis retirez uniquement ce fichier .maintenance du serveur. Utilisez l’action ciblée du gestionnaire : il n’y a aucune raison de supprimer un dossier complet ou tous les fichiers dont le nom contient maintenance.
Rechargez l’administration, puis une page publique. Si le site revient, passez aux contrôles des fichiers et des fonctions décrits plus bas. Si une erreur critique remplace la maintenance, vous avez découvert une seconde panne : l’installation a probablement besoin d’une réparation complémentaire. Ne recréez pas arbitrairement le marqueur pour cacher cette erreur et déclarer l’opération terminée.
Si le fichier est absent, la suppression proposée par de nombreux tutoriels ne s’applique pas à ce que vous observez. Passez à l’approche 3. S’il réapparaît immédiatement, relevez son heure et faites rechercher la tâche qui le crée avant toute nouvelle tentative.
Approche 2 : utiliser WP-CLI sur la bonne installation
Cette variante convient aux personnes disposant d’une session SSH autorisée et de WP-CLI déjà installé. Elle évite de manipuler le fichier à la main. Les mêmes prérequis s’appliquent : aucune mise à jour ne doit encore être en train d’écrire dans l’installation.
Placez-vous dans le répertoire WordPress concerné. Contrôlez le chemin et le domaine associés dans votre panneau d’hébergement, surtout si le compte contient plusieurs sites. Demandez d’abord l’état du mode de maintenance avec la commande de lecture ci-dessous. Exécutez ensuite la désactivation seulement si vous avez confirmé que le marqueur peut être retiré, puis demandez de nouveau l’état.
Le résultat de WP-CLI porte sur le mécanisme natif. Un état inactif ne prouve pas qu’une page de maintenance du CDN, de l’hébergeur ou d’une extension a été retirée. Ouvrez donc une URL publique après la commande. Si le terminal signale une erreur d’accès aux fichiers, faites corriger le propriétaire ou les permissions du chemin exact plutôt que de lancer la commande avec des droits excessifs par défaut.
Les trois lignes suivantes montrent l’ordre des commandes. Lisez le résultat de chacune avant d’exécuter la suivante ; ne les collez pas comme une réparation automatique sans vérifier le contexte.
wp maintenance-mode status
wp maintenance-mode deactivate
wp maintenance-mode statusApproche 3 : retrouver une maintenance gérée ailleurs
Si le marqueur natif est absent ou inactif, ouvrez le panneau d’hébergement. Cherchez une fonction de maintenance, un déploiement en cours ou une intervention annoncée. Certains services affichent une page devant WordPress : aucune modification de ses fichiers ne changera alors le résultat. Relevez le nom de la fonction active avant de la modifier.
Dans l’administration WordPress, examinez ensuite les outils que vous utilisiez déjà pour afficher une page d’attente. Une extension de maintenance peut laisser les administrateurs parcourir le site tout en présentant un écran différent aux visiteurs. Si c’est le cas, ouvrez son réglage et désactivez son mode de maintenance lorsque le site est prêt. Il n’est pas nécessaire de supprimer l’extension pour tester ce réglage.
Ne confondez pas cette maintenance avec une protection d’accès mise en place volontairement sur une préproduction. Retirer une authentification ou rendre une copie privée publique n’est pas une réparation de mise à jour. Vérifiez le domaine, l’environnement et l’intention avant de changer un réglage de visibilité.
Comparez enfin les réponses dans votre session connectée et dans une fenêtre privée. Si l’hébergeur confirme que la maintenance est terminée mais que certains visiteurs voient encore la page, purgez le cache correspondant dans l’outil déjà utilisé par le site. Ciblez le cache de page ou du CDN concerné, puis testez de nouveau. Un cache navigateur vidé ne purge pas à lui seul le cache du serveur.
Vérifiez si la mise à jour a laissé des fichiers incomplets
Le site s’ouvre de nouveau : prenez quelques minutes pour vérifier ce qui a réellement été installé. Dans Tableau de bord, puis Mises à jour, relevez l’état du cœur, du thème et des extensions concernés. Comparez avec l’opération lancée. Un numéro de version affiché ne garantit pas que tous les fichiers du paquet sont présents, mais il aide à identifier un écart évident.
Si le message initial mentionnait une extraction ou une copie échouée, ne relancez pas immédiatement le même lot de mises à jour. Recherchez d’abord la cause dans les journaux ou le panneau d’hébergement. Une nouvelle tentative dans un stockage saturé risque d’échouer au même endroit et de compliquer le diagnostic.
Lorsqu’une extension précise est incomplète, la remise en place d’un paquet officiel compatible peut être nécessaire. Préservez sa configuration et ses données ; l’action Supprimer dans l’administration peut déclencher une désinstallation. Vérifiez aussi si le composant contient des personnalisations locales. Une extension commerciale doit provenir du compte de son éditeur, pas d’une archive trouvée sur un site de téléchargement quelconque.
Pour le cœur de WordPress, suivez une procédure de remplacement adaptée à la version visée. Les dossiers du cœur et les fichiers de l’utilisateur n’ont pas le même rôle. Ne remplacez pas aveuglément wp-content, où se trouvent notamment thèmes, extensions et médias, ni wp-config.php, qui contient la configuration de l’installation. Si vous n’êtes pas à l’aise avec ces distinctions, faites réaliser cette remise en état par l’hébergeur à partir de votre relevé.
Contrôle complémentaire des fichiers du cœur avec WP-CLI
Les utilisateurs de WP-CLI peuvent comparer les fichiers du cœur avec les empreintes publiées pour WordPress. Cette vérification peut signaler un fichier manquant ou différent après une copie interrompue. Elle ne répare rien automatiquement et n’est pas un contrôle complet de tous les composants du site.
Exécutez la commande ci-dessous depuis la bonne installation. Si vous devez préciser une version ou une langue, utilisez celles réellement attendues pour votre paquet. Comparer une installation française à une référence différente peut produire des écarts qui demandent une interprétation. Gardez la sortie utile pour le support sans publier les chemins privés ou les informations du compte.
Un contrôle réussi ne prouve pas que la base, les extensions, les thèmes et les commandes clients sont tous en bon état. Un contrôle en échec ne prouve pas à lui seul une intrusion. Il indique des différences à examiner dans leur contexte. Ne contournez pas un problème de certificat en désactivant la vérification TLS pour terminer ce test : faites corriger la connexion ou utilisez une autre procédure de contrôle fiable.
wp core verify-checksumsCorrigez la cause avant de relancer une mise à jour
Le manque d’espace est une cause à vérifier concrètement. Le serveur peut avoir besoin de place pour télécharger une archive, l’extraire et conserver temporairement plusieurs ensembles de fichiers. Consultez l’espace utilisé et, lorsque le panneau l’indique, le quota de fichiers. Un compte peut atteindre sa limite de fichiers sans avoir utilisé tout son volume en gigaoctets.
Ne libérez pas de place en effaçant au hasard des médias ou une sauvegarde unique. Repérez les fichiers temporaires identifiés par l’hébergeur et les copies déjà archivées ailleurs. Si vous ne savez pas ce qui peut être retiré, demandez un relevé des répertoires les plus volumineux et une intervention ciblée. Conservez un point de restauration utilisable pendant toute l’opération.
Les permissions et le propriétaire des fichiers peuvent également empêcher l’écriture. Un transfert manuel effectué avec un autre compte peut produire un mélange de propriétaires. Demandez quel processus doit écrire dans le dossier concerné et faites ajuster ce chemin précisément. Appliquer 777 à toute l’installation élargit les droits sans garantir que la mise à jour fonctionnera.
Si le téléchargement échoue, vérifiez la communication avec le service officiel et les éventuels incidents d’hébergement. Si une limite d’exécution arrête régulièrement l’opération, faites examiner le traitement par le prestataire. Augmenter toutes les limites à l’aveugle ne distingue pas une archive trop lourde, un stockage lent et un composant défectueux.
Une fois la cause identifiée, relancez un seul composant et observez son résultat. Testez ensuite le site avant de passer au suivant. Cette méthode demande un peu plus d’attention qu’une relance globale, mais elle vous permet de savoir quelle étape réussit ou reproduit l’incident.
Traitez séparément les messages qui ressemblent à la même panne
Le message « Une autre mise à jour est déjà en cours » correspond à un mécanisme distinct du fichier .maintenance. Retirer ce fichier n’est donc pas une solution universelle à ce verrou. Vérifiez si une tâche est toujours active et laissez-la terminer. Si le verrou persiste après un échec confirmé, faites contrôler son état par l’hébergeur avant de modifier des valeurs dans la base de données.
De même, une erreur critique apparue à la fin de la maintenance nécessite d’examiner les journaux PHP, les versions et les composants chargés. Une page blanche ou une erreur 500 ne se corrige pas en supprimant encore le marqueur. Le guide consacré à l’erreur critique explique les parcours de récupération et l’isolement d’un composant fautif.
Sur une boutique, une mise à jour peut aussi lancer un traitement de données en arrière-plan. La page publique peut être revenue alors que ce traitement continue. Consultez les indications du composant concerné et évitez une nouvelle restauration pendant qu’il travaille. Si vous devez interrompre ou reprendre ce traitement, demandez une procédure adaptée à sa version et à l’état des données.
Rouvrez le site après une vérification complète
Testez d’abord l’accueil, un article et l’administration. Ajoutez ensuite les fonctions importantes pour votre activité : recherche, connexion, formulaire, panier ou commande en mode de test. Le retour d’une seule page ne suffit pas si l’extension mise à jour gère justement une fonction absente de cette page.
Vérifiez le comportement d’un visiteur déconnecté. Si vous utilisez les outils réseau du navigateur, regardez le statut de la réponse principale : le mécanisme natif de maintenance utilise une réponse temporaire 503, tandis qu’une page normale doit retrouver une réponse de succès adaptée. Une ancienne page de maintenance peut sembler disparaître visuellement tout en laissant une réponse incorrecte à certaines adresses.
Conservez une note courte : opération à l’origine de l’incident, cause trouvée, correction appliquée, versions finales et pages testées. Signalez clairement les fonctions qui n’ont pas pu être vérifiées. Par exemple, constater que le panier s’affiche n’est pas équivalent à avoir testé une notification de paiement de bout en bout.
Pour la prochaine mise à jour, préparez la sauvegarde, vérifiez l’espace disponible et choisissez un moment où vous pouvez contrôler le résultat. Utilisez une copie de test pour les changements sensibles. L’incident ne justifie pas d’abandonner durablement les mises à jour de sécurité : il faut rendre leur exécution plus fiable et savoir revenir en arrière lorsqu’une incompatibilité apparaît.
Faut-il installer une extension pour sortir de maintenance ?
Dans ce cas précis, ajouter une extension est rarement utile. Si WordPress s’arrête avant de charger ses composants, le nouvel outil ne pourra pas résoudre le problème. Les fichiers, le panneau d’hébergement et éventuellement WP-CLI fournissent déjà les moyens nécessaires au diagnostic et au retrait du marqueur natif.
Une extension de maintenance peut servir plus tard à préparer une page d’attente personnalisée pour une intervention volontaire. Ce besoin est différent de la réparation d’une mise à jour échouée. Choisissez-la uniquement si ses fonctions vous sont utiles, puis vérifiez comment elle s’active, qui peut contourner la page et comment elle se désactive. Elle ne doit pas devenir un écran qui masque durablement une panne non résolue.
Si vous demandez de l’assistance, envoyez le domaine, le dernier message de mise à jour, l’heure, l’état du marqueur et les contrôles déjà effectués. Ajoutez si des commandes récentes doivent absolument être conservées. Avec ces éléments, le support peut intervenir sur la cause probable sans recommencer toutes les manipulations ni proposer immédiatement une restauration complète.
