# DISABLE_WP_CRON : ce que cette option implique pour votre infrastructure

> Désactiver le pseudo-cron de WordPress par habitude n'est pas anodin. Voici ce qui s'arrête vraiment, et ce qu'il faut mettre en place pour ne rien perdre.

- Auteur : WordPress Développement
- Publié le : 2022-12-08
- Mis à jour le : 2022-12-08
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/disable-wp-cron-implications-infrastructure/

## L’essentiel

- DISABLE_WP_CRON n'arrête pas les tâches, seulement leur déclenchement par visite
- Sans relais externe, les publications planifiées ne partent jamais
- Un cron système reproduit le même comportement en plus fiable

« 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.

> L'essentiel à retenir : DISABLE_WP_CRON n'arrête pas les tâches, seulement leur déclenchement par visite ; Sans relais externe, les publications planifiées ne partent jamais ; Un cron système reproduit le même comportement en plus fiable

## 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 list` avant 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.