Une publication planifiée reste en attente, une sauvegarde ne démarre plus ou une synchronisation s’exécute avec plusieurs heures de retard. Le message « WP-Cron ne fonctionne pas » décrit le symptôme, pas encore la cause. Le déclencheur peut manquer, le hook peut échouer, une requête sortante peut être bloquée ou une tâche peut simplement attendre la prochaine visite.
Un bon diagnostic sépare donc quatre niveaux : l’événement existe-t-il, est-il arrivé à échéance, WordPress peut-il le déclencher et la fonction appelée termine-t-elle son travail ? Cette distinction évite de supprimer une file saine ou de lancer plusieurs fois une opération non idempotente.
Sommaire
La réponse courte
Commencez par relever l’heure WordPress, le hook concerné, sa prochaine exécution et sa récurrence. Vérifiez ensuite si d’autres événements sont également en retard. Testez uniquement le hook visé dans un environnement contrôlé, observez l’erreur produite et contrôlez l’effet métier attendu.
Sur un site peu visité ou soumis à un cache agressif, un déclenchement par un planificateur fiable peut être pertinent. Ne désactivez toutefois le déclenchement natif qu’après avoir prouvé que le nouveau mécanisme appelle effectivement WordPress. Ne publiez jamais dans un article les URL techniques, clés, journaux ou chemins utilisés pour cette configuration.
La documentation officielle rappelle que WP-Cron vérifie les tâches lors des chargements de page : ce n’est pas un démon qui tourne continuellement.
Principes qui restent valables
Le principe de WP-Cron n’a pas changé : WordPress stocke des événements, détecte ceux qui sont dus et appelle leurs hooks lorsqu’une occasion de déclenchement se présente. Une heure planifiée est donc une échéance, pas une garantie d’exécution à la seconde.
Les usages, eux, sont devenus plus nombreux. Publications différées, renouvellements, e-mails, files e-commerce, imports et sauvegardes peuvent s’appuyer sur ce mécanisme ou sur une couche qui lui ressemble. Cette diversité rend le diagnostic par supposition encore moins fiable.
Comprendre les quatre états possibles
Premier cas : aucun événement n’est enregistré. Le code d’activation, la configuration ou l’extension n’a peut-être jamais planifié le hook. Deuxième cas : l’événement existe, mais sa date est encore future ou l’heure affichée est mal interprétée.
Troisième cas : l’événement est dû, mais aucune requête ne déclenche correctement WP-Cron. Quatrième cas : le hook démarre et échoue pendant son traitement. Dans ce dernier cas, modifier la fréquence ne corrige ni une exception PHP, ni une API distante indisponible, ni un verrou applicatif.
Écrivez l’état observé avant toute action. « Hook absent », « prochaine exécution dépassée » et « exécution lancée mais résultat absent » conduisent à des pistes différentes.
Vérifier le fuseau horaire avant le retard
Comparez l’heure actuelle, le fuseau configuré dans WordPress et la valeur affichée par l’outil d’inspection. Les timestamps internes et les dates présentées à l’administrateur ne sont pas toujours rendus dans le même format.
Un décalage d’une ou deux heures autour d’un changement saisonnier ne prouve pas que la file est bloquée. Utilisez une référence explicite, notez le fuseau et calculez le retard réel. Pour une publication programmée, vérifiez aussi son statut et sa date locale.
Inventorier la file sans la modifier
Une inspection en lecture seule doit montrer au minimum le nom du hook, la prochaine exécution, le retard éventuel et la récurrence. WP-CLI documente `wp cron event list` pour lister les événements et choisir les champs utiles.
Cherchez un motif plutôt qu’une seule ligne. Si presque tous les hooks sont en retard, suspectez le mécanisme de déclenchement. Si un seul hook stagne, examinez son extension, ses arguments, ses verrous et ses dépendances. Si des milliers d’occurrences identiques existent, la planification peut être dupliquée.
Ne copiez pas une liste brute dans un ticket public. Elle peut révéler des noms d’extensions, des intégrations ou des identifiants métier.
Identifier le propriétaire du hook
Reliez le hook au cœur WordPress, à une extension, au thème ou à un développement spécifique. Consultez la documentation et le code maintenu ; ne déduisez pas la fonction à partir d’un nom ressemblant.
La documentation de planification recommande de vérifier `wp_next_scheduled()` avant d’ajouter un événement récurrent. Sans cette garde, un code exécuté plusieurs fois peut accumuler des doublons.
Avant de supprimer quoi que ce soit, déterminez aussi ce qui désenregistre proprement l’événement lors d’une désactivation. Un hook orphelin peut signaler une ancienne extension, mais il faut le prouver.
Tester un événement de façon contrôlée
Créez une sauvegarde appropriée et préférez un staging représentatif lorsque la tâche modifie des commandes, des abonnements, des fichiers ou des services externes. Neutralisez e-mails, paiements et webhooks avant le test.
WP-CLI permet d’exécuter un hook choisi ou les événements dus. Commencez par la cible la plus étroite. Une commande qui « s’exécute » prouve seulement que l’appel a été tenté ; vérifiez ensuite le résultat attendu dans l’application.
Évitez de lancer plusieurs fois une tâche inconnue. Certaines opérations sont idempotentes, d’autres peuvent envoyer deux messages, créer deux exports ou retraiter une transaction.
Lire l’erreur au bon endroit
Corrélez l’heure du test avec les journaux applicatifs et la santé du site. Cherchez une erreur fatale, une limite de mémoire, un délai dépassé, une réponse HTTP, un verrou non libéré ou une dépendance manquante.
Activez une collecte de diagnostic limitée dans le temps et retirez-la après l’analyse. Ne laissez pas l’affichage des erreurs exposé aux visiteurs. Masquez les données personnelles, jetons, URL privées et détails d’infrastructure avant tout partage.
Une tâche qui dépasse systématiquement la durée acceptable doit parfois être découpée en lots avec reprise, plutôt que relancée plus souvent.
Vérifier le déclenchement en boucle locale
WP-Cron peut être appelé par une requête que le site initie vers lui-même. Une résolution DNS incohérente, une authentification globale, une règle de pare-feu ou un certificat invalide peut perturber cette boucle.
Utilisez les diagnostics WordPress et un test autorisé pour confirmer la réponse, sans désactiver durablement une protection. Si une barrière est nécessaire sur un staging, prévoyez une exception contrôlée ou un autre déclencheur pour les tâches de test.
Une page servie par le cache n’implique pas nécessairement que PHP a reçu une occasion de vérifier la file. Mesurez le mécanisme réel.
Distinguer faible trafic et panne
Puisque WP-Cron dépend des occasions de déclenchement, un site sans visite peut exécuter une tâche après son heure prévue. La documentation officielle cite précisément ce retard possible.
Sur un blog où quelques minutes importent peu, le comportement natif peut suffire. Pour des échéances importantes, un planificateur externe ou système peut appeler régulièrement le point d’entrée prévu. Sa fréquence doit correspondre au besoin métier, pas à un chiffre universel.
Avant de basculer, documentez qui surveille ce déclencheur, comment une alerte apparaît et comment le comportement natif sera restauré si nécessaire.
Remplacer le déclencheur sans créer un trou
La séquence sûre est simple : préparer le nouveau déclencheur, tester son appel, observer plusieurs cycles, puis seulement désactiver le déclenchement sur visite si l’architecture le demande. Inversez la séquence pour revenir en arrière.
Ne confondez pas la constante de configuration qui désactive l’appel automatique avec la suppression de la file. Les événements restent des données WordPress ; vous changez la manière de leur donner une occasion de s’exécuter.
Conservez la commande, la fréquence et les secrets hors du contenu public. Une documentation interne peut contenir les paramètres nécessaires avec un accès limité.
Traiter les doublons avec prudence
Une file dupliquée peut consommer des ressources et reproduire des effets. Identifiez d’abord pourquoi l’événement est replanifié : activation répétée, absence de contrôle, option corrompue ou comportement voulu avec des arguments différents.
Sauvegardez avant une correction de masse. Désenregistrez via l’API ou l’outil propriétaire lorsque cela est possible, puis laissez le code recréer une occurrence saine. Supprimer aveuglément toutes les lignes d’un nom peut effacer des tâches légitimes.
Après nettoyage, surveillez la réapparition. Si les doublons reviennent, la cause est encore active.
Surveiller un résultat métier, pas seulement une horloge
Une file « à l’heure » peut exécuter une fonction qui n’aboutit pas. Choisissez un signal utile : publication devenue publique, sauvegarde terminée et vérifiée, export généré, file réduite ou synchronisation confirmée.
Définissez un seuil et une alerte raisonnables. Un événement horaire en retard de deux minutes n’a pas la même gravité qu’une commande non traitée depuis une journée.
Pour la sauvegarde, le succès d’une tâche n’est pas le succès d’une restauration. Le guide restaurer une sauvegarde WordPress explique pourquoi un test complet reste nécessaire.
Ordre de diagnostic recommandé
- Définir le résultat attendu et l’heure de référence.
- Lister la file en lecture seule.
- Vérifier présence, échéance, récurrence et éventuels doublons.
- Identifier le code propriétaire et ses dépendances.
- Contrôler la santé du déclenchement et de la boucle locale.
- Tester un seul hook dans un contexte sûr.
- Corréler l’appel avec journaux et effet métier.
- Corriger la cause, puis observer plusieurs cycles.
- Documenter le mécanisme de retour arrière.
Les erreurs à éviter
- Installer plusieurs extensions de contrôle sans diagnostic initial.
- Supprimer toute la file parce qu’un hook est en retard.
- Relancer une tâche non idempotente plusieurs fois.
- Désactiver WP-Cron avant que le remplaçant soit prouvé.
- Confondre fuseau horaire et retard réel.
- Publier des journaux, URL techniques ou commandes contenant des secrets.
- Déclarer le problème résolu sans vérifier l’effet attendu.
Checklist WP-Cron ne fonctionne pas
- [ ] Le hook et son propriétaire sont identifiés.
- [ ] L’heure WordPress et le fuseau sont notés.
- [ ] La prochaine exécution et la récurrence sont vérifiées.
- [ ] Les autres événements servent de comparaison.
- [ ] Les doublons éventuels sont expliqués avant suppression.
- [ ] Le test est limité et ses sorties externes sont neutralisées.
- [ ] L’erreur technique est corrélée à l’heure du test.
- [ ] Le résultat métier est confirmé.
- [ ] Le déclencheur de remplacement est testé avant bascule.
- [ ] Une surveillance et un retour arrière existent.
Conclusion
Quand WP-Cron ne fonctionne pas, augmenter la fréquence ou vider la file ne constitue pas un diagnostic. Vérifiez successivement l’existence de l’événement, son échéance, l’occasion de déclenchement et l’exécution réelle du hook.
Cette méthode transforme un symptôme flou en preuve reproductible. Elle protège aussi les données et les intégrations, car chaque test possède un périmètre, un contrôle du résultat et un retour arrière. Pour replacer cette maintenance dans un choix d’exploitation plus large, consultez le guide choisir un hébergement WordPress.