Dataverse vs SharePoint vs Excel : guide de décision technique pour architectes Power Platform

Choisir la bonne source de données pour une application Power Platform est une décision architecturale critique qui impacte les performances, les coûts et la maintenabilité sur plusieurs années. Pourtant, beaucoup de projets démarrent sur Excel ou SharePoint "par défaut", sans analyse préalable des besoins réels.

Ce guide vous aide à prendre une décision éclairée basée sur des critères techniques et financiers concrets.

1. Comprendre les véritables limites de chaque plateforme

Excel : prototypage rapide, limites structurelles

Forces techniques :

• Déploiement instantané (OneDrive/SharePoint)

• Formules natives pour calculs métiers

• Modification structure sans migration

• Pas de coût de licence supplémentaire

Limites techniques réelles :

• Délégation Power Apps : 5 000 lignes maximum (non extensible)

• Concurrence : verrouillage fichier entier lors de l’édition

• Pas de transactions ACID : risque de corruption sur écritures simultanées

• Pas de typage strict : validation côté client uniquement

• Pas d’audit trail : aucune traçabilité native des modifications

Seuils de rupture :

• Au-delà de 1 000 enregistrements → performances dégradées dans Power Apps

• Plus de 3 utilisateurs simultanés → problèmes de concurrence

• Besoin de relations entre tables → non gérable

Cas d’usage valides :

• Prototypes/POC à durée de vie inférieure à 3 mois

• Données de référence statiques (moins de 500 lignes)

• Fichiers personnels ou équipe inférieure à 5 personnes

SharePoint : la plateforme collaborative sous-estimée

Forces techniques :

• Scalabilité réelle : millions d’items par liste (avec architecture adaptée)

• Sécurité granulaire : item-level permissions, folder-level security

• Relations natives : colonnes Lookup, Managed Metadata

• Versioning natif : historique complet des modifications

• Intégration documentaire : pièces jointes sans limite de taille

Limites techniques réelles :

• Seuil de vue de liste : 5 000 items par requête (contournable avec index)

• Délégation Power Apps : limitée à certains opérateurs (égalité, StartsWith, pas Contains)

• Performance des Lookup : dégradation sur relations supérieures à 2 niveaux

• Pas de transactions : pas de rollback natif sur opérations multiples

• Complexité des calculs : colonnes calculées limitées (pas de lookups dans formules)

Optimisations critiques souvent ignorées :

Anti-pattern : Requête non indexée

Filter(SharePointList; Contains(Title; "recherche"))

Pattern optimisé : Index + StartsWith

1. Créer index sur colonne Title dans SharePoint

2. Utiliser opérateur délégable

Filter(SharePointList; StartsWith(Title; "recherche"))

Architecture performante SharePoint :

1. Créer des index sur toutes les colonnes utilisées dans Filter/LookUp

2. Limiter les vues à moins de 5 000 items via folders ou filtres de vue

3. Utiliser des colonnes calculées côté serveur pour les agrégations simples

4. Archiver les données anciennes dans une liste séparée (partitionnement manuel)

Seuils de rupture réels :

• Au-delà de 50 000 items actifs → nécessite architecture avancée (index, vues, archivage)

• Plus de 10 relations inter-listes → devient difficile à maintenir

• Besoin de workflows complexes avec états → limites de Power Automate cloud flows

Cas d’usage valides :

• Applications métiers jusqu’à 100 000 enregistrements avec architecture optimisée

• Forte composante documentaire (gestion de fichiers)

• Budget limité (inclus dans M365)

• Équipe sans compétences Dataverse

Dataverse : la base de données enterprise-grade

Forces techniques :

• Base relationnelle complète : relations 1:N, N:N avec intégrité référentielle

• Scalabilité illimitée : millions d’enregistrements sans dégradation

• Délégation totale : tous opérateurs supportés dans Power Apps

• Transactions ACID : rollback automatique, isolation des écritures

• Typage fort : validation serveur, contraintes d’intégrité

• Sécurité avancée : row-level security, field-level security, hierarchical security

• Audit complet : traçabilité native de toutes les opérations

• Solutions managées : déploiement ALM avec gestion de versions

• Business rules : logique métier côté serveur (indépendante de l’UI)

• Plugins et workflows : extensibilité via C# pour logique complexe

Limites et coûts réels :

Composant	Limite/Coût	Impact
Licence Power Apps	Premium requise (40-48€/user/mois ou 10€/app/mois)	Coût récurrent élevé
Capacité base de données	10GB inclus, puis 40€/GB/mois supplémentaire	Peut exploser sur gros volumes
API calls	40 000/user/jour (Per User) ou 6 000/user/jour (Per App)	Limite atteinte sur apps intensives
Capacité fichier/image	20GB inclus, puis 2€/GB/mois	Stockage de documents coûteux
Environnements	3 inclus (Prod + 2 sandbox), puis payant	Complexifie le DevOps

Coût réel sur 3 ans – exemple concret :

Scénario : 50 utilisateurs, application métier critique

Option 1 – SharePoint optimisé :

• Licences M365 : incluses (0€ supplémentaire)

• Développement initial : 40h × 800€ = 32 000€

• Maintenance annuelle : 5 000€

• TOTAL 3 ans : 47 000€

Option 2 – Dataverse Per App :

• Licences : 50 users × 10€/mois × 36 mois = 18 000€

• DB capacity : 50GB × 40€ × 36 mois = 72 000€

• Développement initial : 60h × 800€ = 48 000€

• Maintenance annuelle : 8 000€

• TOTAL 3 ans : 162 000€

Différence : +245% de coût

Seuils de justification économique :

• Volume : supérieur à 100 000 enregistrements actifs avec croissance forte

• Complexité relationnelle : supérieur à 15 tables avec relations multiples

• Criticité : données métiers stratégiques (CRM, ERP, finance)

• Intégration Dynamics 365 : si déjà présent dans l’entreprise

• Conformité stricte : audit trail réglementaire obligatoire

Cas d’usage obligatoires :

• CRM / ERP / Gestion commerciale

• Applications transactionnelles (commandes, inventaire, facturation)

• Workflows métiers complexes avec états et approbations

• Intégration native avec Dynamics 365

• Multi-environnements avec ALM structuré (Dev/Test/Prod)

2. Matrice de décision technique

Critères de volumétrie

Nombre d’enregistrements	Recommandation	Justification
Moins de 1 000	Excel ou SharePoint	Coût/bénéfice favorable
1 000 – 10 000	SharePoint	Performance acceptable sans optimisation
10 000 – 100 000	SharePoint optimisé	Nécessite architecture (index, vues, archivage)
100 000 – 500 000	Dataverse ou SharePoint expert	Analyse coût/complexité requise
Supérieur à 500 000	Dataverse obligatoire	SharePoint atteint ses limites structurelles

Critères de complexité relationnelle

Nombre de tables/listes	Relations	Recommandation
1-3 tables	Aucune ou simple (1 Lookup)	Excel ou SharePoint
3-8 tables	Relations 1:N simples	SharePoint
8-15 tables	Relations 1:N multiples	SharePoint (limite haute) ou Dataverse
Supérieur à 15 tables	Relations 1:N, N:N, hiérarchiques	Dataverse obligatoire

Critères de concurrence utilisateurs

Utilisateurs simultanés	Écritures/jour	Recommandation
Moins de 5	Moins de 100	Excel acceptable
5-50	100-1 000	SharePoint
50-200	1 000-10 000	SharePoint ou Dataverse
Supérieur à 200	Supérieur à 10 000	Dataverse obligatoire

3. Patterns hybrides : le meilleur des deux mondes

Pattern 1 : SharePoint + Dataverse sélectif

Principe : Données documentaires sur SharePoint, données transactionnelles sur Dataverse

Architecture exemple :

• Documents et pièces jointes → SharePoint (natif)

• Commandes clients → Dataverse (transactionnel)

• Produits catalogue → Dataverse (référentiel)

• Relation : Commande.DocumentID → SharePoint via lien

Avantages :

• Stockage fichiers gratuit (SharePoint)

• Performance transactionnelle (Dataverse)

• Coût optimisé (moins de GB Dataverse)

Pattern 2 : SharePoint avec cache Dataverse

Principe : Données volumineuses sur SharePoint, cache performant sur Dataverse

Workflow :

1. Données principales dans SharePoint (historique complet)

2. Synchronisation quotidienne vers Dataverse (90 derniers jours)

3. Power Apps interroge Dataverse uniquement

4. Archivage automatique SharePoint → Azure Blob Storage

Avantages :

• Performance Power Apps optimale

• Rétention longue durée économique

• Capacité Dataverse maîtrisée

Pattern 3 : Excel pour référentiels statiques

Principe : Données transactionnelles Dataverse, référentiels simples Excel

Exemple :

• Commandes, clients → Dataverse

• Liste pays, devises, unités de mesure → Excel

• Chargement Excel au démarrage dans collection locale

Avantages :

• Modification référentiels sans déploiement

• Pas de pollution Dataverse avec données statiques

• Coût optimisé

4. Checklist de décision

Analyse préliminaire (répondre OUI/NON)

Volume et croissance :

• Plus de 50 000 enregistrements prévus sur 2 ans ?

• Croissance supérieure à 20% par an ?

• Archivage impossible ou non souhaité ?

Complexité technique :

• Plus de 10 tables/entités ?

• Relations N:N nécessaires ?

• Logique métier serveur requise (calculs complexes, validations) ?

• Transactions multi-tables avec rollback ?

Criticité métier :

• Données financières ou réglementées ?

• SLA de disponibilité supérieur à 99% requis ?

• Perte de données = impact business critique ?

• Audit trail réglementaire obligatoire ?

Concurrence et performance :

• Plus de 50 utilisateurs simultanés ?

• Besoin de temps de réponse inférieur à 2 secondes ?

• Écritures simultanées sur mêmes enregistrements ?

Budget et licences :

• Budget récurrent supérieur à 10 000€/an disponible ?

• Dynamics 365 déjà déployé dans l’entreprise ?

• Compétences Dataverse en interne ou budget formation ?

Gouvernance et ALM :

• Environnements multiples requis (Dev/Test/Prod) ?

• Déploiements automatisés via CI/CD nécessaires ?

• Gestion de versions et rollback obligatoires ?

Scoring de décision

0-3 OUI → SharePoint suffit (avec optimisations)

4-8 OUI → Analyse coût/bénéfice approfondie requise

9+ OUI → Dataverse recommandé

5. Erreurs fréquentes et mythes

Mythe 1 : "Dataverse est toujours plus performant"

Faux. Sur de petits volumes (moins de 10 000 items), SharePoint avec index bien configurés peut être aussi rapide que Dataverse, voire plus sur certaines opérations de recherche full-text.

Mythe 2 : "SharePoint ne scale pas"

Faux. SharePoint peut gérer des dizaines de millions d’items avec une architecture correcte (exemple : Microsoft utilise SharePoint pour Viva Topics avec des milliards d’items). Le problème est la délégation Power Apps, pas SharePoint lui-même.

Mythe 3 : "Excel est toujours à éviter"

Faux. Pour des référentiels statiques (moins de 500 lignes) modifiés manuellement, Excel peut être plus simple et efficace qu’une table Dataverse. Exemple : liste de codes postaux, pays, catégories métiers.

Mythe 4 : "Dataverse = pas de limites"

Faux. Dataverse a des limites :

• API calls : 40 000/user/jour (ou 6 000 en Per App)

• Taille message : 128 MB max par requête

• Timeout requêtes : 2 minutes max

• Nombre de tables : 1 024 max par environnement

Erreur 1 : Ne pas évaluer le coût total sur 3-5 ans

Beaucoup de projets démarrent sur Dataverse sans calculer :

• Licences utilisateurs (récurrentes)

• Capacité DB (croissance exponentielle)

• Environnements multiples (sandbox, dev, test)

• Formation et montée en compétences

Résultat : Facture qui explose après 2 ans.

Erreur 2 : Sous-estimer l’optimisation SharePoint

Beaucoup abandonnent SharePoint après des problèmes de performance, sans avoir :

• Créé des index sur les colonnes filtrées

• Utilisé des folders pour partitionner

• Optimisé les requêtes Power Apps (StartsWith vs Contains)

• Archivé les données anciennes

Résultat : Migration Dataverse coûteuse alors que SharePoint aurait suffi.

Erreur 3 : Choisir en fonction de la compétence de l’équipe

"On connaît SharePoint, donc on reste sur SharePoint" même si le besoin justifie Dataverse.

Résultat : Dette technique, workarounds complexes, maintenance cauchemardesque.

6. Cas réel et retour d’expérience

Migration SharePoint → Dataverse évitée (économie 80k€)

Contexte :

• Application RH : gestion des congés

• 200 utilisateurs, 25 000 demandes/an

• Performance SharePoint jugée "insuffisante"

• Migration Dataverse planifiée (120k€ sur 3 ans)

Action :

• Audit de l’architecture SharePoint actuelle

• Création de 4 index sur colonnes clés

• Ajout de folders par année pour partitionnement

• Optimisation des formules Power Apps (délégation)

• Archivage automatique supérieur à 3 ans

Résultat :

• Temps de chargement : 8s → 1,2s

• Aucun problème de performance après optimisation

• Coût : 8 000€ (refonte) vs 120k€ (migration)

• ROI : 112k€ économisés

Leçon : Ne pas migrer par défaut. Optimiser d’abord.

7. Arbre de décision simplifié

Question 1 : Dynamics 365 déjà déployé ?

• OUI → Dataverse (synergie native)

• NON → Question 2

Question 2 : Budget supérieur à 10k€/an disponible ?

• NON → SharePoint ou Excel

• OUI → Question 3

Question 3 : Volume supérieur à 100 000 enregistrements OU croissance supérieure à 50%/an ?

• OUI → Dataverse

• NON → Question 4

Question 4 : Plus de 10 tables avec relations complexes (N:N, hiérarchiques) ?

• OUI → Dataverse

• NON → Question 5

Question 5 : Criticité métier forte (finance, réglementaire, CRM) ?

• OUI → Dataverse

• NON → Question 6

Question 6 : Besoin ALM structuré (CI/CD, solutions managées) ?

• OUI → Dataverse

• NON → SharePoint

Exception : Si moins de 1000 enregistrements ET prototype → Excel acceptable

Conclusion : la décision doit être data-driven

Le choix entre Excel, SharePoint et Dataverse n’est pas idéologique mais technique et économique :

1. Analysez vos besoins réels : volume, complexité, criticité, budget

2. Calculez le TCO sur 3-5 ans : licences + capacité + développement + maintenance

3. Évaluez les compétences : formation nécessaire vs expertise disponible

4. Testez avec des volumes réalistes : POC avec 80% du volume final, pas 10 lignes

5. Considérez l’hybride : souvent la solution optimale coût/performance

Règles d’or :

✅ Excel : POC, prototypes, référentiels statiques moins de 500 lignes

✅ SharePoint : Apps métiers jusqu’à 100k enregistrements avec architecture optimisée

✅ Dataverse : Apps stratégiques supérieur à 100k enregistrements, relationnel complexe, intégrations multiples

✅ Hybride : Le meilleur des deux mondes dans 60% des cas

La pire erreur : choisir par défaut sans analyse. La meilleure décision : celle basée sur des critères mesurables et un TCO calculé.

Ressources complémentaires :

• Limites de délégation SharePoint (Microsoft)

• Pricing Dataverse Calculator

• SharePoint limits and boundaries