Sortir WordPress du mode maintenance en 2 minutes

Si votre site affiche soudain « Briefly unavailable for scheduled maintenance » et refuse de revenir, vous êtes presque toujours à un fichier .maintenance resté coincé après une mise à jour.

Le problème

Le message typique (front-end et parfois wp-admin) ressemble à ceci :

Briefly unavailable for scheduled maintenance. Check back in a minute.

Vous le voyez généralement :

Après une mise à jour (WordPress 6.9.4, un plugin, un thème), surtout si la connexion a coupé au milieu.
Après une mise à jour “en lot” (10+ plugins d’un coup), ou via un outil de cache/optimisation qui interfère.
Sur le front-end (les visiteurs sont bloqués), et parfois aussi dans /wp-admin/ selon la configuration.
Sur un hébergement mutualisé où les droits fichiers sont serrés, ou avec une limite CPU/IO qui fait “time out” la mise à jour.

À la fin, vous saurez :

Sortir du mode maintenance en 2 minutes (suppression du fichier .maintenance).
Vérifier pourquoi ça a coincé (droits, cache, PHP, plugin fautif).
Relancer proprement la mise à jour sans retomber dans le piège.

Résumé rapide

Le “mode maintenance bloqué” est presque toujours un fichier .maintenance oublié à la racine de WordPress.
Solution express : via FTP/gestionnaire de fichiers, supprimez /.maintenance.
Ensuite : retentez la mise à jour (de préférence en une seule action) et vérifiez les droits et les logs.
Si ça revient : suspectez un plugin (cache/sécurité), une limite PHP, ou un hébergeur qui coupe les processus.
Pour les sites pro : WP-CLI permet de vérifier/relancer plus proprement.

Les symptômes

Les symptômes ne se limitent pas au message de maintenance. J’ai souvent vu des sites “à moitié” mis à jour, et c’est là que les ennuis commencent.

Message de maintenance sur tout le site, y compris la page d’accueil.
wp-admin inaccessible ou redirection vers la maintenance.
Erreur 500 après suppression du .maintenance (mise à jour incomplète, PHP fatal).
Écran blanc (fatal error) après mise à jour d’un plugin majeur (builder, sécurité, e-commerce).
Boutons “Mettre à jour” qui tournent en boucle dans /wp-admin/ (AJAX bloqué, cache admin, conflit plugin).
Site cassé seulement pour certains visiteurs (cache CDN ou cache serveur qui sert une ancienne réponse).

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Message “Briefly unavailable…”	Fichier `.maintenance` resté présent	Présence de `/.maintenance` à la racine WP	Supprimer `.maintenance` (Solution 1)
Message revient après 1-2 minutes	Mise à jour relancée en boucle / cron / outil auto-update	Regarder “Mises à jour auto” + logs + cache	Désactiver temporairement auto-update + corriger cause racine (Solution 3)
Après suppression : erreur 500	Mise à jour incomplète, conflit plugin, PHP fatal	Logs PHP / WP_DEBUG	Désactiver plugins, réinstaller plugin/thème, vérifier PHP (Solution 3)
Seulement sur front-end, admin OK	Cache/CDN sert la page maintenance	Test en navigation privée + purge cache	Purger cache plugin/serveur/CDN (Solution 3)
wp-admin bloqué mais front OK	Cache admin, plugin sécurité, cookies/session	Console navigateur + désactivation plugin sécurité	Vider cache + désactiver plugin (Solution 3)

Pourquoi ça arrive

Explication simple (débutant)

Quand WordPress met à jour le cœur, un plugin ou un thème, il active un “mode maintenance” temporaire pour éviter que des visiteurs chargent des fichiers en plein remplacement. Ce mode est matérialisé par un fichier nommé .maintenance dans le dossier principal de WordPress.

Normalement, WordPress supprime ce fichier à la fin de la mise à jour. Si la mise à jour s’interrompt (coupure réseau, timeout serveur, manque de droits), le fichier reste. Résultat : votre site reste bloqué en maintenance.

Explication technique (intermédiaire/pro)

Le mode maintenance est déclenché pendant les opérations d’upgrade (core et “upgrader” des extensions). WordPress écrit un fichier .maintenance à la racine (même niveau que wp-config.php). À chaque chargement, WordPress teste sa présence et son horodatage, puis sert la page de maintenance si l’upgrade est considéré en cours.

Ce qui fait coincer, dans mon expérience :

Timeout PHP pendant le dézip/copie (gros plugins, builders, packs de langue).
Droits fichiers : WordPress ne peut pas supprimer .maintenance ou écrire dans wp-content/.
Cache agressif (plugin cache, cache serveur, CDN) qui continue à servir la page “maintenance” même après correction.
Auto-updates qui relancent une mise à jour immédiatement et recréent .maintenance.
Conflit plugin (sécurité, optimisation) qui bloque les requêtes sortantes ou l’écriture disque.

Prérequis avant de commencer

Sauvegardez avant de modifier quoi que ce soit. Même si la solution est “juste supprimer un fichier”, le vrai risque est la mise à jour incomplète derrière.

Une sauvegarde fichiers + base de données (via l’hébergeur, ou un plugin de sauvegarde fiable).
Accès aux fichiers : FTP/SFTP, ou gestionnaire de fichiers (cPanel, Plesk, Manager OVH, etc.).
Version cible : WordPress 6.9.4 (avril 2026) et PHP 8.1+ recommandé. Vérifiez la compatibilité PHP sur php.net.
Outils utiles :
- Plugin Query Monitor (diagnostic requêtes/erreurs).
- Plugin Health Check & Troubleshooting (désactivation plugins sans impacter les visiteurs).

Pour le debug, la référence officielle reste Debug WordPress sur developer.wordpress.org.

Solution 1 : supprimer le fichier .maintenance (la vraie sortie en 2 minutes)

C’est la méthode la plus rapide, et celle que j’utilise en premier sur 90% des cas.

Où agir exactement

Dans le dossier racine de WordPress : là où se trouvent généralement wp-config.php, wp-admin/, wp-includes/.
Le fichier est nommé : .maintenance (avec un point au début). Certains gestionnaires de fichiers masquent les fichiers “dotfiles”. Activez “Afficher les fichiers cachés”.

Étapes (FTP/SFTP ou gestionnaire de fichiers)

Connectez-vous à votre site en SFTP/FTP ou via le gestionnaire de fichiers.
Ouvrez le dossier racine de WordPress.
Repérez .maintenance.
Supprimez .maintenance.
Rechargez votre site (idéalement en navigation privée).

Code AVANT / APRÈS (pour comprendre ce que vous supprimez)

Le fichier .maintenance contient souvent une petite structure PHP. Exemple réaliste :

AVANT (cassé : le fichier reste présent)

<?php
/* Fichier généré automatiquement par WordPress pendant une mise à jour */
$upgrading = 1712700000;

APRÈS (corrigé : le fichier n’existe plus)

<?php
/* Rien ici : le fichier .maintenance a été supprimé */

Oui, l’“APRÈS” paraît idiot, mais c’est exactement l’idée : vous ne devez pas “corriger” ce fichier, vous devez le supprimer.

Pourquoi ça corrige le problème

WordPress teste la présence de ce fichier au chargement. Tant qu’il existe, WordPress considère qu’une mise à jour est en cours (ou l’a été récemment) et bascule sur la page maintenance. En le supprimant, vous forcez WordPress à reprendre un fonctionnement normal.

Si le fichier revient immédiatement

Ça arrive quand une mise à jour automatique tourne en boucle (cron) ou qu’un outil de management relance l’upgrade. Dans ce cas, supprimez .maintenance puis passez directement à la Solution 3.

Solution 2 : sortir du mode maintenance via WP-CLI (rapide et propre)

WP-CLI est la ligne de commande officielle de WordPress. Sur des hébergements un peu sérieux (ou un VPS), c’est souvent plus fiable que l’interface web quand l’admin est instable.

Référence officielle : WP-CLI Commands.

Prérequis

Avoir un accès SSH.
Avoir WP-CLI installé (souvent déjà présent).
Être dans le dossier WordPress (là où se trouve wp-config.php).

Commandes utiles

1) Vérifier que vous êtes au bon endroit

wp core version

2) Supprimer le fichier .maintenance (équivalent Solution 1)

rm -f .maintenance

3) Vérifier l’état des mises à jour

wp core check-update
wp plugin list --update=available
wp theme list --update=available

4) Relancer proprement une mise à jour (à faire avec prudence)

wp core update
wp plugin update --all
wp theme update --all

Sécurité : ne lancez pas un update --all en production si vous n’avez pas de sauvegarde et un plan de rollback. J’ai vu des sites se casser sur une mise à jour de builder (Divi/Elementor/Avada) faite “en aveugle”.

Code AVANT / APRÈS (erreur fréquente)

Erreur classique : lancer WP-CLI depuis le mauvais dossier (vous n’êtes pas dans l’installation WordPress).

AVANT (cassé)

cd ~
wp plugin update --all
# Error: This does not seem to be a WordPress installation.

APRÈS (corrigé)

cd /var/www/votre-site/public_html
wp plugin update --all

Solution 3 : corriger la cause racine (mise à jour qui boucle, droits, cache, PHP)

Sortir du mode maintenance est la partie facile. Si vous ne corrigez pas la cause, vous risquez une rechute à la prochaine mise à jour, ou pire : un site partiellement mis à jour.

3.1 Vérifier et corriger les droits fichiers (permissions)

Symptôme typique : la mise à jour démarre, puis échoue, puis WordPress reste en maintenance ou ne termine pas l’installation.

Dossiers : souvent 755
Fichiers : souvent 644

Sur Linux via SSH (à adapter à votre hébergement) :

# À exécuter dans la racine WordPress
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Si votre hébergeur utilise un propriétaire/groupe spécifique (www-data, nginx, etc.), un chown peut être nécessaire, mais sur mutualisé vous ne l’aurez pas. Dans ce cas : ticket hébergeur.

Référence : File Permissions (developer.wordpress.org).

3.2 Purger le cache (plugin, serveur, CDN) pour arrêter de servir la page maintenance

J’ai souvent vu le fichier .maintenance supprimé… mais le visiteur voit encore la page maintenance parce qu’un cache la sert.

Cache navigateur : testez en navigation privée.
Plugin cache : purgez depuis son interface (si accessible) ou supprimez temporairement son dossier cache (selon plugin).
Cache serveur (LiteSpeed, Nginx FastCGI cache, Varnish) : purge via panel hébergeur.
CDN (Cloudflare, etc.) : purge “Everything” si nécessaire.

Si vous utilisez un builder :

Divi 5 : purgez le cache Divi (et le cache statique si activé), puis régénérez si besoin.
Elementor : “Outils” > “Régénérer les fichiers CSS & données”.
Avada : “Performance” > purge des caches/compilations.

Ces actions ne “réparent” pas WordPress, mais elles évitent un faux diagnostic (“ça ne marche pas”) alors que c’est juste une page en cache.

3.3 Vérifier PHP (version, limites, timeout) et les erreurs fatales

WordPress 6.9.4 tourne très bien en PHP 8.1+. Si vous êtes encore en PHP 7.4/8.0 sur un vieux serveur, vous augmentez le risque d’échec de mise à jour et d’incompatibilités plugins.

Référence PHP : php.ini directives.

Activez temporairement le debug WordPress (sur un site de test si possible). Dans wp-config.php, ajoutez/ajustez :

<?php
/* Sauvegardez avant modification. À placer dans wp-config.php, avant "/* That's all, stop editing! */" */

/* Active le debug WordPress */
define( 'WP_DEBUG', true );

/* Écrit les erreurs dans wp-content/debug.log */
define( 'WP_DEBUG_LOG', true );

/* Évite d'afficher les erreurs aux visiteurs (sécurité) */
define( 'WP_DEBUG_DISPLAY', false );

Ensuite, consultez wp-content/debug.log. Une erreur fréquente après mise à jour incomplète ressemble à :

PHP Fatal error:  Uncaught Error: Class "..." not found in /wp-content/plugins/...

Dans ce cas, la mise à jour du plugin a probablement été interrompue. La correction “propre” :

Renommer le dossier du plugin pour le désactiver (ex. nom-plugin → nom-plugin.off).
Réinstaller le plugin depuis une source fiable (ZIP officiel) si nécessaire.

Référence debug : Debug WordPress.

3.4 Réparer une mise à jour interrompue (plugins/thèmes)

Cas très courant : la mise à jour a supprimé l’ancien dossier, mais n’a pas fini de copier le nouveau.

Procédure (sans code) :

Supprimez .maintenance.
Dans wp-content/plugins/, repérez le plugin mis à jour juste avant le blocage.
Renommez son dossier pour le désactiver.
Reconnectez-vous à wp-admin si possible.
Réinstallez le plugin (ou uploadez une version propre).

Pour les thèmes, même logique dans wp-content/themes/. Attention : si vous supprimez/renommez le thème actif, WordPress basculera sur un thème par défaut si disponible.

3.5 “Code AVANT / APRÈS” : le snippet qui provoque une mise à jour qui échoue

Je le vois régulièrement : un snippet ajouté dans functions.php (ou via un plugin de snippets) casse l’admin pendant une mise à jour. Résultat : la mise à jour se lance, puis la requête suivante plante, et vous restez coincé.

AVANT (cassé : erreur de syntaxe, mise à jour interrompue)

<?php
/* Mauvais exemple : une parenthèse manque, PHP plante */
add_action( 'admin_init', function() {
	if ( current_user_can( 'manage_options' ) {
		update_option( 'mon_option', '1' );
	}
} );

APRÈS (corrigé)

<?php
/* Bon exemple : syntaxe valide, et conditions claires */
add_action( 'admin_init', function() {
	if ( current_user_can( 'manage_options' ) ) {
		update_option( 'mon_option', '1' );
	}
} );

Si vous avez ajouté du code récemment, désactivez-le temporairement le temps de stabiliser le site. Et évitez de coller des snippets “trouvés sur un forum” qui datent de 2017 : beaucoup sont incompatibles PHP 8.1+.

Vérifications après correction

Ne vous contentez pas de voir la home revenir. Vérifiez que la mise à jour n’a pas laissé un état incohérent.

Front-end : chargez 2-3 pages (accueil, article, page contact).
Admin : connectez-vous à /wp-admin/ et allez dans “Mises à jour”.
Extensions : vérifiez qu’il n’y a pas d’extensions “désactivées involontairement”.
Site Health : Outils > Santé du site. C’est basique, mais ça remonte souvent une erreur de boucle cron ou de mail.
Logs : regardez wp-content/debug.log (si activé) et désactivez WP_DEBUG ensuite.
Cache : purge cache plugin/serveur/CDN une dernière fois.

Quand tout est OK, revenez à un mode normal :

<?php
/* Une fois le diagnostic terminé, évitez de laisser WP_DEBUG à true en production */
define( 'WP_DEBUG', false );

Si ça ne marche toujours pas

Quand la suppression de .maintenance ne suffit pas, le site est souvent dans un état “mi-upgradé”. Voici une procédure que j’applique sur des sites clients, dans cet ordre.

Étape 1 : confirmer que .maintenance n’existe plus

Vérifiez la racine WordPress.
Attention aux caches : testez en navigation privée + autre réseau si possible.

Étape 2 : désactiver tous les plugins sans wp-admin

Renommez le dossier wp-content/plugins en plugins.off. WordPress désactivera tout.

Ensuite testez le site. Si ça revient, un plugin est en cause. Remettez plugins, puis renommez plugin par plugin.

Étape 3 : basculer temporairement sur un thème par défaut

Renommez le thème actif (dossier dans wp-content/themes/) pour forcer WordPress à basculer sur un thème par défaut présent.

Sur des sites Divi/Elementor/Avada, c’est utile pour isoler :

un problème de builder après update,
ou un enfant de thème (child theme) avec un functions.php cassé.

Étape 4 : vérifier les erreurs côté navigateur

Ouvrez la console (F12) et regardez :

Erreurs 403/404 sur admin-ajax.php (souvent sécurité ou cache).
Erreurs CORS (souvent CDN / configuration serveur).
JS cassé qui empêche l’admin de finir une action.

Étape 5 : vérifier la REST API si l’admin “tourne”

Les mises à jour et l’admin moderne s’appuient sur des requêtes API. Si la REST API est bloquée, vous pouvez avoir des comportements bizarres.

Référence : REST API Handbook.

Étape 6 : utiliser Health Check en mode dépannage

Le plugin Health Check permet de désactiver les plugins uniquement pour vous (les visiteurs gardent la version “normale”). C’est très pratique quand le site est en prod.

Étape 7 : réinstaller WordPress core (sans toucher au contenu)

Si vous suspectez un core partiellement écrasé :

Téléchargez la version officielle depuis wordpress.org/download.
Ré-uploadez wp-admin et wp-includes (et les fichiers PHP racine), sans toucher à wp-content ni wp-config.php.

Ça règle beaucoup de “mises à jour core interrompues” sans toucher à vos contenus.

Pièges et erreurs courantes

Symptôme	Cause probable	Solution recommandée
Vous ne trouvez pas `.maintenance`	Fichiers cachés non affichés	Activer “Afficher fichiers cachés” dans le gestionnaire, ou utiliser SFTP/SSH
Vous supprimez `.maintenance` mais le message reste	Cache CDN/serveur/plugin	Purger caches + test navigation privée
Après suppression : erreur 500	Plugin mis à jour partiellement / fatal PHP	Consulter logs, renommer plugin fautif, réinstaller proprement
Vous avez collé un snippet “pour régler la maintenance”	Code au mauvais endroit / hook inadapté	Supprimer le snippet, revenir à la suppression du fichier `.maintenance`
Vous modifiez des fichiers du core	Correction non persistante, risque sécurité	Ne jamais modifier le core ; réinstaller proprement le core si besoin
Mise à jour qui échoue toujours au même plugin	Incompatibilité PHP / manque mémoire / plugin corrompu	Mettre PHP à jour, augmenter mémoire, réinstaller le plugin, contacter l’éditeur
Permaliens cassés après retour	Rewrite rules non régénérées	Réglages > Permaliens > Enregistrer (sans changer)

Erreurs “humaines” que je vois vraiment :

Copier du code dans le mauvais fichier (ex. dans wp-config.php au lieu de functions.php), puis écran blanc.
Oublier un point-virgule dans un snippet, ce qui casse l’admin au pire moment.
Tester en production sans sauvegarde “parce que c’est juste une mise à jour”. C’est rarement “juste”.
Suivre un vieux tutoriel (pré-PHP 8) qui conseille des manipulations risquées ou obsolètes.

Variante / alternative

Méthode sans code : passer par l’hébergeur

Si vous n’avez pas FTP/SFTP :

Ouvrez le gestionnaire de fichiers (cPanel/Plesk/outil maison).
Affichez les fichiers cachés.
Supprimez .maintenance.

C’est souvent la méthode la plus simple pour les débutants.

Méthode plus avancée : mu-plugin de “sécurité” (temporaire) pour forcer la sortie

Je ne recommande pas ça en premier, mais en dépannage sur un site où .maintenance réapparaît et où vous devez reprendre la main pour diagnostiquer, vous pouvez ajouter un mu-plugin (plugin “must-use”) qui supprime .maintenance au chargement.

Attention : c’est un contournement. Si une mise à jour est réellement en cours, vous pouvez créer un état incohérent. À utiliser temporairement, le temps d’identifier la cause (cron/auto-update).

Où coller le code : créez le fichier wp-content/mu-plugins/force-remove-maintenance.php. Si le dossier mu-plugins n’existe pas, créez-le.

Code AVANT (cassé : rien n’empêche la maintenance de rester)

<?php
/* Aucun mu-plugin : WordPress reste bloqué si .maintenance persiste */

Code APRÈS (corrigé : suppression automatique)

<?php
/**
 * Plugin Name: Force remove .maintenance (temporaire)
 * Description: Supprime le fichier .maintenance s'il est présent. À retirer après dépannage.
 * Author: Votre Nom
 */

/* Sécurité : empêcher l'accès direct */
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'plugins_loaded', function() {
	/* Chemin du fichier .maintenance à la racine WordPress */
	$maintenance_file = ABSPATH . '.maintenance';

	/* Si le fichier existe, on tente de le supprimer */
	if ( file_exists( $maintenance_file ) ) {
		/* @ est volontaire : on évite de casser le site si permissions insuffisantes */
		@unlink( $maintenance_file );
	}
}, 1 );

Une fois le site accessible, supprimez ce mu-plugin et corrigez la cause racine (auto-update qui boucle, droits, cache, etc.).

Éviter ce problème à l’avenir

Vous ne pourrez pas empêcher tous les incidents, mais vous pouvez réduire drastiquement les risques.

Bonnes pratiques concrètes

Évitez les mises à jour en lot sur un site fragile. Faites core, puis plugins critiques (builder/sécurité), puis le reste.
Faites les mises à jour hors pic (moins de trafic, moins de risques de processus concurrents).
Gardez PHP à jour (8.1+ recommandé) et surveillez les limites (temps d’exécution, mémoire).
Utilisez un environnement de staging si vous avez Divi 5, Elementor ou Avada : une mise à jour de builder peut casser le rendu.
Évitez les plugins “snippets” non maîtrisés en prod. Un snippet cassé au mauvais moment peut faire échouer une mise à jour.

Un petit garde-fou : vérifier l’écriture disque

Si vous avez souvent des mises à jour qui échouent, testez si WordPress peut écrire dans wp-content. Vous pouvez créer un mini plugin de test (à supprimer ensuite).

Où coller le code : créez wp-content/plugins/test-ecriture/test-ecriture.php, activez-le, puis supprimez-le après test.

<?php
/**
 * Plugin Name: Test d'écriture wp-content (temporaire)
 * Description: Ajoute une page d'admin qui teste l'écriture dans wp-content/uploads.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'admin_menu', function() {
	add_management_page(
		'Test écriture',
		'Test écriture',
		'manage_options',
		'test-ecriture',
		function() {
			echo '<div class="wrap"><h2>Test écriture</h2>';

			$upload_dir = wp_upload_dir();
			$path       = trailingslashit( $upload_dir['basedir'] ) . 'test-ecriture.txt';
			$content    = "Test à " . gmdate( 'c' ) . "n";

			$result = @file_put_contents( $path, $content, FILE_APPEND );

			if ( false === $result ) {
				echo '<p><strong>Échec</strong> : impossible d’écrire dans uploads. Vérifiez permissions/propriétaire.</p>';
			} else {
				echo '<p><strong>OK</strong> : écriture réussie dans ' . esc_html( $path ) . '.</p>';
			}

			echo '</div>';
		}
	);
} );

Si ce test échoue, vos mises à jour échoueront aussi tôt ou tard. Corrigez les permissions/propriétaires avec l’hébergeur.

Ressources

Questions fréquentes

Le fichier .maintenance est-il dangereux ?

Non, ce n’est pas un malware. C’est un mécanisme normal de WordPress. Le problème, c’est quand il reste présent alors que la mise à jour est terminée (ou a échoué).

Je ne vois pas .maintenance en FTP, c’est normal ?

Oui. Beaucoup d’outils cachent les fichiers qui commencent par un point. Activez “Afficher les fichiers cachés” (dotfiles).

Est-ce que je peux juste attendre ?

Parfois, oui : WordPress sort souvent tout seul du mode maintenance en moins d’une minute. Si ça dure plus de 2–3 minutes, c’est généralement bloqué : supprimez .maintenance.

Après suppression, j’ai une erreur 500. Qu’est-ce que ça veut dire ?

Souvent qu’un plugin/thème a été mis à jour partiellement, ou qu’un fatal PHP est apparu. Regardez les logs (ou activez WP_DEBUG_LOG), puis désactivez le plugin fautif en renommant son dossier.

Est-ce que Divi 5 / Elementor / Avada peuvent provoquer ça ?

Ils ne “provoquent” pas directement le mode maintenance, mais leurs mises à jour sont parfois lourdes. Sur un hébergement limité, ça augmente les risques de timeout. Après correction, purge des caches et régénération des assets du builder peuvent être nécessaires.

Le message reste affiché uniquement pour certains visiteurs

Ça sent le cache (CDN, cache serveur, cache navigateur). Purgez et testez depuis un autre appareil/réseau.

Est-ce que je dois modifier wp-settings.php ou un fichier du core ?

Non. Ne modifiez jamais le core pour ça. Supprimez .maintenance, puis corrigez la cause (permissions, plugin, timeout). Si le core est abîmé, ré-uploadez wp-admin et wp-includes depuis la version officielle.

Comment éviter que .maintenance revienne tout seul ?

Quand il revient, c’est qu’une mise à jour est relancée (auto-update, cron, outil hébergeur) ou qu’elle échoue systématiquement. Corrigez les droits, la version PHP, la mémoire, et mettez à jour plugin par plugin.

Je peux faire ça depuis la base de données ?

Non. Le mode maintenance bloqué ici est un fichier sur disque. La base de données peut refléter une mise à jour incomplète, mais supprimer .maintenance se fait au niveau fichiers.

Quel est le test le plus fiable pour confirmer que c’est réglé ?

Vérifiez que .maintenance n’existe plus, chargez le front-end en navigation privée, puis allez dans /wp-admin/ > Mises à jour et vérifiez qu’aucune mise à jour n’est “en cours” ou en échec.