Mises à jour automatiques WordPress : le guide

Un bandeau « mise à jour disponible » qui traîne trois semaines dans le tableau de bord, une extension restée sur une version vulnérable, ou à l'inverse un site qui plante après une mise à jour appliquée en pleine nuit sans surveillance : les mises à jour automatiques de WordPress rassurent autant qu'elles inquiètent.

Le point de départ est plus nuancé qu'on ne le dit. La documentation officielle de WordPress, mise à jour le 1er juillet 2026, distingue les installations neuves et les installations existantes, ce qui change la réponse à la question « les versions majeures sont-elles automatiques ? ». Ce guide fait le point sur ce qui est automatique par défaut, sur les réglages qui existent vraiment, sur le temps que l'automatisation fait gagner ou perdre (calcul illustratif), et sur le plan à suivre pour garder la main.

Ce que dit la documentation officielle

Les mises à jour automatiques en arrière-plan sont apparues avec WordPress 3.7. La page « Upgrading WordPress » du guide d'administration avancée distingue quatre types : noyau, extensions, thèmes et fichiers de traduction. Avant WordPress 5.6, tous les sites recevaient par défaut les versions mineures du noyau et les traductions. Depuis WordPress 5.6, une installation neuve reçoit aussi les versions majeures, sauf si WordPress détecte une copie sous gestion de versions. Une installation existante garde l'ancien comportement tant qu'un administrateur, une constante ou un filtre n'active pas les versions majeures.

Conséquence pratique : deux sites WordPress du même âge n'ont pas forcément le même comportement. Avant d'écrire « mon site se met à jour tout seul », il faut regarder l'écran Tableau de bord, Mises à jour, et chercher dans le fichier de configuration une constante qui aurait changé la règle. La constante, quand elle existe, l'emporte sur le réglage de l'écran.

La documentation recommande de placer les filtres dans une extension à chargement obligatoire (dossier mu-plugins) et non directement dans le fichier de configuration : à cet endroit WordPress n'est pas entièrement chargé, ce qui peut créer des conflits avec d'autres outils comme WP-CLI. Elle déconseille aussi de désactiver les mises à jour du noyau : les développeurs ont choisi de les activer par défaut parce que c'est l'un des meilleurs moyens de garder un site à jour et sécurisé.

Cinq repères pour organiser les mises à jour automatiques

1. Laisser le noyau se mettre à jour seul sur les versions mineures. C'est le comportement par défaut pour les correctifs de sécurité et de maintenance : il n'y a rien à activer, et aucune raison technique de le désactiver sur un site standard.

2. Trier les extensions avant d'automatiser. Une extension largement utilisée, mise à jour régulièrement par son auteur et sans personnalisation locale peut passer en automatique avec un risque limité. Une extension modifiée dans son code, liée au paiement ou à la réservation, ou peu maintenue, gagne à rester en vérification manuelle. Le réglage se fait extension par extension dans la colonne « Mise à jour automatique » de l'écran Extensions : la documentation de WordPress.org décrit aussi ce réglage pour les thèmes.

3. Ne jamais automatiser sans une sauvegarde récente et testée. La documentation de WordPress conseille de sauvegarder avant toute mise à jour et de vérifier que la sauvegarde est utilisable. Elle ajoute qu'un retour à une version plus ancienne n'est pas recommandé, notamment parce que les versions récentes embarquent des correctifs de sécurité et que la structure de la base peut changer : sans sauvegarde du site et de la base, un retour arrière réussi est très difficile à garantir.

4. Garder une trace des mises à jour appliquées. Après une mise à jour du noyau, WordPress envoie un e-mail à l'administrateur, avec trois types possibles : succès, échec, critique. Le filtre qui le supprime existe : ne l'utiliser que si une autre alerte prend le relais.

5. Revoir le site après une montée de version majeure. Si les versions majeures sont automatiques sur le site, un contrôle de quelques pages clés (accueil, formulaire, paiement) après chaque version majeure évite de découvrir une régression par un client.

Calcul illustratif : le temps gagné dépend du contrôle après coup

Prenons un parc fictif de 24 sites WordPress, 15 extensions par site, soit 360 extensions, avec en moyenne une mise à jour par extension tous les deux mois : 180 mises à jour par mois. Hypothèse : 3 minutes par mise à jour manuelle, soit 9 heures par mois. Si 75 % des extensions passent en automatique, il reste 45 mises à jour manuelles par mois (135 minutes), auxquelles s'ajoute un contrôle hebdomadaire de chaque site. Ces valeurs sont des hypothèses de calcul, pas des mesures.

Le résultat est instructif : l'automatisation ne fait gagner du temps que si le contrôle après coup reste léger. À 5 minutes par site et par semaine, elle en fait perdre, ce qui ne veut pas dire qu'elle est inutile, puisqu'elle réduit le délai entre la sortie d'un correctif et son application. Elle appelle simplement un contrôle rapide et standardisé : une page d'accueil, un formulaire, une page de paiement, et l'e-mail du noyau.

Ce que cherchent les internautes

Relevé DataForSEO sur la France, de septembre 2025 à août 2026. Le sujet précis a un volume très faible : les internautes cherchent la mise à jour en général, la nouvelle version majeure et les failles. La colonne « Moyenne mensuelle » reprend le volume moyen indiqué par DataForSEO.

Non mesurées dans la base : « mises à jour automatiques wordpress », « activer mises à jour automatiques wordpress » et « wordpress 6.9 » ; « mise à jour plugin wordpress » et « mise à jour thème wordpress » existent sans volume. Le pic de « wordpress 7 » en mai 2026 (3 600) et celui de « faille wordpress » en juillet 2026 (720) montrent que l'intérêt se concentre autour des annonces de versions et des alertes de sécurité, sans que ces données établissent de lien de cause avec un événement précis.

Plan d'action en quatre temps

Aujourd'hui. Ouvrir l'écran Mises à jour de chaque site, noter son type d'installation (neuve depuis la version 5.6 ou ancienne) et chercher une constante dans le fichier de configuration.

Cette semaine. Classer les extensions en trois groupes : automatiques, à vérifier avant application, à ne pas toucher sans test sur une copie.

Ce mois-ci. Programmer une sauvegarde avant chaque série de mises à jour et tester une restauration complète.

Chaque semaine. Contrôler en cinq minutes les pages clés, lire l'e-mail du noyau et noter dans le carnet de maintenance ce qui a changé.