Automatisations internes : gérer les échecs et les doublons

Un formulaire déclenche une réservation de matériel, crée une tâche pour le magasin et envoie une confirmation au demandeur. Prenons ce cas fictif : la réservation réussit, mais la création de tâche ne renvoie aucune réponse. L’exécution apparaît en échec. Un collègue la relance, et le matériel se retrouve réservé à nouveau.

Je commencerais par cette situation avant d’ajouter une nouvelle automatisation. Le parcours normal montre le temps que l’on espère économiser. Le parcours interrompu révèle le travail que l’équipe devra assurer quand personne ne saura exactement ce qui a été fait.

Décrire le résultat attendu et les étapes qui engagent

Je demande au responsable métier de décrire ce qui doit être vrai à la fin du traitement. Dans notre exemple, une demande acceptée correspond à une réservation identifiable, une tâche exploitable par le magasin et une confirmation cohérente. Un voyant vert dans le moteur de flux ne remplace pas cette définition.

Pour chaque étape, je note le système modifié, la preuve disponible et la conséquence d’une répétition. Lire une référence de matériel et réserver ce matériel n’ont pas le même effet. Le second geste engage une ressource dont une autre personne pourrait avoir besoin.

Cette description tient dans une fiche courte. Elle précise également le déclencheur, les conditions d’acceptation et les situations à laisser au traitement humain. Une demande incomplète doit pouvoir être renvoyée pour correction sans lancer les actions suivantes. Automatiser un circuit dont personne ne sait expliquer les exceptions revient à déplacer les hésitations dans un outil.

Distinguer un refus, une panne et un résultat inconnu

Une indisponibilité temporaire peut justifier une nouvelle tentative. Une référence inexistante demande une correction. Une réponse perdue impose d’abord de rechercher ce qui s’est passé chez le destinataire. Je veux que ces situations aboutissent à des traitements différents.

La documentation de Power Automate sur la gestion des erreurs décrit des chemins conditionnés par le résultat d’une action et des politiques de nouvelle tentative. Ces fonctions permettent d’organiser la réaction du flux ; leur présence ne détermine pas la décision métier à prendre.

Je fixe une limite aux tentatives et une destination pour les demandes toujours bloquées. Attendre indéfiniment masque le retard ; réessayer sans pause peut aggraver une indisponibilité. Le délai acceptable dépend du travail à accomplir. Une réservation nécessaire au départ d’un technicien appelle une décision différente d’une mise à jour sans urgence.

Empêcher une relance de créer un nouvel effet

Chaque demande reçoit une référence stable, conservée pendant les tentatives successives. Je demande que cette référence accompagne les échanges et permette de retrouver les objets créés. Un identifiant différent à chaque relance aide à distinguer les exécutions techniques, mais ne suffit pas à reconnaître la même demande métier.

L’API de Stripe documente les clés d’idempotence, qui permettent de répéter une requête sans créer une seconde fois son effet. C’est un exemple concret du mécanisme à rechercher dans les interfaces utilisées. Il faut vérifier ses conditions, notamment sa durée de conservation et le comportement lorsque les paramètres changent. Tous les connecteurs n’offrent pas cette protection.

Si le destinataire ne la propose pas, rechercher un objet existant avant de créer peut aider, mais cette recherche seule ne protège pas de deux exécutions simultanées. Je demande alors à l’intégrateur comment il empêche ces exécutions de créer chacune leur objet. Une contrainte d’unicité ou un traitement sérialisé peut être nécessaire selon le système.

L’absence de réponse ne prouve pas l’absence d’action.

Faute de protection démontrée, je préfère bloquer la relance automatique d’une étape engageante et faire vérifier son résultat. Cette réserve réduit l’autonomie du flux, mais laisse une décision compréhensible à l’équipe qui devra le reprendre.

Préparer la correction des opérations déjà réalisées

Revenons à la réservation réussie suivie d’une tâche manquante. Le bon traitement peut être de créer seulement la tâche. Si la demande a été abandonnée entre-temps, il faudra plutôt libérer la réservation. La décision dépend de l’état actuel du dossier, pas uniquement de l’erreur initiale.

Microsoft décrit ce principe dans son modèle de transaction de compensation : corriger les effets d’opérations déjà exécutées ne revient pas nécessairement à restaurer leur état initial. D’autres actions ont pu intervenir, et la correction peut elle-même échouer.

Je demande donc une consigne par étape engageante : poursuivre, annuler si les conditions le permettent, ou transmettre au responsable métier. Dans notre exemple, libérer automatiquement un matériel déjà remis au demandeur créerait une nouvelle incohérence. Le magasin doit pouvoir confirmer la situation physique avant toute correction du stock.

Donner au repreneur une file de travail exploitable

Une notification contenant seulement le nom du flux en erreur oblige quelqu’un à refaire toute l’enquête. Je préfère une file d’exceptions où chaque demande affiche sa référence, son ancienneté, la dernière étape confirmée, le résultat incertain et le responsable de la prochaine action.

Les traces doivent permettre de relier une demande à ses exécutions et aux objets créés, sans recopier inutilement le contenu des dossiers ni les secrets de connexion. Leur accès doit correspondre aux responsabilités de reprise. Le magasin peut avoir besoin de connaître l’état d’une réservation sans accéder aux détails techniques des autres applications.

Je fais également écrire la procédure de passage en manuel : suspendre le traitement concerné, consulter les opérations déjà réalisées, terminer le dossier puis enregistrer cette reprise. Il faut ensuite empêcher une exécution automatique restée en attente de refaire le travail. Arrêter seulement le déclenchement des nouvelles demandes ne garantit pas l’arrêt des exécutions en cours.

Le responsable et son relais doivent pouvoir appliquer cette procédure avec leurs propres accès. Une fiche de connaissances utilisable par le support sert ici à retrouver les contrôles, les décisions autorisées et les contacts nécessaires, même lorsque le concepteur du flux est absent.

Tester les interruptions avant d’étendre le périmètre

Je commencerais la semaine prochaine par un flux existant qui modifie plusieurs applications. Avec son responsable métier, je préparerais des demandes fictives dans un environnement isolé et vérifierais les connexions utilisées, pour éviter tout envoi réel ou mouvement de stock de production.

L’exercice doit couvrir une donnée refusée, une indisponibilité, un résultat obtenu malgré une réponse perdue et un même déclenchement reçu plusieurs fois. Je ferais aussi reprendre un dossier manuellement, puis vérifierais qu’une relance tardive ne reproduit pas son effet. Pour chaque essai, on observe le résultat dans les applications destinataires, pas seulement le journal du moteur.

Le compte rendu précise ce qui reste non démontré. Si le connecteur ne permet pas de simuler une réponse perdue, cette limite doit rester visible et conduire à une règle de reprise prudente. La validation métier avant mise en production doit intégrer ces parcours interrompus.

Enfin, je regarderais le travail complet : exécution normale, diagnostic, reprises et entretien du flux. Une automatisation qui exige une enquête à chaque exception peut coûter plus d’attention que la tâche initiale. Réduire son périmètre à une étape fiable reste une décision utile, surtout lorsque l’équipe devra en assurer seule le fonctionnement.