Vous consultez un tableau de bord Power BI et les chiffres datent de plusieurs heures. Le temps de rafraîchir manuellement, la réunion est terminée. Ce décalage entre la donnée source et le visuel affiché tient souvent à un mauvais choix de mode de connexion dans Power BI Service. Comprendre les options disponibles, leurs contraintes techniques et leurs cas d’usage concrets permet de construire un plan BI connection adapté à vos besoins de temps réel.
DirectQuery, Import et Live Connection : trois logiques de connexion Power BI
Avant de parler d’optimisation, posons les bases. Power BI propose plusieurs modes pour relier un rapport à ses données. Chacun répond à un besoin différent, et choisir le mauvais mode génère soit des rapports lents, soit des données obsolètes.
A lire aussi : Reengineering en entreprise : redéfinir le processus pour optimiser la performance
Import : la copie locale des données
Le mode Import copie les données de la source vers Power BI. Le rapport interroge ensuite cette copie stockée en mémoire. Les performances d’affichage sont excellentes, mais les données ne bougent plus jusqu’au prochain rafraîchissement planifié.
Ce mode convient aux analyses historiques ou aux jeux de données qui changent peu (une fois par jour, par exemple). Pour du temps réel, il montre vite ses limites.
A lire en complément : Optimiser la productivité avec le travail en 2x8
DirectQuery : la requête à la source à chaque interaction
Avec DirectQuery, Power BI n’importe rien. Chaque filtre appliqué, chaque clic sur un visuel déclenche une requête vers la base de données source. Le résultat est toujours frais, mais chaque interaction génère une charge sur le serveur source.
Un rapport avec une vingtaine de visuels peut envoyer des dizaines de requêtes simultanées à chaque ouverture de page. Si la base n’est pas dimensionnée pour absorber cette charge, les temps de réponse explosent.
Live Connection : le lien direct avec un modèle tabulaire
La Live Connection s’adresse aux modèles hébergés dans Analysis Services ou dans un jeu de données Power BI Premium. Le rapport se branche directement sur un modèle sémantique existant, sans recréer de couche de données. Ce mode centralise la logique métier et évite les doublons de modèles entre équipes.
Direct Lake sur Microsoft Fabric : le mode qui change le plan BI connection
Depuis l’arrivée de Microsoft Fabric, un quatrième mode s’ajoute au trio classique. Direct Lake connecte Power BI directement aux fichiers Parquet stockés dans OneLake, sans passer par une base relationnelle intermédiaire.
Vous avez déjà remarqué que le mode Import offre de bonnes performances mais des données figées, tandis que DirectQuery offre des données fraîches mais des performances variables ? Direct Lake combine les avantages des deux approches : il lit les données depuis le lac sans les copier intégralement en mémoire, tout en maintenant des temps de réponse proches de l’Import.
Microsoft recommande ce mode pour les scénarios temps quasi-réel sur de gros volumes, là où DirectQuery surchargerait la source. La condition : vos données doivent résider dans un Lakehouse ou un Warehouse Fabric.
Quand choisir Direct Lake plutôt que DirectQuery
Direct Lake prend tout son intérêt quand le volume de données est élevé et que les rafraîchissements fréquents suffisent (quelques minutes de latence acceptables). Si vous avez besoin d’une latence inférieure à la minute, DirectQuery reste pertinent, à condition d’optimiser le modèle source.
Optimiser un plan BI connection en DirectQuery pour le temps réel
DirectQuery est le mode le plus utilisé pour du temps réel dans Power BI Service. Il est aussi le plus sensible à la qualité du modèle de données. Voici les leviers concrets qui font la différence entre un rapport fluide et un rapport inutilisable.
- Réduire le nombre de visuels par page : chaque visuel envoie sa propre requête à la source. Passer de quinze visuels à huit divise la charge réseau et serveur de façon significative.
- Privilégier un modèle en étoile avec des tables de faits et de dimensions bien séparées, plutôt que des tables aplaties avec des relations Many-to-Many qui multiplient les jointures côté source.
- Utiliser des tables d’agrégation (aggregations tables) pour que Power BI interroge d’abord un résumé précalculé avant de descendre dans le détail. Cette technique réduit considérablement le volume de données transféré.
- Limiter les colonnes calculées côté Power BI et reporter le maximum de calculs dans la source (vues SQL, colonnes précalculées) pour alléger chaque requête.
Ces optimisations ne sont pas optionnelles. Sans elles, un rapport DirectQuery avec plus d’une dizaine de visuels devient lent au point de décourager les utilisateurs.
Modèle composite Power BI : mixer les modes pour un compromis réaliste
Pourquoi se limiter à un seul mode ? Le mode Composite permet de combiner Import et DirectQuery dans le même rapport. Une table de référence (liste de produits, hiérarchie géographique) reste importée pour garantir la rapidité des filtres. Les tables de faits transactionnelles passent en DirectQuery pour afficher des données fraîches.
Le mode Composite est souvent le choix le plus pragmatique pour un plan BI connection en entreprise. Il évite de tout miser sur DirectQuery (et de surcharger la source) tout en gardant une fraîcheur acceptable sur les indicateurs critiques.
Un point de vigilance : les relations entre une table Import et une table DirectQuery peuvent limiter certaines fonctionnalités DAX. Testez systématiquement vos mesures après avoir activé le mode Composite.
Actualisation planifiée et passerelle : les pièges à éviter dans Power BI Service
Même avec un bon mode de connexion, une passerelle mal configurée ruine la chaîne de données. La passerelle de données locale (On-premises Data Gateway) fait le pont entre Power BI Service et vos bases internes. Si elle tourne sur une machine sous-dimensionnée ou si plusieurs jeux de données la sollicitent en même temps, les rafraîchissements échouent silencieusement.
Pour les connexions DirectQuery, la passerelle reste active en permanence (pas seulement lors des rafraîchissements planifiés). Prévoyez une machine dédiée avec suffisamment de mémoire et une connexion réseau stable.
Côté actualisation planifiée (mode Import ou Composite), Power BI Service permet de programmer jusqu’à plusieurs rafraîchissements par jour selon la licence. Vérifiez les plages horaires pour éviter les conflits avec d’autres processus sur la source.
Choisir le bon mode selon votre contexte
- Données historiques, analyses mensuelles : Import suffit, avec un rafraîchissement quotidien.
- Suivi opérationnel avec quelques minutes de latence tolérées : Direct Lake sur Fabric ou mode Composite.
- Monitoring en temps réel strict (latence inférieure à la minute) : DirectQuery avec un modèle en étoile optimisé et des tables d’agrégation.
Un plan BI connection efficace ne repose pas sur un seul mode appliqué partout. Il combine les approches selon la criticité de chaque rapport et la capacité de l’infrastructure source à absorber la charge. Commencez par identifier vos rapports les plus consultés, mesurez la latence acceptable pour chacun, puis attribuez le mode de connexion adapté. Le temps réel dans Power BI Service n’exige pas forcément DirectQuery sur tout : c’est souvent un assemblage réfléchi qui donne les meilleurs résultats.
