Liste SharePoint de plus de 5 000 éléments : pourquoi vos apps et flows Power Platform plantent, et comment y remédier

Le List View Threshold de SharePoint est fixé à 5 000 éléments par défaut : au-delà, toute requête qui ne peut pas s'appuyer sur un index (filtre sur colonne non indexée, tri sur plusieurs colonnes, requête OR complexe) est bloquée par SharePoint lui-même, avant même d'atteindre Power Apps ou Power Automate. C'est une limite de plateforme, distincte de la limite de délégation à 2 000 lignes propre à Power Apps : une liste de 6 000 éléments peut très bien fonctionner dans une app si les requêtes sont déléguées et indexées correctement, et planter malgré tout dans un flow Power Automate qui utilise un filtre non indexé. Cet article détaille comment reconnaître ce seuil dans les symptômes observés, pourquoi l'indexation ne suffit pas toujours à le contourner, et les options concrètes pour sécuriser une liste qui s'en approche.

Le List View Threshold, une limite SharePoint, pas une limite Power Apps

SharePoint impose cette limite au niveau de la base de données sous-jacente pour éviter que des requêtes non optimisées ne dégradent les performances de tout le tenant. Elle s'applique à toute interaction avec la liste au-delà de 5 000 éléments correspondant aux critères d'une requête non indexée : vue SharePoint classique, Power Apps, Power Automate, Microsoft Lists, mais aussi l'API REST et Graph. Contrairement à la limite de délégation Power Apps, elle ne dépend pas du connecteur utilisé : c'est SharePoint qui refuse d'exécuter la requête, quel que soit l'outil qui la lui envoie.

Ne pas confondre avec la limite de délégation Power Apps (2 000 lignes)

La limite de délégation à 2 000 lignes, traitée en détail dans notre article sur la délégation Power Apps, concerne la capacité de Power Apps à déléguer une formule entière à la source de données plutôt que de la calculer côté client sur un sous-ensemble de lignes. Le List View Threshold de 5 000 éléments est différent : c'est SharePoint qui bloque la requête côté serveur, avant même que Power Apps n'ait l'occasion de décider si elle est délégable. Une app peut très bien être correctement configurée pour la délégation et échouer quand même, si la liste SharePoint sous-jacente dépasse le seuil sur une requête non indexée.

Les symptômes concrets sur le terrain

Dans Power Apps

Le symptôme le plus fréquent est une galerie ou un contrôle qui affiche un nombre de lignes incohérent, parfois incomplet, sans message d'erreur explicite à l'écran. Quand la requête touche réellement le seuil, Power Apps peut aussi renvoyer une erreur réseau générique lors du chargement des données, difficile à distinguer au premier regard d'un problème de connexion.

Dans Power Automate

L'action "Obtenir des éléments" (Get items) est la plus exposée : au-delà du seuil, elle renvoie une erreur du type "The attempted operation is prohibited because it exceeds the list view threshold" dès qu'un filtre OData porte sur une colonne non indexée, ou qu'un tri est appliqué sur plusieurs colonnes. Le flow qui fonctionnait depuis des mois s'arrête brutalement le jour où la liste franchit la barre des 5 000 éléments, sans qu'aucun changement n'ait été fait sur le flow lui-même.

Pourquoi l'indexation ne suffit pas toujours

Indexer une colonne aide, mais seulement si la requête s'appuie entièrement sur cet index. Un filtre combinant plusieurs colonnes avec un opérateur OR, une requête avec un tri sur une colonne différente de celle filtrée, ou une pagination mal construite, peuvent toutes repasser par un scan complet de la liste et retomber dans la limite, même avec un index en place sur l'une des colonnes.

Causes, symptômes et correctifs : tableau de référence

Les solutions pour fiabiliser durablement une liste volumineuse

1. Indexer les colonnes réellement utilisées en filtre, dans les paramètres avancés de la liste (jusqu'à 20 colonnes indexées par liste), en vérifiant que chaque requête s'appuie bien sur l'index via un test isolé de l'action Get items.
2. Créer des vues filtrées dédiées par cas d'usage (par exemple "éléments actifs des 90 derniers jours") plutôt que de faire reposer apps et flows sur la vue par défaut, qui scanne l'intégralité de la liste.
3. Revoir la pagination dans Power Automate avec le paramètre de pagination activé et une taille de page raisonnable, pour éviter qu'une boucle de récupération ne déclenche elle-même le seuil sur des volumes croissants.
4. Archiver ou purger les éléments anciens vers une liste ou une bibliothèque séparée, quand le volume actif réel reste nettement inférieur au volume total historisé.
5. Migrer vers Dataverse dès que la liste dépasse durablement quelques dizaines de milliers d'éléments ou que les besoins de relations, de sécurité au niveau ligne ou de requêtes complexes deviennent structurants : Dataverse n'impose pas ce seuil et délègue nativement des volumes bien supérieurs.

SharePoint vs Dataverse pour des volumes importants

Checklist avant qu'une liste n'atteigne le seuil

• Suivre l'évolution du nombre total d'éléments de chaque liste critique, pas seulement au moment où un incident survient.
• Vérifier que les colonnes utilisées en filtre par les apps et les flows sont bien indexées, et que le tri associé reste cohérent avec l'index.
• Remplacer les vues par défaut non filtrées par des vues dédiées dans toute source de données Power Apps ou Power Automate.
• Tester le comportement des flows critiques avec un volume simulé proche de 5 000 éléments avant la mise en production.
• Planifier la migration vers Dataverse en amont, dès que la trajectoire de croissance laisse anticiper un dépassement durable.

Questions fréquentes

Le List View Threshold peut-il être relevé au-delà de 5 000 éléments ?

Un administrateur SharePoint peut relever ce seuil pour l'ensemble d'une collection de sites, via le centre d'administration, mais Microsoft déconseille cette pratique au-delà d'un usage ponctuel et limité : elle déplace le problème de performance vers l'ensemble du tenant plutôt que de le résoudre, et n'évite pas les blocages liés à des requêtes réellement non indexées.

Une app Power Apps qui fonctionne bien peut-elle planter du jour au lendemain à cause de ce seuil ?

Oui, c'est le scénario le plus fréquent sur le terrain : une liste qui croît progressivement franchit le seuil sans qu'aucun changement n'ait été fait sur l'app ou le flow eux-mêmes. C'est pourquoi le suivi du volume des listes critiques doit faire partie du suivi opérationnel d'une solution Power Platform, au même titre que la supervision des flows.

Faut-il migrer systématiquement vers Dataverse dès qu'une liste approche 5 000 éléments ?

Pas nécessairement : une liste correctement indexée et interrogée via des vues filtrées peut fonctionner de façon fiable bien au-delà de ce volume. La migration vers Dataverse devient pertinente quand le volume continue de croître durablement, ou quand les besoins fonctionnels (relations entre données, sécurité fine, requêtes complexes) dépassent ce que l'indexation SharePoint peut raisonnablement absorber.