Charger des fichiers à la main dans un Lakehouse fonctionne pour un essai, jamais pour la production. Dès que les données doivent arriver chaque nuit, depuis plusieurs sources, sans intervention humaine, il faut un mécanisme répétable, surveillé, capable de reprendre après une panne. Dans Microsoft Fabric, ce mécanisme s’appelle Data Factory, et son outil central est le pipeline de données. Ce tutoriel construit un pipeline d’ingestion complet, d’une source vers une table du Lakehouse, puis le planifie et le surveille.
Ce tutoriel s’inscrit dans une série sur Power BI et Microsoft Fabric ; le guide de référence Power BI et Microsoft Fabric en donne la vue d’ensemble. Il suppose que vous avez déjà créé un Lakehouse, car c’est lui qui servira de destination.
Prérequis
- Un accès à Microsoft Fabric (capacité F ou essai) et un espace de travail rattaché.
- Un Lakehouse déjà créé pour recevoir les données.
- Une source de données accessible (base SQL, stockage cloud, ou fichier).
- Niveau : intermédiaire. Aucune programmation requise pour le cas de base.
- Temps estimé : 60 à 80 minutes.
Étape 1 — Pipeline ou Dataflow Gen2 ?
Data Factory dans Fabric propose deux outils d’ingestion qu’il ne faut pas confondre. Le pipeline de données orchestre des activités : il déplace de gros volumes, enchaîne des étapes, gère des conditions et des boucles, appelle des notebooks. Le Dataflow Gen2, lui, repose sur le moteur Power Query : il excelle dans la transformation visuelle de données, étape par étape, pour qui connaît déjà Power Query.
La règle pratique : utilisez un pipeline quand l’objectif premier est de déplacer des données et d’orchestrer un flux, et un Dataflow Gen2 quand l’objectif est de transformer finement, avec l’interface Power Query. Les deux se combinent souvent : un pipeline copie les données brutes, puis déclenche un Dataflow ou un notebook pour les transformer. Pour ce tutoriel, on se concentre sur le pipeline, brique d’orchestration la plus structurante.
Étape 2 — Créer un pipeline de données
Le pipeline se crée comme tout objet Fabric, dans l’espace de travail. Cliquez sur Nouvel élément et choisissez Pipeline de données. Donnez-lui un nom décrivant son rôle, par exemple Ingestion_Ventes_Quotidienne, afin que sa fonction soit lisible d’un coup d’œil dans la liste des objets.
Le concepteur de pipeline s’ouvre sur une toile vide. C’est ici que vous allez assembler des activités — des briques d’action reliées par des flèches qui définissent l’ordre d’exécution. Fabric propose un assistant Copier des données qui guide la création de la première activité, ainsi qu’une galerie d’activités plus avancées. Pour un premier pipeline d’ingestion, l’activité de copie est le point de départ naturel.
Étape 3 — Ajouter l’activité Copier des données
L’activité de copie est le cœur de l’ingestion : elle lit une source et écrit une destination, en gérant au passage le format et la performance. Lancez l’assistant Copier des données depuis la toile. Il se déroule en quelques écrans : choix de la source, choix de la destination, mappage, puis récapitulatif.
L’intérêt de l’assistant est qu’il crée pour vous les connexions réutilisables vers vos systèmes. Une connexion stocke, une fois pour toutes, l’adresse et les identifiants d’une source ; les pipelines suivants la réutiliseront sans tout reconfigurer. Prenez le temps de nommer clairement chaque connexion créée. À la fin de l’assistant, une activité de copie apparaît sur la toile, prête à être affinée. On détaille maintenant ses deux extrémités.
Étape 4 — Configurer la source
La source décrit d’où viennent les données. Dans l’assistant, sélectionnez le type adapté : une base SQL, un stockage cloud, un service en ligne, ou un fichier. Fabric propose un large catalogue de connecteurs, ce qui permet d’unifier l’ingestion de sources hétérogènes dans un seul outil.
Pour une base SQL, vous renseignez le serveur, la base, les identifiants, puis vous choisissez soit une table entière, soit une requête personnalisée si vous ne voulez qu’un sous-ensemble. Privilégier une requête ciblée à la source réduit le volume transféré et accélère l’ingestion : inutile de copier des colonnes ou des lignes qui ne serviront pas en aval. Validez la connexion : un aperçu des données confirme que la source répond correctement avant d’aller plus loin.
Étape 5 — Configurer la destination dans le Lakehouse
La destination est l’endroit où atterrissent les données : ici, une table de notre Lakehouse. Dans l’assistant, choisissez votre Lakehouse comme destination, puis la zone Tables. Indiquez le nom de la table cible — par exemple ventes_brut pour respecter une logique de couche bronze.
Un choix important apparaît : créer une nouvelle table ou écrire dans une table existante, et dans ce dernier cas, écraser ou ajouter. Pour une ingestion quotidienne d’un instantané complet, l’écrasement convient ; pour accumuler un historique, on ajoute. Comme la destination est une table Delta du Lakehouse, elle devient immédiatement interrogeable en SQL et exploitable par Power BI une fois le pipeline exécuté. Cette intégration native est l’avantage de rester dans l’écosystème Fabric : aucun pont à construire entre l’ingestion et l’analyse.
Étape 6 — Vérifier le mappage des colonnes
Entre la source et la destination, Fabric établit un mappage colonne à colonne. Le plus souvent, il le déduit correctement, mais une vérification évite des surprises, en particulier sur les types. L’écran de mappage de l’assistant liste chaque colonne source en face de sa colonne destination, avec le type retenu.
Contrôlez surtout les colonnes sensibles : les dates, qui peuvent être mal interprétées, et les nombres décimaux, où un type trop étroit tronquerait des valeurs. Si une colonne ne doit pas être copiée, retirez-la du mappage pour alléger la table cible. Un mappage propre dès l’ingestion épargne des corrections fastidieuses plus tard, lors de la modélisation. Validez ensuite l’assistant : l’activité de copie est désormais entièrement configurée.
Étape 7 — Ajouter de la logique d’orchestration
Un pipeline ne se limite pas à une copie unique ; sa force est d’orchestrer plusieurs étapes conditionnelles. Une fois la copie en place, vous pouvez enrichir le flux avec des activités supplémentaires depuis la galerie. L’activité ForEach répète une action sur une liste — par exemple copier successivement plusieurs fichiers ou plusieurs tables. L’activité Notebook déclenche un traitement Spark pour transformer les données fraîchement copiées.
On relie les activités par des flèches qui portent une condition : « en cas de succès », « en cas d’échec », ou « à la fin quoi qu’il arrive ». Cela permet, par exemple, de lancer la transformation seulement si la copie a réussi, et d’envoyer une alerte en cas d’échec. Les paramètres du pipeline ajoutent de la souplesse : on peut passer une date ou un nom de fichier au lancement, pour réutiliser le même pipeline dans plusieurs contextes. Cette logique transforme une simple copie en un véritable flux de production résilient. Pour les transformations Spark elles-mêmes, voir le tutoriel transformer des données avec les Notebooks Spark.
Étape 8 — Planifier l’exécution
Un pipeline n’apporte sa pleine valeur qu’automatisé. Une fois le flux testé manuellement avec le bouton Exécuter, on le planifie. Dans l’onglet de planification du pipeline, activez une nouvelle planification, choisissez la fréquence (par exemple chaque jour à 4 h du matin, avant l’arrivée des équipes) et le fuseau horaire.
À partir de là, Fabric déclenche le pipeline aux heures prévues, sans intervention. Avant de quitter, lancez une exécution manuelle de bout en bout pour confirmer que tout s’enchaîne : la copie remplit la table, l’éventuelle transformation s’exécute, et aucune activité ne tombe en erreur. Une exécution manuelle réussie est le feu vert avant de confier le flux à la planification automatique. Pensez à dimensionner la fréquence selon la fraîcheur réellement nécessaire : rafraîchir toutes les heures une donnée qui ne change qu’une fois par jour gaspille de la capacité.
Étape 9 — Surveiller les exécutions
Un pipeline planifié doit être surveillé, car une source peut devenir indisponible ou un identifiant expirer. Fabric centralise le suivi dans un hub de surveillance qui liste chaque exécution, son statut, sa durée et le volume traité. C’est le tableau de bord de santé de vos flux d’ingestion.
Prenez l’habitude de le consulter, surtout après une modification de source ou de structure. En cas d’échec, le détail de l’exécution pointe l’activité fautive et le message d’erreur, ce qui accélère le diagnostic. Configurez aussi des alertes pour être prévenu sans surveiller manuellement. Un pipeline observé est un pipeline fiable : les anomalies se détectent avant que les utilisateurs ne consultent des données périmées ou incomplètes. C’est la dernière pièce qui transforme une ingestion artisanale en un service de données digne de confiance.
Industrialiser : du développement à la production
Un pipeline bricolé directement en production finit toujours par casser au plus mauvais moment. Dès que les flux deviennent critiques, on sépare les environnements : un espace de développement où l’on construit et teste, un espace de production où tournent les pipelines validés. Fabric fournit deux mécanismes complémentaires pour gérer ce cycle de vie proprement.
Le premier est l’intégration Git : un espace de travail peut être relié à un dépôt, ce qui versionne les pipelines, les notebooks et les autres objets. Chaque modification est tracée, on peut revenir en arrière, et plusieurs personnes collaborent sans s’écraser mutuellement. Le second est constitué des pipelines de déploiement, qui propulsent le contenu d’un espace de développement vers un espace de test puis de production, en appliquant au passage des règles — par exemple pointer automatiquement vers la base de production plutôt que celle de test. Ce duo apporte aux flux de données la même rigueur que celle attendue du développement logiciel : rien n’arrive en production sans être passé par une étape de validation. Pour une organisation qui dépend de ses tableaux de bord, cet investissement dans l’industrialisation évite les incidents coûteux et rend les évolutions sereines, parce que réversibles et tracées.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Échec de connexion à la source | Identifiants expirés ou réseau bloqué | Mettre à jour la connexion, vérifier l’accès réseau |
| Dates ou décimaux corrompus | Mappage de types incorrect | Vérifier et corriger le mappage de colonnes |
| Table cible qui se duplique | Mode « ajouter » au lieu d’« écraser » | Choisir le mode d’écriture adapté au besoin |
| Transformation lancée malgré une copie échouée | Lien d’activité « à la fin » au lieu de « succès » | Relier la transformation à la sortie « en cas de succès » |
| Capacité saturée | Planification trop fréquente | Aligner la fréquence sur la fraîcheur réellement utile |
| Échec silencieux non détecté | Absence d’alertes | Configurer des alertes et consulter le hub de surveillance |
Tutoriels liés
- Créer un Lakehouse dans Microsoft Fabric — la destination de ce pipeline.
- Transformer des données avec les Notebooks Spark — l’étape de transformation après l’ingestion.
- Connecter Power BI au Lakehouse en mode DirectLake — exploiter les tables alimentées.
Références
- Documentation « Data Factory dans Microsoft Fabric » et « Pipelines de données » (Microsoft Learn).
- Guide « Activité Copier des données » et catalogue des connecteurs.
- Documentation « Dataflow Gen2 dans Fabric » pour la comparaison.
Questions fréquentes
Quand préférer un Dataflow Gen2 à un pipeline ?
Quand le besoin principal est de transformer finement les données avec l’interface Power Query. Le pipeline est préférable pour déplacer de gros volumes et orchestrer un enchaînement d’étapes.
Un pipeline peut-il ingérer plusieurs sources d’un coup ?
Oui. En combinant plusieurs activités de copie ou une boucle ForEach, un seul pipeline peut consolider des données venues de bases, de fichiers et de services en ligne différents.
Faut-il une passerelle comme pour Power BI ?
Pour des sources internes derrière un pare-feu, une passerelle de données est nécessaire, comme pour les actualisations Power BI. Les sources cloud accessibles publiquement se connectent directement.
Le pipeline transforme-t-il les données ou seulement les copie-t-il ?
L’activité de copie déplace les données avec un mappage simple. Pour des transformations riches, le pipeline déclenche un notebook Spark ou un Dataflow Gen2 dédié à cette tâche.
Comment maîtriser le coût d’un pipeline en capacité Fabric ?
Chaque exécution consomme des unités de capacité proportionnelles au volume déplacé et à la durée. On réduit ce coût en filtrant les données à la source, en n’ingérant que les colonnes utiles, et en calant la fréquence sur la fraîcheur réellement nécessaire plutôt que sur un réflexe « le plus souvent possible ». Le hub de surveillance aide à repérer les exécutions anormalement longues qui pèsent sur la capacité.