Try-Catch avec « Configure run after » dans Power Automate

Un plantage au milieu d'un flux est agaçant ; un plantage que personne ne remarque est dangereux. Power Automate ne dispose pas d'un Try-Catch intégré comme un langage de programmation classique, mais en combinant les scopes avec le paramètre Configure run after tu construis toi-même exactement ce modèle. Le résultat est un flux qui, en cas d'erreur, ne s'interrompt pas simplement mais réagit de façon maîtrisée, consigne l'erreur et t'avertit en cas de doute.

Dans cet article, nous te montrons pas à pas comment construire des scopes Try, Catch et Finally, comment configurer correctement leurs conditions d'exécution après, et comment accéder au message d'erreur réel en cas d'échec. La base de tout cela provient de la documentation officielle de Microsoft, plus précisément du guide sur la gestion robuste des erreurs et de l'aperçu des scopes dans les flux cloud.

Pourquoi Power Automate ne connaît pas de Try-Catch classique

Dans les langages de programmation, tu interceptes une exception avec un bloc Try-Catch : le code s'exécute dans la partie Try, et une erreur bascule automatiquement dans la partie Catch. Power Automate fonctionne différemment : chaque action possède une condition d'exécution après, qui est réglée par défaut sur « a réussi ». Si une action précédente échoue, l'action suivante est simplement ignorée et l'ensemble du flux s'interrompt, sauf configuration contraire de ta part.

C'est exactement là qu'intervient le modèle Try-Catch : tu regroupes ta logique réelle dans un scope, tu ajoutes un second scope pour la gestion des erreurs et tu configures sa condition d'exécution après pour qu'il ne s'exécute qu'en cas d'erreur dans le premier scope. Tu obtiens ainsi structurellement le même comportement qu'un Try-Catch, mais configuré via l'interface plutôt que par le code.

La structure : scopes Try, Catch et Finally

Pour un modèle complet de gestion des erreurs, tu crées trois scopes à la suite :

• Try : Un scope contenant ta logique métier réelle, c'est-à-dire les actions qui doivent s'exécuter en temps normal.
• Catch : Un second scope juste en dessous, qui ne s'exécute que si quelque chose se passe mal dans le scope Try. C'est ici que tu consignes l'erreur ou envoies une notification.
• Finally : Un troisième scope qui s'exécute toujours, quel que soit le résultat, que le scope Try ait réussi ou non. Pratique pour les tâches de nettoyage comme fermer une connexion ou définir un champ de statut.

Tu ajoutes chaque scope via Ajouter une action en recherchant « Scope », décrit en détail dans le guide Créer et utiliser des scopes. Veille à donner des noms pertinents aux scopes ; « Try », « Catch » et « Finally » sont compréhensibles en un coup d'œil et rendent le flux lisible aussi pour les collègues qui le reprendront plus tard.

Étape par étape : configurer Configure run after

Voici comment configurer la condition d'exécution après pour le scope Catch :

• Ouvre le scope Catch dans le concepteur et sélectionne le menu « ... » en haut à droite.
• Sélectionne Configure run after (en allemand : « Ausführen nach konfigurieren »).
• La liste affiche le scope précédent, à savoir « Try », avec quatre cases à cocher : a réussi, a échoué, est ignoré et le délai d'expiration a été dépassé.
• Retire la coche de « a réussi » et coche à la place « a échoué », « est ignoré » et « le délai d'expiration a été dépassé ».
• Confirme avec Terminé.

Ainsi, le scope Catch ne s'exécute plus que lorsque le scope Try ne se termine pas proprement. Pour le scope Finally, tu procèdes de la même façon, mais tu coches les quatre cases, y compris « a réussi ». Ce scope s'exécute alors dans tous les cas, quelle que soit la façon dont se termine le scope Try. Important : au moins une case doit toujours rester cochée, la condition ne peut pas être enregistrée complètement vide.

Lire l'erreur dans le scope Catch

Un scope Catch qui sait seulement que quelque chose s'est mal passé, mais pas quoi, ne t'aide guère à résoudre le problème. Pour accéder au message d'erreur précis, tu utilises dans le scope Catch l'action Filtrer le tableau combinée à la fonction d'expression result(), qui renvoie le statut et la sortie des actions précédentes. À partir de cette réponse filtrée, tu extrais le code et le texte de l'erreur et les places par exemple dans une action Créer un tableau HTML, que tu envoies par e-mail ou stockes dans une liste de journal d'erreurs sur SharePoint ou Dataverse.

De plus, la fonction workflow() fournit des métadonnées sur l'exécution actuelle du flux, comme l'ID de l'environnement et du flux. Combinée à l'action Composer, tu construis ainsi un lien direct vers l'exécution en échec, que tu intègres dans la notification. Ainsi, ce n'est pas seulement l'information « une erreur s'est produite » qui arrive dans la boîte de réception, mais directement le chemin vers l'endroit où tu peux la corriger.

Pièges courants

• Profondeur d'imbrication : Power Automate autorise un maximum de huit niveaux imbriqués de scopes, conditions, switches et boucles. Si tu imbriques des modèles Try-Catch les uns dans les autres, garde cette limite à l'esprit, sinon le flux ne pourra plus être enregistré.
• Statut global plutôt qu'action individuelle : Si un scope échoue, le concepteur ne signale d'abord que le statut « Échec » pour l'ensemble du scope. Tu ne vois quelle action précise en est réellement responsable qu'en développant le scope dans l'historique d'exécution.
• Les déclencheurs et les actions de réponse n'ont pas leur place dans un scope. Ils doivent rester en dehors pour que le flux démarre et réponde correctement.
• Trop de scopes : Chaque action individuelle n'a pas besoin de son propre scope. Utilise le modèle Try-Catch de manière ciblée là où il apporte réellement une valeur ajoutée, par exemple pour des opérations d'écriture critiques ou des appels à des systèmes externes, sinon le flux devient inutilement confus.

Si tu souhaites intégrer ce modèle de manière fiable dans un flux de production plus important, ou si tu n'es pas sûr de l'endroit où un scope Catch est vraiment nécessaire dans ton processus, le conseil Power Automate de NordFlux peut t'y aider. Tu gardes le contrôle total sur ton flux et tes données, nous t'aidons uniquement pour une mise en place propre.

Questions fréquentes

Configure run after est-il la même chose qu'un Try-Catch dans un langage de programmation ?

Techniquement non, fonctionnellement oui. Power Automate ne dispose pas d'un concept d'exception intégré qui fait automatiquement basculer une action vers un chemin d'erreur. Mais via la condition d'exécution après d'un scope, tu obtiens le même comportement : le scope Catch ne s'exécute que si le scope Try échoue, tout comme un bloc catch en cas d'exception.

Dois-je définir une condition d'exécution après distincte pour chaque action individuelle ?

Non. Si tu regroupes tes actions dans un scope Try, un seul paramètre Configure run after pour l'ensemble du scope suffit, au lieu de sécuriser chaque action individuellement. C'est précisément l'un des avantages pratiques des scopes par rapport à de nombreuses conditions d'exécution après individuelles au niveau de l'action.

Que se passe-t-il si je laisse accidentellement « a réussi » coché pour le scope Catch ?

Le scope Catch s'exécute alors aussi lorsque le scope Try a réussi, ce qui va à l'encontre du principe même d'un chemin d'erreur. Pour un véritable scope Catch, retire systématiquement la coche de « a réussi » et n'active que « a échoué », « est ignoré » et « le délai d'expiration a été dépassé ».

Puis-je également utiliser une stratégie de nouvelle tentative en plus de Configure run after ?

Oui, les deux se complètent bien. Une stratégie de nouvelle tentative dans les paramètres de l'action essaie d'abord de réexécuter automatiquement une action ayant échoué temporairement, idéalement avec des intervalles croissant de façon exponentielle. Ce n'est que si l'action échoue encore après toutes les tentatives que ton scope Catch entre en jeu via la condition d'exécution après.

Comment savoir quelle action, au sein d'un scope en échec, était réellement à l'origine du problème ?

Ouvre l'exécution du flux concernée dans l'historique d'exécution et développe le scope en échec. Comme un scope ne signale vers l'extérieur qu'un statut global unique, tu ne verras le message d'erreur précis accompagné du marquage rouge qu'au niveau de l'action individuelle à l'intérieur du scope.