Un même rapport de ventes ne doit pas montrer la même chose à tout le monde. Le directeur régional du Nord ne devrait voir que sa région ; un commercial, que ses propres clients ; la direction générale, l’ensemble. Recopier le rapport autant de fois qu’il y a de périmètres serait ingérable. La sécurité au niveau des lignes — row-level security, ou RLS — résout ce problème à la racine : un seul rapport, mais des données filtrées automatiquement selon l’identité de la personne connectée. Ce tutoriel construit cette mécanique pas à pas, du cas le plus simple au plus dynamique.
Ce tutoriel fait partie d’une série sur Power BI et Microsoft Fabric ; le guide de référence Power BI et Microsoft Fabric en donne la vue d’ensemble. Il s’appuie sur la maîtrise des expressions DAX et d’un modèle en étoile bien relié, car la RLS repose entièrement sur la propagation du filtrage à travers les relations.
Prérequis
- Power BI Desktop avec un modèle en étoile fonctionnel (faits + dimensions reliées).
- Un compte Power BI pour la phase de publication et d’affectation des membres.
- Niveau : intermédiaire. Des notions de DAX et de relations sont nécessaires.
- Temps estimé : 60 à 80 minutes.
Étape 1 — Comprendre les deux formes de RLS
Avant de cliquer, il faut saisir la distinction qui structure tout le sujet. La RLS statique définit des rôles figés : un rôle « Nord » qui ne voit que la région Nord, un rôle « Sud » pour le Sud, etc. Simple à mettre en place, elle convient quand les périmètres sont peu nombreux et stables. La RLS dynamique, elle, n’utilise qu’un seul rôle dont le filtre s’adapte automatiquement à l’utilisateur connecté, grâce à son adresse de connexion. Elle est indispensable dès que les périmètres sont nombreux ou changent souvent.
Le principe commun aux deux est le même : un rôle porte un filtre écrit en DAX, appliqué à une table. Ce filtre réduit les lignes visibles, et grâce aux relations du modèle, cette réduction se propage à toutes les tables liées. Filtrer la dimension Région suffit donc à filtrer mécaniquement les ventes correspondantes. C’est toute la beauté d’un modèle en étoile bien conçu : la sécurité hérite de la structure.
Étape 2 — Créer un rôle statique
Commençons par le cas le plus pédagogique : un rôle qui ne montre qu’une région. Dans Power BI Desktop, ouvrez l’onglet Modélisation du ruban, puis cliquez sur Gérer les rôles. Une fenêtre s’ouvre, listant les rôles (vide au départ). Cliquez sur Créer et nommez le rôle, par exemple Region_Nord.
Le nom du rôle est purement descriptif : c’est une étiquette à laquelle vous rattacherez plus tard des personnes. À ce stade, le rôle existe mais ne filtre encore rien. L’étape suivante consiste à lui donner sa règle. Gardez à l’esprit qu’un utilisateur sans aucun rôle assigné ne verra aucune donnée du rapport publié : la RLS est restrictive par nature, ce qui est exactement le comportement de sécurité souhaité.
Étape 3 — Écrire le filtre DAX du rôle
Le cœur de la RLS est une expression DAX qui renvoie vrai ou faux pour chaque ligne de la table ciblée. Seules les lignes pour lesquelles l’expression est vraie restent visibles. Sur la table dimension Région, sélectionnez-la dans la fenêtre des rôles et saisissez le filtre :
[Region] = "Nord"Cette règle, attachée au rôle Region_Nord, signifie : « ne garder que les lignes où la colonne Région vaut Nord ». Comme la dimension Région est reliée à la table de faits, les ventes des autres régions disparaissent automatiquement pour les membres de ce rôle. Vous pouvez utiliser des expressions plus riches : appartenance à une liste avec l’opérateur IN, combinaisons de conditions avec && et ||. L’important est que le filtre porte sur la dimension, jamais sur la table de faits directement, afin de profiter de la propagation par les relations.
Étape 4 — Tester le rôle avant publication
Ne publiez jamais une RLS sans l’avoir testée localement : une règle trop permissive expose des données, une règle trop restrictive masque tout. Power BI Desktop offre un mode de simulation très pratique. Toujours dans l’onglet Modélisation, cliquez sur Afficher en tant que, cochez le rôle Region_Nord et validez.
Le rapport se recharge alors comme si vous étiez un membre de ce rôle : tous les visuels ne montrent plus que les données du Nord, et une bannière en haut indique le rôle simulé. Parcourez les pages, vérifiez les totaux : ils doivent refléter le périmètre attendu. Pour revenir à la vue complète, cliquez sur Arrêter l’affichage. Ce test, mené pour chaque rôle, est votre garantie qu’aucune fuite de données ne se produira en production.
Étape 5 — Publier et affecter les membres dans le service
La définition des rôles vit dans le fichier, mais l’affectation des personnes se fait en ligne, car c’est le service qui connaît les comptes des utilisateurs. Publiez votre rapport, puis rendez-vous dans le service Power BI. Sur le jeu de données, ouvrez le menu contextuel et choisissez Sécurité.
Vous y voyez la liste de vos rôles. Pour chacun, ajoutez les adresses des personnes ou des groupes de sécurité concernés, puis enregistrez. À partir de cet instant, quand un membre du rôle Region_Nord ouvre le rapport, il ne voit que le Nord, sans aucune manipulation de sa part. Important : les administrateurs et le propriétaire du jeu de données ne sont pas soumis à la RLS par défaut — pensez à tester avec un compte réellement restreint, ou via l’option « Tester en tant que rôle » disponible sur cette même page de sécurité.
Étape 6 — Passer à la RLS dynamique
Créer un rôle par région devient vite ingérable au-delà de quelques périmètres. La RLS dynamique élimine cette multiplication : un seul rôle, dont le filtre se réfère à l’identité de l’utilisateur connecté. La fonction clé est USERPRINCIPALNAME, qui renvoie l’adresse de connexion (généralement l’e-mail professionnel) de la personne qui consulte le rapport.
[Commercial] = USERPRINCIPALNAME()Attaché à un rôle unique appliqué à la dimension Commercial, ce filtre ne laisse voir à chacun que les lignes où la colonne Commercial correspond à sa propre adresse. Un seul rôle sert ainsi des centaines de personnes, chacune voyant son propre périmètre. La condition de réussite est que la colonne du modèle contienne exactement les mêmes adresses que celles des comptes du service ; le moindre écart de casse ou de domaine fait qu’un utilisateur ne voit rien.
Étape 7 — Gérer des périmètres complexes avec une table de mapping
Que faire quand une personne supervise plusieurs régions, ou quand le découpage ne suit pas une colonne unique ? On introduit alors une table de mapping de sécurité : une table dédiée qui associe chaque adresse e-mail aux périmètres qu’elle a le droit de voir. Cette table se relie à la dimension concernée, et le filtre dynamique s’applique sur elle.
Concrètement, vous créez une table « Securite » avec deux colonnes — l’adresse de l’utilisateur et la région autorisée — puis vous la reliez à la dimension Région. Le rôle porte alors le filtre :
[Email] = USERPRINCIPALNAME()appliqué à la table « Securite ». Le filtrage de cette table se propage à la dimension Région via la relation, puis aux ventes. Une même personne associée à trois régions verra les trois, sans créer trois rôles. Cette approche, plus élaborée, est la norme dans les déploiements sérieux : elle externalise la logique de droits dans des données, qu’on peut mettre à jour sans toucher au rapport. Pour que la propagation fonctionne, le sens du filtre de la relation entre la table de sécurité et la dimension doit être correctement orienté — un point à vérifier dans la vue Modèle.
Étape 8 — Vérifier la propagation à travers le modèle
La RLS ne filtre directement qu’une table ; tout le reste dépend des relations. Il est donc essentiel de confirmer que le filtrage atteint bien la table de faits et toutes les tables censées être restreintes. Reprenez le mode Afficher en tant que, mais cette fois en simulant aussi un utilisateur précis grâce à l’option qui combine rôle et nom d’utilisateur.
Saisissez une adresse réelle de votre table de mapping et observez : chaque visuel doit se restreindre au périmètre de cette personne. Portez une attention particulière aux tables qui ne sont pas directement reliées à la dimension filtrée — elles pourraient rester visibles en totalité, ce qui constituerait une fuite. Si une table échappe au filtre, c’est qu’une relation manque ou que son sens de propagation est inadéquat. Ce contrôle systématique, table par table, est la dernière barrière avant de confier le rapport à ses destinataires.
RLS et performance : garder les filtres légers
La sécurité au niveau des lignes n’est pas gratuite en performance : à chaque requête, le moteur applique d’abord les filtres de rôle avant de calculer les visuels. Sur un gros modèle consulté par de nombreux utilisateurs, des règles mal conçues peuvent ralentir sensiblement l’expérience. Quelques principes permettent de garder un rapport rapide tout en restant sécurisé.
D’abord, filtrez toujours une dimension de petite taille plutôt que la table de faits : un filtre sur une table de quelques centaines de régions s’évalue instantanément, là où un filtre sur des millions de lignes de ventes pèse lourd. Ensuite, privilégiez des conditions simples, basées sur une égalité ou une appartenance, et évitez d’imbriquer des fonctions DAX coûteuses dans la règle de rôle. Enfin, méfiez-vous des relations bidirectionnelles combinées à la RLS : elles peuvent créer des chemins de propagation ambigus et dégrader fortement les temps de réponse. Quand un besoin transversal l’impose, testez l’impact avec l’analyseur de performances de Power BI Desktop, qui chronomètre chaque requête. Une RLS bien pensée filtre tôt, sur des tables courtes, avec des expressions limpides — c’est le meilleur compromis entre confidentialité et fluidité, un thème approfondi dans le tutoriel sur l’optimisation des performances.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| L’utilisateur ne voit aucune donnée | Aucun rôle assigné, ou adresse non reconnue | Affecter le rôle dans le service, vérifier l’adresse exacte |
| L’utilisateur voit tout malgré la RLS | Compte administrateur du jeu de données | Tester avec un compte restreint ou « Tester en tant que rôle » |
| RLS dynamique sans effet | Casse ou domaine différent de l’adresse | Aligner la colonne sur l’UPN exact des comptes |
| Une table reste entièrement visible | Relation manquante vers la table filtrée | Créer la relation et vérifier son sens de filtre |
| Périmètres multiples impossibles | Filtre par égalité simple | Utiliser une table de mapping reliée à la dimension |
| Fuite découverte après publication | Absence de test « Afficher en tant que » | Simuler chaque rôle et chaque utilisateur avant publication |
Tutoriels liés
- Modéliser en schéma en étoile — la RLS dépend entièrement de la qualité des relations.
- Maîtriser DAX — pour écrire des filtres de rôle plus expressifs.
- Publier et partager dans le service Power BI — où s’affectent les membres des rôles.
Références
- Documentation « Sécurité au niveau des lignes (RLS) avec Power BI » (Microsoft Learn).
- Référence DAX : fonction USERPRINCIPALNAME et opérateurs logiques.
- Guide « Restreindre l’accès aux données avec des rôles dynamiques ».
Questions fréquentes
La RLS protège-t-elle aussi les données à l’exportation ?
Oui. Les filtres de rôle s’appliquent à toutes les requêtes du jeu de données, y compris lors d’un export ou d’une analyse dans Excel via une connexion live. Un utilisateur ne peut pas extraire ce qu’il n’a pas le droit de voir.
Faut-il choisir entre RLS statique et dynamique ?
Les deux peuvent coexister dans un même modèle. On utilise souvent la statique pour quelques rôles transverses (direction, audit) et la dynamique pour le gros des utilisateurs opérationnels.
La RLS masque-t-elle des colonnes entières ?
Non : la RLS filtre des lignes. Pour masquer des colonnes ou des tables selon le profil, on utilise la sécurité au niveau des objets, un mécanisme distinct et complémentaire.
Que se passe-t-il si l’adresse d’un utilisateur change ?
En RLS dynamique avec table de mapping, il suffit de mettre à jour la table de sécurité : aucune modification du rapport n’est nécessaire, ce qui rend la maintenance bien plus légère.