Shopify Flow Product updated : automatiser les changements produit sans boucle

À quoi sert Product updated dans une boutique Shopify ?

Ce déclencheur permet de réagir à une modification du catalogue sans construire soi-même un connecteur. Tu sélectionnes les champs utiles dans Flow, tu ajoutes les conditions métier, puis l’action adaptée. Le déclenchement ne signifie pas que toutes les actions doivent s’exécuter : une condition peut terminer le parcours sans écrire.

Tu peux par exemple demander une revue après un changement de titre, signaler un produit après une modification de prix de variante, ou préparer une règle de classement fondée sur des données produit. Ce sont des scénarios à adapter, pas des modèles importables ni des résultats garantis. La référence Product updated décrit les champs et les actions utilisables.

Pour une intégration avec un ERP ou une app personnalisée, le guide Shopify Events et webhooks traite un autre problème : transporter et traiter les événements dans ton application. Ici, on reste dans l’éditeur de workflows de la boutique. Le guide Flow pour les étiquettes d’expédition concerne quant à lui la préparation des commandes, pas la gouvernance du catalogue.

Quels champs surveiller, et quand choisir un autre déclencheur ?

Dans l’éditeur, clique sur Product updated, puis Select fields dans Select product fields. Sélectionne les champs dans Add field to monitor. Un seul changement parmi les champs retenus suffit ; un champ non sélectionné ne démarre pas ce workflow. La limite est de cinq champs, pas une obligation de remplir cinq cases. Sélection officielle des champs.

Ces correspondances viennent de la liste des champs et des déclencheurs dédiés. Choisis le signal qui correspond à la décision, puis les conditions nécessaires. Surveiller davantage de champs pour « ne rien rater » élargit surtout le nombre de situations à expliquer et à recevoir.

Attention à la création d’un produit. Les champs simples du groupe Product, comme le titre ou les tags, ne démarrent pas ce déclencheur lorsqu’ils sont définis à la création. En revanche, les variantes, options, médias et certaines relations ajoutés avec le produit comptent comme des changements. Shopify précise ainsi qu’un workflow surveillant variants.price tourne aussi à l’ajout d’un produit, puisque chaque produit possède une variante. Ne considère donc pas le nom « updated » comme une exclusion universelle des créations. Comportement documenté à la création.

Quelles données sont réellement disponibles ?

Product et Shop sont toujours disponibles. Les objets liés dépendent du changement concerné. Si tu surveilles à la fois tags et variants.price, une modification des seuls tags peut laisser Product Variant vide. Ajoute une condition de présence avant toute étape qui utilise cette variante. Le même principe concerne les options, médias et produits de Combined Listings. Objets et valeurs disponibles.

Product updated ne fournit que les valeurs courantes : les précédentes ne sont pas disponibles dans le workflow. « Le nouveau prix est inférieur à un seuil défini » et « le prix vient de baisser de 20 % » sont deux règles différentes. La seconde demande une référence antérieure fiable, avec sa date et son périmètre. N’invente pas cet historique à partir du seul événement. Limite officielle sur les anciennes valeurs.

Si tes règles produit et variante n’ont ni les mêmes conditions ni les mêmes responsables, mon conseil est de les séparer. Si tu les réunis, rends les branches explicites. Le nombre de workflows mérite aussi une revue : Shopify avertit qu’un grand nombre de workflows sur un même déclencheur peut ralentir le traitement. Le regroupement se décide selon la clarté des règles, pas seulement selon le nombre de blocs. Diagnostic des workflows partageant un déclencheur.

Une méthode simple pour éviter les boucles et les écritures inutiles

Une règle qui surveille tags et ajoute un tag modifie potentiellement sa propre entrée. De même, deux outils peuvent se répondre : l’un ajoute une valeur, l’autre la retire, puis le premier recommence. C’est un risque de conception déduit du fonctionnement documenté du déclencheur, pas la preuve qu’une boutique rencontre déjà ce problème.

Ma méthode consiste à définir trois éléments avant de dessiner le workflow : le champ qui déclenche, l’état attendu et la condition de sortie. Évite de surveiller ton champ de sortie quand ce n’est pas nécessaire. Avant une écriture, vérifie si le résultat existe déjà. Cette précaution réduit les passages inutiles ; elle ne constitue pas une garantie d’exécution unique en présence d’autres automatisations ou de modifications simultanées.

Exemple proposé : après une modification de title, ajouter le tag catalogue-a-controler seulement au produit pilote convenu, et seulement si ce tag est absent. Le champ surveillé est title ; l’action écrit tags. Ajouter ce tag seul ne constitue donc pas un changement surveillé par ce workflow. L’action native Add product tags est disponible avec Product updated. Respecte la casse du tag, qui est significative pour cette action.

Ce tag représente une tâche de revue, pas une validation du contenu. L’équipe le retire une fois le contrôle effectué ; un changement ultérieur du titre peut alors demander une nouvelle revue. Ne conditionne pas le workflow à l’absence d’un tag « déjà traité » permanent si tu veux continuer à surveiller les modifications futures.

L’exemple s’étend à un prix de variante en changeant le champ surveillé et les conditions. Un tag produit « prix-a-controler » signale toutefois une revue de la fiche, pas un historique détaillé de toutes les variantes. Pour des notifications externes ou une écriture dans un autre outil, définis aussi ce qui doit se passer lors d’une répétition ; le tag ne suffit pas à prouver qu’un message ne partira qu’une fois.

Configurer le pilote en six étapes

1. Écrire le contrat métier. Note le champ surveillé, le résultat, le produit pilote, le responsable de la revue et la manière de suspendre la règle. Liste les apps, imports ou autres flows qui écrivent sur les mêmes champs. Une synchronisation PIM fait partie du périmètre à vérifier.
2. Vérifier les accès. Installe Flow si nécessaire : Shopify le présente comme une application gratuite. Dans les rôles, l’accès passe par Flow automations → View, create, and delete automations. Activer ou relancer le workflow demande aussi les droits sur les données et apps de ses étapes ; les secrets ont un droit supplémentaire. Tester avec des données en lecture et activer une écriture ne demandent pas nécessairement les mêmes droits. Présentation de Flow et permissions actuelles.
3. Créer le workflow et sélectionner un signal. Pour l’exemple, sélectionne Product updated, puis title. N’ajoute pas tags simplement parce que l’action en utilise : surveiller un champ et le lire dans une condition ont des rôles différents. Conserve le workflow inactif pendant la préparation.
4. Délimiter puis contrôler. Ajoute la condition qui réserve le pilote au produit convenu, puis celle qui vérifie l’absence du tag catalogue-a-controler. Pour un scénario variante, contrôle d’abord la présence de Product Variant. Vérifie les opérateurs et la différence entre toutes les conditions et au moins une condition.
5. Préparer l’action et sa vérification. Utilise Add product tags avec le tag décidé. Note où l’équipe verra la file à traiter et qui retire le tag après revue. Avant toute extension, simule le chemin et les paramètres, puis organise le test réel décrit ci-dessous sur le périmètre autorisé.
6. Activer progressivement et rapprocher le résultat. Modifie le champ surveillé sur le produit pilote, ouvre le run correspondant et contrôle la fiche finale. Si le résultat est inattendu, suspends la règle concernée, examine les autres outils puis corrige la cause avant de relancer. Une désactivation ne retire pas les tags déjà écrits ; prévois leur traitement séparément.

L’exemple est une logique à construire dans l’éditeur, sans code API ni fichier d’import promis. Les données et libellés effectivement proposés dans ton compte doivent être vérifiés. Flow gratuit ne signifie pas que les actions d’un service tiers sont gratuites ou incluses dans ton accès.

Comment tester sans confondre simulation et action réelle ?

Le mode Test your workflow peut vérifier les conditions et paramètres sans modifier les données de la boutique. Il s’arrête à la première action qui voudrait écrire ; certaines actions externes ne sont pas simulables. Les tests n’apparaissent pas dans Recent runs. Dans l’éditeur, ouvre le test depuis le déclencheur et utilise un événement adapté, créé ou enregistré selon les possibilités proposées. Test officiel sans écriture.

Enregistrer un événement peut néanmoins demander une vraie modification dans un autre onglet. Ce geste reste réel, même si le workflow en test n’écrit pas. La référence spécifique de Product updated décrit aussi un test réel : activer le workflow puis modifier un champ surveillé du produit. Fais-le après les simulations utiles, sur un produit et un changement autorisés, en examinant les autres automatismes actifs. Test du déclencheur Product updated.

Cette grille constitue des critères à recevoir, pas des tests marchands exécutés pour l’article. Une simulation qui suit la bonne branche ne prouve ni l’écriture finale ni le comportement des autres apps. Shopify documente d’ailleurs le cas d’un tag ajouté par Flow puis écrasé par un outil concurrent. Diagnostic officiel des tags remplacés.

Surveiller les runs et reprendre après une erreur

Dans Flow → Recent runs, recherche le produit et l’horaire du changement, puis examine les conditions et actions du run. Les horaires suivent le fuseau de la boutique. Les runs sont conservés quatorze jours après leur fin : si ta procédure demande une preuve plus durable, conserve uniquement les informations utiles dans un journal adapté. Recherche et conservation des runs.

Observe les sorties sans action autant que les erreurs. Un workflow qui ne fait rien sur un produit hors périmètre peut fonctionner correctement. En revanche, plusieurs passages rapprochés pour la même fiche, un tag qui disparaît ou une action réussie suivie d’un état final incorrect demandent une investigation sur l’ensemble des écrivains du catalogue. Le guide de diagnostic des apps Shopify aide à prolonger cette recherche côté intégrations.

Une relance manuelle ne rejoue pas une photographie complète du passé. Shopify réutilise les données du déclencheur d’origine, mais récupère les dernières données des actions Get data et utilise des données à jour dans les conditions et actions. Le workflow doit être actif, son déclencheur compatible et le run terminé. Vérifie donc le prix, le tag et les effets déjà produits avant de cliquer sur Retry run. Règles officielles de reprise.

Après une panne, identifie la cause et le sous-ensemble réellement touché. Ne relance pas tous les runs pour compenser une erreur d’objet absent ou une règle trop large. Une notification ou une écriture externe peut exiger un rapprochement supplémentaire avant toute répétition.

Quand demander un audit du workflow ?

Si la règle utilise des données de plusieurs apps, des mises à jour simultanées, un historique de prix ou des actions commerciales, écris d’abord le résultat attendu et les exceptions. Le bon livrable est un circuit compréhensible : source du changement, conditions, écriture autorisée, preuve du résultat et reprise. Le nombre de workflows activés ne mesure pas la qualité de l’automatisation.

Tu veux sécuriser une règle catalogue ou comprendre pourquoi tes apps réécrivent les mêmes produits ? Parle-moi du circuit et du problème observé, ou consulte le périmètre de l’audit Shopify. On peut partir d’un produit, d’un changement et d’un run pour décider ce qu’il faut corriger.

Sources et méthode

Guide rédigé le 1er novembre 2026 à partir de l’annonce Shopify du 28 octobre et des références actuelles liées près des faits. La sélection des champs, les objets disponibles, les tests, les permissions et la reprise ont été relus séparément. La méthode de sortie avant écriture, le schéma et la grille de recette sont des propositions éditoriales originales. Aucun workflow de boutique cliente, changement de produit, message ou test marchand n’a été exécuté pour cette rédaction. Les possibilités réelles d’un compte et les actions de ses apps restent à vérifier avant activation.