Avant d'ouvrir Copilot, votre RSSI pose la question qui fâche : les données utilisées par Copilot restent-elles dans la région ?

Pour répondre, il faut séparer trois sujets : qui peut utiliser Copilot (et depuis quelle application), où l’IA traite les données et quelles traces restent ensuite. C’est parti !

⚡ En 30 secondes

Ce qu’il faut retenir :

• Europe, pas France. Avec Azure OpenAI opéré par Microsoft, le traitement IA d’une capacité située dans l’EU Data Boundary reste dans cette frontière. Ce n’est pas une garantie « France uniquement ».

• Vos valeurs, pas seulement le schéma. Copilot peut traiter des données réelles. Dans certains scénarios, votre question et son contexte restent 48 h en cache, notamment dans la région d’origine du tenant.

• Pas tous les interrupteurs. Vérifiez qui a accès à Copilot, quel fournisseur d’IA est activé et quelles régions sont autorisées. « Processed outside » et « stored outside » n’ouvrent pas la même chose.

C’est quoi, le traitement des données par Copilot ?

Copilot n’envoie pas votre question seule. Il l’enrichit d’un contexte, appelé grounding ou données d’ancrage, puis transmet le tout à un modèle de langage (LLM). Il transforme ensuite la réponse en texte, en DAX ou en contenu de rapport.

Ce contexte peut contenir des métadonnées, mais aussi des valeurs métier. Trois questions sont donc à traiter séparément :

1. 🔐 Qui peut utiliser Copilot, et depuis quelle application ? → sections 1 et 7

2. 🌍 Où partent vos données, et qui les traite ? → sections 2 à 5

3. 🗂️ Quelles traces restent après la réponse ? → section 6

La réalité du terrain

Etape 1. Activer Copilot : qui fait quoi, et dans quel ordre

Les prérequis

• ✅ Une Capacité payante Fabric F2 ou supérieure, ou Power BI Premium P1 ou supérieure, dans une région prise en charge.

• ✅ Ou une Fabric Copilot Capacity (FCC). Elle permet aux utilisateurs affectés d’utiliser Copilot avec des Workspaces Pro ou PPU. Elle centralise la consommation IA ; les requêtes sur le modèle sémantique restent à la charge de la Capacité de ce modèle.

• ❌ Une licence Pro ou PPU seule, ou une Capacité d’essai (Trial).

• ❌ Private Link ou un réseau fermé : selon la procédure Power BI, Copilot n’y est pas pris en charge à ce jour. Si cette contrainte est obligatoire, ne contournez pas votre architecture pour faire apparaître le bouton.

L’activation, rôle par rôle

1. Administrateur Fabric (portail d’administration > Tenant settings > Copilot and AI) :

   • vérifiez Users can use Copilot and other features powered by Azure OpenAI, activé par défaut ;

   • limitez le pilote à un groupe de sécurité Entra, puis sélectionnez Apply.

   Attention : ce réglage ouvre Copilot dans toutes les charges de travail Fabric, pas seulement dans Power BI.

2. Administrateur de Capacité : contrôlez les Delegated tenant settings et les groupes effectifs de chaque Capacité (Capacity settings > Fabric capacity > nom de la Capacité > Delegated tenant settings).

3. Utilisateur du service Power BI : vérifiez la Capacité du Workspace et vos droits.

4. Créateur dans Power BI Desktop : sans FCC, il vous faut un Workspace compatible où vous êtes Admin, Member ou Contributor. Desktop vous demande de le choisir au premier usage, et vous pouvez le changer ensuite dans ses paramètres. Le modèle de langage ne tourne pas sur votre poste.

Conséquence :

⚠️ Couper Copilot au niveau du tenant ne suffit pas. Le réglage est délégué automatiquement aux administrateurs de capacité, et l’administrateur du tenant ne peut pas désactiver cette délégation. Une capacité peut donc activer Copilot même si le tenant l’a désactivé. Le réglage hors zone, lui, reste désactivé et n’est pas délégué automatiquement.

Le Copilot autonome, qui cherche parmi plusieurs éléments, a son propre réglage : Users can access a standalone, cross-item Copilot in Power BI experience (preview). Il exige que le réglage Azure OpenAI soit activé au niveau du tenant : l’activer au niveau d’une capacité ne suffit pas.

Conséquence:

Etape 2. Quelles données partent réellement vers l’IA

Copilot ne récupère que les données auxquelles l’utilisateur a accès. Mais ce contexte va bien au-delà du schéma. Selon le fonctionnement documenté de Copilot dans Fabric, il peut contenir :

• l’historique de la session en cours ;

• des métadonnées, comme le schéma du modèle sémantique ou celles d’un visuel de rapport ;

• des points de données précis, comme ceux affichés dans un visuel ;

• des méta-prompts, c’est-à-dire des instructions ajoutées pour chaque expérience.

Pour une question de données, c’est encore plus net : le modèle produit d’abord une requête, évaluée sur le modèle sémantique, puis Copilot renvoie le résultat de cette requête à Azure OpenAI pour en obtenir un résumé. Et vous ne pouvez ni intercepter ni modifier ces données avant leur envoi.

Les bonnes pratiques Prep Data for AI dans Power BI améliorent ce contexte et la qualité des réponses. Elles ne remplacent pas le contrôle d’accès.

Mon conseil : qualifiez les données des réponses attendues, pas seulement les noms des tables. Un résultat agrégé reste une donnée métier à gouverner.

Etape 3. Où sont-elles traitées : France, Europe ou ailleurs ?

Réponse courte : en Europe, pas forcément en France. Le service Azure OpenAI qui alimente Copilot dans Fabric est déployé dans des centres de données américains (East US, East US2, South Central US et West US) et dans l’EU Data Boundary.

Voici les correspondances documentées, selon la zone de votre Capacité :

• Capacité aux États-Unis = traitement aux États-Unis, sans sortie de zone. Action : activer Copilot.

• Capacité dans l’EU Data Boundary, comme France Central = traitement dans l’EU Data Boundary, sans sortie de zone. Action : activer Copilot.

• Capacité au Royaume-Uni = traitement dans l’EU Data Boundary, donc hors zone. Actions : activer Copilot et autoriser le traitement hors zone.

• Australie, Brésil, Canada, Inde, Asie, Japon, Corée, Afrique du Sud, Émirats arabes unis = traitement aux États-Unis, donc hors zone. Actions : activer Copilot et autoriser le traitement hors zone.

Hors des États-Unis et de l’EU Data Boundary, Copilot est d’ailleurs désactivé par défaut, tant que l’administrateur n’autorise pas ce traitement hors zone.

Source : disponibilité et flux géographiques de Copilot Fabric.

Une frontière n’est pas un datacenter. L’EU Data Boundary ne promet ni un traitement dans la seule région France Central, ni un traitement exclusivement en France.

Etape 4. Azure OpenAI ≠ OpenAI sous-traitant

Les noms se ressemblent, pas les flux. Fabric peut s’appuyer sur deux fournisseurs, chacun avec son propre réglage :

• Azure OpenAI, opéré par Microsoft : activé par défaut. Ce service n’utilise ni les services publics ni les API d’OpenAI, et OpenAI n’a pas accès à vos données.

• OpenAI comme sous-traitant de Microsoft : désactivé par défaut. L’activer peut faire sortir vos données de la frontière de conformité de Fabric, vers un système tiers dont les contrôles de conformité peuvent être moins stricts. Ces modèles restent inclus dans l’EU Data Boundary, sauf exceptions précisées dans sa documentation.

⚠️ Une exception compte : avec les modèles opérés par OpenAI dans les Microsoft Generative AI Services, un identifiant utilisateur pseudonymisé est traité et stocké aux États-Unis, pour des finalités opérationnelles et de sécurité. Selon la documentation EU Data Boundary, les autres données concernées sont traitées dans l’EU Data Boundary et ne sont pas stockées par OpenAI.

Le réglage s'appelle Users can use Copilot, AI Agents and other AI experiences powered by OpenAI as a Microsoft Subprocessor :

Mon conseil : gardez le sous-traitant désactivé si le périmètre validé est Azure OpenAI. Certaines fonctionnalités ou certains modèles peuvent n’être disponibles qu’avec lui : son ouverture doit donc être une décision contractuelle explicite, pas une case cochée pour débloquer un écran.

Etape 5. « Processed outside » ≠ « stored outside »

Les libellés sont presque identiques. Le verbe change le périmètre :

• Data sent to Azure OpenAI can be processed outside your capacity’s geographic region, compliance boundary, or national cloud instance : l’IA peut traiter vos données hors de la zone de votre Capacité. C’est le réglage hors zone (cross-geo) de la section 3.

• Data sent to Azure OpenAI can be stored outside your capacity’s geographic region, compliance boundary, or national cloud instance : l’historique de conversation peut être stocké hors de votre zone. Ce réglage concerne Copilot dans les notebooks et les agents de données Fabric, qui conservent cet historique d’une session à l’autre. Si l’utilisateur ne l’efface pas, il est gardé 28 jours.

Un troisième réglage, Data sent to OpenAI as a Microsoft Subprocessor can be processed outside…, fait la même chose pour les modèles opérés par OpenAI, pas pour Azure OpenAI.

Les trois sont désactivés par défaut. Surtout, ils ne s’appliquent qu’aux capacités situées hors de l’EU Data Boundary et des États-Unis.

💡 Mon conseil : si toutes vos Capacités sont dans l’EU Data Boundary, ces réglages ne vous concernent pas : laissez-les désactivés. Si vous en activez un, par exemple pour une Capacité au Royaume-Uni, documentez pourquoi.

Etape 6. Fin de session ≠ Aucune trace

En règle générale, Copilot ne se souvient pas de l’historique des sessions précédentes et ne l’utilise pas. Mais il reste des traces, à plusieurs endroits :

• Un cache de 48 heures : dans certains scénarios, Copilot met en cache votre prompt et les données d’ancrage pendant 48 heures. Ce cache se trouve à deux endroits : dans le navigateur de l’utilisateur, et dans un premier cache côté serveur, situé dans la région d’origine (home region) du tenant et conservé à des fins d’audit. Rien n’est mis en cache dans le service Azure OpenAI ni là où se trouvent les GPU.

• L’historique des expériences conversationnelles (Copilot dans les notebooks, agents de données) : 28 jours par défaut, voir la section 5.

• Les journaux Purview, si vous les configurez (voir plus bas).

⚠️ Le cache serveur suit le tenant, pas forcément votre Capacité. Pour connaître la région d’origine de votre tenant : Help > About > Your home region is.

Côté Purview, l’option Allow Microsoft Purview to secure AI interactions du portail d’administration Fabric est activée par défaut. Cela ne prouve pas que la collecte et la rétention sont configurées.

Vérifiez trois points :

• une stratégie de collecte, comme DSPM for AI – Capture interactions for Copilot experiences, pour capturer prompts et réponses ;

• une stratégie de rétention sur l’emplacement Microsoft Copilot Experiences ;

• la facturation à l’usage (pay-as-you-go), requise pour gérer ces interactions avec Purview.

Prompts et réponses sont aussi capturés dans le journal d’audit unifié. Ils sont stockés dans la boîte aux lettres de l’utilisateur, ce qui permet de les retrouver avec eDiscovery.

Etape 7. Droit de lecture ≠ destination

Copilot utilise les droits de l’utilisateur, sans permission supplémentaire : il respecte les rôles de workspace, les permissions sur les éléments et la sécurité des données. Mais la RLS et l’OLS ne s’appliquent pas aux rôles Admin, Member ou Contributor d’un Workspace, qui ont des droits d’édition. Testez donc les parcours lecteurs avec un compte Viewer.

Deux réflexes à oublier :

• Masquer une colonne : Copilot ignore bien les objets masqués, mais ce n’est pas une règle de sécurité.

• Compter sur un filtre de page : ce n’est pas une RLS. Microsoft précise que les filtres du rapport ne s’appliquent pas aux questions de données posées à Copilot.

C’est la sécurité du modèle qui doit porter la restriction.

Reste la destination : la RLS limite ce qu’un utilisateur lit, pas l’endroit où partent ensuite les résultats. Or vos données peuvent être interrogées depuis plusieurs applications.

Depuis quelle application ?

• Service Power BI ou Fabric (navigateur) : Capacité du Workspace ou FCC.

• Power BI Desktop : un Workspace compatible, ou une FCC.

• Application mobile Power BI : le rapport doit se trouver dans un workspace pris en charge, avec Copilot activé.

• Copilot autonome : son réglage active aussi l’agent Power BI dans Microsoft 365.

• Agents de données Fabric : une fois publiés, ils peuvent être utilisés depuis Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry ou n’importe quel client MCP. Ce sont des utilisateurs qui les y connectent, pas forcément un administrateur. Leurs réponses peuvent alors sortir de la frontière de conformité ou de la zone géographique de Fabric, et suivent les règles du service qui les reçoit.

• Copilot Chat et Copilot Cowork, via Fabric IQ : Copilot peut chercher les rapports Power BI pertinents et utiliser leurs modèles sémantiques pour répondre. Dans Cowork, le plugin Fabric IQ est installé par défaut. Les droits de l’utilisateur s’appliquent, RLS et OLS comprises. Une licence Microsoft 365 Copilot Premium est requise.

⚠️ Point d’attention sur le dernier point, sur Copilot Chat et Cowork :

• Le réglage principal est dans Microsoft 365. Le réglage Fabric data available in M365 Copilot, dans le centre d’administration Microsoft 365, est activé par défaut. L’utilisateur n’a pas besoin d’accès à Copilot dans Fabric. Et contrairement à Copilot dans Fabric, les workspaces Pro et PPU sont pris en charge.

• L’EU Data Boundary tient, sauf avec Anthropic. Pour un client européen, Microsoft Copilot est un service EU Data Boundary. Mais les modèles Anthropic en sont actuellement exclus. Ils sont désactivés par défaut dans l’EU Data Boundary et au Royaume-Uni. Un administrateur peut toutefois les activer, et Cowork peut alors les utiliser.

• Les données sortent ensuite de Power BI. Cowork peut réutiliser une réponse dans un e-mail, un document ou une réunion. Or la DLP n’y est pas encore prise en charge.

💡 Mon conseil : avant de publier un agent de données, décidez où il a le droit d'être utilisé. Soyez particulièrement vigilant avec le serveur MCP : il accepte n'importe quel client. Associez l’administrateur Microsoft 365 à votre revue. Les réglages Fabric data available in M365 Copilot et AI providers operating as Microsoft subprocessors font partie de votre périmètre Power BI.

✅ Checklist avant d’ouvrir Copilot

• ☐ Capacité F2+/P1+ (ou FCC) dans une région prise en charge, sans Trial ni Private Link

• ☐ Réglage Azure OpenAI limité à un groupe pilote

• ☐ Délégations vérifiées sur chaque Capacité

• ☐ Copilot autonome : décision explicite

• ☐ Sous-traitant OpenAI désactivé, sauf décision contractuelle

• ☐ « Processed outside » et « stored outside » désactivés, sauf pour une Capacité hors EU Data Boundary et hors États-Unis

• ☐ Région d’origine du tenant notée (Help > About)

• ☐ Purview : collecte, rétention et facturation à l’usage configurées

• ☐ Canaux ouverts listés et testés avec un compte Viewer

• ☐ Agents de données : services autorisés validés avant publication (Microsoft 365, Copilot Studio, Foundry, MCP)

• ☐ Microsoft 365 : réglage Fabric data available in M365 Copilot et sous-traitant Anthropic vérifiés

🥇 La Règle d’Or

Si vous ne devez retenir qu’une chose : activer Copilot ouvre l’accès, mais la résidence des données se vérifie ailleurs (fournisseur, régions autorisées, cache et rétention).

Pour revenir à la question de départ : avec Azure OpenAI opéré par Microsoft et sans autorisation hors zone, le traitement IA de votre Capacité « France Central » reste dans l’EU Data Boundary, sans garantie « France uniquement ». Et dans certains scénarios, le cache suit la région d’origine du tenant.

Séparer ces sujets donne au métier un périmètre clair, et à vos admins des contrôles vérifiables.

Et chez vous, qu’est-ce qui bloque encore ?

Répondez simplement à cet email ou ce post, je lis tous vos messages.

Bon mardi et à la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

🔗 À lire dans Fabric Mastery

• Fabric Copilot Capacity : isoler la consommation IA — la centralisation des coûts, distincte du lieu de traitement.

• RLS Power BI ou OneLake Security : choisir la frontière — les contrôles de lecture avant d’ajouter un consommateur IA.

• Tenant, Workspace, Capacity : les fondamentaux Fabric — les périmètres administratifs de votre déploiement.

📚 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 :

• 🛠️ Activer Copilot pour Power BI — service, Desktop et délégation.

• 🛠️ Paramètres Copilot et agents du tenant — portée des autorisations et historique intersessions.

• 📘 Comment Copilot dans Fabric fonctionne — grounding, cache, appels IA et restitution.

• 📘 Disponibilité régionale et flux géographiques de Copilot — zones de traitement.

• 📘 OpenAI comme sous-traitant dans Fabric — opérateur, engagements et exclusions.

• 🔗 Gouverner Copilot Fabric avec Microsoft Purview — audit, collecte et rétention.

Aujourd’hui, on va parler d’un Workspace que quasiment tous les utilisateurs Power BI possèdent, mais qui est parfois oublié lorsque l’on construit sa gouvernance : My Workspace.​‌

Sur le papier, son rôle est simple : permettre à chacun de créer et tester du contenu dans son espace personnel.​‌

La question qu’on se pose : Peut-on tout simplement désactiver My Workspace pour l’ensemble du tenant et si oui, comment ?​‌

⚡ En 30 secondes

1. My Workspace ne se désactive pas avec un simple tenant setting. Chaque utilisateur dispose de son espace personnel et les paramètres d’administration permettent surtout d’en encadrer les usages.

2. Le vrai risque est qu’un espace personnel devienne un canal de diffusion non gouverné. Un rapport créé « juste pour tester » peut progressivement être partagé et utilisé par plusieurs personnes sans passer par vos Workspaces collaboratifs et votre cycle de gouvernance habituel.

3. Pour aller jusqu’au blocage opérationnel, une approche consiste à isoler les My Workspaces sur une F-SKU dédiée, empêcher leur réaffectation, puis mettre cette capacité en pause. La capacité pausée ne consommant plus de ressources, le contrôle peut rester en place sans faire tourner inutilement du compute.

Chaque utilisateur Fabric possède son propre espace de travail personnel. En revanche, il existe un moyen d’administration qui le rend indisponible : concentrer tous les espaces personnels sur une capacité Fabric dédiée, empêcher leur réaffectation, puis mettre en pause cette capacité.

Ne vous y trompez pas : cette méthode détourne une fonction d’arrêt de capacité pour produire un verrou de gouvernance. Il doit donc être traité comme un contrôle réversible, supervisé et assumé et c’est ce qu’on va voir concrètement par la suite.

S'abonner maintenant

La méthode « F-SKU en pause »

Le mécanisme repose sur trois briques :

• une capacité F-SKU Azure dédiée aux My Workspaces,

• le tenant setting qui interdit aux propriétaires de revenir en capacité partagée,

• et la pause de la capacité.

Tant que cette dernière reste en arrêt, les contenus qui lui sont affectés deviennent indisponibles. Les Workspaces collaboratifs gouvernés restent sur leurs Capacités habituelles.

La réalité du terrain

✅ 1. Les tenant settings réduisent le risque, mais ne ferment pas My Workspace

Quatre réglages dans le portail d’administration de la plateforme sont souvent cités dans la même discussion :

• “Allow shareable links to grant access to everyone in your organization” permet de retirer l’option People in your organization pour restreindre le partage de rapports à toute les personnes de l’entreprise.

• “Restrict content with protected labels from being shared via link with everyone in your organization” permet de restreindre le partage de contenus portant un étiquette de sensibilité de protection.

• “Create workspaces” contrôle la création de Workspaces collaboratifs. Il ne supprime pas le My Workspace automatiquement attribué à chaque utilisateur.

• “Export to Excel” et “Export reports as PowerPoint presentations or PDF documents” peuvent être désactivés ou limités à des groupes.

Pour structurer ce qui doit remplacer l’usage personnel, rattachez les contenus durables à des Workspaces avec un propriétaire, un domaine et des règles documentées. J’ai détaillé cette logique dans le guide Fabric Domains pour gouverner les Workspaces.

✅ 2. Les prérequis à valider

Préparez le changement comme une migration de service, pas comme un réglage isolé :

• droits Administrateur de Fabric pour administrer le tenant et les affectations;

• droits Azure Contributeur sur l’abonnement pour permettre de créer, modifier, suspendre la capacité Fabric.

✅ 3. Passons à la pratique : rendre My Workspace indisponible

Maintenant que le principe est clair, passons à la mise en œuvre. L’objectif est de mettre en place le mécanisme progressivement, depuis la création de la capacité dédiée jusqu’à la validation finale avec un utilisateur non-admin.

Étape 1 : Créer la Capacité Fabric dédiée

Dans le portail Azure, créez une ressource Microsoft Fabric :

1. Sélectionnez la souscription et le Resource Group de gouvernance.

2. Choisissez une région conforme à vos exigences de résidence.

3. Sélectionnez une capacité F2.

4. Nommez clairement la ressource.

5. Affectez uniquement les administrateurs responsables du contrôle.

6. Ajoutez des tags de coût, de propriétaire et de finalité.

Étape 2 : Configurer la capacité côté Fabric

Dans le portail Microsoft Fabric :

1. Ouvrez Admin portal > Capacity settings > Fabric capacity.

2. Sélectionnez la capacité créée.

3. Dans Details, développez “Preferred capacity for My workspace”.

4. Activez l’option, puis sélectionnez Apply.

⚠️ Ce réglage place la capacité comme destination préférée des My Workspaces concernés par le mécanisme de capacité par défaut. Dans le pattern retenu, il couvre notamment les nouveaux utilisateurs et ceux qui n’avaient pas encore initialisé leur espace personnel.

Étape 3 : Activer le tenant setting anti-rollback

Dans le portail Microsoft Fabric :

1. Ouvrez Admin portal > Tenant settings > Workspace settings.

2. Développez “Block users from reassigning personal workspaces (My Workspace)”.

3. Activez l’option, puis sélectionnez Apply.

Sans ce verrou, un propriétaire peut réaffecter son My Workspace vers un type Power BI Pro. Vous auriez alors déplacé les espaces personnels sans fermer la porte de sortie.

Ce tenant setting ne bloque pas “My Workspace” à lui seul. Il fige son affectation. C’est le couplage avec la Capacité pausée qui produit l’indisponibilité.

Étape 4 : Affecter tous les My Workspaces existants

Retournez dans Capacity settings, puis :

1. Sélectionnez la capacité créée.

2. Ouvrez Workspaces assigned to this capacity.

3. Sélectionnez Assign workspaces.

4. Choisissez The entire organization’s My workspaces.

5. Confirmez l’affectation.

Cette option observée dans l’interface F SKU permet de rattraper en masse les espaces personnels déjà créés.

Après l’opération, contrôlez un échantillon de My Workspaces dans “Admin portal > Workspaces” et vérifiez le nom de capacité.

Étape 5 : Mettre en pause la capacité

Dans le portail Azure :

1. Ouvrez la ressource Microsoft Fabric.

2. Sélectionnez Pause.

3. Confirmez l’opération.

4. Attendez que l’état de la ressource indique Paused.

La pause est une opération de plateforme. Microsoft indique qu’elle peut rendre indisponible le contenu affecté à la capacité.

Étape 6 : Vérifier depuis un compte non-admin

Depuis un compte de test représentatif :

1. Connectez-vous à app.powerbi.com.

2. Ouvrez My Workspace.

3. Tentez d’ouvrir un rapport.

4. Tentez de créer un rapport.

Le résultat attendu est une erreur indiquant que l’action ne peut pas être exécutée parce que la capacité est pausée.

🥇 La Règle d’Or

Si tu dois retenir une chose : My Workspace ne se désactive pas avec un tenant setting. Pour le rendre indisponible, concentrez tous les espaces personnels sur une capacité F SKU dédiée, empêchez leur retour en capacité partagée, puis pausez cette capacité.

L’impact terrain est immédiat : les rapports personnels ne peuvent plus servir de canal parallèle de diffusion, tandis que les Workspaces gouvernés restent disponibles. Vous obtenez aussi une règle vérifiable : inventaire des affectations, état Azure, test non-admin et alerte de reprise.

Votre organisation veut-elle réduire le partage depuis My Workspace, ou assumer son blocage opérationnel complet avec un chemin gouverné de remplacement ?

Répondez simplement à cet email ou ce post, je lis tous vos messages.

Bon mardi et à la semaine prochaine pour continuer à explorer ensemble les entrailles de Fabric !

🔗 À lire dans Fabric Mastery

• Fabric Copilot Capacity : isoler les workloads IA : pour appliquer la même discipline d’isolation, de périmètre et de gouvernance à une Capacity spécialisée.

• Capacity Metrics App : surveiller une Capacity Fabric : pour construire le volet détection et conserver une lecture opérationnelle des événements de Capacity.

📚 Ressources pour aller plus loin

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

• 📘 Gouverner les My Workspaces dans Microsoft Fabric : accès administrateur, Capacity par défaut et anti-réaffectation.

• 🛠️ Configurer et gérer une Fabric Capacity : réglages Preferred capacity for My workspace et affectation des Workspaces.

• 🔐 Paramètres d’export et de partage Power BI : liens organisationnels, invités, Publish to web et exports.

• 🏷️ Paramètres de protection de l’information : sensitivity labels et restriction des liens vers toute l’organisation.

• ⏸️ Pauser et reprendre une Fabric Capacity : prérequis RBAC, effets et procédure Azure.

• 📘 Licences et capacités des utilisateurs Power BI : capacités de création, publication et partage associées à Power BI Pro.

Plusieurs équipes partagent une même capacité Fabric, mais vous ne voulez pas forcément leur donner les mêmes possibilités partout.

Comment limiter la création de certains items Fabric pour un groupe, tout en laissant les autres équipes travailler normalement ?

C’est typiquement le genre de scénario où les Microsoft Fabric Policies deviennent intéressantes, notamment pour appliquer des règles plus granulaires et mieux protéger vos environnements de production.

⚡ En 30 secondes

Ce qu’il faut retenir sur les Policies:

• Contrôle granulaire : appliquer des règles ciblées plutôt que de restreindre toute la capacité ou toutes les équipes.

• Gouvernance par groupe : différencier ce que certains groupes d’utilisateurs peuvent créer, tout en laissant les autres travailler normalement.

• Protection des environnements : éviter certaines créations sur des workspaces sensibles, notamment en production, sans bloquer les autres usages Fabric.

Ce que les Policies gouvernent aujourd’hui

Trois niveaux sont à distinguer :

• le Policy set, item Fabric qui contient les configurations et que vous activez sur une portée ;

• la Policy, qui contrôle une opération précise ;

• les règles, qui décrivent les cas autorisés en mode Advanced.

La portée de cette Policy est à deux niveau : Capacité ou Tenant. La documentation consultée décrit trois Policies disponibles :

La création relève donc de la Capacity, pas d’une Policy tenant qui couvrirait indistinctement toutes les opérations. Les Workspaces peuvent être des conditions ; ce ne sont pas des portées administratives autonomes dans cette preview.

Cette liste ne contient pas de Policy générale « interdire la lecture ou l’utilisation des Data agents ». Nous reviendrons sur les permissions des agents existants dans le premier exemple.

1. Trois mode : Allowed, Blocked et Advanced

Pour la Policy Allow item creation, voici ce que change chaque mode :

Pour résumer en d’autres termes :

• “Allowed” ne donne pas de droits supplémentaires. Un Viewer ne devient pas créateur.

• “Blocked” interdit toute création mais ne révoque pas les accès aux items existants. Le contrôle porte sur l’opération de création.

• “Advanced” permet d’autoriser les cas voulus (c’est la partie la plus intéressante), en fonction du type d’éléments, du groupe de personnes et du workspace.

✅ Ce qu’il faut savoir sur “Advanced” :

• Plusieurs conditions dans une règle : ET.

• Plusieurs règles : OU.

• Is any of (AnyOf) : au moins une valeur correspond.

• Is none of (NoneOf) : aucune des valeurs configurées ne correspond.

• Une condition omise ne restreint pas la règle sur cette dimension.

Dès que vous configurez Advanced avec des règles Allow, la Policy fonctionne comme une liste d’autorisation. Tout ce qu’aucune règle n’autorise est implicitement bloqué. Il n’y a pas de règle Deny prioritaire sur les autres.

Conséquence : une règle trop étroite bloque des usages attendus ; une règle trop large peut réautoriser le cas que vous vouliez interdire.

2. Organiser les Policy sets : noms, nombre et lisibilité

Une convention de nommage explicite

✅ Recommandations

• Des noms de Policy sets et de règles qui indiquent la portée et l’objectif.

• Un nom de Policy set unique, descriptif et sans espaces.

• Pour chaque règle, un nom et une description précisant à qui elle s’applique, ce qu’elle autorise et où.

🛠️ Convention proposée, pas norme Microsoft

Capacity : ps-cap-<capacite>-<policy>-v<NN>
Tenant   : ps-tnt-<policy>-v<NN>

Exemples fictifs : ps-cap-prod-fr-itemcreation-v01 et ps-tnt-workspacesettings-v01.

Le segment policy décrit l’intention du set ; il n’impose pas un item distinct pour chaque règle ou chaque Policy.

Le suffixe vNN distingue l’actif de son candidat ou de son prédécesseur lors du remplacement décrit en section 4.

Pour les règles, utilisez des noms comme R00-autres-types ou R10-dataagent-horsgroupe. La numérotation sert uniquement à la lecture : les règles restent combinées en OU, sans ordre de priorité.

Une description utile ajoute au qui / quoi / où le propriétaire, par exemple : « Autorise les créations hors Data agent dans les Workspaces de prod-fr ; tous les utilisateurs éligibles ; propriétaire : équipe plateforme. »

Combien de Policy sets et de règles ?

✅ Limites et fonctionnement documentés

• Un seul Policy set actif par portée à un instant donné. Un même set n’est actif que sur une portée à la fois ; pour l’activer sur une autre Capacité, il faut d’abord le désactiver.

• Donc N Capacities gouvernées simultanément nécessitent N Policy sets actifs à portée Capacité.

• Jusqu’à 50 règles par Policy à portée Capacité, 100 à portée Tenant, et 50 valeurs par condition.

• Les Workspaces référencés par la Policy de création doivent appartenir à la Capacité sélectionnée.

• Microsoft recommande de regrouper dans un Workspace d’administration sécurisé les Policy sets gérés par la même équipe. La Capacité qui héberge ce Workspace n’est pas nécessairement la Capacité ciblée par les règles.

🛠️ Recommandations terrain

• Pas de Policy set « par principe ». Pour la création, sans restriction active, les permissions Workspace continuent de s’appliquer. Commencez par les capacités de production où un besoin est identifié.

• Une cible de deux sets conservés par capacité : l’actif et son candidat, ou l’actif et le précédent pour revenir en arrière. C’est une discipline d’exploitation, pas un maximum produit ; l’historique reste dans Git.

• Viser 10 à 15 règles par Capacité comme seuil de lisibilité interne. Approcher 50 doit déclencher une revue de conception, pas une recherche de contournement.

• Utiliser des groupes Entra plutôt que des listes d’utilisateurs ; pour la création, l’appartenance transitive aux groupes est résolue.

• Aligner, quand cela répond à l’architecture, les capacités sur les zones de gouvernance. Une capacité entièrement dédiée à la production peut éviter de répéter des filtres Workspaces.

Le Policies center présente les sets actifs, pas tous vos candidats inactifs. Complétez l’inventaire via API, avec l’opération API List Policy Sets et les items du Workspace d’administration.

Enfin, choisissez consciemment les types d’items : AnyOf n’autorise que la liste choisie, donc pas automatiquement les nouveaux types ajoutés par Microsoft ; NoneOf autorise tout sauf la liste exclue, y compris de nouveaux types couverts par le contrôle.

3. Trois exemples pour mieux comprendre

Les noms, groupes et périmètres que j’ai utilisé ci-dessous sont fictifs. Les tableaux utilisent les libellés de l’interface

Exemple 1 : Bloquer la création de Data agents pour un groupe

Besoin : les membres de sg-fabric ne créent pas de Data agents ; les autres créations restent disponibles pour eux, et les autres utilisateurs conservent la possibilité de créer des agents.

Question : faut-il créer une règle avec ET ou deux règles avec OU.

Je voulais laisse réfléchir et je vous mets la réponse ci-dessous et les distinctions :

Créez deux règles distinctes :

Tests attendus :

• Alice, hors du groupe, crée un Data Agent: autorisé par R10.

• Alice crée un Notebook : Autorisée par R00 et R10.

• Bob, membre de sg-fabric, crée un Data Agent : refusée car aucune règle l’autorise.

• Bob, membre de sg-fabric, crée un notebook : autorisée par R00.

Une règle avec deux conditions ou deux règles distinctes ?

En “Advanced”, une règle décrit ce qui est autorisé, pas ce qui est interdit. À type et groupe ciblés identiques, les deux configurations ne sont donc pas équivalentes :

• Une seule règle avec Item type Is none of [Fabric data agent] ET Security groups Is none of [groupe interdit] autorise uniquement les autres types pour les utilisateurs hors du groupe. Si c’est la seule règle, les membres du groupe ne peuvent créer aucun type d’item, et les non-membres ne peuvent pas non plus créer de Data agent.

• Deux règles distinctes, comme ci-dessus, autorisent une création si le type n’est pas un Data agent OU si l’utilisateur est hors du groupe. Une seule des règles doit correspondre : les autres types restent disponibles pour le groupe, et les autres utilisateurs peuvent toujours créer des agents.

Voici les résultats attendus, sans autre règle susceptible d’autoriser l’opération :

C’est la loi de De Morgan.

Exemple 2 : Réserver Dataflow Gen2 à un groupe sur toute la Capacité

Besoin : seuls les membres de sg-fabric créent des Dataflow Gen2 ; le reste demeure disponible.

Sans filtre Workspace, ces règles couvrent tous les Workspaces de la Capacité.

Tests attendus :

• Alice, hors du groupe, crée un Notebook : autorisé par R00.

• Alice crée un Dataflow Gen2 : refusé, aucune règle ne correspond.

• Bob, membre de sg-fabric, crée un Dataflow Gen2 : autorisé par R10.

Exemple 3 : Bloquer la création de dbt jobs dans toute la Capacité

Besoin : personne ne doit créer de nouvel item dbt job dans les Workspaces de la Capacité cible, mais les créations d’autres items doivent rester disponibles.

4. Créer, remplacer et maintenir sans surprise

Préparer la fonctionnalité et la population concernée

Avant de commencer :

1. Vérifiez la région. La documentation liste actuellement West Europe, North Europe et West US parmi les régions de Capacity non prises en charge. Ne déplacez pas des données pour une preview sans revue de résidence.

2. Préparez le Workspace d’administration sur une Capacity Fabric. Un rôle Contributor, Member ou Admin permet d’y créer l’item ; seul l’administrateur de la portée peut l’activer : Capacity administrator pour la Capacité, Fabric administrator pour le Tenant.

3. Un administrateur Fabric ouvre OneLake catalog > Govern > Policies pour gouverner les Policies par capacité ou au niveau du tenant.

Activer ou remplacer

Ouvrez le candidat depuis son Workspace, sélectionnez le statut Active, choisissez la Capacité cible et confirmez le remplacement éventuel.

L’ancien set devient inactif. Le nouveau prend effet sous 15 minutes ; les modifications d’un set déjà actif peuvent aussi prendre jusqu’à 15 minutes.

Le Policies center, dans OneLake catalog > Govern > Policies, sert à voir et gérer les configurations actives par portée. Ses changements sont synchronisés avec l’item actif. Il ne permet pas actuellement de créer, activer ou désactiver un Policy set : utilisez l’item Workspace ou l’API appropriée pour ces opérations.

Une personne ayant les droits nécessaires sur l’item peut modifier les règles ; l’activation reste réservée à l’administrateur de portée. Un set actif n’est pas figé : limitez aussi les droits de modification pour éviter qu’une édition ne change le contrôle hors du processus prévu.

Vérifier, puis conserver la preuve

Après propagation, utilisez des comptes avec des permissions et prérequis comparables, dont le fonctionnement initial a été contrôlé :

• membre et non-membre des groupes ciblés ;

• compte appartenant à plusieurs groupes, y compris par imbrication ;

• types autorisés et type restreint ;

• Workspace de production, hors production et, si possible, hors de la Capacity cible ;

• compte hors de la population soumise aux Policies si vous avez limité le pilote.

Rapprochez les résultats des Fabric audit logs et conservez les opérations horodatées, la version et la configuration testée. Un refus dû aux permissions Workspace ne prouve pas que votre Policy fonctionne.

Pour revenir en arrière, réactivez la version précédente en remplaçant l’actuelle, puis refaites les contrôles. Désactiver sans remplacement rétablit le comportement système applicable, pas votre ancienne configuration : pour la création, cela peut rouvrir les créations selon les permissions. L’item désactivé reste dans le Workspace.

Versionner les définitions, contrôler l’activation

Git et le CI/CD permettent de versionner, relire et promouvoir les définitions. Git n’active pas le Policy set : l’activation passe par une opération API ou par l’item dans son Workspace.

Les API Policies prennent en charge les jetons utilisateur, les principaux de service et les identités managées. Cela permet l’automatisation, sans supprimer les exigences de droits sur l’item et sur la portée d’activation.

Mon conseil : une mise à jour est validée seulement lorsque le refus attendu et le maintien des usages autorisés sont prouvés. Le statut Active n’est pas une recette.

🥇 La Règle d’Or

Si tu dois retenir une chose : en “Advanced”, chaque opération qui ne correspond à aucune règle est refusée ; décrivez donc aussi tout ce qui doit continuer à fonctionner.

Nommez l’intention, gardez des règles lisibles et préparez le remplacement avant de toucher à l’actif. Et ne confondez jamais création d’item et accès aux données existantes.

Quel serait votre premier contrôle utile : réserver les notebooks à une équipe, limiter la création de Data agents ou différencier production et exploration ?

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 : Data Agent vs Copilot — pour distinguer les usages avant de choisir un contrôle qui affecte l’un ou les deux.

• Microsoft Fabric : Git Integration — pour replacer les définitions de gouvernance dans un cycle de versionnement.

• Sécurité des données : Pourquoi vous ne pouvez plus la traiter en fin de projet — pour replacer les permissions et la sécurité des données dans la conception de votre plateforme.

  ---

📚 Ressources pour aller plus loin

• Vue d’ensemble des Fabric policies (preview) — Policies disponibles, périmètres, logique d’autorisation et restrictions régionales.

• Créer et activer une Fabric policy — paramètre tenant, création du Policy set, activation, recette et désactivation.

• Gérer le Policies center du OneLake catalog — rôles, éligibilité des utilisateurs, gestion des règles et synchronisation avec l’item actif.

• Allow item creation — conditions, opérateurs AnyOf et NoneOf, identifiants de groupes et blocage implicite.

• Fabric policies REST APIs — création, inventaire List Policy Sets, activation, Git, CI/CD et identités d’automatisation.

• Référence API : types d’items Fabric — identifiant DataAgent, distinct du nom affiché dans l’interface.

• Partage et permissions des Fabric data agents — version publiée, droits de consommation et accès nécessaires aux sources.

• Modèle de permissions Fabric — articulation entre permissions d’items et rôles Workspace.

Beaucoup d’entre vous se posent la question de la migration AAS to Fabric, qu’est-ce que c’est ? pourquoi on en parle et comment le faire ?

J’aimerai vous partager ma démo réalisée sur la migration de modèles AAS vers les modèles sémantiques sur Microsoft Fabric. Pendant 5 mins, je décrypte tout ce tu as besoin de savoir et comment le réaliser.

⚡ En 30 secondes

Ce qu’il faut retenir :

• Avant de cliquer sur Migrate dans Fabric, j’ai configuré 3 services adjacents :

  • le Storage Account de backup AAS (networking public + storage account key access ON),

  • le workspace / la Capacité (F-SKU, Large model ON, XMLA Read/Write),

  • et le tenant Fabric (Azure Connections activé + workspace lié à un ADLS Gen 2).

• Migrate : lance la migration du modèle AAS vers le modèle sémantique Fabric / Power BI.

• Après Migrate, j’ai deux boutons à activer :

  • la redirection XMLA (pour vos outils Tabular Editor, SSMS, PowerShell)

  • et le rebind (pour vos rapports Power BI live-connect).

Migrate dans Fabric, c’est le point de départ concret de la migration : un bouton qui permet de prendre votre modèle AAS et de lancer sa migration vers un modèle sémantique dans Microsoft Fabric. Une fois la migration réalisée, il reste ensuite à rediriger les outils utilisant XMLA et à reconnecter les rapports Power BI au nouveau modèle.

⚠️ Avant de migrer : vérifiez le sizing de votre capacité Fabric

La migration d’AAS vers Fabric n’est pas uniquement une question de compatibilité fonctionnelle. Il faut aussi vérifier que la capacité Fabric cible est correctement dimensionnée pour accueillir vos modèles et leur consommation.

Pour dimensionner la cible d’une migration AAS, Microsoft recommande notamment de considérer la taille du plus gros modèle AAS, le nombre d’utilisateurs et la consommation CPU. La consommation CPU entre AAS et Fabric/Power BI peut différer selon les workloads, refresh et patterns de requêtes.

👉 En clair : ne choisissez pas votre F-SKU uniquement en faisant une équivalence avec votre SKU AAS actuel. Regardez la taille de vos modèles et mesurez la charge réelle.

Source : Migrate from Azure Analysis Services to Power BI

Maintenant, voyons la check-list pour que votre migration dans Microsoft Fabric se passe correctement. Chaque point est un paramétrage à valider AVANT ou APRÈS avoir cliqué sur le bouton Migrate dans le portail Microsoft Fabric.

S'abonner maintenant

✅ 1. Préparer le compte de stockage utilisé pour le backup AAS

Avant de lancer la migration, il faut préparer un compte de stockage Azure utilisé par Azure Analysis Services pour sauvegarder le modèle AAS.

Lors de la migration, le modèle AAS est d’abord sauvegardé sous la forme d’un fichier .abf (Analysis Services Backup File) dans un container Blob configuré au niveau du serveur AAS. Ce backup constitue une étape intermédiaire permettant ensuite au processus de migration de récupérer le modèle pour le transférer vers Fabric.

👉 Attention : il s’agit ici du Storage Account configuré pour le backup du serveur AAS, et non du stockage associé au workspace Fabric.

Trois réglages à vérifier en premier sur les comptes de stockage:

1. Networking du Storage Account

Le serveur AAS doit pouvoir accéder au compte de stockage dans lequel il écrit son backup.

Dans mon environnement de démo, j’ai donc vérifié la configuration réseau du Storage Account et autorisé l’accès nécessaire.

Pour un PoC, cela peut notamment passer par une configuration réseau suffisamment ouverte. Dans un environnement de production, il faut évidemment adapter cette configuration aux règles réseau et de sécurité de l’organisation.

2. Accès via la clé du Storage Account

J’ai également vérifié que Allow storage account key access était activé afin que le mécanisme de backup AAS puisse utiliser le Storage Account configuré.

3. Configurer le Storage Account côté AAS

Enfin, le compte de stockage doit être déclaré comme destination de backup du serveur AAS :

Azure Portal > serveur Azure Analysis Services > Settings > Backup

Il faut y configurer le container Blob qui recevra les fichiers .abf.

✅ 2. Créer et déployer un modèle BIM dans AAS

💡 Cette étape est spécifique à ma démo. Si vous avez déjà un modèle AAS à migrer, vous pouvez directement passer à l’étape suivante.

Personnellement, je ne disposais pas d’un modèle AAS existant. J’ai donc dû en créer un afin de pouvoir reproduire le scénario de migration de bout en bout.

Mais tout d’abord, qu’est-ce qu’un modèle BIM ?

Un fichier .bim décrit le modèle tabulaire Analysis Services : il contient notamment la définition du modèle, ses tables, colonnes, relations, mesures, partitions, sources de données et rôles.

Dans ma démo, j’ai donc :

Azure SQL Database > création du modèle BIM dans Tabular Editor > déploiement sur AAS > processing du modèle > connexion d’un rapport Power BI

Étape 2.1 : création du modèle

J’ai créé dans Tabular Editor un modèle tabulaire basé sur plusieurs tables provenant d’une Azure SQL Database.

Une fois le modèle construit, je l’ai déployé vers mon serveur AAS via :

Model → Deploy…

avec :

• Server : URI de mon serveur AAS

• Database : nom du modèle à créer sur AAS

• Structure

• Data Sources

• Partitions

• Roles

À ce stade, le modèle existe dans AAS, mais cela ne signifie pas encore que ses données sont chargées.

Étape 2.2 : processing du modèle

Le déploiement du modèle et le chargement des données sont deux étapes distinctes dans mon scénario.

J’ai donc rouvert le modèle AAS directement depuis Tabular Editor :

File → Open → From DB → URI du serveur AAS

Puis j’ai configuré l’accès à mon Azure SQL Database et lancé un Full Refresh afin de charger les données dans le modèle AAS.

Dans mon environnement de démonstration, j’ai utilisé un compte SQL Auth dédié en lecture pour permettre à AAS d’accéder à la source.

Une fois le refresh terminé, j’ai vérifié dans DAX Studio que les tables du modèle contenaient bien des données.

Étape 2.3 : création du rapport Power BI de test

Enfin, j’ai créé un rapport Power BI connecté au modèle AAS :

Power BI → Get Data → Azure Analysis Services → serveur AAS → modèle

Ce rapport est important pour la suite de la démonstration : il me sert de test de bout en bout pour vérifier, après la migration, que le rapport peut être rebindé vers le nouveau modèle sémantique Fabric.

✅ 3. Préparer le workspace Fabric cible et sa capacité

À ce stade, le côté AAS est prêt : le modèle est déployé, les données sont chargées et mon rapport Power BI en Live Connection vers AAS est publié.

On passe maintenant côté cible.

L’objectif est de préparer le workspace qui accueillera le modèle AAS une fois transformé en modèle sémantique Power BI/Fabric.

Ce workspace ne peut pas être configuré comme un simple workspace Power BI Pro. La fonctionnalité de migration nécessite un environnement compatible, notamment :

• Une capacité Fabric F-SKU (recommandé).

• Dans les paramètres du workspace, activer le “Large semantic model storage format”.

• Au niveau de la capacité, le XMLA endpoint doit être configuré en Read/Write.

• Un compte ADLS Gen2 connecté au workspace (voir le prochain point).

On a donc deux stockages à ne pas confondre dans cette migration :

• côté AAS : le Storage Account avec son container destiné au backup AAS ;

• côté cible : l’ADLS Gen2 connecté au workspace vers lequel on migre.

🔐 Et côté permissions ?

Pour réaliser la migration, vérifiez également vos droits.

Côté AAS, Microsoft demande des permissions Server Administrator et d’appartenir aux rôles Owner et/ou Contributor de la subscription. Côté Power BI/Fabric, vous devez être Workspace Administrator du workspace cible.

Source : Migrate Azure Analysis Services to Power BI - Microsoft Fabric

✅ 4. Connecter le workspace à ADLS Gen2

Dernier prérequis avant de cliquer sur Migrate : le workspace cible doit être connecté à un Azure Data Lake Storage Gen2 (ADLS Gen2) situé dans le même tenant. Microsoft recommande également que ce stockage soit dans la même région que la capacité du workspace pour de meilleures performances.

💡 ADLS Gen2 est un compte Azure Storage utilisant les fonctionnalités Data Lake, notamment le hierarchical namespace.

Dans Fabric, j’ai donc vérifié deux choses :

• Au niveau du tenant : le paramètre permettant l’utilisation des connexions Azure est activé.

• Au niveau du workspace : le workspace cible est connecté au compte ADLS Gen2 que j’ai préparé.

✅ 5. Maintenant, on migre !

À ce stade, tous les prérequis sont en place :

• AAS prêt

• Backup configuré

• Capacité Fabric dimensionnée

• Large Model activé

• XMLA Read/Write

• ADLS Gen2 connecté

• permissions vérifiées.

On peut maintenant passer à la partie concrète : lancer la migration du modèle AAS vers Fabric.

Étape 1 : Créer le pairing AAS au Workspace

Dans le workspace Fabric : Migrate > Data Model (AAS).

Puis compléter les informations :

• Subscription Azure,

• Resource group,

• Server AAS,

• Workspace Fabric cible.

Cliquer sur “Start Migration”.

Étape 2 : Sélectionner les modèles à migrer

Sur la page Migration Details, cochez le ou les modèles de databases à migrer sur la colonne “Include in Migration”, puis Migrate (en haut à droite).

Fabric gère : backup sur le Blob AAS qui le copie dans ADLS Gen 2 du workspace puis restore en modèle sémantique. On peut avoir jusqu’à 5 modèles en parallèle.

Étape 3 : Activer la redirection serveur (XMLA)

Une fois le modèle sémantique présent dans Fabric, la migration n’a pas encore redirigé vos outils. Vos Tabular Editor, SSMS, PowerShell continuent à parler à AAS.

Sur la colonne Server redirection enabled, passez le slider à “On”. Cela crée un alias transparent : les scripts qui se connectaient à asazure://... sont automatiquement redirigés vers l’endpoint XMLA du workspace Fabric.

Étape 4 : Rebind du rapport Power BI

La redirection XMLA gère les outils. Elle ne gère PAS les rapports déjà publiés dans le service Power BI. Pour ceux-là, un mécanisme distinct : Rebind.

Sur la page Migration Details du modèle migré, cliquez sur “Rebind reports”. Fabric parcourt tous les rapports du tenant qui pointaient vers ce modèle AAS et les réoriente vers le semantic model Fabric.

Le processus prend quelques minutes. Vous pouvez suivre l’avancement via “Rebind status”. Si un rapport pose problème, vous pouvez faire “Undo rebind”, les rapports repointent alors vers AAS (à condition que le serveur ne soit pas encore pausé).

Étape 5 : Vérifier le rebind dans le Lineage Fabric

C’est l’étape que je vois trop souvent sautée. Sans elle, vous croyez la migration terminée alors qu’un rapport peut encore taper AAS en douce.

Ouvrez le workspace Fabric, sur Lineage view. Le rapport migré doit afficher un lien direct vers le nouveau modèle sémantique (nom du modèle qui vient d’apparaître), et plus vers l’ancien connecteur AAS.

Deuxième vérification côté modèle sémantique, le mode de stockage : ouvrez le rapport dans Power BI Desktop ou dans le service Fabric et regardez la source. Elle ne doit plus mentionner l’endpoint AAS mais bien le nouveau modèle sémantique, avec un mode de stockage approprié (Import) :

🥇 La Règle d’Or

Si tu dois retenir une chose : la migration AAS vers Fabric n’échoue jamais sur le modèle. Il y a des paramètres à prendre en compte en amont comme la taille des modèles, le backup Blob, les paramètres du tenant,…

Vous avez déjà migré un modèle AAS vers 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 !

🔗 À lire dans Fabric Mastery

• Direct Lake en production : les prérequis à valider avant de basculer : après avoir migré votre modèle AAS en Import, la question suivante est le mode de stockage : rester en Import restauré, ou basculer Direct Lake sur OneLake. Voici les critères de décision.

• RLS, CLS, OLS Microsoft Fabric : guide sécurité des données : vos rôles AAS (Read, Administrator) deviennent des permissions Fabric (Build, Write) : les mappings ne sont pas 1:1, voici comment restructurer la sécurité fine post-migration.

• Fabric Chargeback vs Capacity Metrics : dimensionner votre F-SKU : dimensionner la Capacity cible qui remplace votre S-SKU AAS n’est pas un simple ratio cœurs pour cœurs, voici la méthode de sizing.

📚 Ressources pour aller plus loin

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

• 📘 Migrate from Azure Analysis Services to Power BI (guidance) : la vision stratégique et la matrice de comparaison AAS vs Fabric.

• 🛠️ Migrate Azure Analysis Services to Power BI (how-to) : le pas-à-pas exact du portail Fabric, avec captures et prérequis.

• 🛠️ Analysis Services database backup and restore : la configuration du Storage Account et du container Blob côté AAS.

• 🔗 Manage Azure connections (Fabric admin) : la référence pour activer le tenant setting Azure connections et le workspace-level ADLS Gen 2.

• 🔗 Migration scenarios AAS to Power BI : six scénarios chiffrés pour choisir le bon SKU cible selon votre profil de consommation.

Capacity Metrics App est l’application Microsoft dédiée au suivi et à l’analyse des capacités Fabric. Elle permet de visualiser la consommation, l’état de santé et l’utilisation du stockage, avec un historique de 14 jours disponible sur la page Compute

Aujourd’hui, on décortique un problème d’historique sur la Capacity App Metrics en se penchant sur une solution avec FUAM. De plus, je vais détailler le throttling sur Microsoft Fabric pour vous permettre de tout comprendre sur la capacité.

⚡ En 30 secondes

Ce qu’il faut retenir :

• La page Compute de Capacity Metrics couvre les 14 derniers jours. FUAM persiste les collectes dans son Lakehouse pour construire un historique plus long à partir de son déploiement.

• Les graphiques Interactive delay, Interactive rejection et Background rejection suivent le même principe de Throttling sur des fenêtres différentes (de 10 minutes, 60 minutes et 24 heures).

• Sous 100 %, le palier n’est pas actif. Au-dessus, Fabric retarde l’interactif, rejette l’interactif, puis rejette toutes les nouvelles requêtes.

S'abonner maintenant

Capacity Metrics App et FUAM

Capacity Metrics App est l’application Microsoft native pour diagnostiquer une Capacity : consommation CU, throttling, overages, timepoints et opérations, avec 14 jours sur la page Compute.

FUAM (Fabric Unified Admin Monitoring) est un Solution Accelerator permettant de centraliser la supervision d’un environnement Microsoft Fabric à l’échelle du tenant. Il collecte les logs, métriques de capacité, informations d’inventaire et données d’usage dans un Lakehouse unique, puis expose des rapports Power BI pour l’administration et l’optimisation de la plateforme.

⚠️ Note : FUAM n’est pas un produit officiel Microsoft Fabric, mais un accélérateur développé par la Fabric Customer Advisory Team.

Que s’est-il passé avant les 14 derniers jours ?

Nous savons que la page Compute de l’application Capacity Metrics couvre 14 jours : c’est souvent trop court pour comparer deux clôtures mensuelles ou prouver qu’un pic se produit principalement en été ou en fin d’année.

La solution FUAM conserve les extractions concernant les métriques de capacités successivement dans son Lakehouse. L’historique grandit après le déploiement, puis ses graphiques permettent de suivre l’utilisation des Capacity Units (CU), les délais d’interactives et throttling sur la durée.

⚠️ FUAM ne récupère pas rétroactivement des mois disparus. Le chargement initial reste limité à 14 jours, c’est l’exécution régulière de la Pipeline d’ingestion qui construit l’historique long terme.

Une couche d’historisation et de diagnostic

Pour information, FUAM extrait au maximum 14 jours depuis le modèle Capacity Metrics lors du chargement initial, puis peut réduire la fenêtre des exécutions suivantes et ajouter les nouvelles données dans ses tables Delta dans le lakehouse. Le rapport principale de FUAM est FUAM_Core_Report, où la page Capacity Compute fournit ainsi une vue historique au-delà de la fenêtre native, et vous pouvez ainsi filtrer la période que vous voulez pour comparer l’usage de votre consommation CU de vos capacités sur plus de 14 jours.

Vous pouvez utiliser le bandeau de droite “Filters” pour filtrer sur une capacité spécifique avec le champ “Capacity” et tous les graphiques présents se mettent dynamiquement à jour :

Que représente les pourcentages des graphiques de Throttling ?

Voici comment la capacité arrive à du Throttling :

Regardons ensemble les mécanismes de Throttling dans Fabric, les trois courbes lisent la même consommation lissée sur des horizons différents :

Le pourcentage décrit le niveau d’occupation de la fenêtre de throttling à un timepoint. Il ne prédit ni le nombre d’utilisateurs touchés ni la durée d’une requête. Voyons un exemple de pourcentage sur “Interactive Delay” dans ma démo :

À 50 % sur Interactive Delay, c’est 5 des 10 minutes autorisées qui sont déjà engagées. Les 50 % restants peuvent partir en un seul timepoint de 30 secondes, ou ne jamais être consommés si la capacité respire.

Chaque graphique est normalisé sur SA propre fenêtre, donc 50 % partout n'est pas la même marge. Un 50 % sur la courbe Interactive Delay c’est 5 minutes, mais un 50% sur la courbe Background Rejection, c'est une demi-journée de capacité hypothéquée.

La règle terrain : 100% est la ligne de seuil commune. Dans les définitions détaillées Microsoft, le palier devient effectif lorsque sa courbe franchit ce seuil. Traitez toute valeur inférieure à 100 % comme un signal de contexte, pas comme la preuve d’une limitation. Comparez toujours les trois fenêtres et leur tendance.

Le bon réflexe se joue en deux temps :

Diagnostiquer : le franchissement de 100 %, sa durée et la tendance des courbes, jamais le niveau instantané d’une seule d’entre elles.

Traiter : identifier ce qui alimente la charge avant de scaler le SKU, de rééquilibrer entre capacités ou de replanifier les jobs.

🥇 La Règle d’Or

Si tu dois retenir une chose : FUAM étend l'observation, pas la règle. La pipeline d’ingestion construit, collecte après collecte, un historique au-delà des 14 jours natifs de la Capacity Metrics App.

Sur la page Capacity Compute du rapport, les trois courbes indiquent si la capacité a subi un throttling récurrent, jusqu'à quel palier afin d'anticiper la charge avant le prochain incident.

La limite native de 14 jours vous a-t-elle déjà empêché d’identifier un motif récurrent sur votre Capacity ?

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

• Capacity Metrics App Microsoft Fabric : piloter votre capacité : pour installer l’app native et explorer ses pages Compute, Timepoint et Overages.

• Ingestion Microsoft Fabric : Dataflow, Pipeline ou Notebook ? : pour arbitrer entre les principales charges background selon leur volume, leur orchestration et leur consommation en CU.

• Fabric Copilot Capacity : isoler les workloads IA : pour comprendre quand le découplage d’une charge Copilot protège la Capacity de production.

📚 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 :

• 📘 Understand capacity throttling and smoothing : bursting, lissage, carryforward, burndown et paliers de throttling.

• 📘 Metrics app calculations : interprétation des pourcentages et formule de récupération.

• 🛠️ Compute page in the Fabric Capacity Metrics app : lecture des graphiques Utilization, Throttling et Overages.

• 🔗 Understand the metrics app timepoint page : identification des opérations contributrices sur une fenêtre de 30 secondes.

• 🔗 Explore Fabric capacity overview events : schéma des événements et définition des trois pourcentages.

• 🧰 Fabric Unified Admin Monitoring sur microsoft/fabric-toolbox : code source et avertissement de support de FUAM.

• Vous avez remplacé vos anciens visuels Map et Filled map basés sur Bing par Azure Maps ?

• Votre tenant Power BI est localisé en Europe ?

• Où est-ce que les données sont traités en utilisant ce visuel ?

Azure Maps possède plusieurs endpoint, notamment un endpoint européen, constituant une garantie technique importante, mais elle dépend de trois niveaux que je vois souvent mélangés : la localisation du tenant, les paramètres d’administration et les fonctionnalités utilisées dans le visuel.

Ici, on tranche : ce qui reste dans la géographie Europe, ce qui peut en sortir, et la checklist à conserver.

⚡ En 30 secondes

Ce qu’il faut retenir :

• Pour Azure Maps, Power BI choisit automatiquement l’endpoint selon la localisation du tenant. La région de votre Capacité n’entre pas dans cette décision.

• Avec eu.atlas.microsoft.com, les requêtes et données d’entrée restent dans la géographie Europe, réplication de haute disponibilité comprise.

• Il y a deux paramètres sur le portail d’administration qui permet d’autoriser le traitement hors région et de sous-traitance sur des fonctionnalités de la carte.

S'abonner maintenant

La résidence des données Azure Maps dans Power BI

Le visuel Azure Maps est la brique cartographique native de Power BI. Il appelle un endpoint Azure Maps pour récupérer les tuiles, géocoder le champ Location et afficher les données géographiques. La résidence décrit où les requêtes et données d’entrée sont traitées et stockées ; elle ne remplace ni le contrôle d’accès, ni la minimisation, ni l’analyse de conformité de votre organisation.

La réalité du terrain

✅ 1. C’est le tenant Power BI qui choisit l’endpoint

Le routage est automatique. Si la localisation du tenant Power BI est en Europe, le visuel appelle eu.atlas.microsoft.com. L’auteur du rapport et le lecteur n’ont rien à configurer dans le visuel pour obtenir ce comportement.

Le point qui prête à confusion : la région de la Capacité n’est pas prise en compte pour déterminer l’endpoint Azure Maps. Une Capacité en France Central n’est donc pas la preuve à produire.

La donnée de référence se trouve dans le service Power BI : menu Aide (?) → About Power BI, puis la mention indiquant où les données du tenant sont stockées :

Ce découplage est logique : la Capacité porte le moteur de calcul, tandis que le tenant porte la localisation utilisée par le visuel pour son routage géographique.

✅ 2. L’endpoint européen garde les entrées dans la géographie Europe

La documentation Microsoft indique qu’avec eu.atlas.microsoft.com, les requêtes et les données d’entrée sont traitées et stockées dans la géographie Azure Europe. Pour la reprise après sinistre et la haute disponibilité, Microsoft peut répliquer les données client, mais uniquement dans une autre région de cette même géographie.

Cette garantie porte sur la résidence du service. Elle ne limite pas le pays depuis lequel un utilisateur autorisé peut consulter le rapport.

✅ 3. Toutes les données du rapport ne partent pas vers Azure Maps

Le visuel transmet ce dont le service cartographique a besoin :

• la zone sur laquelle la carte est centrée, afin de récupérer les tuiles nécessaires au rendu ;

• les données placées dans le compartiment Location, lorsqu’un géocodage est nécessaire ;

• une éventuelle télémétrie de santé du visuel, si la télémétrie Power BI est activée.

En dehors de ces scénarios, Microsoft précise que les autres données superposées sur la carte sont rendues localement dans le client et ne sont pas envoyées aux serveurs Azure Maps. Une mesure de chiffre d’affaires utilisée pour dimensionner une bulle n’est donc pas, par ce seul usage, envoyée au service de géocodage.

Ne vous y trompez pas : une coordonnée, une adresse ou un nom de lieu peut rester sensible selon son contexte. La bonne pratique consiste à préparer dans votre couche Gold le niveau géographique strictement nécessaire à la valorisation de la donnée : ville plutôt qu’adresse complète, zone plutôt que point précis, lorsque le besoin métier le permet. C’est la même logique de minimisation que dans une architecture Médaillon Bronze, Silver, Gold sur Microsoft Fabric.

✅ 4. La migration Bing vers Azure Maps doit être recettée

Les anciens visuels Map et Filled map utilisent Bing Maps.

Power BI Desktop propose une conversion de tous les anciens visuels cartographiques du rapport ou d’un seul visuel. Les réglages sont repris, mais Microsoft avertit que la taille de certains marqueurs peut différer, car les plages de taille ne sont pas identiques entre les plateformes.

La migration est donc un projet de recette, pas une formalité : comparez le cadrage, les couches, les marqueurs, les tooltips, les interactions, les bookmarks et le rendu mobile. Puis refaites l’audit de résidence sur le visuel converti. Remplacer une brique ne valide pas les paramètres du tenant à votre place.

Mon conseil : Inventoriez d’abord les rapports contenant Map ou Filled map, versionnez une copie, convertissez par lot contrôlé et faites signer la recette fonctionnelle ainsi que la revue de résidence avant publication.

Points de vigilance

⚠️ 1. « Process data outside your region or boundary » change la conclusion

Le portail d’administration Power BI permet d’autoriser le traitement des données Azure Maps hors de la région géographique, de la limite de conformité ou de l’instance de cloud national du tenant. Ce réglage sert notamment aux tenants situés dans une zone où les services Azure Maps requis ne sont pas disponibles.

Pour un tenant européen qui utilise l’endpoint européen, activer cette option élargit volontairement le périmètre possible. Vous ne pouvez plus reprendre la conclusion « les données ne quittent pas la géographie Europe » sans documenter les opérations concernées.

Mon conseil : Laissez ce réglage désactivé pour les groupes qui n’en ont pas besoin. Si une exception est nécessaire, limitez son périmètre, nommez un propriétaire et consignez la justification ainsi que la date de revue.

⚠️ 2. L’outil de sélection peut faire intervenir un sous-traitant

Un second réglage autorise les sous-traitants Microsoft Online Services à traiter les données. Il nécessite l’activation préalable du traitement hors région. Certaines fonctions, dont l’outil de sélection Azure Maps, peuvent alors utiliser des capacités cartographiques tierces ; la documentation de prise en main cite les données TomTom et prévient que les données utilisateur peuvent ne pas rester dans la frontière géographique.

Microsoft indique que seules les informations essentielles liées à la localisation sont partagées, par exemple des coordonnées ou noms de lieux, et que les identités des utilisateurs ainsi que les informations de consommation des rapports ne sont pas incluses.

Architecture / Fonctionnement

Voici l’architecture de traitement et les flux de données du visuel Azure Maps dans Power BI (pour les abonnés free/paid) :

Couleurs :

• orange = données susceptibles d’être envoyées ;

• vert = données métier restant dans le client ;

• bleu = traitements ;

• jaune = stockage cloud ;

• rouge = sous-traitance conditionnelle ;

• turquoise = sortie ;

• gris = contrôles.

Exécution étape par étape

1. Préparer les données : Power BI applique les permissions, RLS, filtres, segments et interactions. Les filtres ne sont pas directement envoyés à Azure Maps, mais ils déterminent les lieux et coordonnées restant à afficher.

2. Séparer les données :

   • 2A, susceptibles d’être envoyées : zone visible et niveau de zoom, valeurs textuelles de Location si elles doivent être géocodées, latitude et longitude, puis télémétrie de santé si elle est activée ;

   • 2B, non envoyées selon le comportement documenté : Legend, Size, Tooltips, mesures métier, titre du modèle sémantique, nom du rapport, de la page ou du visuel, identité utilisateur et informations de consommation du rapport.

3. Construire l’appel : le visuel choisit automatiquement le point de terminaison Azure Maps selon l’emplacement du locataire Power BI, puis transmet uniquement les éléments nécessaires de l’étape 2A.

4. Traiter dans Azure Maps : Azure Maps récupère les tuiles correspondant à la zone visible et, si nécessaire, transforme les valeurs de Location en coordonnées. Une télémétrie de santé, par exemple un rapport de plantage, peut être collectée si l’option Power BI est activée.

5. Retourner le résultat : Azure Maps renvoie les tuiles du fond de carte et les coordonnées produites par le géocodage. Les requêtes nécessaires peuvent être stockées temporairement ; la durée propre au visuel n’est pas publiée. Un sous-traitant peut intervenir uniquement pour les fonctions autorisées.

6. Assembler localement : le client Power BI combine les réponses Azure Maps avec les coordonnées disponibles et les données 2B restées dans Power BI pour dessiner les points, couleurs, tailles et infobulles.

7. Afficher la carte : le lecteur voit la carte finale. Les contrôles Power BI continuent de régir l’accès aux données métier affichées.

🥇 La Règle d’Or

Si tu dois retenir une chose : l’endpoint européen protège la résidence seulement tant que les paramètres et les fonctionnalités respectent cette frontière. Vérifiez la chaîne tenant, réglages, outil de sélection avant d’écrire « conforme UE ».

L’impact terrain est concret : vous savez quelle preuve demander, quel réglage challenger et quelle exception faire valider. Vous pouvez migrer les anciens visuels Bing sans déplacer aveuglément la dette de conformité vers Azure Maps, et répondre à un audit avec une chaîne de décision documentée.

Votre organisation a-t-elle déjà audité les deux tenant settings Azure Maps et l’usage de l’outil de sélection dans ses rapports ?

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

• RLS, CLS, OLS Microsoft Fabric : guide sécurité des données : pour compléter la résidence par les contrôles d’accès dans Power BI, OneLake et Fabric.

• Fabric Domains : structurer la gouvernance des Workspaces : pour attribuer un propriétaire clair aux Workspaces et aux décisions de conformité associées.

📚 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 :

• 📘 Résidence des données du visuel Azure Maps Power BI : routage automatique selon la localisation du tenant.

• 📘 Étendue géographique du service Azure Maps : endpoints, stockage et réplication dans une même géographie.

• 🛠️ Gérer le visuel Power BI Azure Maps dans votre organisation : tenant settings pour le traitement hors région et les sous-traitants.

• 🔗 Bien démarrer avec le visuel Azure Maps Power BI : données envoyées, rendu local et avertissement sur l’outil de sélection.

• 🛠️ Convertir Map et Filled map vers Azure Maps : procédure de migration et point de vigilance sur le rendu.

Plusieurs équipes partagent votre capacité Fabric, mais leurs usages sont différents. Comment répartir la facture entre elles, et qui prend en charge la capacité inutilisée ?

Aujourd’hui, on décortique un problème courant sur la refacturation des Capacity Units (CU).

⚡ En 30 secondes

Ce qu’il faut retenir :

• Fabric Chargeback App montre qui consomme la capacité Fabric. Ce rapport Power BI ventile les Capacity Units (CU) par workspace, item, domaine et utilisateur, avec des données actualisées chaque jour.

• Elle fournit la consommation, pas une facture en euros.

• Utiliser les domaines pour faciliter la refacturation avec le Chargeback.

S'abonner maintenant

Je vois ce scénario où les équipes IT essayent de refacturer grâce à l’application Capacity Metrics où on peut suivre la consommation au niveau de chaque capacité Elles pensent que “l’outil de monitoring FinOps est en place”, jusqu’au jour où la DAF pose la vraie question de la refacturation par équipe, elles se retrouvent à monter un Notebook custom pour agréger l’export CSV. Plutôt que reconstruire une solution personnalisée, je vais vous montrer qu’il existe une application pour facilement refacturer les CU Fabric.

Deux apps : deux angles de FinOps différents

Microsoft expose deux applications Power BI officielles pour piloter la consommation d’une capacité Fabric, installées par l’administrateur de la capacité depuis AppSource :

1. Microsoft Fabric Capacity Metrics App : elle expose la santé, l’usage et la performance de chaque capacité avec des données rafraîchies toutes les 10 à 15 minutes, une granularité de 30 secondes, et des visuels de throttling, d’autoscale, de storage et de plan capacité.

2. Microsoft Fabric Chargeback App ! Est-ce la solution miracle ? Elle permet l’allocation des coûts (ventilation par équipe) ! Elle expose la consommation CU par workspace, item, domain / subdomain et user, avec un refresh quotidien, un drill-through et un export pour intégration à vos outils Finance.

Le mécanisme recommandé : d’abord on vérifie ce qui s’est passé avec la Capacity Metrics App, ensuite on attribue les coûts en fonction des CU consommés avec la Chargeback App, enfin la refacturation formelle grâce à Azure Cost Management pour la partie externe entre Fabric capacité et l’abonnement.

En savoir plus sur la Capacité Metric App :

Fabric Chargeback App : la ventilation par équipe

a. Ce que ça fait

Est-ce encore une application pour faire beau ? Là où Metrics App expose la santé technique d’une capacité, la Chargeback App répond à une seule question : qui consomme quoi ?

Ses visuels sont pensés pour la refacturation, voici l’interface de la Chargeback app :

1. Workspace, Item, Domain / Subdomain : trois onglets pour voir quel pourcentage de la capacité a été consommé par chaque axe.

2. Utilization (CU) by date montre l’utilisation quotidienne agrégée et permet de cerner les tendances.

3. Utilization (CU) details, c’est une matrice ligne à ligne avec les détails de consommation.

4. Drill-through permet d’avoir une vue dédiée et détaillée sur un périmètre précis (workspace, item ou domain).

5. Export data, matrice complète exportable avec des slicers pour filtrer, colonnes de hiérarchie sélectionnables, format compatible Excel / Power BI Desktop.

La configuration de l’application est très simple, il y a deux paramètres qui définissent son cadre d’analyse :

• UTC Offset, le timezone à adapter avec l’heure de votre pays (typiquement 10 pour Sydney, 2 pour Paris été).

• Days Ago to Start, c’est la fenêtre historique à choisir entre 14 jours ou à 30 jours.

b. La Réalité du Terrain

• Actualisation quotidien uniquement : “The Fabric Chargeback Report data isn’t real-time; it’s refreshed daily.”

• Les domaines Fabric sont un prérequis, sans domaine assigné aux workspaces, l’app catégorise tout sous “No domain” et “No subdomain”. Vous refacturez au workspace sans axe métier. C’est le piège n°1 que je vois sur le terrain, et il est traité en amont dans le guide Fabric Domains : structurer vos workspaces sans transformer Fabric en marécage. (exemple ci-dessous)

• Setting tenant “Show user data” : Lorsque ce paramètre est activé, les données utilisateur actives, y compris les noms et adresses e-mail, sont affichées. Si votre tenant admin a désactivé ce setting côté audit, tous vos utilisateurs remontent comme “Masked user” et le count agrège tous les masked users en un seul.

• Non supporté sur Government clouds : Si vous êtes secteur public / défense sur un tenant gov. ou souverain, l’app n’est pas disponible.

• Non supporté avec Private Link : Si votre tenant utilise Private Links, cette app ne fonctionnera pas du tout.

• Installer dans un workspace Pro : Microsoft recommande explicitement un workspace avec licence Pro pour l’installation, afin d’éviter que l’app elle-même consomme des CU de votre capacity de production.

• Le modèle sémantique n’est pas réutilisable : Vous ne pouvez pas construire vos propres rapports Power BI par-dessus le modèle sémantique de l’app. Il est supporté uniquement pour les rapports fournis. Pour du reporting custom, vous exportez et vous rechargez ailleurs.

De la facture Azure à la refacturation à la bonne équipe

La facture Microsoft reste inchangée. Chargeback mesure la consommation et Cost Management présente les coûts.

1. Croiser trois données. Coût Azure de la capacité, consommation Chargeback sur la même période et correspondance workspace / domaine > équipe > centre de coûts.

2. Valider la clé de répartition. Par exemple, le prorata des CU consommées par équipe.

3. Vérifier les droits et les cibles. Les règles nécessitent un contrat pris en charge et les droits Enterprise Administrator (EA) ou Billing account owner (MCA).

4. Appliquer la ventilation. Dans Cost Management > Configuration > Cost allocation, répartissez les coûts entre subscriptions, resource groups ou tags. Les pourcentages ne se synchronisent pas avec Chargeback.

5. Contrôler et clôturer. Vérifiez que le total réparti correspond au coût de départ, archivez les sources et la clé retenue, puis transmettez les montants par centre de coûts à Finance pour les écritures internes.

Exemple fictif : sur 10 000 € à répartir, une clé validée de 30 / 50 / 20 % donne 3 000 € pour Finance, 5 000 € pour Marketing et 2 000 € pour la plateforme.

🥇 La Règle d’Or

Si tu dois retenir une chose : Metrics App est ton radar technique, Chargeback App est ta ventilation par équipe. Installe les deux, la première pour diagnostiquer, la seconde pour refacturer. Et avant de télécharger Chargeback, verrouille tes domaines dans Fabric, sinon 80 % de la valeur de l’app tombe dans “No domain”.

Et vous, avez-vous déjà installé la Chargeback App, ou vous êtes encore sur un export Notebook custom ? 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 : la FCC est une capacity Fabric à part entière : elle apparaîtra dans votre Chargeback et dans votre Metrics App, avec sa propre ventilation.

• Fabric Domains : structurer vos workspaces sans transformer Fabric en marécage : la prérequis absolu pour que Chargeback ne remonte pas 80 % de “No domain”.

📚 Ressources pour aller plus loin

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

• 📘 Microsoft Fabric Chargeback app : visuels, drill-through, considérations, limitations.

• 🛠️ Install the Microsoft Fabric Chargeback app : installation AppSource, paramètres UTC Offset / Days Ago, troubleshooting.

• 📘 What is the Microsoft Fabric Capacity Metrics app? : les 10 pages de l’app, latence, partage, support SKUs.

• 🔗 The Fabric throttling policy : smoothing, overages, carryforward, burndown : les mécaniques que Metrics App expose.

• 🛠️ Compute page in the Fabric Capacity Metrics app : throttling par fenêtre, ribbon charts, matrix par item et opération.

• 📘 FinOps framework Invoicing and chargeback : le cadre méthodologique Showback → Cost allocation → Chargeback appliqué au cloud Microsoft.

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