Low Code mon amour (sarcasme)

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é.