Mise à jour WordPress échouée : comment la résoudre

Mise à jour WordPress échouée : un message trompeur

WordPress affiche « La mise à jour a échoué. Vous êtes probablement hors ligne. » dès qu’il ne parvient pas à valider une étape technique précise de sa procédure — la formulation suggère une coupure réseau côté visiteur, ce qui n’est presque jamais la cause réelle. Le noyau, un plugin ou un thème restent alors bloqués sur l’ancienne version, avec un paquet de mise à jour partiellement téléchargé ou extrait. Une variante du même blocage se manifeste par une erreur JSON illisible plutôt que par ce message précis, sans changer le diagnostic à mener.

Avant d’apparaître, avant même le téléchargement du paquet, WordPress s’envoie à lui-même une requête HTTP interne — un « loopback » — pour vérifier que le site répond correctement une fois la procédure lancée. Si cette requête échoue (délai dépassé, réponse HTTP différente de 200, blocage réseau), WordPress interrompt la mise à jour et affiche ce message par défaut, quel que soit le mécanisme réellement en cause côté serveur. Ce test loopback est la source la plus fréquente de l’échec : le problème ne vient presque jamais de la connexion de la personne qui déclenche la mise à jour, mais de la capacité du serveur à se joindre lui-même.

Avant toute manipulation, une sauvegarde complète (fichiers et base de données) reste la précaution de base — le guide de sauvegarde et restauration en 5 étapes couvre la marche à suivre si aucun plan n’est déjà en place, la mise à jour manuelle décrite plus bas en dépendant directement en cas d’erreur de manipulation.

Diagnostiquer un échec de requête loopback

Trois origines reviennent régulièrement pour un loopback qui échoue :

Un pare-feu applicatif ou un plugin de sécurité (Wordfence, iThemes Security, un WAF côté hébergeur) qui bloque les requêtes internes émises depuis le serveur vers son propre nom de domaine — vérifier les journaux du plugin de sécurité juste avant l’échec de la mise à jour est le point de départ le plus rapide.
Une règle .htaccess ou une configuration DNS locale qui empêche le serveur de résoudre son propre domaine vers lui-même — un ajout récent dans .htaccess (protection par mot de passe, restriction d’IP) coïncidant avec l’apparition du problème est un signal fort.
Un certificat SSL invalide côté serveur au moment de la requête interne (renouvellement en cours, certificat expiré) — WordPress refuse la connexion loopback si la validation SSL échoue, même si le site reste accessible normalement dans un navigateur.

Un plugin comme Health Check & Troubleshooting (WordPress.org) expose un test loopback dédié dans son onglet Info, avec le code HTTP exact retourné — plus précis qu’une déduction a posteriori.

Vérifier la connexion sortante vers l’API WordPress.org

Le téléchargement du paquet de mise à jour dépend d’une requête sortante du serveur vers api.wordpress.org (ou downloads.wordpress.org pour le fichier lui-même). Un hébergement mutualisé avec un pare-feu sortant restrictif, ou un DNS local mal configuré, peut bloquer cette requête sans qu’aucun message ne le précise clairement dans wp-admin.

Un test direct en ligne de commande, si un accès SSH est disponible, confirme rapidement l’origine :

curl -I https://api.wordpress.org/core/version-check/1.7/

Un code différent de 200, un délai dépassé ou une erreur de certificat à cette étape pointe vers une restriction réseau côté hébergeur plutôt que vers WordPress lui-même — un point à signaler au support technique de l’hébergeur avec ce résultat en main plutôt qu’une simple description du symptôme observé dans wp-admin.

Sans accès SSH, l’onglet « Informations sur le site » de l’outil Health Check & Troubleshooting propose le même test sous forme de rapport lisible, avec le code de réponse exact renvoyé par chaque requête sortante testée. C’est l’option la plus rapide sur un hébergement mutualisé où l’accès en ligne de commande n’est pas proposé par défaut.

Permissions de fichiers et espace disque insuffisant

WordPress télécharge le paquet de mise à jour dans wp-content/upgrade, l’extrait, puis remplace les fichiers du cœur ou de l’extension concernée. Chacune de ces étapes échoue silencieusement — ou avec un message générique — si :

wp-content et wp-content/upgrade ne sont pas inscriptibles par le compte utilisateur exécutant PHP (droits 755/644 habituels, propriétaire cohérent avec le compte d’hébergement) ;
l’espace disque alloué par l’offre d’hébergement est saturé — le paquet compressé et sa version extraite occupent temporairement le double de la taille finale ;
un quota d’inodes (nombre de fichiers, pas seulement de taille) est atteint sur un mutualisé, un cas plus difficile à repérer qu’un simple manque d’espace en Go.

Un espace disque ou des ressources régulièrement sous tension pendant les mises à jour est aussi le symptôme qui rapproche cette panne de l’erreur 508 Resource Limit Is Reached — un signal que l’offre d’hébergement actuelle est sous-dimensionnée pour le site, pas seulement pour cet incident ponctuel.

Un fichier .maintenance résiduel qui bloque toute nouvelle tentative

Chaque mise à jour crée un fichier .maintenance à la racine du site le temps de l’opération, puis le supprime automatiquement une fois terminée. Si la première tentative s’est interrompue brutalement (coupure réseau, dépassement de temps d’exécution PHP), ce fichier peut rester en place et bloquer toute nouvelle tentative avec un message de maintenance affiché à la place du site — un mécanisme détaillé dans l’article sur le site WordPress bloqué en maintenance.

Avant de relancer la mise à jour, vérifier par FTP/SFTP la présence d’un fichier .maintenance à la racine et le supprimer s’il date de plus de quelques minutes évite de répéter le même échec en boucle.

Mémoire PHP insuffisante pendant l’extraction du paquet

L’extraction et l’application d’un paquet de mise à jour, en particulier pour le cœur de WordPress ou un thème volumineux, consomment davantage de mémoire PHP que l’affichage normal du site. Une limite memory_limit déjà proche du seuil pour un usage courant peut suffire pour un affichage classique du site, mais s’avérer insuffisante lors de cette opération ponctuelle plus lourde.

Le fichier journal PHP (error_log, accessible via l’hébergeur ou un plugin comme Query Monitor) confirme ce cas précis avec un message explicite (« Allowed memory size exhausted »). La correction rejoint celle détaillée pour l’erreur 500 WordPress : augmenter memory_limit dans le fichier de configuration racine de WordPress ou dans php.ini selon ce que permet l’offre d’hébergement, ou changer d’offre si la limite est fixée par l’hébergeur lui-même.

Forcer une mise à jour manuelle quand l’échec se répète

Quand aucune des causes ci-dessus ne se confirme, ou en attendant leur correction définitive, une mise à jour manuelle par FTP/SFTP contourne le mécanisme automatique qui échoue :

Télécharger la dernière version du cœur, du thème ou du plugin concerné directement depuis WordPress.org.
Désactiver temporairement les plugins de cache et de sécurité, qui interfèrent parfois avec le remplacement de fichiers en cours.
Remplacer les fichiers via un client FTP/SFTP en conservant wp-content (thèmes, extensions, médias) intact pour une mise à jour du cœur.
Vérifier l’absence d’un fichier .maintenance résiduel après l’opération, puis réactiver les plugins désactivés un par un.

Cette méthode reste un contournement ponctuel — elle ne corrige pas la cause du blocage automatique (loopback, permissions, mémoire), qui reviendra à la mise à jour suivante si elle n’est pas traitée à la racine.

Choisir un hébergement qui absorbe les mises à jour sans réglage

Un hébergement WordPress dimensionné pour ce type d’opération (mémoire PHP suffisante par défaut, quota d’inodes confortable, pare-feu sortant qui n’entrave pas les requêtes loopback et l’accès à l’API WordPress.org) évite une bonne partie des causes détaillées ici avant même qu’elles ne se manifestent. Le comparatif des meilleurs hébergeurs WordPress détaille les critères techniques à vérifier sur ce point précis avant de choisir ou changer d’offre.