Un client medias me signale un mardi matin qu’un article programmé pour 8h00 affiche toujours le statut « Programmation manquée » à 9h30. Rien dans les logs applicatifs, aucune erreur PHP visible, et pourtant l’article reste bloqué en attente. Ce symptôme revient régulièrement sur les sites à faible trafic nocturne ou matinal, et la cause n’est presque jamais celle qu’on imagine en premier.
Ce statut « Programmation manquée » (missed schedule) n’a rien d’un bug aléatoire : il traduit un mécanisme précis, celui du planificateur de tâches de WordPress, qui dépend entièrement des visites reçues par le site. Voici comment diagnostiquer la cause exacte, sans réexpliquer le fonctionnement général de wp-cron.
Diagnostic : trafic insuffisant au moment prévu
La cause la plus fréquente est aussi la plus simple : wp-cron n’est pas un vrai planificateur système, il se déclenche à chaque chargement de page front-end via une requête vers wp-cron.php. Si aucune visite n’a lieu entre l’heure de programmation et la marge de tolérance de WordPress, la tâche check_and_publish_future_post ne s’exécute simplement pas.
Pour vérifier cette hypothèse, on consulte les statistiques de trafic sur la tranche horaire concernée. Sur un site B2B avec un trafic quasi nul entre 2h et 7h du matin, une programmation à 5h00 aura statistiquement peu de chances de se déclencher à l’heure.
Diagnostic : DISABLE_WP_CRON activé sans remplacement
Deuxième cause très fréquente en environnement mutualisé ou VPS optimisé : la constante DISABLE_WP_CRON a été définie à true dans wp-config.php pour éviter que chaque visite ne déclenche un appel HTTP interne coûteux, sans qu’une vraie tâche cron système n’ait été configurée en remplacement.
grep -n "DISABLE_WP_CRON" wp-config.phpSi cette ligne existe et vaut true, il faut vérifier immédiatement qu’une tâche cron système appelle bien wp-cron.php à intervalle régulier — via crontab, ou plus proprement via wp cron event run --due-now en ligne de commande.
crontab -l | grep wp-cronL’absence totale de résultat à cette commande, combinée à DISABLE_WP_CRON activé, confirme le diagnostic : aucune tâche planifiée ne s’exécute plus jamais, qu’il s’agisse d’une publication différée ou de n’importe quelle autre tâche cron d’extension.
Diagnostic : un cache de page masque les visites
Sur les sites équipés d’un cache de page agressif (cache serveur type Varnish, ou cache statique généré par une extension), les visites peuvent être servies directement par le serveur web ou par un fichier statique, sans jamais réellement charger WordPress ni déclencher wp-cron.php. Le site semble recevoir du trafic, mais ce trafic ne touche jamais le cœur applicatif.
Pour confirmer cette piste, on consulte les journaux du cache (durée de vie, taux de succès) et on compare avec les journaux applicatifs PHP : un fort écart entre les deux est un signal net.
Diagnostic : un décalage de fuseau horaire
Plus rarement, le réglage Réglages > Général > Fuseau horaire ne correspond pas au fuseau attendu par le rédacteur, ou une migration de serveur a changé le fuseau système sans que le réglage WordPress ne soit mis à jour en conséquence. L’article semble « manqué » alors qu’il est en réalité programmé pour une heure différente de celle que croit le rédacteur.
Correctif immédiat : publier ou reprogrammer
Pour débloquer l’article immédiatement, deux options : le republier manuellement depuis l’écran d’édition (le statut repasse à « Publié » sans attendre le cron), ou déclencher manuellement l’exécution des tâches en attente.
wp cron event run --due-nowCette commande force l’exécution de toutes les tâches arrivées à échéance, y compris check_and_publish_future_post, sans attendre une visite front-end.
Prévention : un vrai cron système
La prévention durable consiste à désactiver le déclenchement via visite et à le remplacer systématiquement par une tâche cron système, seule solution fiable sur un site à trafic irrégulier.
define( 'DISABLE_WP_CRON', true );# Toutes les 5 minutes, via crontab système
*/5 * * * * wp cron event run --due-now --path=/var/www/exemple.fr > /dev/null 2>&1Sur chaque nouveau projet à trafic incertain, je configure ce cron système dès la mise en production, avant même que le client ne programme son premier article : c’est nettement moins coûteux qu’un diagnostic en urgence un lundi matin.
En résumé
Une « Programmation manquée » a presque toujours l’une de ces quatre origines : absence de visite au bon moment, DISABLE_WP_CRON activé sans relais, cache masquant le trafic réel, ou décalage de fuseau horaire. Un vrai cron système reste la seule prévention fiable, quel que soit le trafic du site.
