Délégation dans Power Apps : comprendre la limite des 2 000 lignes et l'éviter

C'est le bug le plus coûteux de Power Apps Canvas, parce qu'il ne ressemble pas à un bug. L'application ne plante pas, aucune erreur ne remonte, l'écran s'affiche normalement. Il manque simplement des lignes. En recette avec 200 enregistrements de test, tout est correct. En production avec 40 000 enregistrements, la moitié des résultats a disparu.

Ce que fait réellement la délégation

Quand vous écrivez un Filter, un LookUp ou un Sort, Power Apps essaie de faire exécuter le travail par la source de données plutôt que par le client. C'est la délégation : la requête part vers Dataverse, SharePoint ou SQL Server, le serveur trie les millions de lignes et ne renvoie que le résultat.

Si l'expression n'est pas délégable, le comportement change radicalement. Power Apps télécharge les N premières lignes de la table, puis applique le filtre localement, sur cet échantillon uniquement. N est la limite de lignes de données définie dans les paramètres de l'application : 500 par défaut, 2 000 au maximum. Tout ce qui se trouve au-delà n'est jamais évalué.

Le point critique : cette troncature est silencieuse. Elle ne produit pas une erreur, elle produit un résultat faux.

La matrice de délégation, source de vérité

Chaque connecteur supporte un sous-ensemble différent de fonctions et d'opérateurs. Les écarts les plus structurants :

Fonction ou opérateur	Dataverse	SharePoint	SQL Server
Filter avec =, <>, >, <	Oui	Oui	Oui
StartsWith	Oui	Oui	Oui
EndsWith	Oui	Non	Oui
Opérateur in	Partiel	Non	Non
Sum, Average, Min, Max	Oui	Non	Oui
CountRows	Oui	Non	Oui
Sort, SortByColumns	Oui	Oui	Oui
First, Last, Concat	Non	Non	Non

Cette matrice évolue à chaque version. Elle se vérifie dans la documentation Microsoft avant de figer une architecture, pas après la mise en production.

Le piège des collections

Un ClearCollect ramène les données en mémoire côté client. À partir de ce moment, la notion de délégation n'existe plus : tout filtre appliqué à la collection s'exécute localement, et il s'exécute sur un jeu de données déjà tronqué au chargement.

Charger une table volumineuse dans une collection pour « éviter les problèmes de délégation » ne résout rien. Cela déplace la troncature au moment du chargement, là où elle devient encore plus difficile à repérer.

Cinq patterns pour rester délégable

1. Sortir les fonctions non délégables du prédicat

Une fonction évaluée à l'intérieur du filtre casse souvent la délégation. Évaluez-la d'abord dans une variable : Set(varAujourdhui, Today()) puis Filter(Demandes, DateEcheance <= varAujourdhui). Le filtre ne contient plus qu'une comparaison simple, qui part au serveur.

2. Remplacer les opérateurs non supportés

Sur SharePoint, l'opérateur in n'est pas délégué. Un StartsWith sur une colonne texte indexée fait le travail dans la plupart des cas d'usage réels, avec un comportement prévisible en volume.

3. Pré-filtrer côté source

Une vue Dataverse, une vue SQL ou une colonne dénormalisée transforment un calcul complexe en simple égalité. Si votre filtre a besoin de croiser trois conditions et une table liée, il vaut mieux matérialiser le résultat dans une colonne dédiée et filtrer dessus avec un =.

4. Rendre le filtrage explicite pour l'utilisateur

Un écran qui commence par une zone de recherche obligatoire plutôt que par « toutes les lignes » supprime le problème à la racine. L'utilisateur ne consulte jamais 40 000 enregistrements ; il en cherche un.

5. Déporter les agrégats

Une somme ou un comptage sur un gros volume avec un connecteur qui ne les délègue pas doit sortir de l'application : Power Automate qui alimente une table de synthèse, une vue agrégée côté source, ou un visuel Power BI embarqué.

Trois façons de diagnostiquer

• L'avertissement du studio. Power Apps signale les formules non délégables directement dans la barre de formule. Le message est régulièrement ignoré parce que l'application fonctionne en test. C'est précisément le signal à traiter.
• Le test de la limite à 1. Passez temporairement la limite de lignes de données à 1 dans les paramètres. Si les résultats affichés changent, l'expression n'est pas déléguée. C'est le test le plus fiable et le plus rapide.
• Monitor. L'outil Monitor montre les requêtes réellement envoyées à la source. Si votre condition n'apparaît pas dans le $filter de la requête OData, elle est évaluée en local.

Le cas SharePoint : deux limites à ne pas confondre

La limite de délégation (500 à 2 000 lignes rapatriées) et le seuil de vue de liste SharePoint (5 000 éléments) sont deux mécanismes distincts. Le second concerne l'indexation côté SharePoint et provoque des erreurs explicites, pas des résultats tronqués. Indexer les colonnes utilisées en filtre traite le second, pas le premier.

À cela s'ajoute le comportement des colonnes complexes : les types Personne, Choix et Recherche ont un support de délégation limité, ce qui pousse souvent à stocker une copie texte de la valeur dans une colonne simple dédiée au filtrage.

Questions fréquentes

Faut-il systématiquement passer la limite de lignes à 2 000 ?

Non. Augmenter la limite masque le symptôme et dégrade les performances de chargement, sans corriger la formule. Elle ne devient acceptable que sur des tables dont on sait qu'elles resteront durablement sous ce seuil.

Dataverse rend-il le problème caduc ?

Il le réduit fortement, puisque la couverture de délégation y est la plus large des trois connecteurs, mais il ne le supprime pas. First, Concat et plusieurs constructions imbriquées restent non délégables quelle que soit la source.

Comment tester la délégation avant la mise en production ?

En chargeant l'environnement de recette avec un volume représentatif de la production, pas avec un jeu de test de quelques centaines de lignes. Un défaut de délégation est structurellement invisible sous le seuil.