Un directeur régional ouvre son tableau de bord Power BI depuis un hôtel, sur un réseau Wi-Fi partagé. Au même moment, un data analyst lance une requête Copilot sur le même modèle sémantique depuis le siège. Ces deux accès simultanés, sur des réseaux distincts, avec des niveaux de privilège différents, illustrent exactement ce qu’un plan bi connexion doit couvrir en 2026 : garantir que chaque utilisateur accède uniquement aux données qui le concernent, quel que soit le point d’entrée.
OneLake Security et mode d’identité : le prérequis que Power BI seul ne couvre pas
Jusqu’à récemment, on sécurisait les accès Power BI principalement via la sécurité au niveau des lignes (RLS) et des rôles définis dans le service. Cette approche fonctionne encore, mais elle ne suffit plus dès qu’on utilise Microsoft Fabric.
OneLake Security, désormais en disponibilité générale, permet de définir des règles d’accès directement dans OneLake, à l’item, au dossier, à la table, à la ligne et à la colonne. Ces règles sont automatiquement respectées par Power BI, Spark, SQL et les Fabric data agents. On ne duplique plus la gouvernance dans chaque outil : une seule couche de sécurité s’applique partout.
La condition technique que beaucoup d’équipes découvrent trop tard : OneLake Security nécessite que les lakehouses et warehouses soient configurés en User Identity Mode, pas en Delegated Identity Mode. Les environnements créés avant ce changement doivent être vérifiés. Sans cette migration, les rôles OneLake ne s’appliquent tout simplement pas, et les utilisateurs accèdent aux données sans filtrage.
Concrètement, dans un plan bi connexion, la première action à mener est un audit du mode d’identité de chaque objet Fabric. On classe les objets en deux colonnes : ceux déjà en User Identity Mode, et ceux à migrer. Tant que cet inventaire n’est pas fait, toute la couche de sécurité OneLake reste théorique.
Copilot accède aux rapports Power BI : adapter la sécurité des données à l’IA
Depuis l’intégration de Copilot dans Microsoft 365, chaque utilisateur disposant d’une licence Copilot peut interroger les rapports et modèles sémantiques Power BI auxquels il a déjà accès. Copilot raisonne sur ces données et renvoie des réponses directement dans le flux de travail, par exemple dans Teams ou Excel.
Le risque est précis : si un RLS est mal configuré ou si un espace de travail accorde des droits trop larges, Copilot peut synthétiser et restituer des données sensibles à un utilisateur qui n’aurait pas dû y accéder manuellement. L’IA ne contourne rien, elle exploite les permissions existantes. Mais elle rend les failles de gouvernance beaucoup plus visibles, parce qu’un utilisateur n’a plus besoin de chercher l’information, elle lui est poussée.
Pour un plan bi connexion robuste, on doit donc :
- Réviser les rôles RLS et les permissions d’espace de travail en partant du principe que chaque rapport accessible sera aussi interrogeable par Copilot
- Tester les réponses Copilot avec des comptes de test représentant chaque profil métier (commercial terrain, contrôleur de gestion, direction générale)
- Documenter les modèles sémantiques exposés à Copilot et restreindre l’accès aux seuls datasets nécessaires par groupe d’utilisateurs
Ce volet IA n’existait pas dans les plans de sécurisation Power BI il y a deux ans. En 2026, ignorer l’impact de Copilot sur la gouvernance des données revient à laisser une porte ouverte.
Contrôle d’accès réseau pour Power BI : Private Link et isolation cloud
Le plan bi connexion ne se limite pas aux permissions sur les données. Le chemin réseau emprunté par les requêtes compte autant que les rôles attribués dans le service.
Azure Private Link permet de relier le tenant Power BI au réseau virtuel de l’entreprise via un point de terminaison privé. Les requêtes ne transitent plus par l’internet public. Pour les organisations qui manipulent des données financières ou des données personnelles soumises au RGPD, cette isolation réseau est souvent un prérequis contractuel, pas un luxe technique.
Ce que Private Link change dans la pratique
Une fois le Private Link configuré, les utilisateurs qui se connectent depuis l’extérieur du réseau virtuel (VPN non actif, réseau personnel) ne peuvent plus atteindre le service Power BI. On force ainsi un périmètre réseau strict.
Les retours varient sur ce point : certaines équipes trouvent la configuration fluide sur un tenant neuf, d’autres rencontrent des frictions sur des tenants historiques avec des passerelles de données locales (on-premises data gateways) déjà en place. Dans tous les cas, tester le Private Link sur un environnement de pré-production avant de l’appliquer au tenant principal évite des interruptions de service.
Étiquettes de confidentialité Microsoft Purview appliquées aux rapports Power BI
Microsoft Purview permet d’appliquer automatiquement des étiquettes de confidentialité aux fichiers, aux datasets et aux rapports Power BI. Ces étiquettes suivent les données lorsqu’elles sont exportées vers Excel, PDF ou PowerPoint : un rapport classé « Confidentiel » conserve cette classification même hors de Power BI.
L’application automatique des étiquettes repose sur des règles définies dans le centre de conformité Purview. On peut cibler des mots-clés, des types d’informations sensibles (numéros de carte bancaire, identifiants personnels) ou des emplacements spécifiques dans Fabric.
- Configurer les types d’informations sensibles pertinents pour le métier (données RH, marges commerciales, données clients)
- Activer l’étiquetage automatique sur les modèles sémantiques Power BI contenant ces types
- Vérifier que les exports respectent bien la politique d’étiquetage, en particulier les exports Excel depuis le service Power BI
- Former les utilisateurs à la signification concrète de chaque niveau d’étiquette pour éviter qu’ils contournent les restrictions par méconnaissance
Un plan bi connexion complet intègre Purview dès la phase de classification des données, pas après le déploiement des rapports. Étiqueter après coup expose à des semaines de données non classifiées accessibles sans restriction.
Construire un plan bi connexion opérationnel en 2026
Le fil conducteur de ces quatre axes (OneLake Security, gouvernance Copilot, isolation réseau, étiquetage Purview) est le même : la sécurité Power BI ne se joue plus dans une seule couche. On empile des contrôles complémentaires, chacun couvrant un vecteur de risque distinct.
L’erreur la plus fréquente reste de traiter la sécurité des accès comme un projet ponctuel. Un plan bi connexion efficace prévoit des revues trimestrielles des rôles, des tests Copilot après chaque ajout de dataset, et une vérification du mode d’identité à chaque création d’objet Fabric. La sécurité Power BI en 2026 est un processus continu, pas une configuration initiale.
