Ingestion de données dans Microsoft Fabric : toutes les méthodes pour ingérer des données
Avant le moindre rapport, il faut faire entrer les données dans la plateforme. Base SQL, fichiers Excel, API, capteurs : chaque source a ses contraintes, et Microsoft Fabric propose une demi-douzaine d'outils pour les absorber. De quoi s'y perdre.
Dans cet article, on passe en revue les méthodes d'ingestion de données disponibles, on explique quand utiliser chacune et on vous donne une grille de décision simple.
Pourquoi l'ingestion des données est l'étape clé
Tout ce qui suit en dépend : la préparation des données, la science des données, les tableaux de bord. Une source mal chargée, et ce sont des chiffres faux qui remontent jusqu'à la direction.
Le processus d'ingestion de données poursuit trois objectifs :
Récupérer les données à partir de systèmes très différents : ERP, CRM, fichiers, API, objets connectés.
Garantir la qualité des données dès l'entrée, pour ne pas propager d'erreurs.
Centraliser le stockage de données dans un lac unique, pour éviter les copies multiples.
Dans Fabric, toutes les méthodes aboutissent au même endroit : elles écrivent les données dans OneLake, au format Delta, quel que soit l'outil utilisé.
Les 9 principales façons d’ingérer des données dans Microsoft Fabric
Microsoft Fabric regroupe plusieurs outils complémentaires, du plus guidé au plus technique :
Chargement manuel : téléverser un fichier ponctuel dans un lakehouse, puis le convertir en table.
Raccourcis (shortcuts) : lire des données stockées ailleurs, sans les copier.
Mise en miroir (mirroring) : répliquer une base de données en continu.
Copy job : copier simplement, avec chargement incrémental intégré.
Activité de copie : copier au sein d’un pipeline Data Factory, qui orchestre un enchaînement complet de copies et de traitements.
Dataflows Gen2 : se connecter et transformer en low-code, avec Power Query.
Eventstream : capter des événements en streaming.
COPY INTO : charger des fichiers dans un Warehouse en T-SQL.
Notebooks : tout faire en code (PySpark, Spark SQL ou Python), pour les sources complexes.
Microsoft détaille ces options dans sa page Get data into Fabric. Voyons chacune en pratique.
Le chargement manuel : pour un fichier ponctuel
Pour un fichier à charger une seule fois, inutile de construire un flux. Téléversez-le dans la partie Files du lakehouse, depuis le portail Fabric ou l’explorateur de fichiers OneLake. Un clic droit sur un fichier CSV ou Parquet, puis « Charger dans une table », le convertit en table Delta.
Pratique pour un référentiel ou un test. À proscrire en revanche pour une donnée qui doit être rechargée régulièrement : personne ne pensera à refaire la manipulation.
Azure Data Lake, S3, SharePoint : les raccourcis vers les données externes
Un raccourci (shortcut) pointe vers des données hébergées ailleurs (ADLS Gen2, Amazon S3, Google Cloud Storage, SharePoint ou un autre espace Fabric) et les rend visibles comme si elles étaient dans votre lakehouse. Rien n’est copié : pas de duplication, pas de synchronisation à gérer.
C’est la méthode à privilégier quand des données stockées dans un autre cloud ne doivent pas être déplacées, pour des raisons de coût ou de conformité. Deux points d’attention :
Les tables Delta apparaissent directement comme des tables. Les autres fichiers (CSV, JSON…) restent dans Files et doivent être convertis pour être exploités dans un modèle sémantique.
La lecture depuis un autre cloud peut générer des frais de sortie chez ce fournisseur.
La mise en miroir : des données en continu
La mise en miroir (mirroring) réplique en continu une base opérationnelle vers OneLake : Azure SQL Database, SQL Server (de 2016 à 2025), Snowflake et d’autres sources, certaines encore en préversion. Aucun flux à développer : les données mises en miroir sont mises à jour en quasi temps réel, au fil des modifications de la source.
C’est la solution idéale pour analyser une base de production sans la solliciter avec des requêtes d’analyse. Prévoyez simplement les prérequis : une passerelle pour les bases sur site, et le Change Data Capture (CDC) activé pour SQL Server 2016 à 2022.
Copy job : copier des données sans pipeline
Le Copy job est l’option la plus simple pour copier des données vers OneLake. Vous choisissez la source, les tables, la destination et la fréquence : c’est tout.
Il gère nativement le chargement incrémental : seules les lignes nouvelles ou modifiées depuis la dernière exécution sont copiées. Idéal pour répliquer chaque nuit quelques tables d’une base qui n’est pas compatible avec la mise en miroir.
L’activité de copie dans un pipeline Data Factory
Un pipeline est l’outil d’orchestration de Fabric. Son activité « Copier les données » déplace des données depuis plus de cent connecteurs : bases SQL, fichiers SharePoint, Salesforce, API REST… Autour de cette copie, le pipeline enchaîne d’autres étapes : conditions, boucles, notebooks, actualisation d’un Dataflow, alertes en cas d’échec.
C’est la bonne méthode quand le chargement fait partie d’un enchaînement plus large : copier, puis transformer, puis rafraîchir les rapports, le tout planifié chaque nuit. Pour le détail, lisez notre article Qu’est-ce qu’un pipeline de données ? et notre page Data Factory.
Les flux de données (Dataflow Gen2)
Le Dataflow Gen2 reprend l’éditeur Power Query que vous connaissez déjà dans Power BI Desktop et Excel. Il se connecte à une source, transforme les données en quelques clics, puis écrit le résultat dans un lakehouse ou un entrepôt.
C’est la méthode préférée des analystes : aucune ligne de code, et chaque transformation visible étape par étape. Deux points d’attention :
Le volume : pour les gros volumes, activez la copie rapide (Fast Copy), ou passez par un Copy job ou un notebook.
Le coût : à volume égal, un Dataflow Gen2 consomme nettement plus de capacité qu’une activité de copie ou un notebook.
Eventstream : les données en temps réel
Pour les flux continus (capteurs IoT, clics sur un site, transactions bancaires), Eventstream capte des données à haut débit, les filtre ou les enrichit à la volée, puis les envoie vers un Eventhouse, un lakehouse ou une alerte Activator. La latence se compte en secondes.
COPY INTO : charger en T-SQL dans le Warehouse
Si votre équipe travaille en SQL et que la cible est un Warehouse, l’instruction COPY INTO charge des fichiers CSV ou Parquet depuis un stockage Azure directement dans une table de l’entrepôt. Une seule requête suffit, et elle s’intègre facilement dans un pipeline ou une procédure stockée.
Les notebooks : ingérer en code
Un notebook offre une liberté totale : appeler une API paginée, lire des fichiers JSON imbriqués, fusionner plusieurs sources, appliquer des règles métier complexes. En PySpark ou Spark SQL, le travail est réparti sur plusieurs nœuds, ce qui le rend très efficace sur de gros volumes. Pour les traitements plus légers, un notebook Python sans Spark démarre plus vite et consomme moins.
C’est l’outil privilégié des data engineers. Pour bien le combiner avec l’orchestration, lisez Blocs-notes Apache Spark VS pipelines et découvrez notre page Data Engineering.
Comparatif : quelle méthode d’ingestion choisir ?
Méthode | Copie les données ? | Fraîcheur | Code ? | Idéal pour |
Chargement manuel | Oui | Ponctuelle | Non | Un fichier à charger une fois |
Raccourci | Non | Lecture à la demande | Non | Données déjà dans un autre cloud ou espace |
Mise en miroir | Oui, en continu | Quasi temps réel | Non | Bases opérationnelles compatibles |
Copy job | Oui | Planifiée, incrémentale | Non | Une copie simple, sans orchestration |
Activité de copie (pipeline) | Oui | Planifiée ou sur événement | Non | Une copie dans un enchaînement d’étapes |
Dataflow Gen2 | Oui | Planifiée | Low-code | Analystes, transformations Power Query |
Eventstream | Oui, vers la destination | Temps réel | Non | Événements, objets connectés |
COPY INTO | Oui | Planifiée | T-SQL | Équipes SQL alimentant un Warehouse |
Notebook | Oui | Planifiée ou streaming | Python, PySpark | Sources complexes, gros volumes |
Notre règle en formation : commencez par la méthode la plus simple qui répond au besoin. Cas particulier (temps réel, fichier ponctuel, données déjà dans le cloud, base compatible miroir) : utilisez son outil dédié. Sinon, copiez : Copy job pour une copie simple, activité de copie dès qu’il faut orchestrer plusieurs étapes, notebook si aucun connecteur ne convient. Transformez ensuite.
Stockage : lakehouse, Warehouse ou Eventhouse ?
Chaque méthode écrit vers une destination. Le lakehouse accueille aussi bien fichiers que tables : c'est la cible par défaut, notamment pour les données brutes de la couche bronze de l'architecture médaillon. Le Warehouse convient aux tables structurées pilotées en T-SQL, l'Eventhouse aux événements horodatés.
Dans tous les cas, le stockage des données repose sur OneLake : un même jeu de données peut ensuite être lu par Spark, par SQL ou par les rapports, sans copie. Pour choisir, lisez notre comparatif Lakehouse vs Warehouse dans Microsoft Fabric et suivez notre tutoriel pour créer un Lakehouse.
Formats de données et connectivité
Fabric lit la plupart des formats courants : CSV, JSON, Parquet, Avro, Excel, XML. Tous ne sont pas acceptés par toutes les méthodes : « Charger dans une table » ne prend que le CSV et le Parquet, alors que l’activité de copie et le Dataflow Gen2 lisent aussi l’Excel et le XML.
À l’arrivée, deux cas :
Les fichiers déposés dans la partie Files gardent leur format d’origine. C’est la zone d’atterrissage des données brutes.
Les données chargées en tables sont stockées au format Delta, un format ouvert qui apporte transactions, historique des versions et lecture par tous les moteurs de Fabric.
Vérifiez le type de chaque colonne dès l’arrivée : une date lue comme du texte, et ce sont des filtres qui ne fonctionnent plus dans les rapports.
Côté réseau, les sources hébergées sur site passent par une passerelle de données locale. Les sources cloud publiques sont jointes directement ; celles qui sont protégées dans un réseau privé passent par une passerelle de réseau virtuel ou des points de terminaison privés managés.
Améliorer les performances de l’ingestion
Filtrez à la source : ne rapatriez que les colonnes et les lignes utiles. Avec une base SQL, passez une requête plutôt que de copier la table entière.
Parallélisez les grosses copies : pour une source SQL volumineuse, l’activité de copie peut lire la table par partitions, en plusieurs flux simultanés.
Activez la copie rapide (Fast Copy) dans les Dataflows Gen2 pour les gros volumes : le chargement passe par le moteur de copie au lieu de Power Query.
Compactez les petits fichiers : des milliers de fichiers de quelques kilo-octets ralentissent les lectures. La maintenance des tables du lakehouse (OPTIMIZE) les regroupe en fichiers plus gros.
Dimensionnez la passerelle pour les sources sur site : c’est souvent elle le goulot d’étranglement. Installez-la sur une machine dédiée, proche de la source.
Et bien sûr : chargez en incrémental et planifiez hors des heures de pointe (voir les erreurs à éviter).
Gouvernance des données et espace de travail
Séparez les sources par domaine et par couche : un espace dédié à l'ingestion, réservé aux ingénieurs, et des espaces de consultation pour les analystes. Les étiquettes de sensibilité, le lignage et le catalogue OneLake facilitent la gestion des données à l'échelle de l'entreprise.
Documentez enfin les sources de données ingérées (propriétaire, fréquence, contenu) : c'est la base de toute gouvernance.
Du pipeline de données au modèle sémantique Power BI
L'ingestion n'est qu'un début. Une fois les tables en place, le modèle sémantique les lit en mode Direct Lake, sans import ni copie, et les rapports se mettent à jour dès que de nouvelles données arrivent. C'est ce qui rend la chaîne complète si efficace pour l'analyse des données.
Intégrer des données dans Fabric : un exemple
Un distributeur veut suivre ses ventes et ses stocks. Chaque source a sa méthode :
Mise en miroir : sa base ERP sous SQL Server arrive en continu, sans flux à développer.
Raccourci : les tarifs fournisseurs déposés sur Amazon S3 sont lus sur place, sans copie.
Dataflow Gen2 : le fichier Excel de budgets, déposé sur SharePoint par la finance, est nettoyé en Power Query.
Pipeline : chaque nuit, une activité de copie récupère le référentiel produits d’un ancien serveur SQL Server 2014, trop ancien pour la mise en miroir. Le pipeline actualise ensuite le Dataflow Gen2, puis lance deux notebooks qui construisent les tables silver et gold.
Un modèle sémantique en Direct Lake lit enfin ces tables gold pour alimenter le rapport ventes et stocks.
Résultat : quatre méthodes, chacune adaptée à sa source, toutes les données au même endroit dans OneLake, et une seule plateforme à administrer.
Ingestion de données dans Fabric : les erreurs à éviter
Dupliquer des données déjà accessibles : si les données sont déjà dans OneLake ou dans un stockage cloud, un raccourci suffit. Si la base est compatible, la mise en miroir évite de construire un flux de copie.
Recopier tout à chaque exécution : sur des tables volumineuses, chargez en incrémental (le Copy job le gère nativement). Sinon, chaque exécution consomme de la capacité pour rien.
Charger et transformer d’un seul bloc : un traitement géant devient impossible à maintenir et à relancer. Séparez l’ingestion (données brutes en bronze) des transformations (silver et gold).
Ignorer la consommation de capacité : toutes les méthodes ne coûtent pas la même chose. Les plus gourmandes sont :
les Dataflows Gen2, nettement plus coûteux qu’une activité de copie ou un notebook pour un même volume ;
les sessions Spark laissées ouvertes, qui consomment jusqu’à leur expiration, même sans traitement en cours ;
les flux temps réel (Eventstream), qui consomment en continu tant qu’ils tournent.
Planifiez les ingestions lourdes hors des heures de pointe, pour ne pas ralentir les rapports des autres utilisateurs, et identifiez les gros consommateurs dans l’application Capacity Metrics.
Oublier la surveillance : suivez les exécutions dans le hub de surveillance et configurez une alerte en cas d’échec.
Négliger la sécurité : les données de production contiennent souvent des informations personnelles. Réservez l’espace d’ingestion aux ingénieurs, et ne laissez jamais de mot de passe en clair dans un notebook : utilisez des connexions ou Azure Key Vault.
Faire tourner les flux sous un compte personnel : si la personne qui a créé les connexions change de poste ou quitte l’entreprise, toutes les ingestions planifiées échouent. Authentifiez les connexions avec un principal de service (service principal) ou une identité d’espace de travail, quand le connecteur le permet.
Se former à Microsoft Fabric
Choisir la bonne méthode s'apprend vite quand on pratique sur ses propres sources. Nos formateurs, certifiés Microsoft Certified Trainer, vous font mettre en œuvre chacune d'elles sur vos données : Data Factory, Synapse Data Engineering, Data Warehouse et rapports Power BI.
Commentaires