wp-cron vs cron système : WordPress, par défaut, simule un planificateur au trafic. C'est malin sur un mutualisé sans SSH. C'est fragile pour une boutique, un membership, des mails, un cache à purger. Cet article explique la différence, les symptômes (mails en retard, relances en paquet, CPU en pics), comment désactiver wp-cron et poser un vrai cron, et le lien avec les files (Action Scheduler Woo).
⏰ Comment wp-cron ment
À chaque visite (ou presque), WordPress regarde s'il a des tâches dues. Sans visite, rien ne s'exécute. Un site B2B le week-end : silence. Un pic : tout le monde déclenche le cron, CPU en pic. Les deux extrêmes sont mauvais.
Les tâches s'empilent, puis partent en rafale. Les relances panier arrivent trop tard ou toutes d'un coup. Les e-mails « 1 h après » partent à 8 h.
🛠️ Cron système
Le serveur appelle une URL ou `wp cron event run --due-now` toutes les 5 minutes. Indépendant du trafic. Charge lissée. On monitore le dernier run (voir l'article sur le monitoring).
Mutualisé sans cron : on négocie, ou on change d'hébergeur. Un Woo sans cron fiable n'est pas une boutique tenue.
- DISABLE_WP_CRON dans le wp-config
- Crontab 5 min
- Logs du dernier succès
- Woo : file Action Scheduler à jour
⚠️ Erreurs classiques
Oublier de désactiver wp-cron : double exécution. Protéger wp-cron.php trop fort : plus rien ne tourne. Appeler trop souvent (toutes les 10 s) : on recrée le pic.
Les tâches longues (import) ne devraient pas vivre dans ce cron. File dédiée, timeout connu.
✅ Vérification
Planifier un brouillon dans 10 minutes, couper le trafic (maintenance), attendre le cron système, voir le post. Si ça ne part que quand on visite, on n'a rien fait.
wp-cron vs cron système : je pose le second sur tout site que je maintiens. Le premier est un fallback, pas une architecture.
✅ Liste de contrôle avant la bascule
Avant de passer au cron système, j'écris quelles tâches tournent aujourd'hui : mails, sauvegardes, imports, publications programmées. La mesure qui compte : chaque tâche s'exécute à l'heure prévue, même la nuit quand personne ne visite le site.
Sauvegarde restaurable, accès hébergeur à votre nom. Puis la bascule vers le cron système. Puis un contrôle après 24 h et une semaine d'observation (publications planifiées, relances). Sans cette observation, on a posé une tâche, pas vérifié qu'elle tourne.
- Liste des tâches planifiées et de leurs retards avant le changement
- Copie de test avant de désactiver wp-cron
- Un changement à la fois, documenté
- Contrôle des mails et des sauvegardes après 24 h, puis une semaine de suivi
📌 Ce que je refuse sur ce sujet
Je refuse de désactiver wp-cron sans mettre le cron système en place le même jour : les tâches s'arrêtent sans bruit. Je refuse aussi de lancer une tâche lourde chaque minute pour cacher un import mal écrit.
Avec peu de tâches et des visites régulières, wp-cron suffit très bien. Dans ce cas, on n'y touche pas.
wp-cron qui tourne au visiteur, c'est une file qui s'endort dès que personne ne vient.
🧭 Questions fréquentes
Faut-il agir tout de suite ? Oui si des publications planifiées ne partent plus, si les relances de panier traînent ou si les sauvegardes sont en retard. Sinon, on le range dans la prochaine intervention de maintenance, un jour calme.
Peut-on basculer sans copie de test ? Sur une vitrine calme, parfois. Sur une boutique, on essaie d'abord sur une copie : une tâche planifiée mal lancée peut envoyer des mails en double. Voir Tester un site WordPress en local et en préprod.
Combien de temps ? Souvent une heure sur un hébergement qui permet de créer une tâche planifiée (cron), une demi-journée avec un hébergeur mutualisé qui limite les accès. Un devis qui ne parle pas de la vérification des files d'attente est incomplet.
