Pourquoi vous ne pouvez plus vous permettre de désactiver les mises à jour automatiques de WordPress

L’ancien conseil : couper les mises à jour automatiques

Désactiver les mises à jour automatiques de WordPress avait du sens quand les mises à jour étaient la première cause de sites cassés. Une mise à jour d’extension pouvait entrer en conflit avec une autre, une mise à jour de thème pouvait déplacer un bouton, et le découvrir un lundi matin était pire que de mettre à jour tranquillement un vendredi. Propriétaires de sites et agences ajoutaient donc AUTOMATIC_UPDATER_DISABLED ou WP_AUTO_UPDATE_CORE dans wp-config.php, laissaient les interrupteurs de mise à jour automatique des extensions éteints et planifiaient une journée de mises à jour manuelles.

WordPress a pris le chemin inverse. Les versions mineures du cœur s’installent automatiquement depuis WordPress 3.7 ; depuis WordPress 5.5, les administrateurs peuvent activer les mises à jour automatiques extension par extension et thème par thème ; et depuis WordPress 5.6, les nouvelles installations mettent aussi à jour automatiquement les versions majeures du cœur. Les mises à jour automatiques des extensions et des thèmes s’exécutent deux fois par jour via WP-Cron. Le pari de la plateforme est clair : pour la plupart des sites, être à jour est plus sûr qu’être prudent à la main.

Pourquoi la pile de mises à jour ne cesse de grossir

Si vous posez la question autour de vous, la plupart des sites WordPress comptent entre 20 et 30 extensions. Certains sites fonctionnent très bien avec cinq extensions, tandis que d’autres en ont besoin de 50 pour fonctionner : une boutique avec paiements, livraison, factures, avis, SEO, cache, sauvegardes, formulaires et constructeur de pages y arrive vite. Chacune est un code distinct, écrit par un développeur distinct et publié selon son propre calendrier.

Les mises à jour deviennent alors un flux continu plutôt qu’un événement ponctuel. Si chacune de 25 extensions publie une version tous les un ou deux mois, cela fait entre 12 et 25 mises à jour d’extensions par mois, sans compter le cœur de WordPress, votre thème, WooCommerce et ses extensions. Personne n’examine longtemps autant de changements à la main. Le vrai choix est entre laisser les mises à jour s’accumuler et automatiser à la fois la mise à jour et la vérification.

Raison n° 1 : l’IA trouve les failles plus vite que jamais

Le nombre de failles connues dans WordPress augmente fortement. Patchstack a recensé 11 334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, soit 42 % de plus qu’en 2024, dont 91 % dans des extensions. Chacune est une raison pour l’auteur de publier une mise à jour, et une raison pour votre site d’en avoir besoin.

L’IA accélère la découverte. En mai 2026, des chercheurs de TrendAI et de CHT Security ont indiqué avoir utilisé l’IA pour trouver plus de 300 vulnérabilités zero-day critiques dans des extensions WordPress en 72 heures, pour environ 20 dollars par vulnérabilité. Le rapport 2026 de Patchstack avertit que les attaquants disposent d’une IA de plus en plus capable de trouver et d’exploiter des failles par elle-même. Quand trouver une faille coûte moins cher qu’un déjeuner, les extensions de votre site sont examinées en permanence, par les défenseurs comme par les attaquants.

Les attaques arrivent en quelques heures, plus en quelques semaines

Une journée hebdomadaire de mises à jour manuelles suppose qu’il se passe des jours entre la publication d’un correctif et la première attaque. Ce n’est plus le cas. Patchstack a constaté que les failles les plus ciblées étaient exploitées pour la première fois en médiane cinq heures après leur divulgation, et que 46 % des failles n’étaient pas corrigées au moment de leur publication : quand le correctif sort, les attaquants savent déjà quoi chercher.

Le cœur de WordPress n’y échappe pas. Le 17 juillet 2026, WordPress 7.0.2 et 6.9.5 ont corrigé une faille critique, surnommée ensuite wp2shell, qui pouvait permettre à un visiteur anonyme d’exécuter du code sur le serveur. WordPress.org a déployé le correctif via le système de mises à jour automatiques, un code d’exploitation était public en moins d’une journée, et Coalition a signalé des attaques sur ses honeypots dès le 20 juillet. Un site aux mises à jour automatiques désactivées, qui prévoyait de mettre à jour le vendredi suivant, est resté exposé pendant tout ce temps.

Le pare-feu de votre hébergeur ne couvre pas non plus cette fenêtre de façon fiable : Patchstack a mesuré que les protections d’hébergement courantes n’ont bloqué que 26 % des attaques lors de ses tests. Un pare-feu est une couche supplémentaire utile, pas un substitut à la version corrigée.

Raison n° 2 : l’IA accélère aussi le code vers lequel vous mettez à jour

L’autre face de ce changement, c’est la façon dont le logiciel est écrit. Dans l’enquête State of Code 2026 de Sonar auprès de plus de 1 100 développeurs, les répondants indiquent que 42 % du code qu’ils valident est déjà généré ou assisté par l’IA, et s’attendent à 65 % d’ici 2027, alors que seuls 48 % disent toujours vérifier le code généré par l’IA avant de le valider.

Pour un site WordPress, cela signifie plus de versions, des changements plus importants à chaque version et davantage d’occasions qu’une mise à jour touche quelque chose dont votre site dépend : un modèle, un hook, une classe CSS, un champ de commande. La pression de la sécurité accélère la sortie des mises à jour ; le développement assisté par IA élargit chacune d’elles. Vous ne pouvez pas examiner cette pile à la main, et la geler ne fait qu’échanger un problème visible contre un problème invisible.

Désactiver les mises à jour ne supprime pas le risque, il le cache

Avec les mises à jour automatiques désactivées, rien ne casse pendant la nuit, et le site paraît stable. Mais la version vulnérable continue de tourner, et les extensions obsolètes ou abandonnées sont l’une des portes d’entrée les plus fréquentes des sites WordPress compromis. La panne change simplement de forme : au lieu d’une commande cassée que vous remarquez aujourd’hui, vous avez un skimmer de cartes injecté ou un compte administrateur caché que vous découvrez des mois plus tard.

Pour les boutiques en ligne, les dégâts arrivent le plus souvent lentement, pas lors d’une panne spectaculaire. Les mises à jour sont repoussées parce que la dernière a cassé quelque chose. Un développeur corrige un conflit d’extensions à la main et facture ses heures. Un correctif de sécurité attend la prochaine fenêtre de maintenance. Au bout d’un an, le site est trop fragile pour que quiconque ose le mettre à jour. Les boutiques WooCommerce échouent rarement à cause d’une seule panne : elles échouent parce que les faire tourner est devenu, sans bruit, plus coûteux et plus angoissant que prévu.

Si vous gardez volontairement quelque chose à une ancienne version (une extension très personnalisée, un module premium avec son propre système de mise à jour), vous devez savoir dès qu’il devient un risque. C’est le rôle de la surveillance des vulnérabilités, qui signale les extensions et thèmes installés présentant des failles connues ou sans mise à jour récente, et de la surveillance de l’intégrité des fichiers, qui repère les fichiers du cœur et des extensions qui ne correspondent plus à la version officielle.

Comment toutes ces mises à jour peuvent quand même dérégler votre site

La plupart des problèmes commencent par les extensions. Les extensions WordPress provoquent très souvent des problèmes de fonctionnement, ce qui en fait la première cause de pannes, d’erreurs et de failles de sécurité des sites. Les conflits entre extensions arrivent en tête des causes que le guide de dépannage officiel de WordPress donne pour l’écran blanc de la mort et le message « Il y a eu une erreur critique sur ce site », et la première solution qu’il propose est de désactiver les extensions. Côté sécurité, 91 % des nouvelles vulnérabilités recensées par Patchstack en 2025 concernaient des extensions.

Rester à jour ne rend pas les mises à jour inoffensives. Une mise à jour peut entrer en conflit avec une autre extension, modifier un hook dont dépend votre thème, exiger une version de PHP plus récente, renommer la classe CSS ciblée par vos styles ou ajouter un script qui plante sur mobile. Sur WooCommerce, après la mise à jour d’un modèle, la copie obsolète de votre thème continue de s’afficher, et un champ de commande ou un nonce disparaît sans bruit. Une mise à jour interrompue peut bloquer tout le site sur « Brièvement indisponible pour cause de maintenance planifiée ».

La plupart de ces pannes ne font pas tomber le site, donc les contrôles de disponibilité restent au vert. Ce qui casse, c’est un parcours (ajouter au panier, payer, se connecter, envoyer un formulaire) ou une mise en page qui ne s’affiche mal que sur un modèle. Le panorama complet de ce qui change sous un site, mises à jour comprises, se trouve dans notre guide sur les raisons pour lesquelles les sites cassent alors que personne n’y a touché.

Une politique de mises à jour WordPress plus sûre pour 2026

Commencez par la liste des extensions elle-même : leur nombre compte moins que le fait que chacune soit encore maintenue. Cinquante extensions activement mises à jour peuvent être plus sûres que quinze extensions abandonnées ; remplacez donc celles dont la dernière mise à jour date de plusieurs années et supprimez celles que vous n’utilisez plus. Ensuite, gardez toujours activées les mises à jour automatiques de sécurité du cœur de WordPress, et activez les mises à jour automatiques des extensions et des thèmes pour tout ce qui provient d’une source maintenue. Si vous retenez quelque chose, par exemple une version majeure de WooCommerce ou d’un constructeur de pages, faites-le un jour pour lire le changelog, jamais pour un correctif de sécurité, et notez-le pour que cela ne dure pas un mois.

Rendez la récupération peu coûteuse : des sauvegardes quotidiennes dont vous avez réellement testé la restauration, et la connaissance de la façon dont votre hébergeur rétablit une version précédente d’une extension. Utilisez un environnement de préproduction pour les grosses refontes et les sauts de version majeure si vous en avez un, mais ne laissez pas son absence devenir la raison d’arrêter les mises à jour.

Enfin, et surtout, retestez automatiquement le site juste après les mises à jour. Le point faible des mises à jour automatiques n’a jamais été la mise à jour elle-même, mais le fait que personne ne vérifiait la commande avant qu’un client se plaigne. Dès que chaque mise à jour est suivie d’un vrai test des parcours qui vous rapportent de l’argent, les activer n’est plus un pari.

Comment Relvato vous aide à garder le contrôle sur la pile de mises à jour

Relvato fait de cette dernière étape quelque chose auquel vous n’avez pas à penser. Son extension WordPress signale chaque mise à jour d’extension, de thème, du cœur et de WooCommerce dès qu’elle a lieu, et en quelques minutes Relvato relance les contrôles susceptibles d’être touchés, dans un vrai navigateur : la commande, la connexion et les moyens de paiement, la régression visuelle et la dérive de structure sur vos pages clés, ainsi que la recherche d’erreurs PHP et JavaScript et de liens cassés. Chaque exécution enregistre la mise à jour qui l’a déclenchée, pour qu’une alerte vous dise ce qui a cassé et quelle mise à jour examiner.

Relvato n’installe pas les mises à jour et ne les annule pas : WordPress et votre hébergeur s’en chargent. Il vous donne la confiance nécessaire pour laisser les mises à jour automatiques activées : si une mise à jour casse quelque chose, vous le savez en quelques minutes et non quand les ventes chutent. Il surveille aussi l’autre face du problème en signalant les extensions présentant des failles connues et les fichiers qui ne correspondent pas à la version officielle. Découvrez son fonctionnement sur WordPress sur la page surveillance WordPress, et ce qu’il contrôle pour les boutiques sur la page surveillance WooCommerce.