SharePoint ou Dataverse : la matrice de décision en 12 critères chiffrés
BA-IT recommande SharePoint tant que trois conditions sont réunies : moins de 5 000 éléments affichés par vue, des relations simples entre entités, et aucun besoin de sécurité au niveau de la ligne. Au-delà, Dataverse devient nécessaire et impose une licence Power Apps Premium par utilisateur. Cette page détaille les 12 critères de décision, avec un seuil chiffré pour chacun.
. Les seuils cités renvoient à la documentation Microsoft Learn en vigueur à cette date.
Quelle est la vraie différence entre SharePoint et Dataverse ?
Les deux services stockent des données exploitables par Power Apps, mais ils ne répondent pas à la même question. SharePoint est une plateforme de collaboration documentaire dont les listes servent aussi de stockage structuré. Dataverse est une base de données applicative, pensée pour porter un modèle relationnel, une sécurité fine et des règles métier côté données. Choisir, c'est arbitrer entre un coût de licence immédiat et un coût de contournement différé.
Ce que SharePoint fait bien
SharePoint est déjà présent dans la quasi-totalité des organisations sous Microsoft 365, et son connecteur Power Apps fait partie des connecteurs standards. Il gère nativement les documents, les versions, les métadonnées et les étiquettes de rétention Microsoft Purview. Pour un processus porté aujourd'hui par un fichier Excel partagé, il représente presque toujours le chemin le plus court vers une première application gouvernée. Sa limite structurante est le seuil d'affichage des listes : Microsoft documente 5 000 éléments par vue ou par opération, un plafond qui se gère par colonnes indexées, vues filtrées et archivage, mais qui ne disparaît jamais.
Ce que Dataverse apporte en plus
Dataverse apporte quatre choses que SharePoint ne sait pas offrir au même niveau : un modèle relationnel avec intégrité référentielle, une sécurité au niveau de la ligne fondée sur les unités commerciales, les équipes et les rôles, un audit natif activable par table et par colonne, et le support des profils hors ligne mobiles de Power Apps. Il y ajoute des règles métier appliquées côté données : la contrainte reste vraie même si une deuxième application, un flux ou un import écrit dans la même table.
Ce que coûte réellement le passage à Dataverse
Le coût visible est la licence : Dataverse relève des offres Power Apps Premium, facturées par utilisateur ou par application, dont la grille est publiée par Microsoft sur sa page de tarification. BA-IT ne reproduit pas ces montants, qui évoluent régulièrement. Le coût moins visible est organisationnel : modéliser des tables, définir des rôles de sécurité, gérer des environnements et un cycle de vie applicatif suppose une gouvernance que toutes les équipes n'ont pas encore. À l'inverse, rester sur SharePoint au-delà de ce qu'il sait porter engendre des contournements — vues éclatées, recopies, flux de synchronisation — dont le coût cumulé dépasse souvent celui des licences évitées.
Les 12 critères de décision
Les seuils numériques ci-dessous sont ceux documentés par Microsoft au 19 août 2026. Lorsque Microsoft ne publie pas de valeur chiffrée pour un critère, BA-IT affiche une recommandation qualitative plutôt qu'un nombre : un seuil inventé serait pire qu'une absence de seuil.
| Critère | Seuil chiffré | Recommandation SharePoint | Recommandation Dataverse |
|---|---|---|---|
| Volumétrie | Au 19 août 2026, la limite d'affichage des listes SharePoint est de 5 000 éléments par vue ou par opération ; une liste peut contenir jusqu'à 30 millions d'éléments. Source Microsoft Learn | Adapté tant que chaque vue et chaque requête reste sous 5 000 éléments grâce aux filtres et aux colonnes indexées. | Nécessaire dès que les requêtes courantes dépassent ce seuil sans filtrage possible. |
| Nombre de relations entre entités | Au 19 août 2026, Microsoft documente une limite de 12 colonnes de recherche (lookup) par vue de liste SharePoint. Source Microsoft Learn | Convient à un modèle plat ou à quelques relations simples de type liste de référence. | Nécessaire pour un modèle relationnel réel : relations un-à-plusieurs et plusieurs-à-plusieurs, intégrité référentielle, cascades. |
| Sécurité au niveau de la ligne | Pas de seuil chiffré documenté : critère qualitatif. Source Microsoft Learn | Possible via des permissions uniques par élément, mais la gestion devient fragile et coûteuse à maintenir à grande échelle. | Modèle natif de sécurité par unité commerciale, équipe, rôle et propriétaire de ligne, avec partage explicite. |
| Piste d'audit | Pas de seuil chiffré documenté : critère qualitatif. Source Microsoft Learn | Historique de versions par élément et journal d'audit au niveau du tenant ; la reconstitution champ par champ reste laborieuse. | Audit natif activable par table et par colonne, avec durée de rétention paramétrable. |
| Usage hors ligne | Pas de seuil chiffré documenté : critère qualitatif. Source Microsoft Learn | Pas de mode hors ligne géré nativement ; il faut coder une file d'attente locale et gérer soi-même les conflits. | Profils hors ligne mobiles pris en charge par Power Apps, avec synchronisation et résolution des conflits. |
| Coût de licence par utilisateur | Pas de montant cité ici : les tarifs Microsoft évoluent ; voir la grille officielle. Source Microsoft Learn | Couvert par les licences Microsoft 365 incluant Power Apps avec connecteurs standards. | Nécessite une licence Power Apps Premium par utilisateur, à budgéter sur toute la durée de vie de l'application. |
| Intégration ERP ou système tiers | Pas de seuil chiffré documenté : critère qualitatif. Source Microsoft Learn | Suffisant pour des échanges ponctuels par fichier ou par flux Power Automate. | Recommandé pour des synchronisations bidirectionnelles fréquentes, avec clés alternatives et gestion des erreurs. |
| Politique de rétention et d'archivage | Pas de seuil chiffré documenté : critère qualitatif. | Étiquettes de rétention Microsoft Purview applicables aux listes et bibliothèques. | Rétention et purge à définir au niveau applicatif ou via les fonctions de gestion du cycle de vie des données. |
| Contraintes RGPD et localisation des données | Pas de seuil chiffré documenté : dépend de la région de votre tenant et de votre environnement. Source Microsoft Learn | Données stockées dans la région du tenant Microsoft 365. | Région choisie à la création de l'environnement Power Platform, ce qui permet un cloisonnement plus fin. |
| Montée en charge prévue à 3 ans | Projection à comparer au seuil de 5 000 éléments par vue documenté au 19 août 2026. Source Microsoft Learn | Acceptable si la projection reste maîtrisable par filtrage, indexation et archivage. | À privilégier si la trajectoire dépasse clairement ce que le filtrage peut absorber. |
| Complexité des règles métier | Pas de seuil chiffré documenté : critère qualitatif. | Règles portées par l'application et par les flux : simple à démarrer, difficile à garantir si plusieurs applications écrivent dans la même liste. | Règles métier, colonnes calculées et plug-ins appliqués côté données, donc valables quel que soit le point d'entrée. |
| Compétence de l'équipe interne | Pas de seuil chiffré documenté : critère qualitatif. Source Microsoft Learn | Prise en main rapide par une équipe déjà familière de Microsoft 365. | Suppose une culture de modélisation de données et une gouvernance des environnements. |
À noter également pour le dimensionnement : la délégation Power Apps limite le nombre de lignes rapatriées par les requêtes non déléguables, indépendamment de la source de données choisie.
L'arbre de décision en 6 questions
- Une seule vue ou une seule requête doit-elle manipuler plus de 5 000 éléments sans filtre possible ?
Si oui, choisissez Dataverse. Au 19 août 2026, Microsoft documente la limite d'affichage des listes SharePoint à 5 000 éléments par vue ou par opération. Si non, passez à la question suivante.
- Votre modèle comporte-t-il plus de quelques relations, ou des relations plusieurs-à-plusieurs à contrôler ?
Si oui, choisissez Dataverse pour l'intégrité référentielle. Si le modèle reste plat ou limité à quelques listes de référence, passez à la question suivante.
- Un utilisateur doit-il voir certaines lignes et pas d'autres, selon son équipe ou son périmètre ?
Si oui, choisissez Dataverse : la sécurité au niveau de la ligne y est native, alors qu'elle repose sur des permissions uniques difficiles à maintenir dans SharePoint. Si non, passez à la question suivante.
- Devez-vous prouver qui a modifié quelle valeur, et quand, sur des données sensibles ou réglementées ?
Si oui, choisissez Dataverse et activez l'audit par table et par colonne. Si l'historique de versions SharePoint suffit à votre exigence de preuve, passez à la question suivante.
- L'application doit-elle fonctionner hors connexion sur le terrain ?
Si oui, choisissez Dataverse : les profils hors ligne mobiles de Power Apps s'appuient dessus. Si non, passez à la question suivante.
- La trajectoire à trois ans dépasse-t-elle ce que le filtrage, l'indexation et l'archivage peuvent absorber ?
Si oui, choisissez Dataverse dès maintenant : migrer plus tard coûte plus cher que démarrer au bon endroit. Si non, SharePoint suffit, et BA-IT recommande alors de documenter le seuil qui déclenchera le réexamen.
Si les six réponses conduisent à SharePoint, BA-IT considère le choix comme sûr pour au moins deux ans, à condition de consigner par écrit le seuil de réexamen.
Trois cas concrets
Un suivi de commandes pour 40 utilisateurs, verdict SharePoint
Contexte : quarante commerciaux saisissent environ 3 000 commandes par an, consultées par vue mensuelle, avec deux listes de référence, clients et produits. Contrainte décisive : aucune vue ne s'approche du seuil de 5 000 éléments et tout le monde peut voir toutes les commandes. Verdict : SharePoint. Le modèle reste plat et la sécurité par ligne est inutile, donc payer une licence Premium par utilisateur n'apporterait aucune capacité réellement employée.
Un CRM interne avec règles de visibilité par équipe, verdict Dataverse
Contexte : trois agences se partagent un portefeuille de prospects, chacune ne devant voir que ses propres lignes, avec un partage ponctuel entre agences. Contrainte décisive : la sécurité au niveau de la ligne. Verdict : Dataverse. Reproduire cette règle dans SharePoint imposerait des permissions uniques par élément, coûteuses à maintenir et faciles à contourner, alors que Dataverse l'applique nativement au niveau des données.
Une application terrain hors ligne avec 200 000 lignes, verdict Dataverse
Contexte : des techniciens réalisent des relevés sur des sites sans couverture réseau, sur un référentiel de 200 000 équipements. Contrainte décisive : le fonctionnement hors connexion combiné à la volumétrie. Verdict : Dataverse. Les profils hors ligne mobiles de Power Apps s'appuient sur Dataverse, et le référentiel dépasse largement ce qu'une vue SharePoint peut servir sans contournements.
Peut-on commencer sur SharePoint et migrer vers Dataverse plus tard ?
Oui, et c'est un choix légitime lorsque le besoin n'est pas encore stabilisé. Mais BA-IT préfère l'annoncer franchement : une migration tardive n'est pas un simple transfert de données. Elle touche quatre couches à la fois, et c'est ce cumul qui coûte.
Les points de rupture les plus fréquents sont les suivants. Les identifiants changent, donc tous les liens entre éléments doivent être reconstruits. Les colonnes de recherche SharePoint deviennent de vraies relations, ce qui révèle les incohérences accumulées dans les données. Les formules d'application écrites pour des listes doivent être réécrites, en particulier celles qui dépendaient d'un comportement de délégation propre à SharePoint. Enfin, les flux Power Automate, les rapports Power BI et les intégrations existantes pointent vers l'ancienne source et doivent être repris un à un.
Une règle pratique de BA-IT : plus l'application est ancienne et partagée, plus la migration coûte cher, car le nombre de dépendances externes croît avec le temps. Si les critères de sécurité par ligne, d'audit ou de hors ligne sont déjà présents dans l'expression de besoin initiale, il est presque toujours moins cher de démarrer directement sur Dataverse.
Quand le démarrage sur SharePoint est retenu, BA-IT recommande trois précautions : isoler l'accès aux données derrière des composants réutilisables plutôt que de disséminer les requêtes dans l'application, conserver des identifiants métier stables indépendants des identifiants SharePoint, et écrire dès le départ le seuil de bascule, par exemple un volume, une nouvelle exigence de confidentialité ou l'arrivée d'une deuxième équipe utilisatrice.
Questions fréquentes
SharePoint peut-il gérer plus de 5 000 éléments ?
Oui, une liste SharePoint peut contenir bien plus : au 19 août 2026, Microsoft documente jusqu'à 30 millions d'éléments par liste. La limite de 5 000 porte sur le nombre d'éléments qu'une même vue ou une même opération peut traiter en une fois. On la contourne avec des colonnes indexées, des vues filtrées et de l'archivage. C'est un seuil d'affichage, pas un plafond de stockage.
Dataverse est-il inclus dans Microsoft 365 ?
Non. Les licences Microsoft 365 incluant Power Apps couvrent l'usage des connecteurs standards, dont SharePoint. Dataverse relève des licences Power Apps Premium, souscrites par utilisateur ou par application. BA-IT chiffre systématiquement ce coût récurrent avant de recommander Dataverse, car il pèse davantage sur la durée que l'écart de coût de développement.
Quand la sécurité au niveau de la ligne devient-elle indispensable ?
Dès qu'un utilisateur ne doit pas voir les lignes d'un autre : données RH, rémunération, dossiers clients répartis par commercial, informations médicales ou juridiques. Masquer une ligne dans l'interface d'une application ne la protège pas, car la source de données reste interrogeable. Dans ce cas, BA-IT recommande Dataverse, où la restriction s'applique au niveau des données.
Peut-on utiliser SharePoint et Dataverse dans la même application ?
Oui. Une application Power Apps peut se connecter simultanément à plusieurs sources. Un schéma courant consiste à garder les documents dans SharePoint et les données structurées et sécurisées dans Dataverse. Attention toutefois : dès qu'une application utilise Dataverse ou un connecteur premium, la licence Power Apps Premium est requise pour ses utilisateurs.
Combien coûte une licence Power Apps Premium ?
BA-IT ne publie pas de tarif de licence Microsoft, car ces prix évoluent et une valeur périmée induirait un budget faux. La grille officielle est publiée par Microsoft sur sa page de tarification Power Apps. En revanche, BA-IT chiffre l'impact dans votre contexte pendant la phase de cadrage : nombre d'utilisateurs réellement concernés, périmètre premium, et coût cumulé sur trois ans.
Quelle source choisir pour une application appelée à grandir ?
Si la croissance attendue est linéaire et que le modèle reste simple, SharePoint reste défendable, à condition de fixer dès le départ le seuil qui déclenchera le réexamen. Si l'application est destinée à devenir un référentiel partagé par plusieurs équipes ou plusieurs applications, BA-IT recommande Dataverse dès le premier jour : la migration tardive coûte presque toujours plus cher que l'écart initial.
Faire trancher cet arbitrage sur votre cas
Le choix de la source de données se décide avant la première ligne de code : il conditionne le coût de licence, la sécurité et la capacité de l'application à durer. BA-IT tranche ce point pendant le cadrage, documentation Microsoft à l'appui.
Pour situer le budget associé, consultez la grille tarifaire BA-IT. Dataverse implique une licence premium : voir ce qui est inclus dans Microsoft 365 et ce qui ne l'est pas.
Licence et citation
Cette matrice de décision est publiée par BA-IT sous licence Creative Commons CC BY 4.0. Citation demandée : BA-IT, matrice de décision SharePoint ou Dataverse, 19 août 2026.
Journal des modifications
- : publication initiale, 12 critères et arbre de décision en 6 questions, seuils vérifiés dans la documentation Microsoft Learn.
L'URL de cette page est stable et ne changera pas : https://www.ba-it.fr/sharepoint-ou-dataverse/