Gérer les erreurs et exceptions dans Power Automate

Une erreur dans Power Automate, c’est une action qui échoue et qui peut arrêter tout un flux : un service indisponible, une connexion expirée, une donnée mal formée. La gérer consiste à prévoir ce qui se passe dans ces cas-là : réessayer, emprunter un autre chemin, prévenir quelqu’un. Dans une entreprise, cela fait la différence entre une panne repérée tout de suite et une panne découverte une semaine plus tard, par un client.

Pourquoi un flux en panne coûte cher sans qu’on le voie

Prenons une situation type. Un flux transmet chaque commande validée au service expédition. Un vendredi, la connexion du compte qui l’a créé expire. Le flux échoue sans bruit, et les commandes s’empilent. On s’en aperçoit le mardi, quand un client appelle.

Le risque n’est pas l’erreur elle-même : tout système connecté en rencontre. Le risque, c’est qu’elle passe inaperçue. D’autant qu’un flux dont le déclencheur ou les actions échouent en continu est désactivé au bout de 14 jours, selon les limites officielles de Power Automate.

Un flux bien protégé fait trois choses : il se répare seul quand le problème est passager, il prévient la bonne personne quand ce n’est pas le cas, et il garde la trace de ce qu’il n’a pas traité. La suite de ce guide montre comment y parvenir.

Reconnaître le type d’erreur

Le remède dépend de la cause. Dans l’historique d’exécution, ouvrez l’action en rouge et lisez son code et son message.

Laisser le flux réessayer

Beaucoup de pannes sont passagères. La stratégie de nouvelle tentative les règle sans intervention. Elle se trouve dans les Paramètres de chaque action, sous Stratégie de nouvelle tentative.

Le réglage par défaut est déjà généreux : jusqu’à 12 nouvelles tentatives à intervalles croissants, jusqu’à environ une heure pour la dernière (seulement 2 en profil de performance bas). Vous pouvez aussi choisir un intervalle fixe, un intervalle exponentiel ou aucune tentative. Microsoft recommande l’intervalle exponentiel, qui laisse au service le temps de se rétablir. Les limites sont de 90 tentatives, avec un délai minimum de 5 secondes et un délai maximum d’un jour.

Les intervalles s’écrivent au format ISO 8601 : PT10S pour 10 secondes, PT5M pour 5 minutes. Trois précautions :

• Une action qui crée quelque chose peut produire un doublon si elle a réussi côté serveur alors que la réponse s’est perdue. Prévoyez une clé unique ou un contrôle préalable.
• Chaque tentative compte dans vos requêtes.
• Pendant les tentatives, le flux attend. Si une alerte rapide compte plus que la persistance, réduisez leur nombre.

Pour éviter une attente trop longue, réglez aussi le Délai d’expiration de l’action, par exemple PT2M. Une requête synchrone sortante reste de toute façon limitée à 120 secondes.

Prévoir un autre chemin

Exécuter après

Par défaut, une action ne s’exécute que si la précédente a réussi. Le réglage Exécuter après, dans les paramètres de l’action, change cela. Vous pouvez cocher quatre états de l’action précédente : a réussi, a échoué, est ignoré et a expiré. Une action réglée sur « a échoué » et « a expiré » ne se déclenche que si quelque chose s’est mal passé : elle peut envoyer une alerte ou écrire dans un journal.

Le modèle Try et Catch avec des étendues

Une étendue (Scope en anglais) regroupe plusieurs actions dans un bloc. C’est le moyen le plus propre de traiter les erreurs d’un ensemble d’actions sans régler chacune d’elles.

1. Placez vos actions métier dans une étendue nommée Try.
2. Ajoutez une seconde étendue, Catch, juste après.
3. Réglez Exécuter après de Catch sur « a échoué » et « a expiré », et décochez « a réussi ».
4. Dans Catch, récupérez les détails de l’erreur, journalisez-la et envoyez l’alerte.
5. Terminez Catch par l’action Terminer, avec l’état Échec et un message clair.

Ce dernier point est souvent oublié. Si Catch se termine correctement, tout le flux apparaît en réussite dans l’historique, et l’erreur disparaît des statistiques. L’action Terminer propose trois états : réussite, échec ou annulé.

Pour savoir quelle action a échoué, la fonction result renvoie le résultat de toutes les actions d’une étendue. Ajoutez une action Filtrer un tableau dans Catch, avec comme source :

result('Try')

et comme condition, en mode avancé :

@equals(item()?['status'], 'Failed')

Vous pouvez ensuite lire le nom et le code de l’action en échec, ou conserver le détail complet sous forme de texte :

first(body('Filtrer_un_tableau'))?['name']
first(body('Filtrer_un_tableau'))?['code']
string(body('Filtrer_un_tableau'))

Vérifier les données avant de les traiter

Une bonne partie des erreurs de données s’évite par une simple vérification en début de flux. Pour construire ces tests, reportez-vous à notre guide sur les conditions dans les flux. Les expressions, elles, sont détaillées dans le guide des expressions Power Automate.

• empty(triggerBody()?['Email']) vaut vrai si le champ est vide. Le ? empêche une erreur si le champ n’existe pas.
• coalesce(triggerBody()?['Quantite'], 0) remplace une valeur nulle par une valeur par défaut.
• and(greater(triggerBody()?['Prix'], 0), less(triggerBody()?['Quantite'], 10000)) contrôle une plage acceptable. Un prix négatif ou une quantité anormale méritent un traitement à part, pas un enregistrement silencieux.

Attention aussi aux boucles : une valeur vide dans une ligne parmi mille fait échouer ce tour seulement, mais la boucle finit marquée en échec. Voyez comment utiliser Apply to each et Do until efficacement.

Journaliser, alerter, entretenir les connexions

Garder une trace utile

Une liste SharePoint ou une table Dataverse suffit à tenir un journal d’erreurs. Notez le nom du flux, l’heure, l’action concernée, le message et un lien vers l’exécution. Ce lien se construit avec la fonction workflow, qui décrit le flux en cours :

concat('https://make.powerautomate.com/environments/', workflow()?['tags']?['environmentName'], '/flows/', workflow()?['name'], '/runs/', workflow()?['run']?['name'])

Ne journalisez pas tout. Microsoft met en garde : trop d’actions de suivi finissent par alourdir le flux. Réservez cela aux étapes critiques, ou utilisez Application Insights, le service de surveillance d’Azure, si vous avez beaucoup de flux à suivre.

Prévenir sans noyer

Si chaque petite anomalie déclenche une alerte, plus personne ne les lit. Séparez trois niveaux :

• Erreur bloquante : intervention nécessaire, message Teams ou e-mail à une personne nommée.
• Erreur récupérée : le flux s’est débrouillé, mais il faut en garder trace, avec un message dans un canal d’équipe.
• Anomalie mineure : une ligne dans le journal, sans notification.

Pour le canal d’alerte, sachez que les notifications de l’application mobile Power Automate ont disparu avec celle-ci en août 2026. Voici ce qui fonctionne désormais pour alerter sur un téléphone. Power Automate envoie aussi lui-même des e-mails aux propriétaires des flux pour les pannes courantes, comme une connexion rompue ou une limitation. Vérifiez que cette boîte est bien lue.

Entretenir les connexions

Les connexions se contrôlent dans le menu Connexions du portail, où celles qui posent problème sont signalées. Réparez-les avant qu’elles n’arrêtent un flux, et passez en revue ceux qui comptent chaque mois.

Pour un flux critique, évitez qu’il dépende du compte d’un salarié : s’il quitte l’entreprise, le flux tombe. Utilisez un compte de service dédié, muni de la bonne licence, et ajoutez un second propriétaire. Pensez aussi à l’expiration par inactivité : un flux qui n’a pas été déclenché pendant 90 jours peut être désactivé, sauf licence Premium ou Process, avec un avis 30 jours avant. Déployer vos flux dans des solutions Power Platform facilite le changement de connexion entre le test et la production.

Tester les cas qui posent problème

Un flux testé seulement avec des données propres n’est pas testé. Avant la mise en service :

1. Essayez les cas limites : champ vide, valeur nulle, date inhabituelle, caractères spéciaux dans un nom de fichier, très longue liste.
2. Provoquez une vraie erreur, par exemple en pointant vers un fichier inexistant, pour vérifier que Catch se déclenche et que l’alerte arrive.
3. Vérifiez que le flux apparaît bien en échec dans l’historique.
4. Consultez la durée et le nombre d’actions : un flux trop lent en test le sera davantage en production.

Pour réduire les délais dépassés et les limitations, demandez moins de données : un filtre OData sur l’action de lecture vaut mieux que de tout récupérer pour trier ensuite. L’exécution d’un flux reste de toute façon limitée à 30 jours, y compris les étapes en attente comme une approbation. Si vous débutez, commencez par ce guide pour automatiser vos tâches quotidiennes avec Power Automate Cloud.

Quand confier la fiabilité d’un flux à un expert

Pour un flux personnel ou un rappel d’équipe, une nouvelle tentative et une alerte par e-mail suffisent, et vous pouvez les mettre en place seul. Faire appel à un expert devient raisonnable quand un flux touche à la facturation, à la paie ou à des clients, quand une panne se voit d’abord à l’extérieur, ou quand vous avez assez de flux pour ne plus savoir lesquels surveiller. Un regard extérieur sert aussi lorsque les pannes reviennent sans cause claire. Notre page sur l’automatisation avec Power Automate et ce qu’elle change pour vos équipes situe ces enjeux.

Questions fréquentes

Comment savoir si mes connexions sont toujours valides ?

Ouvrez le menu Connexions sur le portail Power Automate : celles qui nécessitent une action y sont signalées. Power Automate envoie aussi des alertes aux propriétaires en cas de connexion rompue. Pour les flux critiques, faites ce contrôle chaque mois et préférez un compte de service à un compte personnel.

Combien de nouvelles tentatives configurer ?

Commencez par le réglage par défaut, qui va jusqu’à 12 tentatives à intervalles croissants hors profil de performance bas. Réduisez-le si vous devez réagir vite ou si l’action risque de créer des doublons. Si vous fixez vous-même la stratégie, préférez l’intervalle exponentiel, et testez-le sur votre service.

Quelle est la différence entre les trois états de l’action Terminer ?

Réussite indique que le flux s’est achevé normalement, même s’il s’arrête avant la fin. Échec signale un problème bloquant et apparaît comme tel dans l’historique. Annulé marque un arrêt volontaire, par exemple quand un contrôle montre qu’il n’y a rien à traiter.

Pourquoi mes flux dépassent-ils le délai sur les gros fichiers ?

Le service visé met trop de temps à répondre, ou le traitement est trop lourd. Filtrez les données à la source, découpez le travail en plusieurs exécutions et réglez le délai d’expiration de l’action. Sur Excel, les recalculs d’un classeur chargé sont une cause classique : le passage en calcul manuel peut aider.

Comment éviter les erreurs de format de données ?

Contrôlez les données avant de les utiliser, avec empty pour les champs vides et coalesce pour fixer une valeur par défaut. Convertissez explicitement les types, par exemple avec int ou formatDateTime. Testez enfin avec de vraies données imparfaites, pas seulement avec un jeu d’essai propre.

Où stocker les informations d’erreur ?

Une liste SharePoint ou une table Dataverse convient à la plupart des équipes. Notez au moins le flux, l’heure, l’action, le message et le lien vers l’exécution. Avec beaucoup de flux, Application Insights offre une surveillance centralisée, sans ajouter d’actions dans chaque flux.