RLS dans Power BI : guide pratique du débutant à expert avec exemples réels

Tu prêtes un classeur Excel à plusieurs collègues, et tu veux qu’ils ne puissent voir que les lignes qui les concernent (leur département, leur région, leur équipe) ? Tu pourrais créer plusieurs fichiers ou des filtres manuels, mais c’est fastidieux, sujet à erreur, et non sécurisé.

La RLS (Row-Level Security) dans Power BI joue ce rôle : elle permet de restreindre, pour chaque utilisateur ou rôle, les lignes de données qu’il est autorisé à voir. Autrement dit, c’est un filtre invisible appliqué en arrière-plan, selon le profil utilisateur.

Par exemple, un commercial de la région Nord ne verra dans le rapport que les ventes pour le Nord, tandis que le directeur national verra toutes les régions.

Si tu utilises Power BI dans un contexte où les données sont sensibles (financières, RH, géographiques…), la RLS est un outil essentiel pour assurer que chacun ne voit que ce qu’il est censé voir.

Types de RLS Power BI : statique vs dynamique

Avant de plonger dans les exemples, distinguons deux grandes approches de la RLS :

la RLS statique, c’est comme attribuer des clés physiques à chaque employé : si tu changes une porte, tu dois refaire les clés. La RLS dynamique, c’est une serrure électronique qui lit l’empreinte digitale/utilisateur : tu peux gérer les droits sans toucher à la serrure.

Mise en œuvre d'un RLS Power BI pas à pas

Je vais d’abord présenter la mise en œuvre statique, puis monter progressivement vers la RLS dynamique.

A. RLS statique — un scénario simple

Contexte

Tu as une table de ventes (Ventes), avec une colonne Région, et tu veux que les utilisateurs dans les régions “Nord” ou “Sud” ne voient que les données de leur région.

Étapes

1. Ouvrir ton modèle dans Power BI Desktop
   Assure-toi que tes données sont bien chargées.
2. Créer des rôles
   Dans le ruban : Modélisation → Gérer les rôles.
3. Ajouter un rôle par exemple “Région Nord”
   Dans la fenêtre, clique “Créer”, nomme-le “Nord”.
   Sélectionne la table Ventes. Ajoute un filtre DAX comme : Ventes[Région] = "Nord" Clique sur la coche pour vérifier l’expression.
4. Ajouter un rôle “Région Sud”
   Même démarche, mais filtre Ventes[Région] = "Sud".
5. Tester les rôles
   Dans le menu Modélisation, clique "Voir comme" → choisis “Nord” ou “Sud” pour simuler ce que verrait un utilisateur.
6. Publier le rapport
   Publie sur le service Power BI.
7. Assigner les rôles dans Power BI Service
   Dans l’espace de travail, sur le dataset publié → Sécurité.
   Pour chaque rôle (Nord / Sud), ajoute les utilisateurs qui y appartiennent.
8. Vérifier les accès
   Utilise “Tester le rôle” pour t’assurer que les utilisateurs voient bien ce qu’ils doivent.

Cette approche est simple mais peut vite être lourde à maintenir lorsque les besoins évoluent.

RLS dynamique — scénario plus réaliste

Scénario

Tu as une table Utilisateurs avec le champ Email ; une table Ventes liée à cette table via une clé (par exemple UtilisateurID). Tu veux que chaque utilisateur ne voie que les ventes liées à son propre email.

Étapes

• Importe la table utilisateurs
  Par exemple :

Établir les relations

• Utilisateurs[UtilisateurID] → Ventes[UtilisateurID]

Créer un rôle dynamique

Dans Gérer les rôles, crée un rôle “RLS_Dynamique”.
Sur la table Utilisateurs, ajoute un filtre DAX :

Utilisateurs[Email] = USERPRINCIPALNAME()

USERPRINCIPALNAME() renvoie l'adresse email ou l’identifiant de l’utilisateur connecté dans le service Power BI.

Cela signifie : l’utilisateur ne verra que les lignes de la table Utilisateurs correspondant à son email. Par propagation, cela restreindra la table Ventes.

Publier et configurer sur le service

Publie le rapport. Dans le service Power BI, sur le dataset, va dans Sécurité et ajoute tous les utilisateurs sous le rôle “RLS_Dynamique”.
(Même si tu ajoutes tous, chacun ne verra que ses propres données grâce à la condition DAX.)

Test final
Simule le rôle pour différents emails pour vérifier que l’utilisateur A ne voit pas les données de B.

Bonnes pratiques et pièges à éviter

Modèle en étoile (star schema)
Évite les relations complexes ou cycliques. Un bon modèle relationnel (dimensions et faits) simplifie la propagation des filtres.

Nommage et documentation des rôles
Utilise des noms explicites (ex : “RLS_RegionNord”) et commente clairement la logique dans ton modèle (via des documents ou annotations).

Ne pas surcharger les rôles avec des conditions trop lourdes
Les filtres DAX très complexes ou les calculs imbriqués ralentissent le modèle.

Toujours tester les rôles via “Voir comme”
En Desktop ou dans le service Power BI, simule les rôles pour vérifier que le comportement est correct pour divers utilisateurs.

Prévoir les nouveaux utilisateurs
Avec la RLS dynamique, tu pourras ajouter de nouveaux utilisateurs dans la table Utilisateurs sans re-publier le PBIX.

Sécurité complémentaire
RLS ne remplace pas d’autres niveaux de sécurité. Vérifie que seuls les rôles appropriés peuvent accéder au dataset ou aux rapports, et revoie les permissions d’espace de travail.

Surveillance de la performance
Sur de grands jeux de données, la RLS peut ajouter une surcharge. Surveille les temps de réponse, optimise les index, la modélisation et évite les requêtes DAX coûteuses.

Pour conclure

La RLS est une fonctionnalité cruciale pour garantir que les utilisateurs voient seulement les données auxquelles ils ont droit, sans devoir dupliquer des rapports.

La RLS statique est simple à mettre en place mais peu scalable ; la RLS dynamique est plus puissante et flexible, adaptée aux organisations avec de nombreux utilisateurs.

Bien concevoir votre modèle de données, maîtriser les fonctions DAX (USERPRINCIPALNAME(), et tester rigoureusement sont les clés du succès.

Avec de bonnes pratiques et anticipation, la RLS devient un pilier de la gouvernance des données sur Power BI.