Mises à jour automatiques
Les mises à jour automatiques sont le mécanisme par lequel WordPress installe seul, en arrière-plan, certaines mises à jour du cœur, des extensions, des thèmes et des traductions.
Définition
Les mises à jour automatiques sont le mécanisme par lequel WordPress installe seul, en arrière-plan, certaines mises à jour du cœur, des extensions, des thèmes et des traductions. Ce que ce mécanisme couvre n’est pas le même d’un site à l’autre, et c’est pour cela qu’il se lit sur chaque site plutôt qu’il ne se suppose.
Ce que le mécanisme couvre, famille par famille
Quatre familles, et elles ne se comportent pas du tout de la même façon.
Les mises à jour automatiques en arrière-plan existent depuis WordPress 3.7, introduites pour améliorer la sécurité des sites. La documentation en distingue quatre familles : le cœur, les extensions, les thèmes et les fichiers de traduction.
| Famille | Ce qui part seul par défaut | Où se règle la suite |
|---|---|---|
| Traductions | Tout, par défaut | Un filtre, si l’on veut arrêter |
| Cœur, versions mineures | Oui sur la quasi-totalité des sites | Écran des mises à jour, constante ou filtre |
| Cœur, versions majeures | Selon l’âge du site, voir ci-dessous | Écran des mises à jour, constante ou filtre |
| Extensions | Non, sauf cas particuliers | Un lien à activer extension par extension |
| Thèmes | Non, sauf cas particuliers | Un lien à activer thème par thème |
La distinction entre version majeure et version mineure est celle que décrit la fiche mise à jour majeure et mineure : les mineures portent les corrections et la sécurité, les majeures apportent des fonctionnalités. C’est précisément cette frontière que le réglage automatique suit.
Pourquoi deux sites identiques ne se comportent pas pareil
À cause d’une règle de bascule qui dépend de la date de création du site.
Avant WordPress 5.6, tous les sites recevaient automatiquement les versions mineures du cœur et les traductions, rien de plus. Depuis la 5.6, la documentation est explicite : une nouvelle installation reçoit par défaut les versions mineures et les majeures, sauf si WordPress détecte que le site est suivi par un outil de gestion de version. Les installations plus anciennes, elles, conservent l’ancien comportement, tant qu’un administrateur, une constante ou un filtre ne l’a pas changé.
La conséquence pratique, pour un parc de sites. Deux sites du même client, administrés par les mêmes personnes, peuvent avoir des comportements opposés sur les versions majeures du cœur, simplement parce que l’un a été installé avant la bascule et l’autre après. Aucune règle générale ne permet de deviner l’état d’un site depuis l’extérieur : il faut le lire, site par site.
Où le réglage se trouve réellement
À trois endroits, et le premier trouvé n’est pas toujours celui qui décide.
L’écran des mises à jour
C’est le réglage visible dans l’administration, celui qui permet d’activer ou non les versions majeures du cœur. Pour les extensions et les thèmes, l’activation se fait ailleurs, dans les listes correspondantes, avec un lien à cliquer sur chaque ligne. Il n’y a pas d’interrupteur global.
Les constantes du fichier de configuration
Deux constantes existent. L’une désactive tout le mécanisme, et la documentation décourage explicitement son usage, puisque ce sont les mises à jour automatiques qui apportent les correctifs de sécurité. L’autre pilote le cœur selon trois valeurs possibles : tout, rien, ou les mineures seulement. Point important : quand elle est définie, cette constante l’emporte sur le réglage visible dans l’administration. Un site peut donc afficher un choix qui n’est pas celui qui s’applique.
Les filtres, posés par une extension
Le réglage le plus fin passe par des filtres, qui permettent de traiter séparément les versions de développement, mineures et majeures. La documentation précise où les placer : dans une extension obligatoire, jamais directement dans le fichier de configuration, parce que WordPress n’y est pas encore entièrement chargé et que cela crée des conflits avec les outils en ligne de commande.
Il existe un quatrième endroit, en dehors de WordPress : l’hébergement. La documentation cite les outils de gestion proposés par les hébergeurs, qui permettent de lancer les mises à jour et d’en configurer l’automatisation depuis leur propre interface, certains les activant par défaut. Sur ces offres, un réglage pris dans le tableau de bord de WordPress peut donc cohabiter avec un autre, décidé ailleurs, et c’est une source de surprise classique quand un site se met à jour alors que tout paraissait désactivé.
Lire ces trois endroits est le seul moyen de répondre à la question « ce site se met-il à jour tout seul ». C’est aussi ce qu’un prestataire devrait pouvoir vous dire de mémoire pour chaque site dont il a la charge, et ce qu’un contrat de maintenance précise quand il est écrit sérieusement.
Relevé du 18 septembre 2026 sur ilti.fr, en lecture seule. Le fichier de configuration ne contient aucune des deux constantes : ce sont donc les réglages du site qui s’appliquent. Ils sont à « activé » pour les trois types de mises à jour du cœur, développement, mineures et majeures : ce site installe seul jusqu’aux versions majeures. Côté extensions, le contraste est net : une seule sur trente est réglée pour se mettre à jour toute seule, et aucun des six thèmes installés ne l’est. Au même moment, trois extensions attendent une mise à jour, et aucune des trois ne partira d’elle-même. Autrement dit, sur ce site, le mécanisme automatique protège la partie qui casse le plus rarement, le cœur, et laisse à la main la partie qui pose le plus de problèmes, les extensions. Dernier élément du relevé : un dossier de travail nommé upgrade-temp-backup, que WordPress utilise le temps d’une mise à jour, porte la date du 17 septembre à 01 h 30 et se trouve vide aujourd’hui. Le mécanisme a donc bien tourné cette nuit-là, et l’opération s’est terminée sans rien laisser derrière elle.
Ce qu’il est raisonnable de laisser en automatique
Le débat porte rarement là où on l’attend.
Sur les versions mineures du cœur et les traductions, il n’y a pas vraiment de débat : ce sont elles qui transportent les correctifs de sécurité, et la documentation déconseille explicitement de les désactiver. Les laisser actives est le réglage par défaut, et c’est le bon.
Le vrai arbitrage porte sur les extensions. Une extension qui se met à jour seule à trois heures du matin peut casser une page sans que personne ne le voie avant le lendemain. Une extension laissée à la main peut rester six mois en retard sur un correctif de sécurité, ce qui est la porte d’entrée la plus fréquente vers un site piraté. Les deux risques sont réels, et le choix dépend de ce qui est surveillé : l’automatique se défend quand quelqu’un regarde le site après, la main se défend quand les mises à jour sont passées à date fixe, sur une préproduction d’abord.
Un point mérite d’être connu, parce qu’il change la façon de surveiller : WordPress envoie un courriel après une mise à jour automatique du cœur, en cas de succès comme en cas d’échec, et ce courriel peut être coupé par un filtre. Une boîte qui ne reçoit plus rien ne signifie donc pas qu’il ne se passe rien.
Enfin, le réglage automatique ne dispense pas du reste. Il n’installe rien sur une extension abandonnée, puisqu’il n’y a plus de mise à jour à installer, et il ne rend pas un retour arrière inutile : il le rend plus nécessaire, puisque l’opération s’est faite sans vous.
Questions fréquentes
Comment savoir si mon site installe seul les versions majeures ?
Cela se lit à trois endroits, dans cet ordre de priorité : la constante définie dans le fichier de configuration, qui l’emporte sur tout le reste, un éventuel filtre posé par une extension, puis le réglage visible sur l’écran des mises à jour. La date de création du site donne une présomption, pas une réponse.
Faut-il activer les mises à jour automatiques des extensions ?
Il n’y a pas de réponse unique. Le critère n’est pas l’extension, c’est la surveillance : une mise à jour automatique sur un site que personne ne regarde transforme une panne de cinq minutes en panne de trois jours. Sur un site suivi, elle raccourcit au contraire le délai d’exposition à une faille.
Peut-on tout désactiver ?
Techniquement oui, par une constante ou par un filtre. La documentation le déconseille explicitement, parce que le mécanisme est présenté comme l’un des meilleurs moyens de garder un site à jour et sûr. Si l’on coupe, il faut assumer de faire à la main, à date fixe, ce que le site faisait tout seul.
Les mises à jour automatiques remplacent-elles une sauvegarde ?
Non, et elles la rendent plus utile. Une mise à jour survenue pendant la nuit se découvre après coup, ce qui suppose de pouvoir revenir en arrière sans avoir assisté à l’opération. C’est le rôle de la sauvegarde, prise avant et vérifiée.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.