Mis à jour le 12 octobre 2026
Une mise à jour WordPress bloquée vient presque toujours d’une des cinq causes suivantes : un fichier .maintenance resté dans le dossier racine, un conflit de plugin ou de thème, un manque de mémoire PHP, des permissions de fichiers incorrectes ou un verrou de mise à jour encore actif. Je commence toujours par sauvegarder, puis je teste ces pistes dans cet ordre.
Comment reconnaître une mise à jour WordPress bloquée ?
Une mise à jour est bloquée quand elle ne se termine pas et que le site ne revient pas à la normale : message de maintenance qui ne disparaît pas, écran blanc, tableau de bord inaccessible ou erreur « Échec de la mise à jour ». Le symptôme oriente le diagnostic, donc je note ce que je vois avant de toucher à quoi que ce soit.
- Le message « Briefly unavailable for scheduled maintenance. Check back in a minute » reste affiché : c’est le cas le plus fréquent, traité plus bas.
- Le bouton de mise à jour tourne sans fin : souvent un délai dépassé côté serveur ou un plugin en conflit.
- Une page blanche ou une erreur critique apparaît après la mise à jour : le problème vient en général d’un plugin ou du thème, pas du cœur.
- WordPress affiche « Une autre mise à jour est en cours » : un verrou de mise à jour est resté actif.
Que faire avant de toucher à quoi que ce soit ?
Avant toute manipulation, je sauvegarde les fichiers et la base de données, puis je vérifie que la sauvegarde est exploitable. La documentation officielle de WordPress insiste sur ce point : sauvegarde de la base et des fichiers, vérification, désactivation des plugins avant une mise à jour manuelle.
Si le site est inaccessible, la sauvegarde se fait en FTP/SFTP pour les fichiers et via phpMyAdmin ou le panneau de l’hébergeur pour la base. J’ai détaillé la méthode dans mon guide sur la sauvegarde manuelle de WordPress.
Comment sortir du mode maintenance bloqué ?
Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine du site et le supprime à la fin. Si la mise à jour s’interrompt, le fichier reste et le site affiche la page de maintenance. La solution est de le supprimer à la main, comme le décrit le guide de Jetpack sur ce message.
- Connectez-vous en FTP/SFTP (ou au gestionnaire de fichiers de l’hébergeur).
- Affichez les fichiers cachés : le nom commence par un point, donc il n’apparaît pas par défaut.
- Dans le dossier racine (celui qui contient
wp-config.php), supprimez.maintenance. - Rechargez le site, puis relancez la mise à jour interrompue.
Une fois le site revenu, je vérifie dans Tableau de bord, puis Mises à jour, que le cœur, les plugins et les thèmes sont bien dans la version attendue. Une mise à jour coupée en plein milieu peut laisser un plugin à moitié remplacé.
Comment lever un verrou de mise à jour du cœur ?
Quand WordPress annonce qu’une autre mise à jour est en cours alors que rien ne tourne, un verrou est resté en base de données. Avec WP-CLI, la documentation de la commande wp core update indique de supprimer l’option core_updater.lock, mais seulement après avoir vérifié qu’aucune autre mise à jour ne tourne.
wp option delete core_updater.lock
wp core updateJe n’utilise cette commande qu’après avoir attendu quelques minutes et contrôlé qu’aucun autre administrateur ni aucune tâche automatique ne lance une mise à jour.
Comment isoler un plugin ou un thème fautif ?
Si l’écran se fige ou si une erreur apparaît, je désactive les plugins puis je bascule sur un thème par défaut pour isoler le conflit. La documentation officielle conseille d’ailleurs, quand le site est brouillé après une mise à jour, de désactiver les plugins non essentiels et de les réactiver un par un.
- Plugins : Extensions, Extensions installées, tout cocher, « Désactiver ». Si l’admin est inaccessible, je renomme le dossier
wp-content/pluginsen FTP. - Thème : j’active un thème par défaut de WordPress (Twenty Twenty-Five, par exemple) pour exclure le thème actif.
- Réactivation : un plugin à la fois, en rechargeant une page du site entre chaque, jusqu’à retrouver le coupable.
Sur un site client, je fais ce test sur une copie de staging quand c’est possible. Mon article sur le diagnostic d’une erreur WordPress détaille la démarche.
Quelles vérifications serveur et wp-config.php faire ?
Si les plugins ne sont pas en cause, je regarde la mémoire PHP, les permissions et wp-config.php. Deux constantes bloquent ou limitent les mises à jour automatiques : AUTOMATIC_UPDATER_DISABLED et WP_AUTO_UPDATE_CORE. Leurs rôles sont décrits dans la documentation de wp-config.php.
define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );La première désactive les mises à jour automatiques. La seconde, avec false, coupe celles du cœur ; true autorise toutes les versions et 'minor', la valeur par défaut, ne laisse passer que les mises à jour mineures. Ces lignes ne sont pas une erreur en soi : un hébergeur ou un développeur peut les avoir posées volontairement. Je les retire seulement si je sais pourquoi elles sont là.
| Point à vérifier | Symptôme typique | Action |
|---|---|---|
| Mémoire PHP | Écran blanc ou arrêt en cours de mise à jour | Augmenter WP_MEMORY_LIMIT (40 Mo par défaut en site simple, 64 Mo en multisite selon la doc) |
| Permissions de fichiers | WordPress demande des identifiants FTP | Corriger le propriétaire et les droits ; FS_METHOD en dernier recours |
| Verrou de mise à jour | « Une autre mise à jour est en cours » | Supprimer core_updater.lock après contrôle |
| Constantes de mise à jour | Aucune mise à jour automatique | Vérifier AUTOMATIC_UPDATER_DISABLED et WP_AUTO_UPDATE_CORE |
La même documentation précise que FS_METHOD ne se change qu’en cas de problème de mise à jour, et que la valeur direct peut créer des risques de sécurité sur un hébergement mal configuré. Les échecs de mise à jour en un clic sont d’ailleurs, d’après la page officielle sur la mise à jour, probablement liés à des problèmes de permissions sur le système de fichiers.
Comment forcer la mise à jour du cœur manuellement ?
Quand rien d’autre ne marche, je remplace les fichiers du cœur à la main ou avec WP-CLI. Attention : remplacer uniquement wp-admin et wp-includes ne suffit pas, car les fichiers de la racine (comme wp-load.php) changent aussi d’une version à l’autre.
Avec WP-CLI, la commande suivante télécharge et installe la version demandée :
wp core update
wp core update --version=X.Y.Z --forceL’option --force sert à réinstaller même si la version installée est identique ou supérieure. Le détail des options (--minor, --version, --force) figure dans la documentation WP-CLI.
Sans WP-CLI, je suis la procédure officielle : sauvegardes, désactivation des plugins, téléchargement du paquet, suppression des anciens fichiers en gardant wp-config.php, wp-content et les règles personnalisées de .htaccess, envoi des nouveaux fichiers, puis passage par l’écran de mise à niveau de la base. Les étapes complètes sont dans la page officielle de mise à jour manuelle.
Quelles erreurs éviter pour que la mise à jour ne se bloque plus ?
Les blocages que je rencontre viennent surtout de quatre habitudes : pas de sauvegarde, mise à jour en masse, fermeture de l’onglet en cours de route et test directement en production. Éviter ces quatre points règle la plupart des cas.
- Ne pas sauvegarder le site avant de mettre à jour : sans sauvegarde, un échec peut devenir une restauration impossible.
- Tout mettre à jour d’un coup : si ça casse, impossible de savoir quel plugin est responsable. Je mets à jour un élément à la fois sur les sites sensibles.
- Fermer l’onglet ou quitter la page pendant la mise à jour : c’est une cause classique de fichier
.maintenanceorphelin. - Laisser en place des plugins abandonnés : ils cassent tôt ou tard à la mise à jour du cœur ou de PHP.
- Ignorer les journaux : le journal d’erreurs WordPress et celui du serveur disent souvent précisément ce qui a échoué.
Comment limiter les risques à chaque mise à jour ?
Je fixe une routine : sauvegarde automatique avant intervention, test sur staging pour les sites importants, mise à jour par lots courts, puis contrôle visuel des pages clés. Sur un parc de plus de 50 sites WordPress, cette discipline évite l’essentiel des interventions d’urgence. Pour le cœur, mon guide pour mettre à jour WordPress core donne la marche à suivre.
Si le site reste inaccessible malgré ces étapes, ne multipliez pas les essais : chaque manipulation sans sauvegarde augmente le risque. À ce stade, une restauration de la sauvegarde ou une intervention technique est plus sûre.
Questions fréquentes
Comment reconnaître une mise à jour WordPress bloquée ?
Le site reste en mode maintenance, la mise à jour ne se termine jamais, une page blanche apparaît ou le tableau de bord devient inaccessible. Ces symptômes indiquent une mise à jour interrompue en cours de route, souvent avec un fichier .maintenance resté à la racine.
Comment débloquer une mise à jour figée ?
Je sauvegarde d’abord, puis je supprime le fichier .maintenance en FTP si le site affiche la page de maintenance. Ensuite je désactive les plugins et je teste avec un thème par défaut pour isoler un conflit, puis je relance la mise à jour.
Pourquoi une mise à jour reste-t-elle bloquée ?
Les causes courantes sont une interruption pendant le téléchargement, un conflit de plugin ou de thème, un manque de mémoire PHP, des permissions de fichiers incorrectes ou un verrou de mise à jour resté actif. Identifier la cause oriente la bonne solution.
Peut-on supprimer le fichier .maintenance sans risque ?
Oui, si aucune mise à jour n’est réellement en cours. WordPress le crée au début d’une mise à jour et le retire à la fin ; un fichier resté après un échec peut être supprimé. Je contrôle ensuite les versions installées pour détecter un plugin à moitié mis à jour.
Comment éviter qu’une mise à jour se bloque ?
Sauvegarde avant chaque mise à jour, connexion stable, ressources serveur suffisantes, mise à jour élément par élément et test sur staging pour les sites importants. Ne fermez pas la page tant que la mise à jour n’est pas terminée.