Une marketplace B2B de pièces industrielles synchronise en continu son catalogue avec les flux de plusieurs centaines de fournisseurs, chacun poussant des mises à jour de stock et de prix à des fréquences variables. Le volume total de tâches de synchronisation à traiter pouvait dépasser 50 000 par jour lors des pics, avec des pointes ponctuelles nécessitant un débit de traitement bien supérieur à la moyenne. Cet article compare deux approches réellement mises en œuvre sur ce projet à des périodes différentes : Action Scheduler, la bibliothèque native de gestion de tâches en arrière-plan de WooCommerce, puis une file d’attente Redis dédiée, développée en interne après que les limites de la première approche sont devenues bloquantes.
Action Scheduler : simple à mettre en place, limité en débit
Action Scheduler stocke ses tâches sous forme de contenus personnalisés (scheduled-action) dans la table wp_posts, et s’appuie sur wp-cron pour déclencher leur traitement à intervalle régulier, ou sur un traitement asynchrone via une requête HTTP interne déclenchée dès qu’une tâche est planifiée. Cette approche a l’avantage de ne nécessiter aucune infrastructure supplémentaire : elle fonctionne avec la seule base de données MySQL déjà en place.
as_schedule_single_action(
time(),
'synchroniser_flux_fournisseur',
[ 'id_fournisseur' => $id_fournisseur ],
'synchro-fournisseurs'
);
Sur ce projet, mesuré en conditions réelles de production, Action Scheduler traitait en moyenne 40 tâches par minute avec la configuration par défaut (trois lots de traitement en parallèle), un débit largement suffisant pour l’usage courant mais qui devenait un goulot d’étranglement lors des pics, où la file d’attente pouvait accumuler plusieurs milliers de tâches en retard, avec un délai de traitement dépassant parfois deux heures avant que le catalogue ne soit entièrement à jour.
Pourquoi ce plafond de débit
Deux facteurs limitent structurellement le débit d’Action Scheduler : chaque tâche traitée passe par un cycle complet de chargement de WordPress (le traitement se fait via une requête HTTP interne vers admin-ajax.php, avec tout le poids que cela implique), et l’accès concurrent à la table wp_posts pour marquer les tâches comme traitées introduit un verrouillage qui limite le parallélisme réel, même en augmentant le nombre de lots configurés au-delà de la valeur par défaut.
La file Redis dédiée
La file d’attente développée en interne s’appuie sur la structure de liste native de Redis (LPUSH / BRPOP), avec un pool de processus PHP en ligne de commande dédiés (lancés via supervisord, en dehors du cycle de requête web WordPress), qui consomment la file en continu plutôt que par intervalle de polling.
# Empilement d'une tâche (côté WordPress, appel PHP classique)
$redis->lpush( 'file_synchro_fournisseurs', wp_json_encode( [
'id_fournisseur' => $id_fournisseur,
'horodatage' => time(),
] ) );
// worker.php, exécuté en continu par supervisord (5 processus en parallèle)
while ( true ) {
$tache = $redis->brpop( 'file_synchro_fournisseurs', 5 );
if ( ! $tache ) {
continue;
}
$donnees = json_decode( $tache[1], true );
require_once '/var/www/marketplace/wp-load.php';
synchroniser_flux_fournisseur( $donnees['id_fournisseur'] );
}
Résultat mesuré
| Critère | Action Scheduler | File Redis dédiée |
|---|---|---|
| Débit en conditions normales | 40 tâches/min | 1 800 tâches/min (5 workers) |
| Infrastructure requise | Aucune (MySQL déjà en place) | Serveur Redis + supervision de workers dédiés |
| Visibilité / interface d’administration | Intégrée à WooCommerce, native | À construire soi-même (tableau de bord maison) |
| Résilience en cas de panne | Reprend au redémarrage de wp-cron | Dépend de la persistance Redis configurée (AOF/RDB) |
Le compromis sur la visibilité
Le passage à la file Redis a fait perdre à l’équipe l’interface d’administration native d’Action Scheduler, qui permet de voir en un coup d’œil les tâches en attente, en échec ou terminées directement depuis l’espace d’administration WordPress. Un tableau de bord maison, plus sommaire, a dû être développé pour retrouver un minimum de cette visibilité, ce qui représente un coût de développement et de maintenance supplémentaire à mettre en balance avec le gain de débit.
Le débit d’une file d’attente ne vaut rien si personne dans l’équipe ne peut plus voir, d’un coup d’œil, ce qui s’y accumule et pourquoi.
Quand faire ce choix
- Rester sur Action Scheduler tant que le volume de tâches par minute reste dans un ordre de grandeur de quelques dizaines, où sa simplicité l’emporte largement sur son plafond de débit.
- Envisager une file dédiée uniquement quand des mesures réelles en production, pas une anticipation théorique, montrent que ce plafond est régulièrement atteint.
- Budgétiser dès le départ le coût de reconstruction de la visibilité perdue en abandonnant l’interface native.
Hors périmètre
Ce comparatif ne traite pas les files d’attente dédiées aux appels vers des API d’intelligence artificielle, dont les contraintes (limites de débit imposées par le fournisseur, coût par appel) diffèrent suffisamment pour mériter un traitement séparé, déjà couvert ailleurs.
