WP-Cron : comprendre et optimiser les tâches planifiées de WordPress (2026)

Votre article programmé à 8h00 ne s’est publié qu’à 10h37. Votre sauvegarde UpdraftPlus "quotidienne" a 3 jours de retard. Et votre newsletter du mardi matin est partie… mardi soir.

Le coupable s’appelle WP-Cron.

J’ai découvert ce problème en 2014 — j’en parle dans nos fiches pratiques depuis, sur un site client qui ne recevait qu’une dizaine de visites par jour. Les articles programmés ne se publiaient jamais à l’heure. Le client pensait que WordPress était cassé. En réalité, c’était juste WP-Cron qui fonctionnait exactement comme prévu — et c’est là tout le problème.

WP-Cron, c’est quoi au juste ?

Sur un serveur Linux, le cron est un service système qui exécute des tâches à intervalles réguliers : toutes les heures, tous les jours, chaque lundi à 3h du matin. C’est fiable, précis et ça tourne que vous soyez devant l’écran ou en vacances.

WordPress n’a pas accès au cron système. Il a donc inventé son propre mécanisme : WP-Cron. Le principe est simple (et c’est là le piège) : à chaque chargement de page, WordPress vérifie si des tâches sont en retard. Si oui, il les exécute en arrière-plan via un appel HTTP interne vers le fichier wp-cron.php.

Pas de visite = pas de vérification = pas d’exécution.

Techniquement, quand un visiteur charge une page, WordPress appelle la fonction spawn_cron() qui envoie une requête HTTP non bloquante vers wp-cron.php. Ce fichier charge WordPress en entier, vérifie les tâches en retard via wp_get_ready_cron_jobs(), et les exécute une par une. Le visiteur ne voit rien — mais votre serveur, lui, travaille en double.

WP-Cron est un système de pseudo-cron déclenché par le trafic web. Il gère les publications programmées, sauvegardes, mises à jour et nettoyage de base de données dans WordPress. Contrairement à un vrai cron serveur, il ne s’exécute pas à heure fixe mais uniquement lorsqu’un visiteur charge une page du site.

Ce que WP-Cron gère sur votre site

WP-Cron ne se limite pas aux articles programmés. Il fait tourner une bonne partie de la mécanique WordPress. Sur wpformation.com, WP Crontrol m’affiche 27 événements actifs. Voici les principaux :

Tâche	Fréquence	Responsable
Publication programmée	Toutes les minutes	WordPress Core
Vérification mises à jour (core, plugins, thèmes)	Toutes les 12 heures	WordPress Core
Suppression des transients expirés	Quotidienne	WordPress Core
Vidange de la corbeille (30 jours)	Quotidienne	WordPress Core
Sauvegardes automatiques	Selon config	UpdraftPlus, BackWPup, BlogVault
Nettoyage base de données	Hebdomadaire	WP-Optimize, WP Rocket
Envoi d’emails (commandes, relances, newsletters)	Variable	WooCommerce, MailPoet, FluentCRM
Purge du cache	Variable	LiteSpeed Cache, W3TC, WP Super Cache
Indexation SEO (sitemap, liens internes)	Quotidienne à hebdomadaire	Yoast SEO, Rank Math, AIOSEO
Traitement des commandes WooCommerce	Toutes les minutes	Action Scheduler (WooCommerce)
Synchronisation réseaux sociaux	Variable	Jetpack, SchedulePress

Plus vous installez de plugins, plus WP-Cron a de travail. Un site WooCommerce avec UpdraftPlus, Yoast et LiteSpeed Cache peut facilement atteindre 40 à 50 événements cron actifs.

Trois limites qui changent tout

Le problème n’est pas que WP-Cron soit "mauvais". C’est qu’il n’a jamais été conçu comme un vrai planificateur de tâches.

1. Dépendance au trafic. Pas de visite, pas d’exécution. Un site vitrine à 10 visites par jour, un blog de niche, un intranet d’entreprise, un site en cours de développement — tous souffrent de tâches en retard. J’ai vu des sauvegardes UpdraftPlus avec 5 jours de retard sur un site client. Le propriétaire pensait que ses données étaient protégées. Elles ne l’étaient pas.

2. Surcharge à fort trafic. À chaque page chargée, WordPress appelle spawn_cron() pour vérifier les tâches en attente. Sur un site à 10 000 visites par jour, ça représente 10 000 requêtes HTTP internes inutiles. C’est du gaspillage CPU pur, et ça ajoute quelques millisecondes au TTFB de chaque page.

3. Aucune garantie de ponctualité. Une tâche programmée à 14h00 s’exécutera à la prochaine visite après 14h00. Ça peut être 14h01 comme 18h45. Si vous envoyez une newsletter à vos abonnés ou des confirmations de commande WooCommerce, cette imprécision est plus qu’une gêne — c’est un problème commercial.

Action Scheduler : le cron moderne de WordPress

Depuis WooCommerce 3.5 (2018), une alternative plus robuste existe : Action Scheduler. C’est une bibliothèque développée par Automattic qui remplace WP-Cron pour les tâches lourdes et critiques.

Action Scheduler est un système de file d’attente pour WordPress qui stocke les tâches dans une table dédiée de la base de données, et non dans les options WordPress comme WP-Cron. Il gère les tâches par lots, supporte les groupes d’actions et intègre un mécanisme de retry en cas d’échec. C’est le moteur derrière les emails transactionnels de WooCommerce, les webhooks et le traitement asynchrone des commandes.

La différence fondamentale : WP-Cron stocke tout dans la table wp_options (une seule ligne sérialisée), ce qui pose des problèmes de performance à grande échelle. Action Scheduler utilise ses propres tables (wp_actionscheduler_actions et wp_actionscheduler_logs) avec des index optimisés.

Aujourd’hui, Action Scheduler est utilisé par WooCommerce, WPForms, All-in-One SEO, WP Mail SMTP et bien d’autres. Si votre site utilise WooCommerce, vous avez déjà Action Scheduler — et il cohabite avec WP-Cron sans conflit.

Désactiver WP-Cron et le remplacer par un vrai cron serveur

L’idée est simple : on empêche WordPress de vérifier les tâches à chaque visite, et on le remplace par un appel externe régulier et prévisible.

Étape 1 — Désactiver le déclenchement automatique. Ajoutez cette ligne dans votre fichier wp-config.php, avant la ligne /* That's all, stop editing! */ :

define('DISABLE_WP_CRON', true);

Cette ligne ne supprime pas WP-Cron. Elle empêche WordPress de le déclencher à chaque visite. Les tâches restent enregistrées, elles attendent simplement qu’on les appelle explicitement.

Étape 2 — Configurer un vrai cron serveur. La méthode varie selon votre hébergeur.

Chez O2switch (cPanel)

Direction cPanel → Tâches Cron. Créez une tâche avec ces paramètres :

• Fréquence : toutes les 5 minutes (*/5 * * * *)
• Commande : wget -q -O /dev/null https://votre-site.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

C’est la configuration que j’utilise sur wpformation.com — zéro publication ratée zéro sauvegarde manquée. Sur O2switch avec LiteSpeed Cache, la combinaison DISABLE_WP_CRON + cron cPanel toutes les 5 minutes est la configuration optimale.

Chez OVH et Infomaniak

Sur OVH : Espace client → Hébergement → Tâches planifiées (Cron jobs). Même URL, même fréquence de 5 minutes. Sur Infomaniak : Panneau de contrôle → Sites → Tâches planifiées. Infomaniak utilise une interface propre mais la configuration est identique.

Sur un VPS ou serveur dédié (SSH)

crontab -e
# Ajouter cette ligne :
*/5 * * * * cd /chemin/vers/wordpress && php wp-cron.php >/dev/null 2>&1

L’appel PHP direct est plus performant que wget car il évite une requête HTTP complète. Mais il nécessite un accès SSH et que le chemin PHP soit correct.

Alternative : services de cron externes

Pas d’accès au cron de votre hébergeur ? Des services gratuits comme UptimeRobot (monitoring + ping) ou cron-job.org peuvent appeler votre wp-cron.php à intervalles réguliers. C’est moins fiable qu’un vrai cron serveur (dépendance à un service tiers), mais c’est mieux que rien.

Les meilleurs plugins pour maîtriser WP-Cron

Configurer un cron serveur ne suffit pas toujours. Il faut aussi voir ce qui se passe sous le capot. Trois plugins se démarquent.

WP Crontrol — le standard

WP Crontrol est développé par John Blackbourn, également créateur de Query Monitor. C’est le plugin que j’installe en premier sur chaque site que je gère — avant même de regarder les tâches cron.

Direction Outils → Événements Cron pour voir l’intégralité des tâches programmées : nom du hook, prochaine exécution, récurrence, temps de retard éventuel. Vous pouvez exécuter manuellement une tâche, la supprimer, en créer de nouvelles, et surtout repérer les tâches orphelines — ces événements cron laissés par des plugins désinstallés qui continuent à tourner dans le vide.

WP Crontrol permet aussi de définir des intervalles de récurrence personnalisés (par exemple toutes les 2 heures) et d’ajouter des événements PHP personnalisés. C’est léger (un seul fichier PHP), sans publicité, sans version pro. Gratuit. Point.

Advanced Cron Manager — l’interface visuelle

Advanced Cron Manager (par Kuba Mikita) offre une interface plus visuelle avec une timeline des événements. La version gratuite couvre les besoins de base. La version Pro ajoute les logs d’exécution et les notifications par email en cas d’échec — utile pour monitorer un site e-commerce en production.

SchedulePress — pour les équipes éditoriales

SchedulePress (par WPDeveloper) ne gère pas le cron système mais résout un problème connexe : la planification éditoriale. Calendrier visuel, publication automatique sur les réseaux sociaux, gestion des publications ratées (missed schedule). Si votre problème principal est "mes articles ne se publient pas à l’heure", SchedulePress est un complément utile au vrai cron serveur.

Plugin	Usage principal	Prix	Testé WP
WP Crontrol	Debug + gestion technique cron	Gratuit
Advanced Cron Manager	Visualisation + logs (Pro)	Freemium	6.8.3
SchedulePress	Calendrier éditorial + réseaux sociaux	Freemium	6.9.1

Cas concrets : quand WP-Cron vous lâche

La théorie, c’est bien. Voici ce qui se passe dans la vraie vie.

WooCommerce et les emails de commande. Un client passe commande à 14h12. L’email de confirmation part… quand le prochain visiteur charge une page. Sur un site à faible trafic, ça peut être 2 heures plus tard. Le client pense que sa commande n’a pas été enregistrée, contacte le support, ou pire — rachète ailleurs. Avec un cron serveur toutes les 5 minutes, l’email part au maximum 5 minutes après la commande.

UpdraftPlus et les sauvegardes fantômes. Vous configurez une sauvegarde quotidienne à 3h du matin. Mais à 3h du matin, personne ne visite votre site. La sauvegarde se lance au premier visiteur du matin — parfois à 9h, en plein pic de trafic. Résultat : le serveur rame, les pages se chargent lentement, et la sauvegarde elle-même peut échouer par timeout.

Cache et purge retardée. Vous mettez à jour un article important. LiteSpeed Cache programme une purge du cache. Mais sur un site à faible trafic, la purge ne se déclenche pas immédiatement. Vos visiteurs voient l’ancienne version pendant des heures. Sur wpformation.com, j’ai résolu ce problème avec un mu-plugin de revalidation combiné au cron serveur — les pages sont rafraîchies en moins de 5 minutes après chaque modification.

Yoast SEO et l’indexation. Yoast utilise WP-Cron pour recalculer les sitemaps et mettre à jour ses tables internes. Un retard de cron signifie un sitemap obsolète — et potentiellement des pages qui mettent plus longtemps à être indexées par Google.

Déboguer WP-Cron comme un pro

Quand les tâches ne tournent pas comme prévu, voici les outils et méthodes que j’utilise systématiquement.

WP-CLI : les commandes essentielles

Si vous avez un accès SSH, WP-CLI est votre meilleur allié (consultez notre guide complet WP-CLI pour toutes les commandes) :

# Lister tous les événements cron avec leur prochaine exécution
wp cron event list

# Exécuter toutes les tâches en attente immédiatement
wp cron event run --all

# Tester si WP-Cron fonctionne correctement
wp cron test

# Lister les intervalles de récurrence disponibles
wp cron schedule list

wp cron test vérifie que WordPress peut planifier et exécuter un événement. Si le test échoue, vérifiez que DISABLE_WP_CRON n’est pas activé sans cron externe configuré, et que votre hébergeur n’a pas bloqué les requêtes loopback (requêtes HTTP du serveur vers lui-même).

Activer les logs de WP-Cron

Pour tracer l’exécution des tâches, ajoutez ces constantes dans wp-config.php (en environnement de développement uniquement) :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Les erreurs cron apparaîtront dans wp-content/debug.log. Cherchez les entrées liées à spawn_cron, wp_cron ou au nom du hook de la tâche problématique.

Les causes fréquentes de panne

En plus de 12 ans de WordPress, j’ai identifié 4 causes récurrentes quand WP-Cron ne fonctionne plus :

• Loopback bloqué : le serveur ne peut pas se contacter lui-même (firewall, mauvaise config DNS interne). Testez avec Santé du site → "Les tâches planifiées fonctionnent"
• Plugin de sécurité trop strict : Wordfence ou Sucuri bloque l’accès à wp-cron.php. Ajoutez une exception
• DISABLE_WP_CRON sans cron externe : la cause n°1. Quelqu’un a copié la ligne d’un tutoriel sans configurer l’alternative
• Objet cron corrompu : la valeur sérialisée dans wp_options (option cron) est corrompue. WP Crontrol permet de la nettoyer

Quel hébergeur gère le mieux le cron WordPress ?

Tous les hébergeurs ne se valent pas sur ce point. Certains gèrent le cron côté serveur, d’autres vous laissent vous débrouiller.

Hébergeur	Cron système intégré ?	Fréquence	Configuration requise
O2switch	Manuel (cPanel)	Configurable	Créer une tâche cron dans cPanel
OVH	Manuel	Configurable	Espace client → Tâches planifiées
Infomaniak	Manuel	Configurable	Panneau → Sites → Tâches planifiées
Kinsta	Automatique	Toutes les minutes	Aucune — WP-Cron géré côté serveur
WP Engine	Automatique	Toutes les minutes	Aucune — WP-Cron système natif
Cloudways	Automatique	Configurable	Aucune — option dans le dashboard

Les hébergeurs managés (Kinsta, WP Engine) désactivent automatiquement DISABLE_WP_CRON et le remplacent par un vrai cron système. Sur un hébergeur mutualisé comme O2switch ou OVH, c’est à vous de le faire. Ce n’est pas compliqué — 2 minutes de configuration — mais il faut le savoir.

J’utilise O2switch pour wpformation.com. Le cPanel offre un accès direct aux tâches cron, le support technique est réactif, et le rapport qualité/prix reste imbattable pour un hébergement mutualisé français. Si la configuration technique vous semble complexe, découvrir notre formation WordPress avec accompagnement personnalisé peut vous faire gagner un temps considérable.

FAQ — WP-Cron WordPress

WP-Cron ralentit-il mon site ?

Oui, mais de façon variable. Sur un site à faible trafic, l’impact est négligeable. Sur un site à fort trafic, chaque visite déclenche une vérification spawn_cron() qui ajoute une requête HTTP interne et quelques millisecondes au TTFB. En désactivant WP-Cron au profit d’un cron serveur, vous supprimez cette surcharge sur 100% de vos pages.

Que se passe-t-il si je désactive WP-Cron sans cron serveur ?

Plus rien ne s’exécute automatiquement. Les articles programmés ne se publient pas, les sauvegardes ne se lancent pas, les mises à jour ne se vérifient plus, et Action Scheduler (WooCommerce) s’arrête. Désactiver WP-Cron sans alternative, c’est couper le système nerveux de WordPress.

Quelle fréquence choisir pour le cron serveur ?

Toutes les 5 minutes est le bon compromis pour 90% des sites. Toutes les minutes est excessif sauf pour un site e-commerce à fort volume (WooCommerce avec des centaines de commandes par jour). Toutes les 15 minutes est suffisant pour les sauvegardes mais retarde les publications programmées et les emails transactionnels.

WP-Cron fonctionne-t-il sur WordPress.com ?

Sur WordPress.com (hébergé par Automattic), le cron est géré côté serveur. Vous n’avez rien à configurer et vous ne pouvez pas modifier son comportement. Cette problématique ne concerne que les installations WordPress.org auto-hébergées.

Comment savoir si WP-Cron fonctionne sur mon site ?

Trois méthodes : (1) Installez WP Crontrol et vérifiez que les tâches s’exécutent aux intervalles prévus. (2) Allez dans Outils → Santé du site et cherchez "Les tâches planifiées fonctionnent". (3) En SSH, lancez wp cron test via WP-CLI.

Action Scheduler remplace-t-il WP-Cron ?

Non, les deux coexistent. Action Scheduler est un système de file d’attente plus robuste utilisé par WooCommerce et d’autres plugins pour les tâches lourdes. Il utilise ses propres tables en base de données mais dépend de WP-Cron (ou d’un cron serveur) pour être déclenché. Configurer un vrai cron améliore les performances des deux systèmes.

Mon article programmé ne s’est pas publié à l’heure, que faire ?

Vérifiez dans l’ordre : (1) WP-Cron est-il désactivé sans cron externe ? (2) La Santé du site signale-t-elle un problème de tâches planifiées ? (3) Un plugin de cache ou de sécurité bloque-t-il wp-cron.php ? (4) Le fuseau horaire WordPress est-il correct (Réglages → Général) ? La solution définitive reste un vrai cron serveur — c’est un problème que vous ne verrez plus jamais.