WordPress range des tâches à une heure donnée : publication programmée, e-mails, sauvegardes, files d’attente d’extensions. Par défaut, le déclencheur n’est pas l’horloge du serveur. C’est WP-Cron : à l’occasion d’une visite, WordPress regarde si une tâche est due et, si oui, lance un appel vers wp-cron.php. Sans visite, la tâche attend. Avec un hébergement qui bloque l’appel du site vers lui-même, elle attend aussi, même si le site a du trafic.
La home peut répondre 200 pendant que plus aucune sauvegarde ne part. Il faut un contrôle spécifique, pas seulement une sonde de disponibilité.
Pourquoi les tâches ne partent pas
| Situation | Effet |
|---|---|
| Peu de visites | Les tâches dues attendent la prochaine page vue, parfois des heures |
| Le site ne peut pas s’appeler lui-même | WP-Cron croit déclencher, l’appel interne échoue |
DISABLE_WP_CRON à true sans cron système | Plus rien ne lance les tâches |
| Une tâche en erreur bloque la file | Les suivantes restent dues |
| Action Scheduler (WooCommerce et autres) saturé | La file grandit, les actions métier ne sortent pas |
Le cron système corrige le premier point. On pose DISABLE_WP_CRON à true dans wp-config.php pour que les visites ne lancent plus le pseudo-cron, puis on appelle https://exemple.fr/wp-cron.php depuis le planificateur du serveur, ou wp cron event run --due-now en ligne de commande, toutes les cinq à quinze minutes. L’intervalle doit être plus court que la précision dont vous avez besoin : une publication « à la minute » ne tient pas avec un appel toutes les heures.
Cet appel système est l’exécution. Il n’est pas la preuve que les tâches réussissent. Une erreur dans une extension laisse l’appel HTTP en 200 et la tâche en échec.
Un battement de cœur lisible de l’extérieur
Choisissez une tâche réelle dont l’absence se voit, ou ajoutez-en une petite qui écrit l’heure dans une option ou un fichier servi par une URL protégée par un secret. La sonde externe lit cette heure. Si elle a plus de deux intervalles de retard, le cron ne fait plus son travail, même si le site répond.
N’utilisez pas la sonde de disponibilité pour déclencher wp-cron.php à chaque test. Vous colleriez l’exécution au rythme de la sonde, y compris en cas de rafale, et vous ne sauriez plus si un vrai planificateur existe. La sonde lit. Le cron système exécute.
Exemples de signaux déjà présents, sans développement :
- la date de la dernière sauvegarde, si le plugin l’affiche sur une URL ou l’envoie quelque part que vous pouvez lire ;
- un article de test programmé chaque jour, dont la publication manquante saute aux yeux (bruyant, à réserver au diagnostic) ;
- la longueur de la file Action Scheduler, visible dans l’admin WooCommerce : utile à la main, moins simple à sonder.
Pour une PME, le battement de cœur sur une URL de contrôle est le plus clair. Gardez cette URL hors du sitemap et hors des liens publics. Un secret dans l’adresse ou un en-tête suffit à éviter qu’elle devienne une page ouverte. Le contrôle externe, du type monitoring SiteGarde, appelle cette URL comme n’importe quelle autre et alerte si le contenu n’a pas la fraîcheur attendue.
Que faire quand l’heure ne bouge plus
- Regardez si le cron système est encore planifié (crontab, tâche hébergeur). Un changement d’offre d’hébergement efface parfois ces tâches.
- Appelez une fois
wp cron event listou utilisez une extension du type WP Crontrol : repérez les événements « en retard » depuis longtemps. - Vérifiez que le site peut joindre
wp-cron.phpsi vous n’avez pas désactivé WP-Cron : pare-feu, basique authentification sur la préproduction, ou boucle HTTPS cassée. - Lisez l’erreur PHP de la tâche qui échoue. La relancer en boucle sans la corriger ne fait que remplir le journal.
- Si vous dépendez des sauvegardes planifiées, partez du principe qu’elles n’ont pas eu lieu tant que la dernière archive n’est pas datée d’aujourd’hui. Le principe de copie avant coup dur est rappelé dans la sauvegarde avant incident.
Les logs du serveur montrent les appels à wp-cron.php : absents, ils confirment que le planificateur ne tape plus. Présents avec des 500, ils confirment que l’appel a lieu et que le travail casse. Les logs serveur servent à départager ces deux cas. Une fois la cause corrigée, l’heure du battement de cœur doit avancer au prochain passage, sans qu’on ait à recharger le site à la main.