Gouvernance Fabric : Autoriser des items Fabric spécifiques sans ouvrir toute la plateforme ?

Le contexte : pourquoi ce modèle pose problème

De nombreuses organisations souhaitent exploiter certains items Fabric comme les Data Agents, Lakehouses ou Notebooks sans pour autant exposer l’intégralité de la surface Fabric à tous les utilisateurs.

Les inquiétudes reviennent toujours :

• Surconsommation de capacité, notamment lorsque des workloads Power BI critiques tournent déjà
• Investissements redondants, en doublonnant des plateformes data ou cloud existantes
• Gouvernance, notamment : Qui peut créer quoi ? Où ? Selon quelles conventions de nommage ?

Aujourd’hui, même en ciblant une capacité spécifique avec un groupe de sécurité, le modèle reste essentiellement tout ou rien. Par exemple :

Il est impossible d’autoriser des utilisateurs à créer uniquement des Data Agents sur une capacité donnée, sans leur permettre aussi de créer des Notebooks ou d’autres items Fabric.

Pourquoi désactiver des workloads Fabric n’est pas la solution

Microsoft Fabric a été conçu comme une plateforme SaaS unifiée, où la valeur vient précisément de l’intégration étroite entre les workloads.

Désactiver arbitrairement certaines briques va à l’encontre de cette philosophie.

👉 La bonne nouvelle : Le besoin de contrôles plus fins est clairement identifié côté Microsoft.

Lors de la dernière FabCon, les Fabric Policies ont été annoncées (actuellement en Private Preview) :

• Des politiques basées sur Microsoft Purview
• Un Policies Center intégré au catalogue OneLake
• La possibilité, pour les administrateurs de capacité, de restreindre la création de certains items (ex. Notebooks) et de cibler des utilisateurs et des workspaces précis
• Fabric applique automatiquement les règles : Action bloquée si non conforme et message explicite à l’utilisateur

Les premiers scénarios couvrent : Item Creation et Data Sharing, d’autres arriveront.

➡️ Demonstration : https://youtu.be/VC7xwTz2GjU

Pourquoi cette solution reste pertinente malgré les Fabric Policies

Cette solution ne concurrence pas les Fabric Policies : elle les complète.

• Les Fabric Policies répondent à : Qui peut créer quoi etOù
• Cette solution répond à une autre dimension clé : Comment les choses sont créées

Elle propose une expérience de provisioning guidée, consciente du contexte organisationnel, capable d’appliquer des décisions qu’aucune policy ne peut exprimer seule.

Là où la solution apporte une vraie valeur

• Conventions de nommage : Validation des noms d’espaces, d’items et d’agents avant tout appel API, avec un retour clair à l’utilisateur.
• Choix intelligent de la capacité : Sélection ou recommandation automatique de la bonne capacité selon le type de projet (BI, data engineering, IA).
• Provisioning organisé et dépendant : Création cohérente d’un ensemble d’objets : workspace, Lakehouse, Data Agent, shortcuts… alignés sur l’architecture de référence.
• Orientation du type de stockage : Guidage vers le bon item (Lakehouse, Warehouse, Eventhouse, Database…) selon la nature des données.
• Blueprints de bonnes pratiques : Intégration des standards de l’organisation : SKUs à éviter, dépendances existantes, plateformes already in place.
• Human-in-the-loop : Possibilité d’introduire une étape d’approbation (Power Automate, ServiceNow, email) avant création.
• Audit & chargeback : Traçabilité complète : demandeur, capacité choisie, items créés idéal pour la gouvernance et la FinOps.

👉 Les Fabric Policies définissent le code de la route, cette solution est l’auto-école !

Un modèle clé : séparer Création et Propriété

J’ai volontairement séparé deux concepts souvent confondus :

• Le droit de création
• La propriété après création

On passe à un modèle de provisioning basé sur l’intention, où la gouvernance est appliquée au moment de la création, et non via des permissions permanentes.

Comment ça fonctionne (l’histoire de Leo)

Leo a besoin d’un Data Agent.

• Il n’a pas de droits de création Fabric
• Il n’en aura jamais

À la place, Leo ouvre un simple assistant web et fournit :

• Nom du workspace
• Nom du Data Agent
• Capacité (optionnelle)
• Administrateur (optionnel)

Il clique sur Deploy.

Ce qui se passe en coulisses

Un runbook Azure Automation, exécuté sous Managed Identity, orchestre le tout via les API REST Fabric :

• Création ou réutilisation du workspace
• Association à la bonne capacité
• Création du Data Agent
• Attribution de Leo comme Admin du workspace

✅ Demande simple côté utilisateur

✅ Traçabilité complète côté IT

✅ Aucun droit de création Fabric accordé

Le point clé (et souvent contre‑intuitif)

Leo ne reçoit jamais de permission pour créer des items Fabric.

Mais une fois le Data Agent créé, il en est propriétaire.

Il peut :

• L’ouvrir dans Fabric
• Le connecter à ses sources de données
• Configurer son comportement
• Itérer librement

Comme n’importe quel owner de workspace.

👉 La frontière de gouvernance est posée une seule fois, au moment de la création.

Ce que contient la solution

• Une web app statique (HTML / CSS / JS)
• Un runbook Python Azure Automation, déclenché par webhook
• Aucun secret stocké (authentification via Managed Identity)
• Le webhook est le seul point d’entrée, diffusé par l’IT

Le projet est open-source, extensible à d’autres items Fabric que les Data Agents.

🔗 GitHub : aka.ms/FabricItemManagement

Pourquoi c’est important

Ce n’est pas qu’un contournement technique. C’est un modèle de gouvernance.

Il permet aux équipes plateformes de dire oui aux métiers de manière contrôlée traçable et répétable sans attendre que toutes les permissions granulaires natives soient disponibles.

Un accès contrôlé n’implique pas un accès bloqué.

Construit avec les retours d’Emilie Beau et Christopher Maneu, et accéléré grâce à VS Code Copilot et Claude Sonnet 4.6.