Test technique Power BI bonnes pratiques : rapport, modèle, performance

Un rapport Power BI en production, c'est comme un logiciel : il doit être maintenu, documenté, et performant. Les profils qui négligent la modélisation ou ne testent pas avant de publier créent de la dette technique que l'équipe entière devra rembourser.

1La modélisation : avant de toucher le rapport

• Schéma en étoile obligatoire — table de faits au centre, tables de dimension autour. Simplifie les relations, réduit le temps de traitement
• Relations plusieurs-à-plusieurs (M:M) — à éviter : augmentent le risque d'erreur dans les filtres, créent des ambiguïtés dans les agrégations. Résoudre avec une table de bridge
• Supprimer les colonnes inutiles — chaque colonne importée consomme de la mémoire. Ne garder que ce qui est nécessaire au rapport
• Relations inactives — les supprimer si inutiles : elles peuvent "casser" le rapport lors d'une mise à jour des données
• Table de dates — créer et marquer une table de dates dédiée pour activer les fonctions de time intelligence

2Structure d'une page de rapport

• Effet entonnoir — de haut en bas : filtres/slicers → KPIs → graphiques → table de détail
• Header fixe — titre clair, date de rafraîchissement, périmètre du rapport
• 3-4 visuels maximum par page — au-delà, les performances se dégradent et l'utilisateur est submergé
• Fond des graphiques — modifier directement dans la mise en page du graphique, pas avec des formes superposées (meilleure performance)
• Synchronisation des slicers — si un filtre doit s'appliquer sur plusieurs pages, le synchroniser (Affichage → Synchronisation des segments)

3Choix des visuels : ce qu'on évite

• Graphiques en secteurs (camemberts) — difficiles à comparer visuellement, surtout avec plus de 4-5 segments. Préférer les barres
• 3D nul — les graphiques 3D déforment les proportions. Toujours préférer les équivalents 2D (donut plutôt que camembert 3D)
• Trop de visuels custom — les visuels de la marketplace peuvent ralentir le rapport et créer des dépendances. Préférer les natifs quand possible
• Tables avec trop de lignes — limiter à 10-20 lignes, trier par l'indicateur le plus important. Utiliser la condition de N premiers
• Graphiques linéaires pour des données catégorielles — utiliser des barres pour les catégories, des lignes pour les séries temporelles

4Optimisation des performances

• Performance Analyzer — activer dans l'onglet Affichage, mesure le temps de rendu de chaque visuel (requête DAX, affichage, autre)
• Limiter les interactions — par défaut, tous les visuels s'influencent. Désactiver les interactions non nécessaires (Format → Modifier les interactions)
• Colonnes calculées vs mesures — les colonnes calculées sont stockées et augmentent la taille du modèle. Préférer les mesures (calculées à la volée)
• KPIs via tables plutôt que cartes — aligner plusieurs KPIs dans une seule table = 1 requête au lieu de N (améliore les performances)
• Filtres en amont — filtrer dans Power Query avant le chargement plutôt qu'avec des filtres visuels
• DAX Studio — analyser les mesures lentes, voir le plan de requête VertiPaq

5Signets et navigation avancée

• Signets — sauvegardent un état du rapport : filtres actifs, visibilité des éléments, page courante
• Paramètre "Données" — inclut l'état des filtres/slicers dans le signet. À activer pour les onglets de période (Last day, Last week)
• Paramètre "Afficher" — inclut la visibilité des éléments. Utile pour montrer/masquer des graphiques
• Visuels sélectionnés — toujours préférer "Visuels sélectionnés" à "Tous les visuels" pour éviter les effets de bord sur les autres éléments
• Navigation sans signets — utiliser les boutons de navigation de page natifs (Insérer → Boutons → Navigation dans les pages)

6Avant de publier : checklist

• Actualiser les données — toujours actualiser avant l'envoi pour éviter les données obsolètes
• Tester tous les boutons et filtres — vérifier que les slicers fonctionnent, que les boutons naviguent correctement
• Vérifier les performances — Performance Analyzer sur chaque page avant publication
• Nettoyer les mesures inutilisées — les mesures orphelines augmentent la taille du fichier et créent de la confusion
• Documenter les sources — indiquer dans le rapport quelle est la date de dernière actualisation et la source des données
• Row-Level Security — tester les rôles RLS avec "Tester comme" avant publication

7Grille par niveau

Niveau	Maîtrise attendue	Signal GO	NO-GO
Junior	Visuels natifs, slicers, relations simples, publication basique	Sait créer un schéma en étoile, évite les camemberts, actualise avant publication	Utilise des relations bidirectionnelles partout, ne nettoie pas les colonnes inutiles
Confirmé	Signets avancés, optimisation interactions, Performance Analyzer	Utilise les signets pour la navigation, désactive les interactions inutiles, a utilisé Performance Analyzer	N'a jamais utilisé Performance Analyzer, ne sait pas configurer les signets
Senior	Deployment pipelines, RLS avancé, DAX Studio, standards de rapport	A déployé via pipelines DEV/TEST/PROD, a configuré du RLS dynamique, utilise DAX Studio	Ne connaît pas les deployment pipelines, n'a jamais utilisé DAX Studio