WordPress : fiabiliser WP-Cron pour éviter les tâches bloquées

Les tâches planifiées font fonctionner une partie discrète mais essentielle de WordPress. Publication différée, nettoyage de données temporaires, vérification des mises à jour, envoi d’e-mails, traitements d’extensions, renouvellements WooCommerce ou sauvegardes : beaucoup d’actions reposent sur le mécanisme interne appelé WP-Cron.

Le problème est que WP-Cron n’est pas un véritable ordonnanceur système. Son exécution dépend généralement des visites reçues par le site. Sur un site à faible trafic, un environnement de préproduction ou une boutique qui ne reçoit des commandes qu’à certains moments, une tâche peut donc être exécutée avec retard. Dans certains cas, elle peut sembler bloquée jusqu’au prochain passage d’un visiteur ou jusqu’à une intervention manuelle.

Fiabiliser WP-Cron consiste à auditer les événements existants, identifier les retards, déléguer le déclenchement à une tâche cron serveur et surveiller les processus qui comptent réellement pour l’activité du site. Cette démarche complète utilement une routine de maintenance WordPress hebdomadaire, particulièrement pour les sites e-commerce, éditoriaux ou professionnels.

Comprendre le fonctionnement réel de WP-Cron

Le terme « cron » peut prêter à confusion. Sur un serveur Linux ou Unix, cron est un service système capable d’exécuter une commande selon un calendrier précis. À l’inverse, WP-Cron est un système de planification applicatif intégré à WordPress. Il enregistre des événements dans la base de données et vérifie les tâches à exécuter lorsqu’une requête WordPress est déclenchée.

Par défaut, WordPress tente de lancer les tâches échues lors d’une visite sur le site. Concrètement, une requête vers une page publique peut provoquer un appel en arrière-plan vers le fichier wp-cron.php. WordPress exécute alors les événements dont l’horaire est arrivé.

Ce fonctionnement est pratique sur un petit site recevant un flux de visites régulier. Il évite de demander une configuration serveur immédiate. Mais il présente une limite fondamentale : l’heure planifiée est une échéance, pas une garantie d’exécution à la seconde près.

Une tâche prévue à 02 h 00 ne s’exécutera pas nécessairement à 02 h 00. Si aucune requête n’atteint WordPress avant 08 h 30, l’exécution peut être reportée à ce moment-là. Ce comportement est documenté dans la documentation officielle de WordPress sur WP-Cron.

Pourquoi WP-Cron échoue plus souvent sur les sites à faible trafic

Le faible trafic est la cause la plus fréquente des décalages, mais ce n’est pas la seule. Plusieurs situations réduisent la fiabilité de WP-Cron ou empêchent carrément son lancement.

Le site ne reçoit pas de requête au bon moment

Un site vitrine consulté ponctuellement, une intranet protégée par authentification ou un site de démonstration peuvent rester plusieurs heures sans visite. Les tâches planifiées pendant cet intervalle attendent alors la prochaine requête capable de déclencher WP-Cron.

Cette situation devient problématique lorsque WordPress gère :

• une publication à une date et une heure précises ;
• des sauvegardes quotidiennes lancées par une extension ;
• des e-mails transactionnels ou des rappels automatisés ;
• des opérations récurrentes de WooCommerce ;
• des contrôles de mises à jour du cœur, des thèmes ou des extensions ;
• des tâches de nettoyage de cache, de sessions ou de données expirées.

Les protections serveur bloquent l’appel à wp-cron.php

Un pare-feu applicatif, une règle de sécurité de l’hébergeur, une authentification HTTP, un plugin de sécurité ou une configuration restrictive peuvent empêcher l’appel interne ou externe à wp-cron.php. Un code HTTP d’erreur, une redirection inattendue ou un délai d’attente excessif peut suffire à compromettre l’exécution.

Les environnements de préproduction sont souvent concernés : ils peuvent être protégés par un mot de passe, limités à certaines adresses IP ou interdits aux robots. Une tâche cron serveur devra alors être configurée avec une méthode compatible avec cette protection.

Des tâches trop longues se chevauchent

Les sauvegardes, imports, exports, synchronisations avec un ERP, génération de flux produits ou envois massifs d’e-mails peuvent demander plus de ressources qu’une action WordPress habituelle. Si une exécution prend trop longtemps, elle risque d’atteindre les limites PHP ou serveur.

Le déclenchement fréquent de WP-Cron par les visiteurs peut aussi créer une charge inutile sur un site très fréquenté. Plusieurs requêtes peuvent tenter de lancer le processus, même si WordPress met en place des mécanismes pour limiter les chevauchements. Dans ce contexte, une tâche cron serveur unique et maîtrisée est généralement plus saine.

WP-Cron convient pour planifier des actions WordPress, mais il ne doit pas être considéré comme un outil d’ordonnancement précis sans déclencheur serveur fiable.

Repérer les tâches planifiées en retard ou bloquées

Un audit commence par l’observation. Il ne suffit pas de vérifier qu’une extension affiche « planifié » : il faut confirmer que les événements sont bien présents, que leur prochain passage est cohérent et qu’ils sont réellement exécutés.

Utiliser l’extension WP Crontrol avec prudence

WP Crontrol est une extension largement utilisée pour consulter les événements WP-Cron depuis l’administration WordPress. Elle permet notamment de visualiser les hooks enregistrés, leur récurrence, leur prochaine exécution et les arguments associés.

Dans son interface, recherchez en priorité :

• les événements dont la date de prochaine exécution est largement dépassée ;
• les tâches associées à une extension supprimée ou désactivée ;
• les récurrences inhabituelles ou très fréquentes ;
• les hooks liés aux sauvegardes, à WooCommerce, aux formulaires ou aux e-mails ;
• les événements qui échouent lorsqu’ils sont lancés manuellement.

Le lancement manuel est utile pour diagnostiquer, mais il ne constitue pas une solution durable. Une tâche qui échoue manuellement peut révéler une erreur PHP, un manque de mémoire, un problème d’accès distant ou une configuration incomplète de l’extension qui l’a créée.

Après l’audit, retirez WP Crontrol si vous ne l’utilisez pas en continu et si sa présence n’est pas justifiée par votre procédure d’administration. Comme toute extension, elle doit rester à jour et être intégrée à votre politique de maintenance.

Vérifier les événements depuis WP-CLI

Lorsque l’accès SSH est disponible, WP-CLI offre une méthode fiable pour examiner les tâches sans dépendre de l’interface d’administration. La commande suivante liste les événements enregistrés :

wp cron event list

Pour n’afficher que les événements arrivés à échéance, utilisez :

wp cron event list --due-now

Ces commandes doivent être lancées depuis le répertoire de l’installation WordPress, ou avec les options WP-CLI appropriées. Elles sont particulièrement utiles lorsqu’un problème empêche l’accès à l’administration ou lorsqu’un site géré ne doit pas recevoir d’extensions de diagnostic supplémentaires.

Pour approfondir ce type d’intervention, consultez notre guide sur les commandes WP-CLI indispensables.

Contrôler les symptômes fonctionnels, pas seulement la liste des cron

Un événement présent dans WP-Cron ne prouve pas que le besoin métier est satisfait. Vérifiez les effets concrets :

• la sauvegarde a-t-elle été créée à l’emplacement attendu ?
• un article programmé a-t-il été publié ?
• l’e-mail de commande WooCommerce est-il bien parti et reçu ?
• les renouvellements ou actions programmées sont-ils traités ?
• les mises à jour automatiques attendues ont-elles laissé une trace dans les journaux ?

Pour les boutiques WooCommerce, l’écran des actions planifiées est également important. WooCommerce s’appuie sur la bibliothèque Action Scheduler pour de nombreux traitements en arrière-plan. L’interface permet notamment de voir les actions terminées, en attente ou échouées. Une accumulation d’actions en attente mérite une analyse immédiate, surtout lorsqu’elle concerne les commandes, abonnements ou communications clients.

Préparer le remplacement de WP-Cron par une tâche cron serveur

La méthode recommandée pour rendre l’exécution plus régulière consiste à désactiver le déclenchement automatique de WP-Cron à chaque visite, puis à appeler WordPress depuis le planificateur du serveur. Cette organisation sépare le trafic public de la maintenance technique.

Avant toute modification, appliquez les précautions habituelles :

• vérifiez qu’une sauvegarde exploitable existe et que sa restauration a déjà été testée ;
• notez la configuration actuelle et les événements importants ;
• identifiez le chemin réel vers l’installation WordPress ;
• confirmez la version de PHP utilisable en ligne de commande ;
• prévoyez un contrôle après déploiement.

La qualité de la sauvegarde compte autant que sa fréquence. Si ce point n’est pas formalisé, suivez notre méthode pour tester une restauration WordPress sans risque.

Il faut aussi choisir une fréquence réaliste. Un intervalle de cinq minutes peut convenir à de nombreux sites ayant des tâches régulières. Une boutique active ou un site dont les traitements sont sensibles au délai peut nécessiter une fréquence plus courte, selon les ressources disponibles et les recommandations de l’hébergeur. À l’inverse, déclencher le cron chaque minute sans besoin identifié peut générer une charge inutile.

Désactiver le déclenchement automatique de WP-Cron

Ajoutez la constante suivante dans le fichier wp-config.php, avant la ligne indiquant d’arrêter les modifications :

define( 'DISABLE_WP_CRON', true );

Cette constante empêche WordPress de lancer WP-Cron lors des visites ordinaires. Elle ne désactive pas les événements planifiés eux-mêmes : elle supprime seulement leur déclenchement automatique via le trafic. C’est pourquoi elle doit être accompagnée d’une tâche cron serveur opérationnelle.

Ne laissez pas cette constante active sans planificateur alternatif. Sinon, les tâches resteront enregistrées mais ne seront plus exécutées automatiquement.

Évitez également de confondre DISABLE_WP_CRON et ALTERNATE_WP_CRON. Cette dernière constante propose un mécanisme de secours fondé sur une redirection lors du chargement des pages. Elle peut aider dans certains environnements, mais elle ne remplace pas la régularité d’un cron serveur et peut avoir des effets indésirables sur les requêtes web.

Configurer une vraie tâche cron serveur

La meilleure commande dépend de votre hébergement. Certains panneaux d’administration proposent une interface « Tâches cron » ; d’autres demandent de passer par SSH. Si vous disposez de WP-CLI, son utilisation est souvent la solution la plus explicite : elle lance directement les événements WordPress arrivés à échéance.

Option recommandée : exécuter les tâches avec WP-CLI

Voici le principe de la commande :

wp cron event run --due-now --path=/chemin/vers/wordpress --quiet

Le chemin doit correspondre au dossier qui contient les fichiers WordPress. Le binaire wp doit également être accessible pour l’utilisateur exécutant la tâche. Selon l’hébergeur, il faudra éventuellement fournir le chemin complet vers WP-CLI ou vers l’interpréteur PHP.

Dans une crontab Linux, une exécution toutes les cinq minutes suit cette structure :

*/5 * * * * wp cron event run --due-now --path=/chemin/vers/wordpress --quiet

Ne copiez pas ce chemin tel quel : remplacez-le par le chemin absolu réel de votre site. Testez d’abord la commande en SSH, puis consultez les éventuels messages d’erreur avant de la planifier.

Option alternative : appeler wp-cron.php avec PHP

Si WP-CLI n’est pas disponible, il est possible d’appeler le fichier WordPress directement avec PHP en ligne de commande :

/chemin/vers/php /chemin/vers/wordpress/wp-cron.php

La commande exacte dépend du chemin de l’exécutable PHP fourni par l’hébergement. Cette solution évite une requête HTTP et ne dépend pas d’un accès public à wp-cron.php. Elle reste néanmoins à tester, car les paramètres PHP disponibles en ligne de commande peuvent différer de ceux utilisés par le site web.

Option HTTP : utile, mais à vérifier soigneusement

Une tâche cron peut aussi appeler l’URL suivante avec curl ou wget :

https://www.votredomaine.fr/wp-cron.php?doing_wp_cron

Cette méthode est parfois la seule proposée par certains hébergeurs mutualisés. Elle doit toutefois être contrôlée avec attention : redirections entre les versions www et non-www, protection par mot de passe, filtrage WAF, règle anti-bot ou réponse HTTP non conforme peuvent empêcher l’exécution.

Quel que soit le choix retenu, ne conservez qu’un seul mécanisme principal de déclenchement. L’objectif est de maîtriser l’exécution, non de multiplier les appels concurrents.

Tester la configuration après la mise en place

La création de la tâche cron ne suffit pas. Un test opérationnel permet de confirmer que le serveur peut effectivement lancer les événements WordPress.

Suivez cette séquence :

• désactivez le déclenchement automatique avec DISABLE_WP_CRON ;
• exécutez manuellement la commande serveur choisie ;
• contrôlez les événements échus avec WP Crontrol ou wp cron event list --due-now ;
• attendez le prochain passage programmé ;
• vérifiez qu’aucune tâche critique ne reste en retard ;
• contrôlez les journaux de votre extension de sauvegarde, de votre outil d’e-mail ou de WooCommerce.

Après une mise à jour du cœur, d’un thème ou d’une extension importante, répétez ce contrôle. Une mise à jour peut modifier une intégration, changer le comportement d’un plugin ou faire apparaître une incompatibilité. Notre checklist de vérifications après la mise à jour d’un plugin ou d’un thème aide à intégrer ce contrôle dans un processus plus global.

Mettre en place une surveillance durable des tâches critiques

Une tâche cron fiable peut malgré tout échouer plus tard : quota disque atteint, modification de mot de passe SSH, changement de chemin PHP, erreur introduite par une extension ou incident chez un prestataire tiers. La surveillance doit donc porter sur les résultats attendus, pas uniquement sur la présence d’une ligne dans une crontab.

Définir les tâches à impact réel

Commencez par une courte liste de processus dont l’absence d’exécution aurait une conséquence concrète. Par exemple :

• la dernière sauvegarde réussie ;
• les e-mails de commande ou de réinitialisation de mot de passe ;
• les publications planifiées d’un média ou d’un blog ;
• les actions programmées WooCommerce ;
• les synchronisations avec un CRM, un outil de facturation ou un stock externe ;
• les traitements automatisés de formulaires.

Pour chaque tâche, documentez le propriétaire, la fréquence attendue, le moyen de vérification et la personne à prévenir en cas d’échec. Cette documentation est particulièrement utile dans le cadre d’un contrat de maintenance WordPress, où les responsabilités et délais d’intervention doivent être clairs.

Exploiter les journaux et les alertes disponibles

De nombreuses extensions de sauvegarde, solutions SMTP, plugins e-commerce et services externes proposent leurs propres journaux. Activez-les lorsque cela est pertinent, puis définissez une vérification périodique. Une sauvegarde affichée comme « terminée » mais non transférée vers son stockage distant ne protège pas le site.

Pour les e-mails WordPress, une extension SMTP peut fournir un journal ou un statut d’envoi selon sa configuration et son offre. Vérifiez aussi la réception réelle sur une boîte de test : un message accepté par WordPress ou un prestataire SMTP n’est pas toujours visible dans la boîte de réception finale.

Sur WooCommerce, surveillez les actions échouées et les actions en attente anormalement anciennes. Elles peuvent signaler un problème de cron, mais aussi une erreur propre à une passerelle de paiement, une extension d’abonnement ou une connexion API externe.

Prévoir un contrôle manuel régulier

Une fois le cron serveur installé, intégrez un contrôle synthétique à votre maintenance mensuelle :

• vérifier l’exécution récente des sauvegardes ;
• contrôler les tâches WP-Cron en retard ;
• examiner les actions WooCommerce échouées si la boutique est active ;
• consulter les erreurs PHP et les journaux de sécurité ;
• tester une action programmée non critique sur un environnement adapté.

Ce suivi rejoint les recommandations d’un plan de maintenance WordPress mensuel : une anomalie détectée tôt coûte généralement moins cher qu’une interruption constatée après plusieurs jours.

Conclusion : faire de WP-Cron un élément contrôlé de la maintenance

WP-Cron est utile, mais son déclenchement par les visites ne suffit pas pour les sites dont les tâches planifiées ont une importance opérationnelle. L’audit des événements, l’identification des traitements critiques et le remplacement du déclenchement automatique par une vraie tâche cron serveur améliorent nettement la régularité et la capacité de diagnostic.

La configuration doit ensuite être testée et surveillée dans le temps, en particulier après une mise à jour ou une modification d’hébergement. Si vos sauvegardes, e-mails transactionnels ou processus WooCommerce dépendent de WordPress, intégrez dès maintenant le contrôle de WP-Cron à votre routine de maintenance.