Une base de données pour toutes les Business Apps — Dataverse plutôt que silos.

L'idée en un paragraphe

Quand toutes les apps lisent et écrivent dans la même base, il n'y a plus d'interfaces.

L'idée n'est pas nouvelle. Les architectes mainframe pensaient déjà ainsi dans les années 1970. SAP l'a réalisée commercialement dans les années 1990 comme solution Grand Compte. Ce qui est nouveau : cela fonctionne désormais aussi en PME, avec une architecture web moderne, sans projet SAP S/4 de 12 mois. La stack s'appelle Microsoft Dataverse.

Dataverse est la plateforme de données métier sous Microsoft Power Platform et Microsoft Dynamics 365. Ce n'est pas simplement une base SQL dans le cloud. C'est un modèle de données métier avec autorisations intégrées, journal d'audit, règles de validation, déclencheurs de workflow, métadonnées multilingues et API REST unifiée. Power Apps, Power Automate, Dynamics 365 Sales, Customer Service, Field Service, Project Operations, Copilot Studio, intégrations Teams et liens SharePoint travaillent sur le même modèle sémantique.

Cela a une conséquence que beaucoup d'architectes ne saisissent vraiment qu'après un premier déploiement productif : construire une nouvelle application métier, ce n'est plus « designer le schéma de données, puis le frontend, puis intégrer avec les autres systèmes ». C'est « créer ou étendre des tables Dataverse, puis construire le frontend ». L'intégration est déjà là, parce que toutes les autres apps lisent et écrivent déjà sur le même socle de données.

Délimitation honnête

Trois scénarios où l'idée ne convient pas.

Nous ne vendons pas l'architecture base unique comme une panacée. Trois constellations où nous déconseillons activement la consolidation complète :

1. Logiciels métier hautement spécialisés avec leur propre profondeur de données. Qui utilise SAP S/4HANA comme ERP Groupe, pilote une supervision MES au niveau machine ou gère une administration CAO spécialisée — ne mettra pas cela dans Dataverse. Ce n'est pas non plus l'objectif. La bonne réponse ici : des zones Dataverse claires pour la couche d'administration métier (ventes, service, opérations terrain, analyses commerciales) et des interfaces maîtres bien définies vers les systèmes spécialisés.
2. Séparation réglementaire. Les zones de conformité qui doivent être tenues organisationnellement et techniquement séparées — par exemple les données patient d'un système hospitalier ou certaines données de services financiers — n'ont rien à faire sur la même plateforme de données que le marketing. Là encore : Dataverse pour la partie non régulée, stack séparé pour la partie régulée, contrats d'interface clairs.
3. Phases de transition organisationnelles. Pendant une intégration M&A, une scission d'activité ou une joint-venture avec IT propre, il est rarement judicieux de tout forcer immédiatement dans une seule instance Dataverse. La réponse d'architecture ici : plusieurs environnements Dataverse avec fédération sélective ou synchronisations maîtres bien définies.

Dans tous les autres cas — et c'est la majorité des paysages PME que nous voyons — l'architecture base unique l'emporte nettement. Qui a 80 % de ses données métier sur une plateforme commune a un avantage structurel de maintenance face à qui détient ses 80 % sur douze bases séparées.

Comment se déroule la transition

Par vagues, pas en Big Bang.

La plus grande erreur dans la transition depuis un paysage en silos est d'essayer de tout migrer d'un coup. Chemin réaliste en trois vagues sur 12 à 36 mois :

Vague 1 — migrer le socle central (3 à 6 mois). Vous choisissez un domaine métier central — typiquement les données CRM (Comptes, Contacts, Opportunités) ou les données Service (Tickets, parc Assets). Vous migrez ce domaine vers Dataverse, construisez la première app productive (typiquement Dynamics 365 Sales ou Customer Service) et établissez ce modèle comme Single Source of Truth. Les systèmes silos existants reçoivent des synchronisations en lecture depuis Dataverse.

Vague 2 — consolider les apps adjacentes (6 à 12 mois). Outils Excel isolés, contrats tiers simples, petites applications spécialisées sont reconstruits en Power Apps — directement sur le socle Dataverse issu de la vague 1. L'automation marketing attaque maintenant directement le socle Comptes, le technicien Field Service voit l'historique service depuis le même modèle Dataverse, la gestion contractuelle tourne sur les mêmes données Contacts.

Vague 3 — intégrer ou remplacer les systèmes spécialisés (12 à 24 mois). Les systèmes spécialisés existants — ERP, MES, solutions tierces sectorielles — restent soit avec une interface bien définie vers le socle Dataverse (via Dataverse Virtual Tables ou Connectors), soit sont remplacés dans la feuille de route. Les décisions ici sont typiquement spécifiques au cas et exigent l'implication de la direction.

Ce qui fait fonctionner ce chemin : un engagement clair de la direction dès la vague 1. Qui poursuit l'idée « uniquement en DSI » reste bloqué après la vague 1 — et la nouvelle instance Dataverse devient simplement un silo de plus.