Power Automate : lire l'historique des exécutions et trouver les erreurs

Un flux ne s'exécute pas comme prévu, mais la cause exacte est rarement évidente au premier coup d'œil. Power Automate enregistre chaque exécution dans l'historique des exécutions, y compris l'heure de début, la durée, le statut et, en cas d'échec, l'étape exacte où cela a coincé. Si vous savez où se trouvent ces informations et comment les lire, vous trouverez généralement la cause en quelques minutes plutôt qu'après de longs tâtonnements.

Cet article vous montre où ouvrir l'historique des exécutions dans Power Automate, comment lire une exécution échouée étape par étape, et quels codes d'erreur et erreurs d'expression reviennent le plus souvent dans la pratique. Vous gardez ainsi le contrôle de vos flux, même quand quelque chose ne va pas.

Où trouver l'historique des exécutions

Connectez-vous sur make.powerautomate.com puis sélectionnez à gauche Mes flux. Dans la ligne du flux concerné, ouvrez directement le flux ou utilisez le menu à trois points pour accéder à la page Détails. Vous y trouverez la section Historique des exécutions (aussi appelée Historique des exécutions sur 28 jours dans les interfaces plus anciennes), qui liste chaque exécution sur sa propre ligne avec l'heure de début, la durée et le statut. Une coche verte signifie un succès, un point d'exclamation rouge signifie une erreur.

Bon à savoir : par défaut, Power Automate ne conserve les données d'exécution que pendant 28 jours. Si votre flux s'exécute rarement, ou si vous avez besoin que l'historique reste consultable plus longtemps, il vaut la peine de se pencher sur les détails, car les anciennes exécutions deviennent tout simplement introuvables ensuite. Microsoft décrit ces détails, y compris la possibilité de conserver l'historique des exécutions plus longtemps via Dataverse, dans l'article Historique des exécutions ou des déclencheurs manquant pour un flux.

Lire une exécution échouée étape par étape

Cliquez sur la date de début de l'exécution échouée dans la liste pour accéder à la vue détaillée. Le flux complet y apparaît comme une chaîne d'actions, et au moins une étape est marquée d'un point d'exclamation rouge. C'est le point de défaillance réel ; toutes les actions précédentes se sont déroulées avec succès.

• Cliquez sur l'étape marquée pour la développer.
• Dans le panneau de droite, sous Détails, vous voyez le code de statut et le message d'erreur précis du connecteur.
• Vérifiez également les onglets Entrées et Sorties des étapes précédentes, car la cause réelle ne se trouve souvent pas dans l'étape échouée elle-même, mais dans une valeur incorrecte ou vide transmise depuis plus haut.
• Si l'erreur se produit dans un bloc Scope, plusieurs actions suivantes peuvent être marquées comme « ignorées ». C'est normal, car un Scope échoué interrompt toutes les actions dépendantes imbriquées à l'intérieur.

Pour ceux qui préfèrent une approche structurée plutôt que de cliquer au hasard, Microsoft a publié une sorte d'arbre de décision : selon que le flux ne s'enregistre pas du tout, ne se déclenche pas, qu'une action échoue ou qu'il produise simplement un résultat incorrect, l'article Résolution des problèmes liés aux erreurs de flux cloud renvoie à la section correspondante avec des étapes de vérification concrètes.

Les codes d'erreur les plus importants en un coup d'œil

La plupart des erreurs d'une action échouée peuvent être classées approximativement grâce au code de statut, avant même de lire le message d'erreur en détail.

| Code | Signification | Première vérification |

| --- | --- | --- |

| 401 | Échec de l'authentification | Réauthentifiez la connexion sous Connexions |

| 403 | Accès refusé | Vérifiez les autorisations sur la ressource cible, puis clarifiez les stratégies DLP avec l'administrateur |

| 404 | Ressource introuvable | La liste SharePoint, le fichier, la boîte aux lettres ou le point de terminaison a été renommé, déplacé ou supprimé |

| 429 | Trop de requêtes (limite de débit) | Ajoutez un délai ou activez la nouvelle tentative avec backoff dans les paramètres de l'action |

| 500 / 502 | Erreur serveur du service cible | Généralement temporaire, relancez l'exécution via Soumettre à nouveau |

Les codes de la plage 400 indiquent presque toujours un problème avec votre propre configuration, tandis que les codes de la plage 500 signalent plutôt un problème temporaire du service appelé et se résolvent souvent simplement en relançant l'exécution.

Reconnaître et classer les erreurs d'expression

Deux messages d'erreur reviennent particulièrement souvent dans l'historique des exécutions : « Invalid template » ou « Unable to process template language expressions », ainsi que « ExpressionEvaluationFailed ». Les deux signifient qu'une expression est syntaxiquement incorrecte ou fait référence, au moment de l'exécution, à une valeur qui n'existe pas du tout. Les causes typiques sont :

• Une référence à un contenu dynamique provenant d'une étape qui n'a pas été exécutée du tout en raison d'une condition non remplie.
• Un type de données incorrect, par exemple une chaîne de caractères là où un nombre est attendu.
• Une valeur vide ou nulle traitée sans protection en amont. Une fonction `coalesce()` ou une vérification `if(empty(...))` en amont permet de l'intercepter.

Si l'historique indique plutôt « ActionFailed. An action failed. No dependent actions succeeded. », c'est généralement un bloc Scope parent qui est le véritable déclencheur. Plutôt que d'examiner individuellement chacune des actions suivantes marquées comme échouées, il vaut mieux rechercher spécifiquement la première action échouée à l'intérieur du Scope, car c'est là que se trouve la cause réelle.

Quand le flux s'exécute mais que le résultat est incorrect

Toutes les erreurs ne se manifestent pas par un point d'exclamation rouge. Parfois, le flux s'exécute entièrement en vert, mais le résultat final est incorrect, par exemple un e-mail d'approbation non envoyé ou un champ mal rempli. Dans ce cas, la recherche classique des erreurs rouges ne sert à rien ; vous devez plutôt parcourir chaque action individuellement et comparer les entrées aux sorties.

• Dans les conditions, vérifiez les valeurs réellement comparées. Les pièges courants sont les espaces en début de chaîne, la casse (« Approuvé » contre « approuvé ») ou une valeur numérique arrivant sous forme de chaîne de caractères.
• Pour une boucle Appliquer à chacun, il vaut la peine d'examiner l'entrée que la boucle parcourt. Si le tableau contient plus ou moins d'éléments que prévu, le problème se situe généralement déjà dans l'étape de récupération précédente.
• Si le flux met à jour un enregistrement puis le relit immédiatement après, un court délai de quelques secondes entre l'écriture et la lecture peut être nécessaire pour éviter que des données obsolètes ne soient renvoyées.
• Pour un débogage ciblé, des actions Compose insérées à des points clés du flux sont utiles. Elles affichent exactement la valeur que vous souhaitez vérifier et peuvent être consultées ultérieurement dans l'historique des exécutions, sans modifier le flux lui-même.

Microsoft décrit ces scénarios et d'autres en détail, avec des exemples concrets d'erreurs d'authentification et de dépannage assisté par Copilot dans le nouveau concepteur, dans l'article Résolution des problèmes d'un flux cloud.

Quand il vaut la peine de consulter la communauté

Tous les messages d'erreur ne sont pas sans ambiguïté, surtout avec des combinaisons inhabituelles de connecteur et de source de données. Dans ces cas, il est généralement plus rapide de copier le texte exact de l'erreur et de le rechercher dans les forums communautaires de Power Automate sur powerusers.microsoft.com plutôt que d'essayer soi-même toutes les causes possibles. Souvent, quelqu'un d'autre a déjà publié exactement le même message d'erreur et trouvé une solution qui fonctionne.

Quiconque parcourt régulièrement l'historique des exécutions développe rapidement un sens de ce qui est anodin et de ce qui est structurel. Pour ceux qui préfèrent un regard extérieur expérimenté ou souhaitent qu'un flux soit conçu de manière robuste dès le départ, le conseil Power Automate de NordFlux offre un interlocuteur unique à prix fixe, sans feuilles de temps.

Questions fréquentes

Combien de temps une exécution échouée reste-t-elle visible dans l'historique des exécutions ?

28 jours par défaut. Ensuite, l'exécution disparaît de l'historique normal des exécutions, même si le flux lui-même continue d'exister. Ceux qui ont besoin d'une traçabilité plus longue peuvent conserver l'historique des exécutions via la connexion Dataverse ou documenter manuellement les détails de l'erreur avant leur suppression.

Pourquoi plusieurs étapes après l'erreur réelle sont-elles marquées comme ignorées ?

Cela se produit généralement lorsque l'erreur survient à l'intérieur d'un bloc Scope. Si une action à l'intérieur échoue, toutes les actions en aval qui en dépendent, dans le même bloc, sont automatiquement interrompues et affichées comme ignorées. La cause réelle se trouve presque toujours dans la première action échouée à l'intérieur du Scope.

Que signifie un code d'erreur 429 dans l'historique des exécutions ?

Un code 429 indique que le service appelé a reçu trop de requêtes en trop peu de temps et rejette donc la requête. La solution habituelle consiste à ajouter un court délai avant l'étape concernée ou à activer une logique de nouvelle tentative avec backoff dans les paramètres de l'action.

Le flux s'exécute entièrement en vert, mais rien de visible ne se produit. Quelle en est la raison ?

Dans ce cas, il ne s'agit généralement pas d'une erreur technique, mais d'un problème de logique, par exemple une condition qui s'évalue différemment de ce qui était prévu, ou une boucle qui rencontre un tableau vide. Il est utile d'ouvrir chaque action de l'historique individuellement et de comparer les entrées et sorties réelles avec vos attentes.

Dois-je redémarrer tout le flux à chaque exécution échouée ?

Non. Dans la vue détaillée d'une exécution échouée, l'option Soumettre à nouveau est disponible. Elle relance l'exécution avec les mêmes données d'entrée une fois que vous avez corrigé la cause sous-jacente, par exemple en réauthentifiant une connexion ou en corrigeant une action défectueuse.