Mise à jour WordPress bloquée : comment forcer la version 7.1.4 quand elle n’apparaît pas

Vous avez lu partout qu’il fallait passer en WordPress 7.1.2 de toute urgence. Vous ouvrez votre tableau de bord, et… rien. Pas de bandeau, pas de bouton, parfois même plus de menu Mises à jour. Pendant ce temps, la faille corrigée par cette version (la CVE-2026-87902, une inclusion de fichier exploitable sans être connecté) est déjà activement exploitée : Patchstack a relevé les premières tentatives le jour même de la sortie, le 22 septembre, puis dès le 23 des attaques qui déposent des fichiers PHP sur les serveurs vulnérables. Depuis, WordPress a publié la 7.1.3 le 6 octobre, puis la 7.1.4 le 28 octobre 2026 : c’est elle qu’il faut viser aujourd’hui, elle contient ce correctif.

Bonne nouvelle : dans l’immense majorité des cas, la mise à jour n’est pas « bloquée », elle est cachée ou désactivée par un réglage précis. Je vous montre comment trouver lequel, puis comment forcer l’installation, du bouton le plus simple jusqu’à la ligne de commande.

Avant de toucher à quoi que ce soit : vérifiez votre version

Premier réflexe, regardez le numéro installé, en bas à droite de chaque page d’administration. La mise à jour s’est peut-être faite toute seule pendant la nuit, ce qui expliquerait l’absence de bouton. Et 7.1.2 n’est pas la seule version sûre : le même correctif existe pour chaque branche jusqu’à la 4.7. Un site en 7.0.6, 6.9.9 ou 6.8.10 est protégé contre cette faille. Pour avoir aussi les correctifs d’octobre, visez la 7.0.8, la 6.9.11 ou la 6.8.12 sur ces branches.

Et avant toute manipulation décrite plus bas, faites une sauvegarde complète de votre site, fichiers et base de données. Une mise à jour du cœur qui plante à mi-chemin, ça arrive.

Mise à jour WordPress bloquée : les 5 causes courantes

1. WordPress n’a pas encore vérifié

C’est de loin la cause la plus fréquente. WordPress ne vérifie pas l’existence d’une nouvelle version à chaque chargement de page : il programme cette vérification deux fois par jour et garde la réponse en cache dans un transient (une donnée temporaire stockée en base) nommé update_core. Tant que ce cache n’a pas expiré, votre tableau de bord vous montre la situation d’il y a quelques heures, avant la sortie de la dernière version.

Même symptôme si votre serveur n’arrive pas à joindre api.wordpress.org (pare-feu sortant, souci DNS ou certificat) : la vérification échoue en silence et l’écran ne bouge plus.

2. La constante DISALLOW_FILE_MODS

Si le menu Mises à jour a carrément disparu, c’est presque toujours elle. Déclarée à true dans wp-config.php, DISALLOW_FILE_MODS interdit à WordPress de modifier ses propres fichiers. Conséquence : plus d’installation de plugins ni de thèmes, plus de mise à jour depuis l’admin, et plus aucune mise à jour automatique, correctifs de sécurité compris.

3. WP_AUTO_UPDATE_CORE ou AUTOMATIC_UPDATER_DISABLED

Cas différent : la mise à jour apparaît bien dans l’admin, mais elle ne s’est jamais installée toute seule. Par défaut, WordPress applique les versions mineures de sécurité en arrière-plan. Deux constantes cassent ce mécanisme : WP_AUTO_UPDATE_CORE réglée sur false (plus aucune mise à jour automatique du cœur) et AUTOMATIC_UPDATER_DISABLED réglée sur true (plus aucune mise à jour automatique du tout). Un plugin de gestion des mises à jour peut faire pareil. J’ai détaillé les réglages possibles dans mon article sur les mises à jour automatiques de WordPress, des plugins et du thème.

Deux autres blocages plus discrets : un dossier .git ou .svn à la racine (WordPress considère alors que le site est versionné et s’abstient), et des droits de fichiers qui l’empêchent d’écrire. Dans ce dernier cas, il se contente de vous envoyer un e-mail. Et si vous lancez la mise à jour à la main, WordPress vous présente à la place un formulaire « Informations de connexion » qui réclame vos identifiants FTP.

4. L’hébergeur gère les mises à jour à votre place

Certains hébergements infogérés prennent la main sur le cœur : ils masquent les notifications et déploient les versions eux-mêmes, parfois avec quelques heures de décalage. Aucune constante suspecte dans wp-config.php ? Regardez le panneau de l’hébergeur et le dossier wp-content/mu-plugins, puis interrogez le support.

5. Un verrou resté en base

Vous cliquez sur « Mettre à jour » et WordPress répond « Une autre mise à jour est actuellement en cours. » ? Pendant une mise à jour du cœur, WordPress pose un verrou, l’option core_updater.lock, pour éviter deux installations simultanées. Si la précédente a planté, le verrou reste. Il saute tout seul au bout de 15 minutes (une heure pour auto_updater.lock, celui des mises à jour automatiques), mais vous pouvez l’effacer sans attendre, je vous montre comment plus bas.

Pour gagner du temps sur le diagnostic, ouvrez Outils > Santé du site. Son test des mises à jour en arrière-plan passe en revue la plupart de ces causes : la constante WP_AUTO_UPDATE_CORE, la coupure complète des mises à jour automatiques (signalée par « Toutes les mises à jour automatiques sont désactivées », sans nommer la constante en cause), un dossier .git ou .svn à la racine, le besoin d’identifiants FTP, les droits d’écriture sur les fichiers et l’échec d’une mise à jour précédente. S’il bloque quelque part, il vous dit où. Sur un site où AUTOMATIC_UPDATER_DISABLED vaut true, il le classe en anomalie critique :

Comment forcer la mise à jour, du plus simple au plus technique

Étape 1 : le lien « Vérifier à nouveau »

Allez dans Tableau de bord > Mises à jour. Au bout de la ligne « Dernière vérification le… », sous la version actuelle, cliquez sur Vérifier à nouveau. Ce lien force une vérification immédiate. Le plus souvent, le bouton vers la dernière version apparaît dans la seconde, et c’est réglé.

Regardez aussi la phrase juste en dessous. « Ce site ne recevra pas de mise à jour automatique pour les nouvelles versions de WordPress. » signifie que les mises à jour automatiques du cœur sont coupées (cause n° 3). Sur un site réglé par défaut, vous lirez plutôt « Ce site est automatiquement maintenu à jour avec les versions de maintenance et de sécurité de WordPress uniquement. »

Étape 2 : corriger wp-config.php

Toujours rien, ou plus de menu du tout ? Ouvrez wp-config.php (par FTP ou le gestionnaire de fichiers de l’hébergeur), après en avoir gardé une copie. Cherchez ces lignes :

// Bloque toute modification de fichiers, mises à jour comprises
define( 'DISALLOW_FILE_MODS', true );

// Coupe les mises à jour automatiques du cœur
define( 'WP_AUTO_UPDATE_CORE', false );

// Coupe toutes les mises à jour automatiques
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Pour débloquer, passez DISALLOW_FILE_MODS à false le temps de la mise à jour, et remplacez WP_AUTO_UPDATE_CORE par 'minor' : les correctifs de sécurité s’installeront seuls, les versions majeures resteront sous votre contrôle. C’est le réglage que je conseille sur un site en production. Si un prestataire a posé ces lignes, prévenez-le avant d’y toucher.

Étape 3 : forcer avec WP-CLI

Si vous avez un accès SSH, WP-CLI (l’outil officiel de WordPress en ligne de commande) contourne l’interface et règle la plupart des blocages. Placez-vous dans le dossier du site et lancez, dans l’ordre :

# 1. Sauvegarde de la base avant tout
wp db export avant-maj.sql

# 2. Version installée, puis vérification fraîche auprès de wordpress.org
wp core version
wp core check-update --force-check

# 3. Si un verrou traîne, on le supprime (et le cache de vérification avec)
wp option delete core_updater.lock
wp transient delete update_core --network

# 4. Mise à jour vers la dernière version mineure de votre branche
wp core update --minor

# 5. Mise à jour de la base si nécessaire, puis contrôle d'intégrité
wp core update-db
wp core verify-checksums

L’option --minor reste sur votre branche : un site en 7.1.1 passe en 7.1.4, un site en 7.0.x passe en 7.0.8, sans saut de version majeure. L’option --network est nécessaire parce que update_core est un transient « de site », même hors multisite. En règle générale, DISALLOW_FILE_MODS ne bloque pas WP-CLI, ce qui en fait l’outil idéal sur un site verrouillé. Et si vous gérez une flotte de sites, MainWP vous montre d’un coup d’œil lesquels sont restés en arrière.

Étape 4 : la mise à jour manuelle par FTP

Pas de SSH ni de menu ? Reste la méthode à l’ancienne, décrite dans la documentation officielle :

1. Faites une sauvegarde complète (fichiers et base), et vérifiez qu’elle est exploitable.
2. Téléchargez l’archive de la dernière version sur fr.wordpress.org pour garder l’interface en français, puis décompressez-la sur votre ordinateur.
3. Désactivez vos plugins.
4. Sur le serveur, supprimez les dossiers wp-admin et wp-includes, puis envoyez ceux de l’archive.
5. Envoyez les fichiers de la racine de l’archive en écrasant les anciens. Ne touchez ni à wp-config.php, ni au dossier wp-content, ni à votre .htaccess.
6. Ouvrez /wp-admin/ : si la base doit être mise à jour, WordPress vous le propose. Réactivez ensuite vos plugins.

Pour le détail de chaque étape et les précautions avant une mise à jour majeure, mon guide pour réussir une mise à jour WordPress sans casser votre site reprend tout.

Le site reste bloqué en maintenance après la mise à jour

Votre site affiche « Indisponibilité temporaire pour cause de maintenance. Veuillez revenir dans un instant. » ? Pendant l’installation, WordPress crée un fichier .maintenance à la racine et le supprime à la fin. Si l’opération plante, il reste. WordPress l’ignore de lui-même au bout de 10 minutes, mais autant le supprimer par FTP (c’est un fichier caché, activez leur affichage) ou avec wp maintenance-mode deactivate. Relancez ensuite la mise à jour : une installation interrompue laisse des fichiers à moitié remplacés, que wp core verify-checksums repère.

Mes recommandations pour ne plus revivre ça

Soyons clairs : sur un site en production, les mises à jour mineures automatiques doivent rester actives. C’est ce mécanisme qui a installé la 7.1.2 en arrière-plan sur les sites qui l’acceptent, sans que leurs propriétaires aient à lever le petit doigt, pendant que les autres découvraient le problème le lendemain. Si vous tenez à garder la main sur les versions majeures, WP_AUTO_UPDATE_CORE sur 'minor' fait le compromis parfait.

Au passage, si vous avez hérité d’un site avec DISALLOW_FILE_MODS, demandez qui applique les correctifs. Si personne ne sait répondre, retirez la constante : un site verrouillé que personne ne met à jour est moins sûr qu’un site qui se patche tout seul. Pour la suite, mon article sur l’amélioration de la sécurité de votre site WordPress couvre le reste des réglages.

Bref : cliquez sur Vérifier à nouveau, contrôlez les trois constantes de wp-config.php, et vérifiez que le numéro affiché est bien 7.1.4 (ou la dernière version de votre branche). Et ne coupez jamais les mises à jour de sécurité sans quelqu’un, ou un outil, pour les faire à la place de WordPress.