Automatisations métier : savoir ce qui a tourné et ce qui peut être rejoué

Une automatisation peut échouer après avoir modifié une ressource ou transmis une demande à un autre outil. Son état final ne dit donc pas, à lui seul, ce qui reste à faire. Avant de relancer, retrouver l’exécution concernée, les effets déjà produits et ce que la nouvelle tentative utilisera comme données.

Ce dossier prend Shopify Flow comme exemple documenté. Il propose une méthode de contrôle ; aucun scénario marchand n’a été consulté ou rejoué. Le fonctionnement d’un autre moteur, d’une application partenaire ou d’une action particulière doit être vérifié dans sa propre documentation.

Partir d’un effet métier, puis retrouver l’exécution

Considérons un scénario fictif de suivi du catalogue : après un événement produit, une condition sélectionne une référence à contrôler, une action ajoute un repère et une autre avertit l’équipe. Ce scénario sert seulement à raisonner sur les effets ; il n’est pas présenté comme une recette installée.

Si l’avertissement manque, la première question n’est pas « faut-il tout relancer ? ». Rechercher l’exécution correspondant à la référence et à l’événement. Relever son identifiant, le déclencheur, l’heure, les étapes parcourues, l’erreur et la version disponible du scénario. Examiner ensuite la fiche produit et la destination de l’avertissement : le repère existe-t-il déjà ? Une demande a-t-elle été reçue malgré l’erreur du moteur ?

Le journal du moteur et le système destinataire apportent des preuves différentes. Une action annoncée comme terminée peut renseigner une transmission technique sans démontrer la prise en charge humaine. Inversement, l’absence de réponse peut laisser incertain un effet externe. Conserver cette incertitude plutôt que la traduire en « rien n’a été fait ».

Distinguer attente, reprise automatique et échec arrêté

La documentation de dépannage Flow distingue les erreurs transitoires, réessayées automatiquement jusqu’à réussite ou expiration de la limite applicable, des erreurs permanentes, qui ne déclenchent pas la même reprise automatique de la tâche.

Une exécution qui attend ou réessaie n’est donc pas nécessairement arrêtée. Vérifier son état avant une intervention manuelle. La documentation du rejeu précise qu’une exécution encore en cours ou en attente ne peut pas être rejouée manuellement : elle doit être terminée avec succès ou avec des erreurs.

Lire l’erreur concrète. Une ressource absente, un mauvais type de donnée ou une destination invalide ne se corrige pas en répétant la même opération. Identifier la cause, vérifier la ressource et examiner les autres exécutions concernées. Une correction générale ne démontre pas que toutes les erreurs antérieures avaient la même origine.

Un rejeu ne reconstitue pas l’instant initial

La page consacrée aux reprises manuelles indique que Flow réutilise les données du déclencheur initial, par exemple l’identifiant de la ressource. Elle précise aussi que les actions de récupération lisent les données les plus récentes, et que conditions et actions utilisent des données à jour.

Dans notre exemple, la référence produit reste le point de départ, mais ses attributs peuvent avoir changé. Une condition qui sélectionnait le produit lors du premier passage peut prendre une autre branche lors de la reprise. Le repère ajouté auparavant peut lui-même influencer le résultat.

Relever l’état actuel et le comparer à ce qui est connu de l’état initial. Si un attribut historique n’a pas été conservé, l’indiquer. Ne pas inventer cet état à partir de la fiche actuelle. Distinguer la version du scénario lors de l’exécution initiale, sa version active et celle qui sera effectivement utilisée pour le rejeu. La page Shopify consultée décrit les données et les conditions de reprise, mais ne précise pas la règle de sélection de version ni le point exact de redémarrage. Ne pas en déduire que le rejeu utilisera nécessairement la version d’origine, ou qu’il repartira seulement de l’étape en erreur. Si ces paramètres restent indéterminés pour le scénario concerné, suspendre le rejeu et les faire établir avant de décider.

Vérifier séparément chaque effet répétable

Pour chaque action, écrire ce qu’une seconde exécution pourrait produire. Ajouter un repère déjà présent n’a pas nécessairement les mêmes conséquences qu’envoyer un nouvel avertissement, créer une demande externe ou modifier une quantité. La protection doit être vérifiée au niveau de l’action et du destinataire.

La recommandation est d’utiliser, lorsque le système le permet et que son comportement est vérifié, un identifiant stable de l’opération métier pour reconnaître une demande déjà traitée. Un simple statut « envoyé » dans le moteur ne prouve pas que le destinataire sait refuser un doublon.

Quand l’effet externe reste incertain, rechercher d’abord une trace chez le destinataire. Si elle n’est pas accessible, confier l’arbitrage à la personne responsable de cet effet. Ne pas ajouter une seconde demande uniquement pour faire disparaître une erreur du journal.

Le dossier sur les notifications de paiement approfondit ce problème lorsque l’événement touche une commande. Ici, le contrôle porte sur l’exploitation d’un scénario métier et ses conditions de reprise.

Choisir entre reprise, correction séparée et attente

Dans la chronologie fictive, le repère catalogue est d’abord ajouté, puis la demande d’avertissement échoue. Si le destinataire confirme n’avoir rien reçu et si les conditions actuelles correspondent encore à l’intention, le rejeu d’une seule exécution peut être examiné après correction de la cause et qualification de la version et du point de redémarrage. Cette limite porte sur le nombre d’exécutions, pas sur la sélection de certaines étapes. Si le destinataire a déjà reçu la demande, le rejeu peut créer un doublon : examiner une correction ciblée par un autre moyen documenté et autorisé. Ce traitement séparé ne suppose pas que Flow permette d’exclure une étape déjà réussie.

Si le repère lui-même n’est plus justifié, sa correction est une décision métier séparée. Ne pas le supprimer automatiquement : une autre opération peut légitimement l’utiliser. Enfin, si la réception reste incertaine ou qu’une reprise automatique continue, différer le rejeu manuel et faire résoudre ce point. Ce raisonnement sur scénario fictif n’est pas une simulation exécutée dans Flow ; les effets exacts du connecteur restent à éprouver.

Préparer le rejeu d’une exécution et sa preuve de clôture

Selon Shopify, le workflow doit être actif et son déclencheur doit correspondre à celui de l’exécution d’origine pour permettre le rejeu. Ce sont des conditions techniques ; elles ne prouvent pas que l’opération est souhaitable.

Avant la reprise, nommer le responsable, l’exécution visée, la correction apportée, les effets attendus et ceux qui ne doivent pas être répétés. Choisir un cas représentatif et maîtrisé avant d’envisager plusieurs reprises. Ne regrouper des exécutions qu’après avoir établi qu’elles partagent le même problème et les mêmes conditions de traitement.

Après une reprise autorisée, relier l’original et la nouvelle tentative. Flow documente des liens entre ces exécutions ainsi qu’une distinction entre événement déclencheur, lancement manuel et reprise manuelle. Vérifier le résultat dans les ressources et destinations concernées, puis noter les écarts et les effets incertains.

La clôture attendue n’est pas seulement un indicateur passé au vert : c’est une explication de ce qui a eu lieu, de ce qui a été repris et de ce qui reste non établi. Garder cette trace permet à une autre personne de comprendre l’incident sans relancer de nouveau par défaut.