Introduction

Power Query, M et les produits Microsoft

Power Query et M sont les deux faces d’une même médaille : leur objectif, c’est l’extraction, la transformation et le chargement de données, depuis une multitude de sources vers les deux outils principaux que sont Power BI et Excel. C’est la raison pour laquelle Power Query est souvent assimilé à un ETL (Extract Transform Load).

Un utilisateur pourra donc s’appuyer sur l’interface graphique exclusivement, ou saisir intégralement son code M, ou opter pour une approche mixte - c’est celle que nous adopterons dans cet ouvrage : laisser le plus souvent l’interface graphique générer le code et y apporter, lorsque c’est utile, des améliorations en code M, tant en termes de rapidité de conception qu’en termes de possibilités de transformations.

Au-delà de Power BI et Excel, c’est à toute la Power Platform de Microsoft que sont destinés Power Query et M. Rappelons que cette plateforme comprend...

À quoi sert Power Query ?

Les deux fonctions principales de Power Query (et donc de M) sont la connexion aux données d’une part, et leur transformation (ou préparation) d’autre part, en vue de charger les données dans l’outil de visualisation et d’analyse (Power BI ou Excel par exemple).

La connexion à une ou plusieurs sources de données ne présente pas de difficulté particulière (pour peu que l’on sache où trouver l’information !), et l’exposition de ce thème consiste essentiellement à découvrir les différents connecteurs, et quelques situations particulières.

C’est surtout l’étape de transformation, au sein de laquelle se cachent en effet de multiples opérations, qui va nous intéresser dans cet ouvrage : les plus simples consistent à filtrer les lignes, choisir les champs, ou encore vérifier le type de la donnée.

Il peut être d’autre part nécessaire de nettoyer les données, d’harmoniser les champs de type texte (par exemple, de tout passer en majuscule), de supprimer les valeurs nulles ou une ligne de total.

Parfois vous souhaiterez créer de nouveaux champs (de nouvelles colonnes) à partir de ceux que vous avez récupérés de la source ou des sources, calculer de nouveaux indicateurs, ou scinder un champ...

À qui s’adresse ce livre et comment est-il structuré ?

J’ai donné de nombreuses formations sur Power Query et j’ai écrit de nombreux articles sur mon blog. J’ai pu observer la réaction de chacun face à Power Query et M.

Certains utilisateurs de Power Query, soit parce que leurs besoins sont simples, soit parce que les données qu’ils vont chercher sont déjà parfaitement préparées, ont une utilisation légère de Power Query : l’interface graphique est plus que suffisante pour eux, elle n’est parfois même pas nécessaire. Nous verrons en effet que la phase de connexion permet de charger directement les données sans les retoucher. Ce cas est toutefois soit ponctuel soit rare.

D’autres utilisateurs vont avoir besoin d’un travail de préparation des données plus conséquent. C’est le cas notamment lorsque les sources sont personnelles ou locales (un fichier Excel, un fichier texte), lorsque les données sont peu structurées (une page web, des commentaires sur un formulaire), ou encore lorsque les bases de données ne répondent pas au besoin d’analyse. Dans ces situations, le recours à l’interface graphique est plus intense, parfois très poussé.

C’est à ce moment là que l’utilisation du code M devient intéressante :...

Aperçu général de l’interface de Power Query

Passons en revue les différents composants de Power Query.

Power Query et le modèle de données

Nous abordons là une articulation essentielle des outils de visualisation et de ceux que propose Microsoft en particulier.

Je vais développer cet exemple en m’appuyant sur Power BI, mais les notions évoquées ici sont transposables dans Power Pivot.

Nous l’avons vu, l’objectif de Power Query est de se connecter aux données, de les préparer, et enfin de les charger.

C’est ici qu’intervient la notion de modèle : cette étape, nécessaire avant de pouvoir analyser et visualiser les données, vient après le chargement, et implique au moins une étape incontournable, la mise en relation des tables.

Mais revenons au point...

Le modèle en étoile

Au cœur du modèle en étoile, il y a la table des transactions (dans notre exemple, il s’agit de Détail des commandes), où sont enregistrés les évènements (passer une commande, signaler un incident, noter les résultats d’un test, etc.) : elle contient les montants, les quantités, les évènements chiffrés.

Elle contient également un autre type de colonne : des identifiants, c’est-à-dire une valeur (le plus souvent représentée par des chiffres) qui permet d’identifier précisément qui a fait l’achat, pour quel produit, etc. La table des transactions est aussi appelée la table des faits.

Un modèle peut contenir plusieurs tables des faits (imaginez, par exemple, un magasin qui propose deux services : la vente, mais aussi la location, de matériel de randonnée - typiquement deux tables des faits).

Le deuxième type d’entité que vous trouverez dans un modèle en étoile est la table de dimension (dans la capture d’écran précédente, il s’agit par exemple de Clients ou de Livres) : c’est en quelque sorte la table de lookup d’Excel. Le client, avec toutes ses caractéristiques, est une dimension. C’est aussi le cas du produit, du magasin, du temps. En définitive...

Power Query et le modèle composite

Une autre notion liée au modèle est mise en place grâce à Power Query : celui de modèle simple ou composite, liés au(x) type(s) de connexion utilisé(s).

Celle-ci peut être de deux sortes : la connexion en mode Import, dans lequel les données sont extraites (copiées) à partir de la source et importées dans le document. Les données sont donc figées à un instant t, celui du chargement (elles peuvent bien entendu être actualisées à volonté). C’est le mode de travail recommandé pour des questions de performances de l’application.

L’autre type de connexion, le mode Direct ou Live, consiste, au contraire, à laisser les données dans la source, et à y retourner chaque fois qu’une action (filtre, calcul, nouveau visuel) est effectuée dans l’application. Ce mode est assez rare. Son avantage est d’analyser les données en temps réel. Son inconvénient est en général de ralentir le fonctionnement de l’application.

Un modèle simple est basé sur un seul type de connexion.

Mais il est également possible de créer un modèle dans lequel une partie des tables est importée (mode Import), et l’autre interrogée en temps réel (mode Direct...