Les outils externes - Leur rôle dans la documentation - Partie 2

Table des matières

Les outils externes - Leur rôle dans la documentation - partie 2
  1. Measure Killer
  2. PowerOps
        2.1 Documentation des signets
  3. TMDL Explorer
  4. SQL Server Profiler
  Récapitulatif rapide

Si vous êtes responsable du développement Power BI et que la documentation est “votre territoire”, c’est vous qui faites bouger les choses. Il vous faut les bons outils pour garder tout cela propre, efficace et sous contrôle.

Un rappel de l’article précédent :

:exclamation: Quand nous finalisons la documentation, nous documentons l’excellence.

Pour y parvenir, nous avons besoin des bons :

• États d’esprit
• Connaissances
• Outils
• Approches

Cet ordre est intentionnel. Le principal moteur est l’état d’esprit, associé à la connaissance métier et aux besoins. Si les discussions techniques sur les méthodes et les outils ont de la valeur, les organisations suivent invariablement une hiérarchie MÉTIER - PROCESSUS - PERSONNES. Les besoins métier créent le socle des processus, et ce n’est qu’ensuite que les personnes ont besoin d’outils et d’actions pour les soutenir.

Cette semaine, nous poursuivons notre discussion sur le rôle des outils externes dans la documentation. Nous allons passer en revue d’autres outils externes à notre disposition, examiner diverses options et explorer comment les exploiter pour créer non seulement des rapports plus soignés, mais aussi enrichir la documentation visuelle, ou simplement évaluer notre progression actuelle.

[!Warning] Un mot de prudence : n’attendez pas une liste exhaustive de tous les outils disponibles — il en existe bien d’autres, à l’intérieur comme à l’extérieur de l’écosystème Microsoft. Je n’ai aucune allégeance, aucun lien d’intérêt. Les opinions exprimées sont entièrement les miennes. Ce que je partage, ce sont des observations pratiques tirées de mon expérience de terrain, en me concentrant délibérément sur une sélection très ciblée d’outils.

Avant d’entrer dans le vif du sujet, je dois insister sur la règle d’or : le processus est roi ! Aucun outil ne fait de miracle sans un processus solide derrière lui.

Soyons honnêtes : attendre des développeurs qu’ils maintiennent la documentation par simple bonne volonté est tout simplement irréaliste. Il nous faut des processus solides et bien définis.

Des processus solides : le gendarme de la documentation

Un exemple type de processus imposant la documentation est le processus de revue de code. Il s’inscrit généralement dans un flux plus large de CI/CD (Intégration Continue/Déploiement Continu) déclenché par des Pull Requests. C’est là que la documentation passe du statut de “bonus” à celui d’exigence critique.

Pas de documentation ? Adieu la mise en prod. Simple et non négociable.

:exclamation: Ce n’est pas personnel, c’est strictement professionnel

Ceci étant clarifié, faisons connaissance avec notre “équipe”.

1. Measure Killer

Cet outil externe ne négocie pas - il élimine ! Et quelle est sa cible ? La menace pour Power BI, c’est l’encombrement des données (Data Clutter).

Dans le monde de Power BI, l’encombrement est l’un des principaux ennemis. Il est toujours là, guettant l’occasion de s’infiltrer dans les projets.

Les éléments inutiles ont toujours tendance à s’immiscer dans le modèle sémantique, et progressivement :

• Ralentissent les performances du rapport
• Compliquent le processus de développement
• Rendent les modèles sémantiques difficiles à comprendre
• Créent un effet boule de neige de complexité

Sans une main ferme pour le contrôler, cet encombrement peut transformer votre projet autrefois efficace en un cauchemar qui finit par vous coûter de l’argent.

Pourquoi Measure Killer ?

Measure Killer aide à garder votre environnement Power BI propre et efficace. Son objectif principal est d’identifier et de supprimer les mesures, colonnes et tables inutiles de votre modèle sémantique.

Lors des revues de code, ne conserver que les éléments essentiels dans votre modèle est une exigence clé. Ceci est particulièrement important pour les jeux de données en self-service, car supprimer des éléments inutilisés devient bien plus difficile une fois que des rapports ont été construits sur votre dataset.

Si la version gratuite de Measure Killer offre des capacités de nettoyage fondamentales, leur version payante propose des fonctionnalités avancées répondant, entre autres, aux défis évoqués précédemment. Measure Killer | Brunner BI

Un exemple d’audit “Measure Killer”.

Une autre fonctionnalité que j’apprécie est l’intégration et la méthodologie de notation construite au-dessus du Best Practice Analyzer.
Veillez à ce que vos rapports évitent la classification “rouge sang” de “criminel Power BI” ! ;)

[!NOTE] L’un des principaux atouts de Measure Killer est sa capacité à repérer les incohérences et les éléments inutilisés dans votre rapport Power BI. Cela en fait un excellent outil pour gérer efficacement votre travail. La version premium étend ces capacités à l’ensemble de votre environnement Power BI Service.

2. PowerOps

Aperçu de l’outil externe Powerops

En savoir plus - Je recommande la lecture de l’article suivant pour un aperçu plus approfondi : Meet Powerops - Your New Best Power BI “External Friend”! - Data Mozart

Cet outil fonctionne comme votre “agent de renseignement”. Imaginez hériter d’un rapport sans aucune documentation et devoir comprendre rapidement tout son écosystème. C’est là que PowerOps devient votre arme secrète. Il vous aide à trouver visuellement et intuitivement l’information que vous recherchez.

[!TIP] À mon sens, cet outil externe est excellent pour enrichir visuellement votre documentation. En intégrant des analyses visuelles bien conçues en complément du texte, vous améliorez la lisibilité de la documentation en rendant les éléments clés plus visibles et mémorables, facilitant ainsi une référence future plus rapide.

Considérez les tâches suivantes :

• Visualiser les dépendances de mesures : découvrez les schémas de ramification des mesures et les relations mesure-colonne

[!Warning] La ramification de mesures est une stratégie puissante pour décomposer des calculs complexes en parties plus petites et réutilisables. Elle améliore généralement la lisibilité et la maintenabilité, mais poussée à l’extrême, elle peut devenir un labyrinthe de dépendances difficile à dépanner et à optimiser.

Il n’existe pas de règle “officielle” de Microsoft ou de la communauté fixant une limite stricte. Une recommandation courante est de limiter la ramification à un maximum de 2 à 3 niveaux de profondeur. Au-delà, vous risquez de la confusion et une surcharge de performance si les mesures sont fortement imbriquées.

Pourquoi rester modeste :

1. Performance : chaque référence à une mesure peut ajouter une surcharge, en particulier dans des modèles complexes ou volumineux.
2. Lisibilité : des références de mesures profondément imbriquées deviennent difficiles à suivre pour d’autres développeurs (et même pour vous-même, des mois plus tard).
3. Débogage et optimisation : tracer un problème à travers plusieurs couches de mesures prend du temps.
   
   

[!TIP] Recommandations :

• Regroupez la logique commune dans des “mesures de base” utilisées à répétition (par ex. “Ventes de base”, “Coûts de base”, etc.).
• Construisez une deuxième couche de mesures effectuant des transformations simples sur ces mesures de base (par ex. Cumul annuel, Cumul mensuel, Taux de croissance, etc.). Envisagez de créer des groupes de calcul si le schéma est souvent utilisé. Réservez une troisième couche uniquement aux scénarios exceptionnels.

Exemple de ramification de mesures plus complexe

• Tracer l’utilisation des mesures : identifiez quelles mesures alimentent chaque graphique ou page

• Comprendre les dépendances Power Query : visualisez facilement vos sources

  

• Comparaison aux bonnes pratiques : comparez automatiquement vos rapports aux standards du secteur

Cet outil intègre également le Best Practice Analyzer. Ce que j’apprécie dans cette expérience, c’est l’explication concise de la raison pour laquelle chaque règle constitue une bonne pratique.

• Vue d’ensemble complète :
  • Insights au niveau des pages
  • Visuels les plus fréquemment utilisés
  • Suivi des actions
  • Identification des visuels personnalisés

Ces vues offrent une richesse d’informations dans un format convivial.

• Analyse détaillée : vous permet d’inspecter chaque page — y compris les visuels masqués — pour comprendre la mise en page, les champs utilisés, les filtres appliqués, les mesures actives, les slicers synchronisés, et plus encore.
• Documentation approfondie : capture et intègre un large éventail de détails dans la documentation de votre rapport Power BI, servant de ressource excellente pour vérifier chaque composant.
• Gestion optimisée des éléments : vous aide à vérifier que tous les composants sont correctement renommés et que seuls les éléments essentiels sont conservés.
• Transparence de type tableau de bord : fournit une vue d’ensemble claire, de style tableau de bord, des composants sous-jacents de votre rapport, renforçant la transparence vis-à-vis des clients et démontrant votre approche méticuleuse, organisée et soignée.
  
  
• Signets : PowerOps accomplit ce que la plupart des outils ne peuvent pas, il aide à documenter les signets !

Discutons brièvement des signets Power BI pour mettre le contexte en place avant d’explorer comment PowerOps aide à la documentation des signets.

Documentation des signets

[!WARNING] Les signets sont le point faible des rapports Power BI. Bien qu’ils offrent une grande flexibilité pour la construction des rapports, ils posent des défis de documentation importants. Lorsque des problèmes surviennent, même mineurs, les signets nécessitent généralement une reconstruction complète plutôt que de simples corrections. Cela rend le transfert de connaissances et les passations particulièrement difficiles.

Pourquoi les signets sont-ils difficiles à documenter ?

1. Pas assez de métadonnées

Les signets capturent l’état visuel (c’est-à-dire les filtres, les slicers et les visuels sélectionnés) à un instant précis, mais ils ne stockent pas de métadonnées détaillées sur les raisons pour lesquelles certains réglages ont été choisis, les relations de données sous-jacentes, ou la logique métier derrière eux. De plus, il n’existe aucun moyen natif de rechercher parmi les signets pour trouver ceux qui contiennent des visuels ou réglages spécifiques.

2. Défis de maintenance :

Puisque les signets sont créés manuellement, tout changement dans le rapport (comme renommer des visuels, modifier des filtres, ou mettre à jour les modèles de données) peut rompre le contexte prévu du signet. Cela rend la maintenance continue chronophage et sujette aux erreurs, surtout si les tests sont manuels.

3. Nature statique vs données dynamiques :

Les signets ne capturent que des instantanés fixes. Lorsque vous travaillez avec des données changeantes, vous pouvez avoir besoin de contrôles plus dynamiques. Dans ces situations, vous pouvez rapidement rencontrer les limites des signets.

[!IMPORTANT] La direction prise par Microsoft :
Microsoft s’oriente de plus en plus vers une réduction de la dépendance aux signets, en introduisant des interactions visuelles améliorées et des fonctionnalités natives (comme les paramètres de champ et de meilleures options de filtrage) offrant des façons plus dynamiques et contextuelles de gérer les visuels. Cette évolution indique une préférence pour des fonctionnalités plus robustes et auto-documentées plutôt que les signets.

Quelles sont les meilleures pratiques pour documenter les signets aujourd’hui ?

1. Créez une page masquée dédiée dans votre rapport Power BI
   • Inventaire : listez chaque signet avec son nom, son objectif, et la page/les visuels spécifiques qu’il affecte.
   • Représentation visuelle : incluez des captures d’écran ou des miniatures de l’état du rapport représenté par chaque signet. Ce repère visuel aide les utilisateurs à comprendre rapidement le contexte de chaque signet.
2. Descriptions manuelles Puisque Power BI ne fournit pas de champ de description natif pour les signets, créez un tableau sur votre page de documentation où vous détaillez :
   • Objectif : ce que le signet est censé mettre en avant ou accomplir.
   • Composants affectés : quels visuels, filtres ou slicers sont concernés.
   • Scénarios d’utilisation : quand et pourquoi un utilisateur devrait sélectionner ce signet (par ex. “Utilisé pour le résumé de fin de mois” ou “Focus sur la répartition par catégorie de produit”).
     
     

[!IMPORTANT] Inclure les signets dans votre documentation est crucial, car cela sert de ressource de formation pour les nouveaux membres de l’équipe et de matériel de passation. Cela réduit la dépendance envers les créateurs d’origine et maintient la cohérence dans le temps.

[!TIP]

• N’utilisez pas trop de signets Restez simple, avec un maximum de 5 à 10 signets essentiels par rapport. Trop de signets rendent votre rapport difficile à maintenir.
• Choisissez les signets avec soin N’utilisez les signets que pour la navigation et la narration importantes. Regroupez-les et nommez-les de façon logique selon leur usage (comme “Vue d’ensemble” ou “Analyse détaillée”). Aussi, renommez et regroupez les éléments visuels sur votre page - cela facilite la sélection lors de la création des signets. Par exemple, regrouper 10 visuels liés en un seul groupe nommé vous permet de tous les sélectionner en une fois plutôt qu’individuellement.
• Faites le ménage régulièrement Vérifiez vos signets souvent. Supprimez ceux que vous n’utilisez pas beaucoup ou qui pourraient être créés différemment à mesure que de nouvelles fonctionnalités apparaissent. Cela rend votre rapport plus simple et plus facile à tester.

Revenons maintenant à PowerOps et voyons comment il nous aide à documenter les signets : J’ai créé trois signets dans le fichier de démonstration.

Le 1er signet est simple, il impacte tous les visuels de la page et leurs données sous-jacentes.

Le 2e signet est un peu plus complexe. Un seul slicer visuel est impacté par le visuel sélectionné. Limite actuelle de l’interface : à quoi sert le visuel sélectionné pour le deuxième signet ?

Le 3e signet est ce que j’appelle “le cauchemar de la documentation”. Plusieurs visuels sont impactés par le signet, les données ne sont pas cochées, les éléments de sélection ne sont ni renommés ni regroupés de manière intuitive.

PowerOps offre une vue très utile où l’on peut voir les réglages choisis. C’est la même information que celle que l’on obtiendrait en vérifiant les signets individuels dans Power BI, mais dans un format que l’on peut facilement capturer ou exporter.

export excel

Ce que nous ne pouvons pas trouver, c’est l’information sur les visuels sélectionnés dans les signets. Les outils externes comme PowerOps peuvent aider à documenter certains aspects des signets, mais ils ne peuvent toujours pas compenser pleinement l’absence de métadonnées de signets consultables dans Power BI, en particulier concernant les visuels sélectionnés dans chaque signet. Cette limitation renforce l’importance d’une documentation adéquate.

[!NOTE] La plus grande force de PowerOps, à mon avis, réside dans son interface épurée et ses synthèses d’insights visuellement engageantes qui s’intègrent parfaitement à la documentation. Combiner des images pertinentes avec du texte contextuel suit la bonne pratique du “Show and Tell” employée dans les rapports Power BI (le data storytelling). Cela améliore considérablement la valeur globale de la documentation.

3. TMDL Explorer

Il s’agit d’une application innovante, la première que j’ai découverte à exploiter TMDL. À mesure que le potentiel de TMDL continue d’être révélé et que la communauté partage de nouveaux cas d’usage pratiques, nous pouvons nous attendre à un éventail croissant d’outils conçus pour nous aider à visualiser les relations entre données et/ou créer des scripts qui accélèrent le développement Power BI. Nous en sommes encore aux débuts, donc la marge pour de nouveaux outils innovants est immense.

TMDL Explorer permet de :

• Visualiser les connexions entre les mesures dans votre modèle sémantique
• Identifier facilement les dépendances amont et aval

Comment l’utiliser

1. Allez dans votre vue TMDL
2. Copiez le TMDL de la table dans le presse-papiers
3. Collez-le dans l’application
4. Explorez vos mesures

Publication source sur LinkedIn

4. Visualiser le rafraîchissement du modèle - SQL Server Profiler

Vous êtes-vous déjà demandé pourquoi le rafraîchissement d’un jeu de données Power BI prend autant de temps ? Phil Seamark présente une méthode pour capturer les événements pendant un rafraîchissement Power BI et transformer ces données en rapports visuels illustrant ces événements.

Dans son article Visualise your Power BI Refresh, Phil fournit des détails complets. Voici ci-dessous un aperçu condensé mettant en avant les étapes clés et la valeur documentaire de ce résultat. Pour une compréhension plus approfondie de l’interprétation des graphiques, je recommande de lire l’article complet de Phil.

Vue d’ensemble du processus :

1. Lancer les traces

Commencez par initier les traces pour capturer les événements.

2. Déclencher le rafraîchissement du modèle sémantique et enregistrer le fichier XML

Lancez le processus de rafraîchissement et enregistrez les traces obtenues.

Enregistrez le fichier de trace

3. Mettre à jour les paramètres

Utilisez le fichier Power BI PBIX fourni (développé par Phil Seamark) et mettez à jour les paramètres.

4. Les résultats

Visualisez et documentez le rafraîchissement du modèle

Pourquoi visualiser et documenter le rafraîchissement du modèle ?

• Transparence et clarté :
  Lorsque vous pouvez voir le processus de rafraîchissement, il est plus facile de comprendre comment les différentes sources de données fonctionnent ensemble. Ajouter cela à votre documentation aide toutes les parties concernées à comprendre comment les données se déplacent et dépendent les unes des autres.

• Dépannage et optimisation :
  Les visuels facilitent le repérage des points de ralentissement ou de rupture. Quand quelque chose ne fonctionne pas, disposer de ces diagrammes vous aide à trouver rapidement la zone du problème, ce qui fait gagner beaucoup de temps lors de la correction.

• Transfert de connaissances et intégration :
  De bons documents sur le processus de rafraîchissement sont très utiles lorsque de nouvelles personnes rejoignent l’équipe ou lors de la passation de projets à quelqu’un d’autre.

• Suivi des performances :
  Disposer de documents sur votre processus de rafraîchissement vous permet de suivre son évolution dans le temps.

• Communication avec les parties prenantes :
  Cela aide les personnes non techniques à comprendre comment fonctionnent les mises à jour de données, ce qui renforce leur confiance envers vos rapports.

• Audit et conformité :
  Des schémas visuels détaillés de votre processus de rafraîchissement aident à répondre aux exigences de conformité et à créer des pistes d’audit. Ils rendent chaque étape transparente pour toute revue nécessaire.

Intégration avec la documentation Power BI :

Intégrer des diagrammes visuels de rafraîchissement du modèle dans votre documentation globale de projet s’aligne avec les bonnes pratiques en offrant une vue complète de votre solution Power BI. Cela complète la documentation sur les sources de données, les transformations et les visualisations, créant une image complète du flux de données de bout en bout. Cela améliore également la maintenabilité et l’évolutivité tout en posant les bases d’une amélioration continue.

Récapitulatif rapide

Dans le numéro #10, nous avons exploré divers outils qui non seulement améliorent votre travail, mais garantissent également la qualité de votre production. Nous avons discuté de leurs avantages, de ce qu’ils apportent, et de la meilleure façon de les exploiter. Cependant, je tiens à souligner à nouveau que ces outils ne remplacent pas une documentation appropriée, ils agissent comme des accélérateurs et des aides. Dans un sens plus large, ils font partie d’un processus porté par un besoin réel.

💬 Discutons-en :

Quel est votre outil de prédilection pour la documentation Power BI ? Quel a été le plus grand défi auquel vous avez été confronté pour maintenir des rapports bien documentés ? Partagez vos réflexions dans la publication LinkedIn : nous aimerions poursuivre la discussion ! Publication LinkedIn : #Issue 10 - External Tools - Their Role in Documentation - Part 2