Erreurs à éviter
avec Power BI

1 - Tomber dans la facilité.

S’il est très facile d’arriver rapidement à un résultat intéressant dans Power BI, sans trop de formation, il est beaucoup plus difficile de construire des rapports pertinents, faciles à utiliser et faciles à mettre à jour, sans maîtriser la philosophie de la solution. La plupart des débutants qui font une première expérience avec le logiciel réussissent à créer une petite visualisation simple. Ils croient alors que créer un rapport sera aussi simple que de reproduire plusieurs fois ce petit travail. C’est là une très grande erreur ! Pour construire un rapport en lien avec les besoins de l’entreprise, l’usager devra passer à travers les étapes suivantes :

• Apprendre à mieux connaître ses sources de données

• Comprendre la normalisation de données

• Apprendre à créer des requêtes performantes sur différentes sources de données

• Apprendre à transformer adéquatement les données sources pour le besoin de reporting

• Apprendre le langage M et la création de fonctions pour optimiser la transformation de données

• Apprendre à créer des modèles de données performants

• Apprendre à créer des mesures en DAX

• Apprendre à créer des visualisations percutantes

• Apprendre à exploiter les fonctionnalités de la plateforme de partage retenue (Power BI Service ou Power BI Report Server)

Autrement dit, il y a de nombreux concepts à maîtriser avant de passer de nombreuses données sources à la création d’un rapport Power BI efficace.

2 - Ne pas faire la différence entre Power BI Desktop et Power BI Service

Power BI Desktop est l’application de bureau qui permet de créer les rapports. Plus précisément, c’est l’application qui permet de créer les requêtes de connexion aux données et les requêtes de transformation des données, de modéliser les données (créer les relations entre les tables), de créer les mesures (valeurs à analyser) et de créer les visualisations de données (pages de rapport).

Beaucoup de débutants s’arrêtent là et partagent directement avec leurs collègues les fichiers issus de Power BI Desktop, c'est à dire des fichiers .pbix. Ce faisant, ces utilisateurs ignorent complètement une partie essentielle de la solution, c'est à dire celle où l’on publie le rapport .pbix sur le service web powerbi.com ou sur le report server (localement). En ne publiant pas le fichier, voici les inconvénients rencontrés ou les opportunités ratées :

• Le fichier .pbix n’est pas sécurisé donc n’importe quel usager peut venir changer les requêtes, les transformations de données, la modélisation, les mesures, les visualisations, les pages, etc. Tout peut être modifié par quiconque a accès au fichier

• Tout le monde consulte le même fichier, en même temps

• Les requêtes et le modèle ne sont pas centralisés. Ils ne peuvent donc pas être réutilisés pour créer d’autres rapports basés sur les mêmes données

• Il est impossible d’ajouter des règles de sécurité par ligne, des règles de partage, des règles de mise à jour des données, etc.

• Tous les usagers verront l’ensemble des données (même s’ils n’ont pas normalement accès, puisque les informations de connexion utilisées seront celles du créateur du rapport)

• Un usager qui n’a normalement pas accès aux données sources ou qui y a accès via un chemin d’accès différent ne pourra pas mettre à jour le fichier sans le briser

• Il est impossible de profiter des nombreuses options du service comme la création de tableaux de bord, la création d’alertes courriels basées sur des valeurs atteintes, les algorithmes d’analyse des jeux de données, la possibilité d’analyser le rapport via Excel, etc.

Pour toutes ces raisons, il devient évident que le fichier .pbix doit être publié sur le service (Power BI Service) ou sur le serveur (Power BI Report Server).

À l’inverse, d'autres débutants utilisent uniquement Power BI Service sans être au courant de l’existence de l’application de bureau Power BI Desktop. En effet, à partir du service, il est également possible de se connecter directement à des données sources. Toutefois, ce faisant, voici les opportunités manquées :

• Il est impossible de créer des transformations de données

• Il est impossible de croiser les sources de données

• Il est impossible de créer des modèles de données

• Il est impossible de créer des mesures en DAX

Pour toutes ces raisons, le débutant en Power BI doit connaître la solution Power BI dans son ensemble et non seulement une portion isolée de la solution, pour être en mesure d’en tirer pleinement profit.

3 - Ne pas tirer partie de la puissance de modélisation des données dans Power BI Desktop

La plupart des débutants ne travaillent qu’avec une seule table de données au lieu de construire un modèle de données à plusieurs tables, préférablement en étoile, ou un dérivé, dans lequel seront présents des tables de faits et des tables de dimension. 

Les tables de faits regroupent des données qui bougent avec le temps, avec souvent des doublons, sur lesquelles seront effectuer les opérations d’agrégation et les mesures calculées (ex : les ventes de produits).

Les tables de dimensions regroupent des données figées comportant des valeurs distinctes principalement sans doublon (ex : les produits).

Le logiciel Power BI Desktop sera alors capable de relier automatiquement les tables du modèle pour peu qu'il repère les colonnes communes si celles-ci se nomment de la même façon dans toutes les tables (ex : id_produit dans la table de faits ventes et également id_produit dans la table de dimension produits).

4 - Ne pas normaliser les données

Dans le même ordre d’idée, les débutants ignorent très souvent l’existence des règles de normalisation de données, ce qui donne lieu à des problèmes de mise à jour de fichiers, qui deviennent vite impossibles à gérer. Par exemple, un débutant va souvent utiliser une source de données construite comme un tableau, avec par exemple des colonnes distinctes pour les différentes années de ventes, au lieu d'utiliser une source sous forme de vraie table de données avec une seule et unique colonne regroupant toutes les dates de ventes journalières qui seront regroupées ensuite par le logiciel en mois, trimestres ou années, soit automatiquement, soit par l'intermédiaire de mesures. Il faudra donc savoir dépivoter des colonnes avec Power Query notamment, et créer des mesures avec DAX.

5 - Tenter de travailler comme dans Excel

Les débutants Power BI qui sont habitués à travailler avec Excel ont du mal à repenser leur façon de travailler, et à passer du mode cellulaire au mode tabulaire. Ce faisant, ils répètent l’approche Excel et ce n’est pas souhaitable. Comme avec le suremploi de la fonction RECHERCHEV dans Excel (qui permet de relier les tables de fait aux tables de dimension par ajout incessant de colonnes), ils vont par exemple penser d’abord à résoudre une problématique par l’ajout de colonnes calculées, que ce soit dans l’éditeur de requêtes Power BI, via le langage M, ou directement dans le modèle de données, via le langage DAX. Cette approche devient vite laborieuse et entraîne souvent des problèmes de performance, tout comme dans Excel. Les usagers du tableur de Microsoft doivent donc se donner du temps pour repenser leur façon de travailler et se débarrasser de leurs réflexes Excel.

6 - Ne pas chercher à optimiser les requêtes

Les débutants en Power BI ont tendance à ne pas saisir complètement l’aspect “performance” des requêtes.  Ce faisant, lorsqu’ils écrivent des requêtes dans l’éditeur Power Query, ils ne cherchent pas à les optimiser, c'est à dire à réduire au minimum les étapes appliquées. Ils peuvent, par exemple, utiliser 10 étapes appliquées (et donc 10 lignes de code, ayant chacune sa lourdeur) pour effectuer une transformation de données qui pourrait être effectuée en une seule étape. Ceci constitue une grave erreur dans Power BI. S’il est vrai que plus l’éditeur de requêtes évolue, moins il devient essentiel de maîtriser le langage M, une connaissance de base minimum du langage M permettra d’améliorer significativement la performance des requêtes.

De même, il faut se questionner sur les sources de données auxquelles on se connecte :

Devrait-on se connecter en mode d’importation de données ? En mode de connexion directe ? Ou encore via les nouveaux modèles composites ? Devrait-on se connecter à la base de données complète ? À une vue ? Devrait-on rédiger une requête SQL dans la requête d’importation ?

Les débutants en Power BI ont tendance à ignorer ces questions et peuvent donc être confrontés à des problèmes de performance importants.

7 - Effectuer des transformations et des calculs dans la source de données

Les débutants en Power BI ne profitent pas assez de la flexibilité de l’éditeur de requêtes et du langage DAX. Ce faisant, ils apportent encore des changements manuels à leurs données sources, souvent avec Excel, avant de les importer dans Power BI, au lieu de laisser l’outil travailler pour eux et automatiser le processus à chaque mise à jour des données. Ceci est une erreur importante avec Power BI.

En effet, pour ajouter de l'information à des données existantes il y aura toujours 3 choix : 

1. Ajouter des colonnes à la source via Excel avant l'importation dans POWER BI, ce qui sera toujours la moins bonne solution. C'est celle qui alourdira le plus le traitement, à tous les niveaux, même en utilisant QUERY dans Excel.

2. Ajouter des colonnes via QUERY dans POWER BI à l'aide des fonctionnalités automatiques de l'onglet "Ajouter une colonne" pour ne pas avoir à utiliser M, mais c'est une solution, bien que meilleure que la première, qui alourdira aussi l'analyse puisque de toute façon on aura besoin au final de mesures DAX pour créer les visuels.

3. Et enfin, la meilleure des 3 qui est de faire le minimum nécessaire et indispensable dans et avec QUERY, et de se concentrer sur les mesures rapides ou manuelles avec DAX une fois les données chargées depuis QUERY. En effet, DAX permet de calculer une mesure directement sans qu'une colonne existe nécessairement et donc sans alourdir les tables, ce qui est le principe de CALCULATE, certainement une des formules DAX les plus intéressantes et les plus utilisées. Voir l'article Référence DAX sur Microsoft Docs.
   
   

8 - Ne pas saisir l’importance du contexte de filtres

Certains débutants ont bien compris l’importance de la normalisation de données et du langage DAX mais ne maîtrisent pas ce que l’on appelle le contexte de filtres des rapports. Voici un exemple : un analyste débutant a construit un rapport complet qui comparait les données de 2021 vs 2020. Ses données sources comprenaient bel et bien une colonne Année. Il avait donc bien normalisé ses données. Il avait aussi utilisé le langage DAX pour créer ses mesures, mais ne saisissant pas très bien le contexte de filtres, il a procédé de la façon suivante:

• Ventes 2020 = CALCULATE ([Ventes], Ventes[Année]=”2020″)

• Ventes 2021 = CALCULATE ([Ventes], Ventes[Année]=”2021″)

• Écart Ventes 2021-2021 = Ventes 2021 – Ventes 2020

Quel est le problème avec cette procédure ?

Et bien, quand est venu le mois de janvier 2022, le client, pris de panique, lui a passé un coup de fil: “Mais c’est l’enfer Power BI ! Tous nos rapports sont à refaire et comme c’est là, ils seront à refaire chaque année !”. N’ayant pas considéré le contexte de filtres et n’ayant pas profité des mesures de Time Intelligence en DAX, le client se trouvait effectivement dans un fichu pétrin. Il devait maintenant recréer toutes ses mesures pour 2022 et refaire ses visualisations. C’est une erreur très courante chez les débutants avec Power BI.

9 - Ne pas optimiser la performance

Power BI repose sur un engin qui compresse les données en colonnes. Ce faisant, il est primordial de normaliser les données. Il faudrait toujours viser à ce que les tables de faits ne possèdent que les valeurs à analyser et des clés pour créer des relations avec les tables de dimensions. Rien d’autre. Comme il est plus facile de compresser des nombres que du texte, et comme les tables de faits sont les tables les plus volumineuses d’un modèle de données, le respect de cette règle sera très profitable au niveau de la performance.

De même, les débutants ont tendance à importer beaucoup trop de données (trop de colonnes), comme s’il ne serait plus possible, par la suite, d’ajouter de nouvelles colonnes au modèle via Query ou DAX. Ceci a un effet direct sur la performance.

10 - Ne pas distinguer les tables de faits des tables de dimensions

Lorsque l’on construit un modèle de données dans Power BI, on devrait tendre vers un modèle en étoile, c’est-à-dire un modèle où la table de faits est au centre et les tables de dimensions sont tout autour.

La table de faits, est la table “transactionnelle”, qui contient les valeurs à analyser. Dans cette table, il devrait n’y avoir que les clés servant à créer des relations avec les tables de dimensions et les valeurs à analyser. Une fois les relations avec les tables de dimension créées, les colonnes comprenant les clés devraient être masquées. De même, une fois les mesures créées, les colonnes comprenant les valeurs à analyser devraient être masquées. Ce faisant, au final, on devrait ne retrouver que des mesures dans la table de faits.

Les tables de dimensions, quant à elles, devraient contenir toutes les informations concernant les axes d’analyse (toutes les informations par rapport aux clients, aux fournisseurs, aux produits, aux filiales, etc.).

Dans les modèles de base, on devrait ainsi avoir des relations “many-to-one” entre la table de faits et les tables de dimensions.

Bien sûr, dans la réalité, il est fort à parier que l’on doive insérer plus d’une table de faits dans le modèle de données. Ces tables de faits secondaires devront elles aussi être liées aux tables de dimensions du modèle de données. Parmi les erreurs courantes rencontrées chez les débutants, on peut noter :

La tentative de liaison directe entre deux tables de faits

• Par exemple, une table de dimensions de produits contiendra notamment une colonne avec le numéro de produit et une colonne avec le prix vendant de chaque produit et chaque produit n’apparaîtra dans cette table qu’une seule fois (aucun doublon)

• Mais si les prix des produits varient en fonction du mois ou de la saison, par exemple, les prix ne seront plus seulement fonction des produits mais aussi des dates. Ce faisant cette table ne sera plus une table de dimensions, elle deviendra une table de faits. Il faudra donc que l’usager en tienne compte dans la création de son modèle de données

La tentative de fusion de deux tables de faits

• Autre exemple, des débutants fusionnent deux tables de faits ensemble via l’éditeur de requêtes, par exemple, une table d’actuels et une table de budget. Toutefois, ils procédent à la fusion avec une jointure externe gauche. Ce faisant, tous les produits qui étaient prévus au budget et qui n’étaient pas présents dans les actuels n’étaient pas compris dans la table.

• Lorsqu’un usager fusionne des tables de faits ensemble, il doit être conscient de type de jointure qu’il utilise et des conséquences d’un mauvais choix de jointure.
  
  

11 - Ne pas comprendre le processus de publication des fichiers .pbix sur le cloud

D’abord, certains débutants ne connaissent pas l’existence du service web Power BI Service, qui fait partie intégrante de la solution Power BI. En effet, lorsque le fichier .pbix est prêt à être partagé, il est très fortement déconseillé de partager le fichier lui-même, pour toutes sortes de raisons évidentes, dont des raisons de sécurité. L’objectif est plutôt de publier le rapport sur le portail web PowerBI.com ou sur le Report Server (on premise / en local), où le rafraîchissement des données sera automatisé et la sécurité implantée. Quand le fichier .pbix est publié sur le service, tout le code est transféré et c’est donc à partir du service que le rapport est mis à jour.

Un cas classique est le suivant :

• L’usager a créé un rapport .pbix à partir de fichiers Excel, enregistrés dans un dossier quelconque (on-premise c'est à dire en local sur son disque dur)

• Il publie ensuite le rapport sur le service

• Afin de ne pas avoir à installer de passerelle de données, pour faire la mise à jour du rapport, l’usager décide de déplacer ses fichiers Excel sur OneDrive for Business

• Il ne modifie pas son fichier .pbix en conséquence

• Il se demande ensuite pourquoi son rapport sur le service n’est pas mis à jour lorsque les données évoluent dans les fichiers Excel

Ceci est une erreur fréquente. Le fait de déplacer les fichiers Excel sur OneDrive for Business ne change pas le code M, c'est à dire le code qui indique à Power BI comment se connecter aux données et où se trouvent ces données. Pour indiquer à Power BI que les fichiers ont changé d’endroit, il faut modifier le code en conséquence. Il faut maintenant indiquer que les fichiers doivent être récupérés non pas localement mais dans le cloud. Tant que cette information dans le code ne sera pas modifiée dans le .pbix et republiée dans le service, Power BI ne pourra pas deviner que vous avez changé l’emplacement des fichiers sources. 

Le code pour se connecter à un fichier Excel local ressemble à ceci :

Source = Excel.Workbook(File.Contents(“C:\Users\…”), null, true)

Alors que le code pour se connecter à un fichier sur OneDrive ressemble plutôt à ceci :

Source = SharePoint.Files(“https://…/”, [ApiVersion = 15])

12 - Ne pas avoir une bonne compréhension de la sécurité par ligne

Plusieurs débutants en Power BI créent plusieurs rapports (et donc plusieurs fichiers .pbix) à partir des mêmes données (en refaisant chaque fois le modèle de données), pour les partager avec différentes personnes, avec différents droits de lecture. Ceci devrait plutôt être contrôlé via le Row Level Security (RLS), c'est à dire la Sécurité au niveau des lignes.

13 - Ne pas avoir une bonne compréhension des tableaux de bord dans le service

Une fois le fichier .pbix publié sur le service, plusieurs débutants partagent ensuite l’espace de travail collaboratif avec tous les collègues qui doivent consommer ce rapport. L’objectif est plutôt de partager l’espace de travail collaboratif avec les usagers qui sont responsables de la mise à jour du rapport. Par la suite, il s’agira plutôt de créer une application (app) et de partager cette application avec tous les collègues devant avoir accès au rapport.

Cela dit, une fois que le fichier .pbix est publié dans le service, il est possible d’y ajouter un tableau de bord. Un tableau de bord comprend les tuiles les plus importantes d’un ou de plusieurs rapports. Toutefois, l’erreur fréquente des débutants est d’épingler dans le tableau de bord, des tuiles qui possèdent des filtres temporels. Par exemple, ils vont épingler une tuile qui montre les marges en dollars du mois de mars 2018. La tuile présente les marges et un filtre de dates est activé sur l’année et le mois. Il peut s’agir d’un filtre, dans le panneau de visualisations ou d’un filtre activé par des segments. Dans les deux cas, la tuile qui sera épinglée montrera toujours les marges du mois de mars 2018, même si on est rendu en avril 2018.

Pour éviter ce genre d’erreurs, il faut plutôt bénéficier du langage DAX pour définir une mesure qui va toujours calculer les marges du mois en cours ou du dernier mois (selon les besoins) et choisir cette tuile pour l’épingler au tableau de bord. Cette nuance est très importante à saisir et il faut bien le comprendre avant d’écrire toutes les mesures en DAX.

14 - Ne pas avoir une bonne compréhension de la réutilisation des modèles pour plusieurs rapports

L’objectif principal de Power BI est de pouvoir créer des modèles de données qui puissent être centralisés et réutilisés pour créer plusieurs rapports. On cherche ainsi à créer “une seule version de la vérité” et on ne veut donc pas dupliquer ni les efforts, ni les données. D’abord, il faut savoir que lorsqu’un rapport est partagé avec des collègues, on peut leur donner la possibilité de créer leurs propres rapports, basés sur le même modèle de données. Ces collègues n’auront pas accès à l’éditeur de requêtes ou à l’engin de modélisation de données. Ils ne pourront donc pas modifier le modèle de données. Ils pourront seulement se connecter au jeu de données, qui lui, est centralisé sur le service et maintenu par les administrateurs du rapport. Comme administrateur, vous pourrez aussi utiliser le service pour créer de nouveaux rapports basés sur le même modèle de données.

Mais vous pourrez aussi retourner dans Power BI Desktop, pour vous connecter à un modèle de données déjà publié sur le service. Vous serez alors connecté en connexion active (impossible de modifier le modèle de données). 

Source Académie Excel et Power BI.