Une mise à jour a cassé votre site : que faire, dans l’ordre

Le site fonctionnait, une pastille rouge invitait à mettre à jour, un clic plus tard la page d’accueil est cassée ou l’administration inaccessible. Première chose à dire, parce qu’elle change tout le raisonnement : une mise à jour WordPress qui casse le site n’est presque jamais la coupable, elle est le révélateur. Elle met au jour une incompatibilité qui existait déjà, entre deux extensions, avec un thème modifié à la main, ou avec une version de PHP que plus personne ne surveillait. Réparer d’abord, comprendre ensuite, s’organiser enfin.

Ce qui casse réellement lors d’une mise à jour

Quatre familles de rupture, et une seule d’entre elles est vraiment imprévisible.

• Le conflit entre deux extensions qui modifient la même chose. Un module de cache et un module d’optimisation qui réécrivent tous deux le code des pages, par exemple. Chacun fonctionne seul, la nouvelle version de l’un ne supporte plus l’autre.
• L’extension abandonnée qui n’a pas suivi le cœur. Elle appelle une fonction retirée de WordPress, et la mise à jour du cœur transforme cet appel en erreur fatale. Le symptôme classique est l’écran blanc au chargement de l’administration.
• Le thème modifié directement, sans thème enfant. La mise à jour du thème écrase les fichiers modifiés, et tout le travail de personnalisation disparaît en une opération. C’est réversible si une sauvegarde existe, définitif sinon.
• La montée de version de PHP côté hébergeur. La plus sournoise, parce que le client n’a rien fait lui-même : le site casse pendant la nuit sans qu’aucune mise à jour n’ait été lancée. En août 2026, PHP 8.1 est en fin de vie et PHP 8.2 ne reçoit plus que des correctifs de sécurité, jusqu’à la fin de l’année (versions supportées sur PHP.net). Les hébergeurs migrent donc leurs parcs, avec ou sans préavis lu.

Revenir en arrière sans aggraver

Trois chemins de retour existent. Le bon choix dépend d’une seule question : sait-on déjà ce qui a cassé ?

Le retour ciblé sur une extension

C’est l’option la moins destructrice : elle ne touche ni au contenu, ni au reste du site. Attention à une confusion fréquente : depuis WordPress 6.3, si une mise à jour manuelle d’extension échoue, l’ancienne version est automatiquement restaurée. Mais quand la mise à jour réussit techniquement et casse le site, aucun bouton natif ne permet de redescendre. Il faut soit une extension dédiée au retour de version, soit récupérer l’archive de la version précédente sur la fiche publique de l’extension, soit une ligne de commande :

wp plugin update nom-de-l-extension --version=3.4.2

Notez la version que vous quittez avant de mettre à jour : sans ce numéro, le retour arrière devient une enquête.

La restauration de l’instantané pris avant la mise à jour

Rapide et propre, à condition que votre hébergeur ou votre outil de sauvegarde prenne un instantané automatique avant chaque mise à jour. Le prix à payer est toujours le même : vous perdez ce qui a été créé entre-temps. Sur un site vitrine, c’est indolore ; sur une boutique, une restauration à la veille efface une journée de commandes. Encore faut-il que la sauvegarde fonctionne, ce qui suppose de l’avoir testée : voir des sauvegardes réellement testées.

Le retour par le dépôt de code

Quand le site est suivi dans un dépôt de code, chaque modification est enregistrée séparément, avec sa date et son auteur. Annuler une modification précise devient une commande unique, sans toucher au contenu ni aux commandes de la journée. C’est la différence entre un retour chirurgical et un retour au bulldozer, et c’est la raison pour laquelle nous conseillons de suivre son site dans un dépôt Git dès qu’il comporte du code sur mesure.

Trouver le coupable en dix minutes

Si le retour arrière n’est pas possible, il faut identifier le composant fautif. La méthode est la dichotomie, pas l’essai un par un. Désactivez tout, vérifiez que le site revient, puis réactivez par moitiés successives : avec trente extensions, cinq essais suffisent là où l’approche naïve en demande trente. Sans accès à l’administration, la même chose se fait en renommant le dossier wp-content/plugins par FTP ou depuis le gestionnaire de fichiers de l’hébergeur.

Deux raccourcis évitent souvent tout ce travail. Le journal d’erreurs PHP donne fréquemment le nom du fichier fautif en une ligne, donc le nom de l’extension : activez WP_DEBUG_LOG et lisez wp-content/debug.log. Et la page Outils puis Santé du site indique la version de PHP réellement active, qui n’est pas toujours celle que vous croyez. Si le site est complètement inaccessible, appliquez d’abord le protocole d’urgence quand le site est en panne.

Le vrai sujet : mettre à jour sans jouer à la roulette

Réparer une fois ne sert à rien si la procédure reste la même. Cinq points, et ils tiennent en un quart d’heure par mois :

1. Une sauvegarde vérifiée juste avant, pas une sauvegarde supposée. Vérifier veut dire ouvrir l’archive et regarder sa date et sa taille.
2. L’exécution sur une copie de préproduction avant le site réel.
3. La lecture du journal des modifications des extensions structurantes : celles qui gèrent le paiement, les formulaires, le référencement ou le constructeur de pages. Une mention de changement majeur vaut un test approfondi.
4. La mise à jour par lots, trois ou quatre composants à la fois, plutôt que les vingt-sept d’un coup. En cas de problème, vous savez immédiatement où chercher.
5. Un contrôle visuel des pages sensibles après coup : tunnel de commande, formulaire de contact, page de connexion. Un site peut s’afficher parfaitement et ne plus rien encaisser.

Et une règle d’organisation qui vaut toutes les techniques : choisissez une fenêtre de mise à jour, un mardi matin par exemple. Un clic un vendredi à 18 h, c’est un week-end entier de site cassé, et la découverte du problème par vos clients avant vous (documentation WordPress sur les mises à jour).

Notre position : automatique ou manuel, la bonne réponse est mixte

Les articles français laissent ce débat dans le flou, en général pour ne froisser personne. Nous tranchons : automatique pour les correctifs de sécurité mineurs du cœur, manuel et supervisé pour tout le reste. WordPress applique déjà les versions mineures automatiquement, et c’est très bien : ce sont des correctifs ciblés, testés à grande échelle, et la fenêtre entre la publication d’une faille et son exploitation automatisée se compte en jours. Les versions majeures, les extensions structurantes et le thème, en revanche, se mettent à jour quand quelqu’un est disponible pour regarder le résultat.

Le raisonnement de fond est celui du risque asymétrique. Ne pas mettre à jour coûte peu aujourd’hui et beaucoup dans six mois, quand le site est compromis ou trop vieux pour évoluer. Mettre à jour trop tôt coûte une journée de dépannage. Mettre à jour sans filet, en revanche, coûte cher tout de suite. C’est ce dernier cas qu’il faut supprimer, et c’est précisément ce que couvrent nos mises à jour supervisées et notre suivi technique. L’inverse a un coût lui aussi, détaillé dans les conséquences d’une maintenance négligée.

Ce que change une préproduction

Une préproduction est une copie complète du site, à une adresse privée et non indexée, sur laquelle on teste avant de toucher au site réel. Le cycle tient en trois temps : tester, valider, appliquer. Ce qui casse casse sur la copie, devant une seule personne, sans client, sans commande perdue et sans urgence.

Elle ne sert d’ailleurs pas qu’aux mises à jour : c’est aussi là que se refont les pages, que s’essaient les nouvelles fonctionnalités et que se prépare une migration. C’est, à notre avis, le seul investissement qui supprime réellement la peur de mettre à jour, parce qu’il déplace le risque hors du site que voient vos clients.

Tester avant d’appliquer est exactement ce que couvre notre maintenance WordPress à Pau.

Questions fréquentes

Peut-on désactiver toutes les mises à jour ?

Techniquement oui, stratégiquement non. Un site figé devient vulnérable en quelques mois, parce que les failles corrigées ailleurs sont publiques et exploitées automatiquement. Le sujet n’est pas de mettre à jour ou non, mais de savoir dans quel ordre et avec quel filet.

Comment savoir si une extension est abandonnée ?

Trois signaux suffisent, tous visibles sur sa fiche publique : la date de dernière mise à jour, la version de WordPress avec laquelle la compatibilité est déclarée, et l’activité du support. Au-delà d’un an sans mise à jour, considérez qu’elle ne sera plus corrigée.

Faut-il mettre à jour PHP ?

Oui, mais après avoir testé sur une copie. Une version de PHP en fin de vie ne reçoit plus aucun correctif de sécurité, et beaucoup d’extensions cessent de la prendre en charge. La montée se prépare, elle ne s’improvise pas.

Que faire si le retour arrière est impossible ?

Corriger en avant : identifier précisément le composant fautif, le remplacer par un équivalent maintenu, et documenter la correction. C’est souvent la bonne décision quand l’extension en cause n’est plus développée.

Conclusion

La peur des mises à jour n’est pas le symptôme d’une technologie fragile, c’est le symptôme d’un site sans filet. Un site correctement outillé, avec une sauvegarde testée, une préproduction et un historique du code, se met à jour sans que personne ne retienne son souffle. La première action à mener aujourd’hui est la plus simple : ouvrez votre dernière sauvegarde et vérifiez qu’elle existe vraiment.

Confier mes mises à jour Discuter d’un environnement de préproduction