Webhooks Shopify : arrêter le polling et diviser votre facture d'automatisation

La plupart des automatisations Shopify que je reprends font la même chose : elles interrogent l'API à intervalle régulier pour vérifier si quelque chose a changé. C'est ce qu'on appelle le polling, et c'est presque toujours le mauvais choix.

Voici pourquoi, et comment en sortir.

Le coût réel du polling

Un scénario qui vérifie les nouvelles commandes toutes les cinq minutes s'exécute 288 fois par jour, soit environ 8 600 fois par mois. Sur une boutique qui reçoit trente commandes par jour, cela signifie que plus de 96 % des exécutions ne trouvent rien.

Si vous payez à la tâche, vous payez ces 96 %.

Et vous payez ce coût pour un service dégradé : une commande passée juste après un cycle attend jusqu'à cinq minutes avant d'être vue.

Le principe du webhook

Un webhook inverse la relation. Au lieu que vous demandiez « du nouveau ? », Shopify vous prévient quand il se passe quelque chose. Une commande arrive, votre scénario s'exécute — une fois, immédiatement.

Zéro exécution à vide. Zéro latence.

Passer au webhook, en pratique

1. Identifiez ce que vous surveillez réellement. Pas « les commandes » : quel événement précis déclenche votre logique. Une commande créée ? Payée ? Expédiée ? Ce sont trois sujets différents, et c'est l'erreur la plus fréquente — s'abonner à la création alors qu'on voulait le paiement.

2. Déclarez l'abonnement. n8n, Make et Zapier proposent tous un déclencheur webhook Shopify natif. L'outil enregistre l'abonnement pour vous.

3. Rendez le traitement idempotent. C'est le point qu'on oublie.

4. Prévoyez l'échec. Si votre point de réception est indisponible, l'événement peut être perdu. Pour les flux critiques, gardez une vérification quotidienne de rattrapage — pas toutes les cinq minutes, une fois par jour, qui compare et corrige.

Les déclencheurs sur metafield changent le calcul

Le reproche classique fait aux webhooks Shopify, c'est leur granularité : s'abonner à products/update réveille votre scénario à chaque modification, y compris celles qui ne vous concernent pas. On remplaçait alors un problème par un autre.

Les déclencheurs sur metafield répondent précisément à ça : l'abonnement porte sur le champ, pas sur l'objet entier. Le filtrage remonte de votre scénario vers Shopify — et ce qui n'est jamais envoyé n'est jamais facturé.

Quand garder le polling

Il reste deux cas légitimes, et c'est tout :

• Aucun webhook ne couvre l'événement. Tous les changements n'ont pas de sujet dédié.
• La réconciliation périodique. Comparer deux systèmes une fois par jour pour rattraper les écarts est un usage sain du polling — c'est le filet de sécurité sous les webhooks, pas leur remplacement.

Le résultat, concrètement

Sur une reprise typique, remplacer un polling à cinq minutes par un webhook fait passer un scénario de ~8 600 exécutions mensuelles à ~900 pour une boutique à trente commandes par jour. Un facteur dix sur la facture, et une latence qui tombe de plusieurs minutes à quelques secondes.

C'est rarement le chantier le plus impressionnant à présenter. C'est presque toujours celui qui a le meilleur rapport effort/résultat.