Power Automate : détecter les erreurs silencieuses en production

Pourquoi un flux « Succeeded » peut-il être un échec métier ?

Dans Power Automate, le statut d'exécution mesure l'exécution technique des actions, pas l'atteinte de l'objectif métier. Un flux qui parcourt une collection vide, qui écrit dans une liste déjà supprimée ou qui saute une branche conditionnelle se termine en « Succeeded » sans avoir rien produit. Aucune alerte n'est envoyée, aucune exécution rouge n'apparaît dans l'historique : l'erreur est silencieuse et se découvre des semaines plus tard, quand un utilisateur signale une donnée manquante.

Ces échecs ne se corrigent pas en ajoutant des blocs « Configurer l'exécution après » : ils se corrigent en rendant explicite ce que le flux devait produire, puis en vérifiant ce qu'il a réellement produit.

Comment détecter une boucle qui tourne sur une collection vide ?

Une action Apply to each dont l'entrée est un tableau vide ne lève aucune erreur : elle exécute zéro itération et rend la main. Le comportement de la boucle est documenté par Microsoft dans Appliquer à chacun.

La parade consiste à compter les éléments avant la boucle avec la fonction length() du langage de définition de workflow, puis à interrompre explicitement le flux si le compte est nul.

Expression à placer dans une action Compose nommée NbElements :

length(outputs('Obtenir_les_elements')?['body/value'])

Condition à évaluer juste après, en mode expression :

equals(outputs('NbElements'), 0)

Dans la branche « si oui », placez une action Terminate configurée en échec. Le JSON de l'action, visible via l'éditeur de code, est le suivant :

{
  "type": "Terminate",
  "inputs": {
    "runStatus": "Failed",
    "runError": {
      "code": "AucunElement",
      "message": "La requete n'a retourne aucun element : verifier le filtre ou la source."
    }
  }
}

Le flux apparaît alors en rouge dans l'historique, avec un message lisible. C'est l'usage de l'action Terminate décrit dans les directives Microsoft de gestion des erreurs.

Comment contrôler la cohérence entre l'entrée et la sortie ?

Le contrôle le plus utile n'est pas « est-ce que ça a marché », mais « est-ce que le nombre d'objets traités correspond au nombre d'objets attendus ». Incrémentez une variable entière Traites dans la boucle, puis comparez en fin de flux avec la fonction sub() :

sub(outputs('NbElements'), variables('Traites'))

Si le résultat est différent de zéro, des éléments ont été ignorés. Une condition sur cette expression suffit :

greater(sub(outputs('NbElements'), variables('Traites')), 0)

L'écriture d'expressions dans les conditions est décrite dans Utiliser des expressions dans les conditions.

Un point d'attention : si le contrôle de concurrence est activé sur la boucle, l'incrémentation d'une variable partagée n'est pas fiable. Microsoft précise dans les limites et la configuration de Power Automate que le contrôle de concurrence est désactivé par défaut et que son activation ne peut pas être annulée sans supprimer puis rajouter le déclencheur. Sur un flux qui compte ses traitements, laissez-le désactivé.

Que se passe-t-il quand une connexion expire ?

Un flux repose sur des connexions liées au compte qui les a créées. Quand le mot de passe change, quand l'utilisateur quitte l'entreprise ou quand le consentement est révoqué, la connexion doit être réautorisée ; la gestion des connexions est décrite dans Ajouter et gérer les connexions et dans la documentation des connecteurs.

La conséquence opérationnelle figure dans les limites de Power Automate : un flux cloud dont le déclencheur ou les actions échouent continuellement est désactivé par la plateforme. Le flux ne s'arrête donc pas seulement de fonctionner, il disparaît des exécutions.

Deux règles de conception limitent l'exposition :

• faire porter les connexions par un compte de service dédié plutôt que par le compte d'un développeur ;
• déployer les flux en solution, ce qui permet de gérer les références de connexion indépendamment du contenu, comme décrit dans Créer un flux cloud dans une solution et dans les bases de l'ALM Power Platform.

Quelles limites de plateforme désactivent un flux sans prévenir ?

Trois mécanismes documentés dans les limites et la configuration de Power Automate désactivent un flux sans qu'aucune exécution n'échoue visiblement :

Mécanisme	Règle documentée par Microsoft	Effet
Inactivité	Un flux cloud non déclenché pendant 90 jours peut être désactivé. Les propriétaires et copropriétaires sont avertis 30 jours avant la suspension. Les flux appartenant à des utilisateurs disposant de licences Premium ou de capacité attribuée (Power Automate Process, par flux) ne sont pas soumis à cette suspension.	Le flux ne se déclenche plus
Dépassement durable des limites	Un flux qui reste constamment au-dessus des limites pendant 14 jours est désactivé par le système.	Le flux est coupé
Limitation de débit	Un flux systématiquement limité est désactivé ; Microsoft recommande d'attribuer une licence Power Automate Process pour disposer d'une capacité dédiée.	Le flux est coupé

À cela s'ajoute une limite qui piège les processus d'approbation : la durée d'exécution inclut les étapes en attente et, après 30 jours, toutes les étapes en attente expirent. Une approbation oubliée ne remonte jamais d'erreur métier, elle expire.

Le volume d'appels autorisé dépend des licences affectées ; les allocations sont détaillées dans Limites de demandes d'API et allocations.

Comment mettre en place une surveillance qui remonte les échecs silencieux ?

La surveillance utile ne consiste pas à regarder l'historique des exécutions, mais à faire remonter le flux lui-même quand son résultat métier est vide ou incomplet. Le schéma minimal, applicable à tout flux de production :

1. compter les éléments en entrée avec length() ;
2. compter les éléments réellement traités dans une variable ;
3. comparer les deux avec sub() en fin de flux ;
4. terminer en Failed avec un message explicite via l'action Terminate en cas d'écart ;
5. encadrer les actions sensibles par une portée et une branche configurée sur « a échoué », selon les directives de gestion des erreurs.

Sur les flux de bureau, la logique est équivalente mais les mécanismes diffèrent : voir Gestion des erreurs dans les flux de bureau.

Le pilotage sur la durée relève ensuite de la gouvernance : cadrage des environnements (Vue d'ensemble des environnements) et stratégie de support (Stratégie de support Power Platform).

FAQ

Un flux Power Automate en statut « Succeeded » peut-il avoir échoué ?

Oui. Le statut décrit l'exécution technique des actions, pas le résultat métier. Une boucle qui reçoit une collection vide effectue zéro itération et se termine en succès. Le seul moyen de détecter ce cas est de compter les éléments en entrée avec length() et de terminer le flux en échec via l'action Terminate lorsque le compte est nul.

Au bout de combien de temps Power Automate désactive-t-il un flux inactif ?

Microsoft documente qu'un flux cloud non déclenché pendant une période de 90 jours peut être désactivé, avec une notification aux propriétaires et copropriétaires 30 jours avant la suspension. Les flux appartenant à des utilisateurs disposant de licences Premium ou de capacité attribuée (Power Automate Process, par flux) ne sont pas soumis à cette suspension.

Que se passe-t-il si un flux dépasse durablement les limites de la plateforme ?

L'activité du flux ralentit puis reprend automatiquement lorsqu'elle repasse sous la limite. En revanche, un flux qui reste constamment au-dessus des limites pendant 14 jours est désactivé par le système, tout comme un flux systématiquement limité en débit.

Pourquoi une connexion expirée peut-elle faire disparaître un flux ?

Une connexion révoquée ou non réautorisée fait échouer le déclencheur ou les actions. Or Microsoft indique qu'un flux cloud dont le déclencheur ou les actions échouent continuellement est désactivé. Faire porter les connexions par un compte de service et déployer en solution avec des références de connexion réduit ce risque.

Combien de temps une approbation en attente reste-t-elle valide ?

La durée d'exécution inclut les étapes en attente comme les approbations, et après 30 jours toutes les étapes en attente expirent. Une approbation oubliée n'apparaît pas comme une erreur : elle expire silencieusement.