Mise à jour automatique de WordPress : faut-il l'activer ou la désactiver ?

Faut-il laisser WordPress installer seul ses mises à jour, ou les désactiver ? Pour les plugins et les thèmes, nous déconseillons les mises à jour automatiques que WordPress applique seul, sans aucun test. Celles d’un hébergeur qui teste chaque mise à jour avant de l’appliquer, et sait revenir à la version précédente, conviennent : à notre avis, pour WordPress, ces vérifications suffisent en général à voir que quelque chose ne va pas. Sans un tel hébergeur, mettez à jour un plugin, ou un thème, à la fois, puis vérifiez qu’il n’introduit pas de dysfonctionnement ; en cas de problème, revenez à la version précédente.

Le NCSC, le centre national de cybersécurité du Royaume-Uni, demande à toutes les organisations d’« appliquer les mises à jour logicielles dès que possible, et idéalement de façon automatique », parce que les attaquants étudient souvent une faille corrigée pour écrire une attaque qui l’exploite ; selon Amazon, l’IA rend ce travail moins coûteux. Le NCSC rappelle que l’éditeur teste lui-même ses mises à jour, tout en demandant de les tester aussi sur ses propres systèmes et de les déployer par étapes. Pour un logiciel que l’on installe et que l’on utilise tel quel (Windows, macOS, un téléphone, un navigateur, un logiciel de bureautique), nous conseillons donc d’activer les mises à jour automatiques de ces logiciels. Pour un service en ligne, c’est son fournisseur qui applique les correctifs. Un site WordPress n’entre dans aucune de ces deux catégories : son propriétaire ne développe pas le logiciel et ne l’utilise pas tel quel, il l’assemble et le configure.

L’éditeur d’un système d’exploitation teste ses mises à jour pour l’ensemble du système. La mise à jour d’un plugin WordPress, elle, ne peut pas être testée à l’avance avec tous les autres plugins installés sur votre site.

Pourquoi nous déconseillons les mises à jour que WordPress applique seul

WordPress est utilisé, en octobre 2026, par près de quatre sites sur dix, et l’essentiel de ses failles ne se trouve pas dans WordPress lui-même. Selon Patchstack, 11 334 nouvelles failles ont été trouvées dans l’écosystème WordPress en 2025 : 91 % dans des plugins, 9 % dans des thèmes, et seulement 6 dans le cœur de WordPress. Et 46 % de ces failles n’avaient pas reçu de correctif de leur développeur au moment de leur publication (Patchstack). Ces chiffres viennent d’une société qui vend des protections contre ces failles.

Elles installent une nouvelle version peu après sa sortie, avant que quiconque ait pu y signaler un problème : du code malveillant glissé dans une version tout juste publiée, ou une nouvelle faille. Le site n’en est donc pas forcément mieux protégé. WordPress.org en tient compte : depuis le 5 juin 2026, chaque nouvelle version d’un plugin de son répertoire attend jusqu’à 24 heures avant d’être distribuée par les mises à jour automatiques, pour laisser à chacun le temps d’examiner ses changements. Et un site WordPress assemble le cœur de WordPress, une version de PHP, et des plugins et des thèmes écrits par des auteurs indépendants les uns des autres. Rien ne garantit que la nouvelle version d’un plugin fonctionne avec la version d’un autre, ni avec la version de PHP du serveur. WordPress l’installe pourtant en production sans qu’aucun test ni aucune personne n’ait vérifié que le site fonctionne encore.

Un hébergeur qui teste chaque mise à jour avant de l’appliquer, et sait revenir à la version précédente, peut s’en charger automatiquement (voir plus bas). Sans un tel hébergeur, la méthode ne change pas, que l’on s’en charge soi-même ou qu’un prestataire le fasse. Elle commence par une sauvegarde : WordPress demande de sauvegarder les fichiers et la base de données avant toute mise à jour, automatique ou manuelle. Ensuite, on met à jour un plugin, ou un thème, à la fois, et l’on vérifie après chacun qu’il n’introduit pas de dysfonctionnement. En cas de problème, on revient à la version précédente en restaurant la sauvegarde, d’abord les fichiers, puis la base de données.

Pour une application développée sur mesure, nous inscrivons la version exacte de chaque dépendance, et chaque mise à jour, une à la fois, passe par le pipeline de déploiement et ses tests automatisés avant d’atteindre la production. Cette règle vient de « Continuous Delivery » (Livraison continue), de Jez Humble et Dave Farley, et des classements de l’OWASP, la fondation de référence sur la sécurité des applications web. Dave Farley est l’inventeur du pipeline de déploiement, qu’on appelle souvent pipeline CI/CD. Le pipeline de déploiement est la chaîne automatique qui prend chaque modification du code, la teste, l’enregistre et la rend prête à partir en production. Pour un site WordPress, versions fixées, pipeline et tests automatisés s’appliquent difficilement. Ils valent la peine quand le site se rapproche d’une application, avec du code écrit sur mesure : c’est le cas décrit plus bas.

Ce que fait WordPress par défaut

Par défaut, WordPress n’installe seul qu’une partie de ses mises à jour. À ce jour (octobre 2026), depuis WordPress 3.7, les mises à jour mineures du cœur s’installent automatiquement par défaut (WordPress). Pour les plugins et les thèmes, les mises à jour automatiques sont à activer une par une depuis WordPress 5.5, et WordPress les lance alors deux fois par jour. Pour les mises à jour majeures du cœur, le réglage par défaut dépend de la date d’installation du site (voir plus bas). La même page de WordPress commence par cette phrase : « Pour garder votre site WordPress sûr, vous devriez toujours mettre à jour vos plugins et vos thèmes vers leur dernière version » (WordPress).

Patchstack a mesuré en 2025 un délai médian de cinq heures entre la publication d’une faille très exploitée et sa première exploitation. Les alertes s’automatisent ; la décision de mettre à jour revient à une personne, qui la prend dès qu’elle reçoit l’alerte. Sur un site WordPress, l’administrateur lance la mise à jour d’un plugin en un clic, puis vérifie que le site fonctionne. Si l’entreprise n’a personne pour s’en charger, un prestataire peut le faire, comme nous le décrivons plus bas.

Deux autres leviers comptent autant. Puisqu’en 2025, près de la moitié des failles de l’écosystème WordPress n’avaient pas de correctif le jour de leur publication, aucune politique de mise à jour, automatique ou manuelle, ne les couvre ce jour-là. Moins de plugins installés, c’est moins de failles possibles, comme pour toute dépendance d’une application. Et un plugin abandonné par son auteur ne recevra plus de correctif : il se remplace.

Activer ou désactiver les mises à jour automatiques de WordPress

Pour les plugins et les thèmes, nous conseillons de désactiver les mises à jour automatiques ; pour le cœur de WordPress, de laisser s’installer seules les mises à jour mineures.

À ce jour (octobre 2026), les mises à jour automatiques des plugins et des thèmes se règlent une par une, depuis l’administration. Dans l’écran Extensions (celui des plugins), la colonne « Mises à jour auto » affiche, pour chaque plugin, un lien qui active ou désactive ses mises à jour ; une action groupée s’applique à plusieurs plugins à la fois. Pour un thème, le lien se trouve dans l’écran Apparence, dans la fenêtre qui s’ouvre quand on clique sur sa vignette. Si ces liens n’apparaissent pas, la fonction a probablement été désactivée par l’hébergeur ou par un plugin.

Pour le cœur de WordPress, le réglage par défaut dépend de la date d’installation du site. Depuis WordPress 5.6, les nouvelles installations reçoivent automatiquement les mises à jour mineures et majeures ; une installation plus ancienne garde son réglage, et reçoit par défaut les seules mises à jour mineures. L’écran des mises à jour de l’administration permet de changer ce réglage.

Les mises à jour mineures du cœur corrigent des failles et assurent la maintenance, et WordPress juge leur désactivation « fortement déconseillée ». Les mises à jour majeures apportent des fonctionnalités nouvelles ; à notre avis, elles se font comme celles des plugins et des thèmes : une à la fois, en vérifiant ensuite que le site fonctionne.

Pour votre équipe technique

Dans wp-config.php, la constante WP_AUTO_UPDATE_CORE fixe ce que le cœur installe seul, et prend le pas sur le réglage de l’écran des mises à jour : true pour toutes les mises à jour, 'minor' pour les seules mises à jour mineures, false pour aucune (WordPress). La constante AUTOMATIC_UPDATER_DISABLED désactive toutes les mises à jour automatiques, cœur et traductions compris. À notre avis, elle ne se justifie que si chaque mise à jour du cœur est testée par ailleurs, comme avec Bedrock, décrit plus bas.

// Dans wp-config.php : le cœur n'installe seul que ses mises à jour mineures
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Pour les plugins et les thèmes, les filtres auto_update_plugin et auto_update_theme décident à la place des liens de l’administration. WordPress conseille de placer ces filtres dans un plugin « must-use », et jamais directement dans wp-config.php. Un plugin « must-use » se place dans le dossier wp-content/mu-plugins, s’active de lui-même et ne peut pas être désactivé depuis l’administration.

<?php
// wp-content/mu-plugins/disable-plugin-theme-auto-updates.php

/**
 * Plugin Name: Disable plugin and theme auto-updates
 */

defined( 'ABSPATH' ) || exit;

// Désactive les mises à jour automatiques de tous les plugins et de tous les thèmes
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

Une mise à jour automatique de WordPress a échoué : que faire ?

Pendant une mise à jour, WordPress met le site en maintenance : il crée un fichier .maintenance à la racine du site, et les visiteurs voient un message de maintenance programmée. Si la mise à jour s’interrompt, le fichier reste en place, et le message aussi. WordPress donne la marche à suivre :

1. Supprimer le fichier .maintenance à la racine du site, par FTP ou par le gestionnaire de fichiers de l’hébergeur. Le message disparaît.
2. Relancer la mise à jour. Si elle échoue encore, la faire à la main, en suivant la procédure de WordPress.
3. Si le site ne fonctionne plus après la mise à jour, restaurer la sauvegarde : d’abord les fichiers, puis la base de données.

La dernière étape suppose une sauvegarde récente, dont la restauration a déjà été essayée : WordPress demande de le vérifier avant d’activer les mises à jour automatiques des plugins.

Quand des plugins ou des thèmes ont été mis à jour automatiquement, le propriétaire du site reçoit un e-mail, même si certaines mises à jour ont échoué. Pour le cœur, un e-mail signale aussi l’échec. Dans l’administration, l’échec s’affiche ainsi : « Une mise à jour automatique de WordPress a échoué en cours de route ; vous pouvez tenter de la relancer ».

Si les mises à jour automatiques ne se lancent jamais, regardez les messages d’erreur de l’écran Outils > Santé du site : elles reposent sur les tâches planifiées de WordPress, qui ne s’exécutent pas correctement sur tous les serveurs.

Qui met PHP à jour, et qui assure la maintenance ?

Les mises à jour de WordPress ne mettent à jour que WordPress, jamais PHP : selon votre hébergement, c’est l’hébergeur ou vous qui installez les correctifs de PHP. Nous conseillons de choisir un hébergeur qui s’en charge, et de lui demander au préalable qui les applique sur votre offre d’hébergement, et dans quel délai.

Pour un site WordPress, rien n’oblige à assurer cette maintenance soi-même. Cybermalveillance.gouv.fr, le service public d’assistance aux victimes d’attaques informatiques, présente ses bonnes pratiques de sécurité d’un site comme des mesures « à adopter ou faire appliquer par son prestataire ». Des hébergeurs spécialisés dans WordPress se chargent de la mise à jour des logiciels du serveur, dont PHP, et des sauvegardes automatiques. Le guide de WordPress sur la sécurité décrit l’hébergeur de confiance : il « fournit les versions stables les plus récentes de tous les logiciels du serveur », « des méthodes fiables de sauvegarde et de restauration », et parle volontiers des mesures de sécurité qu’il propose.

Une offre d’infogérance WordPress met en général PHP et WordPress à jour pour vous. Certaines mettent aussi les plugins à jour automatiquement. La méthode ne change pas pour autant : l’hébergeur met à jour un plugin à la fois, vérifie le site après chacun, et sait revenir à la version précédente. C’est l’option automatique que nous jugeons acceptable : pour WordPress, ces vérifications suffisent en général à voir que quelque chose ne va pas. OVHcloud, par exemple, teste chaque nouvelle version du cœur, des plugins et des thèmes sur une copie temporaire du site avant de l’appliquer. Chez certains hébergeurs, ce type de test est une option payante.

Les plugins payants ou soumis à une clé de licence, et ceux écrits pour le site, restent en général à votre charge. Chacun se met à jour selon la méthode décrite plus haut : un à la fois, en vérifiant ensuite que la fonctionnalité qu’il apporte n’a pas régressé, et en revenant à la version précédente si c’est le cas.

Avant de choisir un hébergeur, posez-lui aussi ces questions :

• Mettez-vous à jour un plugin à la fois, avec une vérification après chacun ?
• Testez-vous les mises à jour sur une copie du site avant de les appliquer ?
• Comment restaurer une sauvegarde ?

Si vous ne souhaitez pas mettre à jour les plugins et les thèmes vous-même, confiez cette tâche à une personne qui administre le site et son serveur. La méthode reste la même : un plugin à la fois, une vérification après chacun, un retour à la version précédente en cas de régression, et PHP mis à jour quand l’hébergeur ne le fait pas. Nous pouvons nous en charger : contactez-nous.

Quand le site contient du code sur mesure

Une application développée sur mesure se met à jour, elle aussi, sur décision. Chaque mise à jour, de PHP comme d’un composant, passe par le pipeline de déploiement et ses tests automatisés ; le correctif d’une faille grave part en production le jour même de sa publication.

Pour votre équipe technique

Tout change le jour où il faut toucher au code. La première règle de WordPress vaut pour tous : « ne touchez pas au cœur de WordPress », parce que chaque mise à jour en écrase les fichiers ; ce que l’on veut ajouter ou modifier passe par un plugin. Pour un thème, un thème enfant permet de le modifier sans toucher à son code, tout en continuant à recevoir ses mises à jour. Ce code écrit sur mesure, thème enfant ou plugin, est un logiciel que l’on développe. Dans « Continuous Delivery », Jez Humble et Dave Farley demandent de garder sous gestion de versions tout ce qui sert à construire et à déployer le logiciel, et de faire passer chaque changement par le pipeline de déploiement. Concrètement, ce code vit dans un dépôt Git et part en production par le pipeline, jamais copié à la main sur le serveur.

Personne n’a besoin de modifier le cœur de WordPress. Ce qui manque à une installation classique est ailleurs. Les plugins s’installent depuis l’administration, sans que leurs versions soient déclarées nulle part, et la configuration tient dans un seul fichier, le même pour tous les environnements. On ne peut donc pas reconstruire à l’identique, sur un environnement de test, le site qui est en production, ce que demandent pourtant Jez Humble et Dave Farley. C’est ce manque que comble Bedrock, de Roots. Il ne modifie pas le cœur de WordPress : il l’enveloppe. WordPress, ses plugins et ses thèmes y deviennent des dépendances, installées par Composer à une version précise et verrouillées dans composer.lock. La configuration change selon l’environnement (développement, recette, production) par des variables d’environnement. Le dépôt Git ne contient plus que le code écrit sur mesure, la configuration et la liste des dépendances, et, selon Roots, le cœur et les plugins ne peuvent plus être modifiés en dehors de l’environnement de développement. Roots présente cette organisation comme l’application à WordPress de la méthode « The Twelve-Factor App » (l’application à douze facteurs), qui décrit comment construire des applications web faciles à déployer et à maintenir. Les mises à jour se font alors dans le code, un plugin à la fois, puis passent par le pipeline. La configuration par défaut de Bedrock désactive, à ce jour, les mises à jour automatiques et l’installation de plugins depuis l’administration (config/application.php).

À notre avis, Bedrock se justifie dès qu’un site WordPress est maintenu comme un logiciel : du code sur mesure, plusieurs environnements, une équipe de développement, un pipeline. Pour un site que l’on configure, auquel on ajoute un thème enfant ou un plugin, il n’est pas nécessaire. Et Bedrock organise le projet, sans plus : la qualité du code écrit sur mesure reste l’affaire de ceux qui le développent.

// config/application.php de Bedrock, configuration par défaut
// Désactive les mises à jour automatiques de WordPress
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Désactive l'éditeur de fichiers de l'administration
Config::define('DISALLOW_FILE_EDIT', true);
// Interdit d'installer ou de mettre à jour des plugins depuis l'administration
Config::define('DISALLOW_FILE_MODS', true);

# Avec Bedrock : mettre à jour un seul plugin, dans le code, puis passer par le pipeline
composer update wp-plugin/plugin-name

Sans Bedrock, le guide de WordPress sur le renforcement de la sécurité conseille de désactiver l’éditeur de fichiers de l’administration, qui permet par défaut de modifier le code PHP des plugins et des thèmes ; il précise que cela n’empêche pas tout, mais peut arrêter certaines attaques (WordPress) :

// Dans wp-config.php : désactive l'éditeur de fichiers de l'administration
define( 'DISALLOW_FILE_EDIT', true );

Pour mettre à jour un plugin à la fois, WP-CLI, l’outil en ligne de commande de WordPress, permet de garder la main : wp plugin update accepte --version pour viser une version précise, --patch pour ne prendre que les corrections, et --dry-run pour voir ce qui serait mis à jour sans rien changer (WP-CLI). La documentation de WordPress elle-même cite les personnalisations et le test préalable sur un environnement de recette comme raisons de désactiver les mises à jour automatiques, et demande, avant de les activer pour les plugins, de pouvoir revenir à la version précédente du site.

Sécuriser un site WordPress

Sur un site WordPress aussi, le code ne doit pas pouvoir être modifié depuis le site, et chaque programme n’a que les droits dont il a besoin. WordPress le prévoit : seul le dossier des contenus envoyés (wp-content) doit être modifiable par le serveur web, et l’éditeur de code intégré à l’administration, souvent « le premier outil qu’un attaquant utilise s’il parvient à se connecter » selon WordPress, peut être désactivé.

Pour votre équipe technique

Le guide de sécurisation de WordPress recommande aussi : utilisateur MySQL limité à la lecture et à l’écriture des données (les droits DROP, ALTER et GRANT peuvent être retirés, en gardant à l’esprit que certaines mises à jour modifient le schéma) ; wp-config.php en permission 400 ou 440 ; DISALLOW_FILE_EDIT, décrit plus haut ; pare-feu applicatif, ModSecurity étant cité comme l’option libre la plus répandue.

Comment nous travaillons

Pour les applications que nous développons, nous inscrivons chaque dépendance à sa version exacte, vérifions chaque jour si une faille connue touche les composants en place, et assurons la supervision des serveurs.

Un site WordPress devient une application quand ses utilisateurs y créent, modifient et conservent leurs propres données, et que le site applique des règles métier à ces données : des commandes avec WooCommerce, un espace membre, des réservations selon des disponibilités. Pour ces applications, comme pour celles développées sur mesure, les mises à jour et les correctifs de sécurité font partie de la maintenance incluse dans notre offre : un logiciel sur mesure à budget mensuel fixe, avec une garantie zéro régression.

Pour aller plus loin

Le 21 octobre 2026, l’équipe de PHP a publié en urgence de nouvelles versions du langage. Elles corrigent deux failles critiques, que leurs découvreurs ont baptisées PHP2Shell. Notre article sur PHP2Shell dit qui est concerné, que faire, dans l’ordre, et comment limiter les dégâts d’une exploitation.

Vous avez une application à faire développer, ou à reprendre en main ? On en parle ?

Sources

• O. Whitehouse, NCSC, « Preparing for a “vulnerability patch wave” », 1er mai 2026.
• NCSC, « Put in place a policy to update by default », version 2.1, 2026.
• NCSC, « Cyber Essentials: Requirements for IT Infrastructure v3.3 », version 3.3, avril 2026.
• CJ Moses, Amazon, « Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot », 21 octobre 2026.
• W3Techs, parts de marché des CMS, relevé du 21 octobre 2026.
• Patchstack, State of WordPress Security in 2026.
• J. Humble et D. Farley, « Continuous Delivery », Addison-Wesley, 2010 : p. 38 (versions exactes des bibliothèques externes).
• OWASP, « A03:2025 Software Supply Chain Failures », Top 10 2025.
• OWASP, « CICD-SEC-3: Dependency Chain Abuse », Top 10 des risques de sécurité des pipelines CI/CD.
• Cybermalveillance.gouv.fr, « Les 10 bonnes pratiques pour sécuriser son site Internet ».
• WordPress, « Hardening WordPress » (choix de l’hébergeur, DISALLOW_FILE_EDIT) et « Upgrading WordPress ».
• WordPress, « WordPress Hosting ».
• Infomaniak, « Découvrir l’app WordPress Infomaniak » (un site installé avec son outil est maintenu « au niveau sécurité » en grande partie par l’hébergeur).
• OVHcloud, « Managed Hosting for WordPress » (chaque nouvelle version du cœur, des plugins et des thèmes testée sur une copie temporaire du site avant d’être appliquée).
• Combell, « WordPress maintenance » (chaque mise à jour du cœur, des plugins et des thèmes vérifiée avant d’être installée).
• one.com, « Update management for WordPress » (mises à jour faites dans un environnement de test, captures d’écran du site comparées avant de les appliquer, retour possible à la version précédente de chaque composant).
• Kinsta, hébergeur américain présent en Europe, « Plugins and Themes – Automatic Updates » (« avant et après chaque mise à jour, Kinsta compare des captures d’écran de votre site », et restaure en cas de changement une sauvegarde faite avant la mise à jour ; option à 3 dollars par mois et par environnement ; les plugins payants ou soumis à une licence n’ont souvent pas d’adresse publique de mise à jour, et ses outils ne peuvent donc pas les mettre à jour).
• WP Engine, hébergeur américain présent en Europe, « Smart Plugin Manager » (« tente de mettre à jour chaque plugin et chaque thème séparément », laisse de côté la version qui a échoué tout en mettant à jour les autres ; prise en charge des plugins payants non garantie).
• M. Mullenweg, WordPress.org, « Protect The Shire », 5 juin 2026.
• WordPress, « FAQ Troubleshooting » (sauvegarde avant toute mise à jour).
• WordPress, « Introduction to Plugin Development » et « Child Themes ».
• WordPress, « Updating WordPress », « Dashboard Updates screen », « Common WordPress Errors », « Backups » et « Must Use Plugins ».
• J. Audras, WordPress, « Plugin and themes auto-updates », 2020, mis à jour en 2023.
• WP-CLI, « wp plugin update ».
• Roots, « Bedrock », Bedrock : « WordPress Dependencies with Composer », « Twelve-Factor WordPress App » et fichier config/application.php.