Power Query :
un modèle propre et documenté
Une fois que la structure du modèle est définie (tables, structure des tables, relations entre elles), vient le moment de passer à Power Query et à l’import des données.
C’est une étape clé :
- Où placer les transformations,
- Comment organiser les requêtes,
- Quoi charger dans le modèle,
- Comment documenter le travail.
Ces choix ont un impact direct sur la performance du modèle, sa lisibilité et sa maintenabilité.
1. Remonter les transformations le plus haut possible
Premier réflexe : remonter les transformations de données le plus haut possible dans l’architecture de données.
Ce “plus haut possible” dépend du contexte :
- Pour un modèle simple, cela peut rester dans Power Query,
- Pour des architectures plus complètes, il est souvent préférable de transformer directement dans : un entrepôt de données, des tables SQL, un Lakehouse, BigQuery, Snowflake, etc.
L’idée est de centraliser les règles de gestion et d’éviter de dupliquer des transformations dans plusieurs rapports.
1.1. Privilégier les sources cloud
Dans la mesure du possible, il est recommandé de privilégier des sources cloud afin d’éviter d’avoir à ajouter une passerelle de données à l’architecture.
La mise en place d’une passerelle n’est pas forcément complexe, mais s’en passer simplifie l’architecture, l’administration et la maintenance à long terme.
1.2. Mieux gérer les fichiers Excel
Pour les fichiers Excel, il est préférable de les stocker sur SharePoint ou dans un autre espace partagé cloud plutôt que dans des dossiers sur un serveur interne, ou pire, en local sur un poste utilisateur !
Cela facilite l’accès, la gouvernance et la pérennité des connexions.
2. Limiter le nombre de requêtes et structurer Power Query
Power Query peut rapidement devenir difficile à gérer si le nombre de requêtes explose et si aucune organisation n’est mise en place.
2.1. Préférer des fonctions M au connecteur “Dossier”
Un point important concerne l’utilisation du connecteur Dossier.
Dans un projet concret, un modèle basé sur ce connecteur comptait près d’une centaine de requêtes. En remplaçant ce fonctionnement par des requêtes personnalisées en M (fonctions réutilisables), le nombre de requêtes est descendu sous la barre des 50.
Moins de requêtes, c’est un Power Query plus lisible et un modèle plus simple à maintenir.
2.2. Classer les requêtes par rôle
Pour garder une vision claire du modèle, il est utile de classer les requêtes en plusieurs groupes, par exemple :
- Paramètres,
- Faits,
- Dimensions,
- Autres requêtes,
Ce classement est d’autant plus important qu’il n’existe pas de champ de recherche dans Power Query. Dès qu’un modèle compte plusieurs dizaines de tables, la navigation devient vite compliquée si rien n’est organisé.
2.3. Ne charger que ce qui est utile au modèle
Autre point clé : ne charger dans le modèle que ce qui est effectivement utilisé.
En pratique :
- Les tables qui ont une relation dans le modèle sont prioritaires,
- Les requêtes intermédiaires, utilisées uniquement pour alimenter d’autres requêtes, n’ont généralement pas besoin d’être chargées.
Cela évite d’alourdir le modèle pour rien et améliore la lisibilité côté modèle.
3. Renommer et documenter les étapes
Renommer et documenter les étapes dans Power Query est un réflexe essentiel.
Sans cela, la seule façon de comprendre une requête consiste à cliquer sur chaque étape pour voir ce qui s’y passe. Sur un petit modèle, cela reste acceptable. Dès que le volume de données augmente, les temps de recalcul rendent cet exercice très long… et très pénible.
Renommer et commenter les étapes permet :
- De lire la logique de la requête sans l’exécuter intégralement,
- De comprendre plus rapidement l’enchaînement des transformations,
- De faciliter la reprise par une autre personne,
- Et de se rappeler, après quelques semaines, le “pourquoi” de telle ou telle étape.
Cette documentation n’est pas un luxe : elle fait gagner du temps à tout le monde, y compris à la personne qui a construit le modèle.
4. Bien typer les données (et gérer date / heure)
Le typage des données est un point fondamental.
Quelques principes simples :
- Une colonne de date doit être typée en date,
- Une colonne d’heure doit être typée en heure,
- Il est préférable d’éviter de mélanger différents formats dans une même colonne (Attention aux erreurs !).
4.1. Séparer date et heure
Sur ce sujet, un cas particulier mérite d’être mentionné : les colonnes qui contiennent à la fois date et heure.
Plutôt que de stocker ces valeurs dans une seule colonne (avec une très forte cardinalité), il est souvent plus pertinent de :
- Dissocier la date pour la relier à la table Calendrier,
- Dissocier l’heure pour la relier à une table des heures du modèle (cas plus rare, mais utile lorsque l’analyse se fait à une maille très fine).
Cette approche améliore la lisibilité et peut avoir un impact positif sur la performance.
5. Créer les relations… puis des vues du modèle
Une fois les données chargées et nettoyées, vient l’étape de création des relations dans le modèle.
Les relations de type 1 à plusieurs sont à privilégier (comme évoqué dans les articles précédents). Elles constituent la base d’un modèle robuste et prévisible.
5.1. Travailler avec des vues plutôt qu’avec “Toutes les tables”
La vue “Toutes les tables” reste acceptable sur un petit modèle à 5 tables. À 50 tables, c’est une autre histoire.
Il est donc recommandé de :
- Créer au minimum une vue par table de faits,
- Organiser ces vues pour faciliter la compréhension du modèle par les utilisateurs, y compris non techniques.
Ces vues aident notamment à comprendre :
- Pourquoi certaines données ne se filtrent pas correctement,
- Pourquoi un axe ne semble pas lié à un indicateur.
La réponse est souvent liée aux relations :
- Une relation manquante,
- Une relation incorrecte,
- Une clé absente,
- Ou une structure qui nécessite encore du travail.
En résumé
Pour garder un modèle propre et documenté, il est important de :
- Remonter les transformations de données le plus haut possible dans l’architecture,
- Privilégier les sources cloud pour simplifier l’architecture,
- Stocker les fichiers Excel dans des emplacements partagés comme SharePoint,
- Limiter le nombre de requêtes en remplaçant le connecteur Dossier par des fonctions M lorsque c’est pertinent,
- Classer les requêtes (paramètres, faits, dimensions, autres requêtes),
- Ne charger dans le modèle que ce qui est réellement utilisé,
- Renommer et documenter les étapes,
- Bien typer les données et, si nécessaire, séparer date et heure,
- Créer les relations puis des vues de modèle adaptées, notamment une vue par table de faits.
🗓️ Prochain article : « DAX : mesures fiables et contrôles intelligents »
Nous passerons au DAX, le langage qui donne vie au modèle. Nous verrons pourquoi ses résultats ne se comportent pas comme dans Excel, comment interpréter les totaux, comment tester ses mesures et s’assurer qu’elles se comportent correctement selon les axes d’analyse.
Nous aborderons également les bonnes pratiques pour documenter ses indicateurs, contrôler leur fiabilité et poser les bases d’un modèle analytique robuste. Le DAX est au cœur du Self-Service BI : bien le comprendre, c’est garantir des analyses fiables, cohérentes… et beaucoup plus simples à maintenir.
🔗 Retrouvez la série facilement via le tag : SelfServiceBI