Gestion des erreurs et stratégie de nouvelle tentative dans Power Automate — éviter qu'un flux qui fonctionnait ne s'arrête sans que personne ne le remarque

« Le flux d’agrégation qui s’exécutait tous les matins était en fait arrêté depuis la semaine dernière. » « Le flux d’enregistrement des commandes a traité deux fois les mêmes données, créant des doublons dans le registre. » Nous recevons régulièrement ce type de demande de la part d’entreprises qui ont créé un flux Power Automate et l’ont mis en exploitation. Le schéma est toujours le même : c’était facile à construire, mais personne ne s’est aperçu de l’arrêt.

Un flux Power Automate qui ne suit que le chemin nominal fonctionnera sans incident pendant des heures. Mais les services auxquels il se connecte tombent temporairement en panne, l’authentification expire, et des données inattendues finissent toujours par arriver. Un flux qui n’a pas été conçu pour répondre à la question « que se passe-t-il en cas d’échec » accumule silencieusement les échecs et, dans le pire des cas, se retrouve désactivé automatiquement au bout de 14 jours¹. Cet article dresse un panorama des modèles de conception pour une gestion des erreurs suffisamment robuste pour la production : classification des échecs de flux, spécification exacte de la nouvelle tentative standard, modèle Try-Catch-Finally construit à partir d’étendues (Scope), mécanismes pour remarquer les échecs, ainsi que réexécution et idempotence. La répartition des rôles entre les différentes briques de Power Automate et la gestion des erreurs côté automatisation de l’interface utilisateur (flux de bureau) est traitée dans « Automatiser les processus métier avec Power Automate — flux cloud, flux de bureau et conception de la gestion des erreurs », cet article se concentre donc exclusivement sur les flux cloud.

1. L’essentiel à retenir

• Pensez les échecs selon quatre catégories : panne temporaire, origine liée aux données, autorisation/authentification expirée, et changement de spécification. La nouvelle tentative standard ne résout que la première ; les trois autres nécessitent un mécanisme de détection et de correction².
• La politique de nouvelle tentative standard ne se déclenche que lorsqu’une requête expire, ou échoue avec une réponse 408, 429 ou 5xx. Par défaut, elle suit un intervalle exponentiel (exponential backoff), et le nombre de tentatives est de 2 ou 12 au maximum, selon le niveau de licence (profil de performance)³¹.
• La forme de base de la gestion des erreurs est un Try-Catch-Finally construit à partir d’étendues (Scope) et de la « configuration de l’exécution après » (run after). La condition d’exécution se choisit parmi quatre états : Réussite, Échec, Ignoré et Délai expiré³⁴.
• Une fois l’échec traité dans Catch, terminez en enregistrant l’exécution comme « Failed » via une action Terminate. L’oublier fait apparaître l’exécution comme réussie dans l’historique, et l’échec est étouffé⁴³.
• L’e-mail de notification d’échec par défaut est limité aux « échecs disposant d’une solution connue » et assorti d’une période de récupération de 28 jours — un mécanisme trop troué pour s’y fier entièrement. Considérez comme obligatoire une notification que vous construisez vous-même depuis un bloc Catch⁵.
• L’historique d’exécution n’est visible que pendant 28 jours par défaut. Un flux qui continue d’échouer est désactivé automatiquement au bout de 14 jours. « Ne s’apercevoir de l’arrêt qu’un mois plus tard » est tout à fait possible, par conception⁶¹.
• Pour anticiper la réexécution (resoumission) et les déclenchements en double, intégrez dès le départ une conception idempotente, sûre même exécutée deux fois (indicateur de traitement, upsert plutôt que création, conditions de déclenchement)⁷⁸.

2. Comment un flux échoue-t-il ? Les quatre catégories d’échec

La conception de la gestion des erreurs s’organise plus facilement en partant d’une classification de « comment ça échoue ». Les recommandations de Microsoft demandent elles aussi de considérer que l’automatisation peut toujours échouer, et d’anticiper des situations telles que la maintenance du service connecté, des changements d’API, des changements de mot de passe ou des pannes réseau momentanées². En pratique, réfléchir selon les quatre catégories suivantes détermine directement la réponse à apporter.

Parmi celles-ci, la plus délicate en pratique est l’autorisation ou l’authentification expirée, car ce n’est plus seulement une action du flux qui échoue, mais le déclencheur lui-même. Le changement (ou l’expiration) du mot de passe utilisé par une connexion est cité par le guide de dépannage officiel comme un exemple typique de déclencheur échouant avec une erreur de la classe 4xx. Lorsque le déclencheur échoue, le flux ne démarre même pas, si bien que l’historique d’exécution ne conserve pas la moindre ligne « Échec », et l’on s’en aperçoit encore plus tard⁹. Comme une connexion est liée à l’utilisateur individuel qui l’a créée, le départ ou la mutation d’un responsable peut provoquer la rupture simultanée de plusieurs connexions. Les mesures organisationnelles à ce sujet sont détaillées dans « Lutter contre la dépendance à une seule personne dans Power Automate — conception des propriétaires, des connexions et de la passation ».

Il y a une autre chose à savoir : laisser les échecs sans réponse finit par arrêter le flux lui-même. Un flux dont le déclencheur ou les actions continuent d’échouer est automatiquement désactivé au bout de 14 jours, et un flux qui continue d’être limité en débit (throttling) l’est également au bout de 14 jours. Un flux qui n’a pas été déclenché pendant 90 jours peut aussi être désactivé, sauf si son propriétaire détient une licence premium ou de capacité¹. Par ailleurs, une violation de politique DLP ou des échecs répétés peuvent placer un flux à l’état « suspendu » (suspended)¹⁰. Une partie des cas de « flux qui fonctionnait, puis qui s’est arrêté » ne relève pas d’une panne, mais bien de cette règle de fonctionnement.

3. Comprendre la nouvelle tentative standard

Chaque action de Power Automate (dont le socle technique est Azure Logic Apps) intègre dès le départ une politique de nouvelle tentative. Connaître précisément cette spécification en amont permet de juger s’il faut ajouter une configuration de nouvelle tentative, ou si une nouvelle tentative ne résoudra tout simplement pas le problème.

Quoi, et quand, est retenté

La politique de nouvelle tentative se déclenche lorsque la requête d’une action (ou d’un déclencheur) expire, ou échoue avec une réponse 408 (délai de requête dépassé), 429 (trop de requêtes = limitation de débit) ou 5xx (erreur serveur)³. La politique par défaut est un intervalle exponentiel (exponential backoff — nouvelle tentative avec un intervalle qui s’allonge de façon exponentielle), et dans Power Automate, le nombre et l’intervalle par défaut dépendent du profil de performance du flux (qui correspond en pratique au niveau de licence)¹.

Autrement dit, pour une même définition de flux, la « résilience face aux pannes temporaires » varie selon la licence du propriétaire. Le profil influe non seulement sur le nombre de tentatives, mais aussi sur le plafond quotidien de requêtes ; pour approfondir cette question du niveau de licence, reportez-vous également à « Licences Power Automate et frontière entre connecteurs standards et premium ».

Vous pouvez modifier la politique de nouvelle tentative depuis les paramètres d’une action. Il existe quatre types — Par défaut, Aucune, Intervalle fixe et Intervalle exponentiel — permettant de spécifier explicitement le nombre de tentatives et l’intervalle. Les limites de configuration sont de 90 tentatives maximum, un intervalle minimal de 5 secondes et un délai maximal d’1 jour³¹. Les recommandations de codage de Microsoft préconisent l’intervalle exponentiel plutôt que l’intervalle fixe pour se remettre d’une panne temporaire, afin de ne pas continuer à solliciter l’autre partie à intervalles rapprochés et de ne pas gêner son propre rétablissement⁴.

Ce qu’une nouvelle tentative résout, et ce qu’elle ne résout pas

Un point à ne pas négliger : une nouvelle tentative consomme elle aussi du volume de requêtes (requêtes Power Platform). Chaque exécution d’action est comptabilisée dans le volume de requêtes, qu’elle réussisse ou échoue, et il en va de même pour les requêtes de nouvelle tentative et de pagination¹. Augmenter le nombre de tentatives en réponse à un 429 peut aggraver la limitation de débit ; avant de renforcer les nouvelles tentatives, examinez d’abord si le nombre d’appels lui-même peut être réduit.

4. Le modèle Try-Catch-Finally — étendues et configuration de l’exécution après

Un échec qu’une nouvelle tentative ne résout pas doit être capturé et traité à l’intérieur du flux. Power Automate ne dispose pas d’une syntaxe try-catch à proprement parler, mais on peut reconstruire la même structure en combinant une étendue (Scope) et la « configuration de l’exécution après » (run after). C’est le modèle classique recommandé par les propres recommandations de codage de Microsoft⁴.

Le socle de tout ce mécanisme est la configuration de l’exécution après. À la fin de son exécution, chaque action se trouve dans l’un des quatre états suivants : Réussite (Succeeded), Échec (Failed), Ignoré (Skipped) ou Délai expiré (TimedOut), et par défaut, l’action suivante ne s’exécute que « si l’action précédente a réussi ». Cette condition peut être modifiée action par action, ce qui permet de créer une branche qui s’exécute « en cas d’échec » ou « en cas de délai expiré »³.

Appliquez cela à une étendue, et vous obtenez un Try-Catch-Finally. Une étendue agrège le résultat de toutes les actions qu’elle contient en un seul état global, si bien qu’une structure du type « si quelque chose échoue quelque part dans l’étendue Try, exécuter l’étendue Catch » est infiniment plus facile à maintenir que de définir une condition sur chaque action individuellement³⁴.

flowchart TD
    Trigger[Déclencheur] --> Try[[Étendue Try<br/>Regrouper ici le traitement principal]]
    Try -- Succès --> Fin
    Try -- Échec / Délai expiré --> Catch[[Étendue Catch<br/>Exécution après : en cas d'échec ou d'expiration du délai]]
    Catch --> Extract[Fonction result + filtrage de tableau pour<br/>extraire l'action en échec et le motif]
    Extract --> Notify[Notifier le responsable via Teams / e-mail<br/>nom du flux, étape en échec, détail de l'erreur, URL d'exécution]
    Notify --> Fin[[Étendue Finally<br/>Exécution après : réussite, échec, ignoré et délai expiré, les quatre cas]]
    Fin --> Cleanup[Nettoyage : mise à jour de la colonne d'état du registre]
    Cleanup --> Judge{Passé par Catch ?}
    Judge -- Oui --> Term[Terminate<br/>État : Failed, fin de l'exécution]
    Judge -- Non --> Done([Fin normale])

Il y a quatre points clés dans la manière de construire cela.

• Choisissez à la fois « en cas d’échec » et « en cas de délai expiré » comme condition d’exécution de l’étendue Catch. Retirez le « en cas de réussite » par défaut. Ne sélectionner que l’échec laisse passer le délai expiré d’une attente d’approbation ou d’une action différée³.
• Extrayez le détail de l’échec à l’intérieur de Catch. La fonction result('NomDeVotreÉtendueTry') renvoie sous forme de tableau les résultats (état, entrées/sorties, corps de l’erreur) des actions directement contenues dans l’étendue ; en filtrant ce tableau (« filtrage de tableau ») sur les entrées dont l’état est Failed ou TimedOut, vous pouvez inclure dans la notification le nom de l’action en échec et son message d’erreur³⁴. Filtrer uniquement sur Failed fait revenir un résultat vide lorsque Catch a été atteint via un délai expiré, et l’étape en échec la plus importante disparaît alors de la notification. Il est également utile d’extraire l’ID d’exécution via la fonction workflow() pour construire une URL de lien direct vers l’historique d’exécution — cela facilite considérablement l’investigation⁴.
• Sélectionnez les quatre états comme condition d’exécution de l’étendue Finally. Placez-y le nettoyage que vous voulez toujours exécuter, que ce soit un succès ou un échec — suppression de fichiers temporaires, mise à jour de la colonne d’état du registre, etc.
• Terminez une exécution en échec par une action Terminate qui l’enregistre comme « Failed », en tout dernier lieu. C’est le point le plus facile à oublier. Si Catch se termine normalement, l’exécution du flux dans son ensemble se termine sur une dernière action réussie, et l’historique d’exécution l’enregistre comme « Réussite ». Autrement dit, si l’on se contente de notifier puis de s’arrêter là, l’échec devient invisible dans l’historique d’exécution et échappe à la surveillance comme aux agrégations ultérieures. En configurant l’état de Terminate sur Failed avec un message d’erreur avant de terminer, l’échec reste bien enregistré comme tel dans l’historique⁴³. Cependant, ne placez jamais Terminate directement à la fin de l’étendue Catch. Terminate met fin immédiatement à l’exécution entière à cet instant, si bien que l’étendue Finally qui suit ne s’exécute jamais, sautant précisément le nettoyage nécessaire en cas d’erreur. Comme le montre le schéma, faites en sorte que Catch se contente de lever un indicateur d’échec (une variable) et de s’arrêter à la notification, évaluez cet indicateur une fois le nettoyage de Finally passé, et ne terminez par Terminate que dans ce cas d’échec.

La configuration de l’exécution après est aussi l’élément central des branches de délai expiré d’un flux d’approbation (relances, escalade). La manière concrète de le construire est traitée dans « Créer un flux d’approbation dans Power Automate — numériser les circuits de validation papier et par e-mail ».

5. Un mécanisme pour remarquer les échecs — notification et visibilité

Construire la gestion des erreurs ne sert à rien si personne ne remarque l’échec. Concevez « un mécanisme pour remarquer » en plusieurs couches, plutôt que de vous reposer sur la notification par défaut.

Bien comprendre l’e-mail de notification d’échec par défaut

Power Automate dispose bien d’un mécanisme d’envoi d’e-mail de notification en cas d’échec, mais s’y fier sans en connaître les spécifications, c’est s’exposer à de nombreux trous. Il existe deux types de notification⁵.

• Alerte d’échec par exécution : envoyée juste après l’échec d’une exécution, mais uniquement lorsque l’échec est jugé avoir « une solution connue » — connexion rompue, limitation de débit, erreur de connecteur connue, etc. Elle n’est pas envoyée pour un échec d’action générique. Elle est adressée au propriétaire et aux copropriétaires (les utilisateurs d’exécution seule en sont exclus), jamais aux administrateurs. De plus, une fois qu’une alerte a été envoyée, le même flux entre dans une période de récupération de 28 jours, pendant laquelle aucune alerte supplémentaire n’arrive pour de nouveaux échecs. Les alertes par exécution ne sont pas non plus activées par défaut pour tous les flux ; il faut vérifier les paramètres du flux⁵.
• Digest hebdomadaire des échecs : un résumé des échecs sur tous les environnements est envoyé une fois par semaine. Il inclut aussi les échecs génériques pour lesquels aucune alerte par exécution n’a été envoyée⁵.

Par ailleurs, pour certaines erreurs, un e-mail de « conseils de réparation » comportant des étapes de correction est envoyé au propriétaire (et peut aussi être désactivé flux par flux)⁷. En résumé, la notification par défaut est un mécanisme où « l’on peut remarquer la première connexion rompue, mais un échec dû aux données métier ou un échec survenant une deuxième fois ou plus a tendance à passer à travers les mailles du filet ». Pour tout flux important, considérez comme obligatoire une notification que vous construisez vous-même depuis le bloc Catch du chapitre 4.

Concevoir la notification depuis Catch — le cas où la notification elle-même échoue

La notification que vous construisez vous-même a elle aussi ses points de conception.

• Ne l’adressez pas à un individu. L’envoyer à une seule personne fait qu’elle cesse d’arriver à quiconque dès que cette personne est absente ou a quitté l’entreprise. L’envoyer à une boîte aux lettres partagée ou à un canal Teams est justement ce que recommande la documentation officielle¹⁰.
• Séparez le chemin de la notification du traitement principal. Un accident courant est l’effondrement conjoint : le flux échoue parce que sa connexion Outlook est rompue, et la notification d’échec ne peut pas non plus être envoyée, car elle utilise cette même connexion Outlook. Lorsque la cause est une authentification expirée, l’action de notification qui partage cette même connexion échoue en même temps que tout le reste. Utiliser un connecteur et une connexion différents pour la notification que pour le traitement principal — une publication Teams, par exemple — ou séparer la notification dans un petit flux dédié appelé indépendamment, réduit le risque de cet effondrement conjoint. Cela dit, on ne peut pas construire indéfiniment « une notification pour la notification », d’où la vérification régulière décrite plus loin, en dernier rempart.
• Incluez dans la notification toutes les informations nécessaires à l’investigation. Le nom du flux, le nom de l’action en échec, le message d’erreur, un lien direct vers l’historique d’exécution. Sans cela, une notification n’apprend rien de plus que « quelque chose a échoué », et a tendance à être ignorée⁴.

Visibilité et vérifications régulières

• Vérificateur de flux (Flow checker) : détecte les erreurs et avertissements de la définition du flux avant l’enregistrement. Prenez l’habitude de le lancer une fois après avoir construit quelque chose¹¹.
• Vérification régulière de l’historique d’exécution : l’historique d’exécution d’un flux ne s’affiche que pendant 28 jours par défaut⁶. Un flux intégré à une solution peut conserver les métadonnées de son historique d’exécution dans Dataverse, mais la rétention par défaut y est aussi de 28 jours, et son extension relève d’un paramètre côté administrateur¹². Pour un flux en production, il est recommandé de vérifier environ une fois par semaine non seulement les échecs, mais aussi les « exécutions à l’état annulé » (qui peuvent être dues au contrôle de la concurrence) et une « chute soudaine du nombre d’exécutions » (signe que le déclencheur ne se déclenche plus)¹⁰.
• Surveillance centralisée par l’administrateur : pour voir absolument tous les échecs, y compris ceux pour lesquels aucun e-mail d’alerte par exécution n’est envoyé, la fonctionnalité Monitor (surveillance) du centre d’administration Power Platform est la plus exhaustive. Elle permet de consulter le nombre d’échecs et le détail des erreurs par flux ou par environnement⁵.

Pour un flux planifié, il faut aussi surveiller s’il s’est même déclenché. La conception d’une exécution planifiée incluant la vérification des jours ouvrés et le traitement de fin de mois est traitée dans « Concevoir les flux planifiés dans Power Automate — traitement de fin de mois, vérification des jours ouvrés et relances en pratique ».

6. Réexécution et idempotence — construire un flux qui « ne casse rien même exécuté deux fois »

Faire face à un échec ne s’arrête pas à sa détection. Il faut à la fois l’opération consistant à « refaire la partie qui a échoué » et une conception où « la refaire ne casse rien », les deux ensemble.

Les spécifications de la resoumission (resubmit)

Une exécution en échec peut être refaite depuis l’historique d’exécution via Resoumettre (Resubmit). Cette opération relance l’exécution avec les mêmes données de déclenchement : pour une panne temporaire (500/502, etc.), il suffit de resoumettre tel quel ; si la cause est une erreur dans la définition du flux, corrigez-la, enregistrez, puis resoumettez, et l’exécution repart avec la définition corrigée⁷. Depuis la liste de l’historique d’exécution, vous pouvez resoumettre jusqu’à 20 exécutions à la fois en bloc, ce qui est utile pour se rétablir après un échec massif. Pour un flux à déclenchement manuel (déclencheur instantané), vous pouvez toujours resoumettre vos propres exécutions, mais resoumettre une exécution déclenchée par un autre utilisateur nécessite qu’un administrateur l’autorise via un paramètre de locataire¹³.

Le point important ici, c’est que resoumettre relance le flux depuis le tout début. Resoumettre une exécution qui a échoué à l’étape 8 sur 10 relance aussi les étapes 1 à 7, qui avaient pourtant déjà réussi. C’est précisément la source d’accidents comme « l’e-mail avait déjà été envoyé, et il l’a été une seconde fois » ou « le registre s’est retrouvé avec deux fois la même ligne ».

Idempotence — une conception sûre même en cas de double exécution

C’est pourquoi il faut intégrer dès le départ une conception idempotente, où exécuter n’importe combien de fois avec la même entrée produit toujours le même résultat. C’est le cœur même de la conception des erreurs : elle protège non seulement contre la resoumission, mais aussi contre les déclenchements en double et les exécutions concurrentes.

• Conservez un indicateur de traitement. Ajoutez à un registre tel qu’une liste SharePoint une colonne « État » (Non traité / En cours / Traité) ; en début de flux, vérifiez l’état et arrêtez-vous immédiatement s’il est déjà traité, puis mettez l’état à jour une fois le traitement terminé. Cela fait, resoumettre ne provoque plus de double traitement. Mais cet indicateur ne fonctionne qu’à condition d’avoir aussi défini l’ordre des mises à jour. Pour un effet de bord externe tel qu’un envoi d’e-mail ou un enregistrement dans un système central, passez l’état à « En cours » juste avant de l’exécuter, puis à « Traité » une fois terminé. Une exécution qui échoue après l’effet de bord mais avant la mise à jour de l’indicateur reste bloquée à « En cours » — un état où l’on ne sait tout simplement pas si l’effet de bord a eu lieu. Resoumettre mécaniquement cette ligne peut provoquer un envoi en double ; excluez donc les lignes « En cours » de la réexécution automatique, et faites en sorte qu’une personne les rapproche du résultat réel de l’envoi ou de l’enregistrement avant de les repasser manuellement à « Traité » ou « Non traité ». Les seules lignes que l’on peut réexécuter sereinement sont celles restées à « Non traité ».
• Utilisez « mettre à jour si ça existe, créer sinon » (upsert) plutôt qu’une « création » inconditionnelle. Recherchez la ligne existante à partir d’une clé garantie unique (numéro de commande, identifiant de demande, etc.), et branchez vers une mise à jour en cas de correspondance, ou vers une création sinon. Une « Créer un élément » inconditionnelle empile des lignes en double à chaque réexécution. Inversement, des données sans clé unique ne peuvent pas être rendues idempotentes, ce qui suppose de décider de la colonne clé dès l’étape de conception du registre.
• Bloquez les déclenchements inutiles avec des conditions de déclenchement. Un déclenchement en boucle, comme un flux sur le déclencheur « Lorsqu’un élément est créé ou modifié » qui se redéclenche lui-même à cause de sa propre réécriture, doit être stoppé avec des conditions de déclenchement (trigger conditions), et non par une branche conditionnelle en aval. Un événement qui ne satisfait pas la condition de déclenchement ne provoque même pas d’exécution, et ne consomme donc ni exécution ni requête⁸.

Un point d’attention : une approche « vérifier puis écrire », comme l’indicateur de traitement ou l’upsert, fonctionne contre une reprise séquentielle telle qu’une resoumission, mais ce n’est pas, à elle seule, une protection atomique. Si deux événements de déclenchement en double se déclenchent presque simultanément, une situation de concurrence peut survenir où les deux exécutions lisent « Non traité » avant que les deux ne se mettent à traiter. Pour un flux où des déclenchements concurrents sont possibles, afin de prévenir les doublons de façon fiable, sérialisez avec le contrôle de la concurrence réglé sur un degré de parallélisme de 1 (voir plus loin), ou combinez cette approche avec un mécanisme côté stockage capable d’imposer une contrainte de clé unique (une contrainte d’unicité de base de données, par exemple), qui fait échouer une création en double au moment même de l’écriture.

Le compromis entre contrôle de la concurrence (concurrency control) et ordre

Aux côtés de la double exécution, « la concurrence » et « l’ordre » sont l’autre paire de problèmes. Par défaut, si un grand nombre d’événements satisfaisant la condition de déclenchement se produisent simultanément, le flux s’exécute en parallèle autant de fois que nécessaire¹. Lorsque plusieurs exécutions lisent et écrivent en même temps la même ligne d’un registre, une incohérence peut survenir où une valeur périmée est lue puis écrasée — une lecture sale (dirty read)¹⁴.

Activer le contrôle de la concurrence (Concurrency Control) dans les paramètres du déclencheur permet de spécifier un degré de parallélisme de 1 à 100. Réglez le degré de parallélisme sur 1, et une seule exécution a lieu à la fois, ce qui rapproche le traitement d’un ordre strict¹¹⁴. Cet interrupteur comporte cependant des mises en garde sérieuses.

• Une fois activé, impossible de revenir en arrière. Le seul moyen de le désactiver est de supprimer le déclencheur et de le recréer¹. Le contrôle de la concurrence étant irréversible, il est recommandé, si vous l’appliquez, de le limiter à un flux comportant peu d’actions (en l’extrayant dans un flux enfant si nécessaire)¹⁴.
• Cela crée un risque d’événements manqués. Avec le contrôle de la concurrence activé, le nombre d’exécutions pouvant être mises en attente est plafonné à « 10 + le degré de parallélisme » ; un déclenchement arrivant pendant que ce plafond est dépassé est retenté côté connecteur, mais si le dépassement se prolonge, il peut ne jamais aboutir à une exécution. La documentation officielle indique explicitement qu’un flux qui a besoin que chaque déclenchement aboutisse de façon fiable à une exécution doit laisser le contrôle de la concurrence désactivé¹. Si un historique d’exécution est truffé d’exécutions à l’état annulé, ce paramètre peut en être la cause¹⁰.

Autrement dit, « respecter l’ordre » et « ne rien manquer » sont un compromis. La sérialisation à un degré de parallélisme de 1 est efficace pour un traitement à faible volume où l’ordre compte — la numérotation séquentielle d’un registre, par exemple — mais elle ne doit pas être utilisée à la légère pour un traitement recevant un flot massif d’événements aux heures de pointe. Si l’ordre et l’exhaustivité sont tous deux strictement nécessaires en même temps, on entre, comme l’indique le chapitre 8, dans un territoire qu’il vaut mieux concevoir en dehors de Power Automate.

7. Liste de vérification de conception avant la mise en production

Avant de mettre un nouveau flux en production, vérifiez au minimum les points suivants.

Douze points, cela peut sembler beaucoup, mais plus de la moitié n’ont besoin d’être réfléchis qu’une seule fois, la première fois. À l’inverse, « rattraper le coup » sur un flux mis en production en ayant sauté cette étape reste, la plupart du temps, lettre morte — la peur de toucher à quelque chose qui fonctionne s’y ajoutant — jusqu’à ce qu’un incident survienne.

8. Jusqu’où aller avec Power Automate

À force de pousser la gestion des erreurs à fond, on voit apparaître des exigences qui dépassent le territoire de Power Automate. Voici quelques repères pour tracer la limite.

Comme repère de jugement, je considère grosso modo que tant que l’on peut expliquer oralement la procédure de récupération en cas d’échec, on reste dans le territoire de Power Automate ; le jour où l’on ne peut plus l’expliquer sans dessiner un schéma, on est passé dans le territoire du développement. C’est particulièrement vrai pour les métiers qui nécessitent une transaction compensatoire (enregistré dans le système de l’entreprise A, échoué dans celui de l’entreprise B — annule-t-on alors A ?) : ils sont plus complexes que ne le laisse penser l’apparence d’un flux, et Terminate suivi d’une notification ne suffit pas à les couvrir. L’arbitrage entre Power Automate, le Planificateur de tâches et PowerShell, y compris la façon de choisir entre eux, est détaillé dans « Choisir entre Power Automate, PowerShell et le Planificateur de tâches ».

9. Conclusion

« Le flux fonctionnait, puis il s’est arrêté » n’est presque jamais un coup de malchance — c’est presque toujours un problème de conception. Un flux finit toujours par échouer. Sur les quatre catégories d’échec, la nouvelle tentative ne prend en charge que les pannes temporaires ; les échecs d’origine données, l’authentification expirée et les changements de spécification ne peuvent être rattrapés que par un mécanisme en plusieurs couches : capture via Try-Catch, enregistrement via Terminate, notification construite soi-même, et vérification hebdomadaire de l’historique d’exécution. L’e-mail de notification d’échec par défaut est un mécanisme limité, conditionnel et assorti d’une période de récupération de 28 jours, et une exploitation qui s’y fie entièrement finit toujours par laisser passer quelque chose.

Et le véritable pilier de la préparation aux échecs n’est pas tant la notification que l’idempotence. En façonnant les choses pour qu’elles « ne cassent rien même exécutées deux fois », avec un indicateur de traitement et un upsert, ni la resoumission ni le déclenchement en double n’ont plus rien d’effrayant, et la récupération se résume à « choisir ce qui a échoué et resoumettre ». À l’inverse, pour un métier qui nécessite une transaction compensatoire ou une garantie d’ordre stricte, forcer la construction dans Power Automate n’est pas la bonne réponse ; décider de l’extraire vers un effort de développement revient moins cher à long terme. C’est précisément le jour où votre flux démarre qu’il faut parcourir cette liste de vérification une première fois.

Articles connexes

• Automatiser les processus métier avec Power Automate — flux cloud, flux de bureau et conception de la gestion des erreurs
• Concevoir les flux planifiés dans Power Automate — traitement de fin de mois, vérification des jours ouvrés et relances en pratique
• Créer un flux d’approbation dans Power Automate — numériser les circuits de validation papier et par e-mail
• Lutter contre la dépendance à une seule personne dans Power Automate — conception des propriétaires, des connexions et de la passation
• Choisir entre Power Automate, PowerShell et le Planificateur de tâches

Domaines de conseil connexes

Komura Software LLC intervient aussi bien sur la revue de la gestion des erreurs et de la conception opérationnelle des flux Power Automate, que sur la mise en système des exigences de garantie d’ordre et de transaction qu’un flux seul ne peut pas couvrir.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Si un flux Power Automate échoue, un e-mail de notification est-il envoyé automatiquement ?

De façon seulement limitée. L'e-mail d'alerte d'échec par exécution est envoyé au propriétaire et aux copropriétaires uniquement lorsque l'échec est jugé avoir « une solution connue », comme une connexion rompue ou une limitation de débit ; il n'est pas envoyé pour un échec d'action générique. De plus, une fois envoyée, la même alerte entre dans une période de récupération de 28 jours pour ce flux, pendant laquelle aucune alerte supplémentaire n'arrive. L'alerte d'échec par exécution n'est pas non plus activée par défaut pour tous les flux. Pour être certain de vous en apercevoir, nous recommandons d'intégrer votre propre notification vers Teams ou par e-mail depuis un bloc Catch.

Combien de fois, et à quels intervalles, la nouvelle tentative standard de Power Automate s'exécute-t-elle ?

Lorsque la requête d'une action expire ou échoue avec une réponse de la classe 408, 429 ou 5xx, elle est automatiquement retentée par défaut, avec un intervalle qui s'allonge de façon exponentielle. Le nombre de tentatives dépend du profil de performance du flux (qui correspond en pratique au niveau de licence) : jusqu'à 2 tentatives sur un profil bas comme une licence Microsoft 365, et jusqu'à 12 tentatives sur un profil moyen ou élevé comme Power Automate Premium ou une licence Process. Vous pouvez modifier la politique de nouvelle tentative dans les paramètres de l'action pour la régler sur « Aucune », « Intervalle fixe » ou « Intervalle exponentiel », et configurer le nombre de tentatives jusqu'à 90 maximum. Les erreurs d'origine données ou configuration, comme 400 ou 404, ne font pas l'objet de nouvelles tentatives.

Comment refaire (resoumettre) une exécution de flux qui a échoué ?

Ouvrez l'exécution en échec depuis l'historique d'exécution et choisissez « Resoumettre » : l'exécution repart avec les mêmes données de déclenchement. Si la cause est une erreur dans la définition du flux, corrigez le flux, enregistrez, puis resoumettez, et l'exécution repart avec le contenu corrigé. Depuis la liste de l'historique d'exécution, vous pouvez resoumettre jusqu'à 20 exécutions à la fois en bloc. Le point d'attention est que la resoumission relance le flux depuis le tout début : pour une exécution qui avait partiellement réussi, les traitements déjà effectués avec succès sont exécutés une seconde fois. Il faut donc prévoir une conception idempotente, dont le résultat ne se casse pas même en cas de double exécution (indicateur de traitement, écriture privilégiant la mise à jour plutôt que la création).

Un flux peut-il être désactivé à l'insu de tous ?

Oui. Un flux dont le déclencheur ou les actions continuent d'échouer est automatiquement désactivé au bout de 14 jours. Un flux qui continue de subir une limitation de débit (dépassement de quota) est lui aussi désactivé au bout de 14 jours. Un flux jamais déclenché pendant 90 jours peut également être désactivé, sauf si son propriétaire détient une licence premium ou de capacité. Comme laisser les échecs sans réponse conduit directement à l'arrêt du flux, il est important d'intégrer à l'exploitation à la fois un mécanisme pour remarquer les échecs et une vérification régulière de l'historique d'exécution (28 jours par défaut).

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.