WP-Cron
Le planificateur de tâches intégré à WordPress, qui lance les opérations programmées, comme une publication différée ou une sauvegarde, au moment où le site reçoit une visite et non à heure fixe.
Définition
WP-Cron est le planificateur de tâches intégré à WordPress : il lance les opérations programmées, comme une publication différée ou une sauvegarde, au moment où le site reçoit une visite, et non à heure fixe. Un site peu visité exécute donc ses tâches en retard. Sur un site en production, on le remplace souvent par une tâche planifiée du serveur, à condition de brancher celle-ci avant de couper le mécanisme d’origine.
Qu’est-ce que WP-Cron ?
Une liste de tâches datées, rangée dans la base, et un mécanisme qui la consulte à chaque visite.
Le nom vient de cron, le planificateur des serveurs Unix, qui exécute une commande à heure fixe. WordPress ne peut pas compter sur lui : certains hébergements n’en donnent pas l’accès. Il tient donc son propre agenda, enregistré dans une option de la base de données nommée cron, où chaque tâche porte une date d’échéance, un nom et, le cas échéant, une fréquence de répétition.
Le cœur s’en sert pour publier les articles programmés, vérifier les mises à jour disponibles, appliquer les mises à jour automatiques ou vider la corbeille. Les extensions y ajoutent leurs propres tâches : sauvegardes, analyses de sécurité, envois de courriels, nettoyage de cache. Sur le site relevé plus bas, la liste compte 69 entrées.
Comment fonctionne WP-Cron ?
Une visite sert de réveil : WordPress regarde l’agenda et, si une tâche est due, se rappelle lui-même en arrière-plan.
Le code de WordPress 7.1.3, lu pour cette fiche, montre l’enchaînement. À la fin de chaque chargement de page, une fois la réponse produite, WordPress vérifie si une tâche est arrivée à échéance. Si c’est le cas, il envoie une requête vers son propre fichier wp-cron.php, sans en attendre la réponse : le délai d’attente est fixé à un centième de seconde. C’est ce second appel, appelé requête en boucle, qui exécute les tâches. Un verrou d’une minute empêche deux exécutions de se chevaucher.
Ce fonctionnement a trois conséquences. Une tâche programmée à 3 heures du matin part à la première visite qui suit, peut-être à 8 heures. Un robot qui parcourt le site compte comme une visite et déclenche les tâches comme un humain, mais une page servie par un cache de page ne réveille rien, puisque WordPress n’est pas chargé. Et si l’hébergeur bloque les requêtes du site vers lui-même, ou si le site est protégé par un mot de passe, comme une préproduction, les tâches ne partent plus. L’outil Santé du site de WordPress contrôle justement que ces boucles de requêtes fonctionnent.
Quels modes de déclenchement choisir ?
Trois réglages existent, et le bon dépend d’abord de l’accès au planificateur du serveur.
| Mode | Ce qui déclenche les tâches | Quand le choisir | Le revers |
|---|---|---|---|
| Par défaut | Les visites, via une requête en boucle | Petit site sans accès au planificateur du serveur | Retards sur un site peu visité, échec silencieux si les boucles sont bloquées |
DISABLE_WP_CRON et tâche serveur | Le planificateur du serveur, à intervalle fixe | Site en production dès que l’hébergeur ouvre ce planificateur | Rien ne tourne entre deux passages, et rien du tout si la tâche serveur disparaît |
ALTERNATE_WP_CRON | Les visites, via une redirection du visiteur | Dépannage, quand les requêtes en boucle sont impossibles | Le visiteur est redirigé vers une adresse portant un paramètre technique |
Notre position : sur un site qui vit de ses tâches planifiées, sauvegardes et analyses de sécurité en tête, le planificateur du serveur s’impose dès que l’hébergement le permet. La documentation officielle de WordPress décrit la manœuvre : la constante DISABLE_WP_CRON dans wp-config.php, puis une tâche du serveur qui appelle wp-cron.php. Le mode alternatif reste un dépannage, pas une solution : il expose un paramètre technique dans l’adresse des pages.
L’ordre compte. On crée la tâche serveur, on vérifie qu’elle s’exécute, puis seulement on pose DISABLE_WP_CRON. Dans l’ordre inverse, ou si la tâche serveur est supprimée plus tard, par un changement d’hébergeur par exemple, plus rien ne part : ni publication programmée, ni sauvegarde. WordPress ne prévient pas, l’article attendu affiche seulement « Planification manquée » dans l’administration.
Comment vérifier que WP-Cron fonctionne ?
En regardant l’agenda lui-même : les tâches dont l’échéance est passée depuis longtemps trahissent un déclencheur en panne.
Lister les tâches
Avec WP-CLI, la commande wp cron event list affiche chaque tâche, sa prochaine échéance et sa fréquence. Une extension d’administration des tâches donne la même vue dans le tableau de bord.
Repérer les retards
Quelques minutes de retard sont normales entre deux déclenchements. Des heures ou des jours de retard sur des tâches quotidiennes signalent que plus rien ne réveille l’agenda.
Tester le déclencheur
wp cron test vérifie que la requête en boucle aboutit. Si le site passe par une tâche serveur, c’est elle qu’il faut contrôler, avec la trace de sa dernière exécution.
Une tâche qui échoue à chaque passage ne se voit pas non plus. Certaines extensions gèrent leur propre file de travail par-dessus WP-Cron, et y accumulent des échecs que personne ne lit. C’est l’une des formes de la dette technique d’un site.
Comment une extension ajoute-t-elle une tâche planifiée ?
Elle inscrit une tâche dans l’agenda avec une fonction du cœur, puis y attache le code à exécuter.
Le code d’une extension appelle la fonction wp_schedule_event avec une date de départ, une fréquence et un nom de tâche, puis associe à ce nom la fonction à lancer. WordPress fournit les fréquences horaire, biquotidienne, quotidienne et hebdomadaire, et une extension peut en déclarer d’autres. C’est pourquoi l’agenda d’un site en compte vite davantage qu’on ne l’imagine, et pourquoi une extension désinstallée sans nettoyage peut y laisser des tâches orphelines.
Certaines extensions, WooCommerce en tête, gèrent leurs traitements avec Action Scheduler, une bibliothèque qui tient sa propre file de travail dans la base. D’après sa documentation, elle est réveillée par défaut par WP-Cron, sans en dépendre pour autant : elle peut aussi être lancée par WP-CLI. En pratique, sa file avance donc au rythme du déclencheur de WP-Cron, quelle que soit la fréquence qu’elle demande.
Ce que montre un site réel
Relevé du 14 octobre 2026, en lecture seule, sur un site vitrine WordPress 7.1.3 que nous maintenons, sur un hébergement mutualisé. WP-Cron y est désactivé par DISABLE_WP_CRON, et une tâche du serveur appelle wp-cron.php toutes les 15 minutes. Les journaux d’accès du 30 septembre au 14 octobre le confirment : aucune requête vers wp-cron.php à la racine, les visites ne déclenchent plus rien. L’agenda compte 69 tâches : 32 quotidiennes, 9 biquotidiennes, 9 hebdomadaires, 4 mensuelles, 4 horaires, 6 toutes les 15 minutes, 4 uniques et une file d’extension programmée chaque minute. Cette dernière ne tourne en réalité qu’au rythme de la tâche serveur, soit une fois par quart d’heure. Au moment du relevé, 4 tâches avaient entre une et trois minutes de retard, ce qui est normal entre deux passages.
Questions fréquentes
Pourquoi mon article programmé ne s’est-il pas publié ?
Dans la plupart des cas, parce que WP-Cron n’a pas été réveillé à temps : aucune visite après l’heure prévue, requêtes en boucle bloquées par l’hébergeur ou par une protection par mot de passe, ou DISABLE_WP_CRON posé sans tâche serveur. L’administration affiche alors « Planification manquée » à côté de l’article.
WP-Cron ralentit-il le site ?
Pas la page du visiteur qui le déclenche : la vérification se fait une fois la page produite, et l’exécution part dans une requête séparée. En revanche, des tâches lourdes lancées pendant les heures de trafic consomment les ressources du serveur au même moment que les visiteurs.
Faut-il désactiver WP-Cron ?
Oui si l’hébergement permet de le remplacer par une tâche du serveur, et seulement dans ce cas. Le désactiver sans remplacement arrête les sauvegardes, les publications programmées et les mises à jour automatiques.
Quelle fréquence donner à la tâche serveur ?
Elle fixe le délai maximal de toutes les tâches. Un passage toutes les 15 minutes suffit à un site vitrine. Un site qui envoie des courriels de commande ou traite une file de travail en continu demande un intervalle plus court, dans la limite de ce que l’hébergeur autorise.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.