Action Scheduler : le moteur de tâches planifiées derrière WooCommerce

Beaucoup de développeurs WordPress connaissent bien le cron natif, basé sur wp_schedule_event() et la table wp_options. Peu réalisent que WooCommerce n’utilise ce mécanisme natif que de façon marginale : depuis plusieurs versions, la quasi-totalité des tâches différées de WooCommerce — envoi de webhooks, e-mails groupés, nettoyage de données, tâches de nombreuses extensions — passe par une bibliothèque à part entière nommée Action Scheduler. Ce billet explore son fonctionnement interne, sans entrer dans le détail des webhooks eux-mêmes, déjà traités par ailleurs.

Pourquoi WooCommerce n’utilise pas le cron natif tel quel

Le cron natif de WordPress souffre d’une limite connue : il stocke ses événements dans une seule ligne sérialisée de la table wp_options, ce qui devient un goulot d’étranglement dès que le volume de tâches planifiées grossit, et ne gère aucune notion de concurrence ni de reprise après échec. Action Scheduler, développé initialement pour Prospress puis intégré au cœur de WooCommerce, répond à ces limites avec une architecture pensée pour un volume de tâches bien plus élevé.

Une architecture appuyée sur des tables SQL dédiées

Action Scheduler ne stocke rien dans wp_options : il crée ses propres tables, notamment wp_actionscheduler_actions pour les actions elles-mêmes et wp_actionscheduler_logs pour leur historique d’exécution. Cette séparation permet d’indexer correctement les actions par statut, par date d’exécution prévue et par groupe, ce qui rend possible une interrogation rapide même avec plusieurs centaines de milliers d’actions enregistrées, une situation courante sur une boutique à fort volume après quelques années d’activité.

SELECT status, COUNT(*) AS total
FROM wp_actionscheduler_actions
GROUP BY status;

Trois façons de programmer une action

Action Scheduler expose une API simple, avec trois fonctions principales selon le besoin de programmation :

// Exécution en tâche de fond dès que possible.
as_enqueue_async_action( 'catalogue_reindexer_produit', array( $product_id ) );

// Exécution différée à une date précise.
as_schedule_single_action( strtotime( '+2 hours' ), 'catalogue_publier_promotion', array( $promo_id ) );

// Exécution récurrente, ici toutes les 30 minutes.
as_schedule_recurring_action(
    time(),
    30 * MINUTE_IN_SECONDS,
    'catalogue_verifier_stock_fournisseur',
    array(),
    'catalogue-sync'
);

Le dernier paramètre, le groupe, joue un rôle important en production : il permet de filtrer, surveiller et parfois mettre en pause un ensemble cohérent d’actions sans toucher aux autres, un détail précieux quand plusieurs extensions cohabitent sur la même boutique.

Le mécanisme de traitement par lots

Contrairement à une exécution immédiate, Action Scheduler traite ses actions par lots, déclenchés soit par une requête HTTP asynchrone dès qu’une page se charge sur le site, soit par un vrai cron serveur si celui-ci est configuré à la place du cron basé sur les visites. Un mécanisme de verrouillage empêche deux processus de traiter simultanément le même lot d’actions, ce qui évite qu’une action ne s’exécute deux fois en cas de charge concurrente élevée.

Ce qu’il faut savoir sur les échecs et les tentatives

• Une action qui lève une exception PHP non interceptée passe au statut failed, visible dans l’écran d’administration dédié.
• Action Scheduler ne relance pas automatiquement une action échouée : c’est au développeur de gérer, si besoin, sa propre logique de nouvelle tentative dans le code de l’action elle-même.
• Une action bloquée trop longtemps au statut in-progress, souvent à cause d’un appel réseau distant qui traîne, finit par être considérée comme abandonnée et repasse en attente.

La contrainte souvent oubliée : ça reste lié au cron WordPress

Une confusion fréquente chez les développeurs qui découvrent Action Scheduler : croire qu’il s’agit d’un vrai démon de traitement en arrière-plan, indépendant du trafic du site. Ce n’est vrai que si un cron serveur véritable a été configuré ; sinon, l’exécution reste dépendante des visites, exactement comme le cron natif de WordPress.

Sur un site à très faible trafic, sans configuration d’un cron serveur réel via DISABLE_WP_CRON et une tâche système wp cron event run --due-now, les actions planifiées peuvent s’accumuler simplement faute de visiteurs pour déclencher leur traitement, un phénomène qui explique de nombreux cas de tâches WooCommerce apparemment « en retard ».

Surveiller la santé de la file au quotidien

wp action-scheduler list --status=pending --per-page=5
wp action-scheduler list --status=failed --per-page=5

Ces deux commandes, exécutées régulièrement sur un site à fort volume, donnent une image fiable de la santé du système sans avoir à charger l’écran d’administration complet, plus lourd à générer quand la table contient un grand nombre d’entrées.

En résumé

Action Scheduler constitue une brique d’infrastructure discrète mais essentielle du fonctionnement de WooCommerce, pensée pour absorber un volume de tâches que le cron natif de WordPress ne pourrait pas gérer proprement. Comprendre sa logique de stockage en tables dédiées, son traitement par lots et sa dépendance au déclenchement du cron évite de nombreux diagnostics à l’aveugle face à une tâche qui semble « ne jamais s’exécuter ».