Power BI : datasets sémantiques vs reports — quand utiliser quoi

À petite échelle, la question ne se pose pas : un analyste ouvre Power BI Desktop, importe ses données, modélise et publie. Tout est dans le fichier .pbix. À plus grande échelle, ce pattern devient ingérable — chaque report dupliquant son propre modèle, ses propres mesures DAX, ses propres règles métier.

Le pattern sémantique partagé

La bonne pratique : un dataset (modèle sémantique en terminologie 2026) centralise les tables, les relations, les mesures, la sécurité au niveau ligne (RLS). Les reports se branchent dessus en mode « live connection » et n'embarquent que la mise en forme visuelle.

Avantages concrets : une mesure « CA prévisionnel » modifiée une fois est mise à jour partout. La gouvernance des accès se gère en un endroit. Le rafraîchissement des données ne se fait qu'une fois pour tous les reports consommateurs.

Quand séparer dataset et report

• —Plus de deux reports utilisent les mêmes données — séparez immédiatement.
• —Plus de cinq utilisateurs consomment au moins un report — la duplication coûte plus cher en maintenance qu'elle ne vous fait économiser à la création.
• —Vous avez une notion de sécurité par périmètre (région, business unit) — RLS centralisé indispensable, donc dataset partagé.

Quand garder tout dans un .pbix

• —Étude ad hoc, audience < 5 personnes, durée de vie < 3 mois.
• —POC ou wireframe à valider avant industrialisation.
• —Données très spécifiques à un cas, sans réutilisation prévue.

Le piège classique

Démarrer avec des .pbix « parce que c'est plus simple », accumuler 30 reports en 18 mois, découvrir qu'aucune mesure ne donne le même chiffre d'un report à l'autre. Le coût de remise en cohérence dépasse alors largement celui d'avoir investi dans un dataset partagé dès le départ.