Skip to content
La mise en place correcte de la structure des capacités et des espaces de travail est cruciale lors de la migration de Power BI vers Fabric.Des erreurs dans cette configuration peuvent entraîner des coûts excessifs, une perte de confiance des utilisateurs et des problèmes de gestion.
Tenant : généralement, une organisation dispose d'un seul Tenant Microsoft Entra ID (anciennement Azure AD).Capacités : dans un tenant, on peut provisionner une ou plusieurs capacités. Une capacité est un pool de ressources dédié (calcul et stockage) alloué à Microsoft Fabric ou à Power BI. Les capacités Fabric s'achètent dans le portail Azure.Espaces de travail : chaque capacité peut héberger plusieurs espaces de travail.C'est là que les éléments Fabric (Data Warehouses, Data Pipelines, Notebooks, Power BI Reports, etc.) sont créés et organisés.Éléments (Items) : ce sont les objets individuels créés au sein d'un espace de travail.
Le dilemme : faut-il une seule capacité ou plusieurs ?Cas idéal : une seule capacité simplifie la gestion et réduit les coûts administratifs.Raisons d'avoir plusieurs capacités :Conformité de résidence des données (Data Residency) : des réglementations comme le RGPD imposent que les données soient stockées et traitées dans des zones géographiques spécifiques. Chaque capacité est provisionnée dans une région, donc plusieurs capacités sont nécessaires pour couvrir différentes régions.Alignement avec les centres de coûts organisationnels : pour faciliter la facturation et l'attribution des coûts, les départements (IT, Marketing, etc.) peuvent demander leur propre capacité.Séparation des charges de travail (Workloads) : pour isoler des charges de travail très intensives (ex: Data Engineering lourd, Machine Learning) ou pour garantir une expérience utilisateur optimale pour des rapports Power BI critiques avec des refreshs fréquents.
Qu'est-ce qu'un Espace de travail ? Un lieu pour créer et collaborer sur des éléments Fabric. C'est aussi le niveau principal pour gérer les permissions.Stratégies courantes pour les espaces de travail :Par département,par architecture Médaillon (Bronze/Silver/Gold),par environnement (Dev/Test/Prod).Le problème : Une conception trop granulaire conduit rapidement à un nombre excessif d'espaces de travail.Signes que vous avez trop d'espaces de travail :Difficulté à comprendre le flux de données de bout en bout.Fardeau administratif ingérable.Expérience utilisateur médiocre (trop d'espaces à parcourir, difficulté à trouver les éléments).Solutions pour réduire le nombre d'espaces de travail :Aligner sur les personas : Créer des espaces de travail dédiés à des rôles spécifiques (ex: Data Engineering, Data Science) et y ajouter les personnes concernées.Convention de nommage des éléments : Utiliser des conventions de nommage claires pour différencier les environnements (Dev, Test, Prod) au sein d'un même espace de travail (ex: DW_Sales_Dev, DW_Sales_Prod).Utiliser le partage au niveau de l'élément (Item-level sharing) : Ne pas créer un espace de travail juste pour héberger une seule table ou un rapport s'il peut être partagé individuellement.
Le problème : ajouter des utilisateurs un par un à des espaces de travail ou partager des éléments spécifiques avec chaque individu rend la gestion complexe et fastidieuse. Quand une personne quitte l'entreprise ou change de rôle, il faut penser à révoquer toutes ses permissions.La solution : Utiliser des groupes de sécurité Microsoft Entra ID ou des groupes Microsoft 365.Créez des groupes (ex: Data Engineers, Sales Analysts).Attribuez des rôles (Admin, Member, Contributor, Viewer) à ces groupes dans les espaces de travail ou sur des éléments spécifiques.Lorsque quelqu'un rejoint l'équipe, il suffit de l'ajouter au groupe approprié. Lorsqu'il part, on le retire du groupe.
Les rôles : dans un espace de travail, il y a 4 rôles : Admin, Member, Contributor, Viewer.Le problème : les utilisateurs ne comprennent pas toujours ce que chaque rôle permet de faire, surtout en fonction du type d'élément Fabric.Explication des rôles (simplifiée) :Viewer : Peut uniquement consulter le contenu des éléments. Exception : peut exécuter un Data Pipeline (et l'annuler). Accès au point SQL d'un Lakehouse, mais pas via Spark.Contributor : Peut créer, modifier, supprimer des éléments.Member : A les permissions de Contributor plus la gestion des accès (ajout/suppression d'utilisateurs).Admin : Contrôle total, y compris la gestion des capacités.Points clés :Les permissions pour Admin, Member et Contributor sont généralement identiques pour les éléments Fabric eux-mêmes.La distinction se fait surtout sur la gestion des accès et des capacités.Le rôle Viewer est le plus restrictif.
Le problème : on ne peut pas partager tous les éléments Fabric individuellement. Par exemple, les Data Pipelines, les Dataflows, et les Event Streams ne peuvent pas être partagés individuellement au moment de l'enregistrement de la vidéo. Pour y donner accès, il faut partager l'espace de travail entier.Implications : cela oblige à une planification minutieuse : si un Data Pipeline doit être utilisé par une équipe qui n'a pas besoin d'accéder à tout l'espace de travail, cela peut poser problème.Partage d'éléments possibles : Data Warehouse, Lakehouse, Notebooks, Power BI Reports, Dashboards, etc.Options de partage : Lors du partage d'un élément, on peut définir des permissions spécifiques (ex: peut lire, peut modifier, peut partager).
Niveau granulaire : dans un Data Warehouse ou le point SQL d'un Lakehouse, il est possible d'aller plus loin que le partage de l'élément entier. On peut partager des objets spécifiques comme des tables, des vues, et même implémenter :Sécurité au niveau des colonnes (Column Level Security).Sécurité au niveau des lignes (Row Level Security).Masquage dynamique des données (Dynamic Data Masking).Le problème : ces permissions au niveau objet ne sont pas toujours respectées lorsque l'accès se fait via Spark.Si un utilisateur a le rôle "Viewer" sur un Lakehouse, il ne peut accéder qu'au point SQL. Les permissions au niveau objet y seront respectées.Mais si cet utilisateur a un rôle supérieur (Contributor, Member, Admin), il peut accéder au Lakehouse via Spark. Dans ce cas, les permissions au niveau objet ne s'appliquent plus ; il aura accès à toutes les tables et colonnes (sauf si d'autres sécurités sont appliquées).
Scénario : Lire des données dans un espace de travail, les transformer, et les écrire dans un autre.Le problème : Certaines activités de Data Pipeline sont limitées à leur propre espace de travail :Activité de copie (Copy Activity) : La source et la destination des données doivent être dans le même espace de travail que le Data Pipeline. On ne peut pas déplacer des données entre espaces de travail avec cette activité.Activité Stored Procedure : Le Data Pipeline doit être dans le même espace de travail que le Data Warehouse contenant la procédure stockée.Activité Invoke Pipeline : Le pipeline parent et le pipeline enfant doivent être dans le même espace de travail.Solutions : Pour les opérations inter-espaces de travail, il faut utiliser d'autres éléments Fabric comme les Notebooks (Spark) ou les Dataflows.
Support formation Microsoft Fabric
- Pages
7 erreurs de capacités, espaces de travail et de contrôle d'accès dans Fabric
La hiérarchie générale d'un environnement Fabric
Erreur #1 : mauvais nombre de capacités
Erreur #2 : trop d'espaces de travail
Erreur #3 : partage individuel au lieu de groupes
Erreur #4 : mauvaise compréhension des rôles d'accès
Erreur #5 : partage d'éléments individuels inapproprié
Erreur #6 : mauvaise utilisation du partage granulaire (Object Level Sharing)
Erreur #7 : limitations des opérations inter-espaces de travail
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.