Limites Apply to each et pagination dans Power Automate : le seuil de 100 000

Lorsqu'un flux dans Power Automate échoue soudainement avec une erreur cryptique dès qu'une liste SharePoint, une table Dataverse ou une plage Excel dépasse une certaine taille, c'est presque toujours l'une des limites intégrées de boucle et de pagination qui en est la cause. La plus connue d'entre elles est la limite de 100 000 pour les boucles Apply to each et les éléments paginés. Au quotidien, elle reste longtemps invisible, car la plupart des listes sont bien plus petites, puis elle frappe exactement les processus les plus importants : importations massives, clôtures annuelles ou migration de grands volumes de données.

Cet article explique quelles limites s'appliquent concrètement aux boucles et à la pagination dans Power Automate, comment activer la pagination pour une action, et quelles astuces te permettent de traiter de manière fiable même de très grandes quantités de données sans atteindre la limite de 100 000 itérations. Toutes les informations proviennent de la documentation officielle de Microsoft.

Quelles limites s'appliquent aux boucles et à la pagination ?

Microsoft documente les valeurs pertinentes dans l'aperçu Limites pour les flux automatisés, planifiés et instantanés. Les chiffres les plus importants pour une seule exécution de flux :

• Apply to each : 5 000 éléments dans le profil de performance Bas, 100 000 éléments pour tous les autres profils. C'est le nombre maximal d'éléments de tableau qu'une boucle Apply to each peut traiter.
• Éléments paginés : également 5 000 pour Bas, 100 000 pour tous les autres profils. Pour traiter davantage d'éléments, tu dois déclencher plusieurs exécutions de flux sur tes données.
• Split On : 5 000 pour Bas sans concurrence de déclencheur, 100 000 pour tous les autres sans concurrence de déclencheur, mais seulement 100 dès que la concurrence de déclencheur est activée.
• Itérations Until : 60 par défaut, 5 000 au maximum.
• Apply to each (concurrence) : la valeur par défaut pour les itérations exécutées simultanément est 1, mais elle peut être augmentée jusqu'à une valeur comprise entre 1 et 50.

Le profil de performance qui s'applique à ton flux dépend de la licence de son propriétaire. Bas concerne entre autres les plans gratuits, les plans Microsoft 365, le plan 1 de Power Apps et les licences d'essai, tandis que les licences premium, de processus et par flux relèvent des profils Moyen ou Élevé et peuvent donc utiliser toute la limite de 100 000.

L'erreur WorkflowRunActionRepetitionQuotaExceeded

Lorsqu'une boucle Apply to each atteint son nombre maximal d'itérations, le flux échoue avec l'erreur `WorkflowRunActionRepetitionQuotaExceeded`. Selon la Référence des codes d'erreur des flux cloud les causes les plus fréquentes sont :

• une Get items ou List rows qui renvoie tous les enregistrements au lieu d'être filtrée au préalable
• des boucles Apply to each imbriquées dont les nombres d'itérations se multiplient, par exemple 100 fois 100 égale 10 000 passages
• une très grande liste SharePoint ou table Dataverse chargée entièrement dans une boucle sans filtre

Comme remède, Microsoft recommande de restreindre les données dès l'action source via des filtres OData tels que `$filter` et `$top` plutôt que de filtrer seulement à l'intérieur de la boucle, de répartir les grands ensembles de données sur plusieurs exécutions de flux à l'aide de jetons de pagination ou de plages de dates, et d'utiliser les actions Select ou Filter array au lieu d'une boucle Apply to each complète pour de simples transformations ou filtrages.

Activer la pagination pour une action

Pour de nombreuses actions de données, comme List rows dans Dataverse, la pagination peut être configurée directement dans les paramètres de l'action. La Documentation sur le listage des lignes dans les flux décrit ainsi la démarche dans le nouveau concepteur :

1. Sélectionne la carte d'action concernée, par exemple List rows.

2. Ouvre dans la zone de gauche l'onglet Paramètres puis Réseau.

3. Mets le curseur Pagination sur Activé.

4. Saisis sous Seuil le nombre maximal de lignes souhaité. Le seuil configurable le plus élevé est de 100 000.

En interne, Power Automate arrondit cette valeur aux multiples entiers de la taille de page par défaut. Si tu saisis par exemple 7 000 et que la taille de page est de 5 000, ce sont en réalité 10 000 lignes qui sont renvoyées. Sans pagination activée, la limite par défaut de 5 000 lignes s'applique automatiquement, et la réponse ne contient plus de paramètre `@odata.nextLink` dès que le seuil est dépassé.

Cas particulier SharePoint : Get items et le seuil de 5 000

Pour l'action SharePoint Get items, la limite par défaut n'est même que de 100 éléments, mais elle peut être augmentée jusqu'à 5 000 via les options avancées et le paramètre Top Count, avant que la liste n'atteigne le seuil d'affichage de SharePoint lui-même. Si tu combines une requête de filtre avec une liste comptant plus de 5 000 entrées, il peut arriver qu'aucun résultat ne revienne, bien que des enregistrements correspondants existent. Là aussi, l'activation de la pagination dans les paramètres de l'action avec un seuil suffisamment élevé apporte un remède, car Power Automate récupère alors les données par lots selon Top Count au lieu de ne vérifier que les 5 000 premières lignes non filtrées.

La limite de rafale d'actions de 100 000 actions par 5 minutes

Outre le simple nombre d'itérations, il existe un second frein souvent négligé : la limite de rafale d'actions. Selon les Directives pour comprendre les limites de la plateforme la limite supérieure actuelle est de 100 000 actions par flux sur une fenêtre glissante de cinq minutes. Chaque action à l'intérieur d'une boucle Apply to each compte individuellement, de sorte qu'une boucle avec plusieurs actions par passage atteint cette limite bien plus vite que ne le laisserait supposer le simple nombre d'itérations. Microsoft recommande dans un tel cas de répartir la charge sur plusieurs flux, par exemple à l'aide de flux enfants (Child Flows) ou de conditions de déclenchement qui empêchent d'emblée les exécutions inutiles.

Traiter proprement de grands volumes de données : recommandations pratiques

Pour les processus qui risquent de s'approcher de la limite de 100 000, une démarche claire a fait ses preuves en pratique :

• Filtrer tôt plutôt que tard : Limite les enregistrements dès l'action source via `$filter`, `$top` ou une requête de filtre SharePoint, plutôt que de charger la liste entière dans la boucle et de la vérifier seulement là.
• Éviter l'imbrication : En cas de plusieurs boucles Apply to each imbriquées les unes dans les autres, vérifie si le nombre d'itérations externe et interne se multiplient, et construis plutôt en amont avec Select ou Filter array là où c'est possible.
• Répartir sur plusieurs exécutions : Utilise des jetons de pagination, des plages de dates ou un déclencheur planifié pour répartir méthodiquement un très grand volume de données sur plusieurs exécutions de flux, au lieu de tout traiter en une seule exécution.
• Utiliser la concurrence de manière ciblée : Si tu augmentes la concurrence d'une boucle Apply to each à une valeur supérieure à 1, plusieurs itérations s'exécutent simultanément, ce qui économise du temps d'exécution mais augmente la charge sur les systèmes connectés, et n'est donc pas judicieux pour tous les connecteurs.
• Garder un œil sur les limites : Consulte régulièrement via Analyses sur la page de détails du flux le nombre réel d'actions, plutôt que de réagir seulement après une erreur.

Cette approche te permet de garder le contrôle de ton flux de données, au lieu d'être surpris par un arrêt soudain précisément dans le processus qui mérite de toute façon le plus d'attention.

Pour qui l'optimisation de tels processus de masse est-elle rentable ?

Un seul collaborateur numérique dans Power Automate n'atteint généralement la limite de 100 000 que lorsqu'une entreprise connaît une croissance réelle, par exemple lors de la migration d'une grande base de données existante, du reporting annuel sur l'ensemble des enregistrements clients, ou du raccordement d'un système ERP comportant plusieurs dizaines de milliers de lignes. Pour de tels cas, une architecture propre composée de requêtes source filtrées, d'une pagination correctement dimensionnée et, si nécessaire, de plusieurs exécutions de flux successives est bien plus rentable dès le départ qu'un rafistolage ultérieur d'erreurs isolées. Celui qui souhaite construire dès le départ ses processus Power Automate pour de grands volumes de données de manière robuste trouvera un appui auprès du conseil Power Automate de NordFlux.

Questions fréquentes

Que se passe-t-il si un flux doit traiter plus de 100 000 éléments ?

Power Automate traite au maximum 100 000 éléments par exécution de flux dans une seule boucle Apply to each ou une action paginée. Pour des volumes de données plus importants, Microsoft recommande de déclencher plusieurs exécutions de flux sur les données, par exemple à l'aide d'un jeton de pagination, d'un filtre de date ou d'un déclencheur planifié qui répartit le traitement en plusieurs portions.

La limite de 100 000 s'applique-t-elle de la même manière à chaque licence ?

Non. La limite de 100 000 s'applique aux profils de performance Moyen et Élevé, qui comprennent notamment les licences premium et de processus. Dans le profil de performance Bas, qui s'applique aux plans gratuits, aux plans Microsoft 365 et aux licences d'essai, la même limite est déjà de 5 000 éléments.

En quoi la limite Apply to each diffère-t-elle de la limite Split On ?

La limite Apply to each concerne une boucle qui parcourt un tableau au sein d'une seule exécution de flux. La limite Split On, en revanche, concerne les déclencheurs qui fournissent un tableau et le répartissent directement en plusieurs instances de workflow distinctes via une propriété SplitOn, au lieu d'utiliser une boucle foreach. Si la concurrence de déclencheur est en plus activée pour un tel déclencheur, la limite Split On descend à 100 éléments.

Comment savoir si un flux atteint la limite de 100 000 ?

Le flux échoue avec l'erreur `WorkflowRunActionRepetitionQuotaExceeded` dès qu'une boucle Apply to each dépasse son nombre maximal d'itérations. Dans l'historique d'exécution du flux, cette erreur peut être retracée directement au niveau de l'action de boucle concernée, et via Analyses sur la page de détails du flux, tu vois en plus combien d'actions une exécution a consommées au total.

Puis-je définir le seuil de pagination à plus de 100 000 ?

Non. Selon la documentation Microsoft, le seuil maximal configurable pour la pagination est de 100 000, quelle que soit la valeur que tu saisis dans le champ de paramètres. Comme il est arrondi en interne aux tailles de page complètes, le nombre réellement renvoyé peut être légèrement supérieur à la valeur saisie, mais jamais au-dessus de la limite supérieure de 100 000.

Sources : Microsoft Learn – Limites pour les flux automatisés, planifiés et instantanés, Microsoft Learn – Comprendre les limites de la plateforme et éviter la limitation, Microsoft Learn – Utiliser les listes de lignes dans les flux