Accueil›Blog›Test technique Power BI bonnes pratiques : rapport, modèle, performance
Guide recrutement data
Test technique Power BI bonnes pratiques : rapport, modèle, performance
Savoir créer un graphique dans Power BI ne suffit pas. En entretien Senior, on évalue la rigueur dans la construction du rapport : structure des pages, gestion des interactions, optimisation des performances et gouvernance.
Data Builder·Juin 2025·8 min de lecture·Data Analyst
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
Question discriminante
Pourquoi évitez-vous les relations plusieurs-à-plusieurs ? Et pourquoi organisez-vous vos tables en schéma en étoile ?
- 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
Règle de base : si votre modèle Power BI a plus de 3 niveaux de jointure ou des relations bidirectionnelles partout, c'est un signal que la préparation des données devrait se faire en amont (Power Query ou dbt), pas dans le modèle.
2Structure d'une page de rapport
Question discriminante
Comment structurez-vous une page de rapport Power BI ? Quelle est votre logique de mise en page ?
- 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
Question discriminante
Quels types de graphiques évitez-vous dans Power BI et pourquoi ?
- 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
Question discriminante
Comment identifiez-vous et résolvez-vous un rapport Power BI lent ?
- 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
Question discriminante
Comment créez-vous un menu de navigation avec des signets ? Quelle est la différence entre "Données" et "Afficher" dans les paramètres d'un signet ?
- 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 |
Home›Blog›Power BI technical test best practices: report, model, performance
Data recruitment guide
Power BI technical test best practices: report, model, performance
Knowing how to create a chart in Power BI is not enough. In a Senior interview, the focus is on rigor in report building: page structure, interaction management, performance optimization and governance.
Data Builder·June 2025·8 min read·Data Analyst
A Power BI report in production is like software: it must be maintained, documented, and performant. Profiles that neglect modeling or do not test before publishing create technical debt that the entire team will have to pay back.
1Modeling: before touching the report
Discriminating question
Why do you avoid many-to-many relationships? And why do you organize your tables in a star schema?
- Star schema mandatory — fact table at the center, dimension tables around it. Simplifies relationships, reduces processing time
- Many-to-many (M:M) relationships — to avoid: increase the risk of filter errors, create ambiguities in aggregations. Resolve with a bridge table
- Remove unnecessary columns — every imported column consumes memory. Only keep what is needed for the report
- Inactive relationships — remove them if unused: they can "break" the report when data is refreshed
- Date table — create and mark a dedicated date table to enable time intelligence functions
Basic rule: if your Power BI model has more than 3 levels of joins or bidirectional relationships everywhere, it is a signal that data preparation should be done upstream (Power Query or dbt), not in the model.
2Report page structure
Discriminating question
How do you structure a Power BI report page? What is your layout logic?
- Funnel effect — top to bottom: filters/slicers → KPIs → charts → detail table
- Fixed header — clear title, refresh date, report scope
- 3-4 visuals maximum per page — beyond that, performance degrades and the user is overwhelmed
- Chart backgrounds — modify directly in the chart layout settings, not with overlaid shapes (better performance)
- Slicer synchronization — if a filter must apply across multiple pages, synchronize it (View → Sync slicers)
3Choosing visuals: what to avoid
Discriminating question
What types of charts do you avoid in Power BI and why?
- Pie charts — difficult to compare visually, especially with more than 4-5 segments. Prefer bar charts
- 3D is useless — 3D charts distort proportions. Always prefer 2D equivalents (donut rather than 3D pie)
- Too many custom visuals — marketplace visuals can slow down the report and create dependencies. Prefer native visuals when possible
- Tables with too many rows — limit to 10-20 rows, sort by the most important indicator. Use the Top N condition
- Line charts for categorical data — use bar charts for categories, line charts for time series
4Performance optimization
Discriminating question
How do you identify and resolve a slow Power BI report?
- Performance Analyzer — enable in the View tab, measures the rendering time of each visual (DAX query, display, other)
- Limit interactions — by default, all visuals influence each other. Disable unnecessary interactions (Format → Edit interactions)
- Calculated columns vs measures — calculated columns are stored and increase model size. Prefer measures (calculated on the fly)
- KPIs via tables rather than cards — aligning multiple KPIs in a single table = 1 query instead of N (improves performance)
- Upstream filters — filter in Power Query before loading rather than with visual filters
- DAX Studio — analyze slow measures, view the VertiPaq query plan
5Bookmarks and advanced navigation
Discriminating question
How do you create a navigation menu with bookmarks? What is the difference between "Data" and "Display" in a bookmark's settings?
- Bookmarks — save a report state: active filters, element visibility, current page
- "Data" setting — includes the filter/slicer state in the bookmark. Enable for period tabs (Last day, Last week)
- "Display" setting — includes element visibility. Useful for showing/hiding charts
- Selected visuals — always prefer "Selected visuals" over "All visuals" to avoid side effects on other elements
- Navigation without bookmarks — use native page navigation buttons (Insert → Buttons → Page navigation)
6Before publishing: checklist
- Refresh data — always refresh before submitting to avoid stale data
- Test all buttons and filters — verify that slicers work and that buttons navigate correctly
- Check performance — Performance Analyzer on each page before publishing
- Clean up unused measures — orphaned measures increase file size and create confusion
- Document sources — indicate in the report the last refresh date and data source
- Row-Level Security — test RLS roles with "View as" before publishing
7Level grid
| Level | Expected proficiency | GO signal | NO-GO |
|---|
| Junior | Native visuals, slicers, simple relationships, basic publishing | Can create a star schema, avoids pie charts, refreshes before publishing | Uses bidirectional relationships everywhere, does not clean up unnecessary columns |
| Confirmed | Advanced bookmarks, interaction optimization, Performance Analyzer | Uses bookmarks for navigation, disables unnecessary interactions, has used Performance Analyzer | Has never used Performance Analyzer, does not know how to configure bookmarks |
| Senior | Deployment pipelines, advanced RLS, DAX Studio, report standards | Has deployed via DEV/TEST/PROD pipelines, has configured dynamic RLS, uses DAX Studio | Does not know deployment pipelines, has never used DAX Studio |