RLS Power BI : guide de mise en œuvre pour décideurs

Concrètement : un commercial ne voit que ses propres opportunités, un directeur régional uniquement son périmètre. La première action à entreprendre est simple : créez un rôle statique dans Power BI Desktop (par exemple [Region] = "West"), puis cliquez sur « Afficher en tant que rôle » pour vérifier que le filtre fonctionne avant toute publication. Selon la documentation Microsoft Learn, la RLS s’applique exclusivement aux utilisateurs disposant de l’autorisation Lecteur dans le service Power BI.

Quelques points à retenir immédiatement :

• La RLS filtre les données au moment de l’exécution des requêtes DAX, pas à l’import.
• Les rôles d’espace de travail Admin, Member et Contributor ne sont pas soumis à la RLS : ils voient toutes les lignes.
• La RLS s’applique aux jeux de données importés et à certains modèles DirectQuery ; pour les connexions actives vers Analysis Services, la configuration se fait dans le modèle source.
• Les utilisateurs B2B (invités) peuvent être membres d’un rôle RLS, avec quelques limitations sur le test d’identité.

Conseil de pro : Le piège le plus fréquent en entreprise est de croire qu’un utilisateur avec le rôle Contributor est protégé par la RLS. Il ne l’est pas. Vérifiez systématiquement les droits d’espace de travail avant de valider votre dispositif de sécurité.

Points clés

La RLS Power BI est un mécanisme de filtrage ligne par ligne qui s’applique à chaque requête DAX, exclusivement pour les utilisateurs avec le rôle Lecteur, et dont l’efficacité dépend autant de la qualité du modèle que de la rigueur des règles DAX.

Table des matières

• Qu’est-ce que la RLS dans Power BI et en quoi diffère-t-elle de l’OLS ?
• Comment créer des rôles RLS dans Power BI Desktop, étape par étape
• Quels patrons DAX utiliser pour vos règles RLS ?
• Où appliquer la RLS selon votre mode de connexion ?
• Comment gérer l’appartenance aux rôles RLS dans le service Power BI ?
• Comment valider et tester la RLS avant et après publication ?
• Quelles bonnes pratiques de modélisation pour préserver les performances ?
• Quels pièges éviter et quand la RLS n’est-elle pas la bonne solution ?
• Checklist opérationnelle pour déployer la RLS en entreprise
• Ce que l’expérience terrain révèle sur la RLS en entreprise
• Vous souhaitez déployer la RLS dans votre organisation ?
• Sources
• Questions fréquentes

Qu’est-ce que la RLS dans Power BI et en quoi diffère-t-elle de l’OLS ?

La RLS (Row-Level Security) est un mécanisme de filtrage qui s’applique à chaque requête DAX exécutée sur un modèle Power BI. Résultat : deux utilisateurs ouvrant le même rapport voient des volumes de données différents, sans que le rapport lui-même soit dupliqué.

Point opérationnel souvent mal compris : la RLS ne protège que les utilisateurs ayant le rôle Lecteur dans l’espace de travail. Un administrateur, un membre ou un contributeur contourne automatiquement tous les filtres RLS, quelle que soit la sophistication des règles définies.

L’OLS (Object-Level Security), en revanche, masque des objets entiers : tables ou colonnes disparaissent complètement de la vue de certains rôles. Là où la RLS filtre les lignes d’une table visible, l’OLS rend cette table inexistante pour l’utilisateur. Autre différence pratique : l’OLS ne se configure pas via l’interface standard de Power BI Desktop ; elle nécessite Tabular Editor ou une manipulation XMLA, ce qui implique des compétences supplémentaires et un workflow de déploiement adapté.

Conseil de pro : Combiner RLS et OLS crée une protection à deux niveaux : les lignes non autorisées sont filtrées ET les colonnes sensibles (ex. rémunérations) sont totalement invisibles. C’est l’approche recommandée pour les données à caractère personnel soumises au RGPD, comme le souligne cette analyse comparative.

Comment créer des rôles RLS dans Power BI Desktop, étape par étape

La procédure se déroule entièrement dans Power BI Desktop avant publication. Voici les étapes dans l’ordre :

1. Ouvrir l’éditeur de rôles : dans le ruban « Modélisation », cliquez sur « Gérer les rôles ».
2. Créer un rôle : cliquez sur « Créer », donnez un nom explicite (ex. Ventes_Region_Est), évitez les espaces et les caractères spéciaux pour faciliter la gestion programmatique.
3. Sélectionner la table : choisissez la table sur laquelle le filtre s’applique (de préférence une table de dimension, pas une table de faits).
4. Définir le filtre : l’éditeur par défaut propose une interface visuelle pour les filtres simples. Pour les expressions dynamiques (USERPRINCIPALNAME(), USERNAME(), CUSTOMDATA()), basculez vers l’éditeur DAX en cliquant sur « Basculer vers l’éditeur DAX ».
5. Tester localement : utilisez « Afficher en tant que rôle » (onglet Modélisation) pour simuler la vue d’un utilisateur assigné à ce rôle.
6. Sauvegarder et publier : enregistrez le fichier .pbix, puis publiez vers le service Power BI. Les définitions de rôles sont incluses dans le jeu de données publié.

Quelques points d’attention pratiques :

• Séparateurs locaux : en France et en Europe centrale, le séparateur de liste dans les expressions DAX est le point-virgule (;), non la virgule. Une expression valide en anglais peut échouer si vous copiez-collez sans adapter.
• Format de USERNAME() vs USERPRINCIPALNAME() : USERNAME() retourne DOMAINEutilisateur dans un environnement on-premise, tandis que USERPRINCIPALNAME() retourne l’adresse e-mail (UPN) dans le service Power BI cloud. Utilisez USERPRINCIPALNAME() pour les déploiements cloud.
• Nommage des rôles : adoptez une convention cohérente dès le départ ([Périmètre]_[Entité]). Cela facilite les audits et la maintenance.

Pour approfondir les expressions DAX utilisées dans ces règles, le guide DAX de Biworks couvre les fonctions essentielles avec des exemples concrets.

Quels patrons DAX utiliser pour vos règles RLS ?

Les expressions DAX constituent le cœur de la RLS. Voici les modèles les plus courants, du plus simple au plus avancé.

Règle statique : adaptée quand les périmètres sont fixes et peu nombreux.

[Region] = "Est"

Un rôle par région, chaque utilisateur assigné manuellement. Simple à mettre en place, difficile à maintenir au-delà d’une dizaine de valeurs.

RLS dynamique avec USERPRINCIPALNAME() : le modèle le plus répandu en entreprise. Une table de mappage (Utilisateurs) contient deux colonnes : l’UPN et la valeur de filtrage (région, entité, code commercial). L’expression DAX sur la table de dimension devient :

[Region] = LOOKUPVALUE(
    Utilisateurs[Region];
    Utilisateurs[UPN];
    USERPRINCIPALNAME()
)

Un seul rôle suffit pour tous les utilisateurs. Ajouter un nouvel utilisateur revient à insérer une ligne dans la table de mappage, sans modifier le modèle. C’est l’approche détaillée dans ce tutoriel RLS dynamique.

• Filtre par commercial : remplacez [Region] par [CodeCommercial] et adaptez la table de mappage. Même logique, périmètre différent.
• Filtre par territoire hiérarchique : utilisez PATHCONTAINS() pour gérer des hiérarchies (un directeur régional voit plusieurs territoires).
• CUSTOMDATA() pour les scénarios embarqués (Power BI Embedded) : la valeur est transmise via le paramètre EffectiveIdentity de l’API REST, ce qui permet de filtrer sans exposer l’identité Azure AD de l’utilisateur final.

Conseil de pro : Méfiez-vous des expressions qui retournent TRUE pour toutes les lignes en cas de valeur inattendue. Une expression comme IF(USERPRINCIPALNAME() = ""; TRUE(); [Region] = LOOKUPVALUE(...)) expose toutes les données si l’UPN est vide. Préférez une expression qui retourne FALSE par défaut : [Region] = LOOKUPVALUE(Utilisateurs[Region]; Utilisateurs[UPN]; USERPRINCIPALNAME(); "AUCUNE_VALEUR").

Où appliquer la RLS selon votre mode de connexion ?

Le choix du bon endroit pour configurer la RLS dépend directement de la topologie technique de votre modèle. Ce n’est pas une décision anodine : une mauvaise configuration peut donner l’illusion d’une sécurité qui n’existe pas.

• Modèles importés : la RLS se définit dans Power BI Desktop et s’applique dans le service. C’est le cas le plus simple et le plus courant.
• DirectQuery : la RLS peut être définie dans Power BI pour de nombreuses sources, mais le comportement dépend de la source sous-jacente. Certaines sources transmettent le filtre en SQL, d’autres non.
• Connexions actives (Live Connection) vers Analysis Services ou Azure Analysis Services : la RLS doit être gérée directement dans le modèle Analysis Services, pas dans Power BI Desktop. Toute règle définie côté Power BI sera ignorée, comme le précise la documentation officielle Microsoft.
• Direct Lake (Microsoft Fabric) : la RLS est supportée, mais attention au mécanisme de fallback vers DirectQuery qui peut modifier les caractéristiques de performance selon le volume de données et la capacité Fabric.
• Power BI Report Server (on-premise) : la RLS se configure sur les jeux de données importés ; les membres ayant des droits Serveur de publication ou Gestionnaire de contenu peuvent affecter des membres à des rôles, selon la documentation Report Server.

Checklist de décision rapide :

• Votre modèle est importé ? Configurez la RLS dans Power BI Desktop.
• Vous utilisez une connexion active vers Analysis Services ? Configurez la RLS dans le modèle AS, pas dans Power BI.
• Vous êtes sur Microsoft Fabric avec Direct Lake ? Testez les performances avec et sans RLS avant de valider l’architecture.
• Vous avez besoin d’une gouvernance centralisée multi-rapports ? Privilégiez la RLS au niveau du jeu de données partagé.

Conseil de pro : Pour les architectures Power BI et Azure avec DirectQuery sur SQL Server, activez la sécurité au niveau de la source (vues SQL filtrées ou RLS SQL Server) en complément de la RLS Power BI. Les deux couches se renforcent mutuellement.

Comment gérer l’appartenance aux rôles RLS dans le service Power BI ?

Une fois le modèle publié, l’attribution des utilisateurs aux rôles se fait dans le service Power BI, pas dans Desktop. Le processus est le suivant : accédez au jeu de données dans votre espace de travail, cliquez sur les trois points puis sur « Sécurité », et ajoutez des membres à chaque rôle.

Recommandations pour une gouvernance scalable :

• Privilégiez les groupes Microsoft Entra (anciennement Azure AD) plutôt que les assignations individuelles. Un groupe se synchronise avec l’annuaire d’entreprise : quand un collaborateur quitte l’organisation, son accès est révoqué automatiquement. La checklist sécurité Power BI de Biworks détaille cette approche pour les équipes IT.
• Utilisateurs B2B (invités) : ils peuvent être membres d’un rôle RLS, mais la fonctionnalité « Tester en tant que rôle » ne fonctionne pas pour les identités externes dans tous les contextes. Prévoyez des tests manuels avec un compte invité réel.
• Rôles d’espace de travail : Admin, Member et Contributor voient toutes les données, RLS ou non. C’est l’erreur de gouvernance la plus fréquente observée en entreprise. Un utilisateur qui n’a besoin que de consulter des rapports doit avoir le rôle Lecteur, pas Contributor.

Conseil de pro : Documentez chaque groupe Azure AD utilisé dans vos rôles RLS avec son propriétaire métier et sa date de dernière revue. Sans cette traçabilité, les accès s’accumulent silencieusement au fil des réorganisations.

Comment valider et tester la RLS avant et après publication ?

Un dispositif RLS non testé est un dispositif non sécurisé. La validation doit couvrir les cas nominaux ET les cas limites.

Checklist de tests à suivre systématiquement :

• « Afficher en tant que rôle » dans Power BI Desktop : simulez chaque rôle défini et vérifiez que les visuels affichent uniquement les lignes attendues. Testez aussi avec une valeur d’UPN qui n’existe pas dans la table de mappage : le rapport doit afficher zéro ligne, pas toutes les lignes.
• Performance Analyzer : comparez les temps de requête avant et après activation de la RLS. Un écart significatif signale un problème de modélisation (filtre sur table de faits, relation bidirectionnelle non optimisée).
• Test des valeurs limites : que se passe-t-il si USERPRINCIPALNAME() retourne une valeur vide ou malformée ? Votre expression doit retourner FALSE (aucune ligne), jamais TRUE (toutes les lignes).
• Scénarios embarqués (Power BI Embedded) : utilisez le paramètre EffectiveIdentity via l’API REST pour simuler des identités et vérifier que CUSTOMDATA() transmet correctement les valeurs attendues.
• Validation post-publication : dans le service Power BI, utilisez « Tester en tant que » sur le jeu de données pour confirmer que les filtres s’appliquent correctement en production.

Conseil de pro : Si votre organisation dispose d’un pipeline CI/CD pour les déploiements Power BI (via les API REST ou Fabric Git integration), intégrez des tests automatisés de vos règles RLS. Un jeu de tests unitaires vérifiant que chaque rôle retourne exactement les lignes attendues détecte les régressions avant qu’elles n’atteignent la production.

Quelles bonnes pratiques de modélisation pour préserver les performances ?

La RLS n’est pas gratuite en termes de performance. Chaque requête DAX exécutée sur un rapport avec RLS active embarque un filtre supplémentaire, ce qui alourdit le plan d’exécution. Sur un modèle mal conçu, l’impact peut être substantiel.

Les recommandations officielles Microsoft sont claires sur ce point : appliquez la RLS sur les tables de dimension, pas sur les tables de faits. Dans un schéma en étoile, le filtre se propage naturellement de la dimension vers les faits via les relations, sans que vous ayez à dupliquer la règle sur chaque table de faits.

Le filtrage croisé bidirectionnel mérite une attention particulière. Activé pour propager les filtres RLS dans les deux sens d’une relation, il peut multiplier les chemins de filtrage et dégrader fortement les performances sur des modèles complexes. Testez systématiquement avec Performance Analyzer et les métriques de capacité Fabric avant de valider ce choix en production. Le document technique sur la sécurisation des modèles tabulaires détaille les mécanismes internes pour les équipes qui souhaitent aller plus loin.

Conseil de pro : *Avant d’activer la RLS en production sur un grand modèle, mesurez le temps de requête de vos visuels les plus lourds sans RLS, puis avec.

Quels pièges éviter et quand la RLS n’est-elle pas la bonne solution ?

La RLS est puissante, mais elle n’est pas la réponse à tous les problèmes de contrôle d’accès. Connaître ses limites évite des architectures fragiles.

Pièges fréquents :

• Règles contradictoires entre rôles multiples : si un utilisateur est membre de deux rôles, Power BI applique l’union des filtres (logique OR). Un utilisateur dans Rôle_Est ET Rôle_Ouest voit les données des deux régions. Ce comportement est souvent inattendu.
• Workspace roles qui contournent la RLS : comme rappelé par Joël Crest, c’est l’erreur classique. Un Contributor voit tout, sans exception.
• USERNAME() en environnement cloud : cette fonction retourne le format DOMAINEutilisateur en on-premise, mais peut retourner l’UPN en cloud selon le contexte. Préférez USERPRINCIPALNAME() pour les déploiements cloud afin d’éviter des retours inattendus.

Quand éviter la RLS :

• Quand le périmètre de sécurité est très simple (deux ou trois utilisateurs, données non sensibles) : des exports sécurisés ou des espaces de travail séparés sont plus simples à maintenir.
• Quand la source de données dispose déjà d’une sécurité robuste (vues SQL filtrées, RLS SQL Server) : dupliquer la logique dans Power BI crée deux points de maintenance.
• Quand les calculs agrégés (totaux, moyennes) doivent ignorer les filtres RLS pour certains visuels : la RLS s’applique à toutes les requêtes sans exception, ce qui peut rendre certains indicateurs de synthèse impossibles à afficher correctement.

Alternatives pratiques :

• OLS pour masquer des colonnes ou tables entières (salaires, marges, données personnelles).
• Tables résumées (summary tables) pré-agrégées pour des calculs non contraints par la RLS.
• Sécurité côté source pour DirectQuery : vues SQL filtrées ou RLS SQL Server, plus proches de la donnée.

Conseil de pro : Traitez vos règles RLS comme du code : versionnez-les dans un dépôt Git, documentez chaque rôle avec son propriétaire métier et sa justification. Une règle non documentée est une règle qu’on ne sait plus modifier sans risque.

Checklist opérationnelle pour déployer la RLS en entreprise

Un déploiement RLS réussi ne s’improvise pas. Voici une checklist structurée pour piloter l’implémentation de bout en bout, adaptée aux organisations en Europe centrale.

Pré-déploiement :

• Cartographier les périmètres de données et les profils utilisateurs (qui doit voir quoi).
• Identifier le mode de connexion (import, DirectQuery, Live Connection) pour choisir où configurer la RLS.
• Vérifier les rôles d’espace de travail existants et s’assurer que seuls les Lecteurs sont soumis à la RLS.
• Créer ou mettre à jour la table de mappage utilisateurs dans la source de données.

Déploiement :

• Définir les rôles dans Power BI Desktop avec des noms explicites et une convention cohérente.
• Écrire et valider les expressions DAX (statiques ou dynamiques) avec l’éditeur DAX.
• Publier le modèle et attribuer les groupes Microsoft Entra aux rôles dans le service Power BI.

Tests et validation :

• Tester chaque rôle avec « Afficher en tant que rôle » et vérifier les cas limites (UPN inexistant, valeur vide).
• Mesurer l’impact sur les performances avec Performance Analyzer.
• Valider avec un utilisateur réel disposant du rôle Lecteur.

Surveillance et maintenance :

• Planifier des revues trimestrielles des membres de chaque rôle (départs, changements de poste).
• Auditer les modifications de règles RLS via les journaux d’activité du service Power BI.
• Mettre à jour la table de mappage lors de chaque évolution organisationnelle.

Pour aller plus loin sur la protection des données dans Power BI et Fabric, le guide protection des données cloud en 9 étapes de Biworks complète utilement cette checklist.

Pour les décideurs qui souhaitent comprendre comment la data s’intègre dans la stratégie d’entreprise, ce contexte stratégique éclaire utilement les choix de gouvernance des accès.

Ce que l’expérience terrain révèle sur la RLS en entreprise

La RLS est techniquement accessible. Ce qui échoue, en pratique, c’est rarement la syntaxe DAX.

Le problème récurrent observé dans les organisations en Europe centrale est d’ordre organisationnel : les règles RLS sont définies avec soin, testées en recette, puis contournées en production parce que des utilisateurs ont conservé le rôle Contributor « par commodité ». La sécurité technique ne compense jamais une gouvernance des accès défaillante. C’est pourquoi la première recommandation, avant même d’écrire la première expression DAX, est d’auditer les rôles d’espace de travail et de réduire les droits au strict nécessaire.

Deuxième point souvent sous-estimé : la maintenance. Une table de mappage utilisateurs non mise à jour après une réorganisation devient une faille. Des collaborateurs qui ont changé de périmètre continuent de voir les données de leur ancien poste, parfois pendant des mois. Automatiser la synchronisation de cette table avec l’annuaire Azure AD, ou planifier des revues trimestrielles, n’est pas optionnel dans un environnement soumis au RGPD.

Enfin, la tentation de mettre la RLS partout est réelle. Or, sur des modèles complexes avec des millions de lignes et des relations bidirectionnelles, l’impact sur les performances peut rendre les rapports inutilisables. La bonne approche est de mesurer d’abord, de simplifier le modèle si nécessaire, puis d’activer la RLS sur une architecture déjà optimisée.

Vous souhaitez déployer la RLS dans votre organisation ?

Mettre en place une RLS fiable dans un environnement d’entreprise demande plus qu’une bonne maîtrise de DAX : il faut une vision claire de la gouvernance des accès, une architecture de modèle adaptée et une procédure de test rigoureuse. C’est précisément ce que Biworks apporte à ses clients.

Biworks accompagne les organisations dans l’audit de leur sécurité Power BI, la configuration de règles RLS adaptées à leur structure (filiales, multi-entités, utilisateurs B2B), et la formation de leurs équipes. Les formations certifiantes Power BI de Biworks, éligibles au CPF et certifiées Qualiopi, couvrent la RLS et DAX dans un programme orienté mise en pratique immédiate. Pour un accompagnement sur mesure, les consultants BI de Biworks prennent en charge l’implémentation complète, de l’audit initial au déploiement en production. Contactez Biworks pour définir ensemble le périmètre d’intervention adapté à votre contexte.

Sources

Les ressources ci-dessous constituent les références de base pour implémenter et maintenir la RLS dans Power BI :

Sécurité au niveau des lignes avec Power BI — Microsoft Learn (FR) : la référence officielle en français pour créer des rôles, attribuer des membres et comprendre les limites de la RLS dans le service Power BI. Point de départ recommandé pour tout projet d’implémentation.

• Sécurité au niveau des lignes avec Power BI – Microsoft Fabric | Microsoft Learn
• Row-level security (RLS) with Power BI – Microsoft Fabric | Microsoft Learn
• Securing the Tabular BI Semantic Model (technical article)
• Sécurité données POWER BI: Sans maîtrise, tu rates ta mission BI !

Questions fréquentes

Qu’est-ce que la RLS dans Power BI ?

Elle s’applique uniquement aux utilisateurs avec l’autorisation Lecteur dans le service Power BI.

Les administrateurs d’espace de travail sont-ils soumis à la RLS ?

Non. Les rôles Admin, Member et Contributor dans un espace de travail Power BI contournent automatiquement toutes les règles RLS et voient l’intégralité des données, quelle que soit la configuration.

Quelle est la différence entre RLS et OLS dans Power BI ?

Combiner les deux offre une protection à deux niveaux, particulièrement utile pour les données sensibles soumises au RGPD.

Comment configurer la RLS pour une connexion active vers Analysis Services ?

Pour une connexion active (Live Connection) vers SQL Server Analysis Services ou Azure Analysis Services, la RLS doit être configurée directement dans le modèle Analysis Services, pas dans Power BI Desktop. Toute règle définie côté Power BI sera ignorée dans ce contexte.

Comment tester que la RLS fonctionne correctement avant publication ?

Dans Power BI Desktop, utilisez « Afficher en tant que rôle » (onglet Modélisation) pour simuler la vue d’un utilisateur assigné à un rôle. Testez également les cas limites : un UPN inexistant dans la table de mappage doit retourner zéro ligne, jamais toutes les lignes.

Recommandation

• Mettre en place une BI efficace avec Power BI : guide pratique
• Démarrer avec Power BI : le guide pour les professionnels
• Démarrer avec Power BI : guide simple pour les professionnels