Quels sont les outils de gestion des droits d’accès dans Power BI ?

Vous publiez un rapport Power BI, et soudain la question qui fâche arrive : qui a le droit de voir quoi ? Un commercial ne doit pas consulter les marges de toute l'entreprise, un partenaire externe ne doit accéder qu'à ses propres chiffres, et la direction veut tout voir. Power BI ne propose pas un seul interrupteur magique, mais une pile de mécanismes complémentaires qui, bien empilés, couvrent tous les cas de figure.

Voici l'essentiel à comprendre tout de suite : la sécurité dans Power BI se joue sur trois niveaux distincts. Les rôles d'espace de travail décident qui peut éditer ou seulement consulter. Les autorisations sur le modèle sémantique et le partage gèrent l'accès aux données publiées. Et la sécurité au niveau des lignes (RLS) filtre, à l'intérieur d'un même rapport, les données que chaque personne aperçoit. Le tout repose sur l'identité Microsoft Entra ID (l'ancien Azure Active Directory).

Ce guide passe en revue chaque outil, dans quel ordre les combiner, et les pièges qui font fuiter des données sans qu'on s'en aperçoive.

Comprendre les trois niveaux de sécurité

Avant de toucher au moindre paramètre, il faut visualiser l'empilement. Une donnée traverse plusieurs portes avant d'atteindre l'œil de l'utilisateur, et chaque porte a sa propre serrure.

• Le contenant (l'espace de travail) : il regroupe rapports, tableaux de bord et modèles. Les rôles d'espace de travail définissent ce qu'on peut faire avec ce contenant — créer, modifier, supprimer ou simplement regarder.
• L'objet publié (le rapport, le modèle sémantique) : on peut le partager individuellement ou via une « app », sans donner accès à l'espace de travail entier. C'est le niveau du partage.
• La donnée elle-même (les lignes du tableau) : c'est là qu'intervient la RLS, qui découpe un même jeu de données selon l'identité de chacun.

Confondre ces niveaux est l'erreur classique. Donner un rôle « Viewer » ne suffit pas si le rapport contient les chiffres de tous les services : il faut aussi de la RLS. À l'inverse, une RLS impeccable ne sert à rien si la personne a un rôle « Membre » qui lui permet de modifier le modèle et de désactiver les filtres.

Les rôles d'espace de travail

L'espace de travail (workspace) est l'unité de collaboration de base. Power BI y propose quatre rôles, du plus restreint au plus puissant. Chacun hérite des droits du précédent et y ajoute les siens.

Rôle	Peut consulter	Peut créer / modifier le contenu	Peut publier des apps	Peut gérer les accès et supprimer
Viewer	Oui	Non	Non	Non
Contributor	Oui	Oui	Non	Non
Member	Oui	Oui	Oui	Partiellement (ajoute des membres de niveau égal ou inférieur)
Admin	Oui	Oui	Oui	Oui (contrôle total)

La règle d'or tient en une phrase : attribuez le rôle le plus bas qui permet de faire le travail. Un consommateur de rapports n'a besoin que de « Viewer ». Un analyste qui construit les visuels prend « Contributor ». Le rôle « Admin » se réserve à une poignée de personnes responsables de la gouvernance.

À retenir : point crucial souvent négligé, un « Viewer » d'espace de travail voit tout de même toutes les données du rapport, sans filtrage. Le rôle ne masque rien à l'intérieur des visuels. Pour qu'un Viewer ne voie qu'une partie des lignes, la RLS est indispensable.

Partage et autorisations sur le modèle sémantique

Tout le monde ne doit pas être membre de l'espace de travail. Pour diffuser largement un rapport sans donner les clés du contenant, deux approches existent.

Le partage direct

On partage un rapport ou un tableau de bord avec une personne précise. C'est rapide, mais cela devient vite ingérable à grande échelle : multiplier les partages individuels rend impossible de savoir qui voit quoi six mois plus tard. À réserver aux échanges ponctuels.

Les apps Power BI

L'app est la méthode recommandée pour une diffusion massive. Vous regroupez un ensemble cohérent de rapports, vous définissez une audience, et les destinataires reçoivent une expérience propre en lecture seule. On peut créer plusieurs audiences au sein d'une même app : par exemple une audience « Direction » qui voit tout, et une audience « Terrain » qui ne voit que deux pages. C'est l'équivalent d'un canal de publication maîtrisé.

Les autorisations sur le modèle sémantique

Le modèle sémantique (le jeu de données partagé) a ses propres permissions, distinctes du rapport. Trois en particulier méritent l'attention :

• Build : autorise une personne à créer ses propres rapports à partir de votre modèle. Pratique pour démocratiser l'analyse, mais à n'accorder qu'aux profils de confiance, car cela ouvre l'accès aux données sous-jacentes.
• Reshare : permet de repartager le contenu à d'autres. À limiter pour garder la maîtrise de la diffusion.
• Read : le socle, nécessaire pour consulter.

Comprendre comment vos tables et relations sont organisées aide à savoir ce que « Build » expose réellement. Si vous débutez sur ce terrain, ce panorama de la structure du modèle de données dans Power BI éclaire pourquoi un accès au modèle est plus sensible qu'un accès au seul rapport.

La sécurité au niveau des lignes (RLS)

C'est l'outil le plus puissant et le plus mal compris. La RLS filtre les lignes d'un tableau selon l'identité de la personne connectée. Un même rapport montre alors des chiffres différents à chacun, sans qu'on ait à dupliquer quoi que ce soit.

La RLS statique

Vous créez des rôles dans Power BI Desktop, chacun assorti d'un filtre DAX. Par exemple, un rôle « Région Nord » applique un filtre du type la colonne Région égale « Nord ». Vous publiez le modèle, puis vous assignez les bons utilisateurs ou groupes à chaque rôle dans le service Power BI. Simple à comprendre, mais le nombre de rôles explose dès qu'il y a beaucoup de cas.

La RLS dynamique

Plus élégante : un seul rôle, dont le filtre s'appuie sur l'identité de la personne connectée, récupérée par la fonction DAX USERPRINCIPALNAME(). On maintient à côté une table de correspondance « utilisateur → périmètre autorisé » (par exemple un commercial associé à ses comptes clients). Ajouter un utilisateur revient alors à ajouter une ligne dans cette table, sans toucher au modèle. C'est la voie à privilégier dès que les périmètres deviennent nombreux ou changeants.

Le piège à connaître : la RLS s'applique aux Viewers, pas aux éditeurs. Une personne avec un rôle d'espace de travail Contributor, Member ou Admin, ou disposant de l'autorisation Build/Write sur le modèle, contourne la RLS. Si vous voulez tester réellement ce que verra un utilisateur final, utilisez la fonction « Voir en tant que rôle » (View as) dans le service. Ne testez jamais avec votre propre compte administrateur : vous verriez tout, et conclueriez à tort que la sécurité fonctionne.

L'identité, socle de tout : Microsoft Entra ID

Aucun de ces outils ne fonctionne sans une gestion d'identité propre. Power BI s'appuie sur Microsoft Entra ID (ex-Azure Active Directory) pour authentifier chaque personne. Deux bonnes pratiques en découlent.

• Assignez des groupes, pas des individus. Plutôt que d'ajouter dix personnes une à une à un rôle RLS ou à un espace de travail, créez un groupe de sécurité Entra ID et assignez le groupe. Quand quelqu'un arrive ou part, on met à jour le groupe, et tous les accès Power BI suivent automatiquement. On évite ainsi les accès orphelins, plaie de la gouvernance.
• Soignez les invités externes (B2B). Partager avec un partenaire hors de l'organisation passe par l'invitation d'un compte invité dans Entra ID. C'est puissant, mais cela mérite une politique claire : qui peut inviter, et combien de temps l'accès reste-t-il valide.

Audit et suivi des accès

Donner les bons droits ne suffit pas : il faut pouvoir vérifier, après coup, qui a accédé à quoi. Power BI et l'écosystème Microsoft 365 fournissent plusieurs leviers de traçabilité.

• Le journal d'activité (Activity Log) et le journal d'audit unifié de Microsoft Purview enregistrent les actions : consultations, partages, exports, modifications de permissions. C'est la source de vérité pour une enquête de conformité.
• Le portail d'administration permet à l'administrateur de fixer des règles globales (tenant settings) : autoriser ou non l'export de données, le partage externe, la publication sur le web, etc.
• La page « Gérer les autorisations » de chaque rapport ou modèle offre une vue rapide des personnes ayant accès, utile pour une revue régulière.

L'idée n'est pas de tout consulter en permanence, mais de pouvoir reconstituer une chaîne d'accès le jour où une question se pose. La capacité d'audit est, en soi, un outil de dissuasion.

Combiner les outils : une stratégie en couches

Pris isolément, chaque mécanisme a des trous. Ensemble, ils forment une défense solide. Voici une trame de mise en place, dans l'ordre.

1. Structurez vos espaces de travail par périmètre métier (un par direction, ou par projet), plutôt qu'un fourre-tout unique.
2. Attribuez les rôles d'espace de travail au plus juste, en réservant Admin et Member à quelques personnes.
3. Diffusez via des apps avec audiences, pas par partages individuels en cascade.
4. Appliquez la RLS (dynamique de préférence) dès qu'un même rapport mélange des données qui ne concernent pas tout le monde.
5. Pilotez les accès par groupes Entra ID, jamais personne par personne.
6. Programmez une revue périodique des droits, par exemple chaque trimestre, et exploitez les journaux d'audit pour repérer les anomalies.

Cette discipline d'attribution prudente rappelle, dans un autre registre, la rigueur nécessaire pour sécuriser et récupérer l'accès à un compte personnel : moins on disperse les clés, plus on garde la main. Et si plusieurs services se renvoient la responsabilité de la gouvernance des accès, la mettre à plat lors d'une table ronde dédiée à la gestion stratégique évite bien des zones grises.

Les erreurs qui font fuiter des données

• Tester la RLS avec un compte admin : vous voyez tout et concluez à tort que c'est sécurisé. Utilisez toujours « Voir en tant que rôle ».
• Donner « Build » trop largement : cela ouvre l'accès aux données brutes du modèle, bien au-delà du rapport visible.
• Multiplier les partages individuels : impossible à auditer ensuite. Préférez les apps et les groupes.
• Oublier les exports : la RLS protège l'affichage, mais si l'export Excel ou la connexion en direct est autorisé, un utilisateur avec les bons droits peut extraire des données. Verrouillez les paramètres du locataire.
• Ne jamais réviser les droits : les accès s'accumulent au fil des départs et des changements de poste. Sans revue régulière, le périmètre dérive.

Questions fréquentes

Quelle différence entre les rôles d'espace de travail et la RLS ?

Les rôles d'espace de travail définissent ce qu'une personne peut faire (consulter, éditer, administrer). La RLS définit quelles lignes de données elle voit à l'intérieur d'un rapport. Les deux sont complémentaires : un Viewer voit tout le rapport sauf si une RLS filtre ses données.

La RLS s'applique-t-elle à tout le monde ?

Non. Elle s'applique aux personnes en lecture seule (rôle Viewer, accès via app ou partage). Les éditeurs — Contributor, Member, Admin, ou détenteurs de l'autorisation Build/Write — la contournent par conception. C'est voulu : ils ont besoin de voir toutes les données pour travailler sur le modèle.

RLS statique ou dynamique : laquelle choisir ?

La statique convient aux cas simples et peu nombreux (quelques régions fixes). La dynamique, basée sur USERPRINCIPALNAME() et une table de correspondance, devient indispensable dès que les périmètres sont nombreux ou évoluent souvent, car elle évite de multiplier les rôles.

Peut-on partager un rapport avec quelqu'un sans licence Power BI Pro ?

Cela dépend de la configuration. Le partage standard requiert généralement une licence côté destinataire, sauf si le contenu est hébergé en capacité Premium ou Fabric, qui permet une diffusion plus large. Vérifiez le mode de licence de votre organisation avant de promettre un accès gratuit.

Comment donner accès à un partenaire externe ?

En l'invitant comme utilisateur invité (B2B) dans Microsoft Entra ID, puis en l'ajoutant à l'audience ou au rôle voulu. Encadrez cette pratique par une politique claire et, idéalement, une RLS pour qu'il ne voie que son propre périmètre.

Comment savoir qui a accès à un rapport ?

Via la page « Gérer les autorisations » de l'objet pour une vue immédiate, et via le journal d'activité ou l'audit Microsoft Purview pour l'historique détaillé des accès et des actions.

En résumé

Il n'existe pas un outil unique de gestion des droits dans Power BI, mais une pile cohérente : les rôles d'espace de travail pour les capacités, le partage et les apps pour la diffusion, la RLS pour le filtrage fin des données, le tout ancré sur l'identité Entra ID et surveillé par l'audit. La meilleure stratégie est celle des couches : structurez vos espaces, attribuez au plus juste, diffusez par apps et groupes, filtrez par RLS dynamique, et révisez régulièrement. Commencez par le principe du moindre privilège — c'est la décision qui vous épargnera le plus de mauvaises surprises.