Next-Generation Events de Shopify : un premier aperçu depuis la préversion développeur

Si vous avez développé plus d’une app Shopify, vous connaissez ce problème : vous souscrivez à products/update parce que vous avez besoin de savoir quand un prix change, et votre handler se déclenche maintenant pour chaque mise à jour de ce produit : modification du titre, changement de tags, ajustement de la description, tout y passe. Vous devez soit refetcher l’objet complet et le comparer vous-même, soit traiter un tas d’événements qui ne vous intéressent pas. Il n’a jamais existé de moyen de dire à Shopify « avertis-moi seulement quand ce champ précis change ».

Shopify vient de commencer à régler ça. Next Generation Events est maintenant en préversion développeur, et on a pu s’y plonger de près : Harshdeep Singh Hura, Senior Product Manager pour les webhooks chez Shopify, a donné un atelier pratique sur le sujet à dotdev 2026. Voici ce que ça change concrètement, comment ça fonctionne sous le capot, et où ça reste encore rugueux.

Ce qui change vraiment

Les webhooks actuels fonctionnent au niveau entité-action : products/update, orders/create, et ainsi de suite. Vous recevez un payload, et déterminer ce qui a changé (ou même si ça vous concerne) est entièrement à votre charge.

Next Generation Events déplace ce filtrage au moment de la souscription plutôt qu’après la livraison. Pour chaque souscription, vous déclarez :

• Un topic : correspond à un type GraphQL, comme Product ou Customer.
• Des actions : standardisées à create, update, delete au niveau de l’entité.
• Des triggers : un pré-filtre sur des champs précis (ex. product.variants.price), de sorte que l’événement ne se déclenche même pas si l’un de ces champs exacts n’a pas changé.
• Un query filter : un filtre supplémentaire sur les données retournées elles-mêmes (ex. seulement les produits ACTIVE), pour que les événements non pertinents soient carrément ignorés plutôt que livrés puis jetés.
• Une query personnalisée : une requête GraphQL Admin standard que vous écrivez vous-même, pour que le payload contienne exactement les données dont votre app a besoin, rien de plus.

Ce dernier point est celui qui change réellement la façon de bâtir des intégrations. Au lieu d’un payload générique suivi d’un appel API pour aller chercher les champs dont vous avez vraiment besoin, la souscription est la query. Un seul aller-retour, façonné par vous.

Comment ça se configure

Les souscriptions vivent actuellement dans shopify.app.toml :

[[events.subscription]]
handle = "price_sync"
topic = "Product"
actions = ["update"]
triggers = ["product.variants.price", "product.variants.compareAtPrice"]
uri = "/api/events/price_tracker"
query_filter = "product.status:'ACTIVE'"
query = """
query priceSync($productId: ID!, $variantsId: ID!) {
  productVariant(id: $variantsId) {
    id
    price
    compareAtPrice
    sku
  }
  product(id: $productId) {
    id
    title
    status
  }
}
"""

À la lecture, c’est essentiellement auto-documenté : se déclencher sur les mises à jour de Product, mais seulement quand le price ou le compareAtPrice d’une variante change réellement, seulement pour les produits actifs, et retourner exactement les champs dont ce handler a besoin : rien sur les tags, les descriptions ou les images n’apparaît jamais.

Une contrainte à connaître avant de concevoir vos triggers : seuls les champs qui font autorité (source-of-truth) sont admissibles. Les champs calculés ou dérivés (l’exemple donné par Shopify est product.description) et les horodatages mis à jour automatiquement (product.updatedAt) ne sont pas des chemins de trigger valides, puisqu’ils changent en conséquence d’autre chose plutôt que d’être la chose qui a réellement changé.

Chaque livraison inclut certaines métadonnées standards en plus du résultat de votre query personnalisée : fields_changed (les chemins exacts qui ont déclenché l’événement), topic, action, handle, et query_variables (les IDs disponibles pour toute requête de suivi dont vous auriez encore besoin). Si un payload devient trop volumineux, Shopify envoie une URL de téléchargement plutôt que le corps complet, le même modèle qu’utilisent déjà les Bulk Operations, donc si vous avez déjà développé contre ça, ce sera familier.

La livraison ne se limite pas non plus à de simples endpoints HTTP : Google Cloud Pub/Sub et Amazon EventBridge sont tous deux supportés, ce qui compte si votre traitement d’événements vit déjà dans l’un de ces pipelines plutôt que derrière une URL de webhook publique. Pour les livraisons HTTP, validez l’en-tête Shopify-Hmac-Sha256 avant de faire confiance à un payload, comme pour les webhooks classiques. Pour l’idempotence, utilisez Shopify-Webhook-Id comme clé de déduplication (elle est unique par livraison) tandis que Shopify-Event-Id identifie l’événement sous-jacent et peut apparaître dans plusieurs souscriptions si vous en avez plusieurs qui observent le même changement.

Ce que Harshdeep nous a montré à dotdev 2026

L’atelier a rendu tout ça beaucoup plus concret que la simple lecture de l’annonce. Harshdeep a configuré une souscription en direct, partant d’un bloc events.subscription vide jusqu’à une combinaison triggers + query_filter fonctionnelle, et c’était vraiment satisfaisant de voir un topic Product bruyant se réduire à seulement la poignée d’événements qu’une app se souciait vraiment de recevoir.

Le détail qui a le plus marqué : les metafields peuvent déjà servir de triggers aujourd’hui, en préversion, pour Product, ProductVariant, Order, Customer, Collection et Location. C’est un vrai manque du modèle de webhooks classique qui se referme : jusqu’ici, il n’y avait aucun moyen de se déclencher seulement quand un metafield précis changeait sans comparer l’objet entier vous-même.

[[events.subscription]]
handle = "product-handle"

topic = "Product"
actions = ["update"]
triggers = [
  "product.variants.metafield(namespace:'custom', key:'workshops').value",
  "product.metafield(namespace:'$app', key:'workshops').value"
]

C’est un metafield sur le produit lui-même et un autre sur une variante, tous deux utilisables comme triggers précis dans la même souscription (namespace et key inclus), donc vous n’êtes même pas limité aux metafields de votre propre app.

La période de questions qui a suivi tournait surtout autour de la même question que se posaient tous les participants : est-ce prêt pour la production ? La réponse honnête, cohérente avec le statut de préversion, était non : pas encore, mais bientôt. Côté feuille de route, les signaux étaient clairs : la couverture des topics est la priorité à court terme (aujourd’hui, Collection, Customer, InventoryItem, InventoryShipment, Location, Order et Product sont déjà supportés, avec davantage d’entités prévues d’ici la fin de 2026), suivie par la livraison pull-based et la gestion des souscriptions via GraphQL plutôt qu’uniquement en TOML. Rien n’a été promis avec des dates fermes, mais la direction était sans équivoque : l’objectif est de remplacer éventuellement toute la surface des webhooks classiques, pas de coexister avec elle comme une option de niche.

Là où ça reste encore rugueux

C’est une préversion développeur sur la version d’API unstable, et ça se voit :

• La couverture des topics s’étend aujourd’hui à Collection, Customer, InventoryItem, InventoryShipment, Location, Order et Product, avec davantage d’entités prévues d’ici la fin de 2026. Les triggers de metafields couvrent pour leur part un ensemble légèrement différent : Product, ProductVariant, Order, Customer, Collection et Location.
• 250 points de complexité de requête est le plafond actuel en préversion : suffisant pour une query de souscription ciblée, pas pour quelque chose de tentaculaire.
• Configuration uniquement en TOML. Les souscriptions ne peuvent pas encore être gérées via des mutations GraphQL, et les queries doivent être écrites directement dans le fichier TOML plutôt que référencées depuis un fichier séparé.
• Aucun outillage de test dédié pour l’instant : vous validez vos souscriptions contre une vraie boutique.
• Shopify CLI 3.92 ou supérieur requis pour déployer une config events.subscription : un piège facile si l’outillage de votre app est figé sur une version plus ancienne du CLI.

Rien de tout ça n’est rédhibitoire pour expérimenter, mais ça veut dire que ce n’est pas encore quelque chose à brancher dans une intégration en production aujourd’hui.

Pourquoi ça compte au-delà de la surface d’API

Pour quiconque bâtit des services de synchronisation, des trackers de prix, des automatisations d’inventaire ou des workflows pilotés par IA par-dessus les données Shopify, le modèle de webhooks actuel a toujours signifié payer une taxe en appels API supplémentaires et en logique de filtrage juste pour savoir si un événement était pertinent. Next Generation Events élimine cette taxe à la source : moins de bruit en entrée, moins de code de filtrage à maintenir, et un payload façonné autour de ce que votre app en fait réellement.

C’est exactement le genre de virage de plateforme à surveiller de près quand les intégrations Shopify font partie de votre stack : il est facile de bâtir contre le modèle de webhooks d’aujourd’hui, puis de devoir tout refaire une fois que le nouveau devient la norme. Si vous préférez qu’une équipe surveille déjà les changements de plateforme Shopify et architecture autour d’eux plutôt que de le découvrir à votre propre rythme, c’est exactement à ça que sert notre Dev Retainer, particulièrement les paliers Growth Engine et Integrated Partner, où vit ce genre de travail au niveau plateforme.

Si vous expérimentez déjà avec Next Generation Events et voulez un second avis sur la conception de vos souscriptions, ou si vous voulez de l’aide pour planifier la migration une fois que ce sera prêt pour la production, contactez notre équipe : on est là pour vous aider.