# Comparatif des files d’attente pour relayer les webhooks WordPress

> Table de transients, cron WordPress, ou service externe comme SQS : trois approches pour fiabiliser la transmission d'événements vers un front headless, comparées.

- Auteur : WordPress Développement
- Publié le : 2022-05-20
- Mis à jour le : 2022-05-20
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/comparatif-files-attente-relayer-webhooks-wordpress/

## L’essentiel

- Une table personnalisée reste la plus simple à déployer sans dépendance
- wp-cron dépend du trafic réel du site pour se déclencher
- Un service externe apporte des garanties, au prix d'une dépendance de plus

Trois approches, trois niveaux de garantie, et un même besoin : s'assurer qu'un événement de publication déclenché côté WordPress finisse bien par atteindre le front headless qui doit en tenir compte, même en cas de panne temporaire du côté récepteur. Ce comparatif ne traite pas de la sécurisation de ces webhooks (signature, protection contre le rejeu), un sujet indépendant du choix de mécanisme de mise en file abordé ici.

Les trois options comparées : une table personnalisée en base MySQL consultée par une tâche planifiée `wp-cron`, une file gérée entièrement par `wp-cron` sans table dédiée (via des *transients*), et un service de file managé externe comme Amazon SQS.

## Option 1 : table personnalisée et wp-cron

Chaque événement à relayer est inséré dans une table dédiée, avec un statut et un compteur de tentatives. Une tâche planifiée consulte cette table à intervalle régulier et tente le relais, en marquant chaque ligne selon son issue. C'est l'approche la plus simple à mettre en œuvre sans ajouter de dépendance externe, décrite plus en détail dans un précédent article de ce blog consacré à un webhook Stripe relayé vers un front Nuxt.

## Option 2 : transients et wp-cron, sans table dédiée

Une variante plus légère stocke chaque événement en attente dans un transient WordPress plutôt que dans une table personnalisée, évitant une migration de base de données. Cette approche perd cependant en visibilité : lister l'ensemble des événements en attente ou en échec demande de parcourir les clés de transients existantes, une opération peu naturelle et peu performante à grande échelle.

> L'essentiel à retenir : Une table personnalisée reste la plus simple à déployer sans dépendance ; wp-cron dépend du trafic réel du site pour se déclencher ; Un service externe apporte des garanties, au prix d'une dépendance de plus

## Option 3 : un service de file managé externe

Amazon SQS, ou une alternative équivalente, reçoit chaque événement via un appel API dès sa publication côté WordPress, puis le distribue à un consommateur dédié — potentiellement hébergé indépendamment du serveur WordPress lui-même. Cette approche découple totalement la fiabilité du relais de la disponibilité de `wp-cron`, qui reste, dans les deux options précédentes, une dépendance structurelle.

## Le tableau comparatif

| Critère | Table + wp-cron | Transients + wp-cron | Service externe (SQS) |
| --- | --- | --- | --- |
| Dépendance externe | Aucune | Aucune | Oui, service tiers |
| Visibilité des événements en attente | Bonne (requête SQL directe) | Faible | Bonne (console du service) |
| Fiabilité du déclenchement | Dépend du trafic du site | Dépend du trafic du site | Indépendante de WordPress |
| Complexité de mise en place | Modérée (migration SQL) | Faible | Plus élevée (API, IAM, consommateur) |
| Coût direct | Aucun | Aucun | Facturation à l'usage |

## La limite commune aux deux premières options

`wp-cron` ne se déclenche qu'à l'occasion d'une visite sur le site, par défaut : sans trafic réel, aucune tâche planifiée ne s'exécute, quel que soit l'intervalle configuré. Sur un site à trafic soutenu, ce mécanisme reste suffisamment fiable en pratique. Sur un site à faible trafic — un site vitrine consulté quelques dizaines de fois par jour — le délai entre deux exécutions réelles de `wp-cron` peut largement dépasser l'intervalle configuré, avec un impact direct sur la fraîcheur du relais.

Un cron système véritable, déclenché en dehors de WordPress via une requête vers `wp-cron.php` à intervalle fixe, contourne cette limite pour les deux premières options sans nécessiter de service externe.

## Le verdict

Pour la majorité des projets, une table personnalisée combinée à un cron système fiable reste le meilleur rapport entre simplicité et fiabilité : aucune dépendance nouvelle, une visibilité complète sur les événements en attente, et une fiabilité largement suffisante une fois le déclenchement de `wp-cron` sécurisé. Un service externe comme SQS ne se justifie que lorsque le volume d'événements dépasse ce qu'une table MySQL classique peut absorber confortablement, ou lorsque le relais doit fonctionner de façon totalement indépendante de la disponibilité du serveur WordPress lui-même.

- Site à trafic modeste, volume d'événements faible : table personnalisée avec cron système externe.
- Besoin de simplicité maximale, tolérance à un délai variable : transients suffisent.
- Volume élevé ou exigence de fiabilité indépendante de WordPress : service externe managé.

> La meilleure file d'attente n'est jamais la plus sophistiquée : c'est celle dont l'équipe comprend réellement le comportement en cas de panne, et qu'elle sait surveiller sans effort particulier.

## Notre verdict

Trois approches, aucune universellement supérieure : le bon choix dépend du volume d'événements, du trafic réel du site, et de la tolérance de l'équipe à ajouter une dépendance externe. Ce qui compte, au-delà du mécanisme choisi, reste la capacité à détecter et rejouer un événement resté en échec — un aspect trop souvent négligé, quelle que soit l'option retenue.