Dataflows Gen1 et Gen2 dans Microsoft Fabric : choisir la bonne architecture de staging et de calcul

By Mirko Peters · 2026-10-28

Comparez les Dataflows Gen1 et Gen2 dans Microsoft Fabric. Découvrez comment le stockage, le staging de calcul et la capacité influencent votre stratégie ETL dans le cloud.

Automatically translated with AI from the original post. Read the English original

Lors de la migration de charges de travail ETL vers Microsoft Fabric, le choix de la bonne architecture de staging et de calcul entre les Dataflows Gen1 et Gen2 influe directement sur les performances de vos pipelines, sur les coûts de ressources et sur la fiabilité des données. Comprendre les différences de fond en matière d’allocation de calcul et de gestion du stockage permet d’éviter des goulots d’étranglement architecturaux coûteux avant que votre équipe ne multiplie ses rapports.

Points clés

• Les Dataflows Gen2 introduisent une intégration native avec OneLake, ce qui change fondamentalement la manière dont les données sont préparées et stockées par rapport à Gen1.
• Choisir une option de calcul inadaptée lors de la création peut entraîner un bridage inattendu de la capacité et une dégradation des performances dans votre espace de travail Fabric.
• Gen1 reposait largement sur des mécanismes de stockage externes, alors que Gen2 écrit directement dans les tables du Lakehouse Fabric comme destination par défaut.
• Une configuration correcte du staging évite les transformations de données redondantes et optimise l’actualisation de vos modèles sémantiques Power BI.
• Aligner votre stratégie ETL sur les unités de capacité Fabric permet à votre organisation d’éviter des coûts de calcul incontrôlés.

Comprendre le changement d’architecture dans Fabric

La transition des dataflows Power BI historiques vers les dataflows Microsoft Fabric ne se limite pas à un simple changement de nom : elle représente une refonte complète de la manière dont les données cloud sont ingérées, transformées et conservées. Dans l’univers Gen1, les dataflows étaient principalement conçus pour alimenter les modèles sémantiques Power BI. Ils évoluaient dans un écosystème plutôt isolé, où les transformations étaient réalisées dans Power Query Online et où les résultats étaient stockés dans un espace de stockage interne géré entièrement par le service Power BI.

Avec l’arrivée de Microsoft Fabric, les Dataflows Gen2 sont conçus dès l’origine pour utiliser OneLake comme référentiel central des données. Concrètement, chaque transformation appliquée via Power Query Online n’est plus enfermée dans un conteneur de modèle propriétaire. Gen2 comble ainsi le fossé entre la préparation de données en libre-service traditionnelle et l’ingénierie de données d’entreprise, en écrivant directement dans des tables Delta Parquet, au format ouvert, au sein d’un Lakehouse Fabric. Ce changement fondamental modifie la manière dont les architectes cloud abordent le staging des données, l’utilisation du calcul et la fiabilité des rapports en aval.

Le changement de paradigme du stockage

Dans les environnements historiques, lorsqu'un analyste métier devait nettoyer un export Excel, supprimer les lignes vides et mettre les dates en forme, ces données restaient confinées à la zone de stockage du flux de données. Si un autre service souhaitait réutiliser ce même jeu de données nettoyé, il devait souvent extraire les données depuis le rapport ou recréer la requête. Dataflows Gen2 résout ce problème en faisant du Lakehouse la destination de premier plan. Une fois votre flux de données exécuté, les données nettoyées sont immédiatement disponibles sous forme de tables Delta, prêtes pour les notebooks Spark, les points de terminaison d’analyse SQL et les rapports DirectLake, sans déplacement de données supplémentaire.

La décision sur le calcul et la préparation que la plupart des équipes négligent

L'une des décisions d'architecture les plus critiques auxquelles sont confrontés les ingénieurs lors de la création de Dataflows Gen2 concerne la gestion des phases de calcul et de préparation. Contrairement à Gen1, où la gestion du calcul était largement abstraite et parfois opaque, Gen2 s'exécute sur les unités de capacité (CU) Fabric sous-jacentes. Si votre organisation ne surveille pas attentivement la manière et le moment où les données sont préparées pendant la phase d'évaluation des requêtes, vous risquez de consommer votre allocation de capacité plus vite que prévu.

Lorsque vous appliquez des transformations complexes, Power Query évalue si les étapes peuvent être reportées sur la source de données ou si elles doivent être exécutées localement dans le moteur du flux de données. Dans Gen2, la zone de préparation joue le rôle d'une zone d'atterrissage intermédiaire. Mal configurée, elle peut entraîner le chargement répété de grands volumes de données en mémoire, leur traitement puis leur écriture, ce qui génère une charge de calcul inutile. Les architectes doivent évaluer leurs systèmes sources, la latence réseau et la complexité des transformations pour décider s'il vaut mieux déporter le traitement vers la base de données source ou laisser Fabric assumer la charge.

Optimiser les unités de capacité pour les charges ETL

La capacité Fabric est un pool partagé au sein de votre organisation. Lorsqu'un Dataflow Gen2 mal optimisé s'exécute lors d'actualisations planifiées pendant les heures de pointe, il peut consommer la capacité au point de limiter l'affichage des rapports Power BI pour les dirigeants. Pour éviter cela, les équipes devraient isoler les tâches ETL lourdes dans des espaces de travail dédiés, adossés à des réservations de capacité appropriées, ou les planifier en dehors des heures de pointe. Comprendre comment les tâches de calcul en arrière-plan interagissent avec les charges interactives est essentiel pour maintenir un environnement Fabric stable.

Bâtir la confiance grâce à une architecture cohérente

L'objectif ultime de la modernisation de vos pipelines de données est d'éliminer les corrections manuelles dans Excel qui pèsent sur le reporting métier. Lorsque les rapports échouent, ce n'est que rarement par manque de données ; c'est presque toujours par manque de confiance. Lorsque les utilisateurs constatent des chiffres contradictoires parce qu'un rapport s'appuie sur un fichier CSV brut et un autre sur un ancien flux de données, l'adoption s'effondre.

En standardisant sur Dataflows Gen2 et en exploitant l'architecture Lakehouse, les organisations établissent une source unique de vérité. Les dates nettoyées, les noms de colonnes standardisés et la logique métier validée sont définis une seule fois dans le flux de données, puis propagés automatiquement en aval. Cela réduit les erreurs humaines, supprime la dépendance aux ordinateurs de bureau individuels et garantit que, lorsque la direction ouvre un tableau de bord, les chiffres sous-jacents sont fiables et prêts pour un audit.

Conclusion

La migration et la création avec Dataflows Gen2 exigent de repenser la manière dont vous abordez le stockage cloud, les budgets de calcul et la gouvernance des données. En commençant par un seul processus récurrent et désordonné basé sur des tableurs, puis en le faisant correspondre correctement à un Lakehouse Fabric, votre équipe pourra bâtir des pipelines évolutifs et durables. Pour explorer les concepts fondamentaux de cette évolution et entendre des experts sur les stratégies cloud modernes de Microsoft, n'hésitez pas à écouter l'épisode complet du podcast M365 FM.

Questions fréquentes

Quelle est la principale différence entre Dataflows Gen1 et Gen2 en matière de stockage ?

Dataflows Gen1 stockent les données transformées dans les limites du stockage interne de Power BI, alors que Dataflows Gen2 écrivent nativement dans des tables Delta Parquet au format ouvert, au sein d'un Lakehouse Microsoft Fabric via OneLake.

Quel est l'impact de Dataflows Gen2 sur les unités de capacité Fabric ?

Les Dataflows Gen2 consomment la capacité Fabric sous-jacente pendant leurs phases de calcul et de préparation. Des transformations mal optimisées ou des actualisations lourdes pendant les heures de pointe peuvent épuiser votre allocation de capacité et limiter les autres charges de travail.

Dataflows Gen2 peuvent-ils remplacer les pipelines traditionnels Azure Data Factory ?

Pour la préparation de données en libre-service, l’ETL léger et la transformation de données low-code, les Dataflows Gen2 constituent une excellente alternative. En revanche, pour l’orchestration d’entreprise complexe, la logique conditionnelle et l’ingénierie des données avancée, Azure Data Factory ou Fabric Pipelines restent les outils à privilégier.

Pourquoi la phase de préparation (staging) est-elle importante dans les Dataflows Gen2 ?

La phase de préparation (staging) joue le rôle de zone d’atterrissage intermédiaire pour les transformations de données. Une configuration correcte du staging évite les traitements de données redondants, optimise le query folding et garantit des écritures efficaces vers votre Lakehouse de destination.

Comment les Dataflows Gen2 améliorent-ils la confiance dans les données des rapports ?

En automatisant le nettoyage des exports manuels désordonnés et en centralisant les transformations dans des tables Lakehouse réutilisables, Gen2 supprime les solutions de contournement manuelles sous Excel et garantit des données cohérentes et fiables dans l’ensemble des rapports en aval.