Implémenter la sécurité au niveau des lignes dans Power BI

La sécurité au niveau des lignes, ou RLS (Row-Level Security), fait en sorte que chaque personne ne voie dans un même rapport Power BI que les données qui la concernent. Un responsable d’agence voit son agence, la direction voit tout, et il n’existe qu’un seul rapport à maintenir. Dans une entreprise, elle évite de multiplier les versions d’un fichier et réduit le risque de montrer à quelqu’un des chiffres qui ne lui sont pas destinés.

À quoi sert la sécurité au niveau des lignes

Prenons une situation type : un réseau de vingt agences suit ses ventes dans Power BI. Sans RLS, deux solutions peu satisfaisantes s’offrent à vous : un rapport commun où chacun voit les résultats de ses voisins, ou vingt copies à tenir à jour et à corriger une par une. Avec la RLS, vous publiez un seul rapport. Quand un responsable l’ouvre, Power BI reconnaît son compte et ne lui montre que les lignes de son agence. Totaux, graphiques et classements se calculent sur ce périmètre.

La même logique sert ailleurs : les RH qui ne veulent montrer à un manager que les effectifs de son équipe, un commercial limité à son portefeuille, une filiale qui ne doit pas voir les marges d’une autre. Elle contribue aussi à la maîtrise des accès aux données personnelles attendue par le RGPD, sans suffire à elle seule à s’y conformer.

Ce que la RLS protège, et ce qu’elle ne protège pas

C’est le point le plus mal compris. Une erreur ici donne une impression de sécurité sans la réalité.

Retenez la conséquence pratique : pour qu’une règle s’applique à quelqu’un dans un espace de travail, cette personne doit être Lecteur. Un filtre de rapport ou de page n’est pas non plus une protection : notre article sur les filtres de Power BI montre à quoi ils servent, à savoir la lecture et non la sécurité. La documentation de Microsoft sur la RLS reprend ces points en détail.

Créer un rôle dans Power BI Desktop

Un rôle est un groupe de personnes associé à une règle de filtrage. La règle est une expression DAX, le langage de calcul de Power BI, qui répond vrai ou faux pour chaque ligne : seules les lignes vraies restent visibles.

1. Dans l’onglet Modélisation, sélectionnez Gérer les rôles.
2. Sélectionnez Nouveau, puis donnez un nom au rôle. Évitez les virgules, refusées dans ce nom.
3. Sous Sélectionner des tables, choisissez la table à filtrer.
4. Sous Filtrer les données, définissez la règle avec l’éditeur par défaut, ou sélectionnez Basculer vers l’éditeur DAX. Les règles dynamiques exigent cet éditeur.
5. Cliquez sur Enregistrer.

Voici la règle la plus simple, dite statique, posée sur une table Regions :

Regions[Region] = "Nord"

Toutes les ventes liées à une autre région disparaissent pour ce rôle, grâce à la relation entre les tables. Ailleurs dans Power BI, le séparateur des formules peut devenir le point-virgule (;) selon la langue ou les réglages régionaux. Dans cette zone d’expression, Microsoft demande au contraire d’utiliser la virgule, même avec des réglages français.

Une règle statique convient à une organisation stable avec peu de périmètres. Pour la direction, créez un rôle sans aucune règle : il voit toutes les données. Vous ne pouvez pas attribuer de personnes à un rôle dans Power BI Desktop : cela se fait après la publication.

La sécurité dynamique : une seule règle pour tout le monde

Avec vingt agences, vingt rôles statiques deviendraient vite ingérables. La sécurité dynamique fait reposer la règle sur l’identité de la personne connectée. Si chaque ligne contient déjà l’adresse du responsable, une ligne suffit :

Commerciaux[Email] = USERPRINCIPALNAME()

USERPRINCIPALNAME() renvoie l’identifiant de connexion de la personne, qui ressemble à une adresse e-mail. Le plus souvent, on passe par une table de correspondance, par exemple une table Acces avec une ligne par couple personne et région. Une personne peut ainsi couvrir plusieurs régions :

Regions[Region] IN
    CALCULATETABLE(
        VALUES(Acces[Region]),
        Acces[Email] = USERPRINCIPALNAME()
    )

La formule récupère les régions de la personne connectée, puis ne garde que celles-ci. Ici, la table Acces n’a pas besoin de relation avec le reste du modèle. L’intérêt est pratique : quand une personne change de poste, on modifie la table, pas le modèle. Gardez cette table dans une source gérée, et prévoyez qui la met à jour.

La fonction USERNAME() existe aussi. Dans Power BI Desktop, elle renvoie DOMAINE\Utilisateur alors que USERPRINCIPALNAME() renvoie utilisateur@contoso.com. Dans le service en ligne, les deux renvoient le même identifiant. Pour éviter un écart entre vos essais et la production, préférez USERPRINCIPALNAME(). Si le DAX est nouveau pour vous, notre article sur les mesures DAX avancées en explique les bases, comme CALCULATETABLE et les filtres.

Tester les rôles avant de les ouvrir

Une erreur de règle peut couper l’accès à quelqu’un ou, pire, exposer des données. Testez donc à deux endroits.

• Dans Power BI Desktop : dans l’onglet Modélisation, sélectionnez Afficher en tant que, puis un ou plusieurs rôles. Le rapport s’affiche avec les filtres du rôle choisi.
• Dans le service en ligne : dans la page de sécurité du modèle, ouvrez Plus d’options à côté du rôle, puis Tester en tant que rôle. Le menu du haut permet de passer à un autre rôle, à une combinaison de rôles ou à une personne précise.

Ce test a des limites. Il ne fonctionne pas pour les modèles en DirectQuery avec authentification unique, ni pour les rapports paginés, et il ne montre que les rapports du même espace de travail. Avec une règle dynamique, Tester en tant que rôle utilise votre propre identité. Pour un utilisateur externe, le seul essai fiable reste une connexion avec son vrai compte.

Pour vérifier ce que Power BI reçoit réellement, créez une mesure de contrôle et affichez-la dans un visuel carte sur une page de test :

Identité = USERPRINCIPALNAME()

Publier et attribuer les membres

Une fois le fichier publié (voir notre guide sur la publication sur Power BI Service), ouvrez l’espace de travail :

1. Pointez le modèle sémantique, c’est-à-dire le jeu de données publié, et ouvrez le menu Autres options.
2. Sélectionnez Sécurité. Il faut être au moins Contributeur pour voir cette option.
3. Choisissez le rôle, puis saisissez l’adresse ou le nom d’une personne ou d’un groupe.

Quelques règles à connaître :

• Privilégiez les groupes. Les groupes de sécurité Microsoft Entra, les groupes à extension messagerie et les groupes de distribution sont acceptés. Les groupes Microsoft 365 ne le sont pas, ni les groupes créés dans Power BI.
• Les rôles s’additionnent. Une personne présente dans les rôles Ventes et Marketing voit les données des deux. On ne peut pas restreindre en ajoutant un rôle.
• Sans rôle, pas de données. Un lecteur qui n’appartient à aucun rôle voit en général un rapport vide.
• Les externes demandent plus d’attention. Un invité Microsoft Entra B2B peut être ajouté à un rôle, mais un groupe de sécurité contenant des invités peut ne pas fonctionner comme prévu : ajoutez-les directement par leur adresse e-mail. Son identifiant peut aussi prendre une forme en #EXT#, qui ne correspondra pas à votre table : vérifiez avec la mesure de contrôle.

Ces règles valent aussi pour la consultation sur téléphone avec Power BI Mobile, puisque la sécurité se trouve dans le modèle et non dans l’affichage.

Pièges, performances et maintenance

• Filtres dans les deux sens. Par défaut, le filtre de sécurité ne suit qu’une direction, même sur une relation bidirectionnelle. L’option Appliquer le filtre de sécurité dans les deux directions de la relation peut être nécessaire avec une table de correspondance reliée au modèle, mais elle peut ralentir les requêtes. Testez-la bien, ou évitez-la avec une formule comme celle ci-dessus.
• Règles simples, sur de petites tables. Posez les règles sur les tables de référence, comme les régions ou les équipes, plutôt que sur une grande table de ventes. Chaque règle s’ajoute aux requêtes du rapport : surveillez les temps d’affichage.
• La fonction USERELATIONSHIP. Avec la RLS active, elle peut provoquer des erreurs inattendues dans les mesures. Revoyez la formule si un visuel se met à échouer pour les seuls lecteurs filtrés.
• Applications et comptes techniques. Un principal de service, l’identité technique d’une application, ne peut pas être ajouté à un rôle. Dans une application intégrée, il faut passer l’identité de l’utilisateur par l’API de Power BI.
• Revue des accès. Une arrivée, un départ ou une réorganisation changent les périmètres. Documentez la logique de chaque rôle et revoyez les membres à intervalles réguliers.

Le bon réglage va de pair avec une mise en page claire : notre article sur la conception des tableaux de bord rappelle de ne montrer que ce qui sert à chaque profil.

Données sensibles : quand confier la mise en place à un prestataire

Quelques rôles sur une région ou une équipe, avec des données peu sensibles, se mettent très bien en place en interne en suivant cette méthode. Un prestataire ou un expert apporte un vrai filet de sécurité quand il s’agit de salaires, de données de santé ou de résultats de filiales, quand les périmètres sont imbriqués (une personne, plusieurs entités, des exceptions), quand des partenaires externes accèdent au rapport, ou quand des règles existantes ralentissent les pages. Une revue extérieure de quelques cas de test, effectuée avec de vrais comptes, vaut souvent mieux qu’une confiance aveugle dans la règle. Pour situer ce travail dans un projet plus large, voyez ce qu’un tableau de bord Power BI peut réunir pour vos équipes.

Questions fréquentes

Quelle est la différence entre USERNAME() et USERPRINCIPALNAME() ?

Dans Power BI Desktop, USERNAME() renvoie DOMAINE\Utilisateur et USERPRINCIPALNAME() un identifiant de la forme utilisateur@contoso.com. Dans le service en ligne, les deux renvoient cet identifiant, appelé UPN. Préférez USERPRINCIPALNAME(), et remplissez votre table de correspondance avec cette valeur, qui peut différer de l’adresse e-mail en cas d’alias.

Peut-on modifier les rôles après la publication ?

Oui. Les membres se gèrent directement dans le service, depuis la page Sécurité du modèle sémantique. Pour changer les règles, modifiez-les dans Power BI Desktop puis republiez, ou passez par la modification du modèle dans le service en ligne si vous y travaillez déjà.

La RLS fonctionne-t-elle avec Publier sur le web ?

Non. Un rapport qui s’appuie sur la RLS n’est pas éligible à la publication publique sur le web, et un code d’intégration existant passe à l’état « Non pris en charge ». Pour un portail interne, utilisez les options d’intégration sécurisées, qui respectent les droits de chaque personne.

Comment gérer des utilisateurs externes à l’entreprise ?

Invitez-les comme invités Microsoft Entra B2B, puis ajoutez-les directement au rôle par leur adresse e-mail, plutôt que par un groupe. Avec une règle dynamique, vérifiez ce que renvoie USERPRINCIPALNAME() pour eux, car le format peut varier selon votre configuration. Testez ensuite avec leur vrai compte.

Pourquoi un administrateur de l’espace de travail voit-il toutes les données ?

C’est normal : la RLS ne s’applique qu’au rôle Lecteur. Les rôles Administrateur, Membre et Contributeur peuvent modifier le modèle, et ne sont donc pas filtrés. Si une personne doit être filtrée, donnez-lui le rôle de lecteur seulement, et testez avec son compte.

Combien de temps faut-il pour la mettre en place ?

Le temps dépend moins de la formule que de vos règles d’accès. Une règle statique sur une colonne propre se pose vite. La vraie durée vient de la définition de qui voit quoi, de la création de la table de correspondance et des tests avec plusieurs profils réels.