Explique moi ce qu'est le DataVerse dans le monde de PowerApps, une simple BD?, une BD objet, c'est un peu abstrait pour moi...
Dataverse est souvent présenté comme une base de données, mais ce n'est pas tout à fait une base relationnelle classique comme SQL Server ou PostgreSQL. C'est plutôt une plateforme de données métier (business data platform) construite par Microsoft pour l'écosystème Power Platform (Power Apps, Power Automate, Power BI, Dynamics 365).
L'analogie la plus simple
Imagine trois niveaux :
| Niveau | Exemple |
|---|---|
| Base de données classique | SQL Server, PostgreSQL |
| ORM / Modèle objet | Entity Framework |
| Application métier | CRM, ERP |
Dataverse combine un peu les trois.
Comment Dataverse stocke les données ?
Dans Dataverse, on ne parle pas de :
- Tables SQL
- Colonnes SQL
- Clés étrangères
Même si techniquement c'est ce qui existe derrière.
On parle plutôt de :
- Tables (anciennement Entités)
- Colonnes
- Relations
- Lignes (Rows)
Exemple :
Table Client
| Nom | Courriel | Téléphone |
|---|---|---|
| Jean | jean@test.com | 514-1234 |
Table Projet
| Nom Projet | Budget |
|---|---|
| Portail RH | 50 000$ |
Relation
Un client peut avoir plusieurs projets.
C'est exactement le même concept qu'une base relationnelle.
Pourquoi ça semble abstrait ?
Parce que Dataverse ajoute une couche métier au-dessus de la BD.
Quand tu crées une table "Client", tu obtiens automatiquement :
Métadonnées
- Description
- Types de données
- Étiquettes multilingues
- Validation
Sécurité
- Qui peut lire ?
- Qui peut modifier ?
- Qui peut supprimer ?
API
Automatiquement exposée en :
- REST API
- OData
- Connecteurs Power Platform
Interface utilisateur
Power Apps peut immédiatement utiliser la table sans coder.
Ce n'est pas une BD objet
C'est probablement ce qui te mélange.
Dataverse ressemble à un modèle objet :
Client
├─ Nom
├─ Courriel
└─ Projets
mais en réalité, c'est toujours relationnel.
Par exemple :
Client
1 ---- n Projet
est stocké comme une relation classique.
Donc :
❌ Ce n'est pas une base orientée objet (comme db4o ou ObjectDB)
❌ Ce n'est pas une base NoSQL
✅ C'est une base relationnelle enrichie de métadonnées métier
Une comparaison avec Entity Framework
Si tu connais EF :
public class Client
{
public Guid Id { get; set; }
public string Nom { get; set; }
public List<Projet> Projets { get; set; }
}
Dans Dataverse, tu définis essentiellement ce modèle :
Table Client
Table Projet
Relation Client-Projet
et Microsoft génère pour toi :
- le schéma physique
- les API
- la sécurité
- les formulaires
- les connecteurs Power Platform
Ce qui différencie Dataverse d'une simple BD SQL
Avec SQL Server tu dois gérer :
CREATE TABLE
CREATE INDEX
API REST
Authentification
Permissions
Audits
Historique
Avec Dataverse :
Créer une table
Créer les colonnes
Créer les relations
et le reste est déjà fourni.
Dans l'univers Power Apps
Le rôle de Dataverse est comparable à celui-ci :
Power Apps
|
Power Automate
|
Power BI
|
-------------------
|
Dataverse
|
-------------------
|
Azure SQL (caché)
Tu pourrais voir Dataverse comme :
"Un SQL Server métier géré par Microsoft, enrichi de métadonnées, de sécurité, d'API et d'intégration native avec Power Platform."
Une analogie pour un architecte logiciel
Si SQL Server est :
Le moteur de la voiture
Dataverse est :
Le moteur
+
La transmission
+
Le tableau de bord
+
Les ceintures de sécurité
+
L'ordinateur de bord
Tu perds un peu de contrôle bas niveau, mais tu gagnes énormément en rapidité pour construire des applications métier.
C'est pour cette raison que les solutions Dynamics 365 (CRM, Service, Sales, etc.) sont aujourd'hui essentiellement des applications construites sur Dataverse. C'est beaucoup plus qu'une base de données : c'est la couche de données métier standard de tout l'écosystème Microsoft Power Platform.
Au niveau performance par contre, ça ne peut surement pas battre un vrai système c'est tellement générique...
Tu as raison... et tort en même temps. 😊
La réponse d'architecte est : ça dépend de ce qu'on mesure.
Si on parle de performance brute
Un système développé sur mesure avec :
- PostgreSQL
- SQL Server
- API .NET optimisées
- Caching Redis
- Requêtes SQL écrites à la main
va presque toujours battre Dataverse.
Par exemple :
| Opération | SQL optimisé | Dataverse |
|---|---|---|
| SELECT simple | Très rapide | Rapide |
| Requête complexe multi-joins | Très rapide | Plus lent |
| Traitement de masse | Très rapide | Moyen |
| Millions de transactions/jour | Excellent | Limité |
| Contrôle des index | Total | Très limité |
Microsoft cache toute la couche physique.
Tu ne peux pas :
CREATE INDEX ...
ni
OPTION(RECOMPILE)
ni optimiser un plan d'exécution.
Pour quelqu'un comme toi qui a travaillé avec SQL Server, PostgreSQL, Kubernetes et l'optimisation d'applications .NET, ça peut donner l'impression d'avoir les mains attachées.
Mais ce n'est pas le problème que Dataverse cherche à résoudre
Microsoft ne vend pas Dataverse comme :
"Le système le plus performant."
Ils le vendent comme :
"Le système le plus rapide à construire et maintenir."
Prenons un exemple.
Application de gestion des demandes
En mode traditionnel :
PostgreSQL
+
API .NET
+
React
+
Authentification
+
Gestion des rôles
+
Audit
+
Historique
+
Recherche
+
Notifications
6 mois de développement.
Même besoin avec Dataverse
Dataverse
+
Power Apps
+
Power Automate
3 semaines.
Les utilisateurs sont contents.
La charge :
500 employés
20 000 dossiers
Dataverse est largement suffisant.
Là où ça commence à souffrir
J'ai vu plusieurs projets Power Platform frapper des murs quand ils arrivent à :
Très gros volumes
50 millions
100 millions
500 millions d'enregistrements
Requêtes analytiques complexes
Exemple :
15 tables
8 joins
agrégations
window functions
Dataverse n'est pas conçu pour ça.
Intégration temps réel haute fréquence
Exemple :
IoT
Télémétrie
Transactions financières
Logs applicatifs
Là on est complètement hors cible.
L'erreur fréquente des architectes
Les architectes logiciels expérimentés regardent Dataverse et pensent :
"C'est un mauvais SQL Server."
Alors que Microsoft le positionne comme :
"Un excellent Dynamics/CRM platform."
C'est comme comparer :
SAP
Salesforce
Dynamics
avec
PostgreSQL
Ce ne sont pas les mêmes catégories.
L'endroit où Dataverse est étonnamment bon
La sécurité.
Si demain tu dois construire un système gouvernemental avec :
- RBAC
- sécurité par équipe
- sécurité par rôle
- sécurité par enregistrement
- audit complet
- historique
En .NET classique, ça représente facilement :
30 à 40 % du développement
Dans Dataverse :
Configuration
Le moteur est déjà là.
Une règle que j'utilise
Dataverse est excellent pour :
- CRM
- Gestion de dossiers
- Workflow administratif
- Applications RH
- Processus gouvernementaux
- Gestion documentaire légère
- Applications low-code
Dataverse est mauvais pour :
- OLTP intensif
- ERP manufacturier lourd
- Temps réel
- Big Data
- Analytique complexe
- Charges massives
Donc ton intuition est bonne :
Un architecte qui construit une solution .NET/PostgreSQL optimisée va presque toujours obtenir de meilleures performances et une meilleure maîtrise qu'avec Dataverse.
Mais la vraie question est souvent :
« Est-ce que j'ai besoin de 10 ms de temps de réponse ou est-ce que j'ai besoin de livrer l'application dans 2 mois plutôt que dans 12 ? »
C'est là que Dataverse gagne souvent la bataille, même lorsqu'il perd la comparaison technique pure.
Par contre si je comprends bien, il faut être prêt à s'attacher à un vendeur et sortir notre argent pour s'en servir...
Oui. Et c'est probablement la principale critique architecturale qu'on peut faire à Dataverse.
Quand tu adoptes Dataverse, tu n'adoptes pas seulement une technologie, tu adoptes pratiquement tout l'écosystème Microsoft Power Platform :
- Dataverse
- Power Apps
- Power Automate
- Dynamics 365
- Azure AD / Entra ID
- Connecteurs Microsoft
C'est du vendor lock-in assumé.
Avec PostgreSQL
Tu possèdes essentiellement tes données :
PostgreSQL
|
+--> .NET
+--> Java
+--> Python
+--> React
+--> Angular
+--> Power BI
+--> Tableau
Si demain tu veux migrer :
- AWS
- Azure
- On-prem
- Kubernetes
ça reste faisable.
Avec Dataverse
Tu es plutôt dans :
Power Apps
|
Power Automate
|
Dataverse
|
Microsoft Cloud
Le jour où tu veux sortir de là :
- récupérer les données est possible ;
- récupérer les règles métier est difficile ;
- récupérer les workflows est pénible ;
- récupérer les formulaires est souvent une réécriture complète.
Les données sont exportables.
L'application, beaucoup moins.
Le piège financier
Au début :
« On va faire ça en low-code et sauver beaucoup d'argent. »
Et souvent c'est vrai.
Mais après quelques années :
500 utilisateurs
Power Apps Premium
Dataverse
Power Automate Premium
Connecteurs Premium
La facture devient significative.
Tu échanges :
CAPEX de développement
contre
OPEX de licences
Là où Microsoft est intelligent
Ils ont compris que :
Pour beaucoup d'organisations, notamment gouvernementales ou grandes entreprises :
10 développeurs pendant 2 ans
coûtent beaucoup plus cher que :
Licences Power Platform
Donc le modèle économique fonctionne.
Comme architecte d'entreprise
Je vois souvent trois catégories :
1. Application stratégique
Exemple :
- système cœur métier
- propriété intellectuelle
- avantage concurrentiel
Je préfère :
.NET
PostgreSQL
Kubernetes
ou équivalent.
Je garde le contrôle.
2. Application administrative
Exemple :
- demandes RH
- gestion des équipements
- approbations
- formulaires internes
Là Dataverse est souvent un excellent choix.
3. Application temporaire
Exemple :
- projet de 2 ans
- programme gouvernemental
- besoin rapide
Dataverse devient très intéressant.
La vraie question
Pour moi, Dataverse n'est pas tant un problème de performance qu'un problème de souveraineté technologique.
Quand tu bâtis sur PostgreSQL :
Tu loues de l'infrastructure.
Quand tu bâtis sur Dataverse :
Tu loues une partie de ton architecture.
Certaines organisations acceptent très bien ce compromis. D'autres, particulièrement celles qui ont une forte culture d'ingénierie ou des exigences de contrôle à long terme, le vivent beaucoup moins bien.
Vu ton profil d'architecte et ton expérience avec les stacks ouvertes (.NET, PostgreSQL, Kubernetes, DevSecOps), il est normal que ton premier réflexe soit de te demander : « Combien de liberté est-ce que je perds en échange de cette rapidité de développement ? » C'est généralement la première question que se posent les architectes expérimentés devant la Power Platform.
Alors c'est low code, mais actuellement la demande est forte pour les ressources qui maitrisent cet environnement, et ces dernières ont tendance à coûter plus cher... moi je croyais que l'objectif entre autre était de pousser ces développement dans la cours des gens affaire.
Tu touches à un point très intéressant, parce que c'est exactement le discours que Microsoft tenait il y a 8-10 ans :
« Les gens d'affaires vont pouvoir construire leurs propres applications sans dépendre de l'informatique. »
Dans la pratique, ce n'est arrivé que partiellement.
La promesse du "citizen developer"
L'idée était :
Utilisateur RH
|
+--> crée un formulaire
+--> ajoute un workflow
+--> publie une application
sans :
- développeur
- architecte
- DBA
- DevOps
Pour des besoins simples, ça fonctionne réellement.
Par exemple :
- formulaire de demande de vacances
- approbation d'achats
- inventaire d'équipement
- gestion de formation
Un analyste d'affaires motivé peut effectivement construire ça.
Ce qui s'est passé dans les grandes organisations
Après quelques années, les applications sont devenues :
Power Apps
+
Dataverse
+
Power Automate
+
SAP
+
ServiceNow
+
Dynamics
+
API REST
+
Sécurité complexe
+
Conformité
Et soudainement :
- gestion des environnements
- pipelines CI/CD
- ALM
- gouvernance
- sécurité
- licences
- performance
- intégration
sont devenues des sujets importants.
À ce moment-là, le "citizen developer" disparaît progressivement et on voit apparaître une nouvelle spécialité :
Développeur Power Platform
C'est le même phénomène qu'avec SharePoint
J'ai vécu ça plusieurs fois.
Le discours initial :
« Les utilisateurs vont faire leurs propres sites. »
10 ans plus tard :
Architecte SharePoint
Développeur SharePoint
Administrateur SharePoint
Expert SharePoint
Power Platform suit un peu la même trajectoire.
Pourquoi les experts Power Platform coûtent cher
Parce qu'ils se situent dans une drôle de zone.
Ils doivent comprendre :
Le monde affaire
- processus
- workflows
- UX
Le monde Microsoft
- Dataverse
- Power Apps
- Power Automate
- Entra ID
Le monde TI
- API
- OAuth
- Azure
- ALM
- DevOps
Ce n'est plus vraiment du low-code.
C'est devenu une expertise spécialisée.
Un paradoxe amusant
Plus une organisation adopte Power Platform sérieusement, plus elle finit par recréer les rôles qu'elle voulait éliminer.
On voit apparaître :
Centre d'excellence (CoE)
Architecte Power Platform
Développeur Power Platform Senior
Administrateur Dataverse
Spécialiste Gouvernance
alors que le discours de départ était :
« Les utilisateurs vont le faire eux-mêmes. »
Ce qui est quand même vrai
Là où Microsoft a gagné son pari, c'est sur la productivité.
Un développeur Power Platform compétent peut souvent livrer une application métier en :
2 à 6 semaines
alors qu'une équipe traditionnelle aurait peut-être besoin de :
3 à 6 mois
Donc même si la ressource coûte plus cher à l'heure :
150$/h
au lieu de :
100$/h
le coût total du projet peut rester inférieur.
À mon avis, la vision du citizen developer a surtout servi d'argument marketing pour ouvrir les portes des organisations. Aujourd'hui, dans les grandes entreprises et les ministères, Power Platform est davantage une plateforme de développement spécialisée à haute productivité qu'un véritable outil destiné aux utilisateurs d'affaires autonomes.
Quand je regarde les offres d'emploi actuelles, je vois rarement des postes de "citizen developer". Je vois plutôt :
- Architecte Power Platform
- Développeur Power Apps Senior
- Consultant Dataverse
- Spécialiste ALM Power Platform
Ce qui est assez révélateur de l'évolution réelle du marché.
Soyons un peu plus technique et concret: Interfaces avec éléments sur mesure (fetch xml, JavaScript, tables liées, Liquid code
Ark, encore des patantes à mêler dans le HTML
😂 Oui, c'est souvent la réaction des développeurs qui arrivent dans Power Pages après avoir travaillé avec Razor, React ou Angular.
Tu regardes un fichier et tu vois :
<div class="container">
{% if user %}
<h1>{{ user.fullname }}</h1>
{% endif %}
</div>
Et ton cerveau te dit :
« Ah non... pas encore du code caché dans le markup... »
L'histoire du développement web est d'ailleurs une succession de tentatives pour sortir la logique du HTML :
ASP Classic <% ... %>
PHP <?php ... ?>
JSP <% ... %>
ASP.NET WebForms <%# ... %>
Razor @...
Liquid {{ ... }}
React JSX { ... }
Angular *ngFor
Vue {{ ... }}
À chaque génération, on promet :
« Cette fois-ci, la séparation des responsabilités sera parfaite. »
Puis on finit toujours par remettre un peu de logique dans les vues parce que c'est pratique.
Ce qui risque particulièrement de t'irriter dans Power Pages, c'est le combo :
{% fetchxml %}
...
{% endfetchxml %}
Autrement dit :
+ HTML
+ Template
+ Requête Dataverse
dans le même fichier.
Pour un architecte habitué à :
Controller
↓
Service
↓
Repository
↓
SQL
ça donne parfois une impression de retour en arrière.
Le côté amusant, c'est que Microsoft vend souvent Power Pages comme du low-code.
Puis tu ouvres un vrai portail de production et tu trouves :
HTML
CSS
Bootstrap
JavaScript
Liquid
FetchXML
Dataverse Security
Web Roles
Web API
et tu te dis :
« Les développeurs ont juste été remplacés par des développeurs Power Platform. »
C'est d'ailleurs une des raisons pour lesquelles les ressources Power Pages expérimentées sont recherchées. Les projets simples restent low-code, mais dès qu'un client demande :
- une expérience utilisateur personnalisée ;
- des règles d'affichage complexes ;
- des intégrations externes ;
- des performances acceptables sur de gros volumes ;
on se retrouve à faire du développement web assez traditionnel, simplement avec un ensemble d'outils Microsoft différent.
En tant que développeur .NET, tu vas probablement avoir le même réflexe que beaucoup de gens :
« Si je dois écrire du HTML, du JavaScript, des templates, des requêtes et gérer la sécurité... pourquoi ne pas faire un vrai frontend React/Blazor et appeler une API ? »
Et c'est exactement la question qui déclenche la plupart des débats d'architecture autour de Power Platform. 😄
