Comment configurer les mises à jour automatiques du cœur de WordPress (WP_AUTO_UPDATE_CORE)

Depuis WordPress 3.7, la plateforme met à jour certaines parties d'elle-même automatiquement, sans que personne ne clique sur quoi que ce soit. La plupart des propriétaires de sites en sont vaguement conscients, mais peu ont une vision claire de ce qui est mis à jour, quand, et comment changer le comportement par défaut. Ce guide passe en revue les quatre niveaux de mises à jour automatiques pris en charge par le cœur de WordPress, ce que chaque niveau fait réellement, et lequel est le bon choix selon que vous gérez un site unique, un portefeuille d'agence ou une configuration d'hébergement infogéré.

Ce que WordPress met à jour automatiquement par défaut

Sans configuration particulière, toute installation WordPress en 2026 effectue les opérations suivantes sans rien demander :

• Mises à jour mineures du cœur. Le passage de 6.5.1 à 6.5.2 se fait automatiquement, en arrière-plan, le jour même de la publication. Ces versions sont des correctifs de bogues et des correctifs de sécurité. Elles sont explicitement conçues pour être installées sans test préalable en toute sécurité.
• Mises à jour des fichiers de traduction. Les packs de langue se rafraîchissent automatiquement.
• Versions de sécurité du cœur pour les branches plus anciennes. Même si votre site est encore en 6.4 parce que vous n'avez pas effectué de mise à jour majeure, les correctifs de sécurité sont rétroportés et appliqués automatiquement.

Ce qui ne se produit pas automatiquement par défaut :

• Mises à jour majeures du cœur. Le passage de 6.5 à 6.6 nécessite un clic manuel. WordPress affiche la bannière dans l'administration mais ne l'installe pas de lui-même.
• Mises à jour des extensions et des thèmes. Les deux peuvent être activées élément par élément via l'interface d'administration (depuis WordPress 5.5), mais ni l'une ni l'autre n'est activée par défaut. Il s'agit d'un sujet distinct, qui n'est pas contrôlé par WP_AUTO_UPDATE_CORE.

La raison de cette distinction relève d'une bonne ingénierie : les versions mineures sont publiées sous une politique stricte de « pas de changements cassants », ce qui rend leur mise à jour silencieuse réellement peu risquée. Les versions majeures introduisent occasionnellement de nouvelles API ou modifient des comportements dont les thèmes et les extensions peuvent dépendre, et faire passer silencieusement la production à une version majeure a causé suffisamment de problèmes par le passé pour que le projet retienne ce comportement par défaut conservateur.

Les quatre niveaux de mises à jour automatiques du cœur

La constante WP_AUTO_UPDATE_CORE dans wp-config.php contrôle tout cela. Elle accepte quatre valeurs :

• true : toutes les mises à jour du cœur sont installées automatiquement, à la fois mineures et majeures. L'option agressive.
• 'minor' : la valeur par défaut si la constante n'est pas définie. Seules les versions mineures et de sécurité sont installées automatiquement. Les versions majeures restent manuelles.
• 'beta' et 'rc' : utilisées par les sites qui veulent des builds de pré-version. Réaliste uniquement sur un environnement de staging ou de test, jamais en production.
• false : toutes les mises à jour automatiques du cœur sont désactivées. Le site ne fait rien de lui-même. Vous êtes responsable de chaque correctif, y compris les correctifs de sécurité.

Définir l'une de ces valeurs ne demande qu'une seule ligne dans wp-config.php, n'importe où au-dessus du commentaire /* That's all, stop editing! Happy publishing. */ :

define('WP_AUTO_UPDATE_CORE', true);

ou

define('WP_AUTO_UPDATE_CORE', 'minor');

Enregistrez le fichier, aucun redémarrage n'est nécessaire. WordPress vérifie les mises à jour selon une planification (deux fois par jour par défaut) et applique ce que le paramètre actuel autorise.

Quel paramètre a du sens pour quel type de site ?

La réponse honnête dépend de trois éléments : combien de tests sont réalisés avant la mise en production d'une version, qui s'aperçoit quand quelque chose casse, et la qualité de la stratégie de sauvegarde.

Site de production standard, sans contrat de maintenance dédié

Paramètre recommandé : true (toutes les mises à jour automatiques).

L'intuition selon laquelle « les mises à jour majeures automatiques sont dangereuses » est en grande partie dépassée. Les mises à jour majeures de WordPress sont stables depuis des années, et l'alternative réaliste est « personne ne met à jour le site pendant six mois parce qu'il n'y a pas de contrat pour ça, et un trou de sécurité connu reste ouvert ». Un site WordPress non maintenu est un pire résultat que la très rare mise à jour automatique qui casse quelque chose. Si une version majeure casse le site, restaurer depuis une sauvegarde est plus rapide que le temps que vous passeriez sinon à courir après la mise à jour manuelle plus tard. L'automatisation est gagnante.

Hébergement infogéré (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Paramètre recommandé : ce que fait le tableau de bord de l'hébergeur, généralement 'minor' au niveau de WordPress.

La plupart des hébergeurs infogérés exécutent leur propre flux de mise à jour par-dessus WordPress. Ils prennent d'abord un instantané, installent la version majeure sur un clone de staging, exécutent un diff visuel basique et ne l'appliquent qu'ensuite à la production. C'est nettement plus sûr que des mises à jour automatiques classiques. Si vous êtes sur ce type d'hébergeur, définir WP_AUTO_UPDATE_CORE à autre chose que la valeur par défaut entre généralement en conflit avec la logique propre de l'hébergeur. Laissez-le tranquille, laissez l'hébergeur faire son travail et consultez le tableau de bord de l'hébergeur pour l'historique des mises à jour.

Portefeuille d'agence avec contrat de maintenance

Paramètre recommandé : 'minor' en production, true en staging.

Si un contrat de maintenance précise que vous testez les mises à jour avant leur mise en production, l'agence joue le rôle de filet de sécurité. La production doit tout de même recevoir automatiquement les versions mineures et de sécurité (qui ne sont pas optionnelles d'un point de vue sécurité), mais les mises à jour majeures passent par le flux de tests de l'agence. Les environnements de staging sont l'endroit approprié pour configurer la valeur la plus agressive, afin que les testeurs détectent les régressions tôt.

Construction WordPress sur mesure avec forte personnalisation du thème ou des extensions

Paramètre recommandé : 'minor', plus un véritable processus de test pour les mises à jour majeures.

Les sites fortement personnalisés (en-têtes refaits, blocs Gutenberg personnalisés, intégrations bizarres avec un constructeur de pages, points de terminaison REST personnalisés) sont précisément le cas où une mise à jour majeure peut casser quelque chose de subtil. Le paramètre 'minor' par défaut est le bon plancher : ne renoncez pas aux correctifs de sécurité, mais traitez les majeures comme une tâche distincte avec une vraie passe de test.

Site à haute disponibilité qui ne peut absolument pas tomber en panne

Paramètre recommandé : false pour le cœur, plus un véritable processus de release.

C'est le seul cas où désactiver entièrement les mises à jour automatiques du cœur a du sens. Banque, santé, environnements réglementés où chaque modification passe par un processus de release. Notez que vous acceptez la pleine responsabilité d'appliquer manuellement les correctifs de sécurité dans les heures qui suivent une publication, sur chaque site. La plupart des équipes qui choisissent ce paramètre disposent également d'une surveillance de la liste de diffusion sécurité de WordPress et d'un pipeline de déploiement capable de livrer les correctifs le jour même.

Comment vérifier que votre paramètre est actif

1. Dans l'administration WordPress, allez dans Outils, Santé du site, Infos.
2. Dépliez la section Constantes WordPress.
3. Recherchez WP_AUTO_UPDATE_CORE. Si elle affiche votre valeur, la constante est bien lue.
4. Pour une vérification plus poussée, regardez la section Mises à jour dans la barre latérale d'administration. Les mises à jour automatiques récentes y apparaissent avec leurs horodatages.

Si la valeur de la constante n'apparaît pas dans la Santé du site, la cause la plus probable est qu'elle a été définie après que le fichier l'avait déjà définie auparavant (le premier define l'emporte, et PHP émet une notice que vous pourriez ne pas voir), ou que vous avez modifié le mauvais wp-config.php.

Ce qui peut mal tourner avec les mises à jour automatiques du cœur

Trois modes d'échec sont réalistes et méritent d'être connus :

• La mise à jour échoue partiellement. Le téléchargement ou l'extraction se casse à mi-chemin, souvent parce que l'hébergeur n'a pas assez d'espace disque, qu'il a atteint une limite d'inodes, ou en raison d'un problème réseau temporaire. WordPress dépose un fichier .maintenance à la racine et le site affiche « Brièvement indisponible pour cause de maintenance programmée » indéfiniment. Solution : connectez-vous en SFTP à la racine et supprimez le fichier .maintenance, puis relancez la mise à jour depuis l'administration.
• La mise à jour réussit mais une extension commence à générer des erreurs. Surtout après une mise à jour majeure, une extension non maintenue peut casser face aux nouvelles API du cœur. Solution : ayez une sauvegarde sous la main, identifiez l'extension défectueuse à partir du journal d'erreurs (ou en désactivant les extensions une par une), puis mettez-la à jour ou remplacez-la.
• La mise à jour est silencieusement ignorée. Raisons courantes : DISALLOW_FILE_MODS est défini dans wp-config.php (ce qui bloque toutes les mises à jour, automatiques ou non), les permissions de fichiers sur le répertoire WordPress empêchent PHP d'écrire, ou le site utilise Git pour le contrôle de version et WordPress détecte le répertoire .git et désactive les mises à jour par mesure de sécurité. La page Santé du site signale généralement ces cas.

Mises à jour automatiques et DISALLOW_FILE_MODS

Les deux constantes interagissent d'une manière qui prend les gens au dépourvu. DISALLOW_FILE_MODS (couvert dans notre base de connaissances sous le sujet de l'éditeur de fichiers) bloque toutes les modifications de fichiers depuis WordPress, y compris les mises à jour automatiques du cœur. Si les deux constantes sont définies :

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

Le résultat est que DISALLOW_FILE_MODS l'emporte. WordPress ne fera aucune mise à jour automatique. Ce n'est rarement ce que les gens souhaitent. Soit vous voulez un site verrouillé qui se met à jour depuis l'extérieur (pipeline de déploiement, WP CLI), auquel cas DISALLOW_FILE_MODS = true est correct et WP_AUTO_UPDATE_CORE est sans pertinence. Soit vous voulez que le site se mette à jour tout seul, auquel cas DISALLOW_FILE_MODS ne doit pas être défini.

Qu'en est-il des mises à jour automatiques des extensions et des thèmes ?

Les mises à jour automatiques des extensions et des thèmes constituent un mécanisme distinct, arrivé avec WordPress 5.5. Elles se configurent élément par élément dans l'administration (liste des Extensions, lien « Activer les mises à jour automatiques » sur chaque ligne) ou globalement via des filtres. La recommandation générale : activez les mises à jour automatiques pour toute extension dont vous faites confiance à la discipline de release du mainteneur, et laissez-les désactivées pour les extensions qui livrent régulièrement des changements cassants. Les versions majeures de WooCommerce, en particulier, méritent souvent d'être retenues pour une mise à jour manuelle accompagnée d'un test rapide.

Si vous voulez activer les mises à jour automatiques des extensions de manière programmatique pour toutes les extensions, ce filtre fait l'affaire :

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Placez cela dans une petite extension must-use sous wp-content/mu-plugins/ plutôt que dans functions.php, afin qu'un changement de thème ne la désactive pas.

L'essentiel pour les mises à jour du cœur : pour la plupart des sites en 2026, le paramètre par défaut 'minor' est conservateur dans la mauvaise direction. Soit vous définissez WP_AUTO_UPDATE_CORE à true et vous laissez la plateforme se maintenir à jour, soit vous vous engagez dans un véritable processus de maintenance qui traite manuellement les mises à jour majeures dans un délai raisonnable. Le juste milieu « paramètres par défaut sans surveillance » est ce qui produit des sites WordPress non patchés en retard de deux versions, et c'est l'état réellement à haut risque.