Mises à jour automatiques WordPress : lesquelles activer sans risque

Un site WordPress reçoit en moyenne entre 30 et 50 mises à jour par an si l’on additionne le cœur, les extensions et le thème. Laisser tout en automatique, c’est risquer un écran blanc un dimanche soir. Tout bloquer, c’est laisser des failles connues ouvertes pendant des semaines. La vraie question n’est pas « automatique ou manuel » mais plutôt : quelles mises à jour peut-on laisser passer seules, et lesquelles méritent une validation humaine ?

Comprendre les quatre types de mises à jour

WordPress ne traite pas toutes ses mises à jour de la même façon. Avant de décider ce que l’on automatise, il faut comprendre ce que l’on automatise. Le système distingue quatre catégories :

• Core minor (correctifs) : passage de 6.5.1 à 6.5.2. Ces versions corrigent des bugs et des failles de sécurité sans modifier de fonctionnalité. Elles sont numérotées sur le troisième chiffre.
• Core major (fonctionnalités) : passage de 6.5 à 6.6. Ces versions ajoutent ou modifient des fonctionnalités, changent parfois des API internes, et peuvent casser la compatibilité avec certaines extensions.
• Extensions : chaque plugin gère son propre rythme de publication. Certains sortent une mise à jour par semaine, d’autres tous les six mois.
• Thèmes : les mises à jour de thèmes sont généralement moins fréquentes, mais une mise à jour d’un thème parent peut écraser des personnalisations si aucun thème enfant n’est en place.

Chacune de ces catégories peut être gérée indépendamment : c’est là que réside toute la souplesse du système, et c’est ce qui permet de trouver le bon équilibre entre sécurité et stabilité.

Ce que WordPress active par défaut

Depuis WordPress 3.7 (octobre 2013), les mises à jour mineures du cœur sont automatiques par défaut. Concrètement, si votre site tourne en 6.5.1 et qu’un correctif 6.5.2 sort, WordPress l’installe tout seul, généralement la nuit, via le système WP-Cron.

Les mises à jour de fichiers de traduction sont également automatiques. En revanche, les mises à jour majeures du cœur, les extensions et les thèmes restent manuels par défaut. Depuis WordPress 5.5, l’interface d’administration propose un bouton pour activer l’auto-update extension par extension, mais il faut le faire explicitement.

Ce réglage par défaut est un compromis raisonnable : il couvre les correctifs de sécurité critiques sans toucher aux changements susceptibles de casser quelque chose. Selon la documentation officielle de sécurité WordPress, ce mécanisme a permis de patcher des millions de sites en quelques heures lors de failles critiques comme celle de l’API REST en janvier 2017.

Mises à jour mineures du cœur : le risque quasi nul

Les versions de maintenance (le troisième chiffre) sont les mises à jour les plus sûres de tout l’écosystème WordPress. Elles ne contiennent aucune nouvelle fonctionnalité, uniquement des corrections de bugs et des patchs de sécurité. L’équipe core de WordPress les teste sur une matrice de compatibilité qui couvre PHP 7.2 à 8.3 et MySQL 5.7 à 8.0.

En plus de dix ans de gestion de sites WordPress, je n’ai constaté qu’un seul cas où une mise à jour mineure a provoqué un problème : un conflit avec un plugin de cache très ancien qui modifiait des fichiers du cœur. C’est exactement le genre de situation qu’une bonne hygiène de maintenance aurait évitée en amont.

Désactiver les mises à jour mineures automatiques est une erreur. Le temps entre la publication d’un correctif de sécurité et l’exploitation de la faille par des bots peut se compter en heures. Si votre site attend que vous vous connectiez manuellement, il reste vulnérable pendant toute cette fenêtre. Le CERT-FR (centre gouvernemental de veille et d’alerte) publie régulièrement des avis concernant des vulnérabilités WordPress exploitées activement.

La seule raison légitime de désactiver ce comportement concerne les environnements de production très sensibles (e-commerce à fort trafic, sites institutionnels) où chaque modification passe par un processus de déploiement contrôlé avec un outil de versioning comme Git. Dans ce cas, la mise à jour est tout de même appliquée rapidement, mais via un pipeline.

Mises à jour majeures : pourquoi garder la main

Les versions majeures (6.5 → 6.6, par exemple) sont une autre histoire. Elles peuvent modifier le comportement de fonctions PHP internes à WordPress, ajouter de nouvelles tables dans la base de données, changer la structure de l’éditeur de blocs ou déprécier des fonctions utilisées par vos extensions.

Quelques exemples concrets de casse lors de mises à jour majeures :

• WordPress 5.0 a introduit Gutenberg : des dizaines de plugins d’édition sont devenus incompatibles du jour au lendemain
• WordPress 6.1 a modifié le comportement de wp_query sur certains types de requêtes, cassant des thèmes personnalisés qui reposaient sur un comportement non documenté
• WordPress 6.4 a renforcé le typage PHP, provoquant des erreurs fatales sur des extensions qui passaient des types incorrects sans que cela pose problème avant

Pour ces raisons, la mise à jour majeure doit suivre un processus en trois étapes :

1. Lire le changelog sur wordpress.org et vérifier les « breaking changes »
2. Tester sur un environnement de staging (la plupart des hébergeurs comme o2switch ou OVH proposent un outil de clonage)
3. Appliquer en production après validation, idéalement en dehors des heures de pointe

Ce processus prend entre 15 et 45 minutes selon la complexité du site. C’est un investissement minime comparé au temps nécessaire pour réparer un site cassé. Avant toute opération, assurez-vous d’avoir une sauvegarde récente et testée.

Extensions et thèmes : le vrai terrain miné

C’est sur les extensions que la question de l’auto-update devient la plus délicate. WordPress héberge plus de 60 000 extensions sur son répertoire officiel, avec des niveaux de qualité et de maintenance extrêmement variables.

Quand activer l’auto-update sur une extension

Avant d’activer la mise à jour automatique sur un plugin, je vérifie systématiquement quatre critères :

• Nombre d’installations actives : au-dessus de 200 000, l’extension est suffisamment utilisée pour que les régressions soient détectées rapidement par la communauté
• Fréquence des mises à jour : une extension mise à jour régulièrement (toutes les 2 à 6 semaines) indique une maintenance active. Une extension qui n’a pas bougé depuis 8 mois est soit stable, soit abandonnée
• Compatibilité déclarée : sur la page du plugin, la mention « compatible avec votre version de WordPress » doit être à jour
• Criticité pour le site : un plugin de formulaire de contact peut se casser sans bloquer le site. Un plugin de cache ou de sécurité qui plante peut rendre le site totalement inaccessible

Extensions à ne jamais mettre en auto-update

Certaines catégories d’extensions modifient le fonctionnement profond de WordPress et méritent toujours une validation manuelle :

• Plugins de cache (WP Super Cache, W3 Total Cache, WP Rocket) : ils modifient le fichier .htaccess et créent des fichiers statiques. Une mise à jour ratée peut rendre le site lent ou inaccessible
• Plugins de sécurité (Wordfence, Sucuri, iThemes Security) : ils interviennent sur les règles de pare-feu et les permissions. Un bug peut bloquer l’accès à l’administration
• Plugins e-commerce (WooCommerce et ses extensions) : les mises à jour majeures de WooCommerce modifient souvent la structure de la base de données. Sans test préalable, on risque de perdre des commandes ou de casser le tunnel d’achat
• Plugins de constructeur de page (Elementor, Divi, WPBakery) : ils stockent le contenu dans un format propriétaire. Une régression peut casser l’affichage de toutes les pages

Concernant les thèmes, la règle est simple : ne mettez jamais le thème actif en auto-update si vous avez fait la moindre personnalisation. Si vous utilisez un thème enfant correctement configuré, le risque diminue, mais il ne disparaît pas. Un changement dans les templates du thème parent peut modifier le rendu sans erreur PHP visible.

Pour les thèmes inactifs, la meilleure pratique reste de les supprimer purement et simplement. Un thème inactif représente du code inutile qui peut contenir des failles. WordPress recommande de garder un thème par défaut (Twenty Twenty-Five par exemple) comme solution de repli, et de supprimer tous les autres.

Configurer les auto-updates dans wp-config

WordPress offre plusieurs constantes et filtres pour contrôler finement le comportement des mises à jour automatiques. Tout se passe dans le fichier wp-config.php ou dans le fichier functions.php de votre thème enfant.

Les constantes essentielles

Pour désactiver toutes les mises à jour automatiques (déconseillé sauf cas spécifique) :

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Pour autoriser uniquement les mises à jour mineures du cœur (comportement par défaut, la configuration recommandée) :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Pour autoriser aussi les mises à jour majeures (à réserver aux sites non critiques avec sauvegarde quotidienne) :

define( 'WP_AUTO_UPDATE_CORE', true );

Pour tout bloquer, y compris les mineures :

define( 'WP_AUTO_UPDATE_CORE', false );

Les filtres pour un contrôle granulaire

Si vous avez besoin d’un contrôle plus fin, les filtres WordPress permettent de cibler des extensions spécifiques. Par exemple, pour activer l’auto-update uniquement sur certaines extensions de confiance :

add_filter( 'auto_update_plugin', function( $update, $item ) {
    $auto_update_plugins = array(
        'akismet/akismet.php',
        'redirection/redirection.php',
        'wordpress-seo/wp-seo.php',
    );
    if ( in_array( $item->plugin, $auto_update_plugins, true ) ) {
        return true;
    }
    return false;
}, 10, 2 );

Ce filtre, placé dans le functions.php du thème enfant ou dans un mu-plugin dédié, offre un contrôle total. Les extensions listées se mettent à jour seules ; toutes les autres restent manuelles.

Pour les thèmes, un filtre équivalent existe :

add_filter( 'auto_update_theme', '__return_false' );

Cette ligne désactive les mises à jour automatiques de tous les thèmes. C’est le réglage que j’applique sur la grande majorité des sites que je maintiens.

Si vous gérez votre site avec un versioning, pensez à versionner ces fichiers de configuration pour ne pas perdre vos réglages lors d’un changement de serveur ou d’une migration d’hébergeur.

La sauvegarde : condition préalable non négociable

Aucune stratégie de mise à jour automatique n’est viable sans un système de sauvegarde fiable et testé. Ce point est tellement fondamental que je le considère comme un prérequis absolu avant de toucher aux réglages d’auto-update.

Un site qui active les mises à jour automatiques sans sauvegarde, c’est comme rouler sans assurance : tout va bien jusqu’au jour où ça ne va plus. Et ce jour-là, le coût de la réparation dépasse largement celui de la prévention.

Voici ce que doit garantir votre dispositif de sauvegarde :

• Sauvegarde complète : fichiers ET base de données. L’un sans l’autre est inutile
• Fréquence adaptée : quotidienne pour un site actif, hebdomadaire minimum pour un site vitrine. J’en parle en détail dans mon guide sur la sauvegarde de site web
• Stockage externe : la sauvegarde ne doit pas être sur le même serveur que le site. Un disque distant, un bucket S3 ou un espace FTP séparé. Vérifiez que votre espace disque est suffisant pour conserver plusieurs versions
• Test de restauration : une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde, c’est un fichier
• Rétention suffisante : conservez au minimum 7 jours de sauvegardes. Si une mise à jour automatique casse quelque chose le lundi et que vous ne le remarquez que le vendredi, il faut pouvoir remonter assez loin

La plupart des hébergeurs de qualité proposent des sauvegardes automatiques incluses dans leur offre. C’est d’ailleurs l’un des critères importants dans le choix d’un hébergeur. Mais ne comptez pas uniquement sur la sauvegarde hébergeur : ajoutez une solution indépendante comme UpdraftPlus ou BlogVault pour avoir une double couche de protection.

Checklist pratique par profil de site

La bonne configuration dépend du type de site, de son niveau de criticité et du temps que vous pouvez consacrer à la maintenance. Voici mes recommandations selon trois profils courants.

Site vitrine / blog personnel

C’est le cas le plus simple. Le site ne génère pas de revenus directs, les données sont essentiellement du contenu éditorial, et une indisponibilité de quelques heures n’est pas catastrophique.

• Core minor : auto (défaut)
• Core major : auto possible si sauvegarde quotidienne en place
• Extensions : auto sur les plugins majeurs (Yoast, Akismet, etc.), manuel sur le reste
• Thème : manuel
• Vérification : une fois par semaine

Site professionnel / PME

Le site représente l’entreprise. Une page blanche ou un défacement aurait un impact sur l’image et potentiellement sur le chiffre d’affaires.

• Core minor : auto
• Core major : manuel avec staging
• Extensions : auto sélectif via le filtre PHP (uniquement les plugins de confiance non critiques)
• Thème : manuel
• Vérification : deux fois par semaine minimum
• Notification par email : activée pour être prévenu de chaque mise à jour automatique

Site e-commerce / application métier

Chaque minute d’indisponibilité coûte de l’argent. Les données clients sont sensibles et soumises au RGPD selon la CNIL.

• Core minor : auto (les correctifs de sécurité restent prioritaires même ici)
• Core major : manuel avec staging complet et tests fonctionnels
• Extensions : tout en manuel, avec un calendrier de maintenance bimensuel
• Thème : manuel
• Vérification : quotidienne
• Monitoring : un outil de surveillance d’uptime qui alerte en cas de panne

Dans tous les cas, maintenez votre version de PHP à jour. Une version de PHP obsolète est souvent plus dangereuse qu’une extension en retard d’une version. PHP 8.1 ou supérieur est recommandé en 2026.

Pensez également à nettoyer régulièrement votre base de données : les révisions et transients accumulés peuvent ralentir les processus de mise à jour et augmenter le risque d’échec lors de migrations de schéma.

Enfin, si votre site a déjà été compromis par le passé, consultez mon guide de remédiation après piratage : les mises à jour seules ne suffisent pas à sécuriser un site dont les accès ont été volés.