Sur un parc de trente sites clients gérés en interne, la boîte mail générique de l’agence recevait chaque semaine des dizaines de courriels « Votre site a été mis à jour automatiquement » et « Réussite de la mise à jour automatique du plugin X ». Utile au départ pour surveiller les mises à jour automatiques activées depuis WordPress 5.5, ce flux était devenu du bruit pur : personne ne les lisait plus, au risque de manquer un vrai courriel d’échec de mise à jour, celui qui compte vraiment.
Deux filtres distincts, l’un pour le cœur de WordPress, l’autre pour les extensions, permettent d’ajuster précisément ce qui mérite un courriel.
Le filtre pour le cœur de WordPress
Le filtre auto_core_update_send_email reçoit un booléen, le type de résultat (success, fail, manual, critical) et l’objet décrivant la mise à jour :
add_filter( 'auto_core_update_send_email', function ( $envoyer, $type, $core_update, $result ) {
// Garder les alertes critiques et les échecs, couper les confirmations de routine
if ( 'success' === $type ) {
return false;
}
return $envoyer;
}, 10, 4 );Le filtre pour les extensions et thèmes
Le comportement des extensions suit un filtre distinct, auto_plugin_update_send_email (et son équivalent auto_theme_update_send_email pour les thèmes), qui reçoit le tableau des résultats de chaque extension mise à jour automatiquement :
add_filter( 'auto_plugin_update_send_email', function ( $envoyer, $resultats ) {
foreach ( $resultats as $resultat ) {
if ( ! $resultat->result ) {
return true; // Au moins un échec : on envoie quand même
}
}
return false; // Tout s'est bien passé, pas besoin de courriel
}, 10, 2 );Rediriger plutôt que supprimer
Couper totalement ces courriels prive l’équipe d’un signal en cas de problème réel. Une approche plus prudente consiste à rediriger ces notifications vers une adresse dédiée à la supervision technique plutôt que la boîte générique de contact, via le filtre auto_core_update_email qui permet de modifier les destinataires du message :
add_filter( 'auto_core_update_email', function ( $email, $type, $core_update, $result ) {
$email['to'] = 'supervision-technique@mon-agence.fr';
return $email;
}, 10, 4 );Regrouper plutôt que traiter courriel par courriel
Sur un parc géré via un outil de supervision centralisé (Jetpack, ManageWP, MainWP ou une solution maison), il est souvent plus pertinent de couper entièrement les courriels natifs de WordPress et de laisser l’outil de supervision remonter les échecs de mise à jour dans un tableau de bord unique, plutôt que de garder deux canaux d’alerte en parallèle qui finissent par se contredire.
- Vérifier que l’outil de supervision central couvre bien les échecs de mise à jour avant de couper les courriels natifs.
- Garder une trace en base de données des mises à jour automatiques via le hook
automatic_updates_complete, même sans envoi de courriel. - Documenter le choix retenu pour l’équipe qui reprendra le site plus tard, sous peine de croire qu’aucune alerte n’est configurée.
add_action( 'automatic_updates_complete', function ( $resultats ) {
error_log( 'Mises à jour automatiques : ' . wp_json_encode( $resultats ) );
} );Couper un courriel de routine sans réfléchir à ce qui doit continuer à alerter, c’est le meilleur moyen de manquer la seule notification qui comptait vraiment.
Ce que ces filtres ne changent pas
Ces réglages n’activent ni ne désactivent les mises à jour automatiques elles-mêmes, pilotées par d’autres constantes et filtres comme WP_AUTO_UPDATE_CORE ou auto_update_plugin. Ils n’agissent que sur la notification par courriel, une fois la mise à jour déjà effectuée.
En résumé
Deux filtres bien choisis, associés à une redirection des courriels vers la bonne adresse, transforment un flux de notifications ignoré en un signal utile. La règle que je retiens sur mes projets : garder tout ce qui signale un échec, filtrer tout ce qui confirme une réussite de routine.
