Comment utiliser le langage M dans Power BI : le guide pratique de Power Query

Pour utiliser le langage M dans Power BI, ouvrez Transformer les données, réalisez ou modifiez les étapes dans Power Query, puis consultez leur code dans la barre de formule ou l'Éditeur avancé. M sert à extraire, nettoyer, combiner et mettre en forme les données avant leur chargement dans le modèle ; il ne remplace pas DAX, qui calcule ensuite des indicateurs dans les rapports.

Le langage M : à quoi sert-il exactement dans Power BI ?

M, pour Power Query Formula Language, est un langage fonctionnel utilisé par Power Query. Chaque action effectuée dans l'interface — promouvoir des en-têtes, supprimer une colonne, fusionner deux tables, changer un type ou filtrer des lignes — devient une étape écrite en M. Une requête M produit le plus souvent une table, mais elle peut aussi retourner une liste, un enregistrement, une valeur ou une fonction.

Dans un flux Power BI classique, M intervient à l'entrée : il se connecte à un fichier Excel, un dossier, une base SQL, une API ou SharePoint, puis prépare les données. Lors de l'actualisation, Power BI exécute cette requête, charge le résultat dans le modèle et rend les données disponibles aux visuels. Les mesures DAX, elles, sont évaluées dans le modèle selon les filtres appliqués dans le rapport. Cette distinction évite un grand nombre de mauvais choix techniques.

Démarrer : trouver et modifier le code M dans Power BI

Il n'est pas nécessaire d'écrire du M dès le premier jour. La méthode la plus sûre consiste à réaliser une transformation avec l'interface, puis à observer le code produit. Dans Power BI Desktop, cliquez sur Transformer les données après l'importation. La fenêtre de l'Éditeur Power Query affiche les requêtes à gauche, l'aperçu central et les étapes appliquées à droite.

1. Créez une requête avec l'interface
   Connectez-vous à une source, puis effectuez une ou deux opérations sans risque : supprimer une colonne technique, renommer un champ ou définir un type de données. Vérifiez immédiatement le résultat dans l'aperçu.
2. Activez la barre de formule
   Dans l'onglet Affichage, activez la barre de formule si elle n'apparaît pas. Cliquez ensuite sur une étape dans le volet de droite : l'expression M correspondant à cette étape devient visible et modifiable.
3. Ouvrez l'Éditeur avancé
   Choisissez Éditeur avancé pour voir la requête complète. Vous y trouverez en général une structure commençant par let et terminant par in. Modifiez une seule partie à la fois et validez.
4. Testez avant de charger
   Contrôlez les types, le nombre de lignes, les erreurs et les valeurs nulles. Terminez par Fermer et appliquer pour charger les données dans le modèle Power BI.

Lire la syntaxe M sans se perdre

Une requête M est une succession d'étapes nommées. Chaque étape reçoit généralement le résultat de la précédente, séparée par une virgule. La dernière étape, indiquée après in, est celle renvoyée par la requête. M est sensible à la casse : Table.SelectRows n'est pas équivalent à table.selectrows.

Voici le squelette typique d'une importation CSV : let Source = Csv.Document(File.Contents("C:\\data\\ventes.csv"), [Delimiter=";", Encoding=65001]), EnTetes = Table.PromoteHeaders(Source, [PromoteAllScalars=true]), Types = Table.TransformColumnTypes(EnTetes, {{"Date", type date}, {"Montant", type number}}) in Types. Dans cet exemple, Source lit le fichier, EnTetes transforme la première ligne en noms de colonnes, puis Types affecte des types fiables. Le résultat final est l'étape Types.

Les noms d'étapes générés automatiquement, tels que #"Lignes filtrées", sont valides mais peu pratiques à relire. Renommez-les sobrement : Source, FiltreDates, ColonnesUtiles, Types. Cette convention rend le code plus facile à diagnostiquer, particulièrement quand plusieurs personnes entretiennent le rapport.

Les transformations M les plus utiles au quotidien

Les requêtes les plus robustes combinent quelques opérations simples, dans un ordre réfléchi. Commencez par conserver les colonnes nécessaires et filtrer les lignes inutiles, puis standardisez les libellés et appliquez les types. Une table étroite et propre est plus légère à transférer, à actualiser et à charger dans le modèle.

1. Filtrer sans supprimer les données à l'aveugle
   Utilisez Table.SelectRows pour ne garder que les lignes pertinentes. Par exemple : Table.SelectRows(Source, each [Statut] = "Validé" and [Montant] <> null). Contrôlez les majuscules, espaces et valeurs nulles : un filtre trop strict peut éliminer des lignes valides.
2. Convertir explicitement les types
   Employez Table.TransformColumnTypes pour déclarer dates, nombres, textes et booléens. Ne vous fiez pas uniquement à la détection automatique, surtout avec des fichiers dont le format varie. Pour des montants utilisant virgule ou point selon le pays, choisissez aussi la locale appropriée dans l'interface.
3. Créer une colonne calculée de préparation
   Utilisez Table.AddColumn pour enrichir une table avant le modèle, par exemple Table.AddColumn(Source, "Mois", each Date.StartOfMonth([Date]), type date). Gardez en M les attributs stables de préparation ; conservez les agrégations dépendantes des filtres pour DAX.
4. Fusionner ou ajouter des tables selon le bon besoin
   Une fusion, via les fonctions Table.NestedJoin ou l'outil Fusionner, rapproche des colonnes sur une clé commune. Un ajout, via Table.Combine ou l'outil Ajouter, empile des lignes de structure comparable. Vérifiez toujours l'unicité de la clé avant une fusion : une relation un-à-plusieurs imprévue duplique des lignes.

Pour rendre un import tolérant à de petites variations de fichiers, vous pouvez sélectionner les colonnes attendues en prévoyant les absentes : Table.SelectColumns(Source, {"Date", "Client", "Montant"}, MissingField.UseNull). La colonne manquante sera créée avec des valeurs nulles plutôt que de bloquer l'actualisation. Cette souplesse ne dispense pas d'alerter le propriétaire de la source : une colonne absente peut révéler une rupture métier.

Paramètres et fonctions : rendre vos requêtes réutilisables

Le vrai gain du code M apparaît lorsque plusieurs requêtes reposent sur la même logique. Les paramètres évitent de répéter un chemin de dossier, une date de début, une URL d'environnement ou un nom de serveur. Créez-les depuis Gérer les paramètres, puis référencez-les dans le code, par exemple Folder.Files(pDossier). Lors d'un changement d'environnement, une valeur unique est à modifier au lieu de dizaines de requêtes.

Une fonction personnalisée encapsule un traitement réutilisable. C'est particulièrement utile pour nettoyer chaque fichier d'un dossier, appeler une API page par page ou appliquer la même normalisation à plusieurs tables. Une fonction reçoit des arguments et retourne un résultat ; son appel peut être ajouté à une colonne ou invoqué par une autre requête. Avant de la généraliser, testez-la sur un fichier représentatif et sur un cas incomplet.

Organiser un projet Power Query maintenable

Séparez les requêtes de staging, qui se connectent et nettoient une source, des requêtes finales chargées dans le modèle. Désactivez le chargement des requêtes intermédiaires lorsque leur rôle est uniquement technique. Nommez clairement les objets, documentez une règle métier complexe dans le nom d'étape ou une note interne, et évitez de copier-coller le même bloc de code dans plusieurs requêtes : créez une référence, un paramètre ou une fonction.

Performance, actualisation et dépannage : les règles qui comptent

Avec une base SQL, Power Query peut parfois traduire les étapes M en requête native exécutée directement par la source : c'est le query folding. Lorsque cela est possible, filtrer un historique de plusieurs années à la source plutôt que rapatrier toutes les lignes dans Power BI peut faire une différence majeure de temps d'actualisation et de charge réseau. Selon le connecteur et l'étape, ce mécanisme n'est toutefois pas garanti.

• Filtrez les dates et conservez les colonnes utiles aussi tôt que possible, surtout sur les sources relationnelles volumineuses.
• Vérifiez, lorsque l'option est disponible pour le connecteur, si l'affichage de la requête native reste accessible après vos transformations : sa disparition peut signaler une rupture du folding.
• Évitez d'utiliser Table.Buffer comme remède réflexe. Il peut consommer beaucoup de mémoire et empêcher le traitement côté source ; ne l'employez qu'après mesure et pour un besoin précis.
• Pour l'actualisation incrémentielle, appliquez un filtre de date compatible avec RangeStart et RangeEnd dès la requête de la table concernée, et préservez autant que possible son exécution à la source.
• Dans Power BI Service, vérifiez séparément les identifiants, les niveaux de confidentialité et, pour une source locale, la configuration de la passerelle.

En cas d'erreur, isolez l'étape qui échoue en cliquant successivement sur les étapes appliquées. Les messages d'erreur M indiquent souvent une colonne absente, une conversion impossible, une référence mal orthographiée ou une virgule oubliée. Ne corrigez pas uniquement le symptôme : inspectez quelques lignes de la source et demandez-vous si son schéma, son encodage ou sa règle métier a changé. Les outils de diagnostic de Power Query peuvent aussi aider à repérer une étape particulièrement lente.