« Ajoutez define('DISABLE_WP_CRON', true);, ça allège le serveur. » Ce conseil, recopié d’un tutoriel à l’autre, est techniquement vrai mais dangereusement incomplet. Beaucoup de développeurs l’appliquent en pensant simplement retirer une charge inutile, sans réaliser qu’ils viennent de couper le seul mécanisme qui déclenche, sur une installation WordPress standard, les publications planifiées, les vérifications de mise à jour et les tâches internes des extensions.
Cet article détaille ce que cette constante arrête réellement, et ce qu’il faut mettre en place à la place pour ne perdre aucune fonctionnalité. Il ne traite pas de la création de tâches cron personnalisées via wp_schedule_event, qui mérite un article à part entière.
Le pseudo-cron de WordPress, un mécanisme déclenché par la visite
WordPress n’a pas de planificateur de tâches au sens système du terme. Ce qu’on appelle wp-cron est en réalité un fichier, wp-cron.php, appelé à la fin de chaque requête HTTP qui charge WordPress, à condition qu’un délai suffisant se soit écoulé depuis la dernière exécution. Ce délai minimal est fixé par la constante WP_CRON_LOCK_TIMEOUT, soixante secondes par défaut. Concrètement, c’est un visiteur qui charge une page qui, silencieusement, relance ce fichier en arrière-plan via une requête HTTP interne non bloquante.
Pourquoi ce mécanisme pose problème sur certaines infrastructures
Sur un site à fort trafic, ce déclenchement à chaque requête devient un coût réel : une requête HTTP interne supplémentaire pour chaque visiteur, même quand aucune tâche planifiée n’est réellement due. Sur un site à trafic faible ou irrégulier, c’est l’inverse qui pose problème : sans visite au moment prévu, une tâche planifiée peut prendre des heures de retard, voire ne jamais se déclencher si le site reste inactif.
Ce que DISABLE_WP_CRON arrête concrètement
Définir cette constante à true empêche WordPress d’appeler wp-cron.php à la fin de chaque requête. Rien d’autre ne change dans le fonctionnement interne : les tâches restent enregistrées dans la table wp_options, sous la clé cron, avec leur horodatage d’exécution prévu. Elles attendent simplement un déclencheur qui ne vient plus. Voici ce qui s’arrête concrètement en l’absence de relais externe :
- Les articles programmés pour une publication future restent au statut « planifié » indéfiniment, au-delà de leur date prévue.
- Les vérifications automatiques de mise à jour du cœur, des thèmes et des extensions ne se déclenchent plus.
- Les tâches propres aux extensions (nettoyage de transients expirés, envoi différé d’e-mails, synchronisations planifiées) s’accumulent sans jamais s’exécuter.
- Les statistiques ou rapports générés périodiquement par certains plugins cessent d’être mis à jour.
Ce qu’il faut mettre en place pour compenser
Désactiver le pseudo-cron n’est une bonne décision que si elle s’accompagne d’un déclencheur externe fiable. La méthode la plus robuste consiste à appeler wp-cron.php via une tâche cron système classique, à intervalle régulier, indépendamment de tout visiteur :
*/5 * * * * curl -s https://exemple-client.fr/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Cette ligne, ajoutée à la crontab système du serveur, déclenche l’exécution des tâches dues toutes les cinq minutes, sans jamais dépendre d’un visiteur pour le faire. Une alternative plus propre côté exécution consiste à utiliser la commande WP-CLI dédiée, qui évite une requête HTTP complète et s’exécute directement en ligne de commande :
*/5 * * * * cd /var/www/exemple-client && wp cron event run --due-now --quiet
Vérifier que tout fonctionne encore
Après avoir désactivé le pseudo-cron et mis en place un relais externe, il reste indispensable de vérifier que les tâches s’exécutent bien. La commande wp cron event list affiche l’ensemble des tâches planifiées avec leur prochaine date d’exécution prévue, ce qui permet de repérer immédiatement une tâche bloquée ou en retard.
| Configuration | Déclencheur des tâches |
|---|---|
| WP_CRON par défaut (non défini) | Visite d’un utilisateur, tant que le délai minimal est écoulé |
| DISABLE_WP_CRON à true, sans relais | Aucun, les tâches s’accumulent indéfiniment |
| DISABLE_WP_CRON à true, avec cron système | Intervalle régulier, indépendant du trafic |
Une vérification que nous appliquons systématiquement après ce genre de changement : comparer la date de « prochaine exécution » de
wp cron event listavant et après la mise en place du relais externe, sur plusieurs heures.
En résumé
La constante DISABLE_WP_CRON ne supprime aucune tâche planifiée : elle coupe simplement le fil qui les déclenche à chaque visite. C’est un choix pertinent pour un site à fort trafic ou pour une infrastructure qui veut un déclenchement prévisible plutôt qu’aléatoire, à condition de le remplacer immédiatement par un appel régulier depuis le système d’exploitation. Sans ce relais, la désactivation transforme un mécanisme imparfait en silence complet, et personne ne s’en aperçoit avant qu’un article programmé ne reste bloqué des jours durant.
