---
url : 'https://www.wpconsults.com/fr/wordpress-cron-job-alternatives/'
langue : 'fr'
titre : 'Comparaison des alternatives à WP-Cron : Cron du serveur, Action Scheduler et services externes'
auteur :
  nom : 'Abdullah Nouman'
  url : 'https://www.wpconsults.com/fr/author/nouman/'
date : '2026-07-14T06:00:00-05:00'
modifié : '2026-07-23T19:25:53-05:00'
type : 'article'
catégories :
  - ' SEO technique '
image : ' https://www.wpconsults.com/wp-content/uploads/2026/07/wordpress-cron-job-alternatives-compared-7892.avif '
publié : true
---

# Comparaison des alternatives à WP-Cron : Cron du serveur, Action Scheduler et services externes

WP-Cron ne fonctionne pas selon un horaire fixe. Il s'exécute à chaque chargement de page, ce qui explique pourquoi votre article programmé n'a pas été publié à l'heure prévue et pourquoi votre e-mail de renouvellement est arrivé avec trois heures de retard.

 

Tout le monde vous dira de le remplacer par un véritable cron de serveur. C’est souvent vrai, mais ce n’est pas toujours le cas ; c’est pourquoi cet article part de votre problème plutôt que de l’outil.

 

## Principaux enseignements

 

- WP-Cron est déclenché par le chargement des pages, et non par l'horloge système ; ainsi, un site à faible trafic ne respecte pas les horaires prévus, tandis qu'un site à fort trafic effectue cette vérification des milliers de fois par heure.
- La solution habituelle consiste à ajouter `define( 'DISABLE_WP_CRON', true );` dans `wp-config.php` ainsi qu’un véritable cron de serveur qui appelle `wp-cron.php` à intervalles réguliers.
- **Définissez la constante et oubliez le cron du serveur : toutes les tâches planifiées sur votre site s'arrêteront alors automatiquement.** La constante désactive le déclencheur, elle ne le remplace pas.
- Action Scheduler est une file d’attente, pas une horloge. Sa propre FAQ indique qu’il est lancé par défaut par WP-Cron et que les actions en retard sont normales ; il optimise donc le débit, et non la ponctualité.
- Les services Cron externes ne nécessitent aucun accès au serveur et permettent d’ajouter une fonctionnalité de surveillance, au prix d’un point de défaillance unique situé en dehors de votre site.
- Le WP-Cron par défaut convient parfaitement à la plupart des petits blogs. WordPress présente son comportement de mise en file d'attente et de nouvelle tentative comme une fonctionnalité, et c'en est effectivement une.

  Table des matières

- Pourquoi WP-Cron ne respecte-t-il pas son calendrier ?
- Partez du symptôme, pas de l'outil
- Comparaison entre le cron du serveur, Action Scheduler et les services externes
- Comment remplacer WP-Cron par un cron de serveur classique
- Action Scheduler est une file d'attente, pas une horloge
- Quels sont les avantages des services Cron externes, et quel est leur coût ?
- Qui n'a vraiment pas besoin de remplacer WP-Cron ?
- Ce que ce site héberge réellement, et pourquoi
- Alors, faut-il remplacer WP-Cron ?

 

## Pourquoi WP-Cron ne respecte-t-il pas son calendrier ?

 

WP-Cron ne se déclenche que lorsqu'un utilisateur charge une page. WordPress vérifie la liste des tâches à exécuter à chaque chargement de page et exécute celles qui sont en retard ; ainsi, si personne ne visite votre site entre 14 h et 17 h, la tâche que vous avez programmée pour 14 h sera exécutée à 17 h.

 

Ce n’est pas mon interprétation, c’est ce qu’indique la documentation de WordPress. Le chapitre consacré au cron dans le « Plugin Handbook » l'explique clairement : **“ WP-Cron ne s'exécute pas en continu comme le cron système ; il n'est déclenché qu'au chargement de la page. ”**, et cela correspond presque exactement à cet exemple de 14 h.

 

C’est donc le nom qui pose problème. Ça s’appelle « cron » et ça fonctionne comme une liste de tâches à effectuer que l’on consulte chaque fois que l’on passe devant.

 

Le problème se pose dans les deux sens, ce que la plupart des guides omettent de mentionner. Un site peu fréquenté ne respecte pas ses délais, tandis qu’un site très fréquenté effectue la même vérification pour chaque requête, ce qui, selon la [documentation de WP Engine](https://wpengine.com/support/wp-cron-wordpress-scheduling/), “ oblige le serveur à fournir un effort plus important que nécessaire et peut entraîner des ralentissements, des délais d’expiration et d’autres problèmes de performances ”.

 

## Partez du symptôme, pas de l'outil

 

Chaque symptôme nécessite une solution adaptée, et c’est souvent en choisissant l’outil avant tout que l’on finit par utiliser un service cron externe pour envoyer des requêtes à un site dont le véritable problème était une table ” actions « surchargée. Repérez votre symptôme dans ce tableau, puis consultez la section correspondante.

 

| Ce que vous voyez | Qu’est-ce qui ne va pas, au juste ? | Comment y remédier ? |
| --- | --- | --- |
| Un article programmé s’affiche **» En retard par rapport au calendrier prévu “** | Personne ne consultait la page au moment où la publication devait avoir lieu | Un véritable cron de serveur, de sorte que le déclenchement s’arrête en fonction du nombre de visiteurs |
| Les e-mails et les rappels de renouvellement de WooCommerce arrivent en retard | Même problème de déclenchement, mais sur une file d’attente plus importante | Cron du serveur, et vérification dans Action Scheduler des tâches bloquées |
| Des milliers de lignes dans `wp_actionscheduler_actions` | Un problème de débit, et non un problème de synchronisation | Optimisation et nettoyage du planificateur d’actions, et non création d’un nouveau déclencheur |
| Votre site reçoit très peu de visiteurs | Le déclencheur ne se déclenche pas assez souvent pour être fiable | Cron du serveur ou service cron externe |
| Trafic intense et TTFB lent en cas de charge élevée | La vérification cron s’exécute à chaque requête | `DISABLE_WP_CRON` ainsi qu’une tâche cron sur le serveur à intervalle fixe |
| En réalité, rien n’est cassé | Rien | Laissez tomber. Vraiment. |

Associez le symptôme à la cause avant de choisir un outil, car deux de ces problèmes ne sont absolument pas liés au calage. 

Remarquez combien peu de ces lignes indiquent ” remplacer WP-Cron “. C’est un choix délibéré, et c’est sur ce point que je ne suis pas d’accord avec les conseils que vous trouverez en tête des résultats de recherche.

 ![Présentation de l’IA de Google concernant les alternatives aux tâches cron de WordPress, recommandant une véritable tâche cron côté serveur](https://www.wpconsults.com/wp-content/uploads/2026/07/wordpress-cron-job-alternatives-serp-ai-overview-7899.avif) En recherchant cette expression, on obtient une seule et même recommandation générale : la remplacer par une tâche cron côté serveur. Capture d'écran réalisée depuis les États-Unis, le 14 juillet 2026, alors que l'utilisateur n'était pas connecté. Aucune publicité n'apparaissait sur cette page de résultats de recherche (SERP) ; tous les résultats qui y figuraient étaient donc naturels. 

## Comparaison entre le cron côté serveur, Action Scheduler et les services externes

 

Ces trois éléments ne sont pas concurrents, et les considérer comme une liste restreinte constitue la première erreur. Un cron côté serveur remplace le déclencheur, Action Scheduler gère une file d'attente de tâches, et un service externe remplace le déclencheur depuis l'extérieur de votre serveur.

 

|  | Cron du serveur réel | Planificateur d'actions | Service Cron externe |
| --- | --- | --- | --- |
| **Ce que cela fait réellement** | Appels à `wp-cron.php` via l'horloge système | Files d'attente, lots, tentatives de reprise et journaux des tâches en arrière-plan | Appels à `wp-cron.php` depuis un autre serveur |
| **Cela résout-il le problème de ponctualité ?** | Oui | Non. Il hérite par défaut du déclencheur de WP-Cron. | Oui |
| **Cela améliore-t-il le débit ?** | Non | Oui, c’est justement son rôle | Non |
| **Faut-il un accès au serveur ?** | Oui, via crontab ou un panneau de configuration | Non, il est intégré à WooCommerce et à d’autres plateformes | Non |
| **Risque principal** | Vous définissez la constante et n’avez plus à vous soucier du cron | Le considérer comme une solution au problème de planification | Un point de défaillance unique sur lequel vous n’avez aucun contrôle |
| **Idéal pour** | Horaires de publication fixes, renouvellements, sites à faible fréquentation | Boutiques comportant des milliers de tâches en file d'attente | Hébergement géré sans accès au cron |

Ces trois options répondent à des problèmes différents ; pour faire une comparaison objective, il faut donc se demander quel est votre problème, et non pas quel outil est le meilleur. 

Pour vérifier ce qui est réellement programmé sur votre site, WP Crontrol est le plugin de référence, et WP-CLI vous fournit la même liste avec ” Liste des événements WP Cron “. Vérifiez bien avant de modifier quoi que ce soit.

 

## Comment remplacer WP-Cron par un cron de serveur classique

 

Il y a deux étapes : désactiver le déclencheur de chargement de page, puis configurer l'horloge système pour qu'elle appelle ce même fichier à intervalles réguliers. Effectuez la deuxième étape, sinon votre site cessera discrètement d’exécuter toutes les tâches planifiées.

 

**Étape 1.** Ajoutez ceci dans le fichier `wp-config.php`, au-dessus de la ligne indiquant ” C'est tout, arrêtez de modifier ' :

 

```
define( 'DISABLE_WP_CRON“, true );
```

 

**Étape 2.** Créez une véritable tâche cron sur le serveur, soit via le panneau de configuration de votre hébergeur, soit dans le fichier crontab. Une fréquence de cinq minutes constitue un réglage par défaut raisonnable :

 

```
*/5 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
```

 

Et maintenant, le plus important : il s'agit du type de défaillance dont personne ne vous met en garde. `DISABLE_WP_CRON` Cela ne désactive pas la planification, mais désactive le **déclencheur**.

 

Vos événements sont toujours en attente dans la base de données, attendant leur tour. Aucun processus ne vient les exécuter. Par conséquent, les articles ne sont pas publiés, les e-mails ne sont pas envoyés, les sauvegardes ne se lancent pas, et WordPress ne signale aucune erreur, car de son point de vue, la file d’attente n’est tout simplement pas sollicitée.

 

Une dernière mise en garde si vous utilisez un hébergement géré. La documentation de WP Engine indique qu’il [ne prend techniquement pas en charge les véritables tâches cron côté serveur](https://wpengine.com/support/wp-cron-wordpress-scheduling/) et propose à la place un service Cron alternatif qui appelle `wp-cron.php` pour vous, ce qui nécessite la même constante. Ainsi, ” il suffit d'utiliser crontab “ n’est même pas littéralement possible sur certains serveurs, et les guides qui le préconisent ne le mentionnent jamais.

 

## Action Scheduler est une file d’attente, pas une horloge

 

Action Scheduler ne garantira pas la ponctualité de vos tâches, car il ne contrôle pas le déclencheur. Sa [FAQ interne](https://actionscheduler.org/faq/) précise qu’il ” est lancé par WP-Cron “ par défaut et qu’il est ” conçu pour fonctionner en parallèle avec WP-Cron sans en modifier le comportement «, et indique que les actions en retard sont normales.

 

Relisez bien cela, car on le présente régulièrement comme la solution miracle aux retards dans les projets. Or, il hérite précisément du problème qu’il est censé résoudre.

 

Je préfère vous le montrer directement sur notre site plutôt que d’en discuter. La section » État du site « de WordPress indique ici qu’une tâche planifiée est en retard, et la tâche en question est : `action_scheduler_run_queue`, qui correspond à l’événement WP-Cron chargé d’exécuter la file d’attente d’Action Scheduler.

 ![Le rapport » Santé du site WordPress « signale qu’un événement planifié est en retard, en mentionnant la file d’attente d’exécution d’Action Scheduler](https://www.wpconsults.com/wp-content/uploads/2026/07/wordpress-site-health-scheduled-event-is-late-7897.avif)» Santé du site « sur wpconsults.com, 14 juillet 2026. Le processus chargé de vider la file d'attente de l'Action Scheduler est lui-même un événement WP-Cron différé. 

Alors, à quoi sert l'Action Scheduler ? Au traitement de gros volumes. Il regroupe les tâches par lots, effectue des tentatives de réexécution, consigne les opérations dans un journal et met à votre disposition un écran d’administration, tout en stockant toutes les données dans ses propres tables `actionscheduler_` plutôt que de tout regrouper dans `wp_options`.

 

Voici à quoi cela ressemble dans une boutique en ligne réelle. Notre site a enregistré 1 697 actions, dont 1 565 menées à bien et **123 ont échoué**, et je n’aurais pas su que ces erreurs existaient si je n’avais pas ouvert cet écran.

 ![Écran d'administration de l'Action Scheduler affichant les actions planifiées en attente et le nombre d'actions ayant échoué](https://www.wpconsults.com/wp-content/uploads/2026/07/action-scheduler-pending-actions-screen-7898.avif)Outils, puis » Actions programmées “ sur notre propre site. Le nombre d'échecs correspond au nombre de sites à vérifier parmi toutes les boutiques utilisant WooCommerce ou Easy Digital Downloads. 

Voici un résumé honnête de cet outil. Il est excellent pour gérer des milliers de tâches, mais ce n’est pas la solution à choisir lorsque votre reproche est : ” Ça aurait dû être fait à 3 h 10 du matin. «

 

## Quels sont les avantages des services Cron externes, et quel est leur coût ?

 

Un service Cron externe appelle votre `wp-cron.php` depuis un autre site Internet, selon un calendrier fixe. Vous n’avez absolument pas besoin d’accéder au serveur, et vous bénéficiez généralement d’une surveillance et d’alertes, ce qu’une ligne de crontab ne vous offrira jamais.

 

En contrepartie, le cœur de votre site se trouve désormais en dehors de celui-ci. Si le service tombe en panne, si votre compte expire ou si la connexion vers votre serveur est interrompue, le déclencheur disparaît et rien sur votre serveur ne s’en rend compte, car aucun élément de votre serveur ne surveillait cette connexion.

 

C’est mon raisonnement, et non une faille avérée dont quelqu’un aurait fait état ; j’opterais tout de même pour cette solution sur un hébergement géré sans accès à cron. La surveillance a une certaine valeur, et il vaut mieux être alerté d’un déclencheur manquant que de le découvrir une semaine plus tard.

 

## Qui n’a vraiment pas besoin de remplacer WP-Cron ?

 

Si votre site n’implique aucune contrainte liée à des horaires fixes, WP-Cron convient parfaitement et vous pouvez arrêter de lire. Un blog qui publie dès que vous cliquez sur » Publier “, sans boutique en ligne, sans renouvellements et sans e-mails urgents, n’a rien à perdre si une tâche de nettoyage s’exécute à 17 h au lieu de 14 h.

 

WordPress le précise lui-même, et c'est justement la citation que les partisans du ” il faut toujours le remplacer “ ne vous montrent jamais. Extrait du même chapitre du manuel :

 

> Avec le planificateur système, si le délai s'écoule sans que la tâche ait été exécutée, celle-ci ne sera pas relancée. Avec WP-Cron, toutes les tâches planifiées sont placées dans une file d'attente et s'exécuteront dès que possible (c'est-à-dire au prochain chargement de la page). Ainsi, même si vous ne pouvez pas être sûr à 100% *quand* votre tâche s'exécutera, vous pouvez être sûr à 100% qu'elle s'exécutera *finalement*.

 

C’est un véritable compromis de conception, pour le dire sans détours. Un système cron qui se déclenche alors que votre site rencontre une erreur saute tout simplement cette exécution et passe à la suivante, tandis que WP-Cron conserve la tâche dans la file d’attente et la réessaie dès que l’occasion se présente.

 

Aucun des deux modèles n’est meilleur en théorie ; ils présentent chacun leurs propres failles. Vous devez choisir entre ” ça fonctionnera, mais je ne sais pas exactement quand “ et ” ça fonctionnera à 3 h 10 du matin, ou ça ne fonctionnera pas du tout ”.

 

Il est également intéressant de noter à qui profitent ces conseils généraux. Ce sont principalement les hébergeurs et les fournisseurs de solutions de surveillance par cron qui les diffusent, et les principes qu’ils vous exposent sont corrects. C’est le mot “ toujours ” que je remettrais en question.

 

## Ce que ce site héberge réellement, et pourquoi

 

Nous sommes résolument partisans de l’idée que “ le timing est essentiel ”, c’est pourquoi nous utilisons un déclencheur côté serveur. Ce blog publie à des horaires fixes, et deux articles ont été mis en ligne cette semaine exactement à l’heure prévue, l’un à 3 h 10 du matin et l’autre à 15 h 30, heure de Dacca, alors que mon ordinateur était éteint et que je dormais.

 

Cela ne fonctionne que parce que le déclencheur ne dépend pas du fait qu’un visiteur arrive justement à 3 h 10 du matin. Presque personne ne consulte un blog consacré au référencement à cette heure-là, ce qui correspond exactement au cas d’échec lié à un faible trafic présenté dans le tableau ci-dessus.

 

Notre hébergeur est [Hostinger](https://www.wpconsults.com/fr/shared-hosting-hostinger/), et comme la plupart des hébergeurs, il propose un écran dédié aux tâches Cron dans le panneau d’administration ; la configuration se résume donc aux deux étapes ci-dessus, rien de plus compliqué que ça.

 

L'histoire de cette « guerre » qui nous a menés là où nous en sommes mérite d'être lue si vous vendez quoi que ce soit : j'ai décrit le cas précis où les e-mails et les renouvellements de WooCommerce arrivaient en retard et [La mise en place d'une véritable tâche Cron a permis de résoudre le problème](https://www.wpconsults.com/fr/correction-des-emails-manquants-de-woocommerce-et-des-renouvellements-retardes-mise-en-place-dun-vrai-job-cron/). Cet article présente la version générale de cette correction.

 

Il y a une distinction qu’il convient de bien garder à l’esprit lorsque vous consultez ce site : un e-mail envoyé en retard est un problème de *planification*, tandis qu’un e-mail qui n’arrive jamais est généralement un problème de *livraison*, dont la solution est tout à fait différente. Si vous ne savez pas de quel problème il s’agit, vérifiez si vos e-mails parviennent à quitter le serveur en [configurant correctement le protocole SMTP](https://www.wpconsults.com/fr/configurer-smtp-manuellement-dans-wordpress-2/) Tout d’abord.

 

Et si ce sujet vous intéresse davantage pour des raisons de charge du serveur que de temps de chargement, sachez que le surcoût lié au chargement de la page est bien réel mais minime, et qu’il est rarement la cause réelle du ralentissement. J’ai déjà rédigé un article sur ce qui fait véritablement la différence lorsqu’[un site WordPress doit pouvoir gérer un trafic important](https://www.wpconsults.com/fr/un-site-wordpress-peut-il-gerer-1-million-de-visiteurs/), ainsi que sur [l’INP et la réactivité](https://www.wpconsults.com/fr/inp-wordpress/) en ce qui concerne le front-end.

 

## Alors, faut-il remplacer WP-Cron ?

 

Si une action doit se produire à un moment précis sur votre site, alors oui, faites-le dès aujourd’hui. Les publications programmées, les renouvellements d’abonnement, les e-mails transactionnels et les sauvegardes nocturnes méritent tous un déclencheur qui ne dépende pas du fait qu’un inconnu charge votre page d’accueil.

 

Si aucun élément de votre site n’est soumis à une échéance, ne touchez à rien. Vous ne feriez qu’ajouter un élément supplémentaire et une nouvelle source d’erreur, en échange d’une ponctualité dont vous ne vous souciez pas.

 

Et s’il y a une chose à retenir de tout cela : lorsque vous définissez cette constante, assurez-vous que la tâche cron du serveur s’exécute bien avant de fermer le terminal. Un site avec `DISABLE_WP_CRON` et aucune tâche cron ne semble fonctionner parfaitement jusqu’au jour où l’on se rend compte que rien n’a été publié depuis une semaine.

  

### Les tâches planifiées continuent-elles à s'exécuter en retard ?

 

Si, après cela, l'heure n'apparaît toujours pas sur vos publications, vos e-mails ou vos renouvellements, [contactez-nous](https://www.wpconsults.com/fr/travailler-avec-wpconsults/) ou [envoyez-moi un e-mail](mailto:abdullah@wpconsults.com) et je vous aiderai à déterminer lequel de ces trois problèmes est réellement le vôtre.