Skip to content
Comment intégrer les données ? Quelle stratégie globale d'intégration choisir (déplacement, orchestration, transformation)Comment déplacer les données ? Quel outil de déplacement privilégier (mise en miroir, travail de copie, activité de copie, flux d'événements)Où stocker les données ? Quel magasin de données utiliser (lakehouse, warehouse, eventhouse, base de données SQL, Cosmos DB)Lakehouse ou warehouse ? Comment trancher entre ces deux options d'entreposage 
Mise en miroir (Mirroring)Solution simple et économique pour répliquer des données dans Fabric.Offre une synchronisation en quasi temps réel sans configuration de pipeline.Données écrites en lecture seule dans OneLake au format Delta.Idéale pour rendre les bases de données accessibles à l'analytique sans impacter les systèmes sources.Travail de copie (Copy Job)Comble le vide entre la mise en miroir et l'activité de copie.Offre une interface assistée sans code.Propose la copie incrémentielle native basée sur des filigranes.Détecte automatiquement les tables compatibles CDC (Change Data Capture)Prend en charge la sélection multi-tables, les comportements upsert et la planification personnalisée sans construction de pipeline.Activité de copie (Copy Activity)Intégrée aux pipelines, offre le plus haut niveau de personnalisation.Permet des requêtes SQL personnalisées à la source.Orchestration avec d'autres activités (procédures stockées, appels API, notifications).Gestion avancée des erreurs.Solution privilégiée pour les architectures médaillon complexes et les volumes à l'échelle du petaoctet.Flux d'événements (Eventstreams)Conçus pour l'ingestion et le traitement de données en streaming temps réel.Permettent d'appliquer des transformations légères (analyse de flux SQL).Routent les événements vers plusieurs destinations (eventhouse, lakehouse, activateur).Créent des tableaux de bord mis à jour en quelques secondes.Adaptés aux scénarios IoT, monitoring et alerting.
Tous les magasins de données Fabric stockent leurs données dans OneLake au format ouvert (Delta).= les données d'un lakehouse peuvent être interrogées depuis un entrepôt via des requêtes inter-bases de données, et vice versa.Le choix du magasin n'est donc pas un choix d'isolation mais de moteur de traitement optimal.
Comment souhaitez-vous développer ?Avez-vous besoin de transactions multi-tables ?Quel type de données analysez-vous ?
Support transactionnel complet multi-tables (ACID) en T-SQLChargement de données à grande échelle avec COPY INTORequêtes inter-bases de données via des noms en trois partiesCompatible avec les outils SQL Server classiques (SSMS, Azure Data Studio)Création de vues, procédures stockées, fonctions et schémasIdéal pour les équipes majoritairement SQL
Gestion native des données structurées et non structuréesMoteur Spark pour les traitements distribués à grande échelleSupport multi-langages : PySpark, Scala, Spark SQL, RArchitecture médaillon (bronze / argent / or) naturelleDécouverte et enregistrement automatiques des tablesPoint de terminaison d'analytique SQL généré automatiquement pour les consommateurs T-SQLIdéal pour l'ingénierie des données et le machine learning Dans la pratique, beaucoup d'organisations utilisent les deux.Le lakehouse sert de zone d'atterrissage et de préparation (couches bronze et argent), tandis que l'entrepôt expose les données modélisées (couche or) aux consommateurs BI.Les deux sont accessibles en lecture croisée grâce au format Delta partagé dans OneLake.
Contexte : une administratrice de bases de données doit rendre des bases SQL Server accessibles à l'analytique en quasi temps réel, sans impacter les systèmes de production. Elle ne souhaite pas créer de pipelines ETL complexes.Solution recommandée : mise en miroir. La réplication est automatique, sans configuration de pipeline, gratuite, et les données sont disponibles en lecture dans OneLake sous forme de tables Delta.
Contexte : un analyste doit consolider des données de ventes provenant de plusieurs bases régionales avec suivi CDC. Il a besoin d'une charge initiale complète puis de mises a jour incrémentielles automatiques, sans code.Solution recommandée : travail de copie. Il offre la sélection multi-tables, la détection automatique CDC, la copie incrémentielle native et une interface assistée sans construction de pipeline.
Contexte : une ingénieure données doit migrer des volumes massifs (de Go à Po) depuis Oracle vers Fabric avec une architecture médaillon (bronze, argent, or). Elle a besoin de planification et d'orchestration.Solution recommandée : activité de copie dans les pipelines. Elle offre la scalabilité nécessaire, l'orchestration des couches médaillon et le support de plus de 50 connecteurs.
Contexte : un chef de produit doit surveiller des métriques opérationnelles en temps réel (volumes d'appels, temps d'attente) et déclencher des alertes automatiques en cas de dépassement de seuils SLA.Solution recommandée : flux d'événements (Eventstreams). Ingestion streaming, transformations légères, routage vers l'eventhouse et l'activateur de données pour les alertes automatiques.
Contexte : une équipe principalement SQL doit créer un entrepôt de données central pour alimenter des tableaux de bord Power BI. Les membres de l'équipe maitrisent T-SQL et les outils SQL Server classiques.Solution recommandée : entrepôt de données Fabric. Support T-SQL complet, requêtes inter-bases, intégration native avec Power BI via Direct Lake, et compatibilité avec les outils existants (SSMS, Azure Data Studio).
Contexte : une data scientist doit travailler sur des jeux de données volumineux en formats variés (CSV, JSON, Parquet), effectuer des analyses statistiques complexes et développer des modèles ML avec Python et Scala.Solution recommandée : lakehouse + notebooks Spark. Environnement interactif multi-langages, calcul distribue, support de centaines de bibliothèques, et combinaison code / visualisations / documentation dans les notebooks.
Contexte : une analyste métier doit intégrer et nettoyer des données provenant de multiples sources (bases de données, API, fichiers) en appliquant des règles métier complexes. Elle maitrise Power Query grâce a son expérience Excel et Power BI.Solution recommandée : Dataflow Gen2. Interface Power Query familière avec 170+ connecteurs et 400+ fonctions de transformation, sans écrire de code.
Support formation Microsoft Fabric
- Pages
Guides de décision
1. Introduction aux guides de décision Fabric
Microsoft Fabric propose un large éventail de services et d'outils pour couvrir l'ensemble du cycle de vie des données : ingestion, transformation, stockage, analyse et visualisation. Face a cette richesse fonctionnelle, il est essentiel de savoir choisir le bon outil pour le bon usage.
Ce document synthétise les quatre guides de décision officiels de Microsoft et les présente sous une forme pédagogique, structurée autour de quatre questions fondamentales :
À retenir
Ces guides ne sont pas exclusifs : dans une architecture Fabric réelle, vous combinerez généralement plusieurs de ces outils. L'objectif est de comprendre le cas d'usage principal de chacun pour faire un choix éclaire.
2. Choisir une stratégie d'intégration des données
Le premier niveau de décision consiste à identifier votre objectif principal. Microsoft Fabric organise l'intégration des données autour de trois piliers : le déplacement, l'orchestration et la transformation. Chaque pilier dispose de ses propres outils.
2.1. Les quatre questions clés
Pour choisir la bonne stratégie, posez-vous ces questions :
Les quatre questions clés
2.2. Les stratégies de déplacement des données
Le déplacement des données consiste à amener les données depuis vos sources vers Fabric. Quatre outils sont disponibles :
Cas d'usage
Réplication continue
Ingestion + réplication
Ingestion de données
Streaming temps réel
Sources
6+ connecteurs
50+ connecteurs
50+ connecteurs
25+ sources
Destinations
OneLake (lecture seule)
40+ connecteurs
40+ connecteurs
4+ destinations
Type de données
Quasi temps réel
Batch / incrémentiel / CDC
Batch / bulk
Streaming continu
Niveau de code
Aucun code
Aucun / low-code
Aucun / low-code
Aucun / low-code
Transformations
Aucune
Faibles
Faibles
Moyennes (Stream Analytics)
Persona cible
Admin BDD, analyste
Analyste, integrateur
Integrateur, ingénieur
Ingénieur, analyste
There are no rows in this table
Source : Microsoft Learn - Guide d'intégration
2.3. Les stratégies d'orchestration
L'orchestration permet de coordonner et planifier l'exécution de plusieurs taches de données. Deux options s'offrent à vous :
Approche
Low-code, visuelle (glisser-deposer)
Code-first (Python, DAGs)
Connecteurs
Tous les connecteurs Fabric
100+ connecteurs Airflow
Niveau de code
Aucun / low-code
Code-first (Python)
Persona cible
Analyste, integrateur, ingénieur
Utilisateurs Apache Airflow
Cas d'usage
Regroupement logique d'activites multiples
Workflows complexes orientes code
There are no rows in this table
2.4. Les stratégies de transformation
La transformation consiste à nettoyer, enrichir et préparer les données pour l'analyse. Trois outils sont disponibles selon votre profil :
Approche
Code-first
Sans code (Power Query)
Sans code / SQL
Sources
100+ bibliotheques Spark
170+ connecteurs + SDK
25+ sources
Destinations
100+ bibliotheques Spark
7+ connecteurs
4+ destinations
Complexite
Elevee (jointures, ML, etc.)
Elevee (400+ transformations)
Moyenne
Niveau de code
Code-first (Python, Scala, R, SQL)
Aucun / low-code
Aucun / low-code
Persona cible
Data scientist, développeur
Ingénieur, analyste
Ingénieur, analyste
There are no rows in this table
Source : Microsoft Learn - Guide d'intégration
3. Choisir une stratégie de déplacement des données
Ce chapitre approfondit le choix du bon outil de déplacement en comparant en détail les quatre mécanismes disponibles dans Fabric.
3.1. Arbre de décision simplifié
Pour choisir rapidement, suivez ce raisonnement :
3.2. Comparaison détaillée des capacités
Le tableau ci-dessous détaillé les capacités fonctionnelles de chaque outil de déplacement :
3.3. Concepts clés par outil
Bonne pratique
Dans de nombreux projets, vous combinerez plusieurs de ces outils. Par exemple : la mise en miroir pour les bases opérationnelles, le travail de copie pour les sources externes, et les flux d'événements pour le monitoring temps réel.
4. Choisir un magasin de données
Une fois les données ingérées dans Fabric, il faut choisir ou les stocker. Fabric propose cinq types de magasins de données, chacun optimise pour des cas d'usage spécifiques. Tous stockent leurs données dans OneLake au format ouvert.
4.1. Les cinq magasins de données Fabric
Lakehouse
Big data, ML, données non/semi-structurées, ingénierie des données
Ingénieur données, data scientist
PySpark, Delta Lake, notebooks
Spark (Scala, PySpark, SQL, R)
Entrepôt de données (Warehouse)
BI SQL, OLAP, entreposage d'entreprise, transactions multi-tables
Développeur warehouse, architecte
Concepts d'entreposage, schema en etoile
T-SQL
Eventhouse
Données de streaming, analytique interactive, series temporelles, haute granularité
Développeur, data scientist, ingénieur
KQL, SQL
KQL, T-SQL
Base de données SQL
Base OLTP, transactions ACID, applications opérationnelles
Développeur, admin BDD
Administration BDD, Azure SQL
T-SQL
Cosmos DB dans Fabric
IA, NoSQL, recherche vectorielle
Développeur IA, développeur applicatif
NoSQL, API REST
JavaScript, Python, C#, Java
There are no rows in this table
Source : Microsoft Learn - Guide magasin de données
4.2. Arbre de décision simplifié
À retenir
5. Lakehouse ou entrepôt de données ?
C'est probablement la question la plus fréquente dans un projet Fabric. Ces deux magasins de données couvrent des cas d'usage proches mais avec des approches différentes. Cette section vous aide à trancher.
5.1. Les trois critères de décision
Microsoft propose trois critères simples pour choisir :
Si vous travaillez principalement avec Spark (PySpark, Scala, R) : choisissez le lakehouse.
Si vous travaillez principalement avec T-SQL : choisissez l'entrepôt.
Non : le lakehouse convient.
Oui : choisissez l'entrepôt (support transactionnel complet T-SQL).
Données structurées et non structurées (fichiers, images, JSON) : choisissez le lakehouse.
Données structurées uniquement : choisissez l'entrepôt.
Vous ne savez pas encore : commencez par le lakehouse (plus flexible).
5.2. Comparaison fonctionnelle détaillée
Fonctionnalite principale
Entreposage complet avec transactions T-SQL (lecture + écriture)
Point de terminaison en lecture seule pour interroger les tables Delta
Profil de développeur
Développeur SQL, citoyen-développeur
Ingénieur données, développeur SQL
Chargement des données
SQL, pipelines, dataflows
Spark, pipelines, dataflows, raccourcis
Prise en charge Delta
Lecture et écriture
Lecture seule
Support T-SQL
Complet : DQL + DML + DDL, transactions complètes
DQL complet, pas de DML, DDL limitée (vues, fonctions table)
Couche de stockage
Format ouvert Delta dans OneLake
Format ouvert Delta dans OneLake
Cas d'usage recommande
Entrepôt d'entreprise, BI SQL, analyses structurées avec tables/vues/procedures
Exploration de tables Delta, zone de préparation (staging), architecture médaillon
There are no rows in this table
Source : Microsoft Learn - Lakehouse vs Warehouse
5.3. Points forts de l'entrepôt de données
5.4. Points forts du lakehouse
Bonne pratique
6. Scénarios de décision
Cette section présente des cas concrets pour illustrer le processus de décision. Pour chaque scénario, identifiez le besoin principal, le profil technique et la solution recommandée.
Scénario 1 : réplication d'une base opérationnelle pour le reporting
Scénario 2 : consolidation incrémentielle multi-sources
Scénario 3 : migration de données à grande échelle avec architecture médaillon
Scénario 4 : monitoring temps réel et alerting
Scénario 5 : entrepôt de données pour la BI
Scénario 6 : plateforme de data science et d'exploration
Scénario 7 : préparation de données sans code
Source : Microsoft Learn - Guide d'intégration
7. Fiche récapitulative
Ce tableau de synthèse résume les principaux outils et leurs cas d'usage pour faciliter vos décisions quotidiennes :
Elément
Rôles
Besoins
Mise en miroir
Réplication simple et gratuite de bases de données vers OneLake, sans transformation
Vous avez besoin de transformations, de planification personnalisée ou de destinations multiples
Travail de copie
Copie incrémentielle/CDC, multi-tables, sans pipeline, avec planification
Vous avez besoin d'orchestration complexe ou de requêtes personnalisées à la source
Activité de copie (pipeline)
Ingestion orchestrée, requêtes personnalisées, architecture médaillon, gros volumes
Le scénario est simple (réplication directe) : la mise en miroir ou le travail de copie suffisent
Flux d'événements
Streaming temps réel, ingestion IoT, alerting, tableaux de bord temps réel
Le traitement par lots suffit a votre besoin
Pipeline
Orchestration low-code de flux complexes avec plusieurs etapes
Vous avez besoin d'orchestration code-first Python (utilisez Apache Airflow)
Apache Airflow
Orchestration Python code-first, DAGs complexes, intégration ML
Votre équipe n'a pas de compétences Python
Notebooks Spark
Transformations complexes code-first, ML, exploration de données
Vos utilisateurs préfèrent le sans code (utilisez Dataflow Gen2)
Dataflow Gen2
Transformations sans code (Power Query), 170+ connecteurs, profilage
Vous avez besoin de traitements distribués à grande échelle (utilisez les notebooks)
Lakehouse
Big data, ML, données mixtes (structurées + non structurées), architecture médaillon
Vous n'avez que des données structurées et une équipe SQL
Entrepôt de données
BI SQL, transactions multi-tables, schema en etoile, reporting d'entreprise
Vous traitez des données non structurées ou faites du ML
Eventhouse
Analytique temps réel, series temporelles, données haute granularité
Vos données sont statiques ou changent rarement
Base de données SQL
Applications OLTP, transactions ACID, accès concurrent élevé
Vous construisez un entrepôt analytique (utilisez le warehouse)
There are no rows in this table
Sources
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.