Power Query rend Power BI Report Builder plus lisible et plus simple à administrer. Le bouton change de nom, les jeux de données exposent enfin leur code M, leurs paramètres et leur Cloud Connection. C’est petit en apparence, mais très utile quand on maintient des rapports paginés.
Qu’est-ce qui change vraiment ?
Power Query devient plus visible dans Power BI Report Builder, et c’est ça le vrai changement. Le bouton qui s’appelait avant Get Data est maintenant renommé Power Query. Dit comme ça, ça peut sembler léger. Mais dans la vraie vie, pour quelqu’un qui vient de Power BI Desktop, d’Excel ou de Fabric, c’est beaucoup plus clair.
Power BI Report Builder sert à créer des rapports paginés. Ce sont des rapports très cadrés, souvent utilisés pour des états détaillés, des factures, des exports PDF, des impressions, des listes longues, bref tout ce qui doit tenir dans une mise en page propre et répétable. Ce n’est pas le même usage qu’un rapport Power BI interactif classique. Ici, on cherche souvent de la précision, du contrôle, et une sortie fiable.
L’intégration de Power Query permet de préparer les données avant de les utiliser dans un jeu de données de rapport. Power Query s’appuie sur le langage M, un langage de transformation de données. Il sert à filtrer, renommer, fusionner, nettoyer ou structurer les données avant qu’elles arrivent dans le rapport. Si vous avez déjà utilisé Power Query dans Excel ou Power BI Desktop, vous êtes en terrain connu.
Et non, ce renommage n’est pas juste cosmétique. Dans mes missions, j’ai souvent vu des équipes chercher où se cachait Power Query dans Report Builder. Le libellé Get Data était trop générique. On pouvait se demander si c’était juste un assistant de connexion, un import simple, ou autre chose. Avec Power Query, le signal est direct. On comprend tout de suite qu’on retrouve la même logique de préparation de données que dans le reste de l’écosystème Microsoft.
Le gain est simple. Moins d’ambiguïté, moins de friction, et une interface qui parle enfin le même langage que les utilisateurs BI.
| Avant | Après | Impact |
| Bouton Get Data | Bouton Power Query | La fonctionnalité est identifiable immédiatement par les utilisateurs déjà habitués à Power Query. |
| Découverte des sources moins explicite | Accès plus clair via l’expérience Power Query | On comprend mieux où préparer et transformer les données avant de créer le jeu de données du rapport. |
| Libellé différent de Power BI Desktop, Excel et Fabric | Nom cohérent avec l’écosystème Power BI et Fabric | Les réflexes existants sont réutilisables, ce qui réduit le temps d’adaptation. |
Pourquoi l’onglet de propriétés compte ?
Le nouvel onglet de propriétés personnalisées compte parce qu’il rend un jeu de données Power Query beaucoup plus contrôlable dans Power BI Report Builder.
Avant, on pouvait vite se retrouver avec un rapport paginé qui marche, mais dont la préparation de données était un peu opaque. Là, je peux ouvrir le dataset Power Query et voir ce qui se passe vraiment. Pour auditer, corriger ou reprendre un rapport créé par quelqu’un d’autre, c’est franchement plus confortable.
| Information visible | À quoi ça sert |
| Code M | Le code M, c’est le langage de Power Query. Il décrit les étapes de préparation des données : source, filtres, colonnes renommées, types modifiés, jointures, etc. Le voir permet de comprendre la logique sans deviner. |
| Paramètres M | Les paramètres M servent à rendre une requête plus flexible. Par exemple, une date de début, un pays, un environnement dev ou prod. On voit donc si le dataset dépend de valeurs variables. |
| Cloud Connection | L’identifiant de la Cloud Connection indique quelle connexion cloud est utilisée pour accéder à la source. C’est utile pour savoir avec quel accès le rapport récupère ses données. |
Voici un exemple très simple de code M. C’est typiquement le genre de chose que j’aime pouvoir lire directement quand je récupère un rapport, parce que je vois tout de suite la source et la transformation appliquée.
let
// Source générique : je pars d'une table simple avec deux colonnes
Source = Table.FromRows(
{{"Client A", 120}, {"Client B", 80}},
{"Client", "Montant"}
),
// Transformation : je garde uniquement les montants supérieurs à 100
Filtre = Table.SelectRows(Source, each [Montant] > 100)
in
FiltreAvec ce code visible, je peux rapidement vérifier si une règle métier est codée en dur, si un filtre explique un écart, ou si la requête fait une transformation que personne n’a documentée. J’ai déjà vu des rapports où un simple filtre caché dans Power Query expliquait deux jours de débat entre métier et IT.
La limite, elle est simple. Voir le code M aide à comprendre la préparation de données, mais ça ne remplace pas une vraie gouvernance. Il faut quand même savoir quelles sources sont autorisées, quels identifiants sont utilisés, qui maintient les connexions partagées et comment elles sont sécurisées. Et c’est exactement là que la Cloud Connection devient le sujet clé du chapitre suivant.
Comment retrouver une Cloud Connection ?
On retrouve une Cloud Connection en copiant son identifiant depuis les propriétés du dataset Power Query, puis en le recherchant dans le portail Fabric, dans la zone Manage Connections and Gateways.
Dans Report Builder, quand vous utilisez un dataset basé sur Power Query, la connexion cloud n’est pas toujours visible comme une connexion classique. Elle est référencée par un identifiant. C’est cet identifiant qui sert de fil d’Ariane.
Le chemin est assez simple. Vous ouvrez les propriétés personnalisées du dataset Power Query dans Report Builder, vous repérez l’identifiant de Cloud Connection, vous le copiez, puis vous allez dans Fabric. Dans Fabric, vous ouvrez la partie Manage Connections and Gateways, c’est l’endroit où sont gérées les connexions cloud et les passerelles. Ensuite, vous recherchez l’identifiant copié. Si vous avez les droits nécessaires, vous tombez sur la connexion utilisée par le rapport paginé.
Une fois la connexion retrouvée, vous pouvez vérifier si elle pointe bien vers la bonne source. Vous pouvez aussi contrôler certains réglages, selon ce que votre tenant Fabric autorise. Et surtout, vous pouvez regarder l’état des identifiants. Si les credentials ont expiré, si un mot de passe a changé, ou si un compte technique a été remplacé, c’est souvent là que le problème se cache.
Je reste prudent sur ce point, parce que tout dépend de vos droits Fabric, des politiques de sécurité, et de la configuration mise en place par l’admin. Parfois vous pouvez modifier directement. Parfois vous pouvez seulement constater et demander à la bonne personne de mettre à jour la connexion.
Sur le terrain, j’ai vu plusieurs rapports paginés casser après une migration de compte ou un simple changement de mot de passe. Sans l’identifiant de Cloud Connection, l’équipe BI fouillait un peu à l’aveugle. Avec l’identifiant, on retrouve la bonne connexion en quelques minutes. C’est un petit détail, mais c’est exactement le genre de détail qui évite de perdre une demi-journée.
- Dataset Power Query identifié dans Report Builder.
- Code M lisible et compréhensible.
- Paramètres M contrôlés, surtout ceux qui influencent la source.
- Cloud Connection retrouvée dans Manage Connections and Gateways.
- Credentials vérifiés ou signalés à la personne qui a les droits.
Quel impact pour la maintenance BI ?
L’impact principal, c’est une maintenance plus rapide et moins opaque des rapports paginés Power BI. Je le vois comme un vrai changement de confort, surtout pour les équipes qui héritent de rapports anciens, avec des sources pas toujours documentées et des paramètres qu’on découvre souvent trop tard.
Avec l’accès plus direct au code M, le langage de Power Query, on peut comprendre comment les données sont appelées, filtrées, transformées. C’est utile pour les développeurs BI qui doivent contrôler une requête avant mise en production. C’est utile pour les analystes qui veulent vérifier si une logique métier est bien appliquée. C’est aussi utile pour les administrateurs Fabric, parce qu’ils peuvent diagnostiquer plus vite les sujets de connexion, de refresh ou de droits d’accès.
Report Builder reste Report Builder. C’est toujours un outil orienté rapports paginés, avec ses tableaux, ses exports PDF, ses usages très opérationnels. Mais il devient plus cohérent avec ce qu’on connaît déjà dans Power Query, Power BI Desktop ou les Dataflows. Et ça, franchement, ça évite pas mal d’allers-retours inutiles.
Un cas très classique. Un rapport paginé utilise une requête Power Query avec un paramètre d’environnement, par exemple Dev, Test ou Prod, ou une source cloud comme SharePoint, Azure SQL ou Dataverse. Le rapport ne s’actualise plus. Avant, l’équipe pouvait perdre du temps à chercher si le problème venait du dataset, du service, des identifiants ou d’une URL mal changée. Maintenant, elle peut regarder le M, les paramètres et la Cloud Connection au même endroit. La Cloud Connection, c’est la connexion déclarée côté service pour accéder à une source cloud avec les bons identifiants et les bons droits.
| Problème courant | Information utile | Gain concret |
| Source difficile à identifier | Lecture du code M et de la chaîne de connexion utilisée | On sait vite quelle source est appelée, sans fouiller partout |
| Credentials expirés | Vérification de la Cloud Connection associée au rapport | On corrige les accès plus vite et on relance le refresh |
| Paramètre M mal configuré | Contrôle des paramètres utilisés dans la requête Power Query | On évite les erreurs entre Dev, Test et Prod |
| Reprise d’un rapport par une autre personne | Accès à la logique Power Query et aux paramètres existants | La reprise est plus simple, même sans documentation parfaite |
J’ai déjà vu des équipes passer une demi-journée sur un rapport bloqué pour une simple connexion cloud mal alignée avec un paramètre. Ce genre d’amélioration ne rend pas tout magique, mais ça réduit clairement la zone grise.
Alors, est-ce que ça vaut le coup de s’y intéresser ?
Ces changements ne transforment pas Power BI Report Builder en nouvel outil, mais ils corrigent des irritants très concrets. Le bouton Power Query parle enfin le même langage que le reste de l’écosystème Microsoft. Le nouvel onglet de propriétés donne accès au code M, aux paramètres et à l’identifiant de Cloud Connection. Pour moi, c’est surtout un progrès côté maintenance. On comprend mieux ce qui alimente un rapport paginé, on retrouve plus vite la bonne connexion dans Fabric, et on corrige plus facilement les soucis d’identifiants. Le bénéfice pour vous est simple : moins de flou, moins de temps perdu, plus de contrôle.
FAQ
- À quoi sert Power Query dans Power BI Report Builder ?
Power Query sert à préparer et transformer les données avant de les utiliser dans un rapport paginé. On peut créer des requêtes en langage M, gérer certaines transformations et alimenter un jeu de données plus propre dans Report Builder. - Pourquoi le bouton Get Data a été renommé Power Query ?
Le nom Power Query est plus clair pour les utilisateurs qui connaissent déjà l’écosystème Power BI, Excel ou Fabric. Get Data était assez générique. Power Query indique directement qu’on va utiliser le moteur de requêtes et de transformation de données. - Que montre le nouvel onglet de propriétés d’un dataset Power Query ?
Il affiche le code M du jeu de données, les paramètres M éventuels et l’identifiant de la Cloud Connection associée. C’est utile pour comprendre comment la donnée est préparée et quelle connexion cloud est utilisée. - Comment utiliser l’identifiant de Cloud Connection ?
On peut copier cet identifiant depuis les propriétés du dataset Power Query, puis le rechercher dans le portail Fabric, dans la section Manage Connections and Gateways. Ça permet de retrouver la connexion, de la vérifier ou de mettre à jour ses identifiants si besoin. - Ces améliorations changent-elles la création de rapports paginés ?
Elles ne changent pas la logique de création d’un rapport paginé, mais elles rendent le travail plus confortable. On identifie mieux les requêtes, les paramètres et les connexions. Pour la maintenance et le diagnostic, c’est un vrai gain.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes data, marketing et BI sur des sujets très opérationnels : collecte, qualité des données, reporting, automatisation et gouvernance. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez fiabiliser vos reportings, vos connexions data ou vos automatisations, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.