Votre ERP contient les données les plus stratégiques de votre entreprise : commandes, stocks, marges, DSO, coûts de production. Votre Power BI consomme une copie vieille de 24 heures exportée par un script Python qui tourne la nuit. Entre les deux, un data engineer passe ses vendredis à réconcilier des tables qui ne se joignent pas.
Microsoft Fabric propose une architecture différente. Depuis son lancement en disponibilité générale en novembre 2023, la plateforme unifie en un seul plan ce qui était auparavant dispersé entre Azure Data Factory, Azure Synapse Analytics, Power BI Premium et Azure Data Lake Storage Gen2. Pour un DSI qui supervise un ou plusieurs ERPs sous Azure, la question n’est plus “faut-il regarder Fabric ?” mais “comment l’architecturer correctement ?”
Ce guide pratique détaille les connecteurs disponibles par ERP, le pipeline de données en quatre étapes, et les cas d’usage concrets pour une ETI industrielle.
Qu’est-ce que Microsoft Fabric et pourquoi les DSI en parlent en 2026
Fabric = Data Factory + Synapse + Power BI + OneLake dans un seul plan
Microsoft Fabric est une plateforme SaaS d’analytique unifiée qui regroupe sous une seule interface et un seul modèle de licence six expériences distinctes : Data Factory (ingestion et orchestration), Data Engineering (notebooks Spark), Data Warehousing (entrepôt relationnel), Real-Time Intelligence (event streams), Data Science (ML) et Power BI (visualisation).
L’élément central qui différencie Fabric d’une simple intégration de services Azure est OneLake. OneLake est un espace de stockage unique, géré par Microsoft sur Azure Data Lake Storage Gen2, dans lequel tous les composants Fabric lisent et écrivent sans dupliquer les données. Un fichier Delta Lake ingéré par un pipeline Data Factory est immédiatement lisible par un notebook Spark, interrogeable par un entrepôt SQL et visualisable dans Power BI, sans copie intermédiaire.
Pour un DSI habitué aux architectures ERP classiques avec trois ou quatre entrepôts distincts (SQL Server du reporting, SFTP de l’intégrateur, cube SSAS, Blob Storage des archives), le passage à un seul lac mutualisé est un changement d’architecture substantiel.
Positionnement vis-à-vis d’Azure Data Factory seul et de Databricks
Azure Data Factory seul reste pertinent pour des pipelines ETL ciblés entre deux systèmes. Mais il ne fournit ni stockage centralisé, ni moteur SQL, ni visualisation. Une architecture ADF classique exige de provisionner séparément un Azure Synapse ou un Azure SQL Database, un Power BI Premium, et un ADLS Gen2. Fabric regroupe ces éléments avec une gouvernance unifiée des licences.
Databricks est une alternative sérieuse sur le segment de la data science et des grands volumes. Il supporte aussi bien le format Delta Lake. La différence structurelle : Databricks est multi-cloud et positionné sur les équipes data engineering avancées. Fabric est optimisé pour les organisations Microsoft (Teams, SharePoint, Dynamics 365) et intègre Power BI nativement, ce qui réduit la courbe d’adoption pour les équipes métier.
Pour une ETI sous Azure qui n’a pas d’équipe data engineering dédiée mais dispose d’un ou deux power users Power BI, Fabric est généralement plus accessible.
Tarification Fabric : SKU F4 à F2048, ce que ça coûte réellement pour une ETI
Microsoft Fabric fonctionne sur des capacités Azure achetées à la demande ou en réservation annuelle. Les SKUs sont nommés de F2 à F8192, chaque palier doublant la puissance de calcul disponible.
Pour une ETI qui centralise deux à trois ERPs avec des volumes de données raisonnables (moins de 500 Go de tables opérationnelles), un F8 est en général un point de départ suffisant. D’après les tarifs Azure West Europe vérifiés en juillet 2026 (Agilytic), un F8 coûte environ 657 EUR/mois en réservation annuelle, soit environ 1 300 EUR/mois en pay-as-you-go. La réservation est environ 40 % moins chère mais facturation continue.
Avantage tactique du pay-as-you-go : la capacité peut être mise en pause pendant les heures creuses (nuit, week-end), ce qui réduit la facture réelle de 50 à 70 % si votre pipeline est uniquement batch.
La licence par utilisateur (Free, Pro, PPU) s’ajoute à la capacité. Depuis un F64 ou supérieur, les utilisateurs avec une licence Free peuvent visualiser des rapports Power BI en lecture seule. En dessous de F64, chaque lecteur Power BI a besoin d’une licence Pro (environ 10 EUR/mois/utilisateur).
Les connecteurs natifs Fabric pour les principaux ERP
Dynamics 365 Finance & Supply Chain — connexion native via Fabric Link
Pour les organisations sous Dynamics 365 Finance ou Supply Chain Management, Microsoft propose Fabric Link (anciennement Azure Synapse Link for Dataverse). L’intégration est native : depuis le portail Power Apps, l’administrateur active l’export des tables Dataverse directement vers OneLake, sans construire de pipeline personnalisé.
Les tables D365 (commandes, stocks, général ledger, entités comptables) apparaissent dans votre lakehouse Fabric sous forme de fichiers Delta Lake, mis à jour en quasi-temps réel par change data capture. Microsoft a officiellement décommissionné l’ancienne fonctionnalité “Export to Data Lake” le 25 mars 2025 (Microsoft Learn), rendant Fabric Link la voie standard pour Dynamics 365.
La couverture est large : Finance, Supply Chain Management, Customer Insights, Field Service et Marketing sont supportés via Dataverse.
SAP S/4HANA et SAP HANA — via les connecteurs SAP dans Fabric
Pour SAP, Fabric propose plusieurs approches selon la version et le mode de déploiement :
- SAP HANA connector (GA depuis 2024 dans Fabric Pipelines) : connexion directe à une instance SAP HANA on-premise ou cloud via SQL. Supporte la copie partitionnée pour les grands volumes. Requiert un Self-Hosted Integration Runtime (SHIR) pour les instances on-premise.
- OData connector (Fabric Dataflows Gen2 ou Pipelines) : pour SAP S/4HANA Public Cloud qui expose ses entités via des API OData (CDS Views, communication arrangements). C’est la voie recommandée pour S/4HANA Cloud sans accès direct à la base HANA.
- Connecteurs partenaires : pour des scénarios avancés (RFC, BAPI, change data capture SAP), des partenaires comme Theobald Software (xtract for Fabric) ou USB4SAP permettent des extractions plus complètes depuis des systèmes SAP ECC ou S/4HANA on-premise.
Microsoft a également annoncé en 2025 une collaboration renforcée avec plusieurs partenaires SAP spécialisés pour couvrir les scénarios analytiques S/4HANA, notamment les snapshots de tables et les CDS queries (Microsoft Community Hub).
Odoo, Sage X3, Cegid XRP Flex — via Dataflow Gen2 et pipelines REST
Pour les ERPs qui ne disposent pas de connecteur natif Fabric, la voie générique repose sur leur API REST ou OData :
- Odoo expose une API XML-RPC et, depuis la version 16, une API REST JSON. Un Dataflow Gen2 dans Fabric peut interroger ces endpoints pour extraire les modèles de données (sale.order, account.move, stock.quant) et les charger dans un lakehouse.
- Sage X3 et Cegid XRP Flex exposent des APIs REST documentées. L’ingestion se construit via Fabric Pipelines avec le connecteur REST générique. La pagination et la gestion des tokens OAuth sont configurables directement dans l’interface Fabric, sans code.
La limite de cette approche : elle est batch (appel périodique à l’API) plutôt que streaming. Pour des rapports actualisés toutes les heures, c’est suffisant. Pour du near real-time (moins de 5 minutes), il faut passer par des webhooks ou des connecteurs CDC dédiés, ce qui augmente la complexité.
OneLake comme couche de gouvernance des données ERP
Le principe “one copy of the truth”
Dans une architecture ERP classique, les données opérationnelles existent en plusieurs copies : dans l’ERP source, dans le datawarehouse du reporting, dans les exports Excel transmis aux managers, et parfois dans un cube OLAP hérité. Chaque copie diverge légèrement dès que les règles métier d’export ne sont pas strictement identiques.
OneLake casse ce modèle en appliquant un principe de shortcut (raccourci) plutôt que de copie. Les tables Dynamics 365 restent dans Dataverse ; elles sont accessibles dans OneLake via un pointeur qui les lit directement, sans duplication. Un rapport Power BI qui interroge ce shortcut lit toujours la donnée source, pas une copie intermédiaire.
Pour les données SAP ou Odoo en revanche, l’ingestion produit une vraie copie dans OneLake (fichiers Delta Lake). Mais cette copie est unique — tous les outils Fabric la partagent. Plus de désynchronisation entre le rapport Finance et le rapport Supply Chain parce qu’ils lisent deux entrepôts différents mis à jour à des moments différents.
Gestion des droits et cloisonnement par domaine
OneLake intègre Microsoft Purview pour la gouvernance et le catalogage. Chaque workspace Fabric correspond à un domaine métier (Finance, Supply Chain, RH) et les droits d’accès sont gérés au niveau des workspaces via les rôles Fabric (Viewer, Contributor, Member, Admin).
Le cloisonnement est important pour les données ERP, qui contiennent souvent des informations sensibles (salaires dans la paie, marges par client, données fournisseurs). Fabric hérite des contrôles d’accès Entra ID de votre tenant Microsoft 365, ce qui évite de gérer un référentiel d’identités séparé.
Microsoft Purview permet également de créer un lignage des données : tracer qu’un chiffre dans un rapport Power BI provient d’une table Dynamics 365 Finance via un pipeline Fabric, avec la date de dernière mise à jour. C’est un argument fort pour les auditeurs et les équipes contrôle de gestion qui veulent comprendre la chaîne de production d’un KPI.
Lakehouse vs Warehouse dans Fabric : quand choisir quoi pour son ERP
Fabric propose deux modes de stockage analytique :
- Lakehouse : stockage en fichiers Delta Lake (format Parquet structuré + logs de transactions). Accessible via Spark (notebooks) et via SQL (endpoint automatique). Idéal pour les données semi-structurées, les grands volumes et les transformations complexes.
- Warehouse : entrepôt SQL géré, avec DDL complet (tables, vues, procédures). Idéal pour les équipes qui veulent raisonner en T-SQL et construire des modèles dimensionnels classiques (étoile ou flocon).
Pour une ETI avec un seul ERP et une équipe limitée : commencer par un Lakehouse. La courbe d’apprentissage est plus douce, et l’endpoint SQL automatique permet de requêter les données sans avoir à gérer un schéma DDL complet.
Pour un groupe avec plusieurs ERPs et une équipe BI expérimentée : un Warehouse en T-SQL facilite la consolidation multi-source, les règles d’intégration explicites et les vues métier partagées.
De la donnée ERP brute aux rapports Power BI — le pipeline en 4 étapes
Étape 1 — Ingestion via Dataflow ou pipeline
La donnée ERP entre dans Fabric via l’un de ces mécanismes :
- Fabric Link (Dynamics 365) : déclenché automatiquement par change data capture, aucun pipeline à maintenir.
- Pipeline Fabric avec un connecteur source (SAP HANA, REST, OData) : orchestration planifiée (toutes les heures, toutes les nuits) ou déclenchée par un événement.
- Dataflow Gen2 : interface low-code inspirée de Power Query, pour des transformations légères à la volée pendant l’ingestion.
La donnée atterrit dans le dossier “Files” du Lakehouse sous forme brute (bronze layer dans l’architecture médaillon).
Étape 2 — Transformation en Delta Lake
Un notebook Spark ou un script SQL transforme les données brutes en tables Delta Lake structurées (silver layer, puis gold layer). Cette étape applique les règles métier : jointure des entités ERP, standardisation des devises, calcul des agrégats (DSO, rotation des stocks, taux de service).
Le format Delta Lake (Parquet + transaction log) garantit l’atomicité des transformations et permet le time-travel : revenir à une version antérieure des données en cas d’erreur de transformation.
Étape 3 — Semantic model Power BI en mode Direct Lake
C’est l’innovation clé de Fabric pour les équipes Power BI : le mode Direct Lake.
En mode Import classique, Power BI copie les données dans un cache en mémoire. C’est rapide, mais les données sont figées jusqu’au prochain refresh (souvent 1 ou 8 fois par jour sur Premium).
En mode DirectQuery, Power BI interroge la base source à chaque interaction. C’est toujours à jour, mais souvent lent sur des volumes ERP.
Le mode Direct Lake combine les deux avantages : Power BI lit directement les fichiers Delta Lake dans OneLake sans les copier, avec des performances proches du mode Import. Dès qu’un pipeline charge de nouvelles données dans le lakehouse, le rapport reflète la mise à jour sans refresh manuel.
Étape 4 — Publication dans Teams et SharePoint pour les métiers
Les rapports Power BI publiés dans un workspace Fabric sont accessibles directement dans Microsoft Teams (onglet Power BI dans un canal) et dans SharePoint Online (webpart Power BI). Les utilisateurs métier accèdent aux KPIs ERP sans quitter leurs outils habituels.
Pour les profils non techniques (direction, managers opérationnels), cette intégration réduit la friction d’adoption. Le rapport n’est pas “dans le SI” ; il est dans le canal Teams du comité de direction.
Cas d’usage concrets pour une ETI industrielle
Dashboard DSO en temps réel depuis Dynamics 365
Le Days Sales Outstanding (délai moyen d’encaissement des créances clients) est un indicateur clé pour la trésorerie d’une ETI. Calculé manuellement depuis un export comptable, il est souvent disponible en fin de semaine seulement.
Avec Fabric Link + D365 Finance, les tables de factures et de règlements sont exportées en continu vers OneLake. Un modèle sémantique calcule le DSO par client, par commercial et par segment en Direct Lake. Le directeur financier consulte un chiffre actualisé en continu dans Teams, pas un export Excel du vendredi.
Consolidation multi-ERP pour un groupe ETI
Un groupe avec une filiale française sous SAP S/4HANA et une filiale allemande sous Odoo 17 dispose de deux référentiels de données incompatibles : comptes de charges différents, devises, règles de consolidation spécifiques.
Fabric centralise les deux sources dans OneLake. Une couche de transformation en Spark normalise les plans de comptes vers un référentiel groupe. Le rapport de consolidation mensuel, autrefois produit en cinq jours par le contrôleur de gestion, devient un tableau de bord actualisé chaque nuit.
L’exemple chiffré que le brief suggère est réaliste : une ETI de 300 salariés qui centralise trois ERPs dans un Fabric F8 (environ 657 EUR/mois en réservation West Europe, d’après Agilytic) peut produire quinze rapports Power BI en Direct Lake. Sans Fabric, une architecture équivalente exige un Azure Data Factory, un Azure Synapse Analytics, un Power BI Premium et un ADLS Gen2 gérés séparément — avec des coûts de maintenance et d’expertise bien supérieurs.
Analyse prédictive des achats via les notebooks Fabric
Une fois les données ERP dans OneLake, les notebooks Fabric (Python/Spark) peuvent entraîner des modèles de prévision sur l’historique des commandes fournisseurs. Un modèle simple (régression linéaire ou Random Forest sur les volumes saisonniers) permet d’anticiper les ruptures de stock et d’optimiser les réapprovisionnements.
L’avantage de Fabric par rapport à un projet ML ad hoc : le notebook s’exécute sur la même capacité que le pipeline d’ingestion et le rapport Power BI. Aucun environnement ML séparé à provisionner. Le modèle entraîné est exportable vers Azure ML si le besoin devient plus complexe.
Pièges et limites à anticiper
Latence des données : batch vs near real-time
Sauf pour Dynamics 365 via Fabric Link (qui est basé sur change data capture), la plupart des intégrations ERP dans Fabric sont batch : le pipeline se déclenche toutes les heures, toutes les nuits ou à la demande. Les rapports reflètent donc des données avec un délai.
Pour des cas d’usage où la fraîcheur est critique (gestion des stocks en temps réel, alertes de trésorerie intraday), batch n’est pas suffisant. Il faut alors passer par les fonctionnalités de Real-Time Intelligence de Fabric (KQL databases, Event Streams) couplées à des webhooks de l’ERP. La complexité et le coût augmentent.
Bien définir le niveau de fraîcheur requis avant d’architecturer la solution est un prérequis que beaucoup d’équipes négligent.
ERP on-premise et Self-Hosted Integration Runtime
Pour les ERPs hébergés on-premise (SAP ECC, Sage X3 sur site, Dynamics AX 2012), Fabric ne peut pas accéder directement à la base de données depuis le cloud. La connexion passe par un Self-Hosted Integration Runtime (SHIR) : un agent installé sur un serveur du réseau interne, qui relaie les requêtes Fabric vers la source de données locale.
Le SHIR est une machine Windows dédiée (ou une VM), avec les contraintes de maintenance qui en découlent : mises à jour, disponibilité, sécurité réseau. Pour les organisations qui veulent supprimer toute infrastructure on-premise, c’est un frein. Pour celles qui ont déjà une infrastructure hybride Azure, c’est un composant connu et gérable.
Fabric ne remplace pas une stratégie MDM
C’est le piège le plus fréquent. Fabric centralise les données ERP, mais il ne corrige pas leur qualité à la source. Si vos données maîtres (référentiel client, nomenclature articles, plan comptable) sont incohérentes dans l’ERP, Fabric les centralise telles quelles — et agrège les incohérences à grande échelle.
Un fournisseur créé trois fois avec des orthographes différentes dans votre ERP apparaîtra en trois lignes dans votre lakehouse. Un rapport de consolidation basé sur des données maîtres non gouvernées produira des chiffres incorrects, même avec le pipeline Fabric le plus sophistiqué.
Avant de brancher Fabric sur votre ERP, auditez la qualité de vos données maîtres. Si elles sont en désordre, une démarche MDM préalable est indispensable — sur ce sujet, notre guide Master Data Management et ERP couvre la méthodologie en six étapes.
Microsoft Fabric change concrètement l’équation analytique pour les DSI d’ETI sous Azure : une plateforme, un lac mutualisé, des connecteurs natifs pour Dynamics 365 et SAP, et Power BI en Direct Lake pour des rapports toujours à jour. La complexité n’a pas disparu — elle s’est déplacée vers la gouvernance des données maîtres et la définition des niveaux de fraîcheur requis.
Pour aller plus loin sur les KPIs à piloter après le déploiement d’une architecture data ERP, lisez notre guide ERP et Business Intelligence : reporting embarqué, dashboards et analytics en 2026 et notre article sur la gouvernance post-déploiement ERP.
Si vous souhaitez valider l’architecture avant d’engager un budget Fabric, un POC de trois mois sur un processus cible (consolidation comptable ou dashboard DSO) est le format recommandé. Budget typique : 15 000 à 30 000 EUR. Résultat : une décision Go/No-Go avec des chiffres concrets sur la fraîcheur réelle des données, les coûts de capacité et la courbe d’adoption des équipes BI.
