OneLake, dans Microsoft Fabric, a une promesse simple : centraliser toutes vos sources de données, en Zéro-Copy, dans un seul lac gouverné. On me pose souvent les mêmes questions :

• Pourquoi mes coûts de stockage augmentent-ils mois après mois, sans qu’aucun nouveau volume ne soit ingéré ?

• Ce storage peut-il être optimisé ?

• Comment savoir combien de fichiers Parquet composent chacune de mes tables, et par où commencer l’optimisation ?

Aujourd’hui, on décortique un problème de maintenance des table delta sur Microsoft Fabric.

⚡ En 30 secondes

Ce qu’il faut retenir :

• La maintenance d’une table Delta Lake sur Fabric repose sur 4 commandes : OPTIMIZE (compaction bin-packing), V-Order (optimisation d’écriture Fabric-native), Z-Order (data-skipping sélectif) et VACUUM (nettoyage du storage OneLake).

• Vous pouvez lancer cette maintenance en 3 clics depuis l’UI Lakehouse ou l’orchestrer via une Lakehouse Maintenance activity (Preview) dans un Pipeline Data Factory.

• La règle terrain : OPTIMIZE après une ingestion massive, VACUUM chaque semaine, V-Order uniquement sur les tables consommées par Power BI Direct Lake ou Warehouse. Rétention VACUUM par défaut : 7 jours, ne descendez pas en dessous sans savoir pourquoi.

S'abonner maintenant

Chaque jour, sans que vous le voyiez, des petits fichiers s’accumulent au fil des ingestions. D’autres fichiers Parquet, qui ne sont plus référencés par la table active, restent physiquement présents sur OneLake parce que personne n’a jamais passé de VACUUM. C’est la mécanique du format Delta Lake : chaque modification (INSERT, UPDATE, DELETE, MERGE) est tracée par le journal de transactions _delta_log, qui référence la version active de la table et permet le time travel, revenir à un instant T de la donnée. Cette garantie a un coût : sans nettoyage explicite, votre Lakehouse continue de payer pour des fichiers historiques dont plus aucun rapport ne se sert.

La réalité du terrain, c’est que Microsoft Fabric ne fait pas la maintenance à votre place. Le format Delta est natif, mais la maintenance de vos tables reste à votre charge. Fabric vous donne les outils pour économiser du temps, du compute (CU) et du storage OneLake, à condition de les utiliser.

Quatre commandes composent cette boîte à outils : OPTIMIZE, V-Order, Z-Order, VACUUM. Chacune a un usage précis. En confondre une avec une autre, c’est l’erreur classique sur le terrain.

Aujourd’hui, on pose les fondations.

Les 4 leviers de maintenance Delta Lake sur Fabric

Delta Lake est le format de stockage natif de OneLake. Chaque table est un dossier de fichiers Parquet, gouverné par un journal de transactions (_delta_log). Avec le temps, ce dossier accumule des petits fichiers, des versions historiques, et de la fragmentation. La maintenance sert à garder cette couche physique compacte, indexée et propre.

Quatre leviers :

1. OPTIMIZE, compaction (bin-packing) : réécrit les petits fichiers Parquet en fichiers plus gros pour réduire l’overhead de scan à chaque lecture.

2. V-Order (VORDER), optimisation d’écriture Fabric-native : réorganise les Parquet (row-group distribution, encoding, compression) pour améliorer la lecture, en particulier sur Power BI Direct Lake et Warehouse.

3. Z-ORDER BY, data-skipping sélectif : co-localise les lignes qui partagent des valeurs proches sur 2 à N colonnes, pour que le moteur saute des fichiers entiers lors d’un filtre. Optionnel.

4. VACUUM, nettoyage du stockage: supprime physiquement les fichiers Parquet qui ne sont plus référencés par le Delta log et qui sont plus vieux que la rétention (7 jours par défaut).

Cette maintenance est particulièrement critique si votre Lakehouse alimente la couche Gold de votre architecture Médaillon Bronze / Silver / Gold sur Microsoft Fabric, la santé de vos fichiers Parquet détermine la performance perçue par vos utilisateurs métier.

Maintenance sur l’interface utilisateur du Lakehouse

Pour débuter, Fabric expose une action de maintenance directement depuis l’explorateur Lakehouse. C’est le chemin le plus court pour lancer une maintenance ponctuelle sur une table.

• Ouvrez votre Lakehouse dans le portail Fabric.

• Dans Lakehouse Explorer, sous Tables, faites un clic droit sur la table cible (ou utilisez l’ellipsis).

• Sélectionnez l’entrée de menu Maintenance.

• Dans la boîte de dialogue “Run maintenance commands”, cochez ce que vous voulez lancer :

  • Optimize (On) : compacte les petits fichiers Parquet en fichiers plus gros.

  • Apply V-Order (case à cocher, disponible si Optimize est On) : applique V-Order pendant la compaction. La doc Microsoft cite un impact d’environ 15 % sur le temps d’écriture, avec jusqu’à 50 % de compression supplémentaire.

  • Vacuum (On) : supprime les fichiers non référencés plus vieux que la rétention.

  • Retention threshold (heures) : 168 heures (7 jours) par défaut.

• Cliquez sur Run now.

Vous suivez l’exécution dans le panneau Notifications (icône cloche en haut du portail) ou dans le Monitoring hub (colonne de gauche → Monitor). Les activités portail-initiées apparaissent sous le nom TableMaintenance.

Les 4 leviers en un coup d’œil

Reprenons les 4 commandes avec un focus “à quoi ça sert” et “quand l’utiliser”.

1) OPTIMIZE : la commande la plus rentable

OPTIMIZE prend tous les petits fichiers Parquet accumulés par vos ingestions et les réécrit en fichiers plus gros. Un scan qui lisait 5 000 fichiers en lit 50 après compaction. Les moteurs (Spark, SQL Analytics Endpoint, Warehouse, Direct Lake) apprécient tous les fichiers de taille homogène, c’est ce qui différencie un Lakehouse qui vieillit bien d’un autre qui suffoque.

Quand la lancer : après une ingestion batch massive, ou dès que vous voyez le nombre de fichiers grimper (au-delà de 500 fichiers dans une partition qui devrait en contenir 20, c’est overdue). Sur les tables Gold servant Direct Lake, une fois par semaine hors heures ouvrées est un bon rythme.

2) V-Order : le boost lecture pour Direct Lake

V-Order est une optimisation d’écriture propriétaire Fabric. Elle réorganise les Parquet (row-group distribution, encoding, compression) pour améliorer la lecture. Ce n’est pas une commande à part entière, c’est un modificateur que vous cochez pendant l’OPTIMIZE (case “Apply V-Order” dans la boîte de dialogue).

⚠️ Depuis 2024, V-Order est désactivé par défaut sur les nouveaux workspaces Fabric. C’est un choix documenté par Microsoft — le gain n’est pas universel. Ne présumez pas qu’il tourne.

Quand l’utiliser : sur toutes vos tables Gold consommées par Power BI Direct Lake. Sur les tables Silver / Warehouse en lecture-intensive.

3) Z-Order : le levier ciblé et optionnel

Z-Order est un algorithme de co-localisation. Il place les lignes qui partagent des valeurs proches (typiquement date + customer_id, ou region + product_family) dans les mêmes fichiers Parquet. Le moteur peut ensuite sauter des fichiers entiers grâce aux statistiques min/max, c’est du data-skipping.

Z-Order est le levier le plus mal utilisé de Delta Lake. Il n’a de sens que si :

• Vos requêtes filtrent régulièrement sur 2 colonnes ou plus ensemble.

• Ces prédicats sont sélectifs (un filtre qui divise le volume par 20 ou 100, pas par 1,2).

Sinon, Z-Order coûte plus qu’il ne rapporte, chaque ZORDER BY réécrit tous les fichiers scopés, c’est un job cher.

Mon conseil : par défaut, pas de Z-Order. Vous l’ajoutez uniquement quand une requête spécifique mérite le data-skipping.

4) VACUUM : le nettoyage qui reprend du storage

VACUUM supprime physiquement de OneLake les fichiers Parquet qui ne sont plus référencés par le Delta log ET qui sont plus vieux que la rétention. C’est ce qui reprend concrètement le storage après un OPTIMIZE, une série d’UPDATE / DELETE / MERGE, ou un INSERT OVERWRITE.

Trois choses que VACUUM ne fait pas :

• Il ne supprime pas les fichiers du _delta_log (rétention gérée séparément par delta.logRetentionDuration, 30 jours par défaut).

• Il ne supprime pas les fichiers référencés par un deletion vector.

• Il n’améliore pas les performances de lecture, sa mission, c’est le storage.

Quand le lancer : chaque semaine, en cadence hebdomadaire, après un OPTIMIZE. Rétention par défaut 7 jours. Ne descendez pas plus bas sans diagnostic préalable via DESCRIBE HISTORY.

Comment orchestrer la maintenance (sans code) ?

Le clic droit dans l’UI est parfait pour du ponctuel. Pour de la production, vous voulez l’automatiser. Fabric Data Factory expose une activité dédiée : la Lakehouse Maintenance activity.

Cette activité expose exactement les mêmes options que l’UI (OPTIMIZE avec V-Order optionnel, VACUUM) et s’intègre dans un Pipeline avec dépendances, déclencheurs et paramètres. Le workflow typique :

1. Copy activity (ingestion vers Bronze).

2. Notebook activity (transformations Bronze → Silver → Gold).

3. Lakehouse Maintenance activity (OPTIMIZE VORDER sur les tables Gold).

4. Refresh SQL Endpoint activity (synchronise les métadonnées SQL en aval).

5. Lakehouse Maintenance activity (VACUUM — après le framing des modèles sémantiques Direct Lake, jamais avant).

⚠️ Deux limitations à connaître sur la Lakehouse Maintenance activity (Preview) :

• Elle ne s’exécute pas dans les workspaces avec Private Link activé.

🥇 La Règle d’Or

Si tu dois retenir une chose : la maintenance Delta Lake sur Fabric commence par le clic droit dans Lakehouse Explorer. Pas par du code. Pas par un Pipeline. Quatre commandes, OPTIMIZE, V-Order, Z-Order, VACUUM, chacune un usage précis, et une UI qui te les expose en trois clics. Tu maîtrises l’UI d’abord, tu automatises ensuite.

Et vous, avez-vous déjà lancé OPTIMIZE + V-Order sur vos tables Gold, ou est-ce encore du terrain vierge dans votre Lakehouse ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

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

🔗 À lire dans Fabric Mastery

• Architecture Médaillon Microsoft Fabric : Bronze, Silver, Gold

• Microsoft Fabric : Comprendre OneLake, le "OneDrive" de la Data

📚 Ressources pour aller plus loin

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

• Run Delta table maintenance in Lakehouse, le point d’entrée officiel : boîte de dialogue Maintenance, options, retention, monitoring.

• Delta table maintenance in Microsoft Fabric (concepts), OPTIMIZE, VACUUM, REORG, cadence recommandée, DESCRIBE DETAIL / HISTORY.

• Lakehouse Maintenance activity (Preview), l’activité Data Factory pour orchestrer OPTIMIZE / VACUUM dans un Pipeline.

• Optimize Delta Lake tables with V-Order, où V-Order aide (Direct Lake, Warehouse), où il pénalise (Spark seul), et comment le contrôler.

• Refresh SQL Endpoint activity, pour chaîner la maintenance avec la synchronisation SQL analytics endpoint.

Vous n’avez pas besoin de lire les éditions dans l’ordre. Cette page vous donne le chemin le plus court selon votre situation : découvrir la plateforme, passer un PoC en production ou préparer vos usages IA.

En moins de cinq minutes :

1. repérez les briques essentielles dans la carte ci-dessous ;

2. choisissez un seul parcours ;

3. utilisez Chatbot Fabric Mastery dès qu’une question bloque votre progression.

La carte Microsoft Fabric

Parcours 1 — Je découvre Microsoft Fabric

Choisissez ce parcours si vous arrivez de Power BI, Azure ou d’une autre plateforme data et que le vocabulaire Fabric reste flou.

1. Tenant, Workspace, Capacity et licences : les fondations — pour comprendre la hiérarchie et les responsabilités.

2. Architecture Médaillon : Bronze, Silver et Gold — pour organiser la transformation des données sans créer un marécage.

3. Choisir son outil d’ingestion dans Fabric — pour arbitrer entre Dataflow, Pipeline, Notebook et les autres briques.

Résultat attendu : vous savez dessiner l’architecture de base et expliquer le rôle de chaque brique sans réciter le catalogue produit.

Parcours 2 — Mon PoC doit passer en production

Choisissez ce parcours si la démonstration fonctionne déjà, mais que la gouvernance, la sécurité ou le déploiement restent fragiles.

1. La checklist Fabric en 10 points avant le Go Live — pour identifier immédiatement les fondations manquantes.

2. Git Integration : versionner les artefacts et les branches — pour sortir du workspace partagé sans historique.

3. RLS, CLS et OLS : sécuriser les données Fabric — pour cartographier qui voit quoi sur Power BI, SQL et OneLake.

Résultat attendu : vous pouvez transformer les risques du PoC en plan de mise en production priorisé.

Parcours 3 — Je prépare Fabric et Power BI pour l’IA

Choisissez ce parcours si vous voulez utiliser Copilot ou un Data Agent sans confondre démonstration convaincante et réponse fiable.

1. Préparer un modèle Power BI pour Copilot — pour travailler les noms, descriptions, instructions et réponses vérifiées.

2. Fabric Data Agent ou Copilot : les différences utiles — pour choisir entre assistant généraliste et expert de domaine gouverné.

3. Fabric Copilot Capacity : isoler la consommation IA — pour éviter que les usages Copilot perturbent les traitements de production.

Résultat attendu : vous savez quelle brique IA employer, quelles données préparer et quelle consommation surveiller.

Une question précise ?

Chatbot Fabric Mastery répond à vos questions sur Microsoft Fabric et Power BI en s’appuyant sur les éditions de la newsletter.

Commencez par une question liée à votre situation :

• « Lakehouse ou Warehouse pour une équipe principalement SQL ? »

• « Où définir le RLS si les données sont aussi interrogées avec Spark ? »

• « Quel outil choisir pour ingérer une API chaque nuit ? »

• « Comment éviter le throttling provoqué par les traitements en arrière-plan ? »

Les réponses sont sourcées afin que vous puissiez ouvrir le guide d’origine et vérifier le raisonnement.

Votre rendez-vous du mardi

Chaque mardi à 8 h, Fabric Mastery traite un problème concret de Microsoft Fabric : architecture, sécurité, gouvernance, coûts, Power BI ou IA.

Vous n’avez rien à rattraper. Choisissez le parcours dont vous avez besoin aujourd’hui, puis utilisez les prochaines éditions pour progresser une décision à la fois.

À mardi prochain pour continuer à explorer ensemble les entrailles de 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 36 éditions de cette newsletter. Réponses sourcées, sans hallucination, avec un lien direct vers l’édition d’origine.

👉 Testez-le maintenant : Chatbot Fabric Mastery
🔑 Code lecture pour accès illimité (réservé aux abonnés) :

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 :

• Copilot dans Power BI Desktop, ce sont 4 fonctionnalités disponibles depuis le Copilot pane :

  • Data questions (interroger en langage naturel),

  • Verified Answers (phrases déclencheuses vers des visuels validés),

  • AI Instructions (spécifier votre vocabulaire métier),

  • Report page creation (générer pages et visuels).

• Les 3 premières briques (Data questions, Verified Answers, AI Instructions) vivent sur le semantic model donc partagées entre tous les rapports qui l’utilisent.

• L’action à lancer : ouvrir le Copilot pane, taper ”Summarize the model semantic” pour voir ce que Copilot comprend de votre modèle. Cette seule query révèle 80 % des problèmes de nommage, de descriptions et de couverture, avant même d’écrire une AI Instruction.

Avez-vous cliqué sur le bouton Copilot dans Power BI Desktop ? Vous avez tapé une question vague et vous avez obtenu un graphique bâton générique, sans contexte métier, sans les bonnes mesures = vous avez conclu que Copilot n’était pas prêt.

Je vois cette scène sur tous les clients où j’interviens. La réalité du terrain, c’est que Copilot Desktop n’est pas un chat magique, c’est un outil qui exécute très bien à condition qu’on l’utilise dans le bon ordre, avec les bons prompts, sur un modèle sémantique préparé. Le problème n’est presque jamais Copilot.

Aujourd’hui, je vous joue la démo end-to-end. Les mêmes 4 fonctionnalités que je passe systématiquement chez mes clients, avec les queries concrètes que j’utilise, les cas d’usage où ça marche, et pourquoi le semantic model reste toujours le plus important dans l’équation.

Copilot Power BI Desktop en 4 briques

Copilot dans Power BI Desktop, c’est un panneau latéral (le Copilot pane) qui expose 4 fonctionnalités distinctes, chacune adressant un usage précis :

1. Data questions : Poser des questions en langage naturel sur les données. Copilot génère un visuel + une explication texte à partir du semantic model.

2. Verified Answers : Lier des phrases déclencheuses à un visuel de rapport validé. Copilot renvoie ce visuel tel quel quand la question matche (exact ou sémantique).

3. AI Instructions : Fournir en langage naturel le contexte métier, la terminologie interne que Copilot ne peut pas deviner du modèle seul.

4. Report page creation : Générer une nouvelle page de rapport (ou modifier des visuels existants) depuis un prompt textuel.

La démo en 4 gestes, dans l’ordre chronologique

Geste 1 : Data questions, commencer par comprendre ce que Copilot comprend

Ouvrez votre rapport, cliquez sur l’icône Copilot dans le ruban Home. Le Copilot pane s’ouvre à droite.

Vous pouvez poser ces questions pour examiner le rapport que vous êtes en train d’analyser :

• “Summarize the model semantic”

• What does the report page tell me?”

On peut facilement vérifier la réponse en cliquant sur les chiffres dans la réponse pour voir le visuel associé :

Question : Comment réagit Copilot pour les questions dont la réponse n’est PAS sur les visuels du rapport mais présent dans le modèle sémantique ?

Si aucun visuel de votre rapport ne montre cette information, Copilot va quand même interroger le modèle sémantique, générer un visuel ad hoc dans le pane, et vous proposer de l’ajouter au rapport.

Par exemple : list the top 5 products sold in a column chart (avec le bouton +Add to page).

En cliquant sur “How Copilot arrived at this”, cela vous permet de vérifier les données utilisés et les filtres qui ont permis d’arriver à ce résultat.

Geste 2 : Verified Answers, vérifier les questions récurrentes

Vous connaissez bien votre rapport, la raison de pourquoi on a chaque visuel dans ce rapport et les questions associés. Au lieu de laisser Copilot sortir une réponse en naviguant dans tout le modèle sémantique, vous pouvez créer des Verified Answers. Ces questions doivent renvoyer toujours la même réponse, lorsque Copilot reconnaît la question.

Exemple : la query ”Give me a Bob/Antoine Analysis”, une analyse que seule les métiers peuvent comprendre mais que Copilot ne reconnaît pas. Pour cela, on veut qu’elle renvoie toujours le visuel “bar chart” que l’analyste a construit.

Setup en 4 étapes :

1. Sélectionner le visuel qui doit servir de réponse.

2. Menu 3 points sur le header du visuel > Set up a verified answer.

3. Ajouter les phrases connectés à la réponse vérifiée : les formulations que les utilisateurs peuvent poser (”Give me a Bob/Antoine Analysis”. Copilot suggère automatiquement des trigger phrases basées sur le visuel, accueillez ces suggestions puis affinez.

4. Optionnel : ajouter des filtres persistants (jusqu’à 10 permutations), l’utilisateur pourra alors slicer via son prompt (”*for the Northeast region*”).

Comment ça fonctionne ?

• Match exact : la phrase de l’utilisateur = la trigger phrase caractère par caractère.

• Match sémantique : Copilot reconnaît les reformulations proches.

• Stocké sur le semantic model donc se propage automatiquement à tous les rapports utilisant ce modèle.

Mon conseil : Ajoutez 5-7 Questions aux Verified Answers pour améliorer la pertinence et le trigger des réponses aux questions les plus posées pour améliorer la fiabilité de Copilot.

Geste 3 : AI Instructions, spécifier votre vocabulaire métier

Le problème qu’elle résout : votre entreprise utilise des termes internes que le modèle ne connaît pas.

Exemple : la query ”Show blabla by Employee”.

Résultat : Copilot ne comprend pas. “blabla” n’existe nulle part dans le modèle. Il vous renvoie soit un message d’incapacité.

Fix en 30 secondes :

1. Ouvrir Prep data for AI > onglet AI Instructions.

2. Écrire une phrase claire et surgicale : ”blabla means the Order Count measure”.

3. Appliquer.

Relancer la même query. Cette fois, Copilot utilise la mesure `Order Count`, groupée par `Employee`.

Bonnes pratiques :

• Spécifier du contexte temporel lorsqu’il s’agit d’une analyse de Ventes : “Any sales analysis question must include a time period. If not specified by the user, use the current fiscal year.”

• Règles de repli : “If data is missing or the question can’t be answered from the model, say so explicitly and suggest the user contacts the Data team.”

Geste 4 : Report page creation, générer des pages complètes

Envie d’aller plus vite dans la création de visuels ? Copilot peut générer des pages entières depuis un prompt textuel.

Exemple : la query : ”Create a new report page showing Product & Category Performance with a slicer for products”

Copilot génère :

• Une nouvelle page nommée automatiquement (”Product & Category Performance” ou similaire)

• Une sélection de visuels adaptés : bar chart de ventes par catégorie, KPI de revenu total, table par produit

• Un slicer produits, comme demandé

• Un layout raisonnable (pas parfait, mais un vrai point de départ)

Vous pouvez ensuite modifier les visuels en langage naturel :

• ”Change the column chart to a pie chart, total revenue by category”

Copilot remplace le visuel. Undo/redo dispos. Vous ajoutez, vous retirez, vous ajustez, le tout par prompts.

J’ai laissé ce démo de rapport BI sur mon répo github, vous pouvez dès maintenant tester Copilot avec le même report.

🥇 La Règle d’Or

Si tu dois retenir une chose : Copilot dans Power BI Desktop, ce n’est pas un chat magique, c’est un outil qui exécute bien à condition qu’on lui prépare 4 briques d’ancrage. Le semantic model AI-ready d’abord (Phase 0), les AI Instructions pour traduire votre vocabulaire métier, les Verified Answers pour spécifier les questions récurrentes, et des prompts précis pour la génération de pages. Avec ces 4 gestes, tu as un accélérateur que tes utilisateurs adoptent parce qu’il marche.

L’impact terrain est direct : vous passez d’un Power BI “outil analyste” à un Power BI conversationnel, sans changer un seul rapport existant, juste en préparant le modèle correctement.

Et vous, aujourd’hui, quel geste Copilot Desktop utilisez-vous le plus ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

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

🔗 À lire dans Fabric Mastery

• Power BI : Fini la page blanche avec Copilot (Guide Complet)

• Microsoft Fabric : Explorer tout le potentiel de Copilot dans Dataflow Gen2

• Fabric Copilot Capacity (FCC) : le guide 2026 pour activer Copilot sans throttling

• Fabric Data Agent vs Copilot : les 3 différences qui comptent en 2026

📚 Ressources pour aller plus loin

Pour approfondir le sujet et jouer la démo chez vous, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Copilot for Power BI overview : vue d’ensemble des capacités, du Copilot pane, des skills disponibles

• Ask Copilot questions about your data : data questions, ad hoc DAX, limitations

• Prepare your data for AI : Verified Answers : trigger phrases, filtres

• Prepare your data for AI to improve Copilot results : AI Data Schema + AI Instructions + Verified Answers + Approved for Copilot

• Create and edit Power BI reports with Copilot : le how-to complet de la génération de pages

• Semantic model best practices for data agent : comment votre Prep for AI sert aussi les Data Agents 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 35 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 :

• Git Integration relie un workspace Fabric à une branche Git (GitHub ou Azure DevOps). Trois opérations fondamentales :

  • Connect and sync.

  • Commit to Git (workspace → branche)·

  • Update from Git (branche → workspace).

  Chaque artefact devient un dossier de fichiers structurés `[Nom].[Type]/` versionnés.

• La règle non négociable : un workspace = une branche à un instant T. Pas de commit direct sur `main`. Chaque développeur travaille sur une feature branch dans son feature workspace, puis passe par une Pull Request (PR) pour merger.

• L’action à lancer : activer Git Integration sur votre workspace `dev`, protéger `main` via la branch policy de GitHub, et adopter le workflow branch out > modifier > change review > commit > PR > update from Git. Sans ces cinq étapes câblées, vous n’avez pas de CI, vous avez un espoir.

Pourquoi perdre du temps dans la collaboration ?

Posez-vous la question franchement. Un collègue ouvre votre semantic model “pour tester une mesure vite fait”, écrase votre schéma, sauve, et rentre chez lui. Le lendemain, vous rouvrez le workspace, votre modèle est en morceaux. Personne ne se souvient de ce qui a été touché. Aucune trace, aucun rollback, aucun coupable.

Je vois ce scénario partout. Il est le vestige direct de l’ère “Power BI Desktop”, quand deux analystes se passaient un `.pbix` sur un file share partagé. La réalité du terrain, c’est que Fabric a hérité de cette culture et l’a démultipliée. Vous n’êtes plus deux analystes à vous marcher sur les pieds : vous êtes six Data Engineers, quatre Analytics Engineers et deux Data Scientists à travailler sur le même workspace, sans branche, sans review, sans historique.

Git Integration est la brique qui résout ça.

La Continuous Integration (CI) est le socle qui garantit que le code (au sens large : semantic model, notebook, pipeline, lakehouse, rapport, dataflow…) est versionné, revu, mergé proprement. Aujourd’hui, on trace le sillon avec GitHub et je vous montre la démo end-to-end.

C’est quoi ?

Git Integration, c’est une liaison bidirectionnelle entre un workspace Fabric et une branche Git (GitHub ou Azure DevOps).

Trois piliers à graver :

• Une définition = un dossier : chaque item Fabric (Lakehouse, semantic model, notebook, pipeline…) est représenté dans Git par un dossier `[Item Display Name].[Item Type]/` contenant les fichiers de définition (JSON, TMDL, py, sql selon l’artefact). Vous pouvez lire l’historique, faire des `git diff`, revenir en arrière, comme n’importe quel code source.

• Trois opérations fondamentales :

  • Connect and sync (relier),

  • Commit to Git (pousser du workspace vers la branche),

  • Update from Git (tirer de la branche vers le workspace).

• Selective branching : depuis 2026, un workspace peut switcher de branche à la volée. Ça change tout : plus besoin de créer un workspace jetable pour chaque feature, vous branchez, vous switchez, vous mergez.

• Fournisseurs supportés : Azure DevOps (Repos), GitHub (github.com et GitHub Enterprise Cloud avec data residency `.ghe.com`). Ne cherchez pas plus loin : ni GitLab, ni Bitbucket, ni Git self-hosted à ce jour.

Mini-glossaire : les mots Git indispensables (et leur équivalent Fabric)

Avant d’ouvrir la démo, on aligne le vocabulaire. Si vous venez du monde Power BI et que Git est un mot flou, gardez cette liste sous la main.

• Repo (repository) : Le dépôt qui héberge le code versionné (dans notre cas, un dépôt GitHub). C’est là qu’atterrissent les définitions de vos items Fabric sous forme de dossiers `[Nom].[Type]/`.

• Branch (branche) : Une ligne de développement parallèle dans le repo. Vous pouvez modifier une branche sans impacter les autres. `main` est la branche de référence, `feature/xxx` sont vos branches de travail.

• Commit: Un instantané des changements que vous validez et intégrez à l’historique de la branche. Chaque commit porte un message qui explique “le pourquoi” du changement.

• Push : Envoyer vos commits vers le repo distant (côté GitHub). Dans Fabric, c’est exactement ce que fait le bouton Commit to Git du Source control pane.

• Pull / Update : Récupérer les commits distants vers votre environnement local. Dans Fabric, c’est le bouton Update from Git, quand un collègue a poussé, vous récupérez (pullez) ses changements dans votre workspace.

• Merge (fusion) : Intégrer les commits d’une branche dans une autre (ex. `feature/xxx` → `main`). Dans notre workflow : toujours via une PR, jamais à la main.

• PR (Pull Request) : Une demande de merge dans GitHub, soumise à la revue d’au moins un pair (team lead). C’est obligatoire avant d’intégrer votre feature dans `main`. La PR expose le diff et les commentaires, c’est là que la revue se fait.

• Checkout : Basculer votre environnement sur une autre branche. Dans Fabric, c’est la comande Switch branch (selective branching) ou Check out new branch (en cas de conflit) dans le Source control pane.

La démo GitHub, étape par étape

1. Le setup : connecter votre workspace à GitHub

Prérequis absolu : vous devez être workspace admin. Un member ou un contributor ne peut pas activer Git Integration. Si vous êtes coincé, remontez au tenant admin.

Étapes exactes (démo GitHub) :

1. Ouvrez votre workspace puis dans Workspace settings (icône ⚙️ en haut à droite).

2. Sélectionnez l’onglet Git integration.

3. Choisissez GitHub comme provider.

4. Si première connexion : autorisez Fabric via un Personal Access Token (PAT) GitHub (scope `repo` minimum) ou via OAuth selon votre configuration tenant.

Recommandé : Utilisez un fine-grained PAT (avec l’autorisation de read write sur le Content) :

Gardez ce token sous la main pour pouvoir l’utiliser dans l’étape ci-dessous !

5. Renseignez trois champs :

• Display Name : doit être unique pour chaque utilisateur de GitHub

• Personal Access Token : collez ici le token généré à l’étape 4.

• Repository URL : l’URL complète de votre repo (ex. `https://github.com/mon-org/fabric-data-platform`)

6. Depuis le menu déroulant, spécifiez les détails suivants concernant la branche à laquelle vous souhaitez vous connecter :

• Branche (Sélectionnez une branche existante via le menu déroulant, ou sélectionnez + Nouvelle branche pour en créer une nouvelle. Vous ne pouvez vous connecter qu’à une seule branche à la fois.)

• Dossier (Tapez le nom d’un dossier existant ou un nom pour en créer un nouveau. Si vous laissez le nom du dossier vide, le contenu est créé dans le dossier root. Vous ne pouvez vous connecter qu’à un seul dossier à la fois.)

À partir de là, Fabric fait un premier Commit to Git automatique : il génère les dossiers `[Nom].[Type]/` pour chaque item existant du workspace, les pousse dans la branche connectée, et le workspace passe en statut Synced.

2. La stratégie de branches : main + feature branches

Le pattern canonique en Fabric CI ressemble à ceci :

• `main` = branche d’intégration. Source de vérité. Aucun push direct, uniquement via Pull Request (PR).

• `feature/xxx` = feature branches, une par chantier (ex. `feature/add-sales-forecast`, `feature/refactor-fact-orders`).

• Chaque feature branch est connectée à son propre workspace, le fameux “feature workspace”.

Pour créer une feature branch + un feature workspace en un clic : depuis le workspace connecté à `main` (le `dev`), utilisez la commande Branch out to workspace dans le Source control pane. Fabric crée la nouvelle branche depuis `main`, provisionne un nouveau workspace, et exécute automatiquement un `Update from Git` pour le peupler. Vous héritez de tous les items de `main` dans un espace isolé.

Alternative : Selective branching est plus légère, vous restez dans le même workspace et vous changez simplement la branche connectée (Source control pane → Switch branch). Fabric fait un `Update from Git` sur la nouvelle branche et remet le workspace en cohérence.

Une règle terrain qui évitent 90 % des ennuis :

1 feature = 1 branche = 1 workspace. Résistez à l’envie de mutualiser plusieurs features dans un même workspace pour économiser des ressources. Le coût d’un feature workspace est marginal ; le coût d’un merge conflict cross-features est énorme.

L’erreur classique sur le terrain :

Brancher trois workspaces différents sur la même branche pour “économiser”. Résultat : trois développeurs commitent la même feature en écrasant leurs modifications mutuellement, sans que Git ne détecte de conflit puisque le pousseur en dernier gagne. Chaos garanti.

3. Change review : voir les diffs AVANT de commit

Vous êtes dans votre feature workspace, connecté à `feature/add-sales-forecast`. Vous modifiez le : ajout d’une mesure DAX, changement d’une relation, refactor d’une hiérarchie. Vous sauvez.

Ouvrez le Source control pane (icône dans la barre supérieure du workspace). Vous voyez maintenant apparaître le nombre d’Uncommitted changes.

Nouveauté 2026 majeure : le granular compare. Cliquez sur un item modifié, vous obtenez un diff propriété par propriété entre l’état actuel du workspace et l’état de la branche. C’est le `git diff` que Fabric n’a pas eu pendant deux ans.

C’est la brique qui vous évite le commit accidentel. Elle vous permet de :

• Commiter sélectivement : cochez seulement les items que vous voulez pousser (pas de “Commit all” aveugle).

• Détecter les modifications parasites : le workspace touche parfois des propriétés techniques (`lastModifiedTime`, cache metadata) qui polluent le diff. Le granular compare les révèle avant qu’elles ne finissent dans l’historique.

• Éduquer votre équipe : le diff propriété par propriété rend visible ce qui, jusqu’ici, était invisible côté Fabric.

4. Updates & sync : quand vos collègues ont poussé du code

Scénario classique de la matinée : vous ouvrez votre feature workspace, et le Source control pane affiche ”Update available”. Un ou plusieurs collègues ont poussé sur la branche à laquelle vous êtes connecté.

Le pane détaille les items entrants :

• Nouveaux items côté Git qui n’existent pas encore dans votre workspace.

• Modifiés : items qui existent des deux côtés mais dont la définition Git diverge.

• Supprimés : items présents dans le workspace mais retirés de la branche.

Cliquez Update all.

5. Ce que Git Integration ne fait PAS : les vrais garde-fous à connaître

Avant de vendre Git Integration en interne comme “la solution CI/CD complète”, assumez ses limites :

• Pas de gestion multi-environnement : Git Integration versionne, elle ne déploie pas. Dev > Test > Prod, c’est Deployment Pipelines ou `fabric-cicd`. Ne confondez pas les deux briques.

• Pas de paramétrisation par environnement : le semantic model commited contient les connexions dev. Si vous faites un `Update all` sur un workspace prod, vous récupérez les connexions dev, il faut un une variable library pour remplacer les valeurs.

• Pas tous les items sont supportés : La liste évolue à chaque release Fabric — vérifiez la doc Basic concepts in Git integration avant de compter dessus.

• Pas de secrets dans le repo : les credentials de connexion ne sont pas versionnés (par design). Bonne nouvelle pour la sécurité, contrainte pour la reproductibilité. Documentez à côté (`README.md`, wiki, Key Vault).

• PAT GitHub à durée limitée : votre PAT expire (30, 60, 90 jours selon vos policies). Anticipez la rotation, sinon Git Integration se déconnecte en silence et personne ne voit passer les updates.

🥇 La Règle d’Or

Si tu dois retenir une chose : Git Integration dans Fabric, c’est le mécanisme qui découple ton workspace de tes développeurs. Un workspace = une branche. Aucun commit direct sur main. Chaque feature vit dans sa branche, dans son workspace, et transite par une PR revue.

L’impact terrain est direct : quand Git Integration est bien configurée, un développeur peut casser son feature workspace sans casser la prod, un reviewer peut voir en 30 secondes ce qui change dans un semantic model via le granular compare, et un audit RGPD trouve la matrice de responsabilité dans l’historique Git plutôt que dans les souvenirs de l’équipe. Vous transformez Fabric d’un espace de bricolage collectif en une plateforme d’ingénierie data, sans changer un seul artefact.

Et vous, aujourd’hui, avez-vous intégré Git Integration dans vos workspaces? Répondez simplement à cet email ou ce post, je lis tous vos messages.

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

🔗 À lire dans Fabric Mastery

• Du PoC à la Production : Guide pratique des pipelines de déploiement

• Microsoft Fabric en production : la checklist en 10 points avant le Go Live

📚 Ressources pour aller plus loin

Pour approfondir le sujet et déployer Git Integration proprement, je vous recommande ces lectures essentielles issues de la documentation officielle :

• What is Microsoft Fabric Git integration? : vue d’ensemble, providers supportés, cas d’usage

• Basic concepts in Git integration : item types supportés, folder mapping, git status, permissions

• Get started with Git integration : le pas-à-pas de connexion (Azure DevOps + GitHub)

• Compare changes with granular compare : la diff experience propriété par propriété

• Development process using branched workspace : Branch out to workspace, Switch branch, Check out new branch

• Fabric CI/CD concepts and best practices : le guide de référence pour aller au-delà de la CI (release process, `fabric-cicd`, deployment pipelines)

• Automate Git integration by using APIs : Connect, Commit to Git, Update from Git en PowerShell/REST pour les pipelines automatisés

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 34 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 :

• Un domaine Fabric regroupe logiquement des workspaces autour d’un périmètre métier (Finance, Sales, Supply Chain…). Il porte la gouvernance déléguée (settings, sensitivity labels, certification) et alimente le filtre du OneLake Catalog.

• Un workspace = un seul domaine (+ éventuellement un sous-domaine). Ce n’est pas un tag transverse. Le rattachement multi-domaines n’existe pas by-design.

• L’action à lancer : verrouiller le scope Contributors de vos domaines (**AdminsOnly**), poser une alerte d’audit sur DeleteDataDomainFolderRelationsAsFolderOwner, et gérer les rattachements as-code via les REST APIs Admin ou le provider Terraform Fabric.

Combien de vos workspaces sont rattachés à un domaine, aujourd’hui ?

Posez-vous la question franchement. Ouvrez votre tenant Fabric, comptez vos workspaces, et regardez combien ont réellement un domaine assigné. La réalité du terrain, je vous la donne : entre les workspaces “test-demo-lab” créés par les métiers, les workspaces techniques oubliés par la BI centrale et les workspaces migrés depuis Power BI Premium sans nettoyage, c’est souvent la majorité qui vit sans propriétaire clair.

Résultat visible dans le OneLake Catalog : un utilisateur cherche les données Finance, et il tombe sur des artefacts dispersés dans dix workspaces, dont trois qu’un consultant a créés en 2020 et dont plus personne ne connaît le contenu. C’est exactement le marécage que la data mesh est censée éviter.

Les Domaines dans Fabric sont la brique qui résout ce problème.

C’est quoi ?

Un domaine, dans Fabric, c’est un regroupement logique de workspaces autour d’un périmètre métier (Finance, Sales, Manufacturing…). Quand un workspace est rattaché à un domaine, tous les artefacts qu’il contient héritent d’un attribut de domaine dans leurs métadonnées.

Trois piliers à graver :

• Rattachement 1:1 : un workspace est rattaché à un seul domaine (et optionnellement à un seul sous-domaine sous ce domaine).

• Gouvernance fédérée : certains tenant settings peuvent être délégués au niveau du domaine (sensitivity labels par défaut, certification, endorsement). Chaque business unit fixe ses règles.

• Consommation ciblée : le OneLake Catalog filtre les items par domaine. Un utilisateur ne voit que ce qui est pertinent pour lui.

Ne vous détrompez pas : le domaine n’est pas un mécanisme de sécurité. Il ne restreint pas l’accès aux artefacts. La visibilité et l’accès dépendent des rôles de workspace et des permissions d’item, pas du domaine.

Concepts Clés

1. Les trois rôles avant tout

Avant de créer votre premier domaine, il faut comprendre qui fait quoi. Fabric introduit trois rôles distincts autour des domaines :

a. Fabric admin : le tenant admin

Il crée, édite, supprime les domaines. Il nomme les “domain admins” et les “domain contributors”. Il rattache les workspaces via l’onglet Domains de l’admin portal. C’est le seul rôle à voir tous les domaines de tous les tenants.

b. Domain admin : l’expert métier

Idéalement, un data owner métier, pas un profil IT central. Il gère son domaine : description, image, contributors, default domain, override des tenant settings délégués. Il ne peut pas supprimer le domaine, changer son nom, ou ajouter d’autres domain admins. C’est une frontière volontaire pour éviter la dérive.

c. Domain contributor : le workspace admin habilité

Un domain contributor est un workspace admin (au sens du rôle workspace) qu’un domain admin ou un Fabric admin a autorisé à rattacher ses workspaces à un domaine, via l’onglet Domain des settings du workspace. Il n’a pas accès à l’onglet Domains de l’admin portal.

2. Les trois façons d’assigner des workspaces

Fabric propose trois méthodes pour rattacher des workspaces à un domaine, plus un mécanisme automatique.

a. Par nom de workspace

Vous cherchez les workspaces par leur nom, et vous cochez ceux à rattacher. Utile si votre convention de nommage est propre (ex. `FIN-Reporting-Prod`, `FIN-Modeling-Dev` → tous rattachés à Finance).

b. Par admin de workspace

Vous sélectionnez un user ou un security group. Tous les workspaces dont ce user (ou ce groupe) est admin sont rattachés. Attention : l’action ne concerne que les workspaces existants, pas les futurs workspaces créés.

c. Par capacité

Vous sélectionnez une ou plusieurs Fabric capacités. Tous les workspaces attachés à ces capacités sont rattachés au domaine. C’est le pattern data mesh par excellence : une capacité par département, un domaine par département.

d. Le Default domain : le mécanisme automatique

Vous désignez un domaine comme default pour des users ou security groups. Le système scanne alors les workspaces :

• Si le workspace a déjà un domaine : il est préservé (pas d’override).

• Si le workspace est non rattaché : il est rattaché automatiquement rattaché au domaine par défaut.

Et bonus : les futurs workspaces créés par ces users (ou security groups) seront automatiquement rattachés. Les users concernés deviennent en général domain contributors des workspaces ainsi rattachés.

⚠️ Point de vigilance sur l’override : un Fabric admin ou domain admin peut écraser un rattachement existant, mais uniquement si le tenant setting Allow tenant and domain admins to override workspace assignments (preview) est activé. Cette option est activée par défaut, mais elle peut avoir été coupée par prudence dans votre tenant. Les REST APIs respectent aussi ce toggle.

Mon conseil : Commencez par la méthode par capacité si vous avez adopté le modèle une capacité par département. C’est le rattachement le plus stable, le plus lisible, et celui qui aligne le mieux la gouvernance financière (SKU, CU) avec la gouvernance data (domaine).

3. Les deux angles morts qui font mal en production

Ici, on rentre dans le dur. Ces deux pièges reviennent systématiquement dans les projets et méritent chacun une section dédiée.

3.a L’admin de workspace peut retirer le domaine

Le contexte : vous avez posé un default domain pour votre équipe Finance. Tous les workspaces créés par ces users sont rattachés automatiquement au domaine Finance. Excellent. Sauf que…

Le problème : le workspace admin peut aller dans les settings de son workspace, ouvrir l’onglet Domain, et retirer le rattachement au domaine. Silencieusement. Sans que personne ne soit notifié. Et si votre stratégie de gouvernance, refacturation repose sur ce rattachement (sensitivity label par défaut, certification, filtrage OneLake Catalog), vous venez de perdre le contrôle.

L’audit Fabric enregistre l’événement sous `DeleteDataDomainFolderRelationsAsFolderOwner`. Encore faut-il le surveiller.

Voici comment le blinder, par couche :

Préventif : Restreindre les Contributors du domaine.

Dans les settings du domaine, l’onglet Contributors, trois choix :

• Tout le monde dans l’organisation (default) : n’importe quel workspace admin peut rattacher/détacher son workspace au domaine.

• Users et groupes spécifiques : seuls ces users, s’ils sont aussi workspace admins, peuvent le faire.

• Tenant et domain admins uniquement : seuls les tenant admins et domain admins peuvent rattacher/détacher.

Passez ce paramètre à “Tenant et domain admins uniquement” pour les domaines critiques (Finance, RH, conformité). Communiquez aux workspace admins que le rattachement au domaine relève de la gouvernance centrale, pas de leur périmètre.

Détectif : poser une alerte sur l’audit log.

Le schéma d’audit dédié aux domaines expose les opérations suivantes (extrait des plus importantes) :

• DeleteDataDomainFolderRelationsAsFolderOwner : Un workspace owner a retiré le domaine depuis les settings du workspace

• UpdateDataDomainFoldersRelationsAsAdmin Un tenant/domain admin a (dés)assigné des workspaces |

Je vous laisse regarder plus en détails dans la documentation.

Points de vigilance

⚠️ Le domaine n’est pas de la sécurité

Un rattachement à un domaine ne restreint pas l’accès. Un user peut ne pas être domain contributor, ni domain admin, et voir quand même les items du domaine dans le OneLake catalog si les permissions d’item l’autorisent. À l’inverse, tous les users du tenant voient tous les domaines dans le filtre du catalog, peu importe leurs droits. Le domaine sert à organiser et gouverner, pas à cloisonner.

⚠️ Les sous-domaines ont des settings limités

À date, les sous-domaines n’exposent que les general settings (nom, description). Pas d’image, pas de contributors dédiés, pas de default domain, pas d’override de tenant settings. Toute la mécanique de délégation vit au niveau du domaine parent. Ne comptez pas sur les sous-domaines pour une gouvernance différenciée fine.

⚠️ Le default domain ne rétro-applique pas

Quand vous définissez un default domain, il ne remplace pas les rattachements existants, il ne fait qu’assigner les workspaces non rattachés. Si vous voulez homogénéiser un tenant existant, le default domain seul ne suffira pas. Il vous faudra un premier passage manuel (ou en API) pour aligner l’existant, puis le default domain gère les nouveaux workspaces.

🥇 La Règle d’Or

Si tu dois retenir une chose : un workspace = un domaine, celui qui en est responsable. Le domaine porte l’ownership et la gouvernance déléguée, pas les tags, pas la classification transverse, pas la sécurité.

L’impact terrain est direct : quand vos domaines sont bien câblés, un consommateur qui cherche une donnée sait immédiatement à qui la demander, un DPO qui audite votre tenant retrouve la matrice de responsabilité en trois clics, et vos data owners métier reprennent la main sur leurs settings (sensitivity, certification) sans passer par un ticket IT. Vous transformez le tenant Fabric de marécage en plateforme structurée, sans avoir à refondre l’organisation, juste en posant la brique de gouvernance au bon endroit.

Et vous, quel est votre avis sur les domaines dans Fabric ?

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

🔗 À lire dans Fabric Mastery

• Microsoft Fabric : Comprendre OneLake, le "OneDrive" de la Data

• Microsoft Fabric : Bonnes pratiques pour la Gouvernance des workspaces

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner votre design de domaines, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Fabric domains — concepts et setup : rôles, création, rattachement, default domain, delegated settings

• Best practices for planning and creating domains : structures organisationnelles (functional, product, process, region, mixed) et méthodes d’assignation

• Audit schema for domains in Fabric : la liste complète des OperationNames à surveiller dans le Fabric activity log

• Domains — Fabric REST Admin API reference : endpoints pour les rattachements as-code

• Domain management tenant settings : override des rattachements existants et paramètres tenant liés

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 33 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 :

• Le RLS filtre les lignes d’une table pas les objets (tables, colonnes, mesures : ça, c’est l’OLS). Et il vit désormais à deux endroits.

• RLS dans le modèle sémantique Power BI : mature, dynamique (par utilisateur), mais il ne protège que Power BI.

• RLS dans OneLake Security : une seule définition, appliquée partout (Spark, SQL analytics endpoint, Direct Lake, moteurs tiers autorisés). En Direct Lake on OneLake, les deux se combinent, Power BI ne peut que restreindre ce qu’OneLake autorise.

Où définissez-vous votre RLS, au juste ?

Posez-vous la question franchement : aujourd’hui, où vit votre sécurité au niveau des lignes ?

Si la réponse est “dans Power BI, comme depuis toujours”, vous n’avez pas tort, mais le terrain a bougé. Pendant des années, le RLS était une affaire de modèle sémantique : des rôles, des règles DAX, et basta.

Le problème ? Ce filtre ne protège que Power BI. Le jour où un Data Engineer ouvre un Notebook Spark sur le même Lakehouse, ou qu’un analyste interroge le SQL analytics endpoint, votre RLS sémantique ne s’applique plus. La donnée est nue.

La réalité du terrain, c’est que dans une plateforme unifiée comme Fabric, la même table est consommée par plusieurs moteurs de calcul. Définir le filtre au niveau du rapport ne suffit plus. C’est exactement le trou que vient combler OneLake Security : un RLS défini une fois, au niveau de la donnée, et appliqué de façon cohérente quel que soit le moteur qui requête.

Pour cet article, j’ai monté un banc d’essai complet avec un star schema (`fact_sale` + dimensions), quatre personas avec de vrais comptes Entra de test, et la même question rejouée dans Spark, le SQL endpoint et Power BI. Mes quatre cobayes :

• Alice, Sales Manager EMEA, doit voir toutes les ventes EMEA.

• Bob et Carol, Sales Reps (EMEA et AMER), chacun ne voit que ses ventes.

• Dan, Finance, voit toutes les ventes de l’année courante, mais pas la colonne `Profit`.

  

Aujourd’hui, on tranche. Voici les deux RLS, ce qui les sépare, comment ils se combinent, et lequel choisir sans exposer vos données par accident.

Un même mot, deux implémentations

D’abord, levons une ambiguïté fréquente : le RLS filtre les lignes d’une table en fonction de l’identité du lecteur. Il ne masque ni une colonne (ça, c’est le CLS), ni une table ou une mesure entière (ça, c’est l’OLS).

Un commercial voit ses comptes, pas ceux du voisin : voilà du RLS.

Là où ça se corse, c’est qu’il existe désormais deux endroits pour le définir :

• Le RLS du modèle sémantique Power BI : Des rôles et des règles DAX, appliqués à chaque requête du rapport. Il protège le modèle sémantique, et lui seul.

• Le RLS de OneLake Security : récent. Des rôles définis sur la donnée dans OneLake, avec des règles en syntaxe SQL, appliqués de manière cohérente sur tous les moteurs Fabric (Spark, SQL analytics endpoint, Direct Lake) et les moteurs tiers autorisés, via les API OneLake.

La distinction tient en une phrase : le RLS Power BI sécurise un rapport ; le RLS OneLake sécurise la donnée elle-même, pour tous ceux qui la lisent.

Les deux RLS, en détail

1. Le RLS du modèle sémantique Power BI : le classique, toujours pertinent

C’est le RLS que vous connaissez. Vous créez des rôles dans Power BI Desktop, vous écrivez une règle DAX par table à filtrer, puis vous mappez vos utilisateurs aux rôles après publication.

Ce qu’il faut maîtriser :

a. Les rôles sont additifs

Si un utilisateur appartient à plusieurs rôles, les filtres s’additionnent : il voit l’union des lignes autorisées par chaque rôle. Contrairement aux permissions SQL, le principe “ce qui est refusé une fois est toujours refusé” ne s’applique pas. L’exemple canonique de la doc est parlant : un rôle `Workers` qui filtre tout (`FALSE()`) et un rôle `Managers` qui ouvre tout (`TRUE()`). Un utilisateur membre des deux… voit toutes les lignes.

Mon conseil : Visez un seul rôle par audience qui accorde toutes les autorisations nécessaires, plutôt qu’une mosaïque de rôles cumulables. Et mappez des groupes de sécurité Entra ID aux rôles, pas des comptes individuels : vous déléguez la gestion des appartenances et vous réduisez la dette de maintenance.

b. Le RLS dynamique : un seul rôle pour tous vos commerciaux

Le vrai pouvoir du RLS Power BI, c’est le dynamique : un seul rôle qui sert tous les utilisateurs grâce à `USERPRINCIPALNAME()`.

Le UserPrincipalName (UPN) est l’identifiant de connexion unique d’un utilisateur dans Entra ID / Microsoft 365, au format e‑mail, utilisé pour s’authentifier aux services cloud et permet d’être utilisé pour du RLS.

c. La performance : filtrez les dimensions, pas les faits

Le RLS applique un filtre à chaque requête DAX, ce qui peut peser sur les performances. La règle d’or de modélisation s’applique pleinement.

Filtrer une table de faits volumineuse à chaque requête, c’est se condamner à des rapports lents. Le RLS efficace repose sur un schéma en étoile propre.

Mon conseil : Appliquez vos filtres RLS sur les tables de dimension, et laissez les **relations actives** propager le filtre vers les faits. Évitez `LOOKUPVALUE` quand une relation fait le même travail.

2. Le RLS de OneLake Security : un filtre, tous les moteurs

Ici, on change de niveau. Le RLS OneLake se définit sur la donnée elle-même : depuis votre Lakehouse, Manage OneLake security, un rôle, “...” sur la table, Row security. La règle s’écrit en syntaxe SQL, pas en DAX.

Pour le rôle `SalesManagerEMEA` de mon lab, la règle ressemble à ça, une clause `WHERE` sur des valeurs statiques.

Et surtout, cette définition unique est appliquée partout : Spark, SQL analytics endpoint (en mode user identity), modèle sémantique en Direct Lake on OneLake, et moteurs tiers autorisés via les API OneLake. OneLake reste la source unique de vérité.

Ce qu’il faut maîtriser :

a. Deux modes d’accès (Preview)

Au niveau du SQL analytics endpoint, le mode d’accès choisi détermine qui gouverne la sécurité :

• User identity mode : l’identité de l’utilisateur connecté est passée à OneLake. L’accès en lecture est gouverné entièrement par les rôles OneLake (RLS, CLS, OLS y sont définis). C’est le mode de la gouvernance centralisée, cohérente sur Power BI, Notebooks, Lakehouse et SQL endpoint.

Delegated identity mode : le endpoint se connecte avec l’identité du propriétaire de l’artefact, et la sécurité est gouvernée exclusivement par les permissions SQL (GRANT/REVOKE, `CREATE SECURITY POLICY`, Dynamic Data Masking). Dans ce mode, les règles RLS définies dans OneLake ne s’appliquent pas au SQL endpoint.

Docs : OneLake Security for SQL analytics endpoints - Microsoft Fabric

b. Les contraintes à connaître avant de vous lancer

OneLake Security RLS n’est pas un copier-coller du RLS Power BI. La règle s’écrit en SQL, mais c’est un sous-ensemble volontairement étroit, et c’est là que mon test m’a le plus appris :

• La syntaxe se limite à `SELECT * FROM schema.table WHERE …`, **1000 caractères** max, avec uniquement `= <>, <, <=, >, >=, IN NOT AND OR IS BLANK IS NULL`. Pas de sous-requête, pas de jointure, pas de fonction utilisateur (`CURRENT_USER()` n’existe pas ici).

• Le RLS ne s’applique qu’aux tables Delta parquet. Sur un objet non-Delta, le rôle bloque l’accès à toute la table au lieu de filtrer.

• RLS et CLS peuvent se combiner, mais dans un seul et même rôle. Un utilisateur dans un rôle “RLS” *et* un rôle “CLS” sur la même table va produire une erreur d’exécution.

• Les rôles Admin, Member et Contributor du workspace ne sont pas filtrés. Si vous testez avec votre propre compte d’admin, vous verrez tout, et vous conclurez à tort que votre RLS ne marche pas.

La Réalité du Terrain : OneLake RLS brille sur les filtres statiques (régions, périmètres figés). Le besoin “chaque utilisateur voit sa ligne via son identité”, lui, n’est pas son terrain, c’est du ressort du RLS dynamique Power BI, ou du combo des deux (section suivante).

Docs : Row-level security in OneLake

c. L’interaction avec Power BI : Direct Lake combine les deux

C’est le moment “wow” de mon lab. Un modèle sémantique en Direct Lake on OneLake ne se contente pas d’hériter du RLS OneLake : il combine les deux niveaux.

Deux conséquences :

• Plusieurs rôles (OneLake ou Power BI) sur un même utilisateur impliquent que leurs filtres s’additionnent (comme un union, `OR`). Ajouter un rôle ne peut qu’élargir le périmètre.

• Entre les deux mondes, c’est une intersection : Power BI ne peut que restreindre ce qu’OneLake autorise, jamais l’étendre.

🥇 La Règle d’Or

Si tu dois retenir une chose : le RLS du modèle sémantique protège un rapport ; le RLS de OneLake Security protège la donnée pour tous ceux qui la lisent. Dans une plateforme unifiée, c’est au plus près de la donnée qu’il faut poser le filtre, à condition de surveiller le mode d’accès et les limites preview.

L’impact terrain est direct : en posant le RLS au bon niveau, vous arrêtez de redéfinir le même filtre dans chaque outil, et d’espérer qu’ils restent cohérents. Un seul point de vérité, c’est moins de dette technique, moins de surface d’erreur, et surtout la certitude qu’un Notebook Spark ou un SQL endpoint n’expose pas ce qu’un rapport Power BI cachait soigneusement.

Et vous, où vit votre RLS aujourd’hui ? Avez-vous déjà testé ce qu’un utilisateur voit en passant par le SQL endpoint plutôt que par votre rapport Power BI ?

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

🔗 À lire dans Fabric Mastery

• RLS, CLS, OLS Microsoft Fabric : le guide sécurité des données 2026

• Sécuriser les connexions Microsoft Fabric : bonnes pratiques et service principal

• Microsoft Fabric & VNet : Le Guide Sécurité Data Gateway

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Aide sur la sécurité au niveau des lignes (RLS) dans Power BI Desktop : bonnes pratiques de conception, RLS dynamique, performance

• Row-level security in OneLake : définition, syntaxe SQL, enforcement multi-moteurs

• OneLake Security for SQL analytics endpoints : user identity vs delegated mode, security sync, Shortcuts

• Restreindre l’accès aux données avec la RLS (Power BI Desktop) : le how-to pas à pas du RLS sémantique

• Get started with OneLake security : types d’items supportés et activation

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 32 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 démarrez un projet Microsoft Fabric.

• Quelles sont les notions à maîtriser pour bien comprendre l’architecture ?

• De quoi parle-t-on exactement lorsqu’on fait référence au Tenant, au Workspace, à la Capacity ou aux licences ?

La réalité du terrain, c’est que ces concepts sont les fondations sur lesquelles repose toute votre plateforme. Mal maîtrisés, ils génèrent des surprises coûteuses et un manque de maturité : des données stockées dans une région non prévue, des utilisateurs bloqués par leurs licences, ou des choix d’architecture à corriger en pleine production.

Ce post est un rappel des notions fondamentales de Microsoft Fabric, pour accélérer votre progression sur la plateforme et poser les bons mots sur les bons concepts dès le départ.

1. Le Tenant

Le Tenant est votre organisation dans Microsoft Entra ID (anciennement Azure Active Directory). C’est le conteneur de plus haut niveau dans la hiérarchie Microsoft Fabric. Un tenant = une entité sécuritaire et organisationnelle unique.

Ce que cela implique concrètement :

• Tous vos utilisateurs, groupes, et applications sont gérés dans ce tenant.

• Tous vos Workspaces, artefacts, et données Fabric y sont rattachés.

• La frontière du tenant est quasi-imperméable nativement : partager des données entre tenants nécessite des mécanismes dédiés (External Data Sharing, cross-tenant shortcuts).

💡 Tips : Dans un contexte de groupe avec plusieurs entités juridiques, la question “un tenant ou plusieurs ?” doit être tranchée avant tout déploiement Fabric. C’est une décision organisationnelle et réglementaire, pas technique.

2. La Home Region

La Home Region est la région Azure datacenter liée à votre tenant Fabric, choisie au moment de la création de votre tenant. C’est là que résident par défaut vos données et les métadonnées de votre tenant.

Comment la trouver ? Depuis le portail Fabric, allez sur About Microsoft Fabric et trouvez la valeur à côté de “Your data is stored in” :

Ce que cela implique concrètement :

• Cette région n’est pas celle que vous choisissez librement. Elle est héritée de la création du tenant.

• Si votre Home Region ne figure pas parmi les régions où Fabric est disponible, vous ne pourrez pas accéder à toutes les fonctionnalités Fabric. Dans ce cas, vous pouvez créer une Capacity dans une région où Fabric est disponible.

⚠️ Point de vigilance : La Home Region d’un tenant est très difficile à changer. Ce n’est pas une opération en libre-service, cela nécessite l’intervention des équipes Microsoft. Si votre organisation a des exigences de souveraineté des données (RGPD, NIS2, secteurs régulés), vérifiez votre Home Region avant tout déploiement.

3. La Capacity (F SKU)

La Capacity est le moteur de calcul que vous provisionnez dans Azure pour faire fonctionner Microsoft Fabric. Elle est définie par un SKU (F2, F8, F32, F64, F128...) qui exprime sa puissance en Capacity Units (CU).

Les trois rôles d’une Capacity :

1. Fournir la puissance de calcul pour tous les Workspaces qui lui sont rattachés (Spark, SQL, Power BI, Pipelines...).

2. Débloquer les fonctionnalités Fabric : c’est le SKU de la Capacity qui détermine ce que vos utilisateurs peuvent faire (Lakehouse, Warehouse, Eventstream, etc.).

3. Flexibilité : une seule Capacity suffit pour l’ensemble de vos usages, inutile de multiplier les capacités par workload. Data engineering, data science, ETL, reporting… tous vos workloads partagent la même puissance de calcul.

Home Region vs région de la Capacity !

Par défaut, sans configuration particulière, vos données résident dans la Home Region de votre tenant.

Lorsque vous utilisez le Multi-Geo, le compute et le stockage (incluant OneLake et le stockage spécifique aux expériences) sont localisés dans la région Multi-Geo, mais certaines métadonnées du tenant restent dans la Home Region.

En clair : si vous provisionnez votre Capacity F64 en West Europe alors que votre Home Region est France Central, vous entrez en configuration Multi-Geo. Les données des Workspaces rattachés à cette Capacity seront stockées en West Europe, mais les métadonnées du tenant resteront en France Central. Ce n’est pas automatique ni anodin, c’est un choix d’architecture explicite avec des implications réglementaires.

Multi-Geo est une fonctionnalité de Microsoft Fabric qui aide les clients multinationales à répondre aux exigences de résidence des données spécifiques à une région, à un secteur ou à une organisation.

💡 Tips : Pour la majorité des organisations françaises, provisionnez votre Capacity dans la même région que votre Home Region. Cela simplifie la gouvernance, la conformité, et évite des coûts de transfert de données inter-région.

4. Le Workspace

Le Workspace est le conteneur de travail et de gouvernance dans Microsoft Fabric. C’est là que vivent vos artefacts : Lakehouses, Warehouses, Pipelines, Semantic Models, Reports...

Les règles structurantes à connaître :

• Un Workspace est obligatoirement rattaché à une Capacity pour utiliser les fonctionnalités Fabric.

• Un Workspace ne peut être rattaché qu’à une seule Capacity à la fois.

• Les rôles dans un Workspace (Admin, Member, Contributor, Viewer) déterminent ce que chaque utilisateur peut faire sur l’ensemble des artefacts qu’il contient.

• Les Workspaces peuvent être organisés en Domaines pour structurer la gouvernance à l’échelle de l’organisation.

La question stratégique : combien de Workspaces ?

Il n’existe pas de réponse universelle. Les critères de segmentation les plus courants sont :

• Par environnement : un Workspace DEV, un TEST, un PROD par domaine fonctionnel.

• Par couche Medallion : un Workspace Bronze (ingestion), un Silver (transformation), un Gold (consommation), avec une Capacity distincte par environnement.

• Par équipe responsable : qui possède les artefacts ? Qui a les droits d’écriture ?

💡 Tips : En phase de démarrage, résistez à la tentation d’avoir un Workspace par projet. Commencez par un découplage environnement (DEV/PROD) et domaine fonctionnel. Vous affinerez la granularité au fur et à mesure que les équipes montent en maturité.

5. Les Licences utilisateur

Les licences utilisateur déterminent ce qu’une personne peut faire dans Fabric, indépendamment de la Capacity à laquelle son Workspace est rattaché.

6. Un point d’attention sur les migrations

Ce post n’est pas un guide de migration, mais deux situations méritent d’être anticipées dès la phase de conception de votre plateforme.

Migration cross-tenant

Les artefacts Fabric (Lakehouse, Warehouse, pipelines Fabric, bases KQL, etc.) ne se migrent pas nativement d’un tenant à un autre.
En cas de fusion, acquisition ou carve-out impliquant un changement de tenant, il est important d’anticiper une reconstruction.

Migration cross-région (Multi-Geo)

Les workspaces contenant des artefacts Fabric autres que Power BI ne peuvent pas être déplacés entre régions.
Avant tout déplacement, il est nécessaire de supprimer ces artefacts. Par ailleurs, les grands modèles sémantiques (Large Semantic Model Storage Format) ne peuvent pas être migrés d’une région à l’autre et doivent être redéployés comme de nouveaux modèles.

Si l’une de ces situations est à l’horizon pour votre organisation, il est essentiel de les analyser en amont, avant de démarrer le déploiement.
Ce ne sont pas des blocages, mais des contraintes structurantes qui doivent être anticipées.

Conclusion

Si tu dois retenir une chose : avant de choisir un SKU ou de dessiner votre architecture Medallion, posez-vous deux questions fondamentales :

• “Quelle est notre Home Region ?”

• “Qui est propriétaire de quoi dans nos Workspaces ?”

Tout le reste en découle.

L’impact terrain : Maîtriser ces concepts, c’est éviter les conversations difficiles en phase de déploiement, quand l’équipe métier attend le Go Live et que l’IT réalise que la Home Region ne correspond pas aux exigences de souveraineté, ou que les licences PPU ne débloquent pas les fonctionnalités attendues.

Et vous, comment avez-vous structuré la relation Capacity / Workspace dans vos projets Fabric actuels ?

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

🔗 À lire dans Fabric Mastery

• Microsoft Fabric : Révolution ou simple rebranding ?

• Microsoft Fabric : Comprendre OneLake, le "OneDrive" de la Data

📚 Ressources pour aller plus loin

• 📘 Comprendre les licences Microsoft Fabric — Microsoft Learn

• 🔗 Trouver votre Home Region Fabric — Microsoft Learn

• 🛠️ Disponibilité régionale de Microsoft Fabric

• 📘 Support Multi-Geo pour Microsoft Fabric — limitations et configuration

• 🔗 Git Integration dans Microsoft Fabric — guide de démarrage

• 🛠️ Rôles dans les Workspaces 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 31 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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à vécu ce genre de scénario sur Microsoft Fabric ? On lance un premier cas d'usage, ça fonctionne, tout tourne parfaitement, cool. Puis on en ajoute un deuxième, un troisième, … et on se pose la question de savoir quels sont les outils qui me permettent de surveiller la consommations des Capacity Units (CUs) de l’ensemble de mes workspaces.

On installe la Capacity Metrics App et la réalité saute aux yeux : un seul espace de travail monopolise toutes les Capacity Units (CUs). On se demande alors, que faire si :

• la capacity Fabric est throttlée par un workspace en particulier ?

• Comment prioriser les tâches interactives plutôt que les tâches en arrière-plan ?

• Certains pipelines sont rejetés dûs à un workspace de DEV ?

C’est la réalité du terrain quand on gère une capacité mutualisée avec 10, 20 ou 50 workspaces différents. Un seul projet de DEV ou un pipeline mal calibré prend en otage l’ensemble de votre production, sans que vous puissiez isoler chirurgicalement le coupable.

C’est pour cela que mon post se tourne vers une fonctionnalité précise pour gérer la capacité : le Surge Protection.

L’objectif : limiter la consommation de CUs au niveau de la capacity entière. Soit tout le monde trinquait, soit personne.

Et Microsoft vient de changer la donne avec le workspace-level surge protection (janvier 2026).

Voici ce que tu dois comprendre avant de l’activer en prod.

C’est quoi la Surge Protection ?

La Surge Protection limite la quantité de compute consommée par les background jobs, pour éviter que la capacity entre en état de throttling profond.

Le principe de base :

• Tu définis un seuil de rejet (rejection threshold) : au-delà, les nouvelles opérations background sont refusées.

• Tu définis un seuil de récupération (recovery threshold) : en dessous, la capacity recommence à accepter des jobs.

Ce mécanisme protège en priorité les opérations interactives (consultation de rapports Power BI, requêtes SQL...) face aux workloads lourds en arrière-plan (actualisations, notebooks, pipelines).

Cette nouveauté de février 2026 : Workspace-level surge protection

Jusqu’ici, la Surge Protection s’appliquait uniquement au niveau de la capacity, tous les workspaces partageaient les mêmes règles.

Maintenant, tu peux aller beaucoup plus fin.

Voici comment configurer concrètement le workspace-level surge protection :

1. Naviguez vers le portail d’administration : Connectez-vous et allez dans Admin Portal → Capacity settings → sélectionnez votre Fabric Capacity.

2. Activez la détection automatique : Sous la section Surge protection, activez l’option pour monitorer tous les espaces de travail et bloquer ceux qui surconsomment.

3. Paramétrez le contrôle par workspace : Activez le bouton Workspace consumption. C’est ici que la gouvernance granulaire se définit. Deux nouveaux champs vont s’afficher :

   • Le seuil de rejet (Rejection Threshold) : Vous définissez le quota maximum de CUs de la capacité totale qu’un seul workspace peut monopoliser sur 24 heures glissantes. Pour un SKU F2 par exemple, un plafond de 5 % équivaut à 2,4 CU-heures par jour.

   • Le blocage (Block) : C’est le disjoncteur chirurgical. Dès que le quota est atteint, paf, le workspace est bloqué. C’est à vous de choisir la durée de la punition : indéfinie pour forcer une discussion d’optimisation ou temporaire (un nombre d’heures spécifique).

L'automatisation c'est bien, mais la réalité du terrain exige parfois des interventions manuelles, vous avez des workspaces qui sont prioritaires par rapport à d’autres et c’est normal. Voici comment reprendre le contrôle manuel sur un workspace spécifique :

1. Dans le portail d’administration, sous “Capacity Settings”, sélectionnez la Capacité Fabric.

2. Dans le tableau “Workspace assigned to this capacity” en bas, cliquez sur l’icône d’engrenage dans la colonne Actions pour accéder aux paramètres de l’espace de travail.

Chaque workspace peut se voir attribuer l’un de ces 3 états :

• 🟢 Available : état par défaut, soumis aux règles de surge protection

• 🔴 Blocked : toutes les opérations (background ET interactives) sont rejetées — manuellement ou automatiquement

• ⭐ Mission Critical : exempté des limites de CU au niveau workspace — mais pas exempté du throttling si la capacity globale est saturée

La réalité du terrain

✅ Bénéfices réels

• Évite les états de throttling profond avec des temps de récupération longs, en déclenchant le rejet plus tôt

• Permet d’exclure les workspaces critiques (Mission Critical) de tout mécanisme de blocage automatique

• Permet de bloquer manuellement un workspace problématique pour une durée définie

• Active des bannières de notification directement dans le workspace bloqué, pour alerter les équipes concernées

⚠️ Limites

• La Surge Protection n’arrête pas les jobs en cours — seules les nouvelles opérations sont rejetées. Le 24h background % peut donc dépasser le seuil configuré le temps que les jobs actifs terminent.

• La Surge Protection ne garantit pas que les requêtes interactives ne seront pas ralenties ou rejetées. Si la capacity atteint ses limites absolues, tout est throttlé, protection active ou pas.

• La Surge Protection ne bloque pas les opérations facturées via Autoscale pour Spark.

Matrice de décision

Q1 : Est-ce que tu partages une capacity entre des workspaces de production et de développement ?

• Oui → Active la protection workspace-level et tague tes workspaces prod en Mission Critical.

Q2 : Est-ce que tu as régulièrement des alertes de throttling ou des rejections en heures ouvrées ?

• Oui → Commence par analyser le Background rejection chart dans le Fabric Capacity Metrics App. Identifie les pics avant de configurer les seuils.

Q3 : Est-ce que tu as des pipelines critiques qui ne peuvent pas être interrompus sous aucun prétexte ?

• Oui → Passe ces workspaces en Mission Critical. Et pense à les isoler dans une capacity dédiée pour une vraie garantie de service.

Q4 : Est-ce que 80% ou plus de ta capacity est consommée par des background operations ?

• Oui → La Surge Protection seule ne sera pas suffisante. La priorité est de réarchitecturer ta capacity ou de scaler.

Mon conseil

L’erreur classique sur le terrain : activer la Surge Protection avec les seuils par défaut sans avoir analysé les patterns réels de consommation.

Résultat : tu bloques des jobs légitimes, tu génères des alertes incompréhensibles pour les équipes data, et tu passes 2 heures à expliquer pourquoi le pipeline du matin n’est pas parti.

Commence par observer, ouvre le Fabric Capacity Metrics App, analyse les charts Background rejection, Interactive rejection et Utilization sur 2-3 semaines, avant de toucher aux seuils.

La bonne configuration, c’est une configuration que tu ajustes empiriquement, pas un réglage qu’on copie d’un blog.

Règle d’Or

Si tu dois retenir une chose : la Surge Protection workspace-level, c’est un gouverneur de ressources. Elle te donne enfin la granularité pour isoler un workspace déviant sans pénaliser toute ta capacity. Mais elle ne remplace pas une architecture propre : workspaces dev/test séparés des workspaces prod, seuils calibrés sur tes vrais patterns de charge, et workspaces critiques tagués Mission Critical dès le départ.

Le gain concret : fini le scénario où un notebook qui tourne en boucle le dimanche soir provoque des rejections en cascade le lundi matin sur tous tes rapports Power BI.

Et vous, pensez-vous que cette fonctionnalité va vous servir ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

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

🔗 À lire dans Fabric Mastery

• Microsoft Fabric : Comment surveiller votre capacité comme un Pro ?

• Fabric Copilot Capacity (FCC) : le guide 2026 pour activer Copilot sans throttling

📚 Ressources pour aller plus loin

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

• La documentation technique Microsoft Learn : Surge protection - Microsoft Fabric

• L’annonce détaillée sur le blog Fabric : Surge protection gets smarter: Introducing workspace-level controls (Preview)

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 30 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 :

• Dataflow Gen1 est officiellement en état **Legacy** : pas de retrait immédiat, mais zéro nouvelle feature à venir. Les Premium bénéficient d’un préavis ≥ 12 mois avant tout retrait.

• Gen2 garde l’expérience Power Query, mais ajoute 4 leviers (Staging, Fast Copy, Modern Evaluator, Partitioned Compute) et une tarification CU découplée, sur les benchmarks officiels, l’écart va jusqu’à ~20× plus rapide sur les patterns ELT.

• Pour un nouveau projet, démarrez direct en Dataflow Gen Gen2 (CI/CD) avec destination Lakehouse. Pour l’existant, migrez par lot avec “Save As” et l’API associée.

Combien de Dataflow Gen1 tournent encore dans votre tenant Power BI ? Et surtout : combien de Data Engineers de votre équipe savent vraiment ce qui change quand on passe en Gen2, quelles sont les prérequis et est-ce vraiment nécessaire ?

La réalité du terrain, c’est que la majorité des organisations que je vois en mission ont accumulé des dizaines, parfois des centaines, de Dataflow Gen1 sur 8 ans d’historique Power BI. Et quand Microsoft annonce que Gen1 entre en état Legacy, deux réflexes apparaissent : la panique migration ”on doit tout refaire pour hier” ou “"on ne voit pas l’intérêt donc on attend”.

Aujourd’hui, on tranche. Ni panique, ni déni : on regarde ce que dit Microsoft, ce que disent les benchmarks officiels, et ce qui se passe vraiment quand on bascule un Dataflow en production.

C’est quoi, Dataflow Gen1 et Dataflow Gen2 ?

Les deux sont des artefacts de préparation de données low-code, basés sur Power Query et le langage M. Ils permettent d’ingérer, nettoyer et publier des tables réutilisables sans écrire de code Spark ou SQL. Trois différences fondamentales :

1. Gen1 (aussi connu sous le nom de Flux de données Power BI) vit dans Power BI, écrit dans un stockage Power BI interne, et son moteur de calcul est lié à la capacité Premium.

2. Gen2 vit dans Fabric (du workload Data Factory), peut écrire dans n’importe quelle destination Fabric ou externe (Lakehouse, Warehouse, ADLS Gen2, Azure SQL DB, Snowflake, SharePoint…), et son compute est facturé au Capacity Unit (CU selon la consommation réelle.

3. Gen2 (CI/CD) est la variante “moderne” de Gen2 : elle embarque par défaut le Modern Query Evaluator (le nouveau moteur d’évaluation M) et débloque les leviers de scalabilité (Fast Copy, Partitioned Compute, Staging).

Le statut officiel depuis avril 2026 : Gen1 = Legacy ! (existant supporté, plus d’innovation), le but : Gen2 = la cible.

La réalité du terrain

✅ 1. Gen1 n’est pas retiré demain, mais l’innovation est stoppée

Microsoft a été clair : les Dataflow Gen1 existants continueront de tourner, et pour les capacités Premium, un préavis d’au moins 12 mois sera donné avant tout retrait. Aucune date butoir publiée à ce jour.

En revanche :

• Plus aucune feature ne sera ajoutée à Gen1.

• Les artefacts Gen1 sont désormais marqués “Legacy” dans le menu **New Artifact**.

• Le support se limite aux correctifs critiques implémentables sans changer l’architecture.

✅ 2. Gen2 garde Power Query, le code est transférable

L’expérience d’authoring est identique, les connecteurs sont là, vos transformations existantes se rejouent telles quelles dans Gen2 via la fonction Save as Dataflow Gen2.

Ce qui change, c’est l’environnement d’exécution :

• Moteur de calcul Fabric élastique (auto-scaling sans tuning manuel).

• Exécution parallélisée des partitions et des étapes.

• Diagnostics enrichis (timing par étape, foldability, comportements connecteurs).

✅ 3. Les 4 leviers Gen2, et quand les utiliser

• Staging : Matérialiser une fois pour réutiliser plusieurs fois en aval pour des Patterns ELT, requêtes dérivées multiples

• Fast Copy : Ingestion haut-débit vers OneLake (Lakehouse) pour du Bulk-load Parquet/CSV depuis ADLS, peu ou pas de transformations

• Modern Evaluator : Nouveau moteur M, par défaut sur Gen2 (CI/CD) pour des transformations lourdes, non-foldables, row-by-row

• Partitioned Compute (preview) : Évaluation parallèle des partitions pour des sources fichiers partitionnables (Combine Files)

Les benchmarks officiels Microsoft (avril 2026), sur des scénarios canoniques exécutés sur Gen1 vs Gen2 (CI/CD) donnent les ordres de grandeur suivants :

✅ 4. La tarification : CU à la consommation, plus capacité Premium “always-on”

C’est le changement structurel le plus mal compris.

• Gen1 : votre compute est inclus dans la capacité Premium achetée, vous payez la capacité même quand les Dataflow ne tournent pas.

• Gen2 : la consommation est facturée en CU (Capacity Units), alignée sur le runtime Fabric. Vous payez ce que vous consommez réellement, avec un scaling élastique pour les bursts.

Le point que Microsoft a explicitement clarifié à FabCon Europe en septembre 2025 (avec les Dataflow Gen2 pricing improvements) : les gains de performance se traduisent directement en gains de coût. Sur Gen2, plus une transformation s’exécute vite, moins elle consomme de CU. Le ratio n’est plus “compute payé d’avance, performance subie”, c’est “compute facturé à l’usage, performance qui réduit la facture”.

Par exemple, sur les patterns du benchmark Microsoft :

• Sur un ELT qui passe de 2h42 (Gen1) à 5m53 (Gen2 avec Staging + Fast Copy), vous ne gagnez pas seulement ~27× sur le temps, vous réduisez dans des proportions équivalentes la consommation CU de ce workload sur votre capacité.

• Sur un bulk-load Parquet Lakehouse qui passe de 1h42 à 7m43, la même logique s’applique : Fast Copy fait le travail plus vite, donc utilise moins de CU sur la durée.

Conséquence côté FinOps :

• Workloads intermittents ou saisonniers : Gen2 peut baisser nettement la facture, car vous ne payez plus une capacité Premium dormante 24/7.

• Workloads très denses : dimensionnez finement votre SKU pour éviter le throttling, mais les gains de perf compensent une partie significative de la consommation.

💡Mon conseil : avant de migrer en bulk, faites tourner un échantillon représentatif (≈ 10 % de vos Gen1) en Gen2 pendant 1 cycle de facturation. Mesurez deux choses, pas une seule : le temps de refresh ET la consommation CU via la Fabric Capacity Metrics App. C’est la combinaison des deux qui vous dit si vous gagnez vraiment, pas le temps d’exécution seul !

Points de vigilance / Pièges à Éviter

⚠️ Pro et PPU : pas encore de chemin Gen2 clair

Le blog Microsoft est explicite : pour les licences Pro et Premium Per User (PPU), des “paths Gen2” sont annoncés mais pas encore livrés au moment où j’écris. Si votre tenant est en Pro/PPU sans Fabric, Gen1 reste votre option par défaut, et Microsoft a confirmé qu’il continuera de tourner. Surveillez les annonces, mais ne vous mettez pas la pression pour migrer ce qui n’a pas encore de destination.

⚠️ Partitioned Compute est en preview

Très puissant (gain ~20× sur Combine Files), mais preview donc pas encore couvert par les SLA de production. Pour vos workloads critiques, attendez la GA ou prévoyez un fallback Modern Evaluator. Vérifiez l’état dans la Data Factory Roadmap.

⚠️ “Save as Dataflow Gen2” ne migre pas tout

La fonction couvre la majorité des transformations courantes, mais certains scénarios anciens (connecteurs custom, paramètres particuliers) peuvent nécessiter un ajustement manuel. Testez chaque Dataflow migré contre son équivalent Gen1 pendant 1-2 cycles avant de débrancher Gen1. Ne supprimez jamais le Gen1 source tant que le Gen2 n’a pas tourné en parallèle.

⚠️ Connecteur “Dataflows” en aval : la limitation qui piège les migrations

Quand vous migrez un Gen1 vers Gen2 et que des items en aval (modèles sémantiques, autres Dataflow) consomment votre Gen2 via le connecteur Dataflow, la donnée transite par une API interne. Cette API peut subir des timeouts intermittents, ce qui se traduit par des échecs de refresh côté items consommateurs, souvent avec un message d’erreur trompeur du type ”The key didn’t match any rows in the table.”. Ce n’est pas un problème de données, c’est le backend qui n’a pas pu retourner les résultats à temps.

La parade officielle Microsoft : **configurez une destination** (Lakehouse ou Warehouse) sur chaque Gen2 source, puis modifiez les items en aval pour qu’ils lisent **via le connecteur Lakehouse / Warehouse**, pas via le connecteur Dataflows. Vous court-circuitez l’API interne et la fiabilité du refresh remonte significativement. Détail dans la doc Data Factory limitations.

🥇 La Règle d’Or

Si tu dois retenir une chose : Dataflow Gen1 n’est pas mort, mais il est gelé. Tout nouveau Dataflow doit naître en Gen2 (CI/CD), pas pour suivre la tendance, mais parce que les 4 leviers de scalabilité et le modèle CU vous évitent de payer pour une capacité dormante. Pour l’existant, migrez par vagues, en commençant par geler les créations Gen1 et en validant chaque Dataflow critique en parallèle avant cutover.

L’impact terrain : vous arrêtez d’empiler de la dette technique sur une plateforme legacy, vous valorisez vos refresh sans surconsommer de CU, et vous ouvrez la porte à Direct Lake sur Lakehouse, qui est la combinaison naturelle de Gen2 pour les rapports Power BI à grande échelle.

Et vous, où en êtes-vous dans l’inventaire de vos Dataflow Gen1 ? Répondez simplement à cet email ou ce post, je lis tous vos messages.

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

🔗 À lire dans Fabric Mastery

• Ingestion Microsoft Fabric : Dataflow, Pipeline ou Notebook ? Guide complet 2026

• Microsoft Fabric : Explorer tout le potentiel de Copilot dans Dataflow Gen2

📚 Ressources pour aller plus loin

Pour approfondir le sujet et affiner vos choix d’architecture, je vous recommande ces lectures essentielles issues de la documentation officielle :

• Choisir la bonne stratégie Dataflow Gen2 — Decision guide

• Créer votre premier Dataflow Gen2]

• Migrer un Dataflow Gen1 vers Gen2 avec “Save As”

• Migration Gen1 → Gen2 (CI/CD) — Scénarios programmatiques

• Tarification Dataflow Gen2 — Standard / High Scale / Fast Copy

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 (ce code est réservé aux abonnés Fabric Mastery) :

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 !

🔗 À lire dans Fabric Mastery

• Architecture Médaillon Microsoft Fabric : Bronze, Silver, Gold expliqués

• Data Stores Microsoft Fabric : Lakehouse vs Warehouse vs KQL

• Microsoft Fabric : Tout savoir sur le OneLake

• Ingestion Microsoft Fabric : Dataflow, Pipeline ou Notebook ?

📚 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 (ce code est réservé aux abonnés Fabric Mastery) :

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 !

🔗 À lire dans Fabric Mastery

• Fabric Data Agent vs Copilot : les 3 différences qui comptent en 2026

• Microsoft Fabric : Comment surveiller votre capacité comme un Pro ?

• Power BI : Fini la page blanche avec Copilot

📚 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 (ce code est réservé aux abonnés Fabric Mastery) :

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 !

🔗 À lire dans Fabric Mastery

• Fabric Copilot Capacity (FCC) : le guide 2026 sans throttling

• Power BI : Fini la page blanche avec Copilot

• Copilot Dataflow Gen2 Fabric : guide pratique et cas d’usage

📚 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 25 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 !

🔗 À lire dans Fabric Mastery

• Sécuriser les connexions Microsoft Fabric : bonnes pratiques et service principal

• RLS, CLS, OLS Microsoft Fabric : le guide sécurité des données 2026

📚 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 24 é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 (ce code est réservé aux abonnés Fabric Mastery) :

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 !

🔗 À lire dans Fabric Mastery

• Migration Power BI Premium → Microsoft Fabric

• Microsoft Fabric : Révolution ou simple rebranding ?

  ---

📚 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 (ce code est réservé aux abonnés Fabric Mastery) :

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 ! 👇

🔗 À lire dans Fabric Mastery

• RLS, CLS, OLS Microsoft Fabric : le guide sécurité des données 2026

• Microsoft Fabric & VNet : Le Guide Sécurité Data Gateway

📚 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