Power Apps relève le plafond des requêtes non déléguées de 2 000 à 10 000 lignes : ce qui change vraiment

Microsoft a relevé le plafond maximal du paramètre Data row limit de Power Apps : il était jusqu'ici fixé à 2 000 lignes, il peut désormais être configuré jusqu'à 10 000 lignes, comme le confirme la documentation officielle mise à jour. Attention toutefois à ne pas confondre ce changement avec une augmentation de la délégation elle-même : ce paramètre ne concerne que le comportement de repli quand une requête n'est pas délégable, et son relèvement ne dispense en rien de concevoir des formules déléguées. Sa disponibilité effective dépend par ailleurs de la version du moteur Canvas de votre application, et l'augmenter sans discernement peut dégrader sensiblement les performances, en particulier sur des tables avec beaucoup de colonnes. Voici ce qui change concrètement, et les précautions à prendre avant de toucher à ce réglage.

Ce qui change concrètement : du plafond de 2 000 à 10 000 lignes

Le paramètre Data row limit se trouve dans les paramètres généraux d'une app canvas. Il définit combien de lignes Power Apps est autorisé à récupérer côté client quand une requête ne peut pas être traduite intégralement vers la source de données (donc non déléguée). Par défaut, cette valeur reste à 500 lignes. Jusqu'à présent, un faiseur d'app pouvait la monter manuellement jusqu'à 2 000 ; la documentation Microsoft indique maintenant un plafond possible de 10 000.

Ce que ce paramètre couvre réellement, et ce qu'il ne couvre pas

Il est essentiel de ne pas confondre ce plafond avec la délégation elle-même. Une formule correctement délégée (un Filter sur une colonne indexée avec un opérateur supporté, par exemple) continue de s'exécuter côté source de données, sans jamais être limitée par ce paramètre, quel que soit le volume réel de la table. Le Data row limit n'intervient que pour les formules non délégables : il fixe combien de lignes Power Apps télécharge avant d'appliquer localement le reste du calcul. Les fonctions UpdateIf et RemoveIf, qui simulent elles aussi une délégation en local, suivent désormais ce même plafond configurable plutôt qu'une valeur fixe de 500 ou 2 000.

Pourquoi cette extension se déploie progressivement selon la version du canevas

Comme pour la plupart des évolutions de moteur Canvas, ce relèvement de plafond ne se généralise pas instantanément à toutes les apps existantes. Une app qui tourne sur une version ancienne du moteur peut continuer à afficher un maximum de 2 000 dans ses paramètres, même après la mise à jour de la documentation, tant qu'elle n'a pas été rouverte et republiée depuis une version à jour de Power Apps Studio. Avant de communiquer ce changement à des équipes métier ou de l'intégrer dans un cahier des charges, il est donc recommandé de vérifier concrètement, dans les paramètres d'une app test, la valeur maximale réellement proposée, plutôt que de supposer qu'elle s'applique uniformément partout.

Les risques de performance à ne pas sous-estimer

Relever ce plafond ne corrige aucun problème de délégation : il élargit simplement le filet de sécurité, au prix d'un coût réseau et mémoire plus élevé. Télécharger 10 000 lignes côté client, en particulier sur une table large avec de nombreuses colonnes, peut rendre une app visiblement lente ou instable sur des connexions moins performantes, surtout en mobilité. La documentation officielle elle-même rappelle que l'augmentation de cette valeur peut dégrader la performance et qu'il reste préférable de déléguer autant que possible plutôt que de compter sur ce plafond étendu comme solution de confort.

500, 2 000, 10 000 : quand utiliser quelle valeur

Checklist avant de relever ce paramètre

• Vérifier dans les paramètres de l'app la valeur maximale réellement proposée pour le Data row limit, plutôt que de supposer 10 000 disponible partout.
• Repasser en revue les formules concernées avec le Data row limit mis à 1, pour confirmer qu'elles sont bien non délégables et non corrigibles par un index ou une réécriture de filtre.
• Mesurer l'impact réel sur les temps de chargement avant et après relèvement, sur un réseau représentatif des conditions d'usage (mobilité incluse).
• Documenter pourquoi la formule reste non déléguée, pour éviter qu'un palliatif de confort ne devienne une dette technique silencieuse.
• Réévaluer si une migration de la source de données (vers Dataverse notamment) ne résoudrait pas durablement le problème plutôt que de dépendre d'un plafond étendu.

Faut-il pour autant arrêter de chercher à déléguer ?

Non. Ce relèvement de plafond est un filet de sécurité élargi, pas une alternative à une bonne conception de requêtes. Une app qui s'appuie massivement sur des formules non délégables, même avec un plafond à 10 000, reste plus lente et plus fragile qu'une app où l'essentiel du filtrage et du tri est réellement délégué à la source de données. Sur des tables qui continuent de croître, le bon réflexe reste d'indexer les colonnes utilisées en filtre, de revoir les formules signalées par l'avertissement de délégation, et d'envisager Dataverse quand les volumes ou la complexité des requêtes dépassent ce que la délégation côté SharePoint ou Excel peut raisonnablement absorber.

Questions fréquentes

Le plafond de 10 000 lignes s'applique-t-il automatiquement à toutes mes apps existantes ?

Pas nécessairement de façon immédiate. Selon la version du moteur Canvas sur laquelle une app a été enregistrée, le paramètre peut encore afficher un maximum de 2 000 tant que l'app n'a pas été rouverte et republiée avec une version à jour de Power Apps Studio. Il est recommandé de vérifier directement dans les paramètres de chaque app plutôt que de supposer le nouveau plafond disponible partout.

Relever le Data row limit à 10 000 règle-t-il un avertissement de délégation ?

Non, l'avertissement de délégation signale qu'une formule ne peut pas être traduite intégralement vers la source de données ; relever ce paramètre ne corrige pas cette limitation, il repousse seulement le seuil au-delà duquel les données récupérées localement seront tronquées. La formule reste non déléguée et continue de rapatrier des données côté client, avec le coût de performance associé.

Quel est le vrai risque à passer directement à 10 000 partout ?

Le risque principal est une dégradation de performance généralisée, en particulier sur des tables à nombreuses colonnes ou pour des utilisateurs en mobilité, puisque chaque requête non déléguée télécharge désormais potentiellement jusqu'à 20 fois plus de données qu'avec la valeur par défaut de 500. Ce plafond doit rester une exception documentée et testée, pas un réglage appliqué par défaut à toutes les apps d'un portefeuille.