Table des matières

Documentation : se concentrer sur les PROBLÈMES pour construire de meilleures solutions Power BI
  Pourquoi une documentation centrée sur le problème fonctionne
  Exemple : documentation Problème vs. Solution
          Documentation centrée sur la solution
          Documentation centrée sur le problème
  Suivre les principes de divulgation progressive
  Tests d’acceptation : valider votre solution
          1. Définir les critères d’acceptation
          2. Validation des données
          3. Validation des visuels et interactions
          4. Tests fonctionnels
          5. Tests des cas limites
          6. Documentation et validation finale
          7. Matrice RACI
  Quand les clients sautent l’étape du problème pour aller directement à la solution
          Pourquoi cette visualisation Gauge pose-t-elle problème ?
          De meilleures alternatives
  Cadre de documentation du problème
  Documentation et Design Thinking travaillent ensemble
  La documentation dans les environnements agiles
  Où stocker votre documentation pour les projets Power BI
  Conclusion

Documentation : se concentrer sur les PROBLÈMES pour construire de meilleures solutions Power BI

Une bonne documentation en Power BI et en analyse de données ne concerne pas seulement les livrables ou les objectifs finaux, c’est un outil qui aide les équipes à travailler ensemble et à construire de meilleures solutions. Lorsque nous nous concentrons d’abord sur la documentation du problème, tout le monde en profite.

Pourquoi une documentation centrée sur le problème fonctionne

Une documentation efficace commence par expliquer clairement le problème. Cela doit couvrir :

• Le contexte métier
• Les besoins des utilisateurs
• Les détails des données
• Le processus et les personnes impliquées
• Les raisons derrière les décisions

Pour plus de détails, lisez tous les articles et les exemples de Design Documents : « What content is in a Design Document ».

Cela garantit que tout le monde comprend et est aligné sur les mêmes objectifs, et peut prendre de meilleures décisions ensemble.

Exemple : documentation Problème vs. Solution

Documentation centrée sur la solution (moins efficace) : « Créer un rapport Power BI avec les ventes par région à l’aide d’un visuel de carte, avec un drill-through vers le détail des produits. »

En suivant ces instructions à la lettre, nous construirons une page de rapport présentant une seule carte affichant les ventes par région ou état, soit sous forme de bulles de taille variable, soit sous forme de carte choroplèthe. Chaque bulle ou état peut être cliqué pour effectuer un drill-through vers des informations détaillées au niveau produit.

Mais est-ce vraiment utile ?

En théorie, passer d’une vue agrégée à une vue détaillée est une bonne approche. Dans cet exemple précis, l’approche n’est pas très efficace car elle privilégie la fonctionnalité au détriment des véritables besoins métier et des problèmes réels.

Laissez-moi vous expliquer : peut-être que ce dont les utilisateurs ont réellement besoin, c’est de comprendre quels produits ont mieux ou moins bien performé que l’année dernière au sein de chaque région spécifique. En nous concentrant immédiatement sur « la solution », nous négligeons et oublions de discuter de ce qui est essentiel - le véritable besoin de l’utilisateur. Au lieu de discuter, de mieux comprendre, de brainstormer, de proposer et d’itérer sur des idées, nous sautons prématurément dans les aspects techniques du développement. Pensez à l’expérience utilisateur : est-il vraiment agréable pour les utilisateurs finaux de faire un drill-down puis de revenir en arrière à travers CHAQUE région juste pour identifier si des produits spécifiques performent bien ou mal ? Une carte affichant les ventes régionales via des tailles de bulles ou une carte choroplèthe communique seulement que certaines régions ont globalement plus de ventes que d’autres - une information qu’ils connaissent probablement déjà.

Documentation centrée sur le problème (plus efficace) : « Les responsables commerciaux ont besoin d’identifier rapidement les régions ou produits sous-performants et de comprendre quels produits affectent la performance régionale. Ils passent actuellement 4 heures par semaine à compiler ces informations à partir de diverses sources. »

Énoncer les questions auxquelles un rapport est censé répondre plutôt que la façon dont le rapport sera présenté donne la liberté de livrer la meilleure solution plutôt que de travailler dans le « tunnel » qui leur a été imposé. Les questions clés à poser sont : « À quelles questions le rapport est-il censé répondre ? » et « Quelle est la quantité minimale de données nécessaires pour répondre à ces questions ? »

Cela fournit des informations bien plus utiles et nous donne une plus grande flexibilité dans la conception, ainsi qu’une bonne base de discussion et d’affinement.

Par exemple, nous pouvons :

• Mélanger différentes granularités et créer des interactions dynamiques directement depuis la première page
• Afficher la carte à côté des ventes et de la performance des produits par rapport aux KPI
• Ajouter d’autres KPI généraux pertinents et le contexte souhaité
• Ajouter des paramètres de champ pour afficher dynamiquement différents types d’analyse sur la carte
• Ajouter des infobulles pour plus de contexte
• Inclure un bouton de bascule permettant aux utilisateurs de passer de la carte à une matrice stylisée montrant la répartition des produits par région
• Permettre aux utilisateurs finaux de définir leurs propres critères de mise en évidence et seuils pour ce qu’ils considèrent comme bon ou mauvais
  

Une itération initiale basée sur une documentation centrée sur le problème

Cette flexibilité aide les utilisateurs à identifier rapidement ce dont ils ont besoin de savoir, ce qui est l’objectif ultime. Les rapports sont des solutions à des problèmes, pas des vitrines de compétences techniques ou de design.

Suivre les principes de divulgation progressive

Une meilleure stratégie pour la conception de rapports Power BI consiste à suivre le concept de divulgation progressive, qui sert de fil conducteur pour un storytelling efficace.

[!NOTE]

La divulgation progressive dans la conception de rapports est une technique où seules les informations les plus essentielles sont affichées par défaut, tandis que des détails supplémentaires sont révélés progressivement, généralement via des interactions comme des clics, des survols ou des drilldowns guidés par une mise en évidence stratégique et une utilisation efficace des couleurs.

👉 Cela aide à garder le rapport épuré, réduit la charge cognitive, et permet aux utilisateurs d’explorer les données à leur propre rythme tout en leur donnant un chemin clair à suivre.

Pour que la divulgation progressive fonctionne efficacement, vous devez mettre en évidence les informations qui se démarquent et susciter la curiosité de l’utilisateur pour explorer des couches de données plus profondes. Cela nous ramène à comprendre les besoins de l’utilisateur : quels problèmes essaient-ils de résoudre ? Cela vous donne le chemin directeur de votre récit et vous permet d’utiliser efficacement la technique de divulgation progressive.

Tests d’acceptation : valider votre solution

[!NOTE]

Les tests d’acceptation pour valider les résultats et les visuels consistent à examiner un rapport pour s’assurer que les calculs de données et les éléments visuels correspondent aux attentes et exigences métier.

👉 Cela confirme que les KPI sont exacts, que les filtres se comportent correctement, et que les visuels reflètent les insights prévus avant le déploiement final.

Pour effectuer des tests d’acceptation sur un rapport Power BI et valider les résultats et les visuels, vous devez suivre un processus structuré :

1. Définir les critères d’acceptation

Définissez à quoi ressemble « correct » :

• Les valeurs des KPI correspondent à celles des systèmes sources (par exemple SAP, SQL, Salesforce, etc.)
• Les visuels suivent les directives UX (par exemple pas de visuels tronqués, couleurs accessibles, etc.)
• Tous les filtres se comportent comme prévu (par exemple sélection forcée/sélection multiple, impact sur les visuels, etc.)

2. Validation des données

Testez si les chiffres affichés sont exacts :

• Recoupez les chiffres clés (par exemple Chiffre d’affaires, Marge, Unités vendues, etc.) avec les requêtes sources ou les exports Excel
• Développez un processus d’AutoTesting pour créer des tests unitaires pour les tests de non-régression
• Utilisez DAX Query View pour décomposer les métriques complexes plus en détail
• Validez les totaux et sous-totaux des visuels et vérifiez si les filtres/segments affectent les visuels de manière logique

*Pour plus d’informations, lisez les articles détaillés : # Issue 6 - Validation Testing & # Issue 11 - Validation

3. Validation des visuels et interactions

Vérifiez si les graphiques, segments et la navigation se comportent comme prévu :

• Confirmez que les graphiques réagissent aux segments
• Assurez-vous que les libellés des axes sont visibles et formatés avec les mêmes attributs (unités, police, taille, couleur)
• Vérifiez que l’axe X commence à 0, sauf conception spécifique à des fins particulières
• Vérifiez que les infobulles au survol sont claires, informatives et bien indiquées
• Testez que le drill-through fonctionne et affiche le bon contexte
• Confirmez que les visuels sont alignés
• Vérifiez que les titres et sous-titres sont présents, ont une police/taille cohérente, et sont significatifs

Exemples :

• Cliquer sur une barre pour « Depot B » → Vérifiez si la page de drill-through affiche uniquement les données pour Depot B
• Survoler un point de nuage de points → L’infobulle devrait afficher Article, Chiffre d’affaires, % de marge, etc.

4. Tests fonctionnels

Validez que les boutons, signets et éléments dynamiques fonctionnent correctement :

• Testez les boutons de réinitialisation des filtres, les boutons de navigation, les infobulles de page
• Testez la logique de mise en forme conditionnelle

Exemples :

• Testez « Réinitialiser les filtres » → Tous les segments reviennent par défaut
• Cliquez sur « Voir le détail » → Accède à la page au niveau transaction avec les bons filtres transmis

5. Tests des cas limites

Vérifiez les cas extrêmes, nuls ou limites pour garantir la stabilité :

• Que se passe-t-il lorsque vous filtrez sur un lieu qui n’a aucune vente ?
• Quels problèmes de visibilité surviennent si les KPI ont des nombres très élevés ?
• Que doit-on afficher lorsque les données sont nulles ou à zéro ?

6. Documentation et validation finale

Tenez à jour une checklist dans Excel ou une liste SharePoint où chaque cas de test est suivi :

Cas de test	Attendu	Réel	Réussi/Échoué	Notes	Date
Chiffre d’affaires total T1	€1 234 000	€1 234 000	✅	Correspond à SAP	22 avril 2025
Réinitialiser les filtres	Tout par défaut	Tout par défaut	✅	Fonctionne	22 avril 2025
Depot C sans données	Visuels vides	Affiche (Blank)	❌	Ajouter un message « Aucune donnée »	22 avril 2025

7. Matrice RACI

Assurez-vous qu’il est très clair qui est responsable de quoi en matière de tests :

• Responsable (Responsible) : qui effectue les tests et où ? (environnement Dev/Test/Prod)
• Approbateur (Accountable) : qui approuve les résultats des tests ?
• Consulté (Consulted) : qui fournit des avis sur les critères de test ?
• Informé (Informed) : qui doit être informé des résultats des tests ?

Quand les clients sautent l’étape du problème pour aller directement à la solution

Parfois, les clients arrivent avec des solutions toutes faites au lieu de discuter d’abord du problème. Cela arrive parce que :

• Ils reproduisent ce qui a fonctionné auparavant
• Ils pensent que cela fera gagner du temps
• Ils ne savent pas ce qui est possible avec les outils actuels

[!IMPORTANT]

Les utilisateurs essaient fréquemment d’imposer leurs propres solutions, par exemple en demandant qu’un KPI soit présenté sous la forme de l’indicateur gauge (jauge) suivant. Bien que ce type de visuel puisse manquer de pertinence, prêter à confusion, et avoir un attrait esthétique discutable, le client reste le décideur final.

Pourquoi cette visualisation Gauge pose-t-elle problème ?

1. Signaux visuels contradictoires

La jauge affiche 125% avec l’aiguille pointant dans la section verte, suggérant une performance positive. Cependant, le texte en dessous indique clairement « -41,1% d’argent perdu ». Ces signaux contradictoires créent de la confusion pour l’observateur, qui doit concilier le fait qu’une apparence positive représente en réalité une perte significative.

2. Relation floue entre les métriques

La visualisation présente plusieurs métriques sans expliquer leur relation :

• La jauge affiche 125% d’une certaine mesure
• L’en-tête indique « PRICE COST DELTA »
• En dessous, on voit « -41,1% d’argent perdu »

Sans contexte clair, les utilisateurs ne peuvent pas comprendre ce que représentent les 125% ni comment ils se rattachent à la perte de 41,1%, rendant la visualisation inefficace comme outil de communication.

3. Utilisation inefficace de l’espace du rapport

Le visuel de jauge occupe un espace considérable tout en ne véhiculant qu’un seul point de donnée. Cet espace pourrait plutôt afficher des tendances historiques, des comparaisons, ou un contexte supplémentaire rendant l’information plus exploitable et significative.

4. Points de référence et contexte manquants

La visualisation ne parvient pas à établir :

• Ce que représente 100% sur la jauge en tant que référence de base
• Si 125% est bon, acceptable, ou préoccupant pour l’entreprise
• Comment la performance actuelle se compare aux objectifs ou aux périodes précédentes

Sans ces points de référence, la donnée manque de contexte métier et de sens.

5. Manque d’insights exploitables

La visualisation ne guide pas les utilisateurs vers l’action. Elle échoue à répondre à des questions critiques comme :

• Ce niveau de performance nécessite-t-il une action immédiate ?
• Quels facteurs entraînent ce delta de coût-prix négatif ?
• Quels domaines devraient être investigués davantage ?
• Comment cela se compare-t-il aux plages de performance normales ?

Une visualisation efficace ne devrait pas se contenter de présenter des chiffres, mais aider à guider la prise de décision et les prochaines étapes.

De meilleures alternatives

Dans ces situations, il est préférable de documenter clairement la demande initiale en précisant les objectifs et les raisons du choix d’un visuel spécifique. Cette approche vous permet aussi d’informer le client des inconvénients potentiels :

1. Risques liés aux visuels non natifs : problèmes lors des mises à jour, suppression possible, impact sur la performance, ou risques de conversion vers des versions payantes
2. Maintenance accrue : ajustements fréquents requis, augmentant l’effort de maintenance
3. Impact sur la performance : temps de chargement plus longs, en particulier avec de grands jeux de données
4. Recommandation d’expert : expliquez les limitations spécifiques du visuel demandé pour répondre aux exigences métier et présentez une solution alternative plus efficace basée sur votre expertise. (Vous êtes l’expert après tout)

C’est ici que la bonne documentation devient précieuse. La documentation écrite pousse les gens à réfléchir plus attentivement. Lorsque vous documentez la solution proposée par un client et que vous montrez clairement ses impacts sur le temps, le coût, la performance et la maintenance, cela ouvre la porte à de meilleures conversations sur les alternatives.

Erreurs courantes des développeurs débutants :

• Être d’accord avec tout
• Éviter les conversations difficiles
• Ne pas documenter les risques
• Se retrouver piégé dans des changements sans fin

Le résultat ? Des modèles médiocres, difficiles à corriger par la suite.

[!TIP]

Obtenez toujours une approbation écrite des exigences. Sans cela, la frontière entre ce qui a été convenu et « juste un petit changement de plus » disparaît rapidement.

[!TIP]

Révisez les priorités lorsque le périmètre s’élargit ; répondez à la question « Oui, je peux ajouter cela, mais lequel des éléments du périmètre actuel dois-je reporter ? » pour éviter les retards de projet.

[!TIP]

Certains pourraient considérer cela comme une bureaucratie inutile ajoutée au développement, ralentissant la progression et frustrant les clients qui veulent des résultats immédiats. Cependant, prendre des raccourcis en implémentant simplement ce qui est demandé est court-termiste. Tout comme il faut apprendre à marcher avant de courir, établir une communication claire et évaluer minutieusement les exigences crée un alignement qui mène à des clients véritablement satisfaits sur le long terme.

Cadre de documentation du problème

Lors de la documentation d’un problème, répondez toujours à ces questions clés :

1. Qui rencontre le problème ? (rôles/départements spécifiques)
2. Quelle tâche ou décision spécifique leur pose problème ?
3. Pourquoi le processus actuel est-il inadéquat ?
4. Comment résolvent-ils actuellement ce problème ?
5. Quand ont-ils besoin de cette information ? (quotidien, mensuel, ponctuel)

Répondre à ces questions fournit une base solide pour la conception de votre solution et aide à prévenir la dérive du périmètre plus tard dans le projet.

Documentation et Design Thinking travaillent ensemble

Le Design Thinking (se concentrer sur les utilisateurs et leurs besoins) s’associe parfaitement à une bonne documentation. Les deux valorisent :

• La compréhension des perspectives des utilisateurs
• Le travail en cycles d’amélioration
• La collecte des avis de toutes les personnes impliquées

Les deux approches posent la question essentielle : « Résolvons-nous le bon problème ? »

La documentation dans les environnements agiles

Dans les projets agiles à rythme rapide, la documentation doit être :

• Standardisée - Ne réinventez pas la roue. Concentrez-vous sur l’essentiel
• Vivante - Mise à jour fréquemment à mesure que de nouveaux insights émergent
• Accessible - Stockée là où toute l’équipe peut facilement s’y référer
• Visuelle - Utilisez des diagrammes et des graphiques autant que possible pour communiquer rapidement
• Valorisée - Pas juste une « tâche » à accomplir, mais servant plusieurs objectifs

Même dans des cycles de développement rapides, l’énoncé du problème doit rester stable tandis que les solutions peuvent évoluer.

Où stocker votre documentation pour les projets Power BI

Plusieurs outils s’intègrent bien aux workflows de développement Power BI :

• Azure DevOps Wikis - Pour une documentation de projet complète et pour le suivi des exigences et des problèmes
• JIRA - Pour une documentation de projet complète et pour le suivi des exigences et des problèmes
• Microsoft Teams - Pour la documentation collaborative et les discussions
• GitHub/AzureDevops/Git - Pour le contrôle de version de la documentation aux côtés du code
• Miro/Figma - Pour la documentation visuelle et le mapping du parcours utilisateur

Chaque outil a ses forces selon les besoins de votre équipe et les workflows existants.

[!TIP] L’ensemble de la série vise à établir un processus complet et standardisé, vous aidant à prioriser ce qui compte vraiment. Nous fournissons, dans le GitHub partagé dans les commentaires des articles, des procédures de documentation, des processus, des conseils pratiques, des recommandations et des extraits de code pour aider tous les développeurs à améliorer leurs pratiques de documentation et à devenir de meilleurs professionnels.

Conclusion

Lorsque la documentation se concentre d’abord sur les problèmes et intègre les contributions de chacun, elle mène à de meilleures solutions. Il ne s’agit pas seulement de mettre les choses par écrit, mais de créer un espace pour la réflexion critique et la compréhension partagée.

Une bonne documentation évite des reprises coûteuses en s’assurant que tout le monde s’accorde sur le problème à résoudre avant de se précipiter sur la façon de le résoudre. Rappelez-vous que le plus beau des rapports ne vaut rien s’il ne résout pas le bon problème pour vos utilisateurs.

En documentant clairement les problèmes, en testant minutieusement les solutions, et en maintenant une bonne communication avec les parties prenantes, vous construirez des solutions Power BI qui apportent réellement de la valeur à votre organisation.

[!IMPORTANT] Pour vous aider à aller plus loin, j’ai également préparé une fiche récapitulative synthétisant les idées clés — n’hésitez pas à la consulter ici. Problem Focused Documentation Cheat-Sheet.pdf

💬 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 le post LinkedIn : nous serions ravis de poursuivre la discussion ! Post LinkedIn : #Issue 12 - When Clients Impose Solutions