Microsoft Fabric en 2026, les nouveautés qui changent vraiment CI/CD, Spark et Dataflow Gen2

Microsoft Fabric est arrivé avec une promesse simple à raconter et beaucoup plus compliquée à tenir. Réunir l'ingestion, le lakehouse, le warehouse, la BI, le temps réel et la data science dans une plateforme SaaS commune semblait séduisant. En pratique, les premières versions donnaient parfois l'impression d'un grand catalogue où chaque workload avançait à son propre rythme.

En cette rentrée 2026, le sujet n'est plus le nombre de tuiles dans le portail. Ce qui m'intéresse est la cohérence opérationnelle. Peut-on travailler à plusieurs, versionner, tester, déployer, paramétrer et surveiller sans réinventer un procédé différent pour chaque item ? Sur ce point, Fabric a fait un vrai bond.

Le changement le plus important n'est pas une nouvelle tuile

Le progrès majeur est la construction d'un socle transversal. Les API REST Fabric servent de fondation. Git relie les workspaces à Azure DevOps ou GitHub. Les deployment pipelines assurent la promotion entre Dev, Test et Prod. Les bibliothèques de variables portent la configuration par environnement. Le CLI Fabric, Terraform et la librairie fabric-cicd complètent l'automatisation.

Pris séparément, aucun de ces éléments n'est révolutionnaire. Ensemble, ils changent la nature du produit. Fabric commence à se comporter comme une plateforme que l'on peut exploiter avec des pratiques DataOps normales, et non comme une collection d'expériences qu'il faut déplacer à la main.

Le CI/CD devient enfin cohérent

Microsoft documente maintenant une architecture CI/CD complète. Git, deployment pipelines et bibliothèques de variables reposent sur les mêmes API. Les automatisations peuvent tourner dans GitHub Actions, Azure Pipelines ou un runner interne. Le support des service principals évite de suspendre une livraison au compte personnel d'un développeur.

Les nouvelles expériences Git vont plus loin. Un branched workspace permet d'isoler une branche de fonctionnalité dans un workspace lié au workspace source. Le branchement sélectif évite de recopier tout un domaine lorsque le développeur ne touche que quelques items. La comparaison de code enrichie rend aussi les changements plus lisibles avant commit ou synchronisation. Ces fonctions restent en preview, mais elles répondent à un problème réel des gros workspaces.

Le mode de publication en masse de fabric-cicd 1.2.0 s'appuie sur l'API d'import par lot quand le scénario est supporté, puis revient au mode classique ailleurs. C'est une évolution discrète mais importante pour les plateformes qui déploient des dizaines d'items. Le CI/CD du SQL analytics endpoint et le source control du Warehouse avancent aussi avec des projets DacFx et des changements de schéma incrémentaux.

Ma préférence reste une chaîne simple. Le workspace de développement est connecté à Git. Une pull request porte la revue et les tests. Le déploiement vers Test puis Prod utilise des workspaces dédiés, des identités non humaines et des valeurs d'environnement explicites. L'interface Fabric peut accélérer le quotidien, mais le dépôt reste la source de vérité.

Dataflow Gen2 change de catégorie

Dataflow Gen2 était l'une des briques où le décalage avec une vraie exploitation industrielle se voyait le plus. Depuis avril 2026, tous les nouveaux items sont créés avec la prise en charge de Git et du CI/CD. L'ancien Dataflow Gen2 sans CI/CD continue de fonctionner, mais il n'est plus proposé pour une nouvelle création. La conversion passe par Save As.

Le cycle d'édition a aussi été simplifié. Enregistrer remplace l'ancienne séparation entre sauvegarde et publication. Une publication juste à temps aligne ce que l'éditeur montre avec ce qui sera exécuté. Les deployment pipelines déplacent ensuite le dataflow entre workspaces.

Le vrai enjeu est la configuration. Les paramètres publics permettent de modifier la logique, les sources ou les destinations au runtime. Les bibliothèques de variables centralisent les identifiants et les valeurs propres à chaque étage. Les références relatives limitent les GUID codés en dur. Microsoft rappelle toutefois qu'une connexion de source ne peut pas encore être reconfigurée dynamiquement comme une simple variable. Il faut donc tester chaque environnement et prévoir les liaisons nécessaires.

Autre évolution majeure, les Mapping Data Flow Transforms ajoutent des transformations visuelles exécutées sur Spark dans Dataflow Gen2. L'objectif est double. Les équipes peuvent créer du low-code à plus grande échelle et migrer progressivement les Mapping Data Flows d'Azure Data Factory ou Synapse. La fonction reste en preview, mais elle rapproche enfin le monde Power Query d'un moteur distribué dans la même expérience.

• Git et deployment pipelines. Les nouveaux dataflows entrent dans le même cycle de livraison que les autres items.
• Actualisation incrémentielle. Les données sont découpées en buckets et seuls les ensembles modifiés sont remplacés dans les destinations prises en charge.
• Fast Copy. Les gros volumes peuvent emprunter un chemin de copie parallèle au lieu du moteur mashup classique.
• Modern Evaluator. Le moteur moderne en .NET 8 est généralement disponible et peut accélérer certains scénarios.
• Diagnostic de refresh. Le téléchargement de diagnostics détaillés est en preview pour faciliter l'analyse des échecs.

Dataflow Gen2 n'est donc plus seulement « Power Query dans Fabric ». Il devient une façade qui peut combiner moteur mashup, staging SQL, Fast Copy et calcul Spark. Cette richesse est utile, mais elle rend la lecture des coûts en CU plus importante. Deux dataflows visuellement proches peuvent utiliser des chemins d'exécution très différents.

Spark 4.1 et Runtime 2.0 changent le socle

Fabric Runtime 2.0 est généralement disponible depuis août 2026. Il embarque Apache Spark 4.1, Delta Lake 4.2, Python 3.13, Java 21, Scala 2.13 et Azure Linux 3.0. Il reste optionnel au moment où j'écris ces lignes. Microsoft prévoit d'en faire le choix par défaut pour les nouveaux workspaces et environnements à la fin du mois de septembre.

Je ne basculerais pas un workspace de production entier sans étape intermédiaire. Un environnement dédié permet de tester Runtime 2.0 sur quelques notebooks et Spark Job Definitions. Les bibliothèques Python et les wheels doivent être republiées dans certains environnements après la mise à niveau de Python. Les fonctions propres à Delta Lake 4.x sont encore expérimentales et ne doivent pas être activées sur des tables qui doivent rester interopérables avec tous les workloads Fabric.

Le Native Execution Engine est probablement le gain le plus visible. Il déporte les opérateurs pris en charge vers un chemin C++ vectorisé basé sur Apache Gluten et Velox. Microsoft annonce jusqu'à six fois plus de vitesse et environ 83 % d'économie de calcul face à Spark open source sur un benchmark TPC-DS donné. Ce chiffre est intéressant, mais ce n'est pas une promesse universelle.

Le moteur natif fonctionne particulièrement bien avec Parquet et Delta sur des agrégations, jointures et transformations coûteuses. Il accélère désormais le CSV, les UDF Python et Scala ainsi que les types complexes. En revanche, le streaming structuré, JSON, XML et le mode ANSI ne passent pas encore par ce chemin. Les opérateurs non pris en charge reviennent vers la JVM. Le bon indicateur n'est donc pas le toggle activé, mais le plan réellement exécuté dans la Spark UI.

Les canaux de release Default et Early Access sont également une bonne nouvelle. Ils permettent de tester les changements de bibliothèques, de sécurité ou de système avant qu'ils ne deviennent la norme. Les Custom Live Pools, encore en preview, réduisent le temps de démarrage pour les charges qui ont besoin de capacité Spark préchauffée. Le suivi de la concurrence et des files d'attente au niveau capacité est désormais GA, ce qui aide enfin à relier lenteur perçue et contention réelle.

Pipelines et exploitation gagnent en visibilité

Data Factory progresse moins par effet spectaculaire que par suppression de petites frictions. L'activité Notebook peut préremplir ses paramètres de base. Le monitoring de niveau activité permet de descendre d'un run de pipeline vers l'activité en échec. Le Refresh SQL analytics endpoint est GA, tandis que le refresh des materialized lake views peut être orchestré dans une pipeline en preview.

Microsoft pousse aussi la migration depuis Synapse et Azure Data Factory. Des compétences assistées par IA peuvent évaluer les assets, migrer notebooks, Spark Job Definitions et pipelines, puis convertir des paramètres globaux en bibliothèque de variables. Je traiterais cette fonction comme un accélérateur d'inventaire et de transformation, jamais comme une validation d'architecture. Une migration fidèle peut aussi reproduire des choix qu'il aurait fallu remettre à plat.

L'Operations Agent for Pipelines, en preview, surveille les échecs et les durées anormales puis alerte dans Teams. Le principe est pertinent. Avant de l'activer largement, je vérifierais la qualité du signal, les droits de l'agent, les données exposées et le coût opérationnel des faux positifs.

OneLake et Warehouse mûrissent sans faire autant de bruit

OneLake dispose maintenant d'un reporting de taille par item et d'une gestion du cycle de vie avec des tiers hot, cool et cold. C'est un progrès très concret pour le FinOps. Une plateforme unique n'annule pas la nécessité de savoir ce que l'on stocke, depuis combien de temps et pour quel usage.

Les patterns de distribution sans copie deviennent plus solides grâce aux shortcuts et au modèle de sécurité OneLake. Les delegated shortcuts, encore en preview, peuvent utiliser un compte d'organisation, un service principal ou une workspace identity pour accéder à la cible. Cela ouvre des scénarios inter-domaines et inter-tenants intéressants, mais les intersections de droits doivent être comprises avant d'en faire une norme.

Les materialized lake views disposent désormais d'analyses de runs, de tendances d'échec et de recommandations. Leur rafraîchissement événementiel reste en preview. Le Lakehouse Query Explorer est GA et facilite l'exploration Spark SQL avant de déplacer une logique dans un notebook ou un endpoint SQL.

Dans le Warehouse, les colonnes IDENTITY sont GA. Le source control et l'accélération GPU des requêtes restent en preview. L'accélération GPU est impressionnante sur le papier, avec jusqu'à sept fois plus de performances annoncées sur les requêtes éligibles à forte concurrence. Là encore, je veux voir les workloads compatibles, le coût et la stabilité avant d'en tirer une règle générale.

Ce que je ferais maintenant sur une plateforme Fabric

1. Cartographier les items et leurs dépendances. Je séparerais ce qui est supporté par Git, deployment pipelines et API de ce qui demande une action manuelle.
2. Normaliser Dev, Test et Prod. Chaque environnement aurait son workspace, son identité, ses connexions et son jeu de variables documenté.
3. Créer les nouveaux Dataflow Gen2 avec le modèle CI/CD. Les anciens dataflows seraient convertis progressivement avec Save As, pas en masse un vendredi soir.
4. Tester Runtime 2.0 dans un environnement dédié. Je rejouerais les notebooks critiques, les wheels, les écritures Delta et les lectures depuis les autres workloads.
5. Mesurer le moteur natif. J'activerais l'accélération sur un lot représentatif, puis je comparerais durée, CU et taux de fallback dans la Spark UI.
6. Traiter les previews comme des previews. Une fonction utile peut entrer dans un pilote sans devenir immédiatement un standard de production.
7. Suivre le coût par chemin d'exécution. Dataflow, Spark, Warehouse et Fast Copy n'ont pas les mêmes compteurs. La simplicité du portail ne doit pas masquer la consommation.

Cette méthode paraît prudente, mais elle évite deux extrêmes. Le premier consiste à ignorer des fonctions désormais suffisamment mûres. Le second transforme chaque nouveauté du portail en standard d'entreprise avant même d'avoir lu ses limitations.

Mon verdict

Fabric devient enfin plus intéressant à exploiter qu'à présenter. C'est le meilleur résumé de cette vague de nouveautés. Le produit garde une surface immense et une quantité de previews difficile à suivre. Cependant, les briques qui déterminent la fiabilité quotidienne avancent dans la bonne direction.

Le CI/CD ne se limite plus à quelques items Power BI. Dataflow Gen2 rejoint le cycle de livraison normal. Spark adopte un runtime moderne et un moteur natif crédible. OneLake progresse sur le stockage, la sécurité et l'observabilité. Le Warehouse commence à se rapprocher des pratiques SQL attendues dans une vraie chaîne de développement.

Je ne dirais pas que tous les problèmes sont réglés. Les connexions, les dépendances, les différences de maturité et l'interopérabilité Delta demandent encore du travail d'architecte. Mais en 2026, Fabric n'est plus seulement la promesse d'une plateforme unifiée. Il commence à fournir les mécanismes nécessaires pour la gouverner et la livrer proprement.

Questions rapides

Le CI/CD de Microsoft Fabric est-il désormais complet ?

Le socle est beaucoup plus cohérent grâce à Git, aux deployment pipelines, aux bibliothèques de variables, aux API, au CLI Fabric et aux outils d'infrastructure as code. La couverture et les limitations varient encore selon les types d'items.

Faut-il migrer immédiatement vers Fabric Runtime 2.0 ?

Runtime 2.0 est GA, mais reste optionnel jusqu'à son déploiement par défaut prévu fin septembre 2026. Il faut d'abord tester les bibliothèques, les environnements et l'interopérabilité Delta sur une charge représentative.

Les nouveaux Dataflow Gen2 sont-ils versionnés dans Git ?

Oui. Depuis avril 2026, tous les nouveaux Dataflow Gen2 sont créés avec la prise en charge de Git et du CI/CD. Les anciens dataflows sans CI/CD continuent de fonctionner et peuvent être convertis avec Save As.

Le moteur natif accélère-t-il tous les traitements Spark ?

Non. Il accélère de nombreux opérateurs et formats, mais certains traitements basculent encore sur le moteur JVM. Le streaming structuré, JSON, XML et le mode ANSI font notamment partie des limites documentées.

Sources

• Microsoft Learn, nouveautés Microsoft Fabric.
• Microsoft Learn, vue d'ensemble du CI/CD Fabric.
• Microsoft Learn, options de workflow CI/CD.
• Microsoft Learn, branched workspaces et branchement sélectif.
• Microsoft Learn, bibliothèques de variables Fabric.
• Microsoft Learn, Dataflow Gen2 avec Git et CI/CD.
• Microsoft Learn, architectures ALM pour Dataflow Gen2.
• Microsoft Learn, Mapping Data Flow Transforms dans Dataflow Gen2.
• Microsoft Learn, actualisation incrémentielle Dataflow Gen2.
• Microsoft Learn, Fabric Runtime 2.0.
• Microsoft Learn, Native Execution Engine pour Spark.