Comment gérer les permissions d'accès aux rapports dans Power BI ?

Gérer les permissions d’accès aux rapports dans Power BI consiste à combiner trois niveaux : le rôle attribué dans l’espace de travail, le mode de diffusion du rapport et les droits sur le modèle sémantique qui alimente les visuels. Pour éviter les fuites de données, accordez le droit le plus limité qui permet réellement à chaque personne de travailler, puis appliquez une sécurité au niveau des lignes lorsque deux publics ne doivent pas voir les mêmes données.

La rédaction de Karène Vérifié par le comité éditorial Publié le 11 mars 2025 · Mis à jour le 3 juin 2026 10 min de lecture

Gestionnaire vérifiant les permissions d’accès aux rapports Power BI sur ordinateur. — illustration Karène

Sommaire de l’article

Distinguer le rapport, l’espace de travail et le modèle sémantique

Un rapport Power BI n’est que la couche de restitution : graphiques, filtres, pages et mesures visibles par l’utilisateur. Les données interrogées proviennent généralement d’un modèle sémantique — anciennement appelé jeu de données — publié dans Power BI Service. Donner accès au rapport sans vérifier les droits sur ce modèle est une source classique d’erreurs de consultation ou, à l’inverse, de droits trop larges.

L’espace de travail est le conteneur où les équipes créent, publient et maintiennent les contenus. Un rôle à ce niveau s’applique en principe à tous les rapports, tableaux de bord, modèles sémantiques et éléments présents dans cet espace. Il convient donc à une équipe de production homogène, mais rarement à une population métier qui ne doit consulter qu’un tableau de bord.

Le troisième niveau est celui des autorisations propres à l’élément. Vous pouvez partager un rapport précis, attribuer des permissions sur son modèle sémantique ou distribuer une application Power BI. Ces accès ciblés sont plus fins, mais leur accumulation rend les revues d’accès plus nécessaires.

Besoin de l’utilisateur	Mécanisme conseillé	Portée de l’accès	Point de vigilance
Créer et maintenir des rapports	Rôle d’espace de travail	Tous les contenus de l’espace	Réserver aux équipes de production
Consulter plusieurs rapports stabilisés	Application Power BI et audience	Contenus publiés dans l’application	Une audience n’efface pas les accès directs existants
Consulter un rapport ponctuel	Partage direct du rapport	Un rapport déterminé	Vérifier le modèle sémantique associé
Créer ses propres analyses	Permission Build sur le modèle	Données exposées par le modèle	Droit plus large qu’une simple lecture

Choisir le bon rôle dans l’espace de travail

Power BI propose habituellement quatre rôles d’espace de travail : Administrateur, Membre, Contributeur et Lecteur. Ils ne représentent pas seulement des niveaux de visualisation ; ils déterminent aussi qui peut publier, modifier, supprimer ou administrer le contenu. Les paramètres du locataire et la capacité utilisée peuvent influer sur certaines possibilités : testez toujours le scénario retenu dans un espace de travail de recette.

Administrateur : gère les accès, les paramètres et l’ensemble du contenu. Limitez ce rôle à quelques responsables capables d’assumer la gouvernance et la continuité de service.
Membre : dispose de droits étendus pour contribuer et, selon la configuration, diffuser le contenu. Il est adapté à un responsable de domaine, pas à un simple analyste consommateur.
Contributeur : crée et modifie les rapports et modèles de l’espace sans avoir à administrer tous les accès. C’est le rôle habituel des auteurs de rapports.
Lecteur : consulte et interagit avec les contenus de l’espace. Il voit néanmoins l’ensemble des éléments auxquels l’espace donne accès, ce qui peut être excessif pour un public large.

Évitez de placer tous les collaborateurs dans un espace de travail en Lecteur par facilité. Même si ce rôle ne leur permet pas de modifier les rapports, il leur révèle la liste des contenus du périmètre. Pour une direction qui ne doit voir que ses indicateurs, une application avec une audience dédiée ou un partage direct est généralement plus propre.

Les rôles élevés créent aussi un risque lors des tests de sécurité. Un Administrateur, un Membre ou un Contributeur ne constitue pas un compte de test fiable pour la sécurité au niveau des lignes : ces rôles disposent de droits qui peuvent contourner les restrictions de consultation prévues pour les lecteurs.

Structurer les accès avec des groupes plutôt qu’avec des individus

L’ajout manuel d’adresses une par une semble rapide au départ, puis devient difficile à contrôler dès qu’une équipe change de périmètre. Créez plutôt des groupes de sécurité Microsoft Entra ID alignés sur des fonctions ou des périmètres stables : BI_Ventes_Nord_Lecteurs, BI_Finance_Contributeurs ou BI_Direction_App. Attribuez ces groupes aux espaces de travail, aux audiences d’application et aux rôles de sécurité du modèle.

Cette organisation sépare les responsabilités. L’équipe BI définit les droits fonctionnels dans Power BI ; le responsable métier ou l’équipe informatique gère l’appartenance aux groupes. Lorsqu’un salarié quitte le service, sa suppression du groupe réduit ses accès partout où ce groupe est utilisé, au lieu de nécessiter une série de retraits manuels.

N’utilisez pas un groupe « Tous les salariés » pour un contenu contenant des données commerciales, financières ou RH, même si le rapport paraît anodin. Un indicateur agrégé peut révéler des informations sensibles lorsqu’il est croisé avec des filtres, des exports ou d’autres rapports. Évitez aussi les groupes imbriqués non testés : selon les services et les politiques d’identité, leur prise en charge ou leur mise à jour peut compliquer le diagnostic.

Mettre en place une matrice d’accès exploitable

Lister les publics et leurs tâches. Distinguez les auteurs, les responsables qui valident, les lecteurs réguliers et les utilisateurs qui doivent produire leurs propres analyses.
Définir un groupe par besoin stable. Un groupe doit correspondre à un droit métier clair, non à une personne ou à une demande ponctuelle.
Choisir le canal de diffusion. Espace de travail pour les producteurs, application pour une population métier, partage direct pour une exception limitée.
Affecter les permissions minimales. Commencez sans Build, sans Reshare et sans rôle élevé ; ajoutez un droit seulement s’il répond à un besoin démontré.
Consigner le propriétaire métier. Chaque groupe et chaque rapport sensible doivent avoir un responsable apte à valider les accès.

Utiliser le partage direct sans ouvrir trop de possibilités

Depuis Power BI Service, le bouton de partage permet d’accorder l’accès à un rapport à des utilisateurs ou à un groupe précis. Choisissez autant que possible une option de lien destinée à des personnes déterminées plutôt qu’un lien ouvert à toute l’organisation. L’envoi d’une URL copiée dans le navigateur ne remplace pas une autorisation : l’utilisateur doit toujours disposer des droits requis au moment de l’ouverture.

Le partage d’un rapport donne normalement au destinataire les droits de lecture nécessaires sur le modèle sémantique sous-jacent afin que les visuels puissent s’afficher. En revanche, l’option permettant aux destinataires de créer du contenu à partir des données accorde la permission Build. Ce droit autorise la création de nouveaux rapports sur le modèle et peut permettre des usages d’analyse dans Excel ou d’autres outils compatibles, selon les paramètres de l’organisation.

N’activez pas l’autorisation de repartage par défaut. Un responsable de réseau commercial qui doit lire un suivi de performance n’a pas forcément à pouvoir le rediffuser à des personnes hors de son périmètre. Si le partage est nécessaire, faites-le porter par un groupe ou une audience d’application afin de garder une piste de gouvernance simple.

Pour une diffusion récurrente auprès de plusieurs métiers, publiez une application Power BI depuis un espace de travail maîtrisé. Les audiences d’application permettent de présenter des contenus différents à plusieurs groupes sans leur donner un rôle dans l’espace de travail de production. Elles améliorent la distribution, mais ne remplacent pas les permissions sur les données : un utilisateur déjà membre de l’espace ou détenteur d’un lien direct peut conserver un autre chemin d’accès.

Protéger les données avec la sécurité au niveau des lignes

La sécurité au niveau des lignes, souvent appelée RLS, filtre les lignes retournées à chaque utilisateur. Elle répond à des cas tels qu’un directeur régional qui doit voir uniquement sa région, ou un franchisé qui ne doit consulter que ses propres points de vente. Le même rapport et le même modèle peuvent ainsi être partagés sans dupliquer un fichier par territoire.

Dans Power BI Desktop, créez un rôle dans la gestion des rôles et définissez un filtre DAX sur une table de dimension. Pour un périmètre fixe, un filtre du type [Région] = "Ouest" peut suffire. Pour une organisation réelle, le modèle le plus maintenable est souvent dynamique : une table de correspondance associe l’adresse de connexion à un territoire, puis une règle reposant sur USERPRINCIPALNAME() sélectionne les lignes autorisées.

Après publication, affectez les groupes ou les utilisateurs aux rôles dans les paramètres de sécurité du modèle sémantique dans Power BI Service. Tester la règle dans Power BI Desktop avec « Afficher en tant que » est utile, mais insuffisant : vérifiez aussi le rendu dans le service avec un compte lecteur de test. Contrôlez les cas particuliers, notamment les personnes responsables de plusieurs zones et les changements d’adresse professionnelle.

La RLS filtre les requêtes exécutées par les utilisateurs concernés, y compris lorsqu’ils explorent les données via un rapport autorisé. Elle ne protège toutefois pas les personnes ayant un rôle Administrateur, Membre ou Contributeur dans l’espace de travail : ces profils de production ne doivent donc pas appartenir à la population que vous cherchez à cloisonner.

Vérifier les permissions du modèle sémantique avant toute diffusion

Ouvrez la gestion des autorisations du modèle sémantique et examinez les droits directs comme les droits hérités d’un groupe, d’un espace de travail ou d’un lien. La permission de lecture permet de consommer le contenu ; Build ouvre la création de contenu fondé sur le modèle ; Reshare autorise, lorsqu’elle est proposée, une redistribution à d’autres personnes. Les permissions peuvent rester en place après des changements de partage si elles ont été accordées indépendamment.

Un piège fréquent consiste à supprimer l’accès au rapport, puis à oublier un droit Build donné séparément sur le modèle. La personne ne voit peut-être plus la page du rapport initial, mais peut encore créer un autre rapport si elle conserve l’accès au modèle. Inversement, retirer un droit trop largement peut faire disparaître les visuels chez un utilisateur qui dispose pourtant d’un lien valide.

Ne confondez pas l’accès au modèle Power BI avec les identifiants de la source de données. Dans la plupart des scénarios d’importation, l’utilisateur interroge le modèle publié et n’obtient pas automatiquement un compte sur la base de données source. Avec DirectQuery, l’actualisation, l’authentification unique et les passerelles peuvent introduire d’autres règles ; faites valider l’architecture par l’administrateur des données lorsque des sources sensibles sont concernées.

Les licences interviennent également dans la diffusion. En général, l’auteur doit disposer d’une licence adaptée à la publication et les lecteurs doivent avoir une licence compatible, sauf lorsque la capacité de l’organisation permet un autre mode de consommation. Les conditions varient selon Power BI Pro, Premium par utilisateur, la capacité Fabric ou Power BI et les règles du locataire : vérifiez-les avant d’annoncer l’accès à un grand public interne.

Auditer les accès et résoudre les incidents les plus courants

Planifiez une revue au moins trimestrielle pour les rapports sensibles, et à chaque réorganisation métier. Demandez au propriétaire du rapport de confirmer les groupes autorisés, les audiences d’application, les accès directs et les personnes ayant Build ou Reshare. Révoquez les accès temporaires dès la fin d’un projet plutôt que de les laisser se transformer en droits permanents.

Les journaux d’audit Microsoft 365 et les activités Power BI, lorsqu’ils sont disponibles pour votre organisation, aident à retracer les partages, consultations et exports. Ils complètent la page « Gérer les autorisations » ; cette dernière montre les droits actuels, tandis que les journaux aident à comprendre une action passée. Pour les données réglementées, associez cette revue à vos procédures internes de conservation et de contrôle des accès.

Quelques symptômes orientent rapidement le diagnostic :

Des visuels vides chez un lecteur indiquent souvent une règle RLS trop restrictive ou une correspondance utilisateur absente de la table de sécurité.
Un message d’accès insuffisant peut venir du modèle sémantique sous-jacent, même si le rapport a été partagé correctement.
Un utilisateur qui voit toutes les données lors d’un test possède peut-être un rôle élevé dans l’espace de travail, ce qui invalide le test RLS.
Un ancien collaborateur qui conserve l’accès appartient souvent à un second groupe, détient un accès direct ou utilise un lien dont l’étendue est trop large.

La séparation entre développement, recette et production réduit ces incidents. Les auteurs peuvent conserver des droits étendus dans les deux premiers environnements, tandis que la production reste limitée à quelques administrateurs et contributeurs identifiés. Avant chaque mise en ligne, testez le rapport avec un compte lecteur représentatif de chaque audience, puis documentez le résultat et le propriétaire des droits.

Questions fréquentes

On répond à vos questions

Quelle est la différence entre un rôle d’espace de travail et le partage d’un rapport Power BI ?

Un rôle d’espace de travail donne un accès à l’ensemble des contenus présents dans cet espace, avec des possibilités variables de lecture, modification ou administration. Le partage direct cible un rapport précis et convient mieux à une consultation ponctuelle ou limitée. Dans les deux cas, le modèle sémantique qui fournit les données doit aussi être accessible avec les permissions appropriées.

Un utilisateur peut-il voir un rapport Power BI sans licence Pro ?

Cela dépend du type de licence de l’auteur, de la capacité qui héberge le contenu et des règles définies par l’administrateur du locataire. Dans de nombreux cas, le partage entre utilisateurs exige une licence Power BI Pro ou Premium par utilisateur pour chaque lecteur. Certaines capacités permettent des modalités de consultation différentes. Vérifiez le scénario exact dans le portail d’administration avant le déploiement.

La sécurité au niveau des lignes fonctionne-t-elle pour les administrateurs Power BI ?

Non, elle ne doit pas être utilisée pour restreindre les Administrateurs, Membres ou Contributeurs d’un espace de travail. Ces rôles de production disposent de privilèges qui leur permettent d’accéder largement au contenu et aux données. La sécurité au niveau des lignes est conçue pour les lecteurs ou les utilisateurs auxquels le contenu est partagé sans rôle élevé. Testez toujours avec un compte lecteur distinct.

Faut-il donner la permission Build pour qu’un utilisateur consulte un rapport ?

Non. La lecture d’un rapport ne nécessite normalement pas la permission Build sur son modèle sémantique. Build doit être accordée lorsque la personne doit créer ses propres rapports, analyser le modèle dans des outils compatibles ou réutiliser les données publiées. Comme elle élargit les possibilités d’exploitation du modèle, attribuez-la à des groupes d’analystes identifiés, pas à tous les destinataires.

Comment retirer totalement l’accès d’une personne à un rapport Power BI ?

Supprimez l’utilisateur ou son groupe du partage du rapport, puis vérifiez les autorisations du modèle sémantique associé afin de retirer tout droit direct restant, notamment Build. Contrôlez aussi l’accès à l’espace de travail et aux audiences d’application. Si l’accès vient d’un groupe Microsoft Entra ID, retirez la personne de ce groupe selon la procédure de votre organisation, puis vérifiez la propagation.

Peut-on sécuriser un rapport Power BI uniquement en cachant des pages ou des colonnes ?

Non. Masquer une page améliore la navigation, mais ne constitue pas une barrière de sécurité si l’utilisateur conserve un chemin d’accès au contenu. De même, une colonne seulement retirée d’un visuel peut rester présente dans le modèle. Utilisez des permissions, la sécurité au niveau des lignes et, lorsque le besoin le justifie, la sécurité au niveau des objets ou un modèle séparé pour les données confidentielles.