Brancher une source de données dans Power BI prend parfois deux minutes. Configurer une connexion fiable qui tient dans le temps, partagée avec toute l’équipe et compatible avec les futures mises à jour, c’est un autre sujet. Ce guide détaille les étapes concrètes pour réussir la connexion dans un plan BI sans accumuler de dette technique dès le départ.
Choix du driver de connexion Power BI : ODBC ou ADBC
Avant même d’ouvrir Power BI Desktop, il faut trancher sur le driver. Ce choix conditionne la performance des requêtes et la maintenance à long terme.
Databricks documente que les nouvelles connexions Power BI utilisent désormais par défaut le driver ADBC (Arrow Database Connectivity), tandis que les connexions existantes restent en ODBC tant qu’elles ne sont pas mises à jour manuellement. La bascule complète vers ADBC est annoncée à partir de 2026.
Concrètement, cela signifie que tout nouveau projet de connexion BI devrait intégrer cette contrainte dès la conception. Databricks précise qu’il faut utiliser un seul type de driver par modèle sémantique. Mélanger ODBC et ADBC sur un même modèle crée des incohérences de typage et des erreurs silencieuses lors de l’actualisation.
Ce que cela change pour votre plan de mise en place
Si vous connectez Power BI à Databricks ou à des sources cloud récentes, prévoyez trois éléments dans votre plan :
- Une stratégie de migration des drivers, en listant les modèles encore en ODBC et en planifiant leur bascule vers ADBC avant la date limite.
- Des tests de performance comparés ADBC/ODBC sur vos modèles les plus volumineux, pour vérifier que le gain de vitesse annoncé se confirme avec vos données réelles.
- Une politique homogène documentée dans un wiki ou un fichier partagé, pour que chaque membre de l’équipe sache quel driver utiliser sur quel modèle.
Ignorer ce point revient à accumuler une dette technique qui se manifestera lors d’une mise à jour forcée du connecteur.
Sources de données dans Power BI : préparer la connexion côté serveur
Power BI peut se connecter à des dizaines de sources différentes : bases SQL, fichiers Excel, API REST, services cloud. Le problème ne vient presque jamais du connecteur lui-même, mais de la configuration côté serveur.
Vous avez déjà vu un rapport échouer à l’actualisation parce qu’un mot de passe de service a expiré ? C’est le cas le plus fréquent. La connexion fonctionne en local sur Power BI Desktop, puis casse dès la publication sur le Power BI Service.
Passerelle de données : le maillon souvent négligé
Pour les sources de données hébergées en local (bases on-premise, fichiers réseau), une passerelle de données (data gateway) est obligatoire. Sans passerelle correctement configurée, aucune actualisation automatique ne fonctionne sur le Service.
Trois erreurs reviennent régulièrement lors de la mise en place de la passerelle :
- Installer la passerelle sur un poste utilisateur qui s’éteint le soir, au lieu d’un serveur dédié ou d’une machine virtuelle toujours allumée.
- Utiliser un compte personnel pour l’authentification de la passerelle, plutôt qu’un compte de service avec un mot de passe géré par l’entreprise.
- Oublier de tester l’actualisation planifiée après la publication. Un rapport qui se rafraîchit manuellement ne garantit pas qu’il s’actualisera automatiquement le lundi à 7 h.
Documenter ces paramètres dans un fichier accessible à l’équipe projet évite de recommencer le diagnostic à chaque incident.
Connecteur PostgreSQL 2.0 et nouveautés Fabric 2025
Microsoft a mis en disponibilité générale la version 2.0 du connecteur Azure Database pour PostgreSQL, avec la prise en charge de TLS 1.3. Ce détail technique a une conséquence pratique directe : les connexions refusées pour incompatibilité TLS disparaissent sur les environnements récents.
Pour les entreprises qui utilisent PostgreSQL comme source principale, cette mise à jour simplifie la connexion depuis Power BI sans passer par un middleware intermédiaire. Si votre plan BI inclut des sources PostgreSQL, vérifiez que vous utilisez bien la version 2.0 du connecteur dans Power BI Desktop.
Plus largement, l’écosystème Microsoft Fabric intègre de nouveaux connecteurs et la montée en puissance de l’upsert sur Lakehouse. Cela ouvre des scénarios de connexion de données plus fluides pour les architectures data modernes, à condition de suivre les mises à jour documentées sur la page « Nouveautés de Microsoft Fabric ».
Publication et partage des rapports Power BI avec l’équipe
La connexion aux données ne s’arrête pas à Power BI Desktop. La publication sur le Power BI Service transforme un fichier local en ressource partagée, mais cette étape introduit des contraintes supplémentaires.
Quand vous publiez un rapport, les identifiants de connexion ne sont pas transférés automatiquement. Il faut reconfigurer les identifiants dans le Service après chaque publication initiale. C’est une étape que beaucoup d’utilisateurs découvrent au moment où l’actualisation échoue pour la première fois.
Workspace et droits d’accès
Un workspace Power BI correspond à un espace de travail partagé. Attribuez les rôles (administrateur, membre, contributeur, lecteur) en fonction de ce que chaque personne doit pouvoir faire, pas en fonction de son titre.
Un analyste qui crée des rapports a besoin du rôle contributeur. Un directeur qui consulte les tableaux de bord n’a besoin que du rôle lecteur. Donner le rôle administrateur à tout le monde « pour simplifier » crée des risques de suppression accidentelle de modèles ou de rapports.
Plan de connexion BI : les étapes concrètes pour démarrer
Pour structurer la mise en place, voici l’ordre qui limite les allers-retours :
Commencez par lister toutes les sources de données du projet et leur localisation (cloud ou on-premise). Identifiez ensuite le driver adapté à chaque source. Installez et configurez la passerelle si des sources locales sont concernées. Testez chaque connexion individuellement dans Power BI Desktop, puis publiez un rapport de test sur le Service pour valider l’actualisation automatique.
Ce processus prend quelques heures sur un projet simple. Sur un projet avec plusieurs dizaines de sources, prévoyez une phase de recette dédiée à la connexion avant de commencer la conception des visuels.
Un rapport Power BI fiable repose d’abord sur la qualité de ses connexions, pas sur la complexité de ses graphiques. Investir du temps sur la configuration des sources, des drivers et de la passerelle évite la majorité des incidents en production. Le reste (tableaux de bord, rapports paginés, partage) découle naturellement d’une fondation de connexion solide.
