La Row-Level Security (RLS) dans Power BI permet de cloisonner l'accès aux données par filiale en appliquant des filtres dynamiques basés sur l'identité de l'utilisateur (adresse e-mail). Grâce à la fonction DAX USERPRINCIPALNAME() et à une table de correspondance utilisateurs-filiales, un unique rapport Power BI affiche uniquement les données autorisées pour chaque collaborateur, éliminant ainsi le besoin de dupliquer les fichiers.
- La Row-Level Security évite la duplication fastidieuse des fichiers Power BI pour chaque filiale.
- La sécurité dynamique via USERPRINCIPALNAME() s'adapte automatiquement aux mouvements de personnel.
- Une modélisation en étoile est indispensable pour éviter que la RLS ne dégrade les performances des rapports.
- L'outil 'Afficher comme' de Power BI permet de tester rigoureusement l'étanchéité des données avant publication.
Le rapport qui en montrait beaucoup trop
Imaginez la scène au siège d'un grand groupe de distribution ou de promotion immobilière à Casablanca. Le directeur général réunit les responsables de chaque filiale pour analyser les performances du trimestre. Sur le grand écran de la salle de réunion, un magnifique tableau de bord Power BI affiche les marges consolidées, mais aussi le détail ultra-confidentiel de chaque entité. En un coup d'œil, le directeur de la filiale Nord découvre les marges nettes de son homologue du Sud, tandis que le responsable de la filiale logistique accède aux données d'achat stratégiques de la branche distribution. Ce manque d'étanchéité crée des tensions immédiates et pose un problème majeur de gouvernance des données au sein de l'entreprise.
Pour pallier cette faille de confidentialité, la réaction classique des équipes informatiques consiste à dupliquer le rapport Power BI en autant de versions qu'il y a de filiales. On se retrouve alors avec un rapport pour la filiale A, un autre pour la filiale B, et un troisième pour la filiale C. Cette approche artisanale se transforme rapidement en cauchemar de maintenance. À la moindre modification d'un indicateur de performance ou d'un visuel, le développeur BI doit répercuter la modification sur l'ensemble des fichiers. Les risques d'erreurs se multiplient, l'espace de stockage s'encombre et la version unique de la vérité s'effondre. C'est précisément pour résoudre ce dilemme qu'intervient la Row Level Security Power BI.
Ce que fait vraiment la Row-Level Security
La Row Level Security Power BI, ou sécurité au niveau des lignes, est une fonctionnalité native qui permet de filtrer les données d'un modèle en fonction de l'identité de l'utilisateur connecté. Plutôt que de multiplier les rapports, vous conservez un seul et unique fichier de rapport connecté à un unique jeu de données. Lorsque le directeur de la filiale de Tanger ouvre le rapport, Power BI intercepte sa connexion, identifie son adresse e-mail professionnelle et applique instantanément un filtre invisible sur les tables de données. L'utilisateur ne voit que les lignes qui le concernent directement, comme si les données des autres filiales n'avaient jamais existé dans le modèle.
Cette technologie assure une sécurité des rapports BI rigoureuse et transparente. Elle repose sur deux concepts fondamentaux que sont les rôles et les règles de filtrage. Les rôles définissent des profils d'accès, par exemple Directeur Filiale Centre ou Responsable Commercial Ouest. Les règles, quant à elles, utilisent le langage DAX pour restreindre l'accès aux données. Par exemple, une formule DAX simple va forcer la colonne Code Filiale à correspondre uniquement à la valeur autorisée pour l'utilisateur. Le traitement s'effectue côté serveur dans le service Power BI, ce qui garantit qu'aucune donnée non autorisée ne transite sur le réseau ou ne puisse être récupérée par un utilisateur curieux via des options d'exportation.
Modéliser les rôles avant d'écrire le moindre filtre
Avant de vous lancer dans l'écriture de formules DAX complexes dans Power BI Desktop, une phase de modélisation conceptuelle est indispensable. Pour un groupe multi-filiales marocain, la sécurité ne doit pas être codée en dur dans le rapport sous peine de devenir ingérable à la première réorganisation ou au premier recrutement. Si vous créez manuellement un rôle pour chaque collaborateur, vous passerez vos journées à mettre à jour votre fichier Power BI. La bonne pratique consiste à mettre en place une sécurité dynamique basée sur une table de correspondance des utilisateurs et de leurs périmètres d'accès.
Cette table d'affectation, souvent appelée table de sécurité, associe l'identifiant de l'utilisateur à son code de filiale. Dans votre modèle de données, cette table sera liée à votre table de faits principale avec une direction de filtrage bidirectionnelle et l'option de filtrage de sécurité activée. En utilisant la fonction DAX USERPRINCIPALNAME, Power BI récupère dynamiquement l'adresse e-mail de la personne connectée et filtre la table de sécurité, qui à son tour propage le filtre sur l'ensemble du modèle de données. C'est cette approche moderne que nous recommandons chez Data Scale Business pour des structures complexes comme Chaabane Immobilier ou Super Auto Distribution, garantissant une évolutivité parfaite sans aucune intervention technique lors des mouvements de personnel.
Les pièges de performance à connaître
La mise en œuvre de la Row Level Security Power BI n'est pas sans impact sur les performances de vos rapports. Lorsque vous activez la sécurité au niveau des lignes, le moteur VertiPaq de Power BI ne peut plus utiliser pleinement ses algorithmes de mise en cache globale, car chaque utilisateur possède désormais sa propre vue personnalisée des données. Chaque visuel du rapport génère des requêtes spécifiques qui intègrent les filtres de sécurité. Si votre modèle de données est mal conçu, le temps de chargement des pages peut considérablement augmenter, frustrant les décideurs habitués à une navigation instantanée.
Le principal piège réside dans l'utilisation de relations bidirectionnelles complexes ou de schémas en flocon désorganisés. Pour maintenir une excellente réactivité, vous devez privilégier un schéma en étoile propre où les filtres de sécurité s'appliquent sur les tables de dimensions, comme la dimension Filiale ou Géographie, et se propagent naturellement vers la table de faits des ventes ou des dépenses. Évitez absolument d'appliquer des filtres RLS complexes directement sur des tables de faits contenant des dizaines de millions de lignes. De plus, limitez l'usage de fonctions DAX lourdes ou non optimisées au sein de vos expressions de sécurité, car elles seront évaluées pour chaque ligne et chaque utilisateur.
Tester et auditer les accès dans la durée
Une fois votre stratégie de sécurité configurée, la phase de validation est cruciale pour éviter toute fuite d'informations sensibles. Power BI Desktop propose un outil formidable baptisé Afficher comme qui permet de simuler la connexion de n'importe quel utilisateur du groupe. Vous pouvez ainsi vous glisser dans la peau du directeur de la filiale de Marrakech et vérifier visuellement que seuls ses indicateurs s'affichent à l'écran. Cette vérification doit être systématique avant chaque publication du jeu de données sur le service en ligne.
Au-delà des tests initiaux, la gouvernance de la sécurité des rapports BI s'envisage sur le long terme. Les organisations évoluent, de nouvelles filiales se créent et les collaborateurs changent de poste. Il est indispensable de planifier des audits réguliers des accès aux données par filiale. En tant que cabinet de conseil expert, Data Scale Business accompagne les DSI et directions métiers dans la mise en place de processus d'audit automatisés, permettant de valider en continu que les rôles Power BI affectés dans l'administration correspondent parfaitement aux habilitations réelles de l'entreprise. Une gouvernance maîtrisée est la clé pour transformer vos données en un actif stratégique totalement sécurisé.



