Mises à jour automatiques WordPress : pourquoi elles viennent de sauver des milliers de sites

Une décision rare

En publiant WordPress 7.0.2 le 17 juillet 2026, l’équipe de WordPress.org n’a pas seulement mis un correctif à disposition. Elle a forcé les mises à jour automatiques sur les sites tournant en version vulnérable.

C’est une mesure exceptionnelle, réservée aux situations où le risque justifie d’intervenir sans attendre l’action du propriétaire du site. Elle mérite qu’on s’y arrête, parce qu’elle raconte beaucoup sur la façon dont un site web se maintient réellement.

Comment fonctionnent les mises à jour automatiques

Depuis la version 3.7, WordPress sait se mettre à jour tout seul. Par défaut, le comportement est le suivant :

• Mises à jour mineures et de sécurité (de 7.0.1 vers 7.0.2 par exemple) : activées automatiquement.
• Mises à jour majeures (de 6.9 vers 7.0) : désactivées par défaut, c’est à toi de déclencher.
• Plugins et thèmes : désactivés par défaut, activables individuellement.

Ce découpage est plutôt bien pensé. Les correctifs de sécurité, qui ne changent presque jamais le comportement du site, passent tout seuls. Les changements structurants attendent ta validation.

Le mécanisme de forçage utilisé pour 7.0.2 s’appuie sur ce même système : WordPress.org signale que la mise à jour doit être appliquée, et les sites concernés l’installent d’eux-mêmes.

Le piège : beaucoup de sites l’ont désactivé

Voici le nœud du problème. Sur les sites professionnels, les mises à jour automatiques sont très souvent désactivées, pour des raisons qui ne sont pas absurdes :

• une mise à jour a cassé le site une fois, et on ne veut plus revivre ça ;
• le site a des personnalisations dans le thème ou dans le cœur, et personne n’ose y toucher ;
• l’agence qui a livré le site a bloqué le mécanisme pour garder la main ;
• un plugin de sécurité ou d’optimisation les a désactivées.

La conséquence est directe : le forçage décidé par WordPress.org ne s’applique pas sur ces sites. Ils restent vulnérables tant que quelqu’un n’intervient pas manuellement.

C’est le paradoxe classique de la sécurité : la précaution prise pour éviter un petit risque (une mise à jour qui casse un affichage) expose à un risque bien plus grand (une prise de contrôle du site).

Vérifier si elles sont actives chez toi

Trois endroits à contrôler.

1. Le fichier wp-config.php. Cherche des lignes de ce type :

define( 'AUTOMATIC_UPDATER_DISABLED', true );
define( 'WP_AUTO_UPDATE_CORE', false );

Si l’une des deux est présente et positionnée ainsi, les mises à jour automatiques sont bloquées.

Les valeurs saines sont :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

qui active les correctifs de sécurité tout en laissant les mises à jour majeures sous ton contrôle. La valeur true active tout, y compris les majeures.

2. Le fichier functions.php du thème. Certains développeurs y ajoutent des filtres qui désactivent le mécanisme. Cherche auto_update ou automatic_updater.

3. Tes plugins. Les plugins de sécurité et de maintenance proposent souvent une option de gestion des mises à jour. Vérifie leurs réglages.

Un test simple : va dans Tableau de bord puis Mises à jour. WordPress y indique explicitement si ton site est configuré pour se mettre à jour automatiquement.

Faut-il les activer sur tous les sites ?

Ma réponse, après avoir repris pas mal de sites mal entretenus : oui pour les mises à jour de sécurité, presque toujours.

Le calcul est simple. D’un côté, le risque qu’une mise à jour mineure casse quelque chose : faible, et généralement réparable en quelques minutes. De l’autre, le risque de rester exposé à une faille critique pendant des semaines : moins probable, mais potentiellement fatal pour l’activité.

Il existe cependant des cas où la prudence se justifie :

• site de vente en période critique (soldes, lancement) : on gèle tout pendant quelques jours, en connaissance de cause ;
• site avec du code sur mesure fragile : là, la vraie réponse est de corriger la fragilité, pas de bloquer les mises à jour indéfiniment ;
• environnement avec préproduction : on teste d’abord ailleurs, puis on applique. C’est la bonne pratique, à condition que quelqu’un le fasse réellement.

Dans tous ces cas, la désactivation doit être une décision assumée avec une procédure derrière, pas un oubli qui dure trois ans.

La condition indispensable : les sauvegardes

Activer les mises à jour automatiques sans sauvegarde automatique, c’est prendre un risque inutile.

L’équation qui fonctionne :

1. sauvegarde automatique quotidienne, stockée ailleurs que sur le serveur du site ;
2. mises à jour de sécurité automatiques ;
3. une alerte qui te prévient quand une mise à jour a eu lieu ;
4. un contrôle visuel rapide derrière.

Avec ça, le pire scénario est une restauration de quinze minutes. Sans ça, le pire scénario est une reconstruction.

Le cas des plugins

Le cœur de WordPress est plutôt bien tenu, et les correctifs arrivent vite. La majorité des piratages que nous voyons ne vient pas du cœur mais des extensions : plugins abandonnés, non mis à jour depuis des années, ou installés puis oubliés.

Un réflexe utile pendant que tu es dans ton administration : passe en revue ta liste de plugins et désinstalle ce qui ne sert plus. Un plugin désactivé mais toujours présent sur le serveur reste un fichier exécutable. Désactivé n’est pas supprimé.

Ce qu’il faut retenir

Le forçage des mises à jour pour la 7.0.2 a probablement évité beaucoup de dégâts. Mais il n’a protégé que les sites qui avaient laissé le mécanisme en place.

La question à te poser n’est pas « est-ce que mon site est à jour aujourd’hui », mais « qu’est-ce qui se passe la prochaine fois, si je ne fais rien ». Si la réponse est « rien ne se passe, personne ne regarde », tu connais déjà ton prochain chantier.