Optimisation des performances des flux Power Automate

Un flux Power Automate qui prend plusieurs minutes pour une tâche qui pourrait en réalité être effectuée en quelques secondes ne coûte pas seulement du temps. Il consomme inutilement une grande partie des demandes d'actions limitées de votre plan, multiplie les erreurs de délai d'attente dans les systèmes en aval et complique le diagnostic, car chaque exécution doit parcourir davantage d'étapes. La bonne nouvelle : la plupart des problèmes de performance dans Power Automate se ramènent à trois leviers, que Microsoft documente en détail dans ses propres directives de codage. Situation en juillet 2026.

Cet article résume comment tu peux construire des flux nettement plus rapides grâce à un parallélisme ciblé, à la réduction des actions inutiles et au bon choix de connecteur ou de données, en te basant sur la documentation officielle de Microsoft pour Power Automate. Tu gardes ainsi le contrôle sur le levier qui a le plus grand effet pour ton flux concret, au lieu de tourner au hasard des réglages qui ne changent presque rien.

Pourquoi les flux deviennent-ils lents ?

Avant d'optimiser, il vaut la peine de regarder la cause. D'après le guide sur Diagnostiquer les problèmes de performance, de nombreux flux ralentis atteignent tout simplement leurs limites quotidiennes Power Automate. L'analyse des actions dans « Mes flux » te montre combien de demandes d'actions un flux consomme réellement, et Power Automate avertit même les propriétaires par e-mail lorsqu'un flux dépasse à répétition les limites d'actions. Tout aussi important : les services connectés eux-mêmes appliquent des limites de protection, qui apparaissent dans ton flux sous forme d'erreur 429 (trop de requêtes) ou 5xx (délai d'attente dépassé). Ces limites varient selon le connecteur et le service, ce qui explique pourquoi la même logique de flux peut se comporter très différemment avec SharePoint qu'avec Dataverse ou une API externe.

Levier 1 : utiliser le parallélisme de façon ciblée

Des branches parallèles pour des étapes indépendantes

D'après le guide sur l'exécution parallèle et le parallélisme, les branches parallèles sont utiles chaque fois que deux actions ou plus ne dépendent pas l'une de l'autre et durent chacune plus de cinq secondes. Selon Microsoft, les cas d'usage typiques sont les demandes d'approbation non bloquantes, les processus d'approbation basés sur un quorum, la création ou la mise à jour simultanée d'enregistrements dans plusieurs systèmes, ainsi que l'initialisation en parallèle de plusieurs variables.

Contrôle de la concurrence dans les boucles Appliquer à chacun

L'effet est encore plus net dans les boucles. Par défaut, une boucle Appliquer à chacun fonctionne de façon séquentielle, élément par élément. La documentation montre, avec un tableau de test de quatre éléments, à quel point cela se raccourcit grâce au parallélisme :

Parallélisme désactivé : 21 secondes
Degré de parallélisme 2 : 11 secondes
Degré de parallélisme 4 : 6 secondes
Degré de parallélisme 6 : 6 secondes

Tu peux régler le degré de parallélisme entre 1 et 50. Important : un chiffre élevé n'accélère pas automatiquement tout, car répartir le travail, mettre en file d'attente des threads supplémentaires et les délais dus au point de terminaison appelé génèrent eux-mêmes une charge supplémentaire. Les boucles Appliquer à chacun imbriquées s'exécutent en outre toujours de façon séquentielle ; selon Microsoft, le contrôle du parallélisme n'agit que sur le niveau supérieur du flux cloud.

Parallélisme du déclencheur : à utiliser avec prudence

Au niveau du déclencheur, tu peux en plus activer un contrôle de la concurrence, qui définit combien d'instances d'un flux peuvent s'exécuter en même temps ; il est désactivé par défaut. Il aide avec les sources de données à débit limité et empêche les fameuses lectures incohérentes (dirty reads), où un flux continue de travailler avec des données obsolètes parce qu'une exécution parallèle a entre-temps modifié l'enregistrement. Microsoft recommande toutefois explicitement la prudence : une fois activé, ce réglage ne peut plus être annulé, seule la recréation du déclencheur le permet. Comme bonne pratique, la documentation recommande d'appliquer le contrôle de la concurrence uniquement à un flux enfant dédié comportant le moins d'actions possible, plutôt qu'à l'ensemble du flux principal.

Levier 2 : réduire les actions et boucles inutiles

Éviter les boucles imbriquées

Le guide sur les anti-modèles dans les flux cloud cite les boucles Appliquer à chacun imbriquées comme l'un des pièges les plus coûteux. Deux boucles de dix itérations chacune donnent mathématiquement 100 exécutions ; avec des volumes de données plus importants, ce nombre croît de façon exponentielle et atteint rapidement les limites d'itérations et de durée totale d'exécution. L'alternative documentée : utiliser l'expansion de requête OData pour charger les enregistrements liés en une seule requête, au lieu de les récupérer dans une seconde boucle imbriquée. Un paramètre comme `Products($select=ProductName,Price)` remplace ainsi toute la boucle interne par un seul appel RetrieveMultiple supplémentaire vers Dataverse.

Des conditions de déclenchement plutôt que des vérifications en aval

De nombreux flux démarrent à chaque modification d'une source de données, alors que seule une fraction des exécutions est réellement pertinente. Une condition de déclenchement, vérifiée directement au niveau du déclencheur, évite ces exécutions superflues dès le départ, au lieu de les intercepter seulement après le démarrage du flux via une condition interne. Cela permet d'économiser non seulement du temps, mais aussi les demandes d'actions qui seraient sinon consommées à chaque exécution non pertinente.

Opérations par lot et en masse plutôt qu'actions individuelles

Selon la documentation, si tu dois créer ou mettre à jour des centaines ou des milliers d'enregistrements, tu ne devrais pas traiter chaque enregistrement individuellement dans une boucle For each. Les opérations par lot regroupent plusieurs requêtes en une seule requête HTTP, tandis que les API web d'opérations en masse de Dataverse vont encore plus loin : au lieu de nombreuses actions individuelles « Créer une ligne », un seul appel à l'API web CreateMultiple avec 100 enregistrements préparés ne compte que comme une seule action.

Levier 3 : choix du connecteur et limitation du volume de données

Ne charger que les données dont tu as vraiment besoin

Selon le guide Travailler uniquement avec les données pertinentes, le volume de données traité peut être limité aussi bien au niveau du déclencheur que des différentes actions. Pour les sources Dataverse, les paramètres Sélectionner des colonnes, Filtrer les lignes et Nombre de lignes réduisent le jeu de résultats directement à la source. Pour SharePoint, Requête de filtre, Nombre maximal et Limiter les colonnes selon la vue remplissent le même rôle. C'est important, car les limites de débit (throughput limits) déterminent la quantité de données qu'un flux cloud peut lire et écrire à partir de son historique d'exécution sur une période donnée. Si cette limite est dépassée en continu pendant 14 jours, Power Automate désactive automatiquement le flux.

La bonne action plutôt que la plus pratique

Le choix du connecteur signifie aussi ne pas recourir automatiquement à l'action la plus coûteuse pour une même tâche. Des opérations de données comme Filter array, Select ou Join traitent les tableaux directement et réduisent le volume de données qui traverse les étapes suivantes, souvent bien plus efficacement qu'une boucle supplémentaire avec conditions. Lorsqu'un service propose des paramètres natifs de filtrage ou de sélection directement dans le connecteur, il est, selon la documentation Microsoft, plus efficace de filtrer à cet endroit plutôt que de charger d'abord tout le volume de données dans le flux puis de le réduire avec une opération de données séparée.

Comment trouver le goulot d'étranglement de ton propre flux

Le moyen le plus rapide de trouver la cause réelle est de suivre un ordre de vérification fixe. Ouvre d'abord l'analyse des actions du flux concerné et vérifie s'il est proche de ses limites quotidiennes. Vérifie ensuite l'historique d'exécution à la recherche d'actions individuelles dont la durée est étonnamment longue ; il s'agit le plus souvent de boucles sans parallélisme ou d'actions qui chargent des volumes de données inutilement importants. Contrôle également si des erreurs de type 429 ou 5xx apparaissent, ce qui indique des limites d'un service connecté plutôt que de Power Automate lui-même. Pour des paysages de flux plus étendus avec plusieurs environnements, un accompagnement Power Automate structuré vaut souvent la peine, car il passe systématiquement en revue le parallélisme, le volume de données et le choix des connecteurs pour tous les flux critiques, au lieu d'optimiser chaque flux individuellement.

Questions fréquentes

Combien d'éléments dois-je traiter en parallèle dans une boucle Appliquer à chacun ?

Il n'existe pas de valeur idéale universelle ; Microsoft autorise un degré de parallélisme entre 1 et 50. Dans la mesure d'exemple documentée avec quatre éléments, un parallélisme de 4 apportait déjà l'accélération maximale, et une augmentation supplémentaire à 6 ne changeait plus rien à la durée d'exécution. En pratique, il est utile de commencer avec une valeur modérée, entre 5 et 10, et d'observer la durée d'exécution dans l'historique, plutôt que de fixer directement la valeur maximale, car un parallélisme trop élevé peut lui-même provoquer des délais dus au point de terminaison appelé.

Le contrôle de la concurrence du déclencheur améliore-t-il automatiquement la performance ?

Pas automatiquement, et Microsoft recommande même la retenue. Le réglage par défaut, sans contrôle de la concurrence, autorise autant d'exécutions simultanées que le système peut en gérer, ce qui est déjà suffisamment performant pour la plupart des scénarios. Le contrôle de la concurrence est surtout utile lorsqu'une ressource connectée ne supporte qu'un débit limité ou lorsqu'il faut empêcher les lectures incohérentes (dirty reads), et non comme mesure générale d'accélération. Comme ce réglage ne peut pas être annulé, tu ne devrais l'appliquer que de façon ciblée à un petit flux dédié.

Pourquoi les boucles imbriquées posent-elles un problème de performance aussi important ?

Parce que le nombre d'exécutions se multiplie au lieu de s'additionner. Deux boucles imbriquées l'une dans l'autre, avec dix éléments chacune, aboutissent à 100 exécutions individuelles ; avec des volumes de données plus importants, ce nombre continue de croître de façon exponentielle. Cela coûte non seulement du temps, mais rapproche aussi rapidement le flux des limites d'itérations et de durée totale d'exécution, ce qui peut, dans le pire des cas, entraîner des erreurs de flux ou une limitation de débit (throttling).

Quel est le rapport entre le choix du connecteur et la performance, lorsque plusieurs connecteurs peuvent effectuer la même tâche ?

Les connecteurs proposent souvent des paramètres de filtrage et de sélection à différents niveaux de granularité directement à la source de données. Un connecteur qui prend déjà en charge le filtrage, la sélection de colonnes et un nombre maximal de lignes au niveau du déclencheur ou de l'action réduit le volume de données traité avant même qu'il n'arrive dans le flux. Cela a un effet direct sur les limites de débit et réduit le risque qu'un flux soit limité en raison d'un volume de données trop élevé, voire désactivé automatiquement après un dépassement prolongé.

Comment savoir si un flux lent est dû à Power Automate ou au service connecté ?

Un coup d'œil aux codes d'erreur dans l'historique d'exécution donne la réponse. Les erreurs de type 429 ou les délais d'attente dans la plage 5xx indiquent des limites de protection du service connecté, qui varient selon le connecteur. Si en revanche Power Automate lui-même atteint ses demandes d'actions quotidiennes, l'analyse des actions dans « Mes flux » le montre clairement, et les propriétaires reçoivent en plus une notification automatique avec des conseils pour réduire le nombre d'actions.