Vous venez de cliquer sur « Mettre à jour maintenant » et votre site affiche une page blanche ? Vous hésitez entre commencer par les extensions, le thème ou le cœur de WordPress ? Ou vous vous demandez si vous pouvez laisser WordPress faire sa mise à jour tout seul, sans y penser ?
La mise à jour WordPress est l'opération la plus banale de la vie d'un site… et celle qui en casse le plus. Pas parce qu'elle serait compliquée : parce qu'on la fait dans le désordre, ou sans filet.
Dans cet article, on ne va pas vous montrer où cliquer - ça, vous l'avez déjà trouvé. On vous donne l'ordre exact des opérations, celui qu'on applique sur les sites qu'on maintient : sauvegarde, extensions, thème, cœur, puis PHP. Et on traite chaque échec un par un, avec le geste qui débloque : page blanche, erreur critique, mise à jour bloquée, mode maintenance coincé.
C'est l'étape que tous les tutoriels expédient en une ligne, et c'est justement celle qui vous sauve la mise.
Une sauvegarde de la base de données seule ne suffit pas : si un fichier de thème ou d'extension casse après la mise à jour, restaurer la base ne réparera rien, le code fautif sera toujours là. Inversement, sauvegarder uniquement les fichiers vous fait perdre les contenus, les réglages et les commandes passées pendant la mise à jour. Il faut les deux : les fichiers et la base de données.
Concrètement, avant de toucher à quoi que ce soit :
wp-content (thèmes, extensions, médias).Notre règle interne : si la sauvegarde n'est pas terminée et vérifiée, la mise à jour n'a pas commencé. Sur un site client, une mise à jour lancée à la main a fait tomber le site en pleine opération : la restauration depuis la copie complète prise juste avant la mise à jour a remis le site en ligne, sans perte. Sans cette copie, c'était une soirée entière à reconstruire un site à l'aveugle.
Si vous voulez la méthode complète, on l'a détaillée dans notre guide sur la sauvegarde d'un site WordPress - ce qu'il faut sauvegarder, où, et à quelle fréquence.
C'est le cœur du sujet, et c'est aussi ce qui manque le plus souvent. L'ordre des opérations décide si une mise à jour est une formalité ou une soirée de dépannage.
1. Les extensions, une par une. Commencez par celles qui touchent au contenu et au commerce (page builder, formulaires, WooCommerce), mettez à jour une extension, rechargez le site, regardez. Puis la suivante. Les extensions gratuites désactivées et jamais utilisées, supprimez-les plutôt que de les mettre à jour.
2. Le thème. Mettez à jour le thème actif, puis vérifiez la page d'accueil et une page intérieure. Si vous avez un thème enfant avec des personnalisations, c'est le moment de regarder si quelque chose a bougé visuellement.
3. Le cœur de WordPress. Tableau de bord → Mises à jour → « Mettre à jour maintenant ». Pendant l'opération, le site passe quelques secondes en maintenance, c'est normal. Ne fermez pas l'onglet et ne relancez pas le clic : on y revient plus bas, c'est justement ce qui produit le message « une autre mise à jour est en cours ».
4. La mise à jour PHP de WordPress, en dernier. PHP est la couche du dessous : c'est le langage dans lequel tourne WordPress et toutes vos extensions. La changer en même temps qu'autre chose, c'est mélanger deux causes possibles de panne et ne plus savoir laquelle accuser.
Pour situer le terrain en novembre 2026 : WordPress 7.1 fonctionne avec PHP 7.4 minimum et jusqu'à PHP 8.5, mais l'équipe Hosting de WordPress recommande PHP 8.4 ou plus récent pour un site en production. Et le calendrier presse : PHP 8.3 n'est plus maintenu que pour les correctifs de sécurité depuis le 31 décembre 2025, et PHP 8.2 atteint sa fin de vie le 31 décembre 2026.
Avant de monter la version PHP, vérifiez donc deux choses : ce que votre hébergeur propose dans son panneau (l'onglet « PHP » ou « Select PHP version »), et si vos extensions annoncent la compatibilité dans leur fiche. Puis changez la version, ouvrez trois pages, testez un formulaire, et laissez passer 48 heures avant de considérer que c'est gagné.
La mise à jour WordPress automatique fait peur, souvent pour de mauvaises raisons. Voici ce que WordPress met à jour tout seul, et ce qu'il ne fera jamais sans vous.
Ce qui est automatique depuis longtemps : depuis WordPress 3.7, les versions mineures et les correctifs de sécurité du cœur s'installent en arrière-plan, sans intervention. C'est ce mécanisme qui a rendu la plupart des sites réellement à jour sur les failles critiques.
Ce qui reste un choix : une version majeure de WordPress (passer de 6.9 à 7.0, par exemple) demande normalement un clic. Et depuis WordPress 5.5, vous pouvez activer les mises à jour automatiques extension par extension (colonne « Mise à jour automatique » dans Extensions) et thème par thème (dans la fiche du thème, sous Apparence → Thèmes). WordPress lance ces vérifications deux fois par jour et vous envoie un e-mail, que ça ait réussi ou échoué.
Ce qui est raisonnablement sûr :
functions.php.Ce qui ne l'est pas :
Chez nous, c'est la vérification qui compte autant que la mise à jour : ce n'est pas la mise à jour qui casse un site, c'est ce qu'on n'a pas regardé autour. Si vous voulez la base côté protection, notre article sur la sécurité WordPress couvre les réglages à poser une fois pour toutes.
Avant le détail, la règle : ne cliquez pas dix fois. La plupart des messages d'échec sont des verrous, pas des pannes, et insister aggrave la situation. Gardez la sauvegarde à portée de main, et traitez un seul cas.
| Ce que vous voyez | Cause la plus fréquente | Premier geste |
|---|---|---|
| Page blanche | Erreur PHP fatale dans une extension ou un thème | Désactiver les extensions une par une |
| « Erreur critique sur ce site » | Extension ou thème incompatible | Mode de récupération WordPress |
| « Une autre mise à jour est en cours » | Verrou resté posé dans la base | Attendre, puis supprimer le verrou |
| « La mise à jour a échoué » | Fichiers non modifiables par le serveur | Vérifier les permissions / identifiants FTP |
| Site bloqué en maintenance | Fichier .maintenance resté en place |
Le supprimer à la racine |
| Le bouton ne fait rien | Permissions, verrou ou serveur saturé | Mise à jour manuelle par FTP |
La page blanche WordPress - écran blanc, aucune erreur, parfois même pas le back-office - signifie presque toujours une erreur PHP fatale : le code s'arrête avant d'avoir affiché quoi que ce soit. Dans 9 cas sur 10, c'est une extension ou un thème qui n'est pas compatible avec la nouvelle version.
La méthode : connectez-vous en FTP, renommez le dossier wp-content/plugins en wp-content/plugins-off, rechargez le site. S'il revient, c'est bien une extension. Renommez le dossier dans l'autre sens, puis désactivez les extensions une par une depuis l'admin jusqu'à trouver la coupable, et laissez-la désactivée le temps que son éditeur publie une version compatible. Même logique pour le thème : renommez son dossier, WordPress bascule sur un thème par défaut.
Depuis WordPress 5.2, le fameux « Erreur critique WordPress » ne vous laisse pas seul : WordPress envoie un e-mail à l'adresse de l'administrateur, avec un lien de connexion qui ouvre le site en mode de récupération. Dans ce mode, l'extension ou le thème fautif est mis en pause pour votre session seulement - vos visiteurs, eux, voient toujours l'erreur, mais vous pouvez travailler.
Ouvrez le lien, connectez-vous, repérez l'encart qui nomme le composant en cause, désactivez-le, puis cliquez sur « Quitter le mode de récupération » et vérifiez le site. Si l'e-mail n'arrive pas (hébergement qui bloque les envois, filtre antispam), la même désactivation se fait en FTP en renommant le dossier de l'extension suspecte.
Ce message apparaît quand WordPress a posé un verrou dans la base avant de mettre à jour, et ne l'a pas retiré. C'est volontaire : ça empêche deux mises à jour simultanées d'abuser de la même table. Le verrou dure normalement 15 minutes après la fin de l'opération.
Attendez une heure avant de faire quoi que ce soit. Si le message est toujours là, c'est un verrou orphelin. Sauvegardez la base, puis, dans phpMyAdmin, ouvrez la table wp_options (le préfixe peut être différent chez vous), cherchez la ligne core_updater.lock et supprimez uniquement celle-là. En ligne de commande, l'équivalent est wp option delete core_updater.lock. Rechargez ensuite Tableau de bord → Mises à jour : les boutons sont revenus.
Quand la mise à jour a échoué, WordPress affiche un message explicite avec un lien pour réessayer. Ne le prenez pas au pied de la lettre : avant de réessayer, vérifiez que le fichier .maintenance n'est pas resté à la racine de votre installation (voir le cas suivant) et que le site répond.
Ce message vient très souvent d'un problème de droits sur les fichiers. Si WordPress vous demande un identifiant FTP au moment de mettre à jour, c'est que le serveur web n'a pas le droit d'écrire dans ses propres fichiers. Deux options : donner les identifiants FTP demandés pour cette opération, ou faire corriger les permissions par l'hébergeur. Sur un site qu'on reprend, on règle ça une fois pour toutes : sinon, chaque mise à jour devient une négociation.
Pendant une mise à jour, WordPress crée un fichier .maintenance à la racine : c'est lui qui affiche « Brièvement indisponible pour une maintenance planifiée ». Si l'opération échoue en cours de route, le fichier reste et votre site reste fermé à tous vos visiteurs.
Une fois certain qu'aucune mise à jour ne tourne, supprimez .maintenance à la racine, via FTP ou le gestionnaire de fichiers. Le site se rouvre immédiatement. Si vous voulez savoir d'où vient le blocage et comment poser un vrai mode maintenance propre, notre article sur le mode maintenance WordPress détaille les réglages et les pièges.
WordPress ne se met à jour et rien ne se passe : pas de message, pas de progression, parfois un retour à l'écran précédent. Trois causes reviennent :
Dans ce cas, ne vous acharnez pas : passez à la méthode manuelle.
Quand rien ne passe par l'administration, la mise à jour manuelle règle le problème en dix minutes. La méthode officielle :
wp-admin et wp-includes sur le serveur.wp-admin et wp-includes à leur place par FTP.wp-content dans votre wp-content existant, sans supprimer votre dossier : c'est là que vivent vos thèmes, extensions et médias.index.php, wp-login.php, etc.). Votre wp-config.php n'est pas touché..maintenance s'il est resté./wp-admin : WordPress détecte le changement et propose de mettre la base à jour. Suivez le lien, puis réactivez vos extensions.
Si vous en êtes à la troisième manipulation, si vous ne savez plus quel dossier vous avez renommé, ou si le site est en panne depuis plus d'une heure alors qu'il fait vivre votre activité : arrêtez. Une mise à jour ratée est un problème de vingt minutes quand on a l'habitude ; c'est une journée entière quand on cherche à l'aveugle.
C'est exactement ce que couvre notre dépannage WordPress en urgence : diagnostic gratuit, intervention rapide, à partir de 75 €HT, et un dépannage garanti 30 jours. Un client a installé lui-même une extension qui a provoqué une erreur critique : le monitoring a alerté et l'intervention a eu lieu dans l'heure. C'est à ça que sert de ne pas être seul sur ce genre de manipulation.
La mise à jour est terminée, le tableau de bord vous dit que tout va bien. Le tableau de bord ne visite pas votre site à votre place. Cinq vérifications, dix minutes :
Ajoutez à ça un coup d'œil aux journaux d'erreurs de l'hébergeur dans les 24 heures : c'est là qu'apparaissent les avertissements PHP qui ne cassent rien aujourd'hui et cassent tout au prochain passage de version.
Tout ce qui précède est faisable soi-même. C'est juste à refaire chaque mois, sur un site qui vit, avec des extensions qui bougent toutes seules.
Dans la formule de maintenance WordPress à 752 €HT/an, soit 62,67 €HT/mois, voilà comment les mises à jour sont organisées :
Le détail de ce qui est inclus est sur la page maintenance WordPress, et le prix comme les prestations hors forfait sont sur la page tarifs - sans reconduction tacite.
Les correctifs de sécurité et les versions mineures s'installent tout seuls. Pour le reste : les extensions et le thème une fois par mois dans un usage classique, une fois par semaine si le site prend des commandes ou des demandes de devis. Une version majeure de WordPress se traite dans les semaines qui suivent sa sortie, une fois la sauvegarde vérifiée - pas le jour même, pas six mois après.
D'abord une faille : les vulnérabilités corrigées sont publiées, donc connues, donc exploitées automatiquement. Ensuite l'accumulation : plus vous attendez, plus l'écart entre votre site et la version actuelle est grand, plus la mise à jour devient risquée. Et un jour, votre hébergeur retire la version de PHP que votre site utilise encore, et le site s'arrête sans prévenir.
Non, sauf si vous acceptez de reconstruire le site. La sauvegarde est aussi ce qui rend la mise à jour réversible : sans elle, un plantage vous laisse sans retour en arrière possible, et il ne reste que le dépannage dans l'urgence. C'est un réflexe à prendre une fois, pour toutes les mises à jour suivantes.
Pas en soi. Elle est même le meilleur rempart contre les failles connues, parce qu'elle agit en heures, pas en semaines. Ce qui est dangereux, c'est une mise à jour automatique sans sauvegarde et sans personne pour regarder le site ensuite : le site peut être cassé pendant des jours sans que personne ne s'en aperçoive.
C'est le cas le plus simple à rattraper : dans le panneau de votre hébergeur, remettez la version PHP précédente - le site se remet en ligne dans la minute, puisque le changement est une simple bascule de configuration. Ensuite, mettez à jour les extensions et le thème qui n'étaient pas prêts, attendez leurs versions compatibles, et retentez. C'est précisément pour ça qu'on garde PHP pour la fin.
Copie complète le lundi, mises à jour chaque semaine, vérification derrière et intervention 7j/7 si quelque chose casse : c'est notre maintenance WordPress, pour 752 €HT/an.
.maintenance. Page mise à jour le 7 novembre 2026.core_updater.lock et méthode de suppression.