Row-Level Security dans Power BI : le guide complet
18 Janvier 2026 NEYO Analytics Team 9 min
Comment sécuriser l'accès aux données au niveau ligne, sans dégrader la performance de vos rapports.
RLS
Sécurité dynamique intégrée
DAX
Filtres optimisés sur dimensions
Fabric
Compatibilité Direct Lake
100%
Conformité RGPD & Azure AD
Qu'est-ce que la RLS et pourquoi elle est incontournable
La Row-Level Security (RLS) restreint l'accès aux données selon l'identité de l'utilisateur connecté, via des filtres DAX appliqués automatiquement à chaque requête. Concrètement : un même rapport peut afficher des résultats différents selon qui le consulte — un manager régional ne voit que sa région, un médecin ne voit que ses patients assignés, un client d'une plateforme multi-tenant ne voit que ses propres données. Sans RLS, sécuriser ces cas d'usage obligerait à dupliquer les rapports par périmètre, ce qui devient vite ingérable.
RLS statique vs RLS dynamique
RLS statique : les rôles utilisent des valeurs fixes dans le filtre DAX (par exemple [Région] = "Est"), avec un rôle distinct par périmètre d'accès. Adaptée à un petit nombre de niveaux d'accès qui changent rarement.
RLS dynamique : basée sur la fonction USERPRINCIPALNAME(), combinée à une table de mapping qui associe chaque utilisateur à son périmètre de données. Adaptée aux organisations avec des dizaines ou centaines d'utilisateurs, où créer un rôle statique par utilisateur serait ingérable.
Configurer un rôle RLS : les étapes
- Dans Power BI Desktop, ouvrir Modélisation > Gérer les rôles
- Créer un rôle et écrire l'expression de filtre DAX sur la table concernée
- Tester immédiatement avec "Afficher en tant que rôles" avant toute publication
- Publier le modèle et le rapport sur le service Power BI
- Dans le service, ajouter les utilisateurs ou groupes de sécurité Azure AD à chaque rôle
- Retester après publication : le comportement peut différer entre Power BI Desktop et le service
RLS et DirectQuery : une sécurité poussée jusqu'à la base
En mode DirectQuery, les filtres RLS écrits en DAX sont traduits en clauses SQL WHERE et exécutés directement sur la base de données source. Concrètement, la donnée non autorisée ne quitte jamais la source — un avantage de sécurité réel pour les environnements sensibles. La contrepartie : la performance dépend alors de l'indexation de la base source sur les colonnes utilisées par les filtres RLS.
Les erreurs les plus fréquentes
- Filtres RLS sur les tables de faitsAppliquer les filtres sur les tables de faits dégrade fortement la performance sur les gros volumes. La bonne pratique est de filtrer les dimensions et de laisser les relations du modèle propager la sécurité.
- Utiliser LOOKUPVALUEUtiliser LOOKUPVALUE au lieu de s'appuyer sur les relations actives du modèle. Les filtres RLS ne se propagent que via des relations actives.
- Table de mapping volumineuseTable de mapping de sécurité trop volumineuse ou en DirectQuery : elle doit être importée et réduite aux utilisateurs actifs uniquement.
- Tests uniquement en DesktopNe tester qu'en Power BI Desktop : un rôle validé en local doit être re-testé après publication sur le service, où le comportement peut différer (notamment en Direct Lake).
RLS et Microsoft Fabric / Direct Lake
Pour les modèles sémantiques en Direct Lake sous Microsoft Fabric, la RLS reste appliquée normalement. Un point de vigilance : si une requête DAX bascule en secours vers DirectQuery à cause d'une fonctionnalité non supportée en Direct Lake, les filtres RLS continuent de s'appliquer, mais les caractéristiques de performance peuvent changer — un point à surveiller via l'app de métriques de capacité Fabric.
Check-list avant mise en production
- Chaque rôle testé en "Afficher en tant que" dans Power BI Desktop
- Chaque rôle re-testé après publication sur le service Power BI
- Filtres appliqués sur les dimensions, pas sur les tables de faits
- Table de mapping de sécurité importée, réduite aux utilisateurs actifs
- Documentation des rôles et de leur logique partagée avec l'équipe cliente
- Groupes de sécurité Azure AD utilisés plutôt que des utilisateurs individuels quand c'est possible
Comment NEYO Analytics sécurise vos rapports
Chaque mission Power BI incluant de la RLS livre systématiquement une documentation des rôles et un cycle de test en environnement de recette avant mise en production, pour éviter tout incident de fuite de données.
MOTS-CLÉS & THÉMATIQUES :
#RLS Power BI#Row-Level Security#DAX#DirectQuery#Microsoft Fabric#sécurité données Power BI#Azure AD
Sources & Références : Microsoft Learn (documentation officielle RLS Power BI et Microsoft Fabric), guides spécialisés Power BI Consulting et DataCamp (bonnes pratiques RLS 2026).
Prêt à concrétiser votre projet Data ?
Discutez directement avec un expert NEYO Analytics pour qualifier votre besoin et estimer votre ROI Nearshore.
Parler à un expert NEYO