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.
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.
