OLS masque complètement des tables ou des colonnes pour certains rôles, contrairement à la RLS qui filtre seulement les lignes. Vous le configurez via la vue TMDL de Power BI Desktop, via Tabular Editor, ou via l’endpoint XMLA sur Power BI Premium. Cette sécurité au niveau des objets ne s’applique qu’aux utilisateurs en rôle lecteur du modèle sémantique, jamais aux administrateurs ou contributeurs.
En bref:
- La sécurité au niveau des objets (OLS) masque complètement les tables ou colonnes pour certains rôles, contrairement à la RLS qui filtre uniquement les lignes.
- OLS rend invisible tout objet, ce qui peut provoquer des erreurs silencieuses si des visuels continuent de référencer ces éléments masqués.
- La configuration d’OLS passe par Power BI Desktop, Tabular Editor, ou l’endpoint XMLA, avec une gestion rigoureuse des rôles et une documentation précise.
- OLS ne protège pas contre les administrateurs ou contributeurs, uniquement contre les utilisateurs en rôle lecteur du modèle.
- Certaines fonctionnalités de Power BI comme Insights rapides ou infobulles ne sont pas compatibles avec l’OLS en production.
Table des matières
- Qu’est-ce que la sécurité au niveau des objets (OLS) et en quoi diffère-t-elle de la RLS ?
- Guide pas-à-pas pour définir OLS avec TMDL, Tabular Editor ou XMLA
- OLS, RLS, mesures et relations : comment ces éléments interagissent-ils ?
- Quels pièges et limitations OLS présente-t-il en production ?
- Comment valider un déploiement OLS avant et après la mise en production ?
- Ce que l’expérience terrain de Biworks révèle sur les déploiements OLS
- Ce que peu de guides osent dire sur OLS
- Besoin d’un déploiement OLS sans mauvaise surprise ?
- Ressources officielles et techniques recommandées
- Sources
- Questions fréquentes
Qu’est-ce que la sécurité au niveau des objets (OLS) et en quoi diffère-t-elle de la RLS ?
Il faut d’abord dissiper une confusion fréquente chez les développeurs qui débutent avec ce type de restriction : OLS ne filtre rien, il efface. Là où la sécurité au niveau des lignes (RLS) laisse une table visible mais réduit les lignes qu’un utilisateur peut consulter, OLS rend une table, une colonne, voire une mesure, totalement invisible pour le rôle concerné. L’objet disparaît des métadonnées elles-mêmes, comme s’il n’avait jamais existé dans le modèle.
Cette différence a des conséquences concrètes :
- Un utilisateur soumis à OLS ne verra pas la table dans le volet de champs, même en cherchant activement.
- Aucune erreur ne s’affiche à l’utilisateur tant qu’aucun visuel ne référence l’objet masqué.
- La restriction ne touche que les personnes en mode « lecteur » du modèle sémantique : les administrateurs, membres et contributeurs conservent un accès complet, quels que soient les rôles OLS définis.
Cette portée limitée est souvent mal comprise : beaucoup de développeurs pensent, à tort, que OLS protège aussi contre les accès des concepteurs de rapports.
Guide pas-à-pas pour définir OLS avec TMDL, Tabular Editor ou XMLA
Trois chemins mènent à la même destination, avec des niveaux de complexité différents.
- Créez vos rôles dans Power BI Desktop. Rendez-vous dans l’onglet Modélisation, puis Gérer les rôles. Nommez chaque rôle selon le public visé (« RH_Standard », « Finance_Restreint »), sans encore toucher aux propriétés OLS à ce stade.
- Configurez OLS via la vue TMDL. Cette vue, intégrée nativement à Power BI Desktop, permet d’éditer directement la définition tabulaire du modèle sans outil externe. Vous y ajoutez une propriété masquant l’objet pour un rôle donné, ce qui simplifie considérablement les tâches courantes de modélisation qui exigeaient auparavant Tabular Editor.
- Ou configurez OLS via Tabular Editor. Ouvrez le modèle depuis Tabular Editor, sélectionnez la table ou la colonne à protéger, puis dans le panneau des propriétés du rôle, réglez la permission sur « None » au lieu de « Read ». L’outil affiche clairement, pour chaque rôle, l’état de chaque objet, ce qui facilite l’audit visuel avant publication.
- Passez par l’endpoint XMLA si votre gouvernance l’exige. Sur un espace de travail Power BI Premium ou Fabric, l’endpoint XMLA permet de scripter les définitions OLS en TMSL et de les déployer via des pipelines automatisés, une option pertinente quand plusieurs modèles partagent les mêmes règles de sécurité.
- Publiez, puis affectez les groupes ou utilisateurs dans le service Power BI. Une fois le modèle en ligne, ouvrez la sécurité du jeu de données et associez chaque rôle aux groupes de sécurité Microsoft Entra ID ou aux utilisateurs individuels concernés.
Conseil de pro : Créez systématiquement un rôle « Full Model » sans aucune restriction et attribuez-le à une petite équipe de test. Cela évite les mauvaises surprises et vous donne un point de comparaison immédiat pour repérer un objet mal masqué.
Les bonnes pratiques recommandent d’ailleurs de prévoir un rôle complet et des rôles distincts par audience dès la conception, plutôt que de les ajouter dans l’urgence après un incident de sécurité.
OLS, RLS, mesures et relations : comment ces éléments interagissent-ils ?
Un modèle ne vit jamais isolé, et c’est là que les développeurs rencontrent leurs premières vraies difficultés.
- Vous ne pouvez pas mélanger RLS et OLS dans un même rôle sans stratégie claire : mieux vaut créer un rôle purement RLS pour le filtrage de lignes, et un rôle purement OLS pour le masquage d’objets, puis combiner leurs effets côté service si nécessaire.
- Une mesure DAX qui référence une colonne ou une table masquée devient indisponible pour l’utilisateur restreint, ce qui peut générer des erreurs inattendues dans les visuels si la mesure est utilisée ailleurs dans le rapport.
- Sécuriser une table centrale casse parfois des parcours relationnels entiers : un visuel qui agrège plusieurs tables liées à l’objet masqué perd sa cohérence. La solution consiste souvent à dupliquer une mesure agrégée en amont, hors du champ visé par OLS, ou à restructurer le modèle pour isoler les objets sensibles.
- Un utilisateur appartenant à plusieurs rôles hérite du comportement le plus permissif : si un seul rôle accorde la lecture d’un objet, cet accès prévaut sur les autres restrictions.
Quels pièges et limitations OLS présente-t-il en production ?
Certaines fonctionnalités de Power BI ne tolèrent tout simplement pas OLS, et le découvrir en production coûte cher en confiance utilisateur.
- Les Insights rapides, la narration intelligente et certaines intégrations de types de données Excel ne sont pas prises en charge lorsque OLS est actif sur le modèle concerné.
- Les visuels cassés apparaissent le plus souvent quand un titre, une infobulle ou une mise en forme conditionnelle référence un champ devenu invisible pour le rôle actif : l’erreur remonte à l’écran plutôt que de disparaître discrètement.
- Un utilisateur sans rôle assigné se retrouve parfois avec un accès complet par défaut, ou au contraire avec un rapport vide, selon la configuration : c’est pourquoi un rôle « Full Model » de secours reste indispensable.
Dans les cas où ces limitations pèsent trop sur l’expérience utilisateur, mieux vaut parfois renoncer à OLS et concevoir des rapports distincts par audience, quitte à dupliquer une partie du travail de modélisation.
Comment valider un déploiement OLS avant et après la mise en production ?
Une checklist rigoureuse évite l’essentiel des incidents signalés par les équipes qui déploient OLS pour la première fois.
- Testez localement avec la fonction « View as ». Dans Power BI Desktop, sélectionnez chaque rôle un par un et vérifiez que les visuels s’affichent sans erreur, y compris ceux qui semblent sans rapport avec l’objet masqué.
- Vérifiez la cohérence des mesures et des infobulles. Ouvrez systématiquement les visuels secondaires (info-bulles, drill-through, signets) que l’on oublie souvent de tester.
- Publiez, puis configurez la sécurité du jeu de données côté service. Affectez les groupes ou utilisateurs à chaque rôle, en suivant la procédure officielle de test et d’affectation après publication.
- Automatisez les scénarios critiques. Des scripts PowerShell couplés à des tests d’intégration de rapports permettent de détecter une régression dès qu’un changement de modèle affecte un rôle existant.
Conseil de pro : Documentez chaque rôle OLS dans un tableau partagé avec les objets masqués et la justification métier. Six mois plus tard, personne ne se souvient pourquoi telle colonne a été retirée, sauf si c’est écrit noir sur blanc.
Cette checklist rejoint d’ailleurs les principes détaillés dans la checklist sécurité Power BI de Biworks, pensée pour couvrir l’ensemble des points de contrôle avant une mise en production.
Ce que l’expérience terrain de Biworks révèle sur les déploiements OLS
François, formateur certifié Qualiopi et préparateur à la certification PL-300 chez Biworks, observe qu’OLS revient le plus souvent dans deux contextes : la protection des données RH sensibles (grilles salariales, données personnelles) et la restriction d’accès aux marges commerciales en finance. Dans les deux cas, la question centrale n’est pas technique mais organisationnelle : faut-il un modèle unique avec plusieurs rôles, ou des modèles séparés par département ?
La règle qu’il applique en formation est simple : centraliser tant que le nombre de rôles reste gérable et que la gouvernance suit, dupliquer dès que les audiences deviennent trop hétérogènes pour un seul modèle. Les entreprises qui négligent cette question passent souvent des mois à corriger des visuels cassés qu’un choix d’architecture initial aurait évités.
Ce que peu de guides osent dire sur OLS
La documentation technique traite souvent OLS comme une simple case à cocher dans les propriétés d’un rôle. C’est trompeur. La vraie difficulté n’est jamais la syntaxe TMDL ou le clic dans Tabular Editor, elle est organisationnelle : décider qui a besoin de voir quoi, et anticiper que cette décision évoluera.
Beaucoup d’équipes activent OLS pour répondre à une urgence de conformité, sans avoir cartographié au préalable les mesures et visuels qui dépendent des objets à masquer. Le résultat prévisible, ce sont des rapports qui plantent silencieusement en production, découverts par un utilisateur mécontent plutôt que par un test interne.
Mon conseil pour un déploiement qui tient dans le temps : traitez la conception des rôles OLS comme un exercice de gouvernance avant d’en faire un exercice technique. Documentez, testez systématiquement avec « View as », et acceptez qu’un modèle trop complexe pour être sécurisé proprement doit parfois être scindé en plusieurs modèles plus simples. La technique suit toujours la clarté de la décision, jamais l’inverse.
— François
Besoin d’un déploiement OLS sans mauvaise surprise ?
Nous accompagnons les entreprises et cabinets qui veulent sécuriser leurs modèles Power BI sans y perdre des semaines en essais et corrections. Contrairement à une configuration bricolée en interne sans méthode, notre équipe audite votre modèle, définit une architecture de rôles cohérente et forme vos équipes pour qu’elles gèrent la suite en autonomie.
Nos solutions Power BI sur mesure couvrent l’audit de modèle, l’implémentation d’OLS et de RLS, ainsi que l’hébergement sécurisé sur Azure. Externaliser devient pertinent dès que votre modèle croise plusieurs audiences sensibles, RH et finance par exemple, ou dès qu’une obligation de conformité impose une gouvernance documentée. Pour les équipes qui préfèrent monter en compétence directement, notre formation Power BI certifiante Qualiopi avec préparation PL-300 est éligible au CPF et se déroule sur trois jours. Consultez notre page Power BI pour évaluer la meilleure option selon la maturité de votre équipe, ou contactez-nous directement pour un audit initial de votre modèle.
Ressources officielles et techniques recommandées
- Documentation Microsoft Learn sur la sécurité OLS, incluant TMDL et endpoint XMLA.
- Module de formation Microsoft sur les restrictions d’accès aux objets.
- Guide pratique Tabular Editor sur OLS.
- Guide RLS Power BI de Biworks pour comparer les deux approches.
Sources
- sécurité Object-Level (OLS) avec Power BI – Microsoft Learn
- Restrict access to Power BI model objects — Microsoft Learn training module
- OLS in Power BI — Tabular Editor blog
- sécurité Object-Level (OLS) avec Power BI – Microsoft Learn (FR)
Questions fréquentes
Qu’est-ce que la RLS dans Power BI ?
La sécurité au niveau des lignes (RLS) filtre les données visibles selon des règles DAX appliquées par rôle, sans masquer les tables ou colonnes elles-mêmes, contrairement à OLS.
Quelle est la meilleure certification Power BI ?
La certification PL-300 de Microsoft reste la référence pour valider des compétences sur Power BI, y compris la modélisation de sécurité comme OLS et RLS. Biworks propose une préparation CPF certifiante à cette certification.
Quel langage utilise Power BI pour les mesures et les modèles ?
Power BI utilise le DAX pour créer des mesures et des colonnes calculées, et le langage M dans Power Query pour la transformation des données en amont du modèle.
Peut-on combiner OLS et RLS sur le même rôle ?
Techniquement oui, mais la pratique recommandée consiste à séparer les rôles OLS et RLS pour éviter les conflits difficiles à déboguer, puis à croiser leurs effets via l’affectation d’utilisateurs à plusieurs rôles si nécessaire.
Pourquoi mes visuels se cassent-ils après avoir activé OLS ?
Un visuel se casse généralement parce qu’une mesure, une info-bulle ou un signet référence encore un objet désormais masqué pour le rôle actif. Tester chaque rôle avec « View as » avant publication permet de repérer ces cas.