Chaos dans les tâches planifiées : Pourquoi WP-Cron casse votre site (et comment le remplacer par un vrai Cron)

Vous avez programmé un article pour 9h. Vous revenez à midi, et il est toujours en statut « Programmé ». Votre sauvegarde hebdomadaire par email n’est jamais arrivée. La file d’attente de la newsletter est bloquée. Vos données d’analyse ont plusieurs jours de retard. Le coupable est presque certainement le même : le système de planification intégré de WordPress, WP-Cron.

Le problème n’est pas que WP-Cron soit une mauvaise idée. Le problème est que c’est un pseudo-cron, pas un vrai. Il repose sur la visite de quelqu’un sur votre site pour déclencher les tâches planifiées . Si votre site est calme, les tâches ne s’exécutent tout simplement pas.

La racine du chaos : un faux Cron

WordPress utilise le fichier wp-cron.php pour gérer les tâches programmées. À chaque chargement de page, WordPress vérifie si des tâches sont dues et les exécute. Cette approche est astucieuse pour les hébergements mutualisés qui n’autorisent pas les vrais cron, mais elle comporte des inconvénients majeurs .

  • Sites à faible trafic : Si personne ne visite votre site, le cron ne se déclenche jamais .
  • Conflits avec le cache : Les plugins de cache servent des fichiers HTML statiques, qui contournent complètement PHP. Si votre cache est actif, WP-Cron peut ne jamais être déclenché, laissant les tâches planifiées en attente indéfiniment .
  • Problèmes de performance : Sur les sites à fort trafic, vérifier la file d’attente du cron à chaque chargement de page gaspille des ressources serveur et peut ralentir les temps de réponse .

Les symptômes du chaos : des planifications manquées et des événements bloqués

Lorsque WP-Cron échoue, les symptômes sont généralement évidents : des articles programmés qui ne sont jamais publiés (l’erreur classique « Missed Schedule »), des mises à jour de plugins qui ne se font pas, des emails automatisés qui ne sont jamais envoyés, et des processus en arrière-plan qui s’arrêtent simplement .

Diagnostiquer le problème

Avant d’appliquer une solution, vous devez confirmer la cause.

  1. Vérifier le statut de WP-Cron : Rendez-vous dans Outils > Santé du site dans votre administration WordPress. Recherchez les avertissements concernant les événements planifiés ou les requêtes de bouclage (loopback) .
  2. Vérifier le drapeau de désactivation : Ouvrez votre fichier wp-config.php et recherchez define('DISABLE_WP_CRON', true);. Si cette ligne existe, WP-Cron est manuellement désactivé .
  3. Tester le point d’accès Cron : Ouvrez votre navigateur et visitez https://votresite.com/wp-cron.php?doing_wp_cron. Une page blanche signifie que WP-Cron est accessible. Une erreur 403 ou une erreur de connexion signifie que quelque chose le bloque .

La solution : Remplacer WP-Cron par un vrai Cron

La seule solution fiable à long terme est de désactiver le WP-Cron par défaut et de configurer un vrai cron côté serveur . Cela supprime la dépendance au trafic du site.

Étape 1 : Désactiver WP-Cron dans WordPress

  1. Connectez-vous à votre serveur via FTP ou le gestionnaire de fichiers de votre hébergement.
  2. Ouvrez le fichier wp-config.php situé à la racine de votre WordPress.
  3. Ajoutez la ligne suivante juste avant la ligne /* C'est tout, ne modifiez plus ! */ :
    define('DISABLE_WP_CRON', true);
  4. Enregistrez le fichier .

Étape 2 : Créer la tâche cron côté serveur

Cette étape nécessite un accès à votre panneau de contrôle d’hébergement (cPanel, Plesk, etc.) ou à la ligne de commande.

**Option A : Utiliser cPanel (le plus courant) **

  1. Connectez-vous à cPanel et trouvez la section « Cron Jobs » sous « Avancé ».
  2. Sous « Ajouter une nouvelle tâche cron », définissez l’intervalle. Pour la plupart des sites, toutes les 15 minutes est suffisant. Pour les sites à fort trafic ou sensibles au temps, toutes les 5 minutes est préférable .
  3. Dans le champ « Commande », entrez ce qui suit, en remplaçant votresite.com par votre URL réelle :
    wget -q -O - http://votresite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
  4. Cliquez sur « Ajouter une nouvelle tâche cron » .

Option B : Utiliser WP-CLI (ligne de commande)

Pour les développeurs avec un accès SSH, cette méthode est plus propre et ne dépend pas des requêtes HTTP :
* * * * * cd /var/www/votre_site/htdocs; /usr/local/bin/wp cron event run --due-now > /dev/null 2>&1

Cette commande utilise WP-CLI pour exécuter les tâches dues, ce qui peut offrir de meilleurs rapports d’erreurs et ne dépend pas des configurations du serveur web .

**Option C : Utiliser PHP-CLI **
*/5 * * * * cd /var/www/votre_site/htdocs; php /var/www/votre_site/htdocs/wp-cron.php > /dev/null 2>&1
Cette méthode utilise PHP pour exécuter le script cron directement sans effectuer de requête HTTP.

Débogage avancé avec WP-CLI

Si les tâches sont toujours bloquées, la ligne de commande est votre meilleur outil de diagnostic.

  • Lister tous les événements Cron : wp cron event list — Cela vous montre ce qui est dans la file d’attente, quand ils sont programmés, et si certains sont bloqués (next_run_relative affichera « now » ou « 1 hour ago ») .
  • Exécuter un crochet spécifique : wp cron event run <nom_du_crochet> — Cela force l’exécution d’un événement spécifique et affiche les éventuelles erreurs PHP directement dans votre terminal .
  • Exécuter tous les événements dus : wp cron event run --due-now — Cela vide le backlog de toutes les tâches en retard en une seule fois .

En résumé

Se fier à WP-Cron est un pari sur la fiabilité de votre site. Pour tout site où les tâches planifiées sont critiques, le remplacer par un vrai cron n’est pas facultatif. C’est une configuration fondamentale qui garantit que votre site fonctionne comme vous l’attendez, que vous ayez dix visiteurs ou dix mille.

Ce billet vous a été utile?
Offrez-nous un café!
Tags: