# WC_Queue_Interface : la file d’attente interne de WooCommerce

> Avant d'accrocher un traitement différé à WooCommerce, mieux vaut comprendre l'interface qui décide comment et quand ses propres tâches asynchrones s'exécutent.

- Auteur : WordPress Développement
- Publié le : 2022-11-23
- Mis à jour le : 2022-11-23
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/wc-queue-interface-file-attente-woocommerce/

## L’essentiel

- WC_Queue_Interface est une abstraction, pas une file physique
- L'implémentation par défaut délègue à Action Scheduler
- Un développeur d'extension peut s'y accrocher sans redévelopper de planificateur

Qu'est-ce qui se cache derrière l'expression « tâche planifiée » quand on l'utilise pour WooCommerce ? Beaucoup de développeurs d'extensions pensent immédiatement à Action Scheduler, la bibliothèque qui exécute effectivement ces tâches en tâche de fond. Mais WooCommerce n'appelle jamais Action Scheduler directement dans son cœur : il passe par une couche d'abstraction nommée `WC_Queue_Interface`, et cette distinction change la manière dont on doit y accrocher son propre code.

Comprendre cette interface avant d'y ajouter un traitement différé personnalisé évite un écueil courant : coder en dur une dépendance à Action Scheduler alors que WooCommerce prévoit justement de pouvoir le remplacer par un autre moteur sans casser le code des extensions qui l'utilisent correctement.

## Une interface, pas une implémentation

`WC_Queue_Interface` définit un contrat : des méthodes comme `add()`, `schedule_single()`, `schedule_recurring()` ou `cancel_all()`, sans imposer la manière dont ces tâches sont réellement stockées et exécutées. C'est la fonction `WC()->queue()` qui renvoie l'instance active de cette interface, quelle que soit son implémentation concrète.

```
WC()->queue()->add(
    'mon_extension_traitement_differe',
    array( 'commande_id' => $order_id ),
    'mon-extension'
);
```

Ce code ne sait rien, et n'a pas besoin de savoir, comment la tâche sera réellement exécutée en arrière-plan. C'est précisément ce découplage qui permet à WooCommerce de faire évoluer son moteur de tâches asynchrones sans casser des centaines d'extensions qui s'y accrochent.

## Ce que fait l'implémentation par défaut

Depuis plusieurs versions, l'implémentation fournie par défaut délègue effectivement à Action Scheduler, la bibliothèque également utilisée par des extensions comme WooCommerce Subscriptions pour les renouvellements récurrents. Chaque appel à `WC()->queue()->add()` se traduit, en coulisses, par un enregistrement dans les tables dédiées d'Action Scheduler, visibles dans l'administration sous « WooCommerce > État > Planification des tâches ».

> L'essentiel à retenir : WC_Queue_Interface est une abstraction, pas une file physique ; L'implémentation par défaut délègue à Action Scheduler ; Un développeur d'extension peut s'y accrocher sans redévelopper de planificateur

### Pourquoi cette indirection compte pour un développeur

Un développeur d'extension qui veut différer un traitement (recalcul d'un tarif, appel à une API externe après validation de commande, génération d'un rapport) n'a jamais intérêt à appeler directement les fonctions d'Action Scheduler comme `as_schedule_single_action()`. Passer par `WC()->queue()` garantit que le code continuera à fonctionner même si WooCommerce change un jour de moteur de file d'attente sous-jacent, ou si l'extension tourne sur une installation qui surcharge volontairement cette implémentation pour des raisons de performance.

## Les méthodes à connaître

- `add()` : ajoute une tâche à exécuter dès que possible par le prochain cycle du moteur sous-jacent.
- `schedule_single()` : planifie une tâche unique à un horodatage précis.
- `schedule_recurring()` : planifie une tâche récurrente à intervalle fixe.
- `cancel_all()` : annule toutes les tâches en attente correspondant à un hook et des arguments donnés.

## Limites à connaître

Cette abstraction ne dispense pas de comprendre le fonctionnement réel d'Action Scheduler pour du diagnostic fin — volume de tâches en attente, gestion des échecs répétés, fréquence réelle d'exécution du cron sous-jacent. Ces aspects opérationnels relèvent d'un sujet à part entière, déjà largement documenté ailleurs, et ne sont volontairement pas détaillés ici : l'objectif de cet article est de clarifier le rôle de l'interface, pas le fonctionnement interne de son implémentation par défaut.

> Accrocher un traitement différé directement à Action Scheduler plutôt qu'à `WC()->queue()`, c'est parier que WooCommerce ne changera jamais de moteur sous-jacent. Un pari qu'aucun développeur d'extension sérieux ne devrait prendre.

## À retenir

`WC_Queue_Interface` est une des abstractions les plus discrètes de WooCommerce, précisément parce qu'elle fonctionne bien et qu'on n'a que rarement besoin d'y penser. Mais dès qu'un développeur d'extension veut différer un traitement proprement, c'est cette interface qu'il doit cibler, et non l'implémentation qui se trouve derrière à un instant donné.