6.3 · Bonnes pratiques & pièges

Niveau 6 · Dans la pratique

6.3Bonnes pratiques & pièges

Objectif : adopter les bons réflexes Power BI et éviter les erreurs de conception les plus fréquentes.
Temps estimé : 10 min · Si vous n'avez que 5 min : lisez « L'essentiel en 30s » + le schéma.

L'essentiel en 30 secondes

  • Structurer : modèle en étoile (faits au centre, dimensions 1:*), nettoyage à la source dans Power Query, table de dates dédiée et marquée.
  • Mesurer & sécuriser : mesures explicites (DIVIDE, VAR/RETURN) rangées dans « _Mesures », RLS testée, données sensibles hors du rapport.
  • Livrer : design à couleur d'accent, performance chronométrée, publication dans un espace d'équipe et actualisation qui ne dépend pas de votre portable.

Fil Zineb — la règle collée au mur

Après un trimestre, Zineb a collé sa règle au mur à Alger : propre et prouvé d'abord, rapide ensuite. Ce qui a le plus compté n'est pas une brique de plus, mais trois habitudes — modèle en étoile, mesures explicites, RLS testée — et son plus gros piège évité de justesse : un rapport diffusé à tous alors que la sécurité par service n'avait pas été vérifiée.

Choisissez une seule habitude à ancrer dans votre rituel, puis passez à la suivante.

Les do / don't d'un rapport fiable

La différence entre un bricolage et une pratique professionnelle ne tient pas aux visuels, mais aux réflexes : un modèle en étoile propre, des mesures explicites, une couleur qui signifie, un rapport sécurisé, performant et réellement actualisé.

Le modèle d'abord

Un modèle en étoile bien construit rend le DAX simple et les performances correctes. À l'inverse, rester en « table unique » dégrade tout : l'étoile n'est pas optionnelle.

Signifiant plutôt que décoré

Une couleur d'accent, des neutres, des titres en affirmations : le design sert la décision. Colorer chaque catégorie en arc-en-ciel rend le rapport joli mais muet.

✓ À faire

  • Modéliser en étoile : faits au centre, dimensions autour, relations 1:* — la fondation de tout.
  • Nettoyer à la source (Power Query) et créer une table de dates dédiée, triée et marquée.
  • Privilégier les mesures explicites (DIVIDE, VAR/RETURN), rangées dans « _Mesures » et formatées.
  • Sécuriser (RLS testée) et optimiser sur preuve (Analyseur de performances, dans l'ordre modèle → mesures → visuels).

✗ À éviter

  • Rester en « table unique » : DAX et performances se dégradent — l'étoile n'est pas optionnelle.
  • Multiplier les colonnes calculées quand une mesure suffit ; oublier de formater les nombres.
  • Colorer chaque catégorie (arc-en-ciel) au lieu d'un accent signifiant ; titres neutres.
  • Publier une RLS sans l'avoir testée, ou diffuser un rapport sensible à un espace trop large.
Erreur d'interprétation fréquente : « cocher toutes les cases chaque jour ». Non. Ce sont des habitudes à installer une par une : choisissez-en une (par ex. modèle en étoile partout), ancrez-la dans votre rituel, puis passez à la suivante.
Version texte du schéma (SEO / lecteurs d'écran / traduction) : 1) Côté modèle — étoile propre, faits au centre, dimensions 1:*, table de dates dédiée et marquée. 2) Côté calculs — mesures explicites (DIVIDE, VAR/RETURN), rangées dans « _Mesures », formatées, sans colonnes calculées inutiles. 3) Côté restitution — design à accent signifiant, titres en affirmations, interactivité réglée, pas d'arc-en-ciel. 4) Côté production — RLS testée, performance chronométrée, publication en espace d'équipe et actualisation fiabilisée. Leçon : un rapport sain est d'abord modélisé et prouvé — la rapidité vient après.

Script prêt à dire — vérifier son rapport avant envoi (30 s)

« Étoile propre ? Table de dates marquée ? Mesures dans « _Mesures » ? Zéro colonne inutile ? Accent signifiant ? RLS testée ? Performance chronométrée ? Si un non, je corrige avant envoi. »

À relire juste avant de diffuser un rapport.

Script prêt à dire — expliquer son design (30 s)

« Une couleur d'accent, des neutres, des titres en affirmations, deux à quatre segments : ma page sert la décision, elle ne décore pas. »

Une phrase pour rappeler que le design sert la décision.

Modèle copier-coller — mesures saines

Total CA = SUMX(Ventes; Ventes[Quantite] * Ventes[PrixUnitaire])
Panier moyen = DIVIDE([Total CA]; [Nb Ventes])
Evol % = VAR n1 = [CA N-1] RETURN DIVIDE([Total CA] - n1; n1)
Part = DIVIDE([Total CA]; CALCULATE([Total CA]; ALL(Produits)))

Modèle copier-coller — mauvaise piste à corriger

-- AVANT : colonne figée, ne réagit pas aux segments
Colonne CA = Ventes[Quantite] * Ventes[PrixUnitaire]
-- APRÈS : mesure explicite réutilisable
Total CA = SUMX(Ventes; Ventes[Quantite] * Ventes[PrixUnitaire])

TPE / petit budget

Une seule habitude par trimestre suffit : modèle en étoile + mesures propres d'abord, le reste ensuite.

PME Alger

Adapter les rituels aux clôtures : un créneau mesure formatée + RLS testée tenu chaque mois.

Remote / hybride

La discipline n°1 à distance : source nommée, RLS testée et date d'actualisation écrites, même pour les petits rapports.

Interculturel

Vérifier les usages locaux plutôt que supposer : un format de date ou de nombre inhabituel doit alerter partout.

Prudence : Rappel générique : règle d'or — un rapport sain est d'abord modélisé et prouvé ; ne diffusez jamais un périmètre sans RLS testée, gardez les données sensibles hors du rapport et vérifiez relations, mesures et totaux avant envoi.

Défi 48h — appliquez demain

Passez votre rapport au crible : zéro table unique, zéro colonne inutile, zéro RLS non testée. Corrigez le premier écart trouvé.

Checklist sortie de section
  • Je connais les réflexes à faire et les pièges à éviter.
  • J'ai vérifié mes points critiques (étoile, mesures, RLS testée).
  • J'ai fait le défi 48h ou planifié sa date.
Auto-évaluation 1-5 : constance des bons réflexes ?pièges évités ?
Vérifiez votre compréhension

Avant sa mise en production, quel réflexe protège le mieux Zineb ?

💡

Règle d'or : un modèle en étoile, des mesures explicites et une RLS testée — le reste (visuels, thème) ne fait que révéler cette base.