Mettre à jour WordPress soi-même, c’est gratuit jusqu’au jour où ça casse tout
Lundi 20 juillet, 8h30. J’ouvre mes mails et j’apprends qu’une nouvelle faille critique de sécurité touchant WordPress nécessite une mise à jour. Joie, bonheur et allégresse… « C’est lundi », aka Jesse Garon. Sauf qu’en tant qu’agence web, c’est pas un ou deux sites qu’on doit patcher mais presque une centaine. Réunion de crise, plan de bataille, et en moins de 24 heures les sites étaient sécurisés. (Merci ma team !)
Vous pourriez penser qu’il n’y a pas de quoi en faire un fromage, qu’il suffisait de cliquer sur le bouton « Mettre à jour ». Mais bien sûr… On clique et on passe au suivant. Sauf que la suite, on la connaît : un plugin qui casse le rendu, le plugin de paiement qui se met à bégayer, les stats qui ne remontent plus, les formulaires de contact qui n’envoient plus rien. Et ce n’est plus le temps d’un clic qu’on y passe, mais toute la journée pour revenir en arrière, corriger, puis relivrer une version propre. Ce n’est pas si rare qu’on le croit : sur les forums, les témoignages de mises à jour ratées se comptent par dizaines.
Donc la vraie question n’est pas s’il faut mettre à jour. C’est comment, et sur cent sites à la fois, qu’est-ce qui a permis de le faire sans y passer la semaine.
Cas 1 : la faille qui tombe un lundi matin
Concrètement, il s’agissait d’une faille critique dans le cœur de WordPress, qui enchaînait deux vulnérabilités : une confusion de routage dans l’API REST batch (CVE-2026-63030, « wp2shell ») et une injection SQL dans WP_Query (CVE-2026-60137). Résultat : exécution de code à distance sans authentification, sur les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Corrigée depuis en 6.9.5 et 7.0.2.
Une faille de cette gravité, on ne peut pas se permettre d’attendre le prochain cycle de maintenance trimestriel. Ça, tout le monde est d’accord. Le problème, c’est que « patcher vite » en prod directement, sans rien vérifier avant, c’est prendre un autre risque : celui de casser un plugin de paiement, un formulaire personnalisé, une intégration métier qui dépendait d’un comportement de l’ancienne version. On a vu des sites reprendre après une mise à jour de sécurité mal testée avec un panier qui ne validait plus les commandes. La faille est corrigée, le chiffre d’affaires du jour, lui, ne revient pas.
Cas 2 : le client qui met à jour tout seul, en prod, sans Git
C’est le cas le plus fréquent, et le moins spectaculaire, jusqu’au jour où. Un client reçoit la notification « mise à jour disponible » dans son admin WordPress, clique, et la mise à jour se fait directement sur le site en ligne. Pas d’environnement de test. Pas de versioning. Si quelque chose casse (un plugin devenu incompatible, un thème qui affiche n’importe quoi), il n’y a pas de « retour arrière » propre. Juste une restauration de sauvegarde à l’aveugle, en espérant qu’elle soit récente, et en acceptant de perdre au passage tout ce qui a été modifié depuis (contenu, commandes, formulaires reçus).
Ce n’est pas un problème de compétence. C’est un problème d’outillage. Sans Git, chaque mise à jour est un pari : soit ça passe, soit on répare dans l’urgence sans savoir précisément ce qui a changé.
Ce que Git et un environnement de dev changent concrètement
Un site versionné avec Git, c’est simple : avant toute mise à jour, on connaît l’état exact du code. Si la mise à jour casse quelque chose, on peut comparer précisément ce qui a changé, isoler le fichier ou la fonction en cause, et revenir en arrière en quelques secondes plutôt qu’en restaurant une sauvegarde complète (avec toute la perte de données que ça implique).
Ajoutez un environnement de développement séparé de la prod, et la mise à jour se teste avant d’être vue par un seul visiteur. C’est exactement là que se joue la différence entre « on a eu de la chance » et « on savait que ça allait tenir ».
Notre méthode de maintenance WordPress, et pourquoi on s’y tient
Chez artwaï, on ne met jamais à jour un site WordPress directement en production. Chaque mise à jour (core, plugins, thèmes) est d’abord appliquée sur notre serveur de développement, où on fait tourner des tests automatisés et des tests manuels avant de passer en prod. Une fois en production, on refait les mêmes vérifications (automatisées et manuelles) pour s’assurer que rien ne s’est comporté différemment entre les deux environnements. Les correctifs de sécurité critiques comme celui du 20 juillet sont traités en priorité, en dehors du cycle habituel, mais toujours avec cette même vérification. En plus des sauvegardes quotidiennes généralement assurées par l’hébergement, chaque intervention est tracée dans un bon de livraison transparent, décompté d’un pool de jours annuel qu’on ne facture qu’à l’usage réel.
On mesure aussi l’impact de chaque mise à jour avec un audit MilleCheck de la prod, avant et après. C’est ce qui nous permet de repérer si une mise à jour a fait reculer une bonne pratique ou dégradé la performance, et pas seulement de vérifier que le site s’affiche encore correctement.
Alors, on fait quoi ?
La faille qui arrive sans prévenir un lundi matin, la mise à jour qui casse tout parce que personne ne l’a testée avant : ce sont deux versions du même problème, et une seule réponse. Pas un argument commercial de façade, juste ce qui fait la différence entre un site qui tient et un site qui tombe.
L’automatisme a sa place : il détecte qu’une mise à jour existe et peut même l’installer. Mais il ne sait pas répondre à la seule question qui compte, celle de savoir si elle va casser quelque chose de spécifique à votre site. Ça, seule une vérification humaine assistée ou pas par une IA (on a rien contre) sur un environnement de test peut le dire. Si votre site tourne encore sans Git ni environnement de test, la question à se poser n’est pas si une mise à jour va un jour poser problème, mais quand, et si vous aurez un filet ce jour-là. C’est précisément ce filet qu’on met en place quelle que soit la maintenance WordPress qu’on nous confie.
