On prépare un plan BI, on choisit Power BI comme couche de présentation, et la première question concrète arrive vite : comment connecter les sources de données sans créer un plat de spaghettis ingérable dans six mois ? Le choix du mode de connexion, la gouvernance des accès et la structure du modèle sémantique conditionnent tout le reste. Voici les pratiques qui tiennent la route une fois le plan BI déployé à l’échelle d’une équipe ou d’une organisation.
Mode de connexion Power BI : Import, DirectQuery ou Direct Lake
La plupart des projets démarrent en mode Import parce que c’est le réglage par défaut de Power BI Desktop. On charge les données dans le fichier .pbix, les rapports sont rapides, et tout semble simple. Le problème apparaît quand le volume de données grossit ou quand plusieurs rapports interrogent la même source avec des copies différentes.
Choisir le mode de connexion au moment du plan BI, pas après. C’est une décision d’architecture, pas un détail technique à régler plus tard.
Le mode DirectQuery interroge la source en temps réel, sans stocker les données dans Power BI. C’est adapté aux très grandes bases de données où l’import deviendrait trop lourd. La contrepartie : chaque interaction utilisateur génère une requête vers la source, ce qui peut ralentir l’affichage si le modèle ou la base n’est pas optimisé.
Avec l’arrivée de Microsoft Fabric, une troisième option existe : Direct Lake. Ce mode lit directement les fichiers Parquet stockés dans le lakehouse OneLake, sans import classique ni requête DirectQuery à chaque clic. Pour les organisations qui centralisent leurs données dans Fabric, Direct Lake devient le mode de connexion le plus cohérent avec un plan BI gouverné.
- Import : adapté aux volumes modérés, rapports très réactifs, mais risque de copies multiples des mêmes données entre rapports
- DirectQuery : pertinent pour les bases volumineuses ou les données qui changent fréquemment, à condition d’optimiser les requêtes côté source
- Direct Lake : combine la performance de l’import et la fraîcheur du DirectQuery, mais nécessite une capacité Fabric et un lakehouse structuré
Gouvernance des connexions dans un plan BI Power BI
On voit souvent des organisations où chaque analyste crée ses propres connexions dans Power BI Desktop, avec ses propres identifiants et ses propres transformations Power Query. Au bout de quelques mois, personne ne sait quelle source alimente quel rapport, ni si les chiffres affichés dans deux tableaux de bord sont calculés de la même façon.
Une bonne pratique documentée dans les guides d’implémentation Microsoft consiste à cartographier chaque exigence du plan BI au bon niveau de contrôle. Microsoft Fabric organise la gouvernance en plusieurs niveaux (tenant, capacité, workspace). La majorité des échecs de gouvernance viennent de décisions prises au mauvais niveau, par exemple bloquer un usage métier au niveau tenant alors qu’un contrôle au niveau workspace suffirait.
Passerelles de données et actualisation
Pour les sources on-premises (SQL Server local, fichiers réseau, ERP hébergé en interne), les passerelles de données sont le point de passage obligé. Sans passerelle correctement configurée, l’actualisation automatique des rapports publiés sur le service Power BI ne fonctionne pas.
On installe la passerelle sur un serveur dédié (pas sur le poste d’un analyste), on centralise les identifiants de connexion, et on planifie les actualisations en dehors des heures de pointe. Une passerelle partagée et documentée évite les connexions sauvages qui se multiplient quand chaque utilisateur bricole sa propre solution.
Modèle sémantique Power BI : structurer avant de connecter
Connecter des sources ne suffit pas si le modèle de données sous-jacent est mal conçu. Le modèle sémantique (anciennement appelé dataset) est la couche intermédiaire entre les données brutes et les rapports. C’est là que se définissent les relations entre tables, les mesures DAX et les hiérarchies.
La pratique la plus rentable à long terme : construire un modèle sémantique unique et certifié, partagé entre plusieurs rapports. Plutôt que de dupliquer les transformations dans chaque fichier .pbix, on publie un modèle sémantique sur le service Power BI, et les créateurs de rapports s’y connectent en mode « connexion active ».
Certification et découverte des données
Power BI permet de certifier un modèle sémantique pour signaler aux utilisateurs qu’il est fiable et gouverné. Dans les paramètres du service, un administrateur définit qui peut certifier, et les modèles certifiés apparaissent en priorité quand un utilisateur cherche une source de données.
- Nommer les modèles sémantiques de façon explicite (pas « Dataset1 » mais « Ventes_France_Mensuel ») pour faciliter la découverte
- Documenter chaque mesure DAX avec une description dans les propriétés du champ
- Limiter le nombre de modèles sémantiques par workspace : un modèle par domaine métier est souvent le bon ratio
- Utiliser la fonctionnalité de promotion avant la certification pour tester un modèle avec un groupe restreint
Sécurité des données et paramètres de partage Power BI
Connecter des données sensibles (comptabilité, RH, données clients) dans Power BI impose de verrouiller les accès dès la conception du plan BI. Deux mécanismes complémentaires existent.
La sécurité au niveau des lignes (Row-Level Security) filtre les données visibles dans un rapport selon le profil de l’utilisateur connecté. Un commercial ne voit que ses clients, un directeur régional voit sa région. Configurer la RLS dans le modèle sémantique, pas dans chaque rapport, garantit que la règle s’applique partout.
Paramètres de partage au niveau du service
Les administrateurs Fabric contrôlent, via les paramètres du tenant, quels utilisateurs peuvent partager des rapports à l’extérieur de l’organisation, exporter des données vers Excel, ou intégrer des rapports dans des applications tierces. Les retours varient sur le niveau de restriction optimal : trop verrouiller freine l’adoption, trop ouvrir expose les données. L’approche la plus pragmatique consiste à activer les restrictions au niveau tenant puis à créer des exceptions ciblées par workspace pour les équipes qui ont un besoin documenté.
Un plan BI qui intègre Power BI comme couche de reporting tient sur trois piliers techniques : le mode de connexion adapté au volume et à la fraîcheur des données, un modèle sémantique unique et certifié, et une gouvernance des accès positionnée au bon niveau. Le reste (choix des visuels, mise en page des rapports) vient après, et ne rattrapera jamais une architecture de connexion bancale.
