La question n’est plus vraiment « faut-il mettre à jour WordPress », mais « faut-il le faire automatiquement, et jusqu’où ». Les mises à jour corrigent des failles de sécurité, souvent avant même qu’elles ne soient exploitées massivement, mais elles introduisent aussi, parfois, des régressions qui cassent un site en production sans prévenir. Trouver le bon curseur entre ces deux risques dépend du type de site, de sa criticité, et de la discipline de maintenance réellement appliquée derrière.
WordPress distingue plusieurs niveaux de mise à jour automatique : le cœur, les extensions, les thèmes, et les traductions, chacun pilotable indépendamment via des constantes et des filtres. Comprendre ces leviers permet de construire une politique de mise à jour adaptée plutôt que de tout activer ou tout désactiver par défaut.
Le cœur : automatique depuis longtemps, avec des nuances
Depuis WordPress 3.7, les mises à jour mineures du cœur, celles qui corrigent des failles de sécurité et des bogues sans changer de fonctionnalités, sont appliquées automatiquement par défaut, sans intervention. Les mises à jour majeures, elles, restent manuelles sauf configuration explicite, via la constante WP_AUTO_UPDATE_CORE.
// Dans wp-config.php
// Comportement par défaut : mises à jour mineures uniquement
// define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// Tout automatiser, y compris les versions majeures
define( 'WP_AUTO_UPDATE_CORE', true );
// Tout désactiver, y compris les mises à jour de sécurité mineures
// define( 'WP_AUTO_UPDATE_CORE', false );Désactiver totalement les mises à jour automatiques du cœur, y compris les mineures, n’est justifiable que sur un projet avec une équipe capable de suivre les annonces de sécurité en temps réel et d’appliquer les correctifs en quelques heures. Sur tout autre projet, c’est prendre un risque inutile pour un gain de contrôle rarement exploité.
Extensions et thèmes : un arbitrage plus fin
Depuis WordPress 5.5, l’administration propose une bascule pour activer les mises à jour automatiques extension par extension et thème par thème, directement depuis l’écran des extensions. Ce réglage peut aussi se piloter par code, ce qui est préférable dès qu’on gère plusieurs sites, pour éviter une configuration incohérente entre eux.
add_filter( 'auto_update_plugin', function ( $update, $item ) {
$extensions_critiques = array( 'wordfence', 'wpforms-lite' );
if ( in_array( $item->slug, $extensions_critiques, true ) ) {
return true;
}
return $update;
}, 10, 2 );Cette approche permet de traiter différemment une extension de sécurité, dont on souhaite le correctif le plus vite possible, et une extension métier complexe, où une régression aurait un impact commercial direct et où l’on préfère valider la mise à jour manuellement avant déploiement.
Automatiser en ligne de commande
Sur un parc de sites gérés en direct, WP-CLI permet de scripter les mises à jour plutôt que de dépendre uniquement du cron interne de WordPress, ce qui offre un contrôle plus fin sur le moment d’exécution.
wp plugin update --all
wp theme update --all
wp core updateLe vrai danger : l’absence totale de test
Une mise à jour automatique n’est risquée que si rien ne vérifie ensuite que le site fonctionne toujours. Le vrai problème n’est donc pas l’automatisation elle-même, mais l’absence de filet de sécurité derrière : pas de sauvegarde récente, pas d’environnement de staging, pas de surveillance qui détecterait une page blanche ou une erreur fatale après coup.
- Sauvegarder automatiquement avant chaque mise à jour, fichiers et base de données
- Tester en environnement de staging les mises à jour majeures ou celles d’extensions complexes
- Surveiller la disponibilité du site après chaque exécution automatique, via un simple contrôle HTTP planifié
Construire une politique adaptée au projet
Un site vitrine simple, avec peu d’extensions et un thème standard, tolère généralement une automatisation large : le risque de régression est faible et le bénéfice sécurité l’emporte largement. Un site e-commerce complexe, avec des extensions de paiement et de logistique interdépendantes, mérite une politique plus prudente, avec des mises à jour de sécurité critiques automatisées et le reste validé en staging avant déploiement.
| Type de site | Cœur | Extensions |
|---|---|---|
| Vitrine simple | Automatique complet | Automatique large |
| E-commerce critique | Mineures automatiques | Sécurité auto, reste en staging |
Sur mes projets, je n’active jamais la mise à jour automatique complète d’une extension de paiement sans staging derrière. Le gain de sécurité ne vaut pas le risque d’une page de commande cassée un samedi de soldes.
En résumé
Les mises à jour automatiques ne sont ni un danger systématique ni une solution miracle : elles réduisent le délai d’exposition à une faille connue, au prix d’un risque de régression qu’un vrai processus de sauvegarde et de test permet de maîtriser. Le filtre auto_update_plugin et WP-CLI donnent le contrôle nécessaire pour construire une politique différenciée, plutôt qu’un tout ou rien appliqué sans réflexion à l’ensemble d’un parc de sites.
