Réserver

WP-Cron ou cron système : fiabiliser les tâches planifiées de WordPress

par Francis Rozange | Oct 2, 2026 | Performance

A glass clockwork with no hands, its gears turning only when a beam passes

WordPress n’a pas d’horloge. Quand un article est programmé pour 14 heures, aucun processus n’attend 14 heures pour le publier. WordPress vérifie, à chaque visite, si une tâche est due. Si personne ne visite le site avant 17 heures, l’article attend 17 heures : c’est l’exemple que donne la documentation officielle, ici appliqué à un article.

Ce mécanisme, WP-Cron, porte bien plus que les articles programmés : les vérifications de mises à jour, les mises à jour automatiques, le nettoyage de la corbeille et des transients, les sauvegardes de nombreux plugins, les renouvellements d’abonnements d’une boutique. Depuis WordPress 7.1, il porte aussi le nettoyage quotidien des demandes de données personnelles.

Ce guide explique comment WP-Cron se déclenche vraiment, pourquoi il rate sur les petits sites et pèse sur les gros, comment le remplacer par un vrai cron système, comment s’articule la file d’attente de WooCommerce, et comment déboguer et surveiller les tâches planifiées.

Comment WP-Cron se déclenche vraiment

Une vérification à chaque requête, un verrou contre les doublons

À chaque requête qui atteint PHP, WordPress consulte la liste des tâches planifiées, rangée dans une seule option de la base, chargée automatiquement. Si une tâche est due, il lance l’exécution, mais un verrou, réglé par la constante WP_CRON_LOCK_TIMEOUT à soixante secondes par défaut, empêche un nouveau lancement tant que le précédent tourne, dans la limite de ces soixante secondes.

La requête de bouclage vers wp-cron.php

Pour ne pas faire attendre le visiteur, WordPress n’exécute pas les tâches dans sa requête. Il envoie une requête HTTP à son propre fichier wp-cron.php, avec un délai d’attente de 0,01 seconde et en mode non bloquant, puis continue d’afficher la page. C’est ce second processus qui exécute les tâches dues.

Ce bouclage suppose que le serveur puisse s’appeler lui-même. Un pare-feu, une authentification HTTP de base, un problème de DNS ou de certificat suffisent à le bloquer, et les tâches ne partent plus.

Ce qui dépend de WP-Cron

Le cœur de WordPress planifie lui-même une série de tâches : la vérification des mises à jour du cœur, des plugins et des thèmes deux fois par jour, la suppression quotidienne des transients expirés, des brouillons automatiques anciens et de la corbeille, le contrôle hebdomadaire de la Santé du site, et depuis WordPress 7.1 le nettoyage quotidien des demandes de données personnelles. Les mises à jour automatiques en dépendent directement.

À cela s’ajoutent les tâches des plugins : sauvegardes, envois de courriels, synchronisations, nettoyages. Un WP-Cron qui ne tourne plus, c’est donc un site qui ne se met plus à jour, ne se sauvegarde plus et ne se nettoie plus, sans message d’erreur visible.

Ce que change le cache de pages

Une page servie par un cache de pages ou un CDN n’atteint jamais PHP, donc jamais WP-Cron. Un site très bien mis en cache peut ainsi recevoir des milliers de visites sans qu’aucune ne déclenche les tâches planifiées.

Le cas réel : la requête « non bloquante » qui bloquait

L’histoire du déplacement de WP-Cron dans WordPress 6.9, à l’automne 2025, montre ce que coûte le déclenchement par les visites. Elle est documentée par les commits du cœur, une note de l’équipe performance et un ticket de la bibliothèque HTTP de WordPress.

Un délai de 0,01 seconde qui durait une seconde

La requête de bouclage est censée ne jamais faire attendre le visiteur. En août 2023, un développeur signale pourtant, sur le dépôt de la bibliothèque Requests utilisée par WordPress pour ses appels HTTP, que le mode non bloquant ne fonctionne pas toujours : son script restait suspendu jusqu’à la réponse. En octobre 2026, ce ticket est toujours ouvert.

Le code du cœur le reconnaît aujourd’hui dans ses commentaires : la fonction d’envoi ne respecte pas toujours les paramètres de délai et de blocage, et un délai de 0,01 seconde peut finir par prendre une seconde. Tant que le lancement avait lieu avant l’envoi de la page, ce délai retardait le premier octet reçu par le visiteur.

Le déplacement

Le 12 octobre 2025, Peter Wilson, l’un des committers du cœur, intègre le changement préparé par Weston Ruter : le lancement de WP-Cron passe à la toute fin de la requête, une fois la page envoyée. Le message du commit résume le problème : la requête de bouclage devait être non bloquante, mais ne l’était pas toujours, et augmentait le temps de réponse.

Le 18 novembre, Weston Ruter, de l’équipe performance, présente le changement dans le guide de WordPress 6.9 : une réduction possible d’une seconde du temps du premier octet, pour les requêtes qui lancent WP-Cron. Nous n’avons trouvé aucune mesure indépendante de ce gain.

Une régression avant la sortie

Le déplacement a cassé une configuration particulière : les sites qui utilisent la constante ALTERNATE_WP_CRON, une méthode de secours qui redirige le visiteur pour exécuter les tâches dans sa propre requête. Le 27 novembre 2025, cinq jours avant la sortie, Weston Ruter rétablit l’ancien comportement pour ces seuls sites. WordPress 6.9 sort le 2 décembre 2025 avec les deux changements.

Ce que fait ALTERNATE_WP_CRON

Ce mode de secours ne s’applique qu’aux requêtes de lecture classiques, hors AJAX et XML-RPC. Au lieu d’envoyer une requête de bouclage, WordPress redirige le visiteur vers la même adresse avec un paramètre de lancement, puis exécute les tâches dans la requête d’origine, que le navigateur vient de quitter. La documentation le présente comme une solution aux articles programmés qui ne se publient pas. On l’active en général quand la requête de bouclage est bloquée. Le visiteur paie là encore le prix, avec une redirection supplémentaire à chaque lancement.

Ce qu’il faut en retenir

Le déclenchement par les visites est payé par un vrai visiteur : une requête de 0,01 seconde peut coûter une seconde. WordPress 6.9 a déplacé ce coût après l’envoi de la page, sans le supprimer : le lancement s’exécute toujours dans le processus PHP d’un visiteur, et le problème de la bibliothèque HTTP n’est pas résolu. Les modes de secours comme ALTERNATE_WP_CRON restent des cas particuliers fragiles.

Avec un cron système et WP-Cron désactivé sur les visites, aucune de ces questions ne se pose : WordPress n’essaie même plus de lancer les tâches pendant les requêtes des visiteurs. Si le temps de réponse de votre site vous préoccupe, notre guide des correctifs Core Web Vitals détaille les autres leviers.

Pourquoi WP-Cron rate sur les petits sites et pèse sur les gros

Trafic faible : la tâche attend un visiteur

Sur un site peu visité, ou presque entièrement servi par le cache, les tâches attendent la prochaine requête qui atteint PHP. Un article programmé paraît en retard, une sauvegarde nocturne part au matin, un renouvellement d’abonnement attend qu’un client se connecte.

Trafic fort : un processus occupé, une file unique

Sur un site très visité, WP-Cron se lance souvent, et chaque lancement occupe un processus PHP du serveur le temps d’exécuter les tâches. Les tâches s’exécutent les unes après les autres : une tâche longue retarde toutes les suivantes, et si elle dépasse le délai du verrou, un autre processus peut reprendre la main.

Mémoire et durée d’exécution

Depuis WordPress 6.3, wp-cron.php relève la limite de mémoire de PHP à la valeur prévue pour les tâches lourdes, 256 Mo par défaut. Ce relèvement ne s’applique pas aux tâches lancées par WP-CLI ou par un mécanisme qui contourne ce fichier. En ligne de commande, en revanche, PHP n’impose pas de durée maximale d’exécution par défaut, ce qui convient mieux aux tâches longues.

Les rattrapages qui n’ont pas lieu

Une tâche récurrente manquée n’est pas rejouée. Si une tâche quotidienne n’a pas pu s’exécuter pendant trois jours, elle s’exécute une seule fois au retour, puis WordPress calcule la prochaine échéance. Pour un nettoyage, ce n’est pas grave. Pour un traitement qui compte sur chaque passage, des exécutions sont perdues.

Une pulsation lumineuse régulière qui entraîne une rangée d'engrenages de verre

Planifier proprement : intervalles et wp_schedule_event

Les intervalles du cœur et les intervalles personnalisés

WordPress fournit quatre intervalles : toutes les heures, deux fois par jour, tous les jours et toutes les semaines. Un plugin peut en ajouter avec le filtre cron_schedules, en indiquant une durée en secondes et un libellé :

add_filter( 'cron_schedules', function ( $schedules ) {
	$schedules['every_ten_minutes'] = array(
		'interval' => 600,
		'display'  => 'Every ten minutes',
	);
	return $schedules;
} );

Un intervalle très court ne garantit rien : le verrou d’une minute et le rythme des visites, ou celui du cron système, fixent la fréquence réelle.

Éviter les doublons et nettoyer

Avant de planifier une tâche récurrente, un plugin doit vérifier qu’elle n’existe pas déjà, sous peine de l’empiler à chaque chargement. La documentation propose ce motif, et rappelle de supprimer la tâche à la désactivation du plugin :

if ( ! wp_next_scheduled( 'my_plugin_hourly_job' ) ) {
	wp_schedule_event( time(), 'hourly', 'my_plugin_hourly_job' );
}

register_deactivation_hook( __FILE__, function () {
	wp_clear_scheduled_hook( 'my_plugin_hourly_job' );
} );

Pour une tâche unique, WordPress ignore une nouvelle planification du même événement à moins de dix minutes d’une existante, sauf si ses arguments diffèrent. Une tâche qui « ne se planifie pas » vient souvent de là.

Une tâche qui dure trop

Une tâche longue pose un problème particulier. Si elle dépasse la durée du verrou, un autre lancement peut reprendre la main pendant qu’elle tourne encore ; le code du cœur arrête alors la boucle du premier processus. Les traitements lourds gagnent donc à être découpés en petits lots, chacun planifié séparément, ou confiés à une file comme Action Scheduler, conçue pour ce travail.

Passer à un vrai cron système

DISABLE_WP_CRON : ce que la constante fait, et ne fait pas

La constante DISABLE_WP_CRON, dans wp-config.php, supprime le lancement par les visites. Elle ne désactive pas les tâches : wp-cron.php continue de les exécuter quand on l’appelle. Le commentaire du fichier le précise, les deux sont indépendants.

define( 'DISABLE_WP_CRON', true );

Définir cette constante sans mettre en place un autre déclencheur est l’erreur la plus courante : plus rien ne part, silencieusement, ni articles programmés, ni mises à jour automatiques, ni renouvellements.

Appeler wp-cron.php par URL, ou lancer WP-CLI

La documentation propose d’appeler wp-cron.php depuis le planificateur du système. Une ligne de crontab qui le fait toutes les quinze minutes ressemble à ceci :

*/15 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

L’autre méthode lance les tâches dues avec WP-CLI, sans passer par HTTP. Le panneau de gestion de serveurs SpinupWP l’enveloppe dans flock, qui empêche deux exécutions simultanées :

*/5 * * * * cd /chemin/vers/wordpress && flock -n ~/.wp_cron.lock /usr/local/bin/wp cron event run --due-now --quiet

Chaque méthode a ses forces. L’appel par URL garde le verrou du cœur et l’augmentation de mémoire prévue pour les tâches, mais dépend du réseau et de l’authentification du site.

WP-CLI évite tous les problèmes de bouclage et n’a pas de limite de durée par défaut en ligne de commande, mais la version stable actuelle ne respecte pas le verrou du cœur : d’où l’intérêt de flock, ou d’une seule méthode à la fois. N’exécutez pas WP-CLI en tant que root : sa documentation le déconseille fortement. Notre sélection de commandes WP-CLI essentielles détaille son installation et ses usages.

Vérifier que le cron système tourne

Après la mise en place, listez les tâches et leur prochaine échéance. Une tâche dont l’échéance est passée depuis longtemps signale un déclencheur qui ne fonctionne pas :

wp cron event list --fields=hook,next_run_relative

Multisite et hébergeurs infogérés

Sur un multisite, chaque site a sa propre liste de tâches : il faut un appel par site, par exemple en bouclant sur la liste des sites avec WP-CLI. Beaucoup d’hébergeurs infogérés proposent leur propre déclencheur, chacun à son rythme. Kinsta lance un cron serveur toutes les quinze minutes sur tous les sites, à vous de désactiver ensuite WP-Cron.

WP Engine propose un cron alternatif à activer dans son portail, qui vérifie les tâches dues chaque minute. Pantheon les lance toutes les heures, et WordPress VIP fait tourner son propre exécuteur toutes les trente secondes. Demandez à votre hébergeur ce qu’il fait avant d’ajouter votre propre cron.

Deux déclencheurs en parallèle ne rendent pas le site plus fiable : ils exécutent parfois deux fois les mêmes tâches. Chaque hébergeur a aussi ses contraintes : Pantheon demande que les appels externes laissent vide le paramètre de lancement, et WP Engine prévient que son cron alternatif ne fonctionne pas derrière une authentification HTTP personnalisée. Choisissez une seule méthode, et documentez-la.

Action Scheduler, la file d’attente de WooCommerce

Comment elle s’appuie sur WP-Cron

WooCommerce et de nombreux plugins confient leurs tâches de fond à Action Scheduler, une file d’attente qui stocke chaque tâche dans ses propres tables : renouvellements, courriels, webhooks, imports de statistiques. Sa documentation précise qu’elle ne dépend pas de WP-Cron, mais c’est bien WP-Cron qui la démarre par défaut, au plus une fois par minute, par lots de vingt-cinq tâches pendant trente secondes.

Si WP-Cron s’arrête, la file ne tourne plus qu’au gré des passages dans l’administration, c’est-à-dire presque plus sur une boutique où personne ne se connecte. La documentation de WooCommerce Subscriptions voit même dans plusieurs tâches en retard de plus d’un jour l’indice possible d’un problème de WP-Cron.

La lancer en WP-CLI sur une boutique chargée

Pour une boutique qui traite beaucoup de tâches, la documentation d’Action Scheduler recommande WP-CLI, bien plus adapté que l’exécuteur par défaut. Une ligne de cron dédiée lance la file régulièrement :

wp action-scheduler run --batch-size=100

Un petit plugin officiel permet ensuite de désactiver l’exécuteur par défaut, avec un avertissement clair : sans WP-CLI ou une autre méthode, plus aucune tâche ne sera traitée.

Les abonnements WooCommerce

WooCommerce Subscriptions s’appuie sur Action Scheduler pour les paiements récurrents, les fins d’essai, les nouvelles tentatives de paiement et les expirations. Sa documentation précise que, sans WP-Cron, la file ne peut plus être traitée que par les requêtes de l’administration. Un contrôle de santé, dans l’état de WooCommerce, résume les tâches d’abonnement en retard. Pour une boutique d’abonnements, un cron système dédié s’impose.

Rétention et tables qui gonflent

Les tâches terminées ou annulées sont purgées au bout de trente et un jours ; depuis la version 4.0, livrée avec WooCommerce 11.0, les tâches en échec le sont au bout de trois mois. Une file qui ne tourne pas, ou qu’un plugin inonde, fait pourtant gonfler la base, comme le raconte notre guide d’optimisation de la base de données WordPress.

Les articles en « Planification manquée »

Ce que fait la publication programmée

Programmer un article crée une tâche unique, à la date de publication prévue. Quand elle s’exécute, WordPress publie l’article s’il est toujours programmé et que l’heure est passée ; si la tâche part trop tôt, elle se replanifie. Si WP-Cron ne passe pas, la liste des articles affiche un message d’échec de programmation, signalé en rouge.

Rattraper sans tout déclencher

Pour publier les articles en retard, WP-CLI lance les tâches dues. Attention à un piège : sans l’option --due-now, la commande appliquée à un nom de tâche exécute toutes les tâches de ce nom, y compris celles prévues dans le futur. La publication programmée se protège, puisque la tâche se replanifie si l’heure n’est pas venue, mais d’autres tâches partiraient en avance.

wp cron event run --due-now

Des plugins comme MWW Scheduled Post Trigger ou Missed Scheduled Posts Publisher republient les articles manqués. Ces plugins dépendent eux-mêmes des visites et ne réparent que les articles. La fiche du premier le présente comme une solution d’attente, le temps de trouver pourquoi le planificateur ne fonctionne pas.

Déboguer avec WP Crontrol

Lire la liste des tâches

WP Crontrol, gratuit, maintenu par John Blackbourn, l’auteur de Query Monitor, et installé sur plus de 300 000 sites en octobre 2026, affiche toutes les tâches planifiées avec leurs arguments, leur intervalle, leurs fonctions et leur prochaine échéance. Il permet de les exécuter, les mettre en pause, les modifier ou les supprimer, et signale celles qui n’ont plus de fonction associée ou ont manqué leur échéance.

Supprimer une tâche qui réapparaît ne sert à rien : son plugin la recrée. Mettez plutôt son nom en pause. Une tâche sans fonction associée provient en général d’un plugin supprimé et peut être retirée. WP Crontrol ne garde pas encore d’historique des exécutions ; pour un journal, Advanced Cron Manager le propose dans sa version payante.

Les erreurs de lancement

Quand les tâches ne partent pas du tout, la cause est souvent la requête de bouclage : DNS, pare-feu, authentification HTTP, certificat, fichier wp-cron.php absent ou erreur PHP fatale. La commande wp cron test vérifie que le lancement fonctionne, tant que WP-Cron n’est pas désactivé, et l’aide de WP Crontrol liste ces causes une à une.

Les tâches PHP et URL de WP Crontrol

WP Crontrol permet aussi de créer des tâches qui exécutent du code PHP ou appellent une adresse. C’est puissant, et donc sensible : en mars 2024, une faille notée 8,1 sur 10 permettait l’exécution de code à distance à condition qu’une autre faille existe déjà sur le site ou que la base de données ait été compromise, corrigée en version 1.16.2. Depuis la version 1.18, la constante CRONTROL_DISALLOW_PHP_EVENTS désactive les tâches PHP. Utilisez-la sur les sites qui n’en ont pas besoin.

Un œil de sécurité

Le fichier wp-cron.php s’exécute à chaque lancement, ce qui en fait une cible. En 2025, Wordfence a décrit un faux plugin de sécurité accompagné d’un wp-cron.php modifié qui le recréait et le réactivait à la visite suivante s’il était supprimé, et dont une variante utilisait une tâche planifiée toutes les minutes pour contacter son serveur de commande. Une tâche inconnue sur un intervalle inhabituel mérite une enquête, et wp core verify-checksums vérifie que les fichiers du cœur n’ont pas été modifiés.

Surveiller la santé du cron

La Santé du site, WP-CLI et Action Scheduler

La Santé du site signale une tâche en retard ou en échec. Sans DISABLE_WP_CRON, une tâche en retard de plus de cinq minutes est considérée comme en échec ; avec la constante, les seuils passent à quinze minutes et une heure, pour tenir compte du rythme d’un cron système. Ce test ne regarde que la liste de WP-Cron, pas la file d’Action Scheduler, qui affiche son propre avertissement dans l’administration dès qu’une tâche a plus d’un jour de retard.

Un battement de cœur externe

Aucun contrôle interne ne voit un cron système qui ne tourne plus du tout. Un service de surveillance comme Healthchecks.io attend un signal à chaque exécution et alerte quand il n’arrive pas. Il suffit d’ajouter un appel à la fin de la ligne de cron, par exemple && curl -fsS -m 10 --retry 5 -o /dev/null suivi de l’adresse fournie par le service.

Healthchecks.io propose une offre gratuite de vingt contrôles au moment où nous écrivons, et peut aussi être auto-hébergé. Cronitor, autre service du même type, propose une offre gratuite de cinq moniteurs. Notre checklist de maintenance WordPress recense les autres vérifications à mener régulièrement.

Tableau récapitulatif

Méthode Déclencheur Limites Pour qui
WP-Cron par défaut Les visites qui atteignent PHP Retards, bouclage fragile, cache Petits sites sans enjeu horaire
ALTERNATE_WP_CRON Redirection du visiteur Cas particulier, fragile Dépannage ponctuel
Cron système par URL Planificateur du serveur Dépend du réseau et de l’authentification La plupart des sites
Cron système avec WP-CLI Planificateur du serveur Verrou à ajouter, accès SSH Boutiques, sites chargés
Exécuteur de l’hébergeur Service de l’hébergeur Rythme imposé Sites en hébergement infogéré

Questions fréquentes

Faut-il toujours désactiver WP-Cron ?

Non, seulement si vous le remplacez par un cron système ou si votre hébergeur le fait. Un petit site sans tâche urgente peut garder le fonctionnement par défaut. Désactiver sans remplacer est la pire option.

Quel intervalle choisir pour le cron système ?

Cinq à quinze minutes conviennent à la plupart des sites. Une boutique avec des abonnements ou beaucoup de tâches de fond gagne à passer à une ou cinq minutes, avec un verrou pour éviter les exécutions simultanées.

Peut-on appeler wp-cron.php chaque minute ?

Oui, mais chaque appel charge WordPress, même quand aucune tâche n’est due. Kinsta fixe à cinq minutes l’intervalle minimal de ses crons personnalisés. Une minute se justifie pour une boutique très active ; pour la plupart des sites, cinq à quinze minutes suffisent.

WP-CLI ou appel par URL ?

WP-CLI si vous avez un accès SSH et que le site est protégé par une authentification ou un pare-feu. L’appel par URL est plus simple à mettre en place sur un hébergement mutualisé, et garde le verrou du cœur.

Pourquoi mes articles programmés ratent-ils encore ?

Vérifiez d’abord qu’un déclencheur existe vraiment : DISABLE_WP_CRON sans cron système arrête tout. Puis, si WP-Cron n’est pas désactivé, testez le lancement avec wp cron test, qui renvoie une erreur dès que DISABLE_WP_CRON est défini. Avec un cron système, vérifiez plutôt la liste des tâches avec wp cron event list, et regardez dans WP Crontrol si la tâche de publication existe et à quelle date.

Action Scheduler a-t-il besoin de WP-Cron ?

Pas en théorie, mais c’est WP-Cron qui le démarre par défaut. Si vous désactivez WP-Cron, gardez un cron système qui appelle wp-cron.php ou lancez la file avec WP-CLI, sinon les tâches d’Action Scheduler s’arrêtent avec le reste.

WordPress 6.9 a-t-il réglé le problème ?

Il a supprimé l’attente du visiteur avant l’affichage de la page, pas la dépendance aux visites ni le travail dans un processus PHP de visiteur. Un cron système reste la solution fiable.

Conclusion

WP-Cron est un compromis ingénieux : il fait fonctionner des tâches planifiées sur n’importe quel hébergement, sans configuration. Ce compromis se paie par des retards sur les sites peu visités, une charge supplémentaire sur les sites très fréquentés, et une fragilité dès que le serveur ne peut plus s’appeler lui-même.

Pour un site qui compte, la recette tient en trois lignes : désactiver le lancement par les visites, mettre en place un cron système, par URL ou WP-CLI, et surveiller qu’il tourne avec un signal externe. Sur une boutique, ajoutez une ligne pour Action Scheduler.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier