Débloquer WordPress après l’erreur de maintenance

Le problème

Si vous venez de lancer une mise à jour et que votre site affiche soudain “maintenance”, vous êtes probablement tombé sur le verrou le plus frustrant de WordPress : le mode maintenance qui ne se désactive pas.

Le message exact ressemble à ça :

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

Où ça apparaît :

Front-end (site public) : la page “maintenance” remplace tout.
Back-office (/wp-admin/) : parfois inaccessible, parfois partiellement accessible.
REST API / AJAX : certains appels renvoient du HTML “maintenance” au lieu de JSON, ce qui casse Elementor, Divi 5, Avada/Fusion, ou l’éditeur de blocs.
WP-Cron : des tâches planifiées peuvent échouer tant que le verrou est présent.

Les circonstances typiques :

Juste après une mise à jour WordPress 6.9.4 (ou une mise à jour de plugin/thème) qui a échoué ou a été interrompue (onglet fermé, timeout, mémoire insuffisante).
Après une mise à jour “en chaîne” (beaucoup de plugins d’un coup) sur un hébergement un peu lent.
Après une tentative d’auto-update pendant un pic de trafic ou un problème disque.

À la fin, vous saurez :

Identifier le fichier .maintenance et le supprimer en sécurité.
Comprendre pourquoi WordPress reste bloqué (et ce qui se passe en coulisses).
Relancer une mise à jour proprement (sans casser le site).
Diagnostiquer les causes “invisibles” (cache, permissions, PHP, conflit plugin, manque d’espace disque).

Résumé rapide

Le message “Briefly unavailable…” est presque toujours causé par un fichier .maintenance resté dans la racine du site.
Supprimez .maintenance via FTP/SFTP ou le gestionnaire de fichiers de l’hébergeur, puis rechargez le site.
Si ça revient, une mise à jour est bloquée (timeout, permissions, manque de mémoire, espace disque, ou conflit).
Vérifiez WP_DEBUG, les logs PHP, et utilisez Health Check + Query Monitor pour isoler le problème.
En cas de site pro, WP-CLI permet de relancer/finir les updates et de vérifier l’état du core sans passer par le navigateur.

Les symptômes

Vous n’aurez pas toujours “juste” la page de maintenance. J’ai souvent vu des variantes qui induisent en erreur, surtout avec des page builders.

Le site affiche la page de maintenance partout, même après 10 minutes.
/wp-admin/ inaccessible ou redirige vers la maintenance.
Erreur 500 après suppression de .maintenance (souvent parce que la mise à jour a laissé un plugin dans un état incomplet).
Écran blanc (fatal error PHP) si un plugin mis à jour partiellement provoque une erreur.
Elementor : l’éditeur charge puis affiche des erreurs “JSON” ou “The response is not a valid JSON response” si la REST API reçoit du HTML.
Divi 5 : le Visual Builder reste sur un chargement infini, ou affiche une erreur AJAX.
Avada : Fusion Builder ne charge pas, ou des modules disparaissent.
Les mises à jour restent “en cours” dans le tableau de bord, ou la page “Mises à jour” boucle.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Page “Briefly unavailable…” partout	.maintenance resté en place	Présence du fichier à la racine WP	Supprimer .maintenance
Ça revient après suppression	Mise à jour relancée automatiquement et re-bloquée	Logs PHP / timeout / espace disque	Relancer update proprement + corriger la cause
Après suppression, erreur 500	Plugin/thème partiellement mis à jour	WP_DEBUG + logs serveur	Réinstaller plugin/thème, désactiver, ou rollback
Admin OK, front KO (cache)	Cache page/CDN sert encore la maintenance	Test en navigation privée + purge cache	Purger cache plugin + serveur + CDN
Éditeur Elementor/Divi cassé	REST API reçoit HTML maintenance	Tester /wp-json/	Supprimer .maintenance + vérifier erreurs

Pourquoi ça arrive

Explication simple (débutants)

Quand WordPress installe une mise à jour (core, plugin ou thème), il active temporairement un mode maintenance pour éviter que des visiteurs chargent des fichiers “à moitié remplacés”.

Ce mode maintenance est déclenché par un petit fichier nommé .maintenance placé à la racine de votre installation WordPress (au même niveau que wp-config.php).

Normalement, WordPress supprime ce fichier dès que la mise à jour se termine. Si la mise à jour échoue ou est interrompue, le fichier reste… et le site reste bloqué.

Explication technique (intermédiaires/pros)

Le mode maintenance est géré par le système d’upgrade de WordPress (classe WP_Upgrader et fonctions associées). Lors d’un upgrade, WordPress écrit un fichier .maintenance contenant un timestamp. Au chargement, WordPress détecte ce fichier et affiche le message de maintenance tant que le délai n’est pas écoulé ou tant que le fichier existe (selon le contexte).

Ce qui fait durer le problème dans la vraie vie : un processus PHP interrompu (timeout), une limite mémoire, un disque plein, des permissions empêchant la suppression du fichier, ou un cache qui sert encore la page de maintenance.

Causes probables (du plus fréquent au plus rare)

Interruption de mise à jour (onglet fermé, timeout PHP, “504 Gateway Timeout”).
Permissions fichiers incorrectes (WordPress ne peut pas supprimer .maintenance ou remplacer des fichiers).
Cache (plugin de cache, cache serveur, CDN) qui sert encore la maintenance.
Espace disque insuffisant lors de l’extraction d’une archive.
Conflit plugin (un plugin de sécurité/backup bloque l’écriture, ou un “snippet” casse l’admin pendant l’update).
Problème réseau vers wordpress.org (téléchargement interrompu).
Version PHP trop ancienne ou environnement instable (moins probable en 2026, mais fréquent sur de vieux hébergements).

Prérequis avant de commencer

Avant de toucher aux fichiers, faites simple et prudent. Une mauvaise manipulation à la racine peut casser le site.

Sauvegarde : au minimum, une sauvegarde des fichiers + base de données (ou un snapshot hébergeur). Ne testez pas “au hasard” en production.
Accès fichiers : FTP/SFTP (idéalement SFTP) ou gestionnaire de fichiers (cPanel, Plesk, panel hébergeur).
WordPress : ce guide cible WordPress 6.9.4 (avril 2026) et reste valable pour les versions 6.9.x+.
PHP : visez PHP 8.1+ (minimum recommandé). Vérifiez la version dans l’espace hébergeur.

Outils utiles (facultatifs mais très pratiques) :

Health Check & Troubleshooting (mode dépannage sans casser le site pour les visiteurs).
Query Monitor (voir erreurs PHP, hooks, requêtes, appels HTTP).
Activer WP_DEBUG (temporairement) pour capturer l’erreur réelle.

Documentation officielle à garder sous la main :

Solution 1 : supprimer le fichier .maintenance (le cas le plus fréquent)

Dans la majorité des dépannages, j’ouvre le serveur, je supprime .maintenance, et le site repart immédiatement. C’est la solution la plus simple, et elle ne nécessite aucun code.

Où se trouve .maintenance

Le fichier .maintenance se trouve à la racine de WordPress :

au même niveau que wp-admin, wp-includes
au même niveau que wp-config.php

Attention : le fichier commence par un point, donc il peut être caché dans certains gestionnaires de fichiers. Activez l’affichage des fichiers cachés (“dotfiles”).

Étapes (FTP/SFTP ou gestionnaire de fichiers)

Connectez-vous en SFTP/FTP ou ouvrez le gestionnaire de fichiers de l’hébergeur.
Allez dans le dossier où se trouve wp-config.php.
Repérez .maintenance.
Sauvegardez le fichier sur votre ordinateur (optionnel mais prudent).
Supprimez .maintenance.
Rechargez votre site (et /wp-admin/).

Ce que vous verrez “avant” et “après”

Avant (site bloqué) :

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

Après (site débloqué) : votre thème se charge normalement, l’admin redevient accessible.

Pourquoi ça corrige le problème

WordPress bascule en maintenance tant que .maintenance existe. Le supprimer retire le verrou. Si la mise à jour s’était terminée mais que la suppression a échoué (permissions, timeout), vous revenez à un état normal.

Si le fichier revient immédiatement

Si vous supprimez .maintenance et qu’il revient, c’est presque toujours qu’une mise à jour se relance (auto-update) et re-bloque. Passez directement à la Solution 2 : il faut traiter la cause de l’échec (timeout, mémoire, disque, permissions, conflit).

Solution 2 : une mise à jour bloquée (plugins/thèmes/core) — relancer proprement

Quand la maintenance revient, le problème n’est plus “le fichier” : c’est la mise à jour qui n’arrive pas à se terminer. Le but est de remettre WordPress dans un état cohérent, puis de relancer l’update proprement.

Étape A — vérifiez si un plugin/thème est incomplet

Après une mise à jour interrompue, WordPress peut laisser un dossier en état partiel (fichiers manquants). Résultat fréquent : erreur 500 après suppression de .maintenance.

Activez le debug temporairement (dans wp-config.php, juste avant “That’s all, stop editing!”). Sauvegardez avant de modifier.

AVANT (cassé) : vous n’avez pas de logs exploitables.

APRÈS (corrigé pour diagnostiquer) :

<?php
// wp-config.php — activez temporairement le debug pour trouver la cause réelle
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
// Évitez d'afficher les erreurs aux visiteurs en production
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Ensuite, rechargez le site, puis ouvrez le fichier wp-content/debug.log. Vous cherchez des erreurs du type :

Fatal error: Uncaught Error: Failed opening required ...
Class "..." not found
Parse error: syntax error, unexpected ...

Étape B — désactivez le plugin fautif (sans accès admin)

Si l’admin est inaccessible, la méthode la plus fiable est de renommer le dossier du plugin.

Allez dans wp-content/plugins/.
Renommez le dossier du plugin suspect, par exemple : mon-plugin → mon-plugin.OFF.
Rechargez /wp-admin/.

Dans mon expérience, les plugins de cache, sécurité, sauvegarde, et optimisation (minification) sont ceux qui provoquent le plus souvent des blocages pendant les updates.

Étape C — réinstallez proprement le plugin/thème (si incomplet)

Si un plugin a été mis à jour partiellement, le plus rapide est de le réinstaller depuis une source sûre.

Si c’est un plugin du répertoire officiel : téléchargez-le depuis wordpress.org/plugins et remplacez le dossier.
Si c’est un plugin premium (Divi, Avada, etc.) : récupérez l’archive depuis votre compte éditeur et remplacez le dossier.

Vous pouvez aussi supprimer le dossier du plugin (si vous êtes sûr de pouvoir le réinstaller) puis le réinstaller. Attention : la suppression peut effacer des fichiers internes mais pas forcément les données en base (ça dépend du plugin).

Étape D — relancez les mises à jour depuis l’admin (quand c’est stable)

Une fois le site accessible :

Allez dans Tableau de bord → Mises à jour.
Mettez à jour en petites séries (2–5 plugins à la fois), pas 30 d’un coup.
Commencez par WordPress (core), puis plugins, puis thèmes.

Cas fréquent : cache qui sert encore la maintenance

Vous avez supprimé .maintenance, mais vous voyez encore la page “Briefly unavailable…” uniquement sur le front. Très souvent, c’est un cache.

Videz le cache du plugin (si accessible) et le cache serveur (LiteSpeed, Varnish, Nginx FastCGI cache selon hébergeur).
Si vous avez un CDN (Cloudflare, etc.), purgez le cache et testez en navigation privée.
Testez aussi avec ?nocache=1 à la fin de l’URL (ça ne marche pas partout, mais ça aide à comparer).

Exemple de “code AVANT” qui aggrave la situation (snippet mal placé)

J’ai déjà vu des utilisateurs coller un snippet de maintenance dans le mauvais fichier (ou un plugin de snippets) et confondre avec la maintenance WordPress. Exemple typique : un code qui force une redirection “maintenance” pour les visiteurs… et qui s’applique aussi à l’admin.

AVANT (cassé) : dans functions.php du thème (souvent le thème parent, ce qu’il ne faut pas faire) :

<?php
// Mauvaise idée : bloque aussi wp-admin et l'API REST selon le contexte
add_action( 'init', function () {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_die( 'Maintenance en cours.' );
    }
} );

APRÈS (corrigé) : si vous devez vraiment afficher une maintenance personnalisée, faites-le proprement, en excluant admin, login, REST et AJAX. Placez ce code dans un plugin custom (recommandé) ou dans le functions.php du thème enfant.

<?php
/**
 * Plugin Name: Maintenance contrôlée (exemple)
 * Description: Exemple pédagogique : n'activez pas ça en production sans raison.
 */

// Action = un "hook" qui exécute du code à un moment précis du chargement.
add_action( 'template_redirect', function () {
    // Ne jamais bloquer l'admin, la page de login, l'AJAX ou la REST API
    if ( is_admin() ) {
        return;
    }

    if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
        return;
    }

    if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
        return;
    }

    if ( strpos( $_SERVER['REQUEST_URI'] ?? '', 'wp-login.php' ) !== false ) {
        return;
    }

    // Exemple : activer/désactiver via une constante
    if ( defined( 'BPCAB_MAINTENANCE' ) && BPCAB_MAINTENANCE === true ) {
        if ( ! is_user_logged_in() ) {
            wp_die(
                'Maintenance en cours. Revenez dans quelques minutes.',
                'Maintenance',
                array( 'response' => 503 )
            );
        }
    }
}, 1 );

Pourquoi c’est mieux : vous évitez de casser Elementor/Divi/Avada (qui dépendent de REST/AJAX), et vous ne vous enfermez pas hors de l’admin.

Solution 3 : débloquer via WP-CLI et vérifier l’état des mises à jour (cas avancé)

Si vous avez un accès SSH, WP-CLI est souvent la méthode la plus propre. Sur des sites un peu gros, ça évite les timeouts du navigateur.

Prérequis : WP-CLI installé côté serveur. Référence officielle : wp-cli.org.

1) Supprimer .maintenance en ligne de commande

Placez-vous dans la racine WordPress (là où se trouve wp-config.php) :

cd /chemin/vers/votre/site
ls -la | grep maintenance
rm -f .maintenance

2) Vérifier l’intégrité du core WordPress

Si une mise à jour du core a été interrompue, vérifiez les checksums (très utile) :

wp core verify-checksums

Si WP-CLI remonte des fichiers modifiés/manquants, vous pouvez réinstaller les fichiers du core sans toucher au contenu :

wp core download --force

3) Mettre à jour plugins/thèmes proprement

Pour finir une série d’updates (en évitant le navigateur) :

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

Si un plugin échoue, mettez à jour un par un pour identifier le coupable :

wp plugin list
wp plugin update nom-du-plugin

4) Désactiver un plugin qui casse tout

wp plugin deactivate nom-du-plugin

Pourquoi WP-CLI aide vraiment

Moins de risques de timeout HTTP côté navigateur.
Sortie d’erreur plus explicite.
Commandes reproductibles (pratique sur staging puis prod).

Si vous gérez un site avec Divi 5, Elementor ou Avada : WP-CLI est aussi un bon moyen de mettre à jour sans charger l’admin (qui peut être lourd).

Vérifications après correction

Une fois le site débloqué, ne vous contentez pas de “ça s’affiche”. Testez ce qui casse souvent après un update interrompu.

Front-end : ouvrez 2–3 pages, dont une page construite avec votre builder (Elementor/Divi/Avada).
Admin : allez dans “Extensions” et “Apparence → Thèmes”. Vérifiez qu’il n’y a pas d’erreurs visibles.
REST API : ouvrez https://votre-site.tld/wp-json/. Vous devez obtenir du JSON, pas une page HTML de maintenance.
Mises à jour : retournez dans “Tableau de bord → Mises à jour” et vérifiez qu’il ne reste pas une update bloquée.
Cache : purgez tous les caches, puis testez en navigation privée.
Logs : si vous avez activé WP_DEBUG_LOG, vérifiez wp-content/debug.log, puis désactivez WP_DEBUG une fois fini.

Si ça ne marche toujours pas

Quand la suppression de .maintenance ne suffit pas, il faut une approche “par couches”. Voici l’ordre qui donne les meilleurs résultats sur le terrain.

1) Vérifiez les permissions fichiers (cause fréquente et silencieuse)

Si WordPress ne peut pas écrire/supprimer, il peut laisser des fichiers temporaires et re-bloquer.

Dossiers : souvent 755
Fichiers : souvent 644

Les valeurs exactes dépendent de l’hébergement. Si vous ne savez pas, demandez au support hébergeur. Évitez 777 (risque de sécurité).

2) Vérifiez l’espace disque

Une mise à jour télécharge une archive, l’extrait, copie des fichiers. Si le disque est plein, le processus s’arrête au milieu.

Vérifiez l’espace dans le panel hébergeur.
Nettoyez des sauvegardes anciennes, caches, fichiers de logs énormes.

3) Isolez un conflit plugin/thème sans casser le site (Health Check)

Installez et activez Health Check & Troubleshooting. Son “mode dépannage” désactive les plugins uniquement pour vous, pas pour les visiteurs.

Activez le mode dépannage.
Réactivez les plugins un par un jusqu’à reproduire le blocage.
Identifiez le plugin qui déclenche l’update bloquée ou la maintenance persistante.

4) Regardez la console navigateur (builder cassé)

Si Elementor/Divi/Avada affiche un chargement infini :

Ouvrez les DevTools du navigateur (F12) → onglet Console/Network.
Si vous voyez du HTML renvoyé à la place de JSON, c’est souvent la maintenance ou une erreur PHP.

5) Vérifiez les erreurs PHP et la mémoire

Une limite mémoire trop basse peut interrompre l’extraction/copie.

Vérifiez les logs PHP côté hébergeur.
Augmentez la mémoire WordPress si nécessaire (selon hébergement).

Exemple (à placer dans wp-config.php) :

<?php
// Augmente la mémoire disponible pour WordPress (si l'hébergeur l'autorise)
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si l’hébergeur impose une limite plus basse, ces constantes ne suffiront pas. Dans ce cas, c’est un réglage PHP côté serveur.

6) Forcer la régénération des permaliens (rare ici, mais utile après gros update)

Ce n’est pas la cause de la maintenance, mais après une réparation, certains sites ont des 404.

Réglages → Permaliens
Enregistrez sans rien changer

7) Si vous suspectez un problème réseau vers WordPress.org

Sur certains hébergements, les requêtes sortantes sont filtrées. Les mises à jour téléchargent des paquets depuis wordpress.org.

Testez la page “Santé du site” (Outils → Santé du site).
Un plugin comme Query Monitor peut montrer des erreurs HTTP sur les téléchargements.

Références :

wp_remote_get() (HTTP API)
Automatic updates

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 les fichiers cachés” dans le gestionnaire
Vous supprimez .maintenance mais ça revient	Auto-update relancée et re-bloquée (timeout, permissions, disque plein)	Corriger la cause + relancer update proprement (Solution 2/3)
Après suppression, erreur 500	Plugin/thème incomplet	Renommer le plugin, réinstaller proprement, vérifier debug.log
Vous avez modifié le mauvais fichier	Code collé dans le thème parent ou mauvais emplacement	Utiliser thème enfant ou plugin custom; ne jamais modifier le core
Erreur “Parse error” dans debug.log	Point-virgule manquant, parenthèse oubliée	Annuler le dernier snippet; valider le fichier PHP
Elementor/Divi/Avada ne charge pas, admin OK	Cache/CDN sert encore la maintenance ou REST API renvoie HTML	Purger caches + tester /wp-json/
La mise à jour boucle à l’infini	Permissions d’écriture ou blocage sécurité	Vérifier droits, désactiver temporairement plugin de sécurité, WP-CLI
Vous testez en production sans sauvegarde	Habitude “je tente”	Snapshot/staging avant toute update majeure

Variante / alternative

Méthode sans code : réparer via l’hébergeur (staging + restauration)

Si vous avez un hébergement géré (ou un bon panel) :

Créez un staging (copie de test) et rejouez la mise à jour dessus.
Si le staging est OK, appliquez en production.
Sinon, restaurez un snapshot juste avant l’update, puis mettez à jour plus progressivement.

Méthode développeur : mu-plugin “filet de sécurité” (à utiliser avec prudence)

Sur des sites où je dois éviter de rester bloqué dehors, j’ai parfois ajouté un mu-plugin (plugin “must-use”) qui supprime automatiquement .maintenance s’il est trop ancien. C’est utile sur des environnements où des auto-updates échouent la nuit et bloquent le site jusqu’au matin.

Risque : si vous supprimez trop tôt, vous pourriez exposer un site pendant une mise à jour réellement en cours. Faites un seuil large (ex : 15–30 minutes) et testez d’abord sur staging.

Où placer le code : créez un fichier wp-content/mu-plugins/bpcab-maintenance-guard.php. Si le dossier mu-plugins n’existe pas, créez-le.

<?php
/**
 * Plugin Name: BPCAB Maintenance Guard
 * Description: Supprime .maintenance s'il est trop ancien (filet de sécurité).
 * Author: Votre nom
 */

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

add_action( 'init', function () {
    // Chemin vers le fichier .maintenance à la racine WordPress
    $maintenance_file = ABSPATH . '.maintenance';

    if ( ! file_exists( $maintenance_file ) ) {
        return;
    }

    // Seuil : 30 minutes. Ajustez selon votre contexte.
    $max_age = 30 * MINUTE_IN_SECONDS;

    $mtime = @filemtime( $maintenance_file );
    if ( ! $mtime ) {
        return;
    }

    // Si le fichier est plus vieux que le seuil, on le supprime
    if ( ( time() - $mtime ) > $max_age ) {
        // Tentative de suppression silencieuse
        @unlink( $maintenance_file );
    }
}, 0 );

Pourquoi ça marche : vous évitez un blocage “infini” lié à un update interrompu. Pourquoi c’est risqué : si votre serveur est très lent et qu’un upgrade légitime dépasse 30 minutes, vous cassez la protection. Sur la plupart des blogs, 30 minutes est déjà très large.

Éviter ce problème à l’avenir

Le mode maintenance coincé est rarement “un bug WordPress” pur. C’est presque toujours un environnement qui interrompt les opérations d’écriture.

Faites les mises à jour par lots (quelques plugins à la fois). C’est bête, mais c’est la différence entre “ça passe” et “timeout”.
Évitez les mises à jour en heure de pointe si votre hébergement est limité.
Gardez PHP à jour (8.1+ minimum recommandé) et surveillez la mémoire. Référence PHP : PHP supported versions.
Surveillez l’espace disque, surtout si vous générez des backups sur le même serveur.
Staging : testez les mises à jour de Divi 5 / Elementor / Avada et des plugins majeurs sur une copie avant la prod.
Évitez les “snippets” douteux trouvés sur d’anciens tutoriels : beaucoup sont incompatibles avec les pratiques actuelles ou cassent REST/AJAX.

Bon réflexe : vérifier la Santé du site

Outils → Santé du site donne souvent des indices (boucles, requêtes sortantes, version PHP, etc.). Documentation : Site Health Screen.

Ressources

Questions fréquentes

Est-ce que je peux simplement attendre ?

Si la mise à jour est réellement en cours, oui, quelques minutes suffisent. Si le message est toujours là après 5–10 minutes, c’est très souvent un .maintenance coincé ou une mise à jour interrompue. Dans ce cas, attendre ne change rien.

Supprimer .maintenance est-il dangereux ?

En général non, si la mise à jour est déjà interrompue. Le risque existe si une mise à jour est réellement en train de copier des fichiers au même moment. Si vous êtes en doute, attendez 2–3 minutes, puis supprimez.

Je ne vois pas .maintenance, pourtant j’ai le message

Deux cas classiques : (1) votre outil n’affiche pas les fichiers cachés, (2) un cache/CDN sert une ancienne page de maintenance. Activez l’affichage des dotfiles, puis purgez les caches.

Pourquoi Elementor/Divi/Avada ne charge plus quand le site est en maintenance ?

Ces builders utilisent des appels AJAX et la REST API. Si WordPress renvoie une page HTML de maintenance au lieu de JSON, l’éditeur ne peut plus interpréter la réponse et se bloque.

Après suppression de .maintenance, j’ai une erreur 500

Ça indique souvent un plugin ou un thème partiellement mis à jour. Activez WP_DEBUG_LOG, regardez wp-content/debug.log, puis renommez le dossier du plugin suspect dans wp-content/plugins/.

Est-ce lié à WP-Cron ?

Indirectement. WP-Cron peut déclencher des auto-updates. Si l’auto-update se lance et échoue (timeout, permissions), il peut laisser .maintenance en place.

Dois-je désactiver les mises à jour automatiques ?

Pas forcément. Sur un blog standard, les auto-updates de sécurité sont plutôt une bonne chose. Si vous constatez des blocages répétés, corrigez d’abord la cause (permissions, ressources, disque, conflit). En environnement pro, privilégiez un process staging + déploiement.

J’utilise un plugin de cache, est-ce la cause ?

Le cache n’est pas la cause du fichier .maintenance, mais il peut masquer la correction en continuant à servir une page en cache. Purgez le cache plugin, le cache serveur, et le CDN.

Quelle est la meilleure méthode “propre” pour mettre à jour sans risque ?

Staging, sauvegarde, mises à jour par lots, puis vérifications (front, admin, REST API). Si possible, utilisez WP-CLI pour éviter les timeouts du navigateur.

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

Non, le déclencheur principal est un fichier (.maintenance). La base de données peut être impliquée si un plugin a laissé des options incohérentes, mais ce n’est pas la première piste pour ce message précis.