WP-Cron WordPress : fiabiliser les tâches planifiées sans surcharger le site

WP-Cron WordPress orchestre les publications programmées, les sauvegardes, les e-mails différés, les nettoyages et de nombreuses tâches d’extensions. Il rend ces fonctions accessibles sur presque tous les hébergements, mais il ne fonctionne pas comme un cron système exécuté en continu : WordPress vérifie les événements arrivés à échéance lorsqu’une page se charge.

Sur un site peu visité, une tâche prévue à 02 h peut donc attendre la prochaine visite. Sur un site très fréquenté, les vérifications répétées peuvent au contraire ajouter une charge inutile. La bonne réponse n’est pas de désactiver WP-Cron au hasard, mais de mesurer, sécuriser le relais serveur et contrôler les événements importants.

Ce que WP-Cron fait réellement

WordPress stocke une file d’événements avec un hook, une prochaine date et parfois une récurrence. Lorsqu’une requête arrive, le système vérifie si un événement doit être déclenché. Cette logique convient à de nombreux sites et garantit qu’une tâche manquée pourra être reprise à la prochaine occasion.

Elle ne garantit toutefois pas une exécution à la minute près. Un faible trafic, un cache mal réglé, un appel HTTP interne bloqué ou une tâche très longue peuvent retarder la file.

Reconnaître un problème de tâches planifiées

• des articles restent marqués « publication manquée » ;
• les sauvegardes ou exports ne démarrent plus à l’heure prévue ;
• les e-mails différés partent par vagues ;
• une extension affiche des événements en retard ;
• des appels répétés à wp-cron.php apparaissent dans les journaux ;
• le site ralentit pendant l’exécution de traitements lourds.

Un retard isolé ne suffit pas à conclure. Relevez l’heure prévue, l’heure réelle, le hook concerné et la durée d’exécution sur plusieurs occurrences.

Étape 1 : inventorier avant de modifier

Listez les événements avec un outil d’administration fiable ou WP-CLI. La commande officielle wp cron event list aide à repérer les hooks en retard, les récurrences anormalement courtes et les tâches sans propriétaire identifiable. La commande wp cron test vérifie notamment si WordPress peut déclencher le système par HTTP.

Les quatre questions à poser

1. Quelle extension ou fonction a créé le hook ?
2. Quelle fréquence est réellement nécessaire ?
3. Que se passe-t-il si l’exécution échoue ou se répète ?
4. Où trouver une preuve de réussite : journal, fichier, e-mail ou statut ?

Ne supprimez jamais un événement inconnu avant d’avoir identifié son origine. L’extension pourrait le recréer ou dépendre de ses arguments.

Étape 2 : décider si un cron serveur est utile

Le remplacement du déclenchement par visite est pertinent lorsque l’horaire compte, que le trafic est irrégulier ou que le site lance des traitements lourds. Il n’est pas obligatoire pour tous les sites : la documentation WordPress précise que WP-Cron est conçu pour limiter sa consommation et qu’un remplacement n’est utile que si le contexte le justifie.

Pour un site vitrine actif, un déclenchement serveur toutes les 10 à 15 minutes est souvent suffisant. Une boutique, un système de réservation ou une plateforme éditoriale peut demander un intervalle différent, fondé sur ses obligations métier.

Étape 3 : installer le relais sans créer de trou

La séquence sûre comporte deux actions coordonnées :

1. créer une tâche système qui appelle régulièrement le mécanisme WordPress ;
2. seulement après un test concluant, définir DISABLE_WP_CRON à true dans wp-config.php pour éviter le déclenchement à chaque visite.

WordPress documente l’appel de wp-cron.php par le planificateur du système. Sur un serveur administré, WP-CLI peut aussi offrir un contrôle plus direct. Le choix dépend de l’hébergement, des droits et de la supervision disponible.

Attention : désactiver WP-Cron avant d’avoir validé le relais arrête les tâches planifiées. Conservez la configuration précédente et prévoyez un retour arrière immédiat.

Étape 4 : tester les cas qui comptent

• programmez un brouillon de test quelques minutes à l’avance ;
• déclenchez une tâche non critique et contrôlez son journal ;
• vérifiez qu’un second passage ne produit pas de doublon ;
• simulez une erreur temporaire et observez la reprise ;
• mesurez la durée totale et l’impact sur CPU, mémoire et base de données.

Une tâche robuste doit être idempotente : si elle est relancée, elle ne doit pas envoyer deux factures, créer deux commandes ou publier deux fois le même contenu.

Le tableau de surveillance minimal

Pour chaque événement critique, consignez le hook, l’extension responsable, la fréquence, la dernière réussite, la durée, le dernier message d’erreur et le contact responsable. Ajoutez une alerte si le retard dépasse un seuil métier plutôt que d’alerter sur chaque variation de quelques secondes.

Les erreurs fréquentes à éviter

• installer plusieurs déclencheurs serveur pour le même site ;
• choisir une fréquence d’une minute sans besoin mesuré ;
• modifier wp-config.php sans sauvegarde ni retour arrière ;
• confondre un hook en retard avec une panne globale ;
• laisser une tâche lourde bloquer toutes les suivantes ;
• supprimer des événements au lieu de corriger l’extension qui les crée.

Plan d’action en 30 minutes

1. 10 minutes : lister les événements et isoler ceux qui sont en retard.
2. 5 minutes : associer chaque hook critique à une fonction métier.
3. 10 minutes : tester le déclenchement et relever les erreurs HTTP.
4. 5 minutes : décider de conserver WP-Cron ou de préparer un relais serveur testé.

Questions fréquentes

Un cron serveur remplace-t-il les événements WordPress ?

Non. Il remplace surtout le mécanisme qui réveille la file. Les hooks et leurs horaires restent gérés par WordPress et les extensions.

Faut-il désactiver WP-Cron sur tous les sites ?

Non. Faites-le seulement si un relais fiable existe et si la ponctualité ou la charge justifie le changement. Sur un petit site sans contrainte horaire, le fonctionnement natif peut suffire.

Sources officielles

• WordPress Developer Resources — Cron et fonctionnement de WP-Cron
• WordPress Developer Resources — Relier WP-Cron au planificateur système
• WordPress Developer Resources — Commandes WP-CLI pour les événements cron

Conseil DigiSense : commencez par mesurer les retards et identifier les hooks critiques. Le bon objectif n’est pas un cron « plus technique », mais des tâches traçables, ponctuelles et récupérables.