J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 29 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

⚡ En 30 secondes

Ce qu’il faut retenir :

• Direct Lake combine la performance de l’Import et la fraîcheur du DirectQuery, mais il a des guardrails liés à votre SKU

• Le fallback DirectQuery est un filet de sécurité, pas une stratégie,si vous tombez en fallback régulièrement, c’est un signal d’alarme !

• Optimisez vos tables Delta (V-Order, taille des segments, cardinalité) avant de dimensionner votre capacité

Votre rapport Power BI est en mode Direct Lake. La promesse ? La performance de l’Import sans la contrainte du rafraîchissement. La réalité ? Votre dashboard exécutif rame depuis ce matin, et personne ne comprend pourquoi.

La réalité du terrain, c’est que Direct Lake est le mode de stockage par défaut sur Fabric, mais la majorité des équipes le déploient en production sans comprendre ses mécanismes internes. Le framing, le fallback, les guardrails par SKU… Ce sont ces détails qui font la différence entre un rapport qui charge en 2 secondes et un rapport qui tombe en DirectQuery sans prévenir.

Aujourd’hui, on tranche. On va décortiquer Direct Lake pour que vous sachiez exactement ce qui se passe sous le capot, et comment l’optimiser pour la production.

C’est quoi Direct Lake ?

Direct Lake est un mode de stockage pour les modèles sémantiques Power BI qui lit directement les fichiers Delta Parquet depuis OneLake, sans import préalable et sans passer par une requête SQL. Il combine :

1. La performance de l’Import : les données sont chargées en mémoire dans le moteur VertiPaq

2. La fraîcheur du DirectQuery : les changements dans OneLake sont reflétés automatiquement (framing)

3. Zéro duplication, pas de copie des données dans le modèle sémantique

C’est le mode par défaut pour tout nouveau modèle sémantique créé sur un Lakehouse ou un Warehouse dans Fabric.

Direct Lake mode VS Import / DirectQuery mode

Avant de plonger dans les variantes et les guardrails, il faut bien comprendre pourquoi Direct Lake n’est ni de l’Import, ni du DirectQuery, même si on entend souvent “c’est le meilleur des deux mondes”. Le vrai marqueur de différence, c’est ce qui se passe au moment du rafraîchissement.

✅ Import : Le moteur copie l’intégralité des données dans le modèle sémantique. Chaque refresh produit une nouvelle copie complète : lecture de la source, transfert réseau, compression VertiPaq, écriture en mémoire. C’est long, ça consomme du CPU et de la mémoire côté capacité, et ça met la source sous pression à chaque itération.

✅ DirectQuery : Aucune donnée n’est stockée dans le modèle. Chaque interaction utilisateur génère une requête SQL envoyée à la source. Pas de refresh à proprement parler, mais chaque clic dans le rapport est un aller-retour vers le moteur SQL. Performance dépendante de la source, et coût récurrent à chaque requête.

✅ Direct Lake : Le refresh ne copie pas les données. Il met à jour uniquement les métadonnées qui pointent vers les derniers fichiers Delta dans OneLake. C’est l’opération de **framing** : quelques secondes, quasi gratuite en CU. Les données restent dans OneLake, et le moteur VertiPaq les charge en mémoire à la demande, colonne par colonne, au fil des requêtes.

La conséquence directe : avec Direct Lake, la préparation des données sort du modèle sémantique et redescend dans OneLake. Vous utilisez les outils natifs de Fabric (Spark, T-SQL, Dataflows Gen2, pipelines…) pour produire des tables Delta propres en couche Silver/Gold. Le modèle sémantique se contente de pointer dessus. Plus de logique de transformation enfouie dans Power Query qui s’exécute à chaque refresh nocturne.

Pourquoi Direct Lake change la donne ?

Maintenant qu’on a posé la différence avec Import et DirectQuery, voyons ce que Direct Lake apporte vraiment en production. Ce n’est pas juste “un nouveau mode de stockage”, c’est un changement de modèle économique et opérationnel pour vos rapports Power BI.

✅ Performance VertiPaq sans la corvée du refresh ! Les requêtes Direct Lake sont traitées par le même moteur VertiPaq que l’Import. Vous obtenez des temps de réponse équivalents, sans avoir à orchestrer, surveiller et débugger des cycles de rafraîchissement qui rechargent l’intégralité des données chaque nuit. C’est autant de pipelines en moins à maintenir.

✅ Réutilisation de vos investissements Fabric :Direct Lake s’intègre nativement avec les Lakehouses, les Warehouses et toute source produisant des tables Delta dans OneLake. Pas de duplication, pas de second système à synchroniser. C’est le mode idéal pour la couche **Gold** d’une architecture Medallion : votre Lakehouse devient directement la source de vos rapports, sans intermédiaire.

✅ ROI maximisé sur la mémoire de capacité : Direct Lake charge en mémoire uniquement les colonnes et les segments nécessaires à la requête en cours. Conséquence directe : le volume total de données analysées peut largement dépasser la mémoire maximale de votre capacité. Là où un modèle Import vous oblige à tenir l’intégralité du dataset en RAM, Direct Lake vous permet d’exposer des téraoctets sur une capacité raisonnable.

✅ Latence réduite, fraîcheur automatique : Plus besoin de planifier des refreshes toutes les heures pour “rapprocher” le rapport de la source. Le framing synchronise le modèle quasi instantanément à chaque écriture dans la table Delta. Les utilisateurs métier voient les nouvelles données dès qu’elles sont écrites en OneLake, sans intervention.

Direct Lake on OneLake vs Direct Lake on SQL ?

La première chose à comprendre, c’est que Direct Lake existe désormais en deux variantes, et qu’elles ne se comportent pas du tout pareil quand ça coince.

✅ Direct Lake on OneLake (la plus récente) : le modèle lit directement les fichiers Delta Parquet depuis OneLake, sans aucun couplage au SQL analytics endpoint. Conséquence : pas de fallback DirectQuery possible. Si un guardrail est dépassé, il n’y a pas de filet, le modèle part en erreur (voir section suivante). En contrepartie, cette variante offre une intégration plus fine avec OneLake security, des plans de requête DAX plus efficaces (pas de contrôle de sécurité SQL à chaque requête), et elle supporte les modèles composites (mix avec des tables Import) ainsi que les colonnes calculées.

✅ Direct Lake on SQL endpoint (la variante historique) : le modèle s’appuie sur le SQL analytics endpoint pour la découverte des tables et la vérification des permissions. Quand Direct Lake ne peut pas charger les données nativement, vue SQL, RLS/OLS appliquée au niveau SQL, ou guardrail dépassé, il bascule automatiquement en DirectQuery via ce même endpoint. C’est le fameux filet de sécurité : les requêtes continuent de répondre, mais en mode DirectQuery, avec la perte de performance qui va avec.

🔑 Le vrai marqueur de différence : DL/OneLake échoue quand il sort des clous, DL/SQL dégrade (il tombe en DirectQuery). L’un est franc, l’autre est silencieux pour l’utilisateur, et c’est précisément ce silence qui rend DL/SQL piégeux en prod.

💡 Mon conseil

Direct Lake sur OneLake est le format à privilégier pour charger rapidement vos données en mémoire sémantique lorsque vos tables (ou vues matérialisées) sont déjà propres dans un Warehouse ou un Lakehouse. Et la bascule entre les deux variantes reste simple : il suffit de modifier la requête M de l’Expression partagée référencée par les partitions Direct Lake.

Les guardrails par SKU Fabric : combien de lignes, de fichiers, de mémoire ?

✅Les guardrails sont des limites qui varient selon votre SKU Fabric et portent sur quatre choses : le nombre de fichiers Parquet par table Delta, le nombre de row groups par table, le nombre de lignes par table, et la taille totale sur disque des données du modèle. (La limite de mémoire par modèle existe aussi, mais ce n’est techniquement pas un guardrail.)

Le point crucial, c’est que le comportement en cas de dépassement dépend de la variante :

✅ Direct Lake on OneLake : pas de fallback, donc pas de demi-mesure. Le build/refresh part en erreur (un framing fail du type « the source Delta table has too many parquet files, which exceeds the maximum guardrails »), et le modèle n’est plus interrogeable du tout tant que vous n’avez pas réoptimisé les tables Delta (OPTIMIZE). C’est brutal, mais au moins c’est visible immédiatement.

✅ Direct Lake on SQL endpoint : contre toute attente, le refresh RÉUSSIT, mais avec un avertissement dans le Refresh History (« …source Delta tables exceed the resource limits… requiring queries to fallback to DirectQuery »). À partir de là, l’intégralité du modèle bascule en DirectQuery, pour toutes les requêtes, ce n’est pas un fallback ponctuel, c’est un état permanent du modèle. Vos utilisateurs ne voient rien… sauf un dashboard qui rame. (Cas limite : sur le plus gros SKU, un F2048, le refresh échoue mais le modèle reste interrogeable, toujours en fallback DQ.)

Optimiser Direct Lake !

✅ V-Order compression : Appliquez la compression V-Order sur vos tables Delta. C’est le format natif de Fabric qui optimise à la fois le chargement (streaming compressé) et les requêtes (VertiScan calcule directement sur les données compressées). Les Notebooks Spark de Fabric l’appliquent par défaut.

✅ Taille des segments : VertiPaq stocke les données par segments de colonnes. Visez entre 1 million et 16 millions de lignes par segment pour les grandes tables. Trop de petits segments = performance dégradée.

✅ Cardinalité des colonnes : Les colonnes à forte cardinalité (beaucoup de valeurs uniques) ralentissent les requêtes. Réduisez la cardinalité là où c’est possible : arrondissez les timestamps, regroupez les valeurs rares.

✅ Types de données : Utilisez des types entiers plutôt que des chaînes de caractères pour les IDs. Évitez de stocker des nombres sous forme de texte.

Voir doc pour plus d’informations : Cross-Workload Table Maintenance and Optimization - Microsoft Fabric

🥇 La Règle d’Or

Si tu dois retenir une chose : Direct Lake n’est ni de l’Import, ni du DirectQuery. C’est un moteur qui déplace ton travail d’ingénierie data en amont, dans tes tables Delta, pour que ton modèle sémantique ne fasse plus que pointer dessus.

Concrètement : connais tes guardrails de SKU avant de partir en prod, mesure tes tables (lignes, fichiers Parquet, row groups) avant de monter en capacité, et applique OPTIMIZE + V-Order avant de toucher au portefeuille.

Et vous, avez-vous déjà rencontré des fallbacks DirectQuery inattendus sur vos rapports Direct Lake ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

• Vue d’ensemble de Direct Lake

• Comment Direct Lake fonctionne

• Optimiser le stockage Direct Lake

• Intégrer la sécurité avec Direct Lake

• Gérer les modèles sémantiques Direct Lake

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 28 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Vous avez sûrement entendu parler de Copilot dans Fabric : meilleure productivité, accès rapide à l’information dans les rapports, génération de mesures DAX en langage naturel... Le pitch est convaincant.

Mais sur le terrain, je vois régulièrement des équipes Data bloquer le déploiement à grande échelle, non pas parce que la fonctionnalité déçoit, mais parce que personne ne sait répondre clairement à cette question : qui absorbe la consommation en CU de Copilot, et sur quelle capacité ?

Si vos pipelines de données, vos notebooks Spark et vos rafraîchissements de modèles sémantiques tournent sur la même capacité que vos utilisateurs Power BI, activer Copilot sans garde-fou, c’est ajouter une charge non planifiée sur une infrastructure déjà dimensionnée au plus juste. Le risque de throttling n’est pas théorique : il arrive, très sûrement, et il perturbe exactement les traitements que vous ne voulez pas voir s’arrêter.

La Fabric Copilot Capacity (FCC) est la réponse structurelle à ce problème.

De quoi parle-t-on ?

La Fabric Copilot Capacity est une brique de configuration qui vous permet de désigner une capacité Fabric comme capacité dédiée au Copilot. Une fois configurée, la consommation Copilot de vos utilisateurs assignés est dirigée vers cette capacité dédiée, et non vers la capacité du workspace où se trouve leur contenu.

En clair : votre capacité de production n’absorbe plus les requêtes IA de vos cinquante analystes qui interrogent leurs rapports en langage naturel.

Depuis avril 2025, cette fonctionnalité est accessible à partir d’une capacité de SKU F2, la plus petite capacité Fabric disponible.

1. Le problème que FCC résout concrètement

Historiquement, pour qu’un utilisateur Power BI accède à Copilot, il fallait que son workspace soit hébergé sur une capacité Premium (P1 ou supérieur, ou F64 minimum).

Résultat : les équipes qui avaient des workspaces Pro ou PPU n’avaient tout simplement pas accès à Copilot, même si l’organisation disposait d’une capacité Fabric ailleurs.

FCC résout ce problème en permettant aux administrateurs de capacité d’accorder un accès direct à Copilot, sans avoir à migrer le contenu vers un workspace Premium.

Vos utilisateurs gardent leurs workspaces Pro. Vous leur donnez accès à Copilot via la FCC. Aucun déménagement d’artefacts.

2. Les scénarios couverts

Une fois un utilisateur assigné à une Fabric Copilot Capacity, sa consommation Copilot est facturée sur cette capacité dédiée dans ces cas précis :

• Copilot dans Power BI Desktop

• Copilot dans Power BI Service (workspaces Pro, PPU, ou Fabric capacity)

• Copilot sur les workloads Fabric (Data Factory, Data Engineering, Data Warehouse, Data Science, Real-Time Analytics, Activator) pour les capacités inférieures à F64

• Data Agents sur les capacités inférieures à F64

💡 Astuce : Si vous êtes déjà sur une capacité F64 ou supérieure, la FCC est moins critique pour les workloads Fabric (la capacité gère déjà Copilot nativement). Son intérêt est maximal pour isoler les usages Power BI Pro/PPU et pour les petites capacités de production.

3. Le modèle de coût qui change tout

Cela signifie que si vous êtes sur une licence Pro ou PPU, vous pouvez activer Copilot pour votre organisation pour moins de 300 dollars par mois en démarrant une F2 et en la désignant comme Fabric Copilot Capacity dédiée.

La logique économique est simple :

• Vous achetez une petite capacité (F2 à F64 selon le volume d’usage Copilot attendu)

• Vous la désignez comme FCC

• Toute la consommation IA de vos utilisateurs assignés remonte sur cette capacité

• Votre capacité de production reste préservée pour ses vraies charges : ingestion, transformation, rafraîchissements

La consommation Copilot dans Power BI impacte votre capacité Fabric disponible, si elle n’est pas isolée, une surconsommation peut conduire au throttling et perturber vos autres opérations Fabric.

C’est exactement le risque que FCC supprime.

4. La configuration : 3 étapes, pas plus

Le déploiement d’une FCC implique deux rôles distincts : l’administrateur Fabric et l’administrateur de capacité. Ne les confondez pas : chacun intervient à une étape spécifique, et l’ordre est important.

Étape 1 : L’administrateur Fabric active Copilot pour l’organisation

Dans le portail d’administration Fabric, sous Copilot and Azure OpenAI Service, activez le paramètre “Users can use Copilot and other features powered by Azure OpenAI”. Ce paramètre est activé par défaut sur les nouveaux tenants, mais vérifiez qu’il ne soit pas désactivé manuellement dans votre environnement.

Étape 2 : L’administrateur Fabric autorise la désignation d’une FCC

Dans ce même groupe de paramètres, activez “Capacities can be designated as Fabric Copilot capacities”. Ce paramètre est désactivé par défaut — c’est souvent là que le déploiement bloque sans que l’on comprende pourquoi. Sans cette étape, l’administrateur de capacité ne verra pas l’option de désignation FCC dans ses paramètres. Vous pouvez restreindre cette autorisation à des groupes de sécurité spécifiques plutôt qu’à toute l’organisation.

Étape 3 : L’administrateur de capacité assigne les utilisateurs à la FCC

Une fois la capacité désignée comme FCC, l’administrateur de capacité accède aux Capacity settings et assigne les groupes d’utilisateurs autorisés à utiliser cette capacité pour leur consommation Copilot. À partir de là, aucune action supplémentaire n’est requise côté utilisateur, le routage de facturation est transparent.

💡 Tips : Créez un groupe de sécurité dans votre Entra ID et assignez ce groupe directement à la Fabric Copilot Capacity dans le portail d'administration. Ils pourront utiliser l'IA partout, sans que vous n'ayez besoin de migrer le moindre rapport vers une nouvelle capacité physique.

⚠️ Points de vigilance

• La région. La Fabric Copilot Capacity n’est supportée que dans la région d’accueil du tenant Fabric. Si votre tenant est hors US/France, vérifiez le paramètre de traitement des données hors région avant tout déploiement.

• Un seul FCC par utilisateur. Si un utilisateur est assigné à plusieurs Copilot capacities, c’est la plus récemment créée qui enregistre son usage. Évitez les configurations ambiguës dans vos groupes de sécurité.

• Les Fabric AI functions ne sont pas concernées. FCC ne couvre pas les AI functions (les transformations IA natives dans les notebooks et dataflows). Ce sont deux mécanismes distincts.

• Les capacités Embedded sont exclues. Les SKUs de type A1, A2, EM1 dédiés à l’embedding externe ne sont pas compatibles. FCC ne fonctionne qu’avec les capacités F-type et P-type.

✅ Conclusion

Si tu dois retenir une chose : La Fabric Copilot Capacity ne supprime pas la consommation de Copilot, elle l’isole. Sans elle, vous choisissez entre priver vos utilisateurs Pro/PPU d’un accès à Copilot, ou accepter que l’IA grignote votre capacité de production au moment le moins opportun.

Mais isoler la consommation ne dispense pas de la surveiller.

La Fabric Capacity Metrics App reste votre meilleur allié une fois la FCC en production. En analysant l’onglet Item history de votre FCC, vous pouvez identifier précisément quels rapports et quels workspaces génèrent le plus de consommation Copilot et agir en conséquence : dimensionner la capacité à la hausse, restreindre l’accès à certains groupes, ou simplement comprendre qui utilise vraiment la fonctionnalité avant de la déployer plus largement.

Et vous, comment avez-vous structuré l’accès Copilot dans votre organisation ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

📘 Fabric Copilot Capacity — Documentation officielle Microsoft

🛠️ Activer Copilot dans Fabric — Guide administrateur

🛠️ Activer Copilot pour Power BI — Prérequis et configuration

📘 Vue d’ensemble de Copilot dans Fabric

🔗 Updates to Fabric Copilot Capacity — Blog Microsoft Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 27 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

⚡ En 30 secondes

• Copilot est un assistant préconfiguré et généraliste, intégré aux workloads Fabric et à Power BI. Il fait deux choses : il aide à produire (code, DAX, requêtes) et il répond en langage naturel aux utilisateurs métier (Copilot dans Power BI, expérience standalone). Vous ne le paramétrez pas.

• Data Agent est un artefact que vous configurez : un expert curé sur un domaine précis (instructions, exemples, sources choisies). Gouverné, en lecture seule, il s’expose dans tout l’écosystème Microsoft : Teams, M365 Copilot, Foundry… et jusque dans Copilot lui-même.

• L’action à lancer : arrêtez de demander “Copilot ou Data Agent ?”. Demandez plutôt “Ai-je besoin d’un assistant généraliste prêt à l’emploi, ou d’un expert gouverné que je configure sur mon domaine ?”. Vous avez la réponse.

Ce matin, j’ai un client qui me dit : “Antoine, on a activé Copilot dans Fabric. Du coup, on n’a plus besoin des Data Agents, c’est bien ça ?”

Je vois souvent cette confusion, et elle est parfaitement logique. Les deux utilisent des grands modèles de langage. Les deux répondent en langage naturel. Sur le papier, on dirait deux noms pour la même chose.

La réalité du terrain, c’est que ce sont deux briques bien distinctes, et je vais vous expliquer la différence au niveau des configurations et des rôles.

Let’s go !

Deux IA, Deux Niveaux de Configuration

Posons le cadre simplement. Copilot et Data Agent reposent sur des LLM (Azure OpenAI) et savent tous les deux répondre en langage naturel. Ce qui les sépare, c’est le niveau de configuration et le rôle :

• Copilot dans Fabric & Power BI est un assistant IA intégré nativement dans toute l’expérience : partout où apparaît l’icône Copilot (Dataflow gen2, Power BI, notebooks, …), vous dialoguez en langage naturel. Préconfiguré et prêt à l’emploi, il aide à créer des visuels et des pages de rapport, écrire et expliquer du DAX ou du SQL, résumer des insights et générer des narratifs, et accélérer les transformations de données. Il travaille dans le contexte Fabric actif, avec mémoire conversationnelle et portée à l’échelle du workspace.

• Un Data Agent est un artefact Fabric que vous créez dans un workspace et publiez, exactement comme un rapport Power BI. C’est un agent conversationnel d’analyse (text-to-query) : agentique dans son fonctionnement interne (il choisit la source, invoque l’outil, génère, valide et exécute la requête) mais strictement cantonné à la lecture (aucune écriture ni action sur les systèmes). On spécifie des instructions, des exemples et jusqu'à cinq sources choisies en sélectionnant les tables pertinentes.

La distinction tient en une phrase : Copilot est l’assistant généraliste prêt à l’emploi ; le Data Agent est l’expert gouverné que vous façonnez et diffusez.

Les Deux Briques (en détail)

1. Copilot in Fabric & Power BI : l’assistant généraliste préconfiguré

Copilot vit à l’intérieur de vos artefacts. Vous ne le créez pas, vous ne le configurez pas : il est là, contextuel, prêt dès que vous ouvrez un Notebook, l’éditeur SQL d’un Warehouse ou un rapport Power BI.

Et surtout, il joue sur deux tableaux, c’est le point que tout le monde oublie :

Côté production (pour ceux qui construisent)

• Dans un Notebook : il connaît votre workspace, le Lakehouse attaché, les schémas et tables. Vous lui demandez “crée un dataframe à partir de sales.csv” ou “explique-moi cette erreur”, et il génère le code, le refactore, le commente.

• Dans le **Warehouse** : il vous assiste pour écrire et expliquer du T-SQL, directement dans l’éditeur.

• Dans **Data Factory** : il génère et explique les transformations.

Côté consommation (pour les utilisateurs métier)

• Dans Power BI, Copilot répond à des questions en langage naturel sur vos données : il interroge le modèle sémantique et renvoie une réponse sous forme de visuel, résume un rapport, crée même des calculs DAX à la volée.

• L’expérience standalone de Copilot dans Power BI va plus loin : un chat plein écran qui trouve tout seul le bon rapport, le bon modèle sémantique, ou le bon Data Agent, pour répondre sans que l’utilisateur ouvre quoi que ce soit.

La Réalité du Terrain : Copilot n’est pas “juste pour écrire du code”. C’est un assistant qui sert aussi bien le créateur que le consommateur. Sa limite n’est pas le langage naturel, c’est la configuration : vous ne lui donnez pas d’instructions métier, vous ne choisissez pas ses sources. Il prend ce qu’il trouve et fait au mieux.

2. Fabric Data Agent : l’expert conversationnel que vous configurez

Le Data Agent, lui, est un artefact que vous créez délibérément dans un workspace, puis publiez. C’est un expert que vous façonnez sur un domaine précis, pour qu’un utilisateur, souvent non technique, obtienne une réponse fiable et gouvernée, sans écrire une ligne de code.

Ce qui le caractérise :

• Vous le configurez. Vous sélectionnez jusqu’à 5 sources de données (Lakehouse, Warehouse, modèle sémantique Power BI, base KQL, ontologie, Microsoft Graph), vous choisissez les tables pertinentes, et vous l’affinez avec des instructions en langage naturel, au niveau de l’agent et de chaque source, ainsi que des exemples de requêtes (jusqu’à 100 par source). C’est vous qui définissez son rôle, son périmètre et sa logique.

• Il est gouverné et en lecture seule. Il s’exécute avec l’identité et les permissions de l’utilisateur qui pose la question. Il ne génère que des requêtes de lecture (jamais de création, mise à jour ou suppression) et respecte les politiques Microsoft Purview, le Data Loss Prevention (DLP), la sécurité niveau ligne/colonne (RLS/CLS) et le moindre privilège. Personne ne voit une donnée à laquelle il n’a pas droit.

• Il s’expose hors de Fabric. Un Data Agent se consomme depuis Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, Teams (ou via un endpoint MCP). Vous amenez la réponse là où vos utilisateurs travaillent déjà.

La réalité du terrain : Là où Copilot prend les sources qu’il trouve, le Data Agent ne répond que sur ce que vous lui avez confié, avec les instructions que vous avez écrites. C’est un produit data que vous livrez à une audience : sa qualité dépend directement du soin mis dans sa configuration. Un agent bien cadré devient un expert de confiance ; un agent mal cadré répond vite et faux.

À noter pour vos utilisateurs francophones : le Fabric Data Agent ne prend actuellement pas en charge les langues autres que l’anglais.

Source : Limitations Data Agent

Les 3 différences qui comptent vraiment

Si vous ne deviez retenir que trois lignes de démarcation, ce sont celles-ci.

a. La configuration : préconfiguré vs paramétrable

Copilot arrive prêt à l’emploi, sans réglage métier. Le Data Agent, à l’inverse, est hautement configurable : instructions, définitions de termes métier, exemples de requêtes. C’est vous qui lui apprenez votre langage.

Mon conseil : Si votre besoin exige que l’IA comprenne votre jargon (vos acronymes, vos définitions de “client actif” ou de “marge nette”), seul le Data Agent vous le permet. Copilot ne se paramètre pas à ce niveau.

b. La spécialisation : généraliste vs expert de domaine

Copilot est généraliste : dans son expérience standalone, il route tout seul votre question vers le rapport ou le modèle sémantique le plus pertinent. Pratique, mais sans garantie qu’il tape dans la bonne source ni qu’il connaisse vos définitions métier. Le Data Agent, lui, est un expert curé : il ne couvre qu’un périmètre choisi, avec un vocabulaire que vous lui avez appris. Sur son domaine, il est plus fiable ; hors de son domaine, il ne répond pas.

c. La portabilité : capacité intégrée vs brique réutilisable

Copilot est une capacité des produits Microsoft (Fabric, Power BI) : il vit là où Microsoft l’a mis. Le Data Agent, lui, est une brique réutilisable que vous branchez où vous voulez, M365 Copilot, Copilot Studio, Foundry, Teams, architectures multi-agents… et jusque dans l’expérience standalone de Copilot dans Power BI, qui peut l’appeler comme l’une de ses sources.

Matrice de Décision : Copilot ou Data Agent ?

Q1 : Avez-vous besoin de configurer un expert gouverné sur un domaine précis ?

• NON, je veux un assistant prêt à l’emploi (générer du code, ou laisser un métier explorer librement ses rapports) = Copilot !

• OUI, il me faut une réponse fiable sur un périmètre métier cadré = Data Agent.

Q2 : Avez-vous besoin que l’IA comprenne votre vocabulaire métier spécifique ?

• OUI = Data Agent. Lui seul accepte des instructions et des définitions de termes (jusqu’à 15 000 caractères) pour s’aligner sur votre langage.

• NON = Copilot. Le paramétrage métier serait inutile ; vous voulez de la productivité inline.

Q3 : La réponse doit-elle être réutilisable en dehors des surfaces Microsoft prêtes à l’emploi (Teams, Copilot Studio, Foundry, app custom, multi-agents) ?

• OUI = Data Agent. C’est une brique portable qui s’intègre partout, et que Copilot lui-même peut appeler.

• NON = Copilot. La capacité est déjà là, intégrée, sans développement.

🥇 La Règle d’Or

Si tu dois retenir une chose : Copilot est l’assistant généraliste préconfiguré, il code ET répond en langage naturel ; le Data Agent est l’expert que tu configures sur un domaine et que tu diffuses partout, jusque dans Copilot. Le premier est une capacité, le second est une brique que tu façonnes.

L’impact terrain : en posant la bonne question “ai-je besoin d’un assistant prêt à l’emploi, ou d’un expert gouverné sur mon domaine ?” vous arrêtez de choisir au hasard et vous arrêtez d’opposer deux briques qui, en réalité, s’emboîtent. Vos métiers gagnent en autonomie immédiate avec Copilot (j’ai écris d’autres blogs sur ces capacités); vos sujets sensibles gagnent en fiabilité avec des Data Agents. La complexité est l’ennemie de la maintenance, et clarifier ces deux briques, c’est déjà réduire votre dette technique future.

Et vous, où en êtes-vous ? Vos métiers se contentent-ils du Copilot généraliste dans Power BI, ou avez-vous déjà construit des Data Agents spécialisés pour vos besoins ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Concepts du Fabric Data Agent : la différence officielle entre Data Agent et Copilot, en détail

• Vue d’ensemble de Copilot dans Fabric et Power BI ; architecture, workloads couverts, sécurité

• Poser des questions à Copilot sur vos données (Power BI) : le Q&A en langage naturel, côté consommateur

• Expérience standalone de Copilot dans Power BI :comment Copilot route vers un rapport, un modèle… ou un Data Agent

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 23 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Vos sources de données peuvent être on-premises, dans le cloud, ou derrière un Virtual Network (un réseau privé sécurisé), non accessible publiquement depuis internet.

Fabric est pertinent pour l’analytique de vos données, mais comment récupérer ce qui se trouve derrière cette couche de sécurité VNet, sans friction ?

La réalité du terrain, c’est que la majorité des bases de données que je rencontre en production, PostgreSQL, SQL Server, Oracle, SAP, ne sont pas exposées sur internet. Et c’est une bonne chose. Mais ça implique de mettre en place la bonne brique de connectivité côté Fabric avant de créer quoi que ce soit.

Je vais décortiquer la méthode issue de la documentation Microsoft pour gérer cette intégration étape par étape, avec des astuces et des points de vigilance.

La solution

Fabric est un service cloud. Par défaut, il ne peut pas atteindre une ressource isolée dans un réseau privé Azure. Pour traverser ce périmètre, vous avez besoin d’une passerelle de données (data gateway), c’est un composant intermédiaire qui reçoit les requêtes Fabric, qui les exécute à l’intérieur du réseau privé, et puis en renvoie les résultats.

Il existe trois types de gateway dans Fabric :

• Cloud data gateway : géré nativement par Fabric, pour les sources cloud accessibles publiquement.

• On-premises data gateway : à installer sur un serveur ou une VM, pour les environnements locaux et datacenter privé.

• VNet data gateway : déployé et géré directement par Microsoft à l’intérieur de votre VNet Azure, sans aucune installation manuelle.

Pour une source hébergée dans un VNet Azure : c’est la troisième brique qui va nous intéresser. Et depuis une mise à jour récente, le Copy Job, l’artefact d’ingestion le plus direct dans Fabric Data Factory, la supporte nativement. Vous pouvez très bien utilisé une pipeline avec Copy Activity (voir à l’étape 2).

La méthode tient en trois étapes. Voici comment les exécuter sans se piéger.

Étape 1 : Configurer la passerelle de données de réseau virtuel

Ce qu’il faut comprendre avant de démarrer

Le VNet data gateway ne s’installe pas. Microsoft utilise le service Power Platform VNet pour injecter un conteneur managé directement à l’intérieur de votre réseau virtuel. Il n’y a pas de VM à provisionner, ni d’agent à maintenir. En revanche, il y a trois actions préalables côté Azure que votre équipe réseau doit valider.

A. Inscrire le fournisseur de ressources

Sur le portail Azure, en tant que propriétaire de l’abonnement :

• Accédez à votre Abonnement, puis “Fournisseurs de ressources”.

• Recherchez Microsoft.PowerPlatform et cliquez sur “S’inscrire”.

B. Créer et déléguer un subnet dédié

Dans votre VNet Azure, créez un nouveau subnet dédié exclusivement au VNet data gateway :

• Nommez-le explicitement, évitez gatewaysubnet et AzureBastionSubnet, ces noms sont réservés à d’autres services Azure et bloqueront la création.

• Dans la délégation de sous-réseau, sélectionnez Microsoft.PowerPlatform/vnetaccesslinks.

• Ce subnet ne doit pas contenir d’espace d’adressage IPv6 et ne doit pas chevaucher la plage 10.0.1.x.

💡Astuce : Si vous manipulez de grands volumes de données, ajoutez le service endpoint Microsoft.Storage sur ce subnet dès maintenant.

⚠️ Point de vigilance : Cette délégation nécessite le rôle Contributeur Réseau (ou l’autorisation Microsoft.Network/virtualNetworks/subnets/join/action) sur le VNet.

C. Créer la passerelle dans Fabric

Dans Fabric : Accédez aux “Settings”, puis “Manage connections and gateways” :

1. Cliquez sur “+ New” puis sélectionnez “Virtual Network data gateway”.

2. Sélectionnez votre Capacity Fabric (toute SKU Fabric est compatible — F2 et au-dessus).

3. Renseignez : Abonnement Azure, Resource Group, VNet, Subnet (seuls les subnets délégués à Power Platform apparaissent dans la liste).

4. Nommez le gateway de façon explicite : vnet-gw-prod-westeurope plutôt que gateway1. Vous en aurez plusieurs, distinguez-les dès le départ.

5. Cliquez sur “Save”. Le provisionnement prend 2 à 5 minutes.

Étape 2 : Créer un Copy Job dans Microsoft Fabric

Le Copy Job est l’artefact d’ingestion que nous allons mettre en place. Conçu pour les transferts fiables et optimisés en volume, il supporte désormais nativement les connexions via VNet data gateway.

Dans votre Workspace Fabric :

1. Cliquez sur “+ New item” et sélectionnez “Copy job”.

2. Donnez-lui un nom explicite, lié à la source et à l’environnement : copyjob-erp-prod par exemple.

3. Choisissez la base de données à partir de laquelle copier des données :

4. Fabric vous guide ensuite vers la configuration de la connexion source, c’est là qu’intervient la dernière étape.

Étape 3 : Sélectionner le VNet data gateway lors de la configuration de la connexion source

Dans la configuration du Copy Job, à l’écran de sélection de la source :

1. Renseignez les éléments de configuration de la connexion.

2. Dans le champ Data gateway, sélectionnez le VNet data gateway créé à l’étape 1.

3. Testez la connexion avant de valider.

Une fois la connexion validée, configurez votre destination normalement — Lakehouse, Warehouse, ou autre artefact Fabric. La destination est dans Fabric : aucun gateway n’est nécessaire côté destination.

Ce qui se passe réellement à l’exécution

Quand le Copy Job tourne :

• Les données transitent depuis votre source, via le conteneur injecté dans votre VNet, vers Fabric.

• Elles ne passent à aucun moment par l’internet public.

⚠️ Pièges à Éviter

Ne choisissez pas l’on-premises gateway par réflexe pour une source Azure.

• Je vois des équipes installer un on-premises gateway sur une VM Azure pour atteindre une source dans un VNet. C’est une erreur ! Si votre source est dans Azure, le VNet data gateway est fait exactement pour ça — sans la charge opérationnelle.

Ne sous-estimez pas l’impact sur votre Capacity.

• Le VNet data gateway consomme des Capacity Units (CU) à chaque requête. Sur une Capacity mutualisée avec d’autres workloads, un Copy Job massif via gateway peut créer de la contention. Monitorez votre consommation dans le Fabric Capacity Metrics app dès la mise en production.

Un seul gateway pour tous les environnements : attention à la dette technique.

• Il est tentant de centraliser dev, recette et prod sur un seul VNet gateway. À court terme, ça simplifie. À moyen terme, un problème sur ce gateway coupe tous vos environnements simultanément. Séparez au minimum la production des environnements de développement sur des gateways distincts.

Matrice de Décision

Q1 : Votre source est-elle accessible depuis l’internet public ?

• OUI : Cloud data gateway. Aucune configuration requise, passez directement à la création de connexion.

• NON : Passez à Q2.

Q2 : Votre source est-elle hébergée dans un VNet Azure ?

• OUI : VNet data gateway. Pourquoi ? Pas de VM à gérer, déploiement managé par Microsoft, intégration native avec la Capacity Fabric.

• NON (datacenter on-premises, réseau privé non-Azure) : On-premises data gateway.

Conclusion

Si tu dois retenir une chose : connecter une source dans un VNet à Fabric, c’est trois étapes dans le bon ordre, configurer le VNet data gateway, créer le Copy Job, sélectionner le gateway sur la connexion source.

L’impact terrain est immédiat : vos données ne transitent plus par l’internet public et vous restez dans le modèle de gouvernance Fabric sans sortie de l’écosystème.

Et vous, quelle est votre configuration actuelle pour atteindre vos sources privées dans Fabric ?

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

• 🛠️ Créer et configurer un VNet data gateway — Documentation officielle Microsoft

• 📘 Copy Job avec VNet data gateway

• 🛠️ Créer un Copy Job dans Microsoft Fabric

• 🔗 Gérer les connexions et gateways dans Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 23 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’oeil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

⚡ En 30 secondes

Ce qu’il faut retenir :

• Rayfin vous permet de définir backend, data model, API et policies en code, puis de déployer dans Fabric avec `rayfin up`.

• Avec Fabric Apps (Preview), l’app devient un artefact Fabric gouverné, avec SSO Entra ID, backend URL, SQL + API GraphQL et static hosting.

• Ma démo est pensée pour être testée dans VOTRE environnement : aucune config tenant commitée, chacun cible son propre workspace capacity-backed.

L’IA générative avance à une vitesse fulgurante. Voici ce qui est devenu possible aujourd’hui : un agent IA (GitHub Copilot, Claude, Cursor…) génère une app complète, frontend, backend, base de données, API, en moins de 10 minutes. Et contrairement à ce qu’on croyait il y a 2 ans, ce n’est plus juste un prototype jetable : vous pouvez le déployer directement en production sur une plateforme gouvernée comme Fabric.

Mais voilà le piège : la plupart des gens ne le savent pas encore. Et même ceux qui l’essaient se retrouvent bloqués au moment du déploiement.

• Où stocker les données ?

• Comment mettre en place l’authentification sans exposer les secrets ?

• Qui peut accéder à quoi ?

• Comment transformer ce prototype généré en une app qui tient vraiment en production, avec gouvernance et RBAC ?

C’est exactement ce problème que Rayfin (+ Fabric Apps) résout.

C’est quoi ? Rayfin + Fabric Apps (Preview)

Rayfin est un SDK + CLI open source annoncé à Build 2026 pour définir un backend complet en code (modèles, API, accès, logique), puis le déployer sur Microsoft Fabric.

Fabric Apps (Preview) est la brique d’exécution managée dans Fabric : l’application tourne comme un item de la plateforme, avec gouvernance, sécurité, et intégration native avec l’écosystème Fabric.

En pratique, vous passez d’un bricolage multi-services à un workflow code-first plus direct : définir, déployer, itérer.

Réflexion

✅ Qui va vraiment en tirer de la valeur ? (métier vs dev)

• Profils métier (non-code) : oui, il y a une opportunité de vibe coding avec un agent pour prototyper vite une app interne. Mais le cadre idéal reste un binôme avec une personne technique pour vérifier le schéma, les droits et le déploiement.

• Développeurs applicatifs classiques : beaucoup ne vont pas “coder une app dans Fabric” au sens plateforme complète, car cela demande de comprendre les prérequis tenant/capacity, les permissions et le modèle de déploiement.

• La bonne lecture : Rayfin n’est pas “no-code magique” ni “réservé aux experts Fabric”. C’est surtout un accélérateur pour des équipes mixtes métier + tech qui veulent livrer vite sans perdre la gouvernance.

🎯 Démo rapide et efficace !

Zava Deliveries est une application de preuve de livraison (POD) complète et authentifiée (je n’ai codé aucune ligne de code, tout en “vibe coding” avec Github Copilot).

GitHub : awang1020/rayfin-delivery-app

Le contexte métier :

• Les chauffeurs enregistrent chaque livraison (destinataire, adresse, articles) avec preuves photo et état des articles (bon, endommagé, manquant, partiel).

• Les clients confirment la réception avec avis ou signalent un problème.

• En cas de litige, le chauffeur propose une résolution (avec preuve mise à jour) ; le client revalide ou relance une nouvelle contestation.

Pourquoi c’est un cas d’école :

• Authentification Fabric SSO (aucun accès anonyme).

• Row-level security : une livraison n’est visible que par son chauffeur ou son client.

• Workflow réaliste multi-étapes avec résolution de litige.

Points de vigilance / Pièges à éviter

1. Preview n’est pas GA

   Fabric Apps est en preview. Le bon reflexe est de tester sur un environnement de validation et de verifier votre region/capacity supportee avant de planifier un usage business-critical.

2. Prérequis tenant souvent oubliés

   Il faut :

   1. Un workspace sur Fabric capacity (trial ou payant) et vérifiez la disponibilité sur la région.

   2. Le workload Fabric Apps (preview) activé par un tenant admin.

   3. Les droits pour créer des items dans le workspace cible.

3. Ne confondez pas vitesse et gouvernance automatique

   Rayfin accélère la mise en route, mais vous restez responsable de ce que votre app expose. Concrètement : gestion des secrets, politiques d’accès, et hygiène des permissions item-level.

🥇 La Règle d’Or

Si tu dois retenir une chose : Rayfin ne remplace pas votre discipline d’architecture, mais il élimine une grosse partie de la plomberie qui vous ralentit entre “idée” et “app testable

Le vrai gain, ce n’est pas seulement de deployer vite. C’est de permettre à plusieurs personnes de tester la même application dans leur propre environnement Fabric, avec des règles de gouvernance explicites, sans copier-coller de secrets ni bricolage infra.

Et oui, les profils métier peuvent s’en servir en mode “vibe coding” pour accélérer le prototype. Mais pour aller au-delà du “démo effect” et tenir en conditions reelles, il faut une couche de discipline technique sur le déploiement et la sécurite.

Et vous, avez-vous testé Rayfin et Fabric Apps ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

• What is Fabric Apps (Preview)?

• Introducing Rayfin: A new AI-first way to build, deploy, and govern application backends

• Demo repo

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

🆕 Nouveauté pour les lecteurs : j’ai créé Ask Fabric Mastery, un assistant IA qui répond à vos questions sur Microsoft Fabric & Power BI en s’appuyant uniquement sur les 23 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : ask-fabric-mastery
🔑 Code d’accès : fabric-mastery-2026

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

La première étape de tout projet dans Microsoft Fabric, c'est de se connecter aux sources.

Quand on parle d’ingestion de données, on parle également de configuration de la connexion pour s’authentifier à la source.

• Comment Microsoft Fabric peut accéder aux données ?

• Les données sont sur du Cloud ou isolée dans un VNet ou On-Premises ?

• Quelle méthode d'authentification et de gouvernance est imposée ?

Souvent, pour aller vite et lancer un PoV sur Microsoft Fabric, le réflexe naturel est d’utiliser son propre compte nominatif (login et mot de passe).

C’est rapide et efficace sur l’instant, mais pas propre !

Car le jour où vous passez en production et que ce développeur quitte l’entreprise, son compte Entra ID est désactivé, et 100% de vos pipelines s’effondrent. On passe alors plus de temps à faire de l’archéologie pour retrouver et réassigner les connexions qu’à réellement construire le flux.

Pourquoi c’est un problème pour vos équipes ? Parce que laisser les utilisateurs monopoliser les connexions avec leurs comptes personnels crée un “Single Point of Failure” (SPOF) critique. C’est transformer chaque départ ou changement de poste en crise technique inévitable.

Voyons voir quelles sont ces méthodes d’authenfication ainsi que les bonnes pratiques dans un contexte de mise en production.

Décryptage

Dans Fabric, la gestion des accès propose un panel d’options pour découpler l’identité du développeur de l’identité du pipeline. L’objectif est de créer une méthode d’authentification fiable et pérenne.

⚠️ Attention : Le menu d’authentification n’est pas magique. En fonction de la source de données ciblée (API, Azure SQL, Snowflake, etc.), Fabric ne vous proposera pas les mêmes options. Vous aurez généralement le choix entre :

• Basic (Login / Mot de passe classique)

• Organizational Account (OAuth 2.0, votre compte Entra ID)

• Service Principal (SPN)

• Workspace Identity

1. Basic

• C’est quoi ? Le bon vieux couple “Login / Mot de passe”.

• La réalité du terrain : C’est souvent la seule option pour des bases de données anciennes (On-Premises) ou des API très simples qui ne supportent pas l’OAuth.

• Mon conseil : À utiliser uniquement si vous n’avez pas le choix (ex: un vieux SQL Server local derrière une Gateway). Si vous l’utilisez, le mot de passe doit être celui d’un compte de service générique (ex: svc_fabric_read), jamais celui d’un humain.

2. Organizational Account

• C’est quoi ? C’est l’OAuth 2.0. Vous cliquez sur “Sign in”, une pop-up s’ouvre, vous validez avec votre compte Microsoft Entra ID (MFA, etc.).

• La réalité du terrain : C’est l’option par défaut, ultra-rapide. Parfait pour le Dev et le PoV.

• Mon conseil : C’est la zone de danger pour la Prod. Si un pipeline de production tourne avec cette méthode, vous avez créé une bombe à retardement liée à votre présence dans l’entreprise. À bannir des environnements de Prod.

3. Service Principal

• C’est quoi ? Une “App Registration” dans Azure. C’est une identité applicative pure, définie par un Client ID et un Secret (ou certificat).

• La réalité du terrain : C’est le standard de l’industrie pour les connexions “Machine-to-Machine”. Elle est indispensable pour se connecter à des sources qui ne font pas partie de votre tenant Azure ou pour des API tierces.

• Mon conseil : Pour que ce soit propre, ne tapez jamais le secret “en dur” dans Fabric. Stockez-le dans un Azure Key Vault et configurez Fabric pour aller le lire. Ainsi, l’équipe Sécurité peut faire tourner les clés sans casser vos pipelines.

4. Workspace Identity

Workspace Identity est un Principal de Service géré automatiquement, créé par les utilisateurs Fabric et associé à l’espace de travail.

• La différence technique : Contrairement au SPN classique (App Registration) que vous devez créer et maintenir dans Azure, ici Fabric pilote tout. C’est un SPN invisible dont le cycle de vie est lié au Workspace.

• La Tueur Feature : Elle permet une authentification transparente et sécurisée (sans secret à gérer) vers les services Azure, y compris les comptes de stockage protégés par pare-feu (Trusted Workspace Access).

• Mise à jour majeure : Longtemps réservée aux items techniques, elle est désormais supportée par les Dataflow Gen2, Pipelines et Copy Job (à vérifier en fonction des connecteurs).

• Mon conseil : C’est votre choix N°1 par défaut pour tout l’écosystème Azure/Fabric (ADLS Gen2, SQL DB). On supprime le workspace, l’identité disparaît. La gouvernance est totale et sans effort.

En pratique : Accès aux données Azure via Workspace Identity

Voici la méthode exacte pour ne plus jamais gérer de mots de passe :

Étape 1 : Créer l’Identité (Côté Fabric)

Allez dans les paramètres de votre Workspace (sauf “My Workspace”).

1. Onglet Workspace identity.

2. Cliquez sur le bouton + Workspace identity.

3. C’est tout. Votre espace de travail a maintenant une existence propre dans l’AD.

Étape 2 : Donner les droits (Côté Azure)

C’est l’étape que tout le monde oublie. L’identité existe, mais elle n’a le droit de rien faire.

1. Allez sur le portail Azure > Votre Storage Account.

2. Onglet Access control (IAM) > Add role assignment.

3. Choisissez le rôle précis (ex: Storage Blob Data Reader pour de la lecture seule).

4. Dans “Assign access to”, cherchez le nom de votre Workspace Fabric et validez.

Étape 3 : Connecter le flux (Côté Dataflow Gen2)

1. Créez votre Dataflow Gen2.

2. Connectez-vous à votre Azure Blob Storage.

3. Dans “Authentication kind”, ne mettez pas “Organizational account”. Sélectionnez Workspace Identity.

4. Le tour est joué.

Quand l'identité ne suffit plus : Le cas obligatoire des Gateways (On-Prem & VNet)

Si vos données ne sont pas exposées publiquement sur internet, aucune identité cloud n’y accèdera directement. Il faut obligatoirement configurer une Data Gateway (Passerelle de données) en amont. Elle agit comme un pont : elle évalue les requêtes sur la machine hôte et transfère la donnée de manière sécurisée vers le cloud.

Il existe deux grands cas de figure où cette passerelle est indispensable :

1. Les sources On-Premises : Cela concerne les bases de données sur des serveurs physiques, les fichiers stockés dans un répertoire local d’entreprise, les machines virtuelles hébergées dans le cloud (IaaS), ou même lorsqu’une requête combine des données cloud et locales.

2. Les réseaux privés (VNet) : Dès qu’une source est isolée d’internet pour des raisons de sécurité (ex: Azure VNet). Cela inclut les data centers derrière un pare-feu, les VM cloud dans un VNet (IaaS), ou encore les services de base de données cloud (PaaS, comme Azure SQL) restreints à un réseau virtuel.

Matrice de décision

Pour sécuriser vos flux et forcer le bon choix technique, suivez cet arbitrage :

• Q1 : Est-ce du prototypage rapide ou une analyse ad-hoc personnelle sur le cloud ?

  • 👉 Organizational Account (OAuth). Le seul cas où le nominatif est accepté.

• Q2 : La cible est-elle un service Azure/Fabric compatible Entra ID (ADLS Gen2, Azure SQL) ?

  • 👉 Workspace Identity. La connexion meurt avec l’espace de travail.

• Q3 : S’agit-il d’une API tierce, d’un SaaS ou d’une source cloud incompatible avec l’identité managée ?

  • 👉 Service Principal (SPN). Implémenté via une Cloud Connection partagée.

• Q4 : Les données sont-elles sur un réseau privé ou un serveur physique local ?

  • 👉 Mettre en place une Data Gateway. Installée sur une VM dédiée (jamais un poste de travail), couplée à un compte de service local (Basic / Windows Auth), et partagée à votre groupe de sécurité de développeurs.

Conclusion

Si tu dois retenir une chose : Une architecture de données robuste survit au départ de son créateur ; si un pipeline de production dépend de l’adresse email d’un développeur ou d’une passerelle installée sur son ordinateur portable, ce n’est pas de la production, ça risque de casser à un moment donné.

Pérenniser vos connexions, c’est éliminer une dette technique invisible et garantir une continuité de service totale. C’est bâtir un socle gouverné (Cloud & On-Prem) pour que vos ingénieurs arrêtent de faire de la plomberie d’urgence et se concentrent enfin sur la valorisation de la donnée, sans trembler à chaque mouvement RH.

Et chez vous, c’est quoi la réalité du terrain ? Vos accès “On-Premises” sont-ils blindés par des Gateways en cluster, ou tournent-ils encore en équilibre instable sur la machine d’un dév ? On en discute en commentaire ! 👇

📚 Ressources pour aller plus loin

Pour approfondir le sujet, je vous recommande ces lectures essentielles :

• 🔗 Microsoft Learn : Workspace Identity in Fabric

• 🔗 Microsoft Blog : Support for Workspace Identity in Dataflow Gen2

• 🔗 Microsoft Learn : On-premises & VNet Data Gateways

• 🔗Microsoft Learn : Service principal support in Data Factory

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

⚡ En 30 secondes

Ce qu’il faut retenir

• Date picker for slicers (Preview) : posez une sélection relative (”Last 30 days”, YTD) qui roule automatiquement à chaque refresh, sans rouvrir le rapport tous les premiers du mois. Activable via “Options > Preview features”.

• Microsoft pose la première pierre du reporting agentique avec les Skills for Fabric, un agent qui construit et publie un report Power BI depuis la ligne de commande. Limite franche : PBIP uniquement, pas PBIX.

• Le mode “sentence” des tooltips permet de raconter votre KPI en langage naturel sans créer de mesure DAX dédiée. À activer dès aujourd’hui sur vos rapports en production.

Le Power BI Update de juin 2026

Microsoft a publié le 2 juin son Feature Summary mensuel, doublé d’une vague d’annonces Build 2026 sur l’agentic stack. Le ton du mois : du pragmatisme. Pas une révolution, mais trois améliorations bien placées qui touchent directement le quotidien du report designer, un nouveau Date picker slicer (Preview), un premier stack agentique de reporting (Preview), et un polish tooltip (GA) qui a l’air anodin mais change vos habitudes.

1. Date picker for slicers (Preview)

Le “Date picker for slicers (Preview)”, est une nouvelle option pour sélectionner une période ou une seule date de votre calendrier en tant que filtre ! Il vous permet de poser une sélection relative (”Last 30 days”, “Year to date”) qui roule automatiquement à chaque refresh des données, sans rouvrir le rapport.

Sur un rapport avec 3 ou 4 slicers de date (un par page, un global, un pour la comparaison N-1…), vous économisez le rituel mensuel d’ouverture et le risque d’oubli. Vous supprimez aussi le besoin d’avoir 2 slicers par page (un “relatif” + un “absolu”), un seul contrôle fait les deux.

⚠️ Deux limites à connaître avant d’activer :

• C’est une Preview. À activer via *Options > Preview features, à ne pas généraliser sur vos rapports business-critical tant que ce n’est pas GA. Testez sur un rapport interne d’abord.

• Le jour de début de semaine n’est pas configurable. Comme le filter pane historique, “Last Calendar Week” suppose une semaine **Sunday-Saturday**. Pour l’Europe (ISO Monday-Sunday), c’est un point bloquant, Microsoft a confirmé en commentaire travailler dessus, sans date annoncée.

Source : Date Picker on Blog

2. AI-Powered Power BI reporting avec agent skills (Preview)

Microsoft pose une brique simple mais structurante : un catalogue de skills spécialisés pour Power BI, open source sur GitHub (`microsoft/skills-for-fabric`), consommable par votre agent IA préféré (GitHub Copilot CLI en cible principale, mais aussi Claude Code, Cursor, Windsurf, Codex).
L’idée : en langage naturel, vous décrivez ce que vous voulez et un agent construit le dashboard. Au lieu d’un seul Copilot qui essaie de tout faire, vous avez plusieurs skills spécialisés qui savent chacun faire une chose bien.

Trois skills couvrent aujourd’hui l’authoring de rapport :

• powerbi-report-planning recueille les besoins. Quand vous dites ”crée-moi un dashboard”, ce skill vous pose 3-5 questions cadrées (audience, objectif, périmètre, livrable), inspecte votre semantic model, et produit un brief approuvable avant la moindre ligne de code.

• powerbi-report-design choisit le quoi : tone, archetype de page (Executive Summary, Operational Monitor, Analytical Canvas…), types de visuels, palette, layout, accessibilité.

• powerbi-report-authoring exécute le comment : crée et modifie les pages, visuels, filtres, thèmes dans un projet PBIP, valide le résultat, recharge Power BI Desktop et capture des screenshots pour vérifier le rendu.

Comment ça se passe ?

L’agent route automatiquement : un prompt “redesign cette page” déclenche `report-design`, un prompt "ajoute une page de drillthrough" déclenche `report-authoring`, un prompt "créons un nouveau rapport" déclenche `report-planning` qui appelle les deux autres derrière. Vous n’avez pas à savoir lequel choisir.

💡 Soyez précis dans le prompt (audience, périmètre, décision visée, KPI…) !

Source : AI-Powered Power BI reporting — agent skills Preview

3. Tooltip options - sentence mode (GA)

Plus modeste, mais immédiatement actionnable. Dans le Format visual pane > General > Tooltips, vous avez désormais un mode “sentence” qui vous permet de construire une phrase explicative en référant directement les champs du Tooltip field well, sans créer de mesure DAX dédiée pour formater le texte.

Concrètement, au lieu d’écrire une mesure :

”Le chiffre d’affaires de “ & MAX(’Date’[Month]) & “ est de “ & FORMAT([Revenue], “€#,0”) 

vous le composez directement dans le panneau de format.

✅ La réalité du terrain : ça paraît anecdotique, mais sur un rapport, vous économisez des dizaines de mesures cosmétiques qui polluaient votre modèle. Et surtout, vous donnez aux utilisateurs métier une explication en langage naturel au hover, sans devoir ouvrir un tooltip page complet.

Source : Visual tooltips

🥇 La Règle d’Or

Si tu dois retenir une chose : Juin 2026 n’est pas un mois de révolution Power BI, c’est un mois de pragmatisme. Trois améliorations bien placées, un Date picker qui supprime la corvée mensuelle, un agent skill qui prépare le futur, un tooltip qui nettoie vos mesures cosmétiques, peuvent vous faire gagner des heures dès cette semaine si vous savez où regarder.

Et vous, sur quelle feature de juin 2026 misez-vous en premier dans votre stack ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Power BI June 2026 Feature Summary

Le PoC tourne sur un workspace unique, avec des connexions hardcodées, sans gouvernance, sans sécurité granulaire, et sans filet de secours si quelque chose casse.

• Ça suffit pour valider un cas d’usage.

• Ça ne suffit pas pour livrer une plateforme que des équipes métier vont utiliser tous les jours.

Depuis le début de cette série, on a posé les briques une par une: architecture médaillon, gouvernance des workspaces, les pipelines de déploiement, variable library, sécurité RLS/CLS/OLS…

Aujourd’hui, on assemble.

Voici les 10 points à cocher avant de considérer qu’une plateforme Fabric est réellement prête pour la production, et les erreurs classiques associées à chacun.

Gardez cette liste. Elle vous évitera des nuits d’astreinte.

Les 10 points de la checklist Fabric Production-Ready

✅ Point 1 : Architecture ! Votre architecture médaillon est-elle un contrat organisationnel, pas juste un nommage ?

→ Post de référence : Architecture Medallion dans Fabric

Bronze, Silver, Gold : trois lakehouses bien nommées ne font pas une Medallion.

La vraie question est : chaque couche a-t-elle une équipe propriétaire clairement désignée ?

• Bronze → équipe ingestion IT.

• Silver → Data Engineers.

• Gold → équipe BI ou métier.

Sans ce contrat organisationnel, la Médaillon est une convention de nommage. Avec lui, c’est un découplage structurel qui permet à chaque équipe de livrer sans bloquer les autres.

À vérifier :

• Avez-vous documenté qui est responsable de quoi dans chaque couche ?

• La couche Gold est-elle un Lakehouse ou un Warehouse selon les compétences de l’équipe consommatrice ?

• Est-ce que vous avez réellement besoin de trois couches ?

✅ Point 2 : Organiser les données ! Votre OneLake est-il organisé ou subi ?

→ Post de référence : Architecture OneLake, Choix du Data Store

OneLake est le socle de données de toute la plateforme.

Avant de créer votre dixième Lakehouse, avez-vous défini une convention de nommage des dossiers, une stratégie de partitionnement, et une règle claire sur ce qui va dans la zone Tables (managed) vs la zone Files (unmanaged) ?

Lakehouse ? Warehouse ? Eventhouse ? SQL DB ? Comment choisir le bon moteur de stockage sans créer une “dette technique” future ?

À vérifier :

• Vos données sont-elles déjà dans une application Azure ?

• Quelle est la vitesse et le volume de la donnée ?

• Quelle est la compétence technique de votre équipe ?

✅ Point 3 : Gouvernance ! Votre gouvernance des workspaces tient-elle à l’échelle ?

→ Post de référence : Gouvernance des Workspaces dans Fabric

Trois questions simples à vous poser maintenant, avant que le chaos s’installe :

• Qui peut créer des workspaces ?

• Qui associe les workspaces aux capacités ?

• Qui est propriétaire de quoi ?

Si vous n’avez pas de réponse documentée à ces trois questions et que vous avez des workspaces, c’est que vous avez un problème de gouvernance.

Référez-vous au post pour avoir une convention de nommage claire et propre ([Domaine]-[Couche]-[Environnement]) et des Domaines dans Fabric pour déléguer la gestion par entité métier.

À vérifier :

• Avez-vous restreint la création de workspaces dans les paramètres tenant ?

• Vos workspaces sont-ils rattachés à des domaines Fabric avec des Domain Admins désignés ?

✅ Point 4 : La sécurité ! Vos rôles workspace sont-ils gérés par groupes de sécurité, pas par individus ?

→ Post de référence : Gouvernance des Workspaces dans Fabric

C’est le détail d’implémentation qui coûte le plus cher en maintenance sur la durée.

Si vous attribuez les rôles, utilisateur par utilisateur, au niveau des workspaces, à chaque départ, arrivée ou changement de poste, cela nécessite une intervention manuelle sur chaque workspace concerné.

Ouf, gérer les rôles via des groupes de sécurité, c’est retirer/ajouter une personne d’un groupe, et toutes ses permissions suivent automatiquement.

À vérifier :

• Avez-vous zéro rôle workspace attribué directement à un utilisateur individuel ?

• Tous vos rôles passent-ils par des groupes de sécurité ?

✅ Point 5 : En prod, on pense au CI/CD ! Votre chaîne DEV → TEST → PROD est-elle configurée avant le premier déploiement ?

→ Post de référence : Deployment Pipelines dans Fabric

Le nombre de stages d’un Deployment Pipeline Fabric est figé à la création, vous ne pouvez pas en ajouter après coup sans tout recréer.

Et un workspace ne peut appartenir qu’à un seul pipeline, quel que soit le stage.

Ces deux contraintes structurelles exigent de planifier votre architecture d’environnements sur papier avant de créer votre premier pipeline.

La bonne séquence : Git integration en premier, Deployment Pipelines ensuite. Pas l’inverse.

À vérifier :

• Vos workspaces DEV, TEST et PROD sont-ils créés et nommés avant la configuration du pipeline ?

• Votre workspace DEV est-il synchronisé avec un repository Git ?

✅ Point 6 : Paramétrage ! Avez-vous zéro connexion hardcodée dans vos items Fabric ?

→ Post de référence : Variable Library et paramétrage dans Fabric

Une chaîne de connexion hardcodée dans un pipeline, c’est une bombe à retardement. Elle voyage silencieusement lors du déploiement DEV → PROD et envoie vos données de production au mauvais endroit.

La Variable Library est la réponse native de Fabric : elle centralise vos paramètres de configuration par workspace, avec des jeux de valeurs distincts par environnement.

Point d’attention critique : l’activation du bon jeu de valeurs post-déploiement n’est pas automatique.

Elle doit être automatisée via les APIs Fabric ou documentée comme étape obligatoire dans votre runbook.

À vérifier :

• Avez-vous une Variable Library configurée sur chaque workspace avec des jeux de valeurs DEV, TEST et PROD ?

• L’activation du jeu de valeurs cible est-elle automatisée ou documentée dans votre processus de déploiement ?

✅ Point 7 : Sécurité, encore et encore ! Votre stratégie de sécurité granulaire est-elle architecturée, pas rajoutée en dernier ?

→ Post de référence : RLS / CLS / OLS dans Fabric

La sécurité fine de la donnée dans Fabric opère sur trois couches distinctes et complémentaires : OneLake RBAC (Object-Level, Row-Level, Column-Level) pour la couche stockage, SQL Endpoint et Warehouse pour la couche requêtage, semantic model Power BI pour la couche consommation.

Ces trois couches ne se substituent pas, elles se complètent selon le moteur d’accès.

L’erreur classique : sécuriser uniquement le semantic model Power BI en oubliant que certains utilisateurs accèdent aussi via le SQL Endpoint ou directement via Spark.

À vérifier :

• Avez-vous cartographié tous les chemins d’accès à vos données sensibles ?

• Votre sécurité dynamique (USERPRINCIPALNAME) remplace-t-elle vos rôles statiques par profil là où c’est possible ?

• Les utilisateurs Contributor dans vos workspaces de consommation sont-ils au strict minimum nécessaire ?

✅ Point 8 : Ingestion ! Votre stratégie d’ingestion est-elle choisie, pas subie ?

→ Post de référence :

• Maîtriser l’Écosystème d’Ingestion et d’Orchestration

• Flux de tâches dans Fabric

C’est la question que personne ne pose assez tôt : “Quel outil d’ingestion pour quel cas d’usage ?” Et pourtant, c’est souvent le premier choix structurant de votre plateforme, celui qui conditionne vos coûts de CUs, la maintenabilité de vos flux, et l’autonomie de vos équipes sur la durée.

Shortcut, Pipeline, Dataflow Gen2, Notebooks, Eventstream, choisissez l’outil le plus adapté à vos besoins.

À vérifier :

• Avez-vous cartographié chaque flux d’ingestion avec l’outil approprié selon le volume, la fréquence et le profil de l’équipe qui le maintient ?

✅ Point 9 : Administrer la plateforme ! Avez-vous un responsable désigné pour gérer la charge de la capacité ?

→ Post de référence : Gestion de capacité Fabric

La capacité Fabric est une ressource partagée entre tous vos workspaces.

Plus vous y rattachez de workspaces et de workloads simultanés, plus vous mutualisez, et plus vous exposez l’ensemble aux variations de performance.

Sur le terrain, la question “qui gère la capacité ?” n’a souvent pas de réponse claire au moment où un job batch mal dimensionné pénalise les dashboards de la direction en production.

Désignez explicitement une équipe DataOps ou un responsable pour gérer les capacités par domaines/workspaces, pour surveiller de manière proactive les CUs, et de prendre des décisions d’optimisation et de scaling.

À vérifier :

• Avez-vous un propriétaire de capacité Fabric désigné ?

• Avez-vous des capacités séparées pour production, développement et expérimentation ?

✅ Point 10 : Comprendre vos données ! Votre OneLake est-il gouverné, découvrable et documenté ?

→ Post de référence : Comprendre OneLake, le “OneDrive” de la Data

Voici la question qui fait mal : combien de fois la même donnée est-elle copiée dans votre organisation ?

Une fois dans le Data Lake, une fois dans le Warehouse, une fois dans le Datamart Finance, et encore une copie sur le poste d’un analyste qui n’était pas sûr que la version partagée était la bonne.

C’est le chaos des données.

Et OneLake est la réponse structurelle de Fabric à ce problème, à condition de l’exploiter correctement.

La philosophie OneLake est simple : amener le calcul à la donnée, pas l’inverse.

• Shortcuts pour virtualiser sans copier.

• Mirroring pour répliquer sans ETL.

• Delta Parquet comme format universel lisible par tous les moteurs.

Mais cette promesse ne tient que si votre organisation de la donnée dans OneLake est structurée, pas subie.

À vérifier :

• Avez-vous activé l’endorsement sur vos datasets critiques dans le OneLake Catalog ?

• Votre équipe utilise-t-elle les Shortcuts avant de créer des pipelines de copie — ou duplique-t-elle encore de la donnée par réflexe ?

🥇 La Règle d’Or

Si tu dois retenir une chose : Une plateforme Fabric production-ready n’est pas le résultat d’une configuration technique parfaite, c’est le résultat de décisions organisationnelles prises avant d’ouvrir la plateforme.

Architecture, gouvernance, déploiement, paramétrage, sécurité : chacun de ces sujets exige des choix humains avant des choix techniques.

Les outils Fabric sont là pour exécuter ces choix, pas pour les remplacer.

💬 À vous de jouer

Sur ces 10 points, lequel est le grand oublié dans vos projets Fabric, celui que vous avez découvert trop tard ? Et si vous deviez en ajouter un onzième à cette checklist, lequel serait-il ?

On construit la liste ensemble en commentaire. 👇

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

⚡ En 30 secondes

Ce qu’il faut retenir :

• OneLake storage tiers : vous pouvez enfin descendre vos données froides dans des tiers économiques sans toucher à vos pipelines.

• GPU-Accelerated Fabric Data Warehouse : le Warehouse passe au GPU. Les workloads agentiques et l’analytique sur très gros volumes deviennent un cas d’usage légitime.

• Fabric Apps (Rayfin SDK) : un SDK open-source pour définir tout un backend applicatif en code (DB, API, identité, policies) et le déployer en quelques minutes dans Fabric !!

Introduction

Le mois de juin 2026 change la donne. Microsoft livre cette fois un lot de briques orientées “run” : tiering automatique sur OneLake, GPU dans le Warehouse pour absorber les nouvelles charges IA, et Rayfin pour livrer des applications gouvernées directement à l’intérieur de votre plateforme data.

Mon objectif aujourd’hui n’est pas de vous lister les 40+ features du Feature Summary. Je me concentre sur **3 nouveautés** qui vont avoir un impact immédiat sur votre quotidien, que vous soyez Data Engineer, Architecte ou responsable FinOps. C’est parti !

1. OneLake : Report, Tiers & Lifecycle Management (Preview)

👉 Première nouveauté : Le rapport de stockage OneLake est créé directement dans le portail Fabric et calcule la quantité de données stockées dans chacun de vos éléments. Utilisez cet outil pour examiner les éléments de votre espace de travail qui contribuent le plus à votre facture de stockage OneLake, afin de prendre des décisions éclairées sur la maintenance de vos données.

Utilisez le rapport de stockage pour :

• Afficher tous les éléments de votre espace de travail

• Trier et rechercher vos éléments, y compris par taille de données

• Décomposer les coûts de stockage entre les données visibles, masquées et supprimées de manière réversible

👉 Deuxième changement : auparavant, OneLake n’offrait qu’un seul tier de stockage. OneLake introduit deux briques complémentaires :

Storage tiers :

1. vos données peuvent être stockées dans des tiers à coût décroissant (hot / cool / cold). Le tier détermine à la fois le coût de stockage et le coût d’accès. Ce coût peut varier en fonction de la région. Par exemple, sur Central US :

Les 3 tiers OneLake, en résumé :

• 🔥 Hot : Utilisez le niveau “Hot” pour les données que vous consultez fréquemment, comme des projets actifs, des tableaux de bord ou des ensembles de données qui se rafraîchissent fréquemment.

• ❄️ Cool : Utilisez le niveau “Cool” pour les données que vous consultez peu fréquemment, comme des tableaux historiques, des rapports anciens ou des journaux que vous consultez occasionnellement. (Sous réserve d’une période minimale de rétention de 30 jours)

• 🧊 Cold : Utilisez le niveau “Cold” pour les données que vous consultez rarement mais que vous devez conserver pour une conservation à long terme, un audit ou une conformité, comme des journaux pluriannuels ou des instantanés archivés. (Sous réserve d’une période minimale de rétention de 90 jours)

Lifecycle management policies

Vous définissez des règles déclaratives qui déplacent automatiquement les fichiers entre tiers selon leur date de création, dernière modification, ou dernier accès. Une fois la policy posée, Fabric fait le travail en arrière-plan, vous n’écrivez plus aucun script de tiering.

⚠️ Deux pièges à connaître avant de poser une policy :

• Frais d’accès (data retrieval fee) : les tiers Cool et Cold facturent chaque GB relu, ce qui consomme des CUs proportionnellement au volume lu. Une donnée “froide” requêtée chaque semaine vous coûtera **plus cher** qu’en Hot.

• Pénalité de sortie anticipée (early deletion fee) : si vous changez le tier ou supprimez une donnée **avant** la fin de la rétention minimale (30j Cool / 90j Cold), Fabric vous facture comme si elle était restée jusqu’à la fin de la période.

👉 La règle d’or :

Ne descendez une donnée d’un tier que si vous êtes sûr de ne pas la rappeler souvent ET de ne pas avoir à la remonter avant la fin de la rétention. Le tiering, c’est de la finance, pas juste de la technique.

2. GPU-Accelerated Fabric Data Warehouse : le Warehouse rentre dans l’ère agentique

Pendant des années, le Data Warehouse a été pensé pour un cas d’usage : alimenter des dashboards et des rapports en mode “batch + cache”. Vous lanciez votre Power BI le matin, le cache se réchauffait, et tout roulait jusqu’au soir.

Sauf qu’aujourd’hui, vos utilisateurs ne sont plus seuls. Vos agents IA peuvent poser des questions au Warehouse en continu, chacune impliquant des requêtes complexes, ad-hoc, imprévisibles… Multipliez ça par dix agents en production, et le modèle CPU traditionnel s’écroule.

👉 Microsoft introduit le GPU-Accelerated Fabric Data Warehouse : l’exécution des requêtes peut désormais s’appuyer sur des GPU directement intégrés au Warehouse. Pas de pipeline custom, pas de bascule vers une autre plateforme, l’accélération GPU est nativement disponible dans le moteur du Warehouse.

L’objectif : supporter une nouvelle classe de workloads où chaque requête est dans le chemin critique d’une expérience temps réel : agents conversationnels, applications data-driven, dashboards interactifs sur très gros volumes.

La réalité du terrain

• Le vrai apport : éliminer le compromis historique entre performance, concurrence et complexité. Avant, soutenir 50 agents qui requêtent en parallèle sur des datasets massifs imposait soit un Warehouse hyper-dimensionné (cher), soit une couche de cache custom (complexe). Le GPU absorbe cette charge sans cette gymnastique.

• Convergence opérationnel/analytique : c’est le sous-texte intéressant. Le GPU rapproche le Warehouse d’une vraie plateforme transactionnelle pour les workloads d’agents : un seul moteur pour l’analytique lourde et les interactions applicatives.

• Activation simple ≠ bénéfice automatique : Microsoft positionne CoddSpeed comme “simple à activer”, et c’est vrai côté ops. Mais le paper SIGMOD 2026 publié par l’équipe est sans ambiguïté : le GPU n’accélère que le moteur Fabric Data Warehouse et uniquement sur les requêtes compute-heavy (joins multiples, agrégations lourdes, predicats LIKE). Pour les scan simples, le coût de transfert PCIe peut même rendre la requête plus lente que sur CPU.

  Conséquence pour Power BI :

  - Mode Import : aucun bénéfice (VertiPaq en mémoire, pas de DW).

  - DirectQuery sur Warehouse : bénéfice potentiel, proportionnel à la complexité de la requête SQL générée par le visual :

  - Un visual “card + SUM” : gain négligeable, voire négatif.

  - Un visual avec drill-down multi-joins sur 100 GB+ : gain potentiellement décisif.

💡 Tips : avant d’activer, profilez vos requêtes lourdes (DMV sys.dm_exec_query_stat sur le Warehouse) et justifiez celles qui dépassent quelques secondes. Ce sont elles qui justifient le GPU.

3. Fabric Apps avec le Rayfin SDK (Preview) : un backend complet déployé dans Fabric, en code

Une IA peut générer le frontend d’une app en quelques secondes. Le backend, lui, reste un assemblage manuel : base de données, identité, policies d’accès, APIs, gouvernance. Résultat : un écart énorme entre la vitesse à laquelle on prototype et le temps qu’il faut pour vraiment **livrer**.

Microsoft annonce à Build 2026 Rayfin, un SDK et une CLI open-source qui permettent de définir l’intégralité d’un backend applicatif en code, et de le déployer directement dans Microsoft Fabric. L’app devient un artefact Fabric à part entière, gouverné dès la première seconde.

Pourquoi ?

Le vrai problème que Rayfin attaque, ce n’est pas “comment construire une app plus vite”. C’est l’écart prototype → production :

• Les prototypes sont faciles à construire, difficiles à industrialiser.

• La config backend reste un patchwork de services à câbler manuellement.

• La gouvernance et la compliance arrivent **trop tard** — souvent quand l’app touche enfin la vraie donnée.

• Les données de l’app ne sont pas immédiatement exploitables pour l’analytique et l’IA.

Dans la réalité du terrain, beaucoup d’équipes finissent par re-plateformer l’app pour passer en prod.

Ce qui change concrètement

Rayfin transforme le développement backend en workflow code-first, pilotable de bout en bout par un développeur, ou par un agent de coding en 4 étapes :

1. Définir l’app en code : modèles de données, APIs, policies d’accès, logique métier et connexions aux sources existantes, le tout dans le SDK Rayfin. Le format est structuré et typé, donc un agent (GitHub Copilot, Claude, Cursor…) peut le générer et le refactorer avec autant de fiabilité qu'un humain.

2. Déployer via la CLI : la CLI provisionne tout le backend dans Fabric : DB, authentification, policies, APIs. Pas de setup manuel, pas d’infra à gérer.

3. Tourner comme un artefact Fabric : l’app hérite automatiquement de la gouvernance, de la sécurité et de la compliance de la plateforme. Plus de “shadow app” hors radar.

4. Analyser ses propres données nativement : les données générées par l’app atterrissent dans OneLake, directement utilisables par Power BI, les notebooks, les Data Agents. Pas de pipeline d’export à construire

Dites-moi en commentaire si vous l’avez testé, je suis curieux de vos tests !

🥇 La Règle d’Or

Si tu dois retenir une chose : Fabric de juin 2026, c’est le mois où la plateforme prend au sérieux ce qui se passe après la mise en production. Tiering automatique sur OneLake, GPU pour absorber les workloads IA, et Rayfin pour faire tourner des applications gouvernées à l’intérieur de Fabric. Ce sont des fondations d’exploitation et d’extension, celles qui transforment Fabric d’une plateforme qu’on installe en une plateforme sur laquelle on construit.

L’Impact Terrain : Une équipe data qui maîtrise ses coûts de stockage via le tiering, qui prépare ses architectures aux requêtes d’agents via le GPU, et qui livre des applications gouvernées via Rayfin, c’est une équipe qui passe du statut de “centre de coût” à celui de “fonction stratégique” auprès de sa direction.

Et vous, quelle nouveauté de juin 2026 vous impacte le plus ? Le tiering OneLake pour reprendre le contrôle de votre facture, le GPU Warehouse pour préparer vos workloads agentiques, ou Rayfin pour combler enfin l’écart entre prototype IA et app de prod gouvernée ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Fabric June 2026 Feature Summary

• OneLake storage tiers

• OneLake item-size reporting

• Fabric Apps documentation (Rayfin SDK)

• Introducing Rayfin — annonce officielle

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Après avoir décortiqué Copilot pour Power BI dans ma précédente édition (voir le post ci-dessous), attaquons-nous à Copilot dans Dataflow Gen2 :

Pour rappel, Dataflow Gen2 est la brique de prédilection pour le low-code ETL, permettant d’ingérer, de nettoyer et de charger des données via une interface visuelle familière dans Microsoft Fabric.

Je vois souvent la même limite émerger : quand les règles métier se complexifient et que vous enchaînez des dizaines d’étapes de transformation, personne n’a en tête toutes les fonctions du code M et cela peut se transformer en une dette technique.

Alors, comment accélérer nos traitements ? Peut-on déléguer l’écriture d’une colonne calculée complexe ou générer instantanément l’explication d’une requête héritée et non documentée ?

C’est là que Copilot dans Dataflow Gen2 révèle tout son intérêt. Il agit comme un accélérateur de productivité, avec des cas d’usage pour livrer plus vite et sécuriser vos développements.

Copilot & Dataflow Gen2

Copilot pour Dataflow Gen2 est l’assistant IA intégré directement dans l’interface Dataflow Gen2 de Microsoft Fabric.

Son rôle : générer, expliquer et ajuster des transformations de données en code M (le langage natif de Power Query) à partir de vos instructions en langage naturel.

Voici comment l’exploiter sur le terrain à travers ses trois caractéristiques clés.

1. Générer des étapes de transformation à la volée

Au lieu de fouiller dans les menus ou d'écrire manuellement des fonctions M complexes (comme des pivots, des extractions conditionnelles ou des regroupements), vous décrivez le résultat attendu dans le panneau Copilot. Le moteur traduit votre prompt en une nouvelle étape de transformation appliquée directement à votre flux.

Par exemple, si votre tableau comprend des champs tels que OrderID, Quantity, Category et Total, vous pouvez saisir une description comme celle-ci :

If the Total order is more than 2000 and the Category is B, then provide a discount of 10%. If the total is more than 200 and the Category is A, then provide a discount of 25% but only if the Quantity is more than 10 otherwise just provide a 10% discount

💡 Tips : Soyez précis dans vos prompts. Utilisez les noms exacts des colonnes.

⚠️ Point de vigilance : Attention au Query Folding (la capacité à déléguer le calcul au système source comme une base SQL). Si Copilot génère une fonction M non supportée par la source, la transformation s'exécutera dans le moteur de calcul de Fabric (Mashup engine). Vérifiez toujours vos plans de requêtes pour éviter d'effondrer les performances de votre ingestion.

2. Faire de la rétro-ingénierie et documenter l’existant

Pour faire de la rétro-ingénierie, Copilot propose deux niveaux de lecture interactifs qui agissent comme une véritable Living Documentation générée à la volée :

• Expliquer la requête globale (”Explain this query”) : Accessible via le volet Copilot ou par un simple clic droit sur votre requête dans le panneau latéral. Le moteur lit l’intégralité du code M et génère un résumé global en langage clair de toutes les transformations appliquées de bout en bout.

• Expliquer une étape spécifique (”Explain this step”) : Parfois, le blocage vient d’une seule ligne de code M obscure. Allez directement dans la section des “Étapes appliquées” (Applied steps), faites un clic droit sur l’étape ciblée, et sélectionnez l’option pour que Copilot décrive uniquement cette opération isolée.

💡 Tips : Utilisez ce résumé généré pour créer une véritable Living Documentation. Copiez l’explication fournie par Copilot et collez-la dans les “Propriétés” de la requête. Le prochain ingénieur (ou vous-même dans 6 mois) comprendra instantanément la logique sans avoir à décrypter le code M ligne par ligne.

⚠️ Point de vigilance : Copilot vous explique le Comment (ce que fait le code), mais il n’a aucune idée du Pourquoi (la règle métier sous-jacente). S’il vous dit “Cette étape supprime les lignes avec des valeurs nulles”, il ne vous dira pas que c’est une exigence réglementaire de la comptabilité. Ne laissez pas l’IA remplacer l’encadrement métier de vos artefacts.

3. Générer de nouvelles requêtes et jeux d’essais

Description : Copilot peut créer une requête entièrement nouvelle (from scratch) basée sur un prompt, générer des données factices pour tester une logique, ou créer une requête qui référence une table existante pour l’enrichir sans casser la source.

💡 Tips : C’est le moyen le plus rapide de générer des tables de dimensions standard. Demandez-lui : “Génère une table de calendrier complète allant du 1er Janvier 2020 au 31 Décembre 2025 avec les colonnes Année, Trimestre, Mois et Jour de la semaine”. Vous économiserez 15 minutes de recherche de script M sur internet.

⚠️ Point de vigilance : Le typage des données. Quand Copilot génère une requête from scratch, il laisse parfois les colonnes en type “Any” (Texte/Général). Ne chargez jamais ce résultat tel quel dans votre Lakehouse ou Warehouse : repassez toujours derrière pour forcer le typage strict (Int64, Date, Decimal) afin de ne pas introduire de la dette technique dès la couche d’ingestion.

Les limites de Copilot dans Dataflow Gen2

Je vois souvent des équipes qui découvrent ces points de friction en production. Mieux vaut les anticiper :

• Copilot génère du code mais ne valide pas le résultat.

  Le M code produit peut être syntaxiquement correct et logiquement faux. Si votre règle métier est complexe, Copilot peut interpréter à sa façon et cela peut engendrer des données incorrectes dans l’aperçu.

• Copilot n’est pas activé par défaut.

  L’administrateur Fabric de votre organisation doit avoir activé Copilot au niveau du portail d’administration.

• Copilot consomme des Capacity Units (CU).

  Chaque interaction mobilise du moteur de calcul. Ce n’est pas négligeable dans un environnement où plusieurs utilisateurs exploitent Copilot en parallèle. Surveillez votre Capacity Metrics App si vous déployez Copilot à grande échelle.

• Copilot ne peut pas effectuer de transformations ou d’explications sur plusieurs requêtes dans une seule entrée.

  Par exemple, vous ne pouvez pas demander à Copilot de « Mettre en majuscule tous les en-têtes de colonne pour chaque requête dans mon dataflow ».

4. Au-delà de Copilot : AI Prompt

Copilot accélère la création de votre logique de transformation. Mais pour enrichir le contenu de vos données, Dataflow Gen2 embarque une nouvelle fonctionnalité : les AI Prompt (actuellement en Preview).

Concrètement, vous utilisez des modèles pré-entraînés (basés sur Azure AI) d’IA générative appelables directement via l’interface, sans avoir à créer des modèles ou de gérer l’infrastructure sous-jacente. La réalité du terrain, c'est que l'on a souvent besoin de valoriser de la donnée non structurée.

L’objectif est direct : vous passez une instruction spécifique à votre contexte métier, qui s’exécutera individuellement sur chaque ligne de vos données !

Par exemple, vous pouvez demander à l'IA de :

• Analyse de sentiment : Détecter le ton (positif, négatif, neutre) d’un commentaire client ou d’un retour utilisateur.

• Extraction de mots-clés : Isoler les termes principaux d’un champ texte long.

• Détection de langue : Identifier automatiquement l’idiome d’une colonne (très utile pour router des données internationales).

• Générer du contenu : Résumer l’avis d’un client et formuler automatiquement une proposition de réponse dans sa langue d’origine.

💡 Tips : Si votre prompt fait référence à un ou plusieurs champs spécifiques, assurez-vous d'avoir explicitement sélectionné la ou les colonnes correspondantes dans le menu de configuration de votre AI Prompt.

Matrice de Décision

Q1 : Héritez-vous d’un flux Dataflow Gen2 avec des dizaines d’étapes de transformation non documentées ?

• OUI : Utilisez immédiatement la fonction “Explain this query” de Copilot.

Q2 : Devez-vous implémenter des règles de gestion de calcul très spécifiques ?

• OUI : Utilisez Copilot pour accélérer la création de ces règles de gestion métiers, et valider les résultats.

Q3 : Avez-vous besoin d’extraire des informations de champs textes libres (commentaires, logs) sur votre couche Bronze ?

• OUI : Utilisez les AI Prompts de Dataflow Gen2 pour valoriser cette donnée.

Conclusion

Si tu dois retenir une chose : Copilot dans Dataflow Gen2 est une brique puissante qui ne remplace pas ton expertise d’ingénieur, mais qui te libère de la dette technique pour accélérer la valorisation de la donnée dès l’ingestion.

Ne vous y trompez pas : c’est toujours votre responsabilité de valider le code, de comprendre les règles métier, et de maîtriser ce qui part en production.

Pour une équipe qui embarque des profils métier dans ses projets Fabric, cet assistant supprime la barrière d’entrée technique.

Le résultat concret : moins de tickets IT pour des transformations de premier niveau, plus d’autonomie côté analyste, et des Data Engineers qui peuvent concentrer leur énergie sur les briques d’architecture à haute valeur ajoutée.

Et vous, quel usage faites-vous de Copilot dans vos Dataflows Gen2 ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

• 📘 Vue d’ensemble de Copilot pour Data Factory

• 🛠️ Utiliser les AI Functions et AI Prompts dans Dataflow Gen2

• 🔗 Générer une Living Documentation avec l’explication de requêtes Copilot

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

La sécurité des données dans le cloud ne date pas d’hier, mais voyons comment Microsoft Fabric relève ce défi.

Imaginons un scénario classique : une équipe BI déploie ses rapports Power BI sur la plateforme. Tout fonctionne à merveille, les visuels sont impeccables. Puis vient la question fatidique du DSI :

• “Est-ce que le directeur régional de Bordeaux peut voir les chiffres de Lyon ?”

• “Est-ce que les RH peuvent voir les salaires des cadres dirigeants ?”

• “Comment la sécurité se concrêtise dans la plateforme ?”

La sécurité de la donnée a souvent été pensée en dernier.

Le problème ? On bricole des dizaines de rôles statiques impossibles à maintenir, on accorde des accès temporaires que l’on finit par oublier, ou on duplique les rapports par profil utilisateur. Cette approche devient rapidement ingérable.

La conséquence ? Une dette technique qui explose à chaque évolution du modèle et un risque sécuritaire qui s’accroît.

Dans Fabric, la sécurité fine de la donnée se joue sur plusieurs couches distinctes.

Comprendre laquelle utiliser selon le contexte, c’est ce qui sépare une gouvernance solide d’un château de cartes.

C’est quoi RLS, CLS et OLS dans Fabric ?

Fabric propose trois niveaux de sécurité granulaire sur la donnée, complémentaires et non interchangeables :

Row-Level Security (RLS) - Filtrage par ligne.

• Restreint l’accès aux lignes d’une table selon l’identité de l’utilisateur.

• Le directeur régional de Bordeaux ne voit que les données de sa région.

• Le commercial ne voit que son propre portefeuille clients.

• La donnée existe dans le modèle, l’utilisateur ne voit simplement pas les lignes auxquelles il n’a pas accès.

Column-Level Security (CLS), Masquage par colonne.

• Restreint l’accès à certaines colonnes entières.

• Les colonnes salaire, numéro de sécurité sociale, ou marge nette ne sont tout simplement pas accessibles aux profils non autorisés.

• Disponible sur le SQL Endpoint du Lakehouse, dans le Warehouse, et dans les semantic models via OLS.

Object-Level Security (OLS), Visibilité des objets du modèle.

• Contrôle la visibilité des tables, colonnes et mesures dans un semantic model Power BI.

• Une table ou une mesure “cachée” via OLS n’apparaît tout simplement pas dans le modèle pour les utilisateurs concernés, même les noms ne sont pas visibles.

Ces trois mécanismes ne sont pas redondants. Ils opèrent à des niveaux différents et se complètent selon la couche d’accès concernée.

La réalité du terrain

✅ La sécurité dans Fabric opère en couches, et chaque couche a son périmètre.

• Au niveau OneLake : les rôles RBAC (Object-Level, Row-Level, Column-Level) s’appliquent directement aux données stockées et voyagent avec elles, y compris via les Shortcuts.

• Au niveau SQL Endpoint et Warehouse : RLS, CLS et Dynamic Data Masking configurables via T-SQL.

• Au niveau semantic model Power BI : RLS statique, RLS dynamique, OLS.

Comprendre quelle couche couvre quel moteur d’accès est la première chose à cartographier avant d’implémenter quoi que ce soit.

✅ La sécurité dynamique est votre meilleure alliée contre l’explosion du nombre de rôles.

• L’erreur classique sur le terrain : créer un rôle statique par région, par département, par équipe.

• Résultat : 30 rôles à maintenir, et à chaque réorganisation interne, tout est à refaire. La sécurité dynamique dans les semantic models repose sur les fonctions DAX USERPRINCIPALNAME() ou USERNAME() : elles retournent l’identité de l’utilisateur connecté et filtrent automatiquement les données selon une table de mapping chargée dans le modèle.

Un seul rôle dynamique remplace potentiellement des dizaines de rôles statiques.

✅ OneLake Security sécurise la donnée à la source, quel que soit le moteur qui la consomme.

• C’est le point architectural clé : les rôles définis dans OneLake s’appliquent en pass-through aux moteurs Spark, et via identité déléguée aux SQL Endpoints et semantic models.

• La sécurité définie une fois dans OneLake reste effective que l’utilisateur accède via Power BI, via SSMS, via les REST APIs ou via un outil tiers compatible ADLS Gen2.

✅ Le OneLake Catalog centralise la vue de vos configurations de sécurité.

• L’onglet Secure (en preview) du OneLake Catalog offre une vue centralisée des rôles et permissions à travers vos workspaces et items.

• Vue par utilisateurs, vue par rôles de sécurité, c’est votre tableau de bord d’audit pour vérifier que personne n’a des droits excessifs, et pour appliquer le principe du moindre privilège à l’échelle du tenant.

Points de vigilance

⚠️ Les utilisateurs avec des rôles élevés dans le workspace contournent le RLS et l’OLS.

C’est une limite fondamentale à connaître : seuls les utilisateurs avec le rôle Viewer (lecture seule) sur le semantic model ou le workspace voient la sécurité RLS et OLS appliquée. Les Admin, Member et Contributor voient tout, sans restriction.

Conséquence directe sur le terrain : si vous donnez des droits Contributor à un utilisateur pour qu’il puisse “juste modifier un rapport”, vous lui donnez aussi accès à toutes les données non filtrées.

Attribuez les rôles workspace avec précision, en gardant en tête cette interaction avec la sécurité modèle.

⚠️ La sécurité OneLake ne s’applique pas aux SQL Endpoints et semantic models en mode délégué.

Les SQL Endpoints, semantic models et Warehouses accèdent à OneLake via une identité déléguée, ils ont leur propre couche de sécurité et ignorent les rôles RBAC OneLake.

Si vous sécurisez uniquement au niveau OneLake en pensant couvrir tous les accès, les utilisateurs passant par le SQL Endpoint ou un rapport Power BI contournent cette sécurité.

Les deux couches doivent être configurées de manière cohérente et complémentaire.

⚠️ Dynamic Data Masking n’est pas une vraie sécurité, c’est de l’obscurcissement.

Le masquage des données (email, numéro de téléphone, valeur numérique sensible) peut être contourné par des requêtes ad hoc successives permettant de deviner la valeur masquée par itération.

C’est un outil utile pour limiter la visibilité accidentelle, pas pour protéger des données réellement sensibles.

Ne comptez pas dessus comme unique mécanisme de protection.

⚠️ Les permissions sur les Shortcuts ont leurs propres règles.

Dans OneLake, les permissions doivent être définies sur la table de destination d’un Shortcut, pas sur le Shortcut lui-même.

Définir des droits sur un Shortcut n’est pas supporté.

C’est une subtilité qui passe souvent inaperçue lors de la mise en place d’architectures multi-sources, et qui crée des failles de sécurité involontaires.

Matrice de décision

Q1 : Vos utilisateurs accèdent-ils à la donnée via Power BI uniquement, ou aussi via SQL / Spark / API ?

• Power BI uniquement : RLS et OLS dans le semantic model suffisent pour la couche de consommation.

• Accès multi-moteurs (SQL, Spark, API) : Configurez également la sécurité au niveau OneLake RBAC et SQL Endpoint pour couvrir tous les chemins d’accès.

Q2 : Avez-vous de nombreuses combinaisons de profils d’accès (>5 rôles distincts) ?

• Oui : Sécurité dynamique avec USERPRINCIPALNAME() et table de mapping dans le semantic model. Un rôle dynamique remplace N rôles statiques.

• Non (<5 rôles stables) : Rôles statiques acceptables, plus simples à configurer et à auditer.

Q3 : Avez-vous des colonnes structurellement sensibles (salaires, données personnelles, marges) ?

• Oui : CLS au niveau SQL Endpoint / Warehouse + OLS dans le semantic model pour masquer ces colonnes selon le profil.

• Non : RLS seul couvre votre besoin de filtrage.

Conclusion

Si tu dois retenir une chose : Dans Fabric, la sécurité de la donnée n’est pas une fonctionnalité à activer après coup, c’est une architecture à concevoir en même temps que votre modèle de données.

RLS, CLS, OLS et OneLake RBAC ne se substituent pas : ils se complètent selon le moteur d’accès.

Un seul rôle dynamique bien conçu vaut mieux que vingt rôles statiques impossibles à maintenir.

L’Impact Terrain : Une stratégie de sécurité granulaire bien conçue dans Fabric, c’est la fin des “je vais dupliquer le rapport pour chaque région” et des “on ne peut pas partager ce dashboard parce qu’il contient des données confidentielles”.

Chaque utilisateur voit exactement ce qu’il doit voir à travers un modèle unique, maintenu une seule fois, c’est l’idée du One Security qui va s’annoncer au fur et à mesure dans la plateforme.

C’est aussi ce qui rend possible le self-service BI à grande échelle : quand la sécurité est structurelle et non contournable, vous pouvez ouvrir l’accès aux données sans craindre les fuites.

La confiance des métiers dans la plateforme se construit sur cette garantie.

Question : comment avez-vous structuré la sécurité dans Fabric ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles :

• Sécurité dans Microsoft Fabric

• Sécuriser les données dans OneLake

• Sécurité au niveau des lignes (RLS) avec Power BI

• Sécurité au niveau des objets (OLS)

• Masquage dynamique des données dans Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie, sans le jargon inutile.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

La semaine dernière, nous avons vu comment mettre en place un Deployment Pipeline pour fluidifier le passage entre vos espaces de travail. Aujourd’hui, passons à l’étape supérieure : l’automatisation des sources de données.

Mon objectif est simple : je veux que mes données pointent automatiquement vers le bon Lakehouse selon l’environnement, sans aucune intervention manuelle après le déploiement.

• En DEV, j’ingère des extraits réduits ou anonymisés dans mon Lakehouse de développement.

• En TEST, je valide les performances sur des volumes réels dans mon Lakehouse de recette.

• En PROD, je sécurise l’accès aux données critiques dans le Lakehouse en production.

Problème :

• comment gérer les chaînes de connexion “hardcodées” dans les pipelines, les notebooks ou les Dataflows Gen2 ?

• Peut-on utiliser une bibliothèque pour centraliser nos variables d’environnement dès le départ ?

Dans Microsoft Fabric, l’erreur du “hardcoding” est plus fréquente qu’on ne le croit. La plateforme rend le développement si fluide et rapide qu’on est souvent tenté de brûler les étapes au détriment des bonnes fondations.

Aujourd’hui, nous allons voir comment la Variable Library permet de résoudre ce problème et d’industrialiser vos déploiements.

Variable Library

La Variable Library est l’objet dans Microsoft Fabric qui a pour but de centraliser des paramètres typés au niveau du workspace.

L’idée est simple :

1. vous définissez une fois vos paramètres (Variables) de vos items comme le nom de l’item, l’URL de source de données, le chemin de fichier, le nom des tables…,

2. vous créez plusieurs jeux de valeurs (value sets) correspondant à vos environnements (DEV, TEST, PROD),

3. et vous activez le jeu approprié selon l’environnement.

Quand vous exécutez le Deployment Pipeline, cela propage vos items entre différents environnements, et la Variable Library voyage avec eux et vous n’avez plus qu’à activer le bon jeu de valeurs dans le workspace cible !

La réalité du terrain

✅ La Variable Library supporte le versioning Git natif.

Depuis sa disponibilité, Microsoft a appliqué le principe qu’il a adopté fin 2024 : tout nouveau item Fabric doit supporter Git dès le premier jour.

La Variable Library est synchronisable avec votre repository Azure DevOps ou GitHub. Vos paramètres sont traçables, versionnés, et comparables entre branches comme n’importe quel item Fabric.

✅ Elle remplace avantageusement les Deployment Rules pour la majorité des cas.

Les Deployment Rules existent depuis plus longtemps dans Fabric, mais leur périmètre est limité et leur maintenabilité laisse à désirer sur des projets complexes.

La Variable Library est plus flexible, plus lisible, et conçue pour durer. Pour tout nouveau projet, partez directement sur la Variable Library.

✅ Trois mécanismes de paramétrage coexistent dans Fabric, et chacun a son rôle.

Les Deployment Rules pour les reconfiguration automatiques sur quelques items ciblés.

La Variable Library pour la centralisation et la réutilisation de paramètres à l’échelle du workspace.

L’Autobinding pour les liens entre items du même workspace (rapports ↔ semantic models, pipelines ↔ pipelines).

Comprendre lequel utiliser selon le contexte vous évite de mélanger les approches.

Points de vigilance

⚠️ Tous les items Fabric ne consomment pas encore la Variable Library nativement.

À ce jour, seuls les Pipelines, Notebooks, Copy Jobs, Dataflows Gen2 et Shortcuts peuvent consommer directement les paramètres de la Variable Library.

Pour les autres items, vous devez gérer la configuration via les Deployment Rules ou manuellement. Le support de nouveaux items est attendu progressivement, vérifiez la documentation officielle avant de concevoir votre stratégie de paramétrage.

🥇Cas particulier du Dataflow Gen2 : la destination de données ne passe pas par la Variable Library.

La destination via Dataflow Gen 2 est gérée via Git : le fichier de définition du Dataflow stocké dans votre repository contient la configuration de destination, et c’est ce fichier que vous modifiez selon l’environnement cible lors du déploiement.

⚠️ L’activation du bon jeu de valeurs n’est pas automatique lors du déploiement.

Vous déployez de DEV vers PROD via le Deployment Pipeline, la Variable Library arrive bien dans PROD, mais le jeu de valeurs actif est toujours celui de DEV.

L’activation du jeu de valeurs PROD doit être faite manuellement via l’interface, ou automatisée via les APIs Fabric.

⚠️ Ne confondez pas la Variable Library avec la gestion des secrets.

La Variable Library n’est pas un coffre-fort. Ne stockez pas de mots de passe, de tokens d’API ou de clés d’accès dedans.

Pour les secrets, utilisez Azure Key Vault et référencez-les dans vos connexions Fabric. La Variable Library gère les paramètres de configuration (noms de serveurs, chemins, URLs) — pas les credentials.

Nouveauté (Janvier 2026) !

La Variable Library continue d’évoluer et cette fonctionnalité change la donne pour la gestion multi-environnements. Modifier manuellement les connexions après chaque déploiement était une tâche longue et fastidieuse !

La variable de référence d’élément (Item Reference Variable) est là pour ça.

C’est un type de variable qui ne stocke pas une valeur de type texte, mais une référence complète vers un objet Fabric (Lakehouse, Notebook, Pipeline, etc.).

• Elle conserve automatiquement l’ID de l’espace de travail (Workspace ID) ET l’ID de l’élément (Item ID).

• Plus besoin de “hardcoder” vos liens. Vos développements pointent dynamiquement vers le bon élément selon l’environnement où ils se trouvent.

• Lors du passage en production, vos pipelines et notebooks s’adaptent automatiquement au contexte de l’espace de travail cible.

Vous construisez une fois, et la Variable Library s’occupe de maintenir la cohérence de vos connexions tout au long de la chaîne de déploiement..

Mon conseil

Si vous avez déjà débuté votre projet sur Microsoft Fabric, la première étape est un faire un audit de vos items.

Passez en revue chaque Pipeline, Notebook, Dataflow Gen2 ou d’autres items, et listez toutes les valeurs configurées en dur : chaînes de connexion, noms de serveurs, chemins de fichiers, URLs, noms de lakehouses...

Chaque valeur identifiée devient un paramètre candidat dans votre Variable Library. Remplacez-les ensuite une par une, en testant après chaque modification — ne migrez pas tout d’un coup sans vérifier.

Matrice de décision

Q1 : Avez-vous plusieurs environnements (DEV/TEST/PROD) avec des sources de données différentes ?

• Oui : Variable Library obligatoire. Créez vos jeux de valeurs par environnement dès le départ.

• Non (workspace unique) : Les paramètres internes aux items suffisent pour un PoC. Mais anticipez la Variable Library si le projet doit évoluer.

Q2 : Avez-vous des secrets ou credentials à gérer en plus des paramètres de configuration ?

• Oui : Azure Key Vault pour les secret, Variable Library pour les paramètres de configuration. Ne mélangez pas les deux.

Conclusion

Si tu dois retenir une chose : Utilisez une Variable Library pour centraliser tous les paramètres de votre espace de travail. En activant le jeu de valeurs correspondant à chaque environnement, vous facilitez le passage en production et sécurisez vos flux de données.

L’impact sur le terrain : Une gestion des variables bien structurée, c’est la fin des post-mortems du type : « On envoyait les données de PROD dans la base de DEV depuis trois jours sans s’en rendre compte ».

• Vos Data Engineers développent avec des paramètres propres dès le premier jour.

• Vos déploiements sont répétables et prévisibles.

• Et votre équipe d’astreinte n’a plus à éplucher le code d’un pipeline à 2h du matin pour trouver une connexion hardcodée qui pointe au mauvais endroit.

C’est transformer le déploiement d’un acte artisanal en un processus industriel, sans sacrifier la lisibilité ni la maintenabilité du code.

De votre côté, utilisez-vous déjà la Variable Library ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, voici les documentations officielles indispensables :

• Prise en main - Variable Library

• Vue d'ensemble - Variable Library

• Tutoriel - Variable Library

• CI/CD - Variable Library

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

J’ai accompagné des clients qui ont commencé une preuve de concept (PoC) sur Microsoft Fabric et qui souhaitent désormais passer leur implémentation en production de manière fluide.

Le problème que j’ai souvent rencontré est que, lors d’un PoC, tout le monde développe dans le même espace de travail (workspace) : développeurs, analystes… le tout sans véritable gestion des droits. Le but est alors de valider la faisabilité, les bénéfices et d’identifier les potentielles limites par rapport aux besoins.

C’est une étape nécessaire, mais un contexte de production exige d’aller plus loin.

• Quelles sont les bonnes pratiques et les outils disponibles pour pérenniser un pipeline ou l’ajout d’une nouvelle source de données ?

• Comment gérer la modification simultanée de notebooks sans générer de conflits ?

• Si le rapport destiné à la direction comporte plusieurs versions, comment identifier celle qui est à jour et s’appuie sur des données fiables ?

La réalité du terrain, c’est que la plupart des blocages ne viennent pas de la technologie. Ils viennent de l’absence de chaîne DEV → TEST → PROD pensée dès le départ.

Voyons ensemble comment Fabric vous donne les briques pour passer d’un workspace unique partagé à un pipeline de déploiement maîtrisé, sans repartir de zéro.

Deployment Pipeline

Le Deployment Pipeline dans Microsoft Fabric est un mécanisme natif qui permet de promouvoir des items d’un environnement à l’autre, typiquement de DEV vers TEST, puis de TEST vers PROD, de manière contrôlée, répétable, et sans copier-coller.

Avoir un seul environnement pour le PoC c’est bien, mais en avoir plusieurs permet d'isoler les risques et de garantir que l'innovation ne se fasse jamais au détriment de la fiabilité.

Concrètement, comment cela fonctionne-t-il ?

• Un pipeline est composé d’étapes (stages), pouvant aller de 2 à 10. Si la configuration DEV → PROD est le minimum viable, l’enchaînement DEV → TEST → PROD reste le standard d’or en entreprise.

• Un stage = un workspace : Chaque étape du pipeline est strictement liée à un espace de travail (Workspace) Fabric dédié.

Que se passe-t-il exactement lors d’un déploiement ?

Le but est de propager vos développements d’une étape à la suivante. Le fonctionnement repose sur un moteur de comparaison visuelle. Par exemple, lorsque vous souhaitez passer de DEV à TEST, Fabric analyse les différences entre les deux espaces de travail. Il vous indique précisément quels items (Lakehouses, Notebooks, Reports, Semantic Models) sont nouveaux, modifiés ou identiques.

✅ Ce qui est copié (ou mis à jour) :

• Le code, les structures, les dossiers et les métadonnées (Notebooks, modèles sémantiques, rapports...).

• Le lien entre les éléments (Autobinding) : si un rapport est lié à un modèle de données en DEV, Fabric remappe automatiquement cette connexion vers le modèle équivalent lors du passage en TEST ou en PROD.

❌ Ce qui n’est pas copié lors du déploiement :

• La donnée elle-même : Le pipeline déploie la logique et l’architecture, pas la data.

• Les URL et les ID des éléments : Lorsqu’un rapport existant est mis à jour en PROD, son URL reste identique. Vos utilisateurs finaux ne verront pas leurs favoris cassés à chaque mise en production !

• Les permissions : Les droits d’accès définis sur le workspace de PROD ne sont pas écrasés par ceux de DEV. Chaque environnement conserve sa propre gouvernance et sa sécurité.

• Les paramètres du workspace et les signets personnels (bookmarks).

💡 Tips : Pour éviter de modifier manuellement vos sources de données lors du passage de DEV à PROD, Fabric permet de configurer des règles de déploiement et de s'appuyer sur une Variable Library. Ainsi, votre pipeline sait automatiquement qu’il doit pointer vers la base de données de production une fois l’étape franchie.

La réalité du terrain

✅ La comparaison entre environnements est l’une des fonctionnalités les plus utiles.

Avant chaque déploiement, Fabric affiche côte à côte le code source (DEV) et le code cible (PROD), avec les lignes modifiées en rouge et les ajouts en vert.

✅ La Variable Library est votre meilleur allié pour gérer les ID des éléments.

C’est un item Fabric qui centralise les paramètres au niveau du workspace (chaînes de connexion, noms de sources…) avec plusieurs jeux de valeurs selon l’environnement.

Quand vous déployez, la Variable Library suit. Vous activez simplement le bon jeu de valeurs pour le stage cible. Actuellement compatible avec les Pipelines, Notebooks, Copy Jobs, Dataflows Gen2 et Shortcuts. D’autres items sont attendus. (Info : Un post arrive la semaine prochaine sur ce sujet) !

✅ L’Autobinding évite les liens brisés entre items du même workspace.

Hérité des deployment pipelines Power BI, ce mécanisme relie automatiquement les items interdépendants dans le workspace cible — par exemple un rapport et son semantic model, ou un pipeline qui en appelle un autre.

✅ Git integration (Azure DevOps ou GitHub) est le socle du développement collaboratif.

Fabric supporte nativement la synchronisation de vos workspaces avec un repository Git.

Chaque développeur peut créer une feature branch, qui génère automatiquement un workspace isolé pour qu’il travaille sans perturber ses collègues.

Une fois son développement terminé, il crée une pull request pour merger dans la branche principale. Propre, traçable, collaboratif.

Points de vigilences

⚠️ Un workspace ne peut appartenir qu’à un seul deployment pipeline, quel que soit le stage.

Si vous avez créé votre pipeline en oubliant un workspace, vous ne pouvez pas modifier les stages après coup. La seule option est de supprimer et recréer le pipeline.

Planifiez votre arborescence de workspaces avant de créer vos pipelines.

⚠️ Le nombre de stages est figé à la création du pipeline.

Vous ne pouvez pas ajouter ou supprimer un stage après avoir créé le pipeline.

Si votre organisation décide d’ajouter un environnement UAT entre TEST et PROD six mois après le lancement, vous recommencez depuis zéro.

Anticipez vos besoins d’environnements dès le départ.

⚠️ L’Autobinding agit en silence — ce qui peut compliquer le debug.

Parce qu’il ne laisse pas de traces visibles dans l’historique de déploiement, quand quelque chose se casse après un déploiement, l’Autobinding est souvent le suspect invisible.

Le cas classique : le lakehouse par défaut assigné à un notebook n’est pas mis à jour par l’Autobinding.

Il faut le gérer via une règle de déploiement ou la Variable Library explicitement.

⚠️ Tous les items Fabric ne sont pas supportés par les deployment pipelines.

Certains items restent incompatibles avec le déploiement natif.

Pour ces cas, il faut se tourner vers des solutions externes : Azure DevOps Pipelines ou GitHub Actions couplés à des outils comme la Fabric CLI, la librairie Python fabric-cicd (publiée par Microsoft), ou les Fabric REST APIs.

Ces approches ne sont pas des fonctionnalités natives Fabric — ce sont des stratégies d’automatisation externe.

À budgéter en effort si votre stack inclut des items non supportés. Vérifiez la liste à jour sur la documentation officielle.

Mon conseil

L’erreur classique sur le terrain est de vouloir configurer les Deployment Pipelines avant même d’avoir mis en place Git.

Résultat : on déploie du code non versionné, non traçable, et personne ne peut répondre à la question “qu’est-ce qui a changé entre la version d’hier et aujourd’hui ?”

La bonne séquence est la suivante :

• D’abord, connectez votre workspace DEV à un repository Git (Azure DevOps ou GitHub) et imposez le workflow par pull request.

• Ensuite, une fois que votre équipe maîtrise le versioning, configurez vos Deployment Pipelines pour automatiser la promotion DEV → TEST → PROD.

• Et enfin, gérez vos configurations multi-environnements via la Variable Library pour éviter les erreurs de connexion entre stages.

Git est le fondement. Les Deployment Pipelines sont l’automatisation qui vient au-dessus.

Matrice de décision

Q1 : Votre équipe est-elle composée d’un seul développeur ou d’une équipe ?

• Seul : Un workspace DEV + PROD avec Deployment Pipeline natif suffit. Git reste recommandé pour la traçabilité.

• Équipe : Git integration obligatoire avec workflow par feature branches et pull requests. Deployment Pipeline natif pour la promotion entre environnements.

Q2 : Avez-vous des items non supportés par les Deployment Pipelines natifs ?

• Non : Les Deployment Pipelines natifs Fabric + Variable Library couvrent votre besoin.

• Oui : Complétez avec Azure DevOps Pipelines / GitHub Actions + fabric-cicd ou Fabric CLI pour les items hors scope natif.

Q3 : Avez-vous des configurations différentes entre DEV, TEST et PROD (sources de données, paramètres de connexion) ?

• Oui : Configurez la Variable Library sur chaque workspace avec des jeux de valeurs dédiés par environnement. N’utilisez pas les Deployment Rules pour ça — la Variable Library est plus flexible et maintenable.

• Non : Le déploiement natif sans paramétrage avancé est suffisant.

Conclusion

Si tu dois retenir une chose : Pour passer d’un simple PoC à une mise en production fluide, les Deployment Pipelines natifs de Fabric sont des alliés puissants. Cependant, leur succès repose sur une configuration réfléchie : le nombre d’étapes, l’utilisation des Deployment Rules et des Variables Libraries, ainsi que l’intégration Git pour le contrôle de version.

L’impact sur le terrain : une chaîne DEV → TEST → PROD bien configurée dans Fabric, c’est la fin des déploiements manuels.

• Vos Data Engineers travaillent en parallèle sans se bloquer.

• Vos QA valident sur un environnement TEST avec des données représentatives.

• Votre PROD reste stable.

C’est transformer une plateforme de PoC en environnement de production fiable.

Et vous, comment déployez-vous en production ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles :

• Vue d'ensemble des Deployment Pipelines dans Fabric

• Intégration Git avec Microsoft Fabric

• Créer des règles de déploiement (Deployment Rules & Autobinding)

• Bien démarrer sur les Deployment Pipelines dans Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Combien de fois avez-vous dû basculer entre le portail Fabric dans votre navigateur, VS Code pour votre code, et un terminal pour debugger un job qui a planté à 3h du matin ? La réalité du terrain, c’est que le workflow quotidien d’un Data Engineer sur Fabric reste encore fragmenté entre trop d’interfaces.

Ce mois d’avril 2026, Microsoft pose des briques qui vont directement impacter votre productivité de développeur. Pas de marketing, on verra ensemble quelques améliorations concrètes pour ceux qui écrivent du code, orchestrent des jobs et maintiennent des environnements en production.

Mon objectif aujourd’hui n’est pas de vous lister toutes les features du mois, mais de me concentrer sur TROIS fonctionnalités qui vont avoir un impact immédiat sur votre workflow de développement dans Fabric. C’est parti !

1. VS Code devient le cockpit Fabric : Workspace, Environment et Lakehouse en un seul endroit

Je vois souvent des Data Engineers qui alternent entre le portail web Fabric pour naviguer dans leurs workspaces, et VS Code pour écrire du code. Chaque modification dans l’un nécessite un rafraîchissement dans l’autre.

• Les Environments Spark ? Configurés dans le portail.

• Le Lakehouse par défaut du Notebook ? Changé dans le portail.

• Le code ? Écrit dans VS Code.

C’est un va-et-vient permanent.

Ce qui change

L’extension Fabric Data Engineering pour VS Code reçoit trois capacités majeures en un seul mois :

a. Gestion multi-workspace dans VS Code

Vous pouvez désormais ajouter plusieurs workspaces Fabric dans une seule fenêtre VS Code. Les artefacts Data Engineering (Notebooks, Lakehouses, Environments) apparaissent dans l’explorateur, et les modifications de code se synchronisent automatiquement avec le workspace distant. Plus besoin d’ouvrir un navigateur pour voir vos items.

b. Environment Spark éditable depuis VS Code

L’extension affiche vos Environments sous un nœud dédié. Un clic droit > Inspect Environment ouvre les paramètres en lecture seule au format YAML. Un clic droit > Edit Environment ouvre un YAML éditable pour modifier vos bibliothèques Spark, sauvegarder, et les changements seront synchronisés.

c. Lakehouse par défaut configurable

Vous pouvez ajouter, supprimer et même définir un lakehouse par défaut dans un notebook. Dans l’arborescence VS Code, vous dépliez Dependencies > Lakehouses, clic droit sur le Lakehouse souhaité, Set as Default Lakehouse. Synchronisation immédiate.

La réalité du terrain

✅ L’impact principal : votre VS Code devient le point d’entrée unique pour le développement Fabric. Vous ne quittez plus votre IDE pour naviguer, configurer ou modifier vos artefacts. C’est un vrai gain de flow, ce temps que vous passiez à chercher l’onglet du portail, vous le passez à coder.

✅ La synchronisation bidirectionnelle est le point clé. Ce n’est pas une copie locale : les modifications dans VS Code remontent directement au workspace distant. Si un collègue modifie un Notebook dans le portail, vous le voyez dans VS Code.

✅ Maven support dans les Environments (Preview) : en parallèle, Fabric supporte désormais l’ajout de bibliothèques via des repositories Maven. Les développeurs Scala et Java peuvent importer/exporter des fichiers pom.xml directement dans un Environment, sans télécharger de JARs manuellement.

⚠️ Point de vigilance : La synchronisation automatique du code signifie que chaque sauvegarde dans VS Code modifie le Notebook distant. Sur vos workspaces de production, assurez-vous d’avoir mis en place un pipeline de déploiement (ou Git integration) avant d’utiliser cette extension. La règle terrain : VS Code en mode Remote sur DEV uniquement. Pour la PROD, passez par votre CI/CD.

2. Retry Policy dans les Notebooks : La résilience qui manquait

Avez-vous déjà eu un job Notebook qui échoue à 4h du matin parce que le cluster Spark a été recyclé ? Vous arrivez le matin, vous découvrez l’échec, vous relancez manuellement, vous perdez une demi-journée de données fraîches pour vos utilisateurs métier.

La réalité du terrain, c’est que les erreurs système transitoires sur Spark sont inévitables. Recyclage de cluster, timeout réseau, instabilité temporaire, ce n’est pas une question de “si”, mais de “quand”. Et jusqu’ici, Fabric n’offrait aucun mécanisme natif de retry pour les Notebooks.

Ce qui change

Fabric Notebook supporte désormais une politique de retry configurable. Quand un job Notebook échoue suite à une erreur système, il redémarre automatiquement sur un nouveau cluster sans intervention manuelle.

La configuration se fait via le %%configure :

Ce setup relance le Notebook jusqu’à 3 fois après un échec, avec environ 120 secondes entre chaque tentative. Si le job échoue après 3 tentatives, l’exécution est annulée.

La réalité du terrain

✅ Erreurs système uniquement : le retry ne couvre que les erreurs système (cluster recyclé, infrastructure instable). Si votre code a un bug Python ou une erreur DAX, le retry relancera le même code bugué 3 fois, ce qui ne sert à rien. Vérifiez que vos Notebooks sont idempotents avant d’activer le retry.

✅ Intégration Pipeline : si votre Notebook est appelé dans un Pipeline Data Integration, le retry du Notebook se déclenche avant le retry du Pipeline. C’est un double filet de sécurité : le Notebook retente d’abord, et si tout échoue, le Pipeline peut prendre le relais avec ses propres règles de retry.

⚠️ Point de vigilance : Un retry sur un Notebook non-idempotent peut créer des données dupliquées. Si votre Notebook insère des lignes sans vérification de doublons (pas de MERGE/Upsert), un retry après un échec partiel va réinsérer les données déjà écrites. La règle terrain : pas de retry sans idempotence. Assurez-vous que vos opérations d’écriture utilisent un MERGE INTO ou un INSERT OVERWRITE.

3. Eventhouse Remote MCP (Preview) : Vos agents IA connectés au temps réel

Le Model Context Protocol (MCP) est en train de devenir le standard pour connecter les agents IA à des sources de données. Mais jusqu’ici, connecter un agent à vos données temps réel dans Fabric nécessitait du code custom, des API REST, et beaucoup de plomberie.

Ce qui change

Microsoft lance un serveur MCP distant hébergé pour Eventhouse. Concrètement : vous pointez votre agent IA vers l’endpoint de votre Eventhouse, et il peut immédiatement :

- Découvrir les schémas de vos tables KQL

- Générer des requêtes KQL en langage naturel

- Échantillonner les données pour comprendre leur structure

- Retourner des insights sur des données temps réel et historiques

Pas d’installation locale. Pas de serveur à maintenir. L’agent se connecte directement à votre Eventhouse via le MCP hébergé par Fabric.

La réalité du terrain

✅ Intégration native avec les plateformes d’agents : GitHub Copilot, Copilot Studio, Azure AI Foundry. Votre agent conversationnel peut poser des questions à vos données IoT, logs applicatifs ou flux transactionnels en temps réel sans quitter son interface.

✅ Le cas d’usage concret : vous supervisez une usine avec des capteurs IoT ingérés via Eventstream dans un Eventhouse. Vous connectez un agent IA via MCP, et un opérateur terrain peut demander en langage naturel : “Quels capteurs ont dépassé le seuil de température dans les 30 dernières minutes ?” L’agent génère le KQL, exécute la requête, et retourne la réponse, en quelques secondes.

✅ Sécurité : la connexion passe par l’authentification Fabric standard. L’agent n’accède qu’aux données auxquelles l’utilisateur connecté a droit. Pas de contournement de la sécurité.

⚠️ Point de vigilance : MCP est en Preview. Le protocole évolue rapidement et les breaking changes sont possibles. Ne déployez pas un workflow critique en production basé uniquement sur MCP aujourd’hui. Utilisez-le pour des PoC et des démonstrations de valeur auprès de vos équipes métier.

🥇 La Règle d’Or

Si tu dois retenir une chose : Fabric d’avril 2026 n’est pas un mois de grandes annonces spectaculaires. C’est un mois de fondations pour les développeurs, VS Code qui devient un vrai cockpit, des Notebooks résilients qui ne vous réveillent plus la nuit, et des agents IA connectés nativement à vos données temps réel. Ce sont ces briques “invisibles” qui font la différence entre une plateforme de démo et une plateforme qu’on exploite en production.

Et vous, quelle fonctionnalité allez-vous tester en premier ? L’extension VS Code pour ne plus quitter votre IDE, ou le retry Notebook pour sécuriser vos jobs nocturnes ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

- [Fabric April 2026 Feature Summary]

- [Manage Fabric workspace inside VS Code]

- [Manage Spark Environment inside VS Code]

- [Eventhouse MCP]

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Combien de temps passez-vous à reformater vos rapports Power BI chaque fois que vous créez un nouveau projet ? Ajuster les couleurs, recaler les tailles de canvas, reconfigurer les styles de tables… La réalité du terrain, c’est que beaucoup de créateurs de rapports perdent un temps considérable sur du formatage au lieu de se concentrer sur la valorisation de la donnée.

Ce mois d’avril 2026, Microsoft s’attaque frontalement à ce problème avec des améliorations qui vont changer la façon dont vous construisez vos rapports au quotidien.

Mon objectif aujourd’hui n’est pas de vous lister toutes les features du mois, mais de me concentrer sur 3 fonctionnalités “Reporting” qui vont avoir un impact immédiat sur votre productivité dans Power BI Desktop. C’est parti !

1. Card Visual : L’interactivité que vous attendiez

Je vois souvent des rapports où le Card visual, devenu GA depuis novembre 2025, est utilisé comme un simple afficheur de KPIs statiques. Vous posez vos métriques clés en haut de page, et c’est tout. Le potentiel interactif du visuel est complètement sous-exploité.

Ce qui change

Microsoft enrichit le Card visual avec des mises à jour qui le transforment en un véritable composant interactif :

• Feedback visuel sur la sélection de catégorie : lorsque vous cliquez sur un header de catégorie, la carte sélectionnée s’illumine tandis que les autres s’estompent. Fini l’ambiguïté sur “qu’est-ce que je suis en train de filtrer ?”

• Concaténation automatique : si vous ajoutez plusieurs colonnes de données dans le champ catégorie, les valeurs se concatènent proprement dans le header. Plus besoin de créer une colonne calculée pour combiner `Ville` et `Région`.

• Edit Interactions : vous pouvez désormais contrôler précisément quels visuels de la page sont filtrés quand l’utilisateur clique sur une carte. C’est le même mécanisme que sur les graphiques, enfin disponible sur les Cards.

• Support images base64 : les images encodées en base64 s’affichent correctement au niveau supérieur. Si vous alimentez vos cartes avec des images stockées dans vos données (logos produits, photos d’articles), elles apparaissent sans conversion supplémentaire.

La réalité du terrain

✅ Le scénario qui change tout : imaginez un dashboard exécutif avec 5 cartes affichant le CA par région. L’utilisateur clique sur “Nord-Est” : la carte se met en surbrillance, les 4 autres s’estompent, et tous les graphiques de la page se filtrent automatiquement. C’est de la navigation contextuelle native, sans boutons, sans slicers, sans bookmarks.

✅ Edit Interactions est un game-changer discret. Jusqu’ici, un clic sur une carte filtrait systématiquement tous les visuels de la page. Maintenant, vous pouvez décider que le clic ne filtre que le graphique de tendance et la table de détails, sans toucher au KPI global en haut de page.

⚠️ Point de vigilance : La fonctionnalité Edit Interactions sur le Card n’est pas rétroactive. Si vous avez des rapports existants avec des Cards, les interactions par défaut restent à “tout filtrer”. Passez en revue vos dashboards existants pour configurer les interactions visuelles souhaitées, surtout si certains KPIs de synthèse ne doivent jamais être filtrés.

2. Modern Visual Defaults & Theme Switcher (Preview) : La fin du formatage artisanal

La réalité du terrain, c’est que la majorité des créateurs de rapports Power BI partent d’une page blanche et reformatent chaque visuel manuellement. Les couleurs par défaut ne correspondent pas à la charte, les tailles de canvas sont approximatives, et les tables n’ont ni banded rows ni boutons d’expansion.

Résultat ? Des heures perdues en formatage, et des rapports visuellement incohérents d’un projet à l’autre.

Ce qui change

Microsoft introduit le thème de base Fluent 2(en Preview) et enrichit considérablement le dialogue Customize current theme :

- Base theme switcher : directement dans le dialogue Customize current theme (View > Themes), vous pouvez maintenant basculer entre trois thèmes de base : Fluent 2 (Preview), Classic 2026 et Classic 2018. Si votre thème personnalisé ne fonctionne pas encore avec les nouveaux defaults, vous revenez au précédent le temps de l’ajuster.

- Preset canvas sizes : des tailles de canvas prédéfinies par ratio d’aspect. Pour le 16:9, vous choisissez directement entre HD (1280×720), Full HD (1920×1080), QHD (2560×1440) et 4K UHD (3840×2160). Plus besoin de deviner les bonnes dimensions.

- Reset to default repensé : le tile “Reset to default” est désormais visuellement distinct dans la galerie de thèmes. Fini la confusion entre “appliquer un thème” et “réinitialiser toute la mise en forme”.

La réalité du terrain

✅ Fluent 2 change le point de départ. Avec ce nouveau thème de base, les nouvelles pages démarrent en 1920×1080 (au lieu de 1280×720), le fond est gris clair pour un meilleur contraste, et tous les visuels partagent des polices, paddings et bordures uniformes. Vous partez d’une base visuellement propre sans rien configurer.

✅ L’impact sur les rapports existants : vos rapports actuels ne changent pas automatiquement. La mise à jour est volontaire : ouvrez le dialogue Customize current theme, un bandeau vous invite à “Update theme”. Vous décidez quand migrer.

✅ Les style presets par type de visuel sont un gain de temps considérable. Les graphiques offrent des presets (Default, Data Labels) et les line charts utilisent des courbes lissées par défaut avec des variations en un clic.

💡 Tips: Activez la Preview dans Power BI Desktop (Options > Preview features > Modern visual defaults). Créez un rapport test avec vos visuels habituels pour évaluer le rendu Fluent 2 avant de migrer vos rapports de production. Exportez ensuite votre thème personnalisé en JSON pour le réutiliser sur tous vos projets, c’est la meilleure façon de standardiser l’apparence de vos rapports à l’échelle de l’équipe.

3. Narrative Visual : Copilot par défaut et 10 000 caractères

Avez-vous déjà ajouté un visuel Narrative (Smart Narrative) dans un rapport, pour être accueilli par un choix entre “Copilot” et “Custom” sans trop savoir lequel prendre ? L’erreur classique sur le terrain : les créateurs de rapports choisissent “Custom”, écrivent manuellement leur résumé, et passent à côté de la puissance de l’IA générative.

Ce qui change

Deux améliorations qui simplifient radicalement l’expérience :

• Copilot mode par défaut : si l’utilisateur dispose d’une licence Copilot, le visuel Narrative s’ouvre désormais directement en mode Copilot. Plus besoin de choisir, l’IA prend la main immédiatement pour générer un résumé contextuel de votre rapport.

• Limite de caractères augmentée à 10 000 : la précédente limite était un frein pour les rapports complexes nécessitant des narratifs détaillés. Avec 10 000 caractères, vous pouvez rédiger des prompts plus riches et obtenir des résumés plus complets.

• Les créateurs peuvent toujours basculer entre les modes Copilot et Custom à tout moment. Aucune fonctionnalité n’est retirée, c’est le comportement par défaut qui devient plus intelligent.

La réalité du terrain

✅ L’impact sur l’adoption : en mettant Copilot par défaut, Microsoft élimine la friction initiale. Je vois souvent des équipes qui n’utilisent pas le Narrative Visual simplement parce qu’elles ne savaient pas qu’un mode IA existait. Maintenant, c’est le premier écran qu’elles voient.

✅ Les 10 000 caractères changent la donne pour les prompts avancés. Vous pouvez désormais écrire des instructions détaillées : “Résume les tendances de vente par région, mets en avant les écarts supérieurs à 10% par rapport au mois précédent, et identifie les 3 produits avec la plus forte croissance.” Ce niveau de détail était impossible avec l’ancienne limite.

⚠️ Point de vigilance : Le mode Copilot par défaut nécessite une licence Copilot active. Sans licence, le visuel s’ouvrira en mode Custom comme avant. Vérifiez la couverture de licences dans votre tenant avant de former vos équipes sur cette fonctionnalité, vous éviterez la frustration du “ça ne marche pas chez moi”.

Conclusion

Si tu dois retenir une chose : Power BI Desktop n’est plus un outil où l’on passe la moitié de son temps à formater et l’autre moitié à modéliser.

Avec Fluent 2, les Card interactifs, le Narrative Copilot par défaut et les colonnes calculées Direct Lake, Microsoft rapproche Power BI de ce qu’il devrait être depuis le début, une plateforme où vous vous concentrez sur la valorisation de la donnée, pas sur la mise en forme.

Et vous, quelle fonctionnalité allez-vous activer en premier ? Le thème Fluent 2 pour standardiser tous vos rapports, ou les Cards interactifs pour repenser la navigation de vos dashboards ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

- [Nouveautés Power BI — Avril 2026]

- [Create a card visual in Power BI]

- [Visual defaults in Power BI reports (Fluent 2)]

- [Use report themes in Power BI Desktop]

- [Create Smart Narrative Summaries]

- [Direct Lake overview]

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

La création d’un Workspace est la toute première étape, avant même de penser au stockage, aux transformations ou à la visualisation. La plateforme Microsoft Fabric permet énormément de choses, mais une question cruciale se pose dès le départ :

• combien de workspaces faut-il créer ?

• Faut-il en dédier un à chaque tâche spécifique ou tout regrouper ?

Six mois après le lancement, vous ouvrez votre portail Fabric et vous voyez défiler des noms comme :

• « Test_Jean »

• « Copie_Prod_v2_FINAL »

• « BI_Marketing_new »

• « Workspace_Antoine_Ne_Pas_Toucher »

Aucune convention de nommage.

Aucun propriétaire clairement désigné.

Des capacités (CU) sur-sollicitées car personne n’a défini qui pouvait associer quoi, et où.

Ce n’est pas un problème de technologie, c’est un problème de gouvernance non anticipée. Dans Fabric, la liberté donnée par défaut est immense — c’est une force, mais à une seule condition : avoir posé les règles du jeu avant d’ouvrir les vannes.

C’est quoi la gouvernance des workspaces dans Fabric ?

Pour rappel, dans Microsoft Fabric, un workspace est l’unité fondamentale de collaboration et d’organisation. C’est là que vivent vos Lakehouses, Warehouses, Pipelines, Semantic Models, Notebooks… Chaque workspace est rattaché à une capacité Fabric, qui définit la région Azure de stockage et les ressources de calcul disponibles.

La gouvernance des workspaces, c’est répondre à trois questions simples avant que le chaos s’installe :

• Qui peut créer des workspaces ?

• Qui les associe aux capacités ?

• Et qui est responsable de quoi dedans ?

La réalité du terrain

✅ Fabric propose deux modèles de création de workspaces.

Le modèle centralisé (seuls les admins IT créent des workspaces) garantit la cohérence et le contrôle — idéal pour des environnements régulés.

Le modèle décentralisé (les project leads ou power users créent leurs propres workspaces) offre de l’agilité, mais doit obligatoirement s’accompagner de règles claires de naming et de gouvernance.

Dans les deux cas, les admins tenant peuvent restreindre la création de workspaces à certains utilisateurs uniquement — c’est un levier de gouvernance souvent sous-utilisé.

✅ Déléguer la responsabilité en utilisant les domaines.

Dans Fabric, les Domaines permettent de regrouper des workspaces par département, projet ou entité métier (Sales, Finance, Supply Chain…). C’est ce qui vous permet de déléguer certains droits d’administration à un Domain Administrator sans lui donner les clés du tenant entier.

Un Domain Administrator peut associer des workspaces, configurer des paramètres délégués, créer des sous-domaines. C’est la couche de gouvernance intermédiaire entre le Fabric Admin et les Workspace Admins.

✅ Bien comprendre les rôles dans un workspace.

• Reader (lecture seule),

• Contributor (modification),

• Member (modification + partage),

• Admin (gestion complète incluant les permissions).

La règle terrain : gérez toujours ces rôles via des groupes de sécurité, jamais par utilisateur individuel. Quand quelqu’un quitte l’équipe, vous retirez une personne d’un groupe — vous ne parcourez pas 12 workspaces pour révoquer ses accès un par un.

✅ Les Tags et le OneLake Catalog sont vos alliés pour garder la vue d’ensemble.

• Les Tags permettent d’apposer des métadonnées sur vos items dans vos workspaces (par projet, département, criticité).

• Le OneLake Catalog offre une vue centralisée avec un onglet Govern (état de documentation, complétude des métadonnées) et un onglet Secure (en preview) pour visualiser les rôles et permissions par workspace et domain. C’est votre tableau de bord de gouvernance.

Points de vigilance

⚠️ L'assignation des capacités Fabric ne doit pas être libre.

Plus vous rattachez de workspaces à une même capacité, plus vous mutualisez les ressources — et plus vous exposez l’ensemble à des variations de performance.

L’erreur classique sur le terrain : laisser chaque workspace admin associer librement sa charge à n’imorte quelle capapcité peut être dangereux et faire face à des surcharges de la capacité.

La règle : cette responsabilité doit être portée par votre équipe DataOps ou infrastructure, avec des guidelines claires. Un modèle hybride fonctionne bien : capacités séparées pour production, développement et expérimentation.

⚠️ Un workspace ne peut appartenir qu’à un seul deployment pipeline.

Si vous construisez vos environnements DEV/TEST/PROD avec des deployment pipelines natifs Fabric, chaque workspace ne peut jouer qu’un rôle dans la chaîne.

Planifiez votre arborescence de workspaces en conséquence avant de créer vos pipelines — vous ne pourrez pas les modifier après coup sans tout recréer.

⚠️ Les dossiers dans un workspace ne sont que de l’organisation visuelle, pas de la gouvernance.

C’est un raccourci mental fréquent : créer des dossiers pour simuler de la séparation de droits.

Dans Fabric, les dossiers n’ont aucun impact sur les permissions. Si vous avez besoin de séparer les droits d’accès, c’est soit au niveau du workspace que ça se passe, sinon au niveau des objets, mais pas par dossier.

Mon conseil : partez de l’organisation humaine, pas du nombre de workspaces

La question n’est pas “combien de workspaces dois-je créer ?”.

Elle est “quelles sont les frontières organisationnelles et de responsabilité dans mon équipe ?”

• Si vos équipes de Data Engineering et de BI sont distinctes, segmenter les espaces de travail devient une nécessité. L’idée est d’isoler les environnements de traitement (où l'on manipule la donnée brute et complexe) des environnements de restitution (dédiés aux rapports et à la consommation métier).

• Si vous avez des environnements DEV/TEST/PROD : un workspace par environnement, par projet.

• Si vous avez des contraintes de résidence de données différentes selon les domaines métier : des capacités différentes, donc des workspaces différents.

• Une naming convention documentée dès le départ sauve des mois de confusion. Un format comme [Domaine]-[Couche]-[Environnement]. Par exemple, Sales-Gold-PROD ou Supply-Bronze-DEV, permet à n’importe quel membre de l’équipe, ou à votre successeur, de comprendre immédiatement ce qu’il regarde.

Matrice de décision

Q1 : Votre organisation a-t-elle des équipes métier distinctes avec des besoins de gouvernance différents ?

• Oui : Configurez des Domaines dans Fabric par entité métier. Déléguez la gestion à des Domain Admins désignés.

• Non : Un domaine unique administré centralement suffit en phase initiale.

Q2 : Qui doit avoir le droit de créer des workspaces ?

• Uniquement l’IT : Activez la restriction de création dans les paramètres tenant. Centralisé et contrôlé.

• Les project leads : Décentralisé acceptable, mais imposez une naming convention et un template de workspace à respecter.

Q3 : Avez-vous plusieurs environnements (DEV/TEST/PROD) ?

• Oui : Planifiez des workspaces dédiés par environnement et configurez des Deployment Pipelines natifs Fabric (2 à 10 stages). Nommez-les dès le départ : [Projet]-DEV, [Projet]-TEST, [Projet]-PROD.

• Non (PoC uniquement) : Un workspace unique est acceptable, mais documentez que c’est temporaire.

Q4 : Avez-vous des contraintes de performance différentes entre vos workloads ?

• Oui : Des capacités Fabric séparées par usage (production vs experimentation vs développement) évitent qu’un job batch mal calibré pénalise vos dashboards en production.

• Non : Une capacité partagée multi-workspaces reste viable à condition de monitorer la consommation de CUs.

🥇 La Règle d’Or

Si tu dois retenir une chose : Dans Fabric, la liberté de créer des workspaces est par défaut illimitée. Cette liberté est un atout si vous avez posé trois règles avant d’ouvrir la plateforme — qui crée, qui associe aux capacités, qui est propriétaire.

L’Impact Terrain

Une gouvernance workspace bien conçue dans Fabric, c’est la fin de l’effet “boîte noire” pour vos administrateurs.

Chaque workspace a un propriétaire identifiable, une convention de nommage lisible, et une capacité dimensionnée à son usage réel.

Vos équipes DataOps peuvent scaler, auditer et décommissionner sans devoir organiser une réunion de trois heures pour retrouver à qui appartient “Workspace_Final_v3”.

C’est le socle qui rend possible la délégation sans perdre le contrôle, et qui transforme une plateforme en environnement de production fiable.

Et vous, comment gouvernez-vous vos workspaces dans Fabric ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles :

• Créer et gérer des espaces de travail dans Fabric

• Comprendre les rôles dans les espaces de travail

• Utiliser les Domaines pour structurer votre tenant

• Introduction aux pipelines de déploiement (CI/CD)

• Administration et gouvernance dans Microsoft Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Le OneLake de Microsoft Fabric a une promesse séduisante : il peut avaler n’importe quel type de données, quels que soient le format ou la volumétrie.

Delta parquet, compressé et optimisé !

Mais attention au revers de la médaille. Sans une gouvernance claire, votre lac de données va très vite se transformer en un marécage.

Aujourd’hui, nous allons explorer une bonne pratique pour bâtir une plateforme de données robuste et évolutive : l’architecture Medallion (Bronze, Silver, Gold).

Et mettons les choses au clair : ce n’est pas qu’une simple convention de nommage pour faire beau dans vos espaces de travail. C’est une stratégie de découplage, autant technique qu’organisationnelle.

Le but ? Qu’à chaque nouvelle source de données à ingérer, vous sachiez parfaitement comment la gérer, la transformer et la mettre à disposition, sans tout mélanger.

C’est quoi l’architecture Medaillon ?

Conceptualisée par Databricks et adoptée nativement par Microsoft Fabric, l’architecture Medaillon organise les données en trois couches de raffinement progressif :

🥉 Bronze — La zone brute. La donnée arrive telle quelle, dans son format d’origine. Pas de transformation. Pas de nettoyage. C’est la zone où l’historique des données est préservé. Si les règles métiers changent ou si quelque chose plante en aval, vous pouvez toujours re-traiter depuis ici sans avoir à interroger à nouveau les systèmes sources.

🥈 Silver — La zone de confiance. C’est la zone où on commence à traiter les données : la donnée est validée, dédupliquée, enrichie et harmonisée. Voici quelques exemples :

• Alignement des référentiels : On réconcilie les données venant de systèmes différents (ex: un ID produit de l’ERP avec celui du CRM) et on uniformise les formats (comme les timestamps dans un seul fuseau horaire).

• Qualité des données : On nettoie les doublons, on gère les valeurs nulles et on écarte ou corrige les erreurs de saisie.

• Gouvernance et stockage : Les données sont structurées et stockées sous forme de tables relationnelles dans un Lakehouse. À ce stade, la donnée est propre, fiable et interrogeable, mais elle reste à sa maille la plus fine (non agrégée).

🥇 Gold — La zone métier. La donnée est agrégée, pré-calculée et modélisée spécifiquement pour la consommation analytique. On quitte la logique “système” pour adopter le vocabulaire des utilisateurs, voici quelques exemples :

• Modélisation métier : C’est ici que l’on construit les modèles en étoile (tables de faits et tables de dimensions) pour faciliter l’analyse.

• Calcul des indicateurs : Les KPI vont être calculés à ce niveau pour des besoins métiers spécifiques (chiffre d’affaires mensuel, taux de churn, panier moyen), cela permet garantir des temps de réponse ultra-rapides pour la visualisation de ces données.

• Consommation sécurisée : C’est cette couche (et uniquement celle-ci) que voient vos data analysts, qui alimente vos dashboards Power BI ou vos modèles sémantiques. Les règles de sécurité (qui a le droit de voir quoi) y sont strictement appliquées.

La réalité du terrain

✅ Chaque zone a son équipe propriétaire.

• Bronze → équipe ingestion IT.

• Silver → Data Engineers.

• Gold → équipe BI ou métier.

Ce découplage organisationnel est le vrai bénéfice de l’architecture Medaillon : chacun travaille dans son périmètre sans bloquer l’autre.

En règle générale, on ne va pas exposer directement les données de la couche Bronze aux équipes métiers. La gestion des accès, de la sécurité fine et du partage se fait au niveau de la couche Gold, là où la donnée est propre, qualifiée et prête à être consommée.

✅ La couche Gold n’est pas forcément un Lakehouse.

La force du Lakehouse réside principalement dans son moteur Spark et la flexibilité de préparer les données via des Notebooks (en Python, Scala, etc.). Mais si votre équipe d’analystes est avant tout experte en T-SQL, un Warehouse est tout à fait adapté. Les profils SQL y retrouveront leurs marques immédiatement et pourront y implémenter nativement la sécurité fine (RLS, CLS et Data Masking).

✅ Un item physique par couche.

Vous stockez peut-être toutes vos données dans un seul et même Lakehouse, en vous contentant de préfixer vos tables par « Bronze », « Silver » et « Gold ».

La véritable bonne pratique sur Fabric est de dédier un item physique par couche.

Par exemple : un Lakehouse LH_Bronze, un Lakehouse LH_Silver, et un Warehouse WH_Gold.

Sur Fabric, la gestion des droits d’accès (RBAC) est beaucoup plus simple et robuste lorsqu’elle est appliquée au niveau de l’item. En séparant physiquement vos couches, vous garantissez que vos analystes n’ont accès qu’au conteneur Gold, sans jamais risquer d’exposer accidentellement les données brutes et sensibles du Bronze.

✅ Multi-workspaces ? Aucun problème grâce aux Shortcuts.

Vos données réparties sur plusieurs espaces de travail (workspaces) ne sont pas un problème, elles restent accessibles via le OneLake sans aucune duplication physique !

Le secret ? Les Shortcuts (raccourcis). Ils vous permettent de référencer les données dans la couche Gold et de donner accès à des tables pour un domaine métier spécifique par exemple. Ainsi, l’équipe métier peut explorer ces tables et créer son propre reporting BI, tandis que vous conservez une gestion centralisée des droits et des permissions.

Pièges à Eviter

⚠️ Le Bronze n’est pas une poubelle.

Ingérer tout type de données et tout déverser dans le Bronze sans structure de répertoires, sans partitionnement ni nommage clair, c’est la garantie de créer un marécage où l’on ne retrouve plus rien. De plus, si vous n’intégrez aucun élément d’historisation, vous finirez vite par oublier les différentes versions et l’objectif initial de ces données.

Imposez une convention de nommage et de partitionnement stricte dès l’ingestion. Par exemple : /{source}/{année}/{mois}/{jour}/.

⚠️ Ne sautez pas le Silver sous prétexte de “gagner du temps”.

Vous vous dites sûrement : « Mes données sources sont déjà propres et bien formatées, je vais passer directement du Bronze au Gold pour gagner du temps ! »

Ça marche… jusqu’au jour où une deuxième source vient s’ajouter et remonte des doublons sur un même client, mais avec un format différent qui n’a pas été géré.

La couche Silver n’est pas optionnelle. C’est la couche qui gère la complexité et les incohérences des systèmes sources (dédoublonnage, standardisation des formats, typage) pour garantir que votre couche Gold reste un espace de consommation propre pour la visualisation.

⚠️ Vouloir nettoyer trop tôt.

À l’inverse, face à des données mal formatées (mauvais typage, mapping erroné, fichiers mal structurés), on est souvent tenté de nettoyer les données dès l’ingestion pour « aller plus vite ».

C’est une erreur stratégique. La couche Bronze doit rester la plus passive possible. Si vous commencez à appliquer des transformations lourdes dès l’ingestion, vous perdez la traçabilité de la donnée brute : en cas de bug ou de besoin de recalcul, vous n’avez plus de point de référence. Gardez vos notebooks de transformation pour le passage vers le Silver.

Matrice de décision : comment structurer votre Medallion ?

Avant de créer votre premier Lakehouse, répondez à ces questions :

🥇 La Règle d’Or

Si tu dois retenir une chose : L’architecture Medallion dans Fabric n’est pas une convention de nommage de lakehouses.

C’est un découplage organisationnel — un workspace, une équipe, une responsabilité. Sans ça, vous aurez trois lakehouses bien nommées et zéro gouvernance.

Une Architecture Medaillon bien construite dans Microsoft Fabric, c’est la fin du goulot d’étranglement IT sur la donnée.

L’équipe ingestion livre en Bronze, l’équipe Data Engineering transforme en Silver, l’équipe BI construit en Gold — sans se marcher dessus, sans blocages inter-équipes.

C’est ce socle qui permet aux analystes de se concentrer sur la valorisation de la donnée plutôt que de passer leur temps à nettoyer des fichiers mal structurés ou à chercher quelle version de la table est “la bonne”.

Et vous, quelle est votre expérience avec l’architecture Medallion ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, voici les documentations officielles indispensables :

• Qu’est-ce que l’architecture de médaillon dans un lakehouse ?

• Comprendre l’architecture de lakehouse en médaillon pour Microsoft Fabric avec OneLake

• Mettre en œuvre l’architecture de médaillon avec des vues sur le lac matérialisées

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie, sans le jargon inutile.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Avez-vous déjà passé des heures en salle de réunion à brainstormer sur l’architecture de votre projet data ?

• Quels sont les besoins métiers ?

• Quelles sont les sources à ingérer pour y répondre ?

• Quelles sont les transformations (règles métiers) à appliquer ?

En fin de session, vous repartez avec une photo du tableau blanc : des notes partout, des flux dans tous les sens et des règles mentionnées à l’oral qui seront oubliées dès le lendemain.

Que devient cette photo lorsque le besoin évolue ?

Lorsqu’un nouvel arrivant débarque sur un projet composé de flux transverses et d’éléments empilés sans hiérarchie, comment faciliter sa compréhension ? Il doit déchiffrer des dépendances à l’aveugle à partir d’une photo qui n’est déjà plus à jour. Le risque d’erreur explose et la documentation est systématiquement obsolète.

Comment résoudre ce point de frustration sur Microsoft Fabric ?

Pas de panique : je vais vous parler d’une fonctionnalité pour intégrer vos architectures data (prédéfinies ou personnalisées) directement au sommet de vos espaces de travail : les Task flows (Flux de tâches).

Cette fonctionnalité va changer la façon dont vous allez concevoir les projets data dans Fabric, voyons voir comment les utiliser.

Task Flows

C’est la couche de modélisation visuelle et logique directement intégrée au-dessus de votre espace de travail. Vous dessinez l’architecture (Ingestion > Stockage > Préparation) et vous venez y “attacher” vos artefacts physiques de manière interactive.

Comment ça s’utilise ?

Rien de complexe, tout se passe directement sur le canevas de votre espace de travail. Deux options s’offrent à vous :

• Les architectures prêtes à l’emploi (Templates) : Fabric propose nativement des modèles industriels reconnus (Medallion, Lambda, etc.). En un clic, les boîtes sont créées et reliées. C’est la méthode la plus rapide pour forcer une équipe à adopter un standard.

• L’approche sur-mesure (Custom canvas) : Votre flux sort des sentiers battus ? Ajoutez des tâches vierges, renommez-les et reliez-les avec de simples flèches en drag-and-drop.

💡 Astuce : Ne partez pas d’une feuille blanche. Importez un template existant sur le canevas et adaptez-le à votre flux. Vous gagnerez un temps précieux. Vous pourrez ensuite facilement supprimer des étapes ou ajouter de nouvelles tâches pour coller parfaitement à votre besoin.

Surtout, ne laissez pas la « Description » de ces boîtes vide. Utilisez cet encart natif pour documenter les règles de gestion, l’usage métier ou l’équipe responsable. C’est le meilleur moyen de conserver le contexte sans sortir de l’outil. C’est ça, la vraie documentation intégrée.

• Sur chaque bloc de tâche, si vous voulez ajouter des éléments, il suffit de cliquer sur “+ New item”. Fabric agit alors comme un guide : il suggère immédiatement une liste filtrée de tous les artefacts disponibles et recommandés pour cette étape précise.

  • Par exemple : « Pour ingérer de faibles volumes de données sur la plateforme, quels objets puis-je utiliser ? » Le bloc de tâche propose plusieurs options pour guider nos choix.

• Vous avez déjà développé plusieurs éléments sans mettre en place de Task Flow ? Pas de souci : l’icône « trombone » sur chaque bloc de tâche vous permet d’associer vos objets existants en un clic. Une fois l’association faite, la colonne « Task » de votre espace de travail s’enrichit automatiquement avec le nom du bloc correspondant.

💡 Astuce : Le Task Flow expose la logique métier et la circulation des données, mais ne négligez pas l’organisation physique. Utilisez les dossiers (Folders) pour ranger vos objets dans l’espace de travail. C’est le duo gagnant pour une navigation fluide.

Discipline requise : Le Task Flow ne s’auto-alimente pas. Si les développeurs n’associent pas systématiquement leurs nouveaux rapports ou pipelines aux blocs de tâches, votre schéma deviendra vite une coquille vide, totalement décorrélée de la réalité technique.

Mon conseil : Ne voyez pas ces outils comme une “décoration” à faire à la fin du projet pour faire plaisir au management. Imposez-les dès le premier jour pour démarrer votre produit data. C’est votre “Living Documentation” officielle.

Matrice de décision

Faut-il imposer l’usage des Task flows dans vos projets ? Posez-vous ces questions :

• Q1 : Votre workspace est-il partagé entre des créateurs (Data Engineers) et des consommateurs (Data Analysts) ?

  • Si oui > Le Task flow est indispensable. Il crée un langage visuel commun et rassure les profils moins techniques.

• Q2 : Vos architectures nécessitent-elles de la documentation externe (Visio, Confluence) ?

  • Si oui > Arrêtez de maintenir des schémas statiques. Utilisez le Task flow pour documenter au plus près du code.

Si tu dois retenir une chose :

Le Task Flow dessine l’architecture, les Folders organisent les objets, mais aucun des deux ne remplacera la rigueur d’association de vos équipes lors de la création d’un nouvel élément dans Microsoft Fabric.

Utiliser les Task Flows, c’est bâtir un socle gouverné pour que vos experts puissent enfin se concentrer sur la valorisation de la donnée.

Ne perdons plus de temps à déchiffrer des flux de données éparpillés ou à traquer des règles métiers transmises à l’oral, ce qui ne fait que complexifier la compréhension d’un espace de travail. Une architecture visuellement propre est souvent le reflet d’une architecture techniquement robuste.

Et vous, comment utilisez-vous les Task Flows ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et passer à la pratique, je vous recommande ces lectures essentielles issues de la documentation officielle :

• 📘 Vue d’ensemble des Task Flows (La théorie)

• 🛠️ Créer et configurer un Task Flow (Le déploiement)

• 🔗 Lier et gérer vos artefacts avec le Task Flow (Le quotidien)

• 📁 Organiser son workspace avec les Dossiers (Folders)

Bienvenue dans cette 3ème édition des nouveautés de Microsoft Fabric.

Ce mois de mars 2026 marque un tournant dans la gestion de l’infrastructure Fabric, accentué par un événement incontournable : la tenue conjointe de la FabCon et de la SQLCon 2026 cette semaine à Atlanta. (D’ailleurs, j’ai publié un post complet à ce sujet si vous souhaitez en savoir plus).

Mon objectif aujourd’hui n’est donc pas de vous lister toutes les features du mois, mais de me concentrer sur 3 fonctionnalités qui vont avoir un impact immédiat sur la stabilité de vos déploiements. C’est parti !

1. Capacity Overage (Preview) : L’airbag de votre moteur de calcul

La réalité du terrain, la capacité Fabric peut rencontrer des pics de charge imprévus susceptibles de paralyser la plateforme lorsqu’elle est mal dimensionnée. Jusqu'ici, les mécanismes natifs de Fabric (Bursting et Smoothing) lissaient la consommation de votre moteur de calcul. Mais en cas de charge soutenue au-delà de la limite de votre SKU, la sanction tombait : la capacité entrait en throttling (bridage), entraînant des ralentissements sévères pour les utilisateurs interactifs, voire le rejet pur et simple de vos opérations et pipelines au bout d’un certain temps.

Avec Capacity Overage (actuellement en Preview), Microsoft propose un véritable airbag pour garantir la disponibilité de votre plateforme.

• Le concept : C’est une option d’activation volontaire (opt-in) qui autorise votre Capacity à consommer momentanément plus de Capacity Units (CU) que son plafond, avec une facturation automatique de l’excédent. Concrètement, le système “paie” votre dette de calcul en temps réel pour sortir la capacité du throttling. Aucun job n’est mis en pause ou annulé.

• Pourquoi ? L’objectif est de maintenir vos charges de travail critiques à flot lors de pics imprévus. Mais attention, la flexibilité a un prix : cet excédent est facturé 3 fois le tarif Pay-As-You-Go. Ce mécanisme est donc conçu pour absorber un choc ponctuel, pas pour masquer un sous-dimensionnement chronique.

• L’implémentation : Au niveau des paramètres de la Capacity, l’administrateur définit une limite maximale de dépassement autorisé sur une fenêtre glissante de 24 heures. Si ce plafond de sécurité est atteint, Fabric coupe l’Overage et repasse au comportement de throttling classique. Tout sera d’ailleurs très vite monitorable en détail directement via la Capacity Metrics App ou le Real-Time Hub.

💡 Tips : Ciblez la production ! Activez l'Overage uniquement sur vos capacités de production hébergeant des processus métiers critiques. Sur vos environnements de Dev/Test, laissez le système bloquer : vos développeurs doivent apprendre à optimiser leurs requêtes, pas à s'appuyer sur du crédit infini.

⚠️ Pièges à Éviter : À 3x le prix standard, c’est un filet de sécurité d’urgence. Si vous constatez que vous tapez dans l’Overage plusieurs jours de suite, ne laissez pas la situation pourrir : la vraie solution est d’auditer votre code pour réduire la dette technique, ou d’upgrader officiellement votre SKU vers la taille supérieure.

Si vous voulez creuser ce point précis, je vous invite d’ailleurs à lire l’excellente analyse de Matthew Farrow sur LinkedIn à ce sujet.

2. Upgrade Synapse Pipelines vers Fabric : Industrialiser la migration

Migrer d’anciennes architectures vers de nouveaux outils peut rapidement se transformer en marécage si l’on se contente de faire du “Lift & Shift” sans discernement. Je vois souvent des entreprises qui ont déjà Synapse Pipeline dans Azure, et qui ont commencé à construire une partie de leur solution data dans Fabric. La question de la bascule devient alors centrale.

Microsoft vient d’annoncer une nouvelle brique pour convertir massivement vos pipelines Synapse vers des Pipelines Fabric natifs. L’objectif n’est pas d’appuyer sur un bouton magique, mais d’adopter une approche intentionnelle, transparente et à faible risque grâce à un rapport de validation avant exécution.

Le processus de migration natif se déroule en 3 étapes claires :

1. L’Audit de préparation (Assessment) : Directement depuis votre workspace Synapse actuel (menu Integrate > Migrate to Fabric), vous lancez une évaluation de vos pipelines et activités. L’outil analyse l’existant sans rien modifier.

2. La Matrice de validation : Les résultats tombent et classent vos artefacts en 4 catégories : Ready, Needs review, Coming soon, ou Unsupported. Vous pouvez exporter ce rapport en CSV. C’est la base de votre plan de remédiation à partager avec vos ingénieurs data.

3. Le Mapping et la Migration : Vous ciblez un Workspace Fabric et vous mappez vos anciens Linked Services Synapse vers des connexions Fabric. La plateforme a prévu de vrais garde-fous : si une connexion n’est pas mappée, le pipeline migre quand même, mais l’activité reste désactivée. Surtout, les Triggers (déclencheurs) migrent désactivés par défaut, vous laissant le temps de valider vos credentials et de faire vos tests de bout en bout avant la véritable mise en production.

💡 Tips : Pré-créez vos connexions de données directement dans les paramètres de votre Workspace Fabric cible avant de lancer l’assistant de migration. Lors de l’étape 3, il vous suffira de les sélectionner dans le menu déroulant, ce qui fluidifiera considérablement la bascule.

⚠️ Pièges à Éviter : Ce n’est pas parce que l’outil automatise la bascule qu’il faut l’utiliser aveuglément sur l’intégralité de vos anciens workloads. Profitez de cet audit pour régler votre dette technique. Si un pipeline Synapse comportait 40 activités de transformation complexes, demandez-vous plutôt si un Notebook PySpark ou un Dataflow Gen2 ne garantirait pas un meilleur découplage dans Fabric. C’est aussi le temps d’optimiser !

3. Nouvelles activités Pipeline : Automatiser l’hygiène de vos Lakehouses

Je vois souvent des équipes choisir le Lakehouse pour sa flexibilité et sa simplicité de mise en place dans une architecture médaillon. Mais la réalité du terrain, c’est qu’un Lakehouse ultra-performant le jour 1 peut rapidement se transformer en marécage lent et coûteux le jour 100 si l’on néglige son entretien.

Jusqu’ici, maintenir l’hygiène de vos tables Delta nécessitait de multiplier les scripts custom via des Notebooks, de gérer manuellement l’optimisation du V-Order, ou encore de scripter le Vacuum des anciens fichiers... Une vraie dette technique en devenir pour vos Data Engineers.

Ce mois-ci, Microsoft introduit deux nouvelles briques (en Preview) natives dans vos Pipelines Fabric pour standardiser ces opérations vitales.

A. Lakehouse Maintenance activity : Le nettoyage automatisé

• Fini les checklists interminables pour gérer vos tables. Cette nouvelle activité permet d’automatiser des actions critiques comme le Vacuum (suppression des anciens fichiers historiques) et l’Optimize (optimisation de la disposition physique des données) directement depuis votre orchestrateur Data Pipelines. C’est le moyen le plus pragmatique de maintenir des performances optimales sur votre moteur de calcul tout en gardant vos coûts de stockage sous contrôle.

B. Refresh SQL endpoint activity : La synchronisation sur demande

• La valorisation de la donnée pour vos analystes BI exige une base prévisible. Le délai de synchronisation naturel entre une écriture Spark et sa disponibilité dans le SQL Analytics Endpoint a souvent causé des sueurs froides aux équipes. Cette nouvelle activité vous redonne le contrôle absolu : vous pouvez désormais forcer le rafraîchissement du point de terminaison SQL de manière ciblée, juste après vos transformations, garantissant que vos consommateurs aval requêtent toujours la dernière version de la vérité.

💡 Tips : Découplez ces deux concepts. Intégrez l’activité Refresh SQL endpoint à la toute fin de vos pipelines de chargement quotidiens (après la mise à jour de votre couche Gold). En revanche, isolez la Lakehouse Maintenance dans un pipeline “DataOps” dédié, planifié pour tourner la nuit ou le week-end, afin de nettoyer vos artefacts sans risquer de perturber la production en journée.

⚠️ Pièges à Éviter : Ne lancez pas d’opérations de Vacuum ou d’Optimize à la fin de chaque ingestion en streaming ou micro-batch ! Ces tâches de maintenance consomment énormément de ressources sur votre Capacity. Vouloir avoir un Lakehouse “trop” propre en temps réel va simplement assécher vos Capacity Units (CU) pour rien. Une passe quotidienne ou hebdomadaire est amplement suffisante.

Conclusion

Si tu dois retenir une chose : La résilience de ton architecture Fabric prime sur la course frénétique aux nouveautés ; utilise ces nouveaux outils (Overage, migration Synapse, automatisation de maintenance) pour consolider tes fondations et purger ta dette technique, pas pour complexifier ta plateforme.

L’Impact Terrain : Prendre le temps d’intégrer ces mécanismes de résilience et d’automatisation, c’est la garantie de sortir vos Data Engineers du mode “pompier”. Fini les alertes de throttling au milieu de la nuit, fini les dizaines de scripts Notebooks custom à maintenir pour le nettoyage : votre équipe se concentre enfin sur la véritable valorisation de la donnée.

Et vous, quelle fonctionnalité va le plus impacter votre quotidien ce mois-ci ? Répondez simplement en commentaire (ou par email) pour me le dire, je lis toutes vos réponses ! 👋

À très vite pour explorer ensemble le futur de la Data.

📚 Ressources pour aller plus loin :

• Nouveautés de Microsoft Fabric (Mars 2026)

• Capacity Overage (Preview)

• Synapse Pipelines to Microsoft Fabric

J’aide les profils techniques à maîtriser l’architecture de Microsoft Fabric, et j’aide les décideurs à comprendre l’impact réel de cette technologie, sans le jargon inutile.

Mon objectif ? Vulgariser le complexe et vous donner les clés pour maîtriser Microsoft Fabric, une plateforme de données SaaS unifiée et alimentée par l’IA pour simplifier la gestion des données et l’analyse.

Cette newsletter est 100% gratuite. En vous abonnant maintenant, vous recevrez en exclusivité mon “One-Pager” pour cartographier l’ensemble de la solution Fabric en un coup d’œil.

Merci à celles et ceux qui me suivent depuis le début. Sans plus attendre, entrons dans le vif du sujet !

Bienvenue dans cette nouvelle édition. Aujourd’hui, on s’attaque au problème de l’ingestion de données dans la plateforme moderne Microsoft Fabric.

Trop de choix tue le choix.

Si vous avez ouvert votre workspace récemment, vous l’avez sûrement remarqué : le menu des outils pour ingérer les données s’allonge à chaque mise à jour.

Vous voulez déplacer de la donnée ?

Fabric vous propose désormais : Data Pipeline, Dataflow Gen2, Notebook, mais aussi Copy Job, Eventstream ou même Apache Airflow...

Résultat ? On passe plus de temps à se demander quel outil utiliser qu’à réellement construire le flux.

C’est la question qui revient le plus : “Antoine, je dois juste charger un CSV, est-ce que je dois vraiment monter un Pipeline ?”

Aujourd’hui, on tranche. Je vous donne tous les éléments pour faciliter votre prise de décisions sur les possibilités ainsi que la Matrice de Décision définitive.

1. Les “Classiques” (Le trio de base)

C’est ici que se joue 90% de votre architecture. Il ne faut pas les voir comme des concurrents, mais comme des outils avec des “personnalisations” différentes.

a. Data Pipelines : Le Chef d’Orchestre

La Data Pipeline est le moteur d’orchestration et de flux de travail (workflow) de Microsoft Fabric. Sa mission n’est pas de transformer la donnée en profondeur, mais de piloter l’ensemble du cycle de vie de l’information. Elle agit comme un chef d’orchestre qui définit l’ordre, la fréquence et les conditions d’exécution de toutes les autres tâches (Copy Jobs, Notebooks, Dataflows).

• Orchestration Logique : Elle permet de créer des séquences intelligentes. Par exemple : “Lance la copie des données ; si elle réussit, exécute le Notebook de nettoyage ; si elle échoue, envoie une notification Teams.”

• Déplacement de Données (Copy Activity) : Elle intègre un moteur de copie ultra-performant capable de se connecter à différentes sources (On-premises, Cloud, SaaS) pour ramener les données brutes dans le OneLake.

• Gestion des Dépendances et Planification : C’est ici que l’on gère le calendrier (Scheduling) ou les déclenchements basés sur des événements. Elle permet de surveiller et de reprendre les flux en cas d’erreur.

• Contrôle de Flux Avancé : Elle offre des outils de logique programmatique visuelle : boucles (ForEach), conditions (If/Else), variables et paramètres, rendant les flux dynamiques et réutilisables.

La Réalité du Terrain :

• Performance : L’activité Copy Data est un moteur optimisé pour le déplacement de blocs binaires. C’est souvent 2 à 3 fois plus rapide qu’un Dataflow pour la même tâche.

• Coût (CU) : C’est l’option la plus économe en Capacity Units.

• Destinations : Les Pipelines brillent par leur polyvalence en sortie. Ils proposent plus de 40 destinations possibles (Azure SQL, Lakehouse, Warehouse, KQL, etc.), là où les destinations des Dataflows Gen2 restent encore assez restreintes.

• Connectivité : Avec un catalogue d’environ 60+ connecteurs natifs, les Pipelines sont plus limités que les Dataflows Gen2 en entrée. Si votre source est un outil SaaS très spécifique, vous pourriez ne pas l’y trouver.

Mon conseil : Considérez le Data Pipeline comme la colonne vertébrale de votre orchestration. Son rôle est d’assurer l’ingestion massive et économique de vos données brutes (SQL, Cloud, On-premises) vers le Lakehouse (zone Bronze). C’est le chef d’orchestre indispensable pour séquencer vos flux, déclencher vos transformations (Notebooks, Dataflows Gen2) et piloter vos alertes opérationnelles.

b. Dataflow Gen2 : ETL Low-code

C’est Power Query dans le cloud. C’est l’outil de prédilection pour le Low-Code ETL : il permet d’ingérer, de nettoyer et de charger des données une interface visuelle intuitive. Grâce à son moteur de calcul scale-out, il traite des volumes importants sans nécessiter de compétences en Python ou Spark, tout en offrant une intégration transparente avec le reste de l'écosystème Fabric.

La Réalité du Terrain :

• Connectivité : Il se connecte à tout (c’est lui qui a le plus de connecteurs natifs).

• Coût & Performance : les Dataflows Gen2 viennent de recevoir une mise à jour majeure.

  • Le Modern Evaluator : Microsoft a intégré un nouveau moteur (.NET 8) qui permet des gains de temps de 20 à 30%.

  • Nouveau modèle de facturation : Le coût en CUs baisse désormais drastiquement après les 10 premières minutes d’exécution (passant de 12 à 1.5 CUs/sec). Plus le flux est long, plus il devient “rentable”.

• L’Upsert : L’Incremental Refresh est basé sur des fenêtres de temps. Ce n'est pas un vrai "Merge". Pour des dédoublonnages complexes, passez sur un Notebook.

• Le bémol de la consommation : Ne vous détrompez pas, cela reste l’item le plus “cher” en CUs. La consommation peut varier de manière imprévisible pour un même flux.

• La limite du Volume : Pour des petits jobs, le Dataflow est imbattable en rapidité de mise en place. Mais dès que le volume grimpe, l’écart de coût avec la Pipeline (2 à 3 fois moins chère) devient impossible à ignorer.

Mon conseil : utilisez la Pipeline pour l'orchestration globale et le déplacement de masse au moindre coût, et le Dataflow Gen2 pour vos transformations complexes en mode Low-Code.

c. Notebooks (Spark)

Le Notebook est bien plus qu'un simple éditeur de code ; c'est le moteur de calcul à haute performance de Fabric. Propulsé par Apache Spark, il est indispensable pour le traitement de volumes massifs (Big Data) et les transformations complexes que le Low-code ne peut pas gérer efficacement. S'il offre une flexibilité totale en Python (PySpark), Scala ou SQL, son véritable atout réside dans sa capacité à industrialiser le Machine Learning et à optimiser les performances de votre Lakehouse via le format Delta.

La Réalité du Terrain :

• Le Roi du “Merge” : Là où le Dataflow galère, le Notebook brille. Faire un MERGE (Upsert) pour gérer les doublons ou l’historisation est trivial et ultra-rapide en PySpark ou SQL (format Delta).

• Économie de CUs imbattable : De toutes les analyses, le Notebook est l’item le moins “coûteux” en CUs pour les gros traitements. C’est l’option la plus efficiente énergétiquement.

• Flexibilité totale : Vous n’êtes jamais limité par un connecteur ou une interface. Si l’API existe, le Notebook peut l’atteindre.

• Ne tombez pas dans le piège de la technologie “tendance” juste pour le plaisir de coder. Posez-vous ces questions :

  • La cohérence de l’équipe : Est-ce que tout le monde comprend le code ? Pouvez-vous diagnostiquer une erreur rapidement à plusieurs, ou dépendez-vous d’un seul expert ?

  • Le coût d’entrée : Est-ce que passer 10 heures à coder un Notebook Python apporte réellement plus de valeur au business que 10 minutes de configuration dans un Dataflow ?

Mon conseil : Ne voyez pas le Notebook comme un outil réservé aux "geeks", mais comme le moteur de performance de votre plateforme. C’est l’environnement de code par excellence (PySpark, SQL, Scala) qui prend le relais là où le Low-code atteint ses limites. Utilisez-le pour transformer des volumes massifs de données à une vitesse que seul un cluster Spark peut offrir, ou pour injecter de l'intelligence artificielle (Azure OpenAI) directement dans vos flux.

2. Les “Spécialistes” (Les outils que vous oubliez peut-être)

Maintenant, voyons voir les plus spécialisés en fonction des besoins. Microsoft a ajouté des outils pour des cas précis où le trio de base n’est pas optimal.

a. Eventstream : Le “Maître du Temps Réel”

L’Eventstream est la tour de contrôle de Microsoft Fabric dédiée à l’ingestion et au traitement des données en temps réel. Contrairement aux outils classiques qui déplacent des fichiers ou des tables par intervalles (Batch), Eventstream capture des flux d’événements à la milliseconde près, les transforme “au vol” et les distribue instantanément vers plusieurs destinations.

Utilisez-le pour capter des événements instantanés, que ce soit des logs de serveurs, des données IoT (capteurs) ou des transactions e-commerce.

• Il est conçu pour encaisser des volumes massifs de données provenant de sources variées : capteurs IoT, logs d’applications, flux de clics (clickstream) ou encore le CDC (Change Data Capture) qui transforme les modifications de vos bases SQL en flux d’événements.

• C’est un véritable moteur d’ETL temps réel. Sans écrire de code, vous pouvez filtrer les données inutiles, agréger des valeurs (ex: moyenne de température par minute) ou transformer les formats de données avant même qu’elles ne touchent le disque.

• Un seul flux entrant peut être envoyé simultanément vers le OneLake (pour l’historique), une base KQL (pour l’analyse de logs) ou l’Activator (pour déclencher une alerte immédiate sur Teams ou par mail).

Mon conseil: Ne simulez pas du temps réel en lançant un Pipeline toutes les minutes, c’est coûteux. Si vous avez besoin de voir la donnée bouger en moins d’une seconde, c’est Eventstream.

b. Copy Job : L’Ingestion Haute Performance

C’est l’outil qui permet une expérience simplifiée et optimisée qui se concentre sur une seule mission : déplacer des données d’un point A (SQL, S3, ADLS, …) vers un point B (Lakehouse, …) le plus vite possible.

• Expérience Simplifiée : Il propose une interface guidée qui permet de configurer une copie en quelques secondes. C’est l’outil idéal pour les tâches d’ingestion ponctuelles ou récurrentes qui ne nécessitent pas de logique d’orchestration particulière.

• Performance Brute : Sous le capot, il utilise le même moteur de mouvement de données haute performance que les Pipelines, mais avec moins de “couches” logicielles. Il est taillé pour maximiser le débit (throughput) et réduire le temps de transfert des gros volumes.

• Ingestion “As-Is” : Sa philosophie est de ramener la donnée telle quelle vers la zone Bronze. Il ne fait pas de transformation complexe, garantissant ainsi une fidélité totale entre la source et le OneLake.

• Maintenance Allégée : Une fois configuré, il s’exécute de manière autonome avec son propre monitoring, sans polluer vos orchestrateurs de workflows plus globaux.

• Le + : Support des chargements incrémentaux de manière native et ultra-légère.

Mon conseil : Ne sortez pas l'artillerie lourde d'une Pipeline complexe si votre seul besoin est de déplacer des volumes massifs de données sans logique métier. Le Copy Job est votre "voie rapide".

c. Apache Airflow Job : L’Orchestrateur Programmatique

L’Apache Airflow Job dans Microsoft Fabric est une instance entièrement managée du célèbre orchestrateur open-source. Contrairement aux Data Pipelines qui reposent sur une interface visuelle (Drag & Drop), Airflow permet de définir vos flux de données sous forme de code Python, appelés DAGs (Directed Acyclic Graphs).

• Le “Code-First” par excellence : Il s’adresse aux Data Engineers qui souhaitent versionner leurs workflows (Git), créer des pipelines dynamiques (boucles, conditions complexes) et manipuler des dépendances fines que l’interface visuelle ne permet pas.

• Une Interopérabilité Totale : Grâce à sa vaste bibliothèque de “Providers”, Airflow peut piloter des tâches au sein de Fabric (Notebooks, Pipelines) mais aussi interagir avec des services externes (AWS S3, Google BigQuery, Snowflake, APIs tierces, etc.).

• Zéro Gestion d’Infrastructure : Fabric s’occupe de toute la complexité opérationnelle. Vous n’avez pas à gérer de serveurs, de bases de données de métadonnées ou de mises à jour de version ; vous vous concentrez uniquement sur l’écriture de vos scripts d’orchestration.

Mon conseil : Si vos besoins dépassent le cadre visuel des Pipelines Fabric, tournez-vous vers l’Apache Airflow Job. C’est l’outil indispensable pour les architectures “Code-First”.

d. Shortcuts : Le “Zéro Copie” Intelligent

Le Shortcut est une fonctionnalité unique de Microsoft Fabric qui permet de virtualiser l’accès aux données. Au lieu de copier physiquement des fichiers d’un point A vers un point B, vous créez un lien direct (un pointeur) qui rend les données stockées ailleurs visibles et utilisables dans votre OneLake comme si elles y étaient réellement hébergées.

• Élimination de la Redondance (Single Source of Truth) : Les données ne sont pas dupliquées. Vous accédez à la version originale, ce qui garantit la cohérence des données et réduit drastiquement vos coûts de stockage.

• Interopérabilité Multi-Cloud : Les Shortcuts permettent de connecter instantanément des sources externes comme Amazon S3, Google Cloud Storage, Azure Data Lake Gen2, Sharepoint... Vos données AWS apparaissent dans votre Lakehouse Fabric sans aucun flux ETL.

• Performance Transparente : Les moteurs de calcul de Fabric (Spark, SQL, Power BI) lisent les données via le Shortcut avec une latence minimale, en utilisant les protocoles optimisés de OneLake.

• Unification du OneLake : Vous pouvez créer des Shortcuts entre différents Lakehouses ou Workspaces au sein de Fabric. Cela permet de briser les silos internes et de partager des données entre équipes sans mouvement de fichier.

e. Mirroring : La réplication en temps réel, sans code

Le Mirroring est une technologie de réplication de données “Cloud-native” qui permet de créer une copie conforme et synchronisée de vos bases de données externes directement dans Microsoft Fabric.

Contrairement à un ETL classique qui extrait les données par intervalles, le Mirroring utilise le Change Data Capture (CDC) pour répercuter chaque modification de la source vers le OneLake en quasi temps réel.

• Configuration “Zéro-ETL” : Vous ne créez pas de pipelines, pas de schémas, et vous n’avez pas à gérer les types de données. Vous connectez votre base (Azure SQL, Cosmos DB, Snowflake, MongoDB, etc.), et Fabric s’occupe de tout.

• Synchronisation Continue : Une fois activé, le miroir reste à jour automatiquement. Dès qu’une ligne est insérée ou modifiée dans votre base de production, elle est disponible dans Fabric en quelques secondes.

• Format Open Delta : Les données sont stockées au format Delta Parquet dans le OneLake. Cela signifie qu’elles sont immédiatement prêtes pour être l’objet de requêtes SQL, de scripts Spark ou de rapports Power BI en mode Direct Lake (vitesse maximale).

• Impact Minimal sur la Source : Le Mirroring est conçu pour lire les journaux de transactions des bases de données, ce qui évite de ralentir vos applications de production pendant la réplication.

En résumé : Le Mirroring est le pont invisible entre le monde transactionnel (vos applications) et le monde analytique (Fabric). C’est la fin des projets d’ingestion complexes pour les bases de données supportées.

3. La Matrice de Décision : 3 Questions pour Trancher

Avant de cliquer sur le bouton “New Item”, passez votre besoin au crible de ces 4 questions. C’est votre filet de sécurité pour éviter la dette technique.

Q1 : Quel est votre objectif prioritaire ? 🎯

• Virtualiser sans bouger la donnée ? 👉 Shortcut.

• Ingérer massivement ? 👉 Pipeline (Copy Activity) ou Copy Job.

• Transformer visuellement ? 👉 Dataflow Gen2.

• Répliquer une BDD de prod sans ETL ? 👉 Mirroring.

• Agir en moins d’une seconde ? 👉 Eventstream.

Q2 : Qui va maintenir le flux de données dans 6 mois ? 🛠️

• Profil Analyste (No-Code) : 👉 Dataflow Gen2.

• Profil Engineer (Code-First) : 👉 Notebook (Python/Spark) ou Airflow.

• Besoin de simplicité absolue : 👉 Copy Job ou Pipeline.

4. Le Récapitulatif “Cheat Sheet”

Pour celles et ceux qui sont visuels, Microsoft a publié ce guide de décision officiel très complet sur le sujet et voici le tableau à garder sous le coude pour vos arbitrages :

📚 Pour aller plus loin : Je vous recommande vivement de le mettre en favori : 👉 Consulter le Guide de décision officiel Microsoft Fabric

5. L'Astuce Navigation

On s’est penché sur la théorie, mais en pratique, l’interface de Fabric peut vite ressembler à un inventaire sans fin.

Bonne nouvelle : Microsoft a uniformisé l’interface.

Plus besoin de chercher dans quelle “expérience” se cache votre outil. Tout est désormais centralisé pour vous permettre de choisir en fonction de votre tâche :

1. Allez dans votre Workspace.

2. Cliquez sur le bouton “New Item” (Nouvel élément).

3. Dans la fenêtre qui s’ouvre, cliquez sur le filtre “Get Data” (ou “Obtenir des données”) dans la colonne de gauche.

Boom ! Fabric filtre instantanément l’arsenal dédié à l’ingestion : Pipelines, Dataflows, Eventstreams, Copy Jobs... Tout est réuni au même endroit. C’est votre point de départ unique pour comparer les options et lancer votre flux en un clic.

Conclusion

Pour résumer ma philosophie, retenez ceci : La complexité est l’ennemi de la maintenance.

Lors de la conception de votre architecture, analysez toujours le volume de données, la fréquence d’accès et le niveau d’automatisation requis.

• Virtualisez dès que possible avec les Shortcuts. Si la donnée est déjà dans le cloud, ne la déplacez pas.

• Répliquez sans effort avec le Mirroring pour vos bases de production. Évitez l’ETL manuel quand l’outil peut le faire pour vous.

• Industrialisez avec les Pipelines (Copy Activity) pour la performance brute et le contrôle des coûts.

• Valorisez avec les Dataflows Gen2 pour donner de l’autonomie au métier sur des transformations agiles.

• Optimisez avec les Notebooks dès que la complexité technique (comme l’Upsert) ou le volume l’exigent.

Ne choisissez pas l’outil qui vous flatte l’œil le premier jour, choisissez celui que votre équipe pourra maintenir sans douleur — et sans ruiner votre capacité Fabric — dans un an.

Et vous, quel outil privilégiez-vous ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

À la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles :

• Notebook in Microsoft Fabric

• Dataflow Gen2 in Microsoft Fabric

• Data Pipelines in Microsoft Fabric

• Copy Job in Microsoft Fabric

• Eventstream in Microsoft Fabric

• Apache Airflow jobs in Microsoft Fabric

• Shortcut in Microsoft Fabric

• Mirroring in Microsoft Fabric