Action Scheduler 4.0.0 : ce qui change pour votre boutique WooCommerce

Si votre boutique WooCommerce ralentit sans raison évidente et que votre base de données enfle mois après mois, il y a de fortes chances qu’Action Scheduler en soit partiellement responsable. C’est le composant qui exécute en arrière-plan les paiements d’abonnements, les webhooks, les emails et une foule d’autres tâches différées. Discret, mais ses tables sont devenues parmi les plus volumineuses de beaucoup de bases WooCommerce.

La version 4.0.0 vient corriger ce problème de fond. Elle est disponible sur WordPress.org et sera embarquée avec WooCommerce 11.0, prévu pour le 28 juillet 2026. Comme certains changements sont volontairement incompatibles avec l’ancien comportement (breaking changes), c’est le bon moment pour comprendre ce qui arrive et tester votre site avant la mise à jour.

C’est quoi Action Scheduler, déjà ?

Action Scheduler est une file d’attente de tâches pour WordPress. Pensez-y comme à une extension de do_action() capable de différer et de répéter l’exécution d’un hook. Chaque tâche est enregistrée dans des tables dédiées (wp_actionscheduler_actions et wp_actionscheduler_logs), exécutée au bon moment, puis marquée comme terminée, annulée ou échouée.

Sur une boutique active, ça représente énormément d’écritures. D’après la documentation officielle, Action Scheduler traite chaque mois des millions de paiements pour WooCommerce Subscriptions et a déjà été observé en train d’écouler des files de plus de 50 000 tâches à un rythme soutenu de plus de 10 000 par heure (source : readme 4.0.0). Multipliez ça par des mois d’historique conservé en base, et vous comprenez pourquoi ces tables gonflent. Ce ne sont d’ailleurs pas les seules à enfler ainsi : les options autochargées de votre base WordPress jouent souvent le même rôle silencieux sur les performances.

Pourquoi sauter directement à la 4.0.0 ?

Vous remarquerez qu’on passe de la 3.9.3 à la 4.0.0, sans 3.10. C’est normal : Action Scheduler suit le versionnage façon WordPress, où il n’y a pas de 3.10 après 3.9. Plutôt que de livrer des changements cassants sous un numéro anodin comme 3.9.4, l’équipe a bumpé en 4.0.0 pour les signaler clairement. Le numéro de version est lui-même un avertissement.

Changement n°1 : les actions échouées sont enfin purgées

C’est le correctif le plus important pour la santé de votre base.

Jusqu’ici, Action Scheduler nettoyait automatiquement les actions terminées et annulées, mais jamais les actions échouées. Elles s’accumulaient indéfiniment, avec leurs logs. Sur une boutique à fort volume, ça signifiait des tables qui grossissaient sans limite et ne se réparaient jamais d’elles-mêmes.

À partir de la 4.0.0, les actions échouées sont supprimées automatiquement une fois qu’elles ont plus de 3 mois. Ce délai n’est pas arbitraire : il correspond à un cycle comptable trimestriel et vous laisse une fenêtre raisonnable pour investiguer les échecs, tout en bornant la croissance des tables.

Concrètement, si vous n’avez jamais fait de maintenance sur ces tables, attendez-vous à un nettoyage notable après la mise à jour. C’est une bonne nouvelle, mais si vous aviez besoin de conserver l’historique des échecs plus longtemps (audit, conformité), vous pouvez ajuster ou désactiver ce comportement :

// Allonger la fenêtre de rétention des actions échouées (en secondes).
add_filter(
	'action_scheduler_retention_period_for_failed',
	function () {
		return 6 * MONTH_IN_SECONDS;
	}
);

// Ou revenir au comportement d'avant la 4.0.0 : ne jamais purger les actions échouées.
add_filter( 'action_scheduler_enable_failed_action_cleanup', '__return_false' );

À noter : si vous utilisiez déjà le filtre action_scheduler_default_cleaner_statuses pour inclure les actions échouées dans le nettoyage, votre réglage reste prioritaire et continue de s’appliquer comme avant.

Changement n°2 : les actions « uniques » tiennent compte des arguments

Celui-ci est plus subtil, mais peut changer le comportement de votre code si vous (ou un de vos plugins) planifiez des tâches uniques.

Les fonctions comme as_enqueue_async_action() et as_schedule_*_action() acceptent un paramètre $unique. Quand il vaut true, Action Scheduler refuse de créer une nouvelle action si une action équivalente est déjà en attente ou en cours.

Le piège, avant la 4.0.0 : « équivalente » voulait dire même hook et même groupe, sans regarder les arguments. Deux tâches avec le même hook mais des arguments différents se bloquaient mutuellement. La seconde était silencieusement abandonnée, alors qu’elle concernait peut-être un travail tout à fait différent (une autre commande, un autre client…).

En 4.0.0, la vérification d’unicité inclut les arguments. Seule une action véritablement identique (même hook, même groupe et mêmes arguments) compte désormais comme un doublon.

Si du code chez vous reposait sur l’ancienne deduplication « hook + groupe » pour éviter des exécutions multiples, attendez-vous à voir plus d’actions créées qu’avant. Relisez attentivement ce code avant la mise à jour : c’est le changement le plus susceptible de provoquer un comportement inattendu (doubles emails, doubles synchronisations, etc.).

Changement n°3 : le nettoyage devient une tâche quotidienne dédiée

Avant, la suppression des vieilles actions se faisait au fil de l’eau, par petites tranches, à chaque lot traité par la file. Sur les boutiques à fort volume, ce nettoyage prenait souvent du retard et n’arrivait jamais à rattraper l’accumulation.

En 4.0.0, le nettoyage devient une tâche à part entière qui s’exécute une fois par jour à 3 h du matin (heure du site), supprime par lots plus larges (au moins 250 par passage) et continue jusqu’à résorber le retard. Le ménage est sorti du chemin de traitement des tâches, ce qui lui permet enfin de rattraper son retard, même sur de grosses tables.

La taille des lots reste personnalisable :

add_filter(
	'action_scheduler_cleanup_batch_size',
	function ( $size ) {
		return 500;
	}
);

Ce changement n’est pas à proprement parler cassant, mais il modifie quand le nettoyage a lieu. Si vous aviez impérativement besoin d’un nettoyage inline à chaque lot comme avant, il faut fournir un queue cleaner personnalisé : dès qu’Action Scheduler détecte un cleaner autre que son ActionScheduler_QueueCleaner natif, il repasse en mode inline. La plupart des sites n’en auront pas besoin.

Les autres améliorations utiles

Le changelog complet contient d’autres correctifs intéressants côté performance et robustesse :

Actions corrompues auto-annulées : les actions dont les données sont corrompues sont automatiquement annulées dès leur détection, et leurs logs excédentaires nettoyés par lots. Cela évite que la file ne se bloque et que la table des logs n’explose.
Requête get_claim_count() optimisée pour les grosses boutiques.
SKIP LOCKED lors de la réservation des actions (depuis la 3.9.3), qui réduit les conflits de verrous quand plusieurs processus traitent la file en parallèle.
Correctif d’une erreur fatale liée à la classe WP_CLI, et divers correctifs d’affichage dans la liste des actions planifiées.

Côté prérequis : la 4.0.0 exige désormais WordPress 6.8 minimum et est déclarée compatible jusqu’à WordPress 7.0.

Faut-il agir, et comment ?

Pour la grande majorité des boutiques, la 4.0.0 est une excellente nouvelle : moins de bloat en base, un nettoyage qui tient enfin la cadence, le tout sans rien faire. Cela dit, alléger ces tables ne remplace pas une optimisation WooCommerce de fond, pas plus qu’un plugin de cache ne compense une base lourde. Voici donc ce que je vérifie avant de laisser passer la mise à jour sur un site client :

D’abord, regardez la taille de vos tables Action Scheduler dès maintenant. Cette requête vous donne le poids des tables et le nombre de lignes (adaptez le préfixe wp_ si le vôtre diffère). Exécutez-la depuis votre client SQL habituel ou, plus commodément sur un serveur, en ligne de commande avec WP-CLI :

SELECT
	table_name AS 'Table',
	table_rows AS 'Lignes',
	ROUND((data_length + index_length) / 1024 / 1024, 1) AS 'Taille (Mo)'
FROM information_schema.tables
WHERE table_schema = DATABASE()
	AND table_name LIKE '%actionscheduler%'
ORDER BY (data_length + index_length) DESC;

Et celle-ci compte vos actions par statut, pour repérer une accumulation d’échecs :

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

Si wp_actionscheduler_actions ou wp_actionscheduler_logs pèsent plusieurs centaines de mégaoctets, ou si la ligne failed se compte en dizaines de milliers, vous avez un historique d’échecs non purgés. La première exécution du nouveau nettoyage va faire du ménage — ce qui est souhaitable, mais à anticiper sur une grosse base (sauvegarde préalable, et idéalement un lancement hors heures de pointe).

Ensuite, inventoriez votre code et vos plugins qui utilisent $unique = true. Si la deduplication par hook seul était (volontairement ou non) un garde-fou contre des exécutions multiples, le passage à la deduplication par arguments peut faire apparaître des doublons. C’est le point qui mérite le plus d’attention.

Enfin, testez sur un environnement de préproduction avant de mettre à jour en production, surtout si vous utilisez WooCommerce Subscriptions ou des extensions lourdes en tâches de fond. Et si vous embarquez vous-même Action Scheduler dans une extension, c’est le moment de la tester contre la 4.0.0 et de remonter tout comportement anormal sur GitHub.

Vous ne savez pas combien pèsent vos tables Action Scheduler, ni si du code chez vous dépend de l’ancien comportement ? Demandez un audit gratuit — l’état des tables et des tâches de fond fait partie des premières choses que je vérifie sur une boutique WooCommerce.