Des modèles qui tiennent les volumes. Des rapports que les métiers utilisent. Des exports maîtrisés et des migrations qui aboutissent : ce livre blanc réunit, pour les métiers et pour les équipes techniques, les pratiques Power BI et Microsoft Fabric qui font la différence quand les volumes, les usages et les exigences grandissent.
Simple à démarrer, exigeant à tenir
Power BI se prend en main en une après-midi. Tenir à l’échelle demande des choix faits tôt.
Un premier rapport Power BI se construit en une après-midi. C'est la force de l'outil, et c'est aussi l'origine de la plupart des difficultés que nous rencontrons sur le terrain : des modèles construits comme des extractions, des rapports qui ralentissent à mesure que l'historique s'allonge, des exports bloqués à la limite de lignes au moment de la clôture, des dizaines de versions d'un même indicateur.
Ces difficultés ne viennent presque jamais de l'outil. Elles viennent de choix faits trop tôt, ou pas faits du tout : où transformer la donnée, comment la modéliser, quel mode de stockage retenir, quel format de restitution proposer pour quel usage, comment encadrer l'export. Elles se révèlent au pire moment, quand les volumes grandissent, quand les utilisateurs arrivent d'un outil historique (SAP BusinessObjects, Tableau, Qlik) avec leurs habitudes, ou quand la donnée devient un outil de gestion quotidien et non plus seulement de pilotage.
Ce livre blanc rassemble les pratiques qui tiennent à l'échelle. Il s'appuie sur la documentation Microsoft à jour (septembre 2026, écosystème Microsoft Fabric compris), sur les références techniques reconnues (SQLBI, Chris Webb, Tabular Editor) et sur nos retours de missions. Il ne remplace pas la documentation officielle, il aide à décider : quelles questions se poser, dans quel ordre, et quelle réponse retenir selon le contexte.
Notre conviction est celle de la sobriété data : ne charger, ne calculer et n'afficher que ce qui sert. C'est la meilleure optimisation de performance, la meilleure protection des données et le plus sûr moyen d'obtenir des rapports que les métiers utilisent.
L'équipe Business Intelligence de Visian
Sommaire
- Poser le cadre
- Modélisation : les fondations
- Requêtes et calculs
- Performance à gros volumes
- Restitution des données
- Export des données
- Gouvernance et industrialisation
- Migrer vers Power BI
- Les outils du projet
Poser le cadre
Avant la moindre mesure DAX, qualifier les usages, choisir le format de restitution et fixer l'architecture qui les sert.
- La plupart des projets Power BI en difficulté ne souffrent pas d'un problème technique, mais d'un mauvais appariement entre un usage et un format : un tableau de 200 colonnes dans un rapport interactif, un état réglementaire bricolé dans un visuel, un tableau de bord exécutif qui sert en réalité d'outil d'extraction.
- Distinguer cinq familles d'usages : pilotage, analyse exploratoire, BI opérationnelle / de gestion, extraction vers d'autres outils, diffusion figée ou réglementaire. Chacune a son format de prédilection.
- Power BI n'est pas un outil unique mais une famille : rapport interactif, rapport paginé, Excel connecté, tableau de bord, application, scorecard, Copilot. Un même modèle sémantique peut les alimenter tous.
- Le cœur de l'architecture est le modèle sémantique partagé : une seule définition des indicateurs, consommée par plusieurs rapports et par Excel. Les transformations lourdes se font en amont, dans la plateforme data.
- La licence conditionne les possibilités : partage, taille des modèles, fréquence d'actualisation, accès XMLA, lecteurs sans licence payante (à partir d'une capacité F64). À instruire avant de concevoir.
- Le self-service fonctionne quand il est managé : modèles certifiés portés par une équipe identifiée, rapports libres pour les métiers.
- Ne pas reproduire à l'identique l'outil précédent. Recenser les usages réels, pas le catalogue de rapports existant.
Au sommaire du chapitre
- 1.1 Pourquoi poser un cadre avant la technique
- 1.2 Typologie des usages
- 1.3 Les formats de restitution de l'écosystème Power BI / Fabric
- 1.4 Architecture de référence
- 1.5 Licences et capacités vues du métier
- 1.6 Rôles et responsabilités
Modélisation : les fondations
Un bon modèle rend le DAX simple, les chiffres justes et les rapports rapides ; un mauvais modèle ne se rattrape jamais en aval.
- Le schéma en étoile (faits au centre, dimensions autour) est le modèle de référence pour Power BI. La « grande table plate » héritée des requêtes d'export est un anti-pattern.
- Chaque table de faits a une granularité écrite noir sur blanc : « une ligne = une ligne d'écriture comptable », pas « les données de la compta ».
- Une table Date dédiée, continue et partagée par toutes les tables de faits ; la date/heure automatique est désactivée.
- Relations 1-n unidirectionnelles par défaut. Le bidirectionnel et le plusieurs-à-plusieurs sont des exceptions justifiées, pas des réglages de confort.
- Chaque chiffre affiché passe par une mesure explicite, nommée, rangée, décrite. Les colonnes techniques sont masquées.
- En finance, les soldes ne s'additionnent pas dans le temps : ils se calculent à une date, avec des mesures dédiées.
- Un modèle sémantique partagé, plusieurs rapports légers : on ne recrée pas un modèle par rapport.
- Ce qui peut être préparé dans le data mart (clés, historisation, libellés, nettoyage) doit l'être : c'est le contrat d'interface entre équipe data et équipe BI.
Au sommaire du chapitre
- 2.1 Pourquoi la modélisation décide de tout
- 2.2 Le schéma en étoile
- 2.3 La granularité
- 2.4 La dimension Date
- 2.5 Relations : cardinalité et filtrage
- 2.6 Mesures, colonnes calculées, colonnes en amont
- 2.7 Cas finance et comptabilité
- 2.8 Modèle partagé ou modèle par rapport
- 2.9 Ce que le data mart doit préparer en amont
Requêtes et calculs
Transformer au bon endroit, laisser travailler la source, écrire un DAX que le moteur aime : la performance se joue avant le premier visuel.
- Chaque transformation a sa place : la plateforme data pour les règles de gestion partagées, Power Query pour la mise en forme propre au modèle, le DAX pour les calculs qui dépendent des filtres de l'utilisateur.
- Le query folding (repli de requête) est le mécanisme qui fait exécuter les transformations Power Query par la base de données. Quand il casse, Power BI rapatrie toute la table avant de la traiter : l'actualisation s'allonge, parfois de façon spectaculaire.
- Filtrer et réduire tôt : ne charger que les lignes et colonnes utiles. C'est la règle la plus rentable du chapitre, et le cœur de la sobriété data.
- Des vues SQL de présentation plutôt que des tables brutes ou des requêtes SQL collées à la main : le contrat entre la plateforme data et Power BI devient lisible, versionné et maintenable.
- Un DAX simple est souvent un DAX rapide : variables, filtres de colonnes dans CALCULATE, DIVIDE, pas de conversion systématique des vides en zéro.
- Mesurer avant de corriger : Performance Analyzer, DAX Studio et Query Diagnostics disent où part le temps. L'intuition se trompe souvent.
- Reproduire le besoin, pas la requête : une requête catalogue d'un outil historique se traduit en modèle, mesures et filtres obligatoires, pas en copie de son SQL.
Au sommaire du chapitre
- 3.1 Où transformer la donnée ?
- 3.2 Se connecter aux sources
- 3.3 Power Query en profondeur
- 3.4 Côté SQL et plateforme data
- 3.5 Un DAX performant et lisible
- 3.6 Diagnostiquer
- 3.7 Cas pratique : reproduire une requête catalogue d'un outil historique
Performance à gros volumes
Comprendre le moteur, alléger le modèle, choisir le bon mode de stockage et prouver les gains par la mesure.
- Ce qui pèse dans un modèle Power BI, ce n'est pas d'abord le nombre de lignes : c'est le nombre de valeurs distinctes par colonne (la cardinalité). Un horodatage à la seconde ou un identifiant unique inutile coûtent plus cher que des millions de lignes supplémentaires.
- Premier levier, le moins cher : ne charger que ce qui sert. Colonnes inutilisées, historiques jamais consultés, identifiants techniques : chaque suppression allège la mémoire, l'actualisation et la facture de capacité.
- Le mode Import reste la référence en rapidité de consultation. DirectQuery laisse la donnée à la source mais en hérite les performances. Direct Lake lit directement les tables Delta de OneLake, sans copie complète, sous réserve de garde-fous liés à la taille de la capacité.
- Pour aller « de l'agrégé au détail » sur de très gros volumes : pré-agréger dans le data mart ou via des tables d'agrégation, et ne solliciter le détail qu'au dernier clic.
- L'actualisation incrémentale évite de recharger tout l'historique à chaque fois : c'est la condition pour tenir les fenêtres d'actualisation (2 heures en capacité partagée Pro, 5 heures en capacité selon la documentation Microsoft).
- Une capacité Fabric est un budget de calcul partagé : actualisations et consultations y puisent. Au-delà du budget, la plateforme lisse puis limite (throttling). Planifier et surveiller n'est pas optionnel.
- Aucune optimisation ne se décrète : elle se mesure, avant et après, sur un jeu de référence et des scénarios utilisateurs définis avec le métier (protocole en 4.9).
Au sommaire du chapitre
- 4.1 Comprendre le moteur
- 4.2 Réduire le modèle : la sobriété data appliquée
- 4.3 Choisir le mode de stockage
- 4.4 Agrégations : l'agrégé en mémoire, le détail à la demande
- 4.5 Actualisation incrémentale et partitions
- 4.6 Grands modèles sémantiques
- 4.7 DirectQuery et Direct Lake : bonnes pratiques côté source
- 4.8 La capacité : un budget de calcul à piloter
- 4.9 Protocole de test de performance
Restitution des données
Un bon rapport répond vite à une question précise, puis laisse descendre, sans détour, jusqu'à la ligne qui l'explique.
- Un rapport, une question métier. Si l'on ne peut pas écrire en une phrase ce que la page doit permettre de décider ou de vérifier, elle n'est pas prête à être construite.
- Trois niveaux de lecture : synthèse (le message en quelques secondes), analyse (filtrer, comparer), détail (la liste des lignes qui expliquent le chiffre). Chaque niveau a sa page, et la navigation entre eux est explicite.
- Le détail unitaire se mérite : on n'affiche jamais une table de plusieurs millions de lignes « au cas où ». On y arrive par extraction, avec des filtres obligatoires.
- Chaque visuel coûte au moins une requête. Moins de visuels, mieux choisis, c'est un rapport plus rapide et plus lisible. La sobriété data s'applique aussi à l'écran.
- Le bon support pour le bon détail : table interactive pour consulter, rapport paginé pour imprimer ou extraire en volume, Excel connecté pour retravailler.
- Une charte, un thème, des formats de nombres cohérents : la confiance dans un chiffre passe aussi par sa présentation (unités, signes, date de fraîcheur affichée).
- Accessibilité dès la conception : contraste, pas d'information portée par la seule couleur, texte alternatif, ordre de tabulation.
- Maquetter avant de construire, et passer une checklist de revue avant chaque publication.
Au sommaire du chapitre
- 5.1 Principes : de la question métier au détail unitaire
- 5.2 Navigation : relier les niveaux
- 5.3 Filtres et interactivité
- 5.4 Performance du rendu
- 5.5 Design et lisibilité
- 5.6 Accessibilité
- 5.7 Usages opérationnels : listes, recherche, contrôle, rapprochement
- 5.8 Diffusion et consommation
- 5.9 Maquetter avant de construire
Export des données
Chaque voie d'export a son volume, son public et ses risques : choisir la bonne, et traiter la cause autant que le symptôme.
- Un export est d'abord un signal : manque de confiance, besoin de retraitement, justificatif, alimentation d'un autre outil ou simple habitude. Identifier la cause avant d'ouvrir ou de fermer les vannes.
- L'export depuis un visuel est plafonné : 150 000 lignes en .xlsx, 30 000 en .csv, 500 000 en Excel avec connexion active. Ce n'est pas un outil d'extraction de masse.
- Pour un retraitement Excel récurrent, préférer Excel connecté (tableau croisé dynamique ou tableau connecté) : les données restent actualisables et la sécurité à la ligne s'applique.
- Pour une liste détaillée mise en forme, à imprimer ou à archiver, le bon outil est le rapport paginé, exportable en Excel, CSV, PDF, Word, XML.
- Pour l'extraction massive ou l'alimentation d'un autre système, sortir de la couche de restitution : lakehouse, entrepôt, point de terminaison SQL ou API, pas un rapport.
- Tout fichier exporté est une copie non gouvernée : figée, hors RLS une fois diffusée, hors traçabilité. Les étiquettes de confidentialité Microsoft Purview suivent Excel, PDF et PowerPoint, mais pas le CSV.
- Plusieurs chemins d'export n'appliquent pas la sécurité du lecteur (abonnements, intégration OneLake, classeur connecté partagé) : les connaître avant de les ouvrir.
Au sommaire du chapitre
- 6.1 Pourquoi les utilisateurs exportent
- 6.2 Panorama des voies d'export et de leurs limites
- 6.3 Sécurité et gouvernance des exports
- 6.4 Quelle voie d'export choisir
- 6.5 Réduire le besoin d'export
Gouvernance et industrialisation
Donner de l'autonomie aux métiers sans perdre la maîtrise : organisation, sécurité, cycle de vie, qualité et supervision.
- La gouvernance n'est pas un frein : c'est ce qui permet d'ouvrir le self-service sans multiplier les chiffres contradictoires.
- Choisir explicitement un modèle d'organisation (BI centralisée, self-service managé, self-service métier) par type de contenu, et l'animer par un centre d'excellence et un réseau de référents.
- Découper les espaces de travail par domaine et par stade (développement, test, production) ; distribuer aux lecteurs via des applications, pas via l'espace de travail.
- Un petit nombre de modèles sémantiques certifiés, réutilisés par de nombreux rapports, vaut mieux que des dizaines de copies divergentes.
- La sécurité à la ligne ne protège que les lecteurs : administrateurs, membres et contributeurs d'un espace voient tout.
- Industrialiser le cycle de vie : format projet (PBIP), versionnage Git, pipelines de déploiement, contrôles qualité automatisés.
- Superviser l'usage et la capacité, puis nettoyer : un rapport que personne n'ouvre coûte quand même (maintenance, actualisations, confusion).
- L'adoption se construit : formation par profil, communauté, support et charte d'usage.
Au sommaire du chapitre
- 7.1 Modèle d'organisation : qui fait quoi
- 7.2 Espaces de travail : découper, attribuer, distribuer
- 7.3 Modèles sémantiques partagés : approuver, découvrir, réutiliser
- 7.4 Sécurité des données : RLS, OLS et étiquettes
- 7.5 Cycle de vie et CI/CD
- 7.6 Qualité : contrôler avant de publier
- 7.7 Supervision : savoir ce qui se passe
- 7.8 Accompagnement et adoption
Migrer vers Power BI
Une migration réussie ne recopie pas l'existant : elle trie, elle modélise, elle prouve les chiffres et elle accompagne les utilisateurs.
- Une migration BI n'est pas un changement de logiciel : c'est un changement de modèle (on passe de requêtes ou de documents autonomes à des modèles sémantiques partagés) et d'habitudes.
- Commencer par mesurer l'usage réel : une part du patrimoine n'est plus consultée. Ne pas migrer le patrimoine mort, c'est de la sobriété data appliquée.
- Construire d'abord les modèles sémantiques partagés, ensuite les rapports. Un rapport migré sans modèle cible reproduit la dette de l'outil source.
- Choisir, rapport par rapport, entre reproduction, refonte ou approche hybride, et avancer par vagues plutôt qu'en « big bang ».
- La confiance se joue sur la recette des chiffres : jeux de contrôle, indicateurs pivots, tolérances, procès-verbal de recette.
- Chaque outil source a ses pièges : culture de l'export et invites côté BusinessObjects, liberté de mise en page côté Tableau, modèle associatif côté Qlik.
- La conduite du changement et la formation des référents métier pèsent autant que la technique. Prévoir aussi le décommissionnement : tant que l'ancien outil reste ouvert, il reste utilisé.
Au sommaire du chapitre
- 8.1 Pourquoi migrer, et pourquoi les migrations échouent
- 8.2 La méthode commune
- 8.3 SAP BusinessObjects / BI4 → Power BI
- 8.4 Tableau → Power BI
- 8.5 Qlik (QlikView / Qlik Sense) → Power BI
- 8.6 Autres cas
- 8.7 Accélérateurs
- 8.8 Recette : prouver les chiffres
- 8.9 Retour du terrain
Les outils du projet
Arbres de décision, checklists, anti-patterns, outillage, glossaire et bibliographie : à garder sous la main en atelier comme en revue de projet.
Au sommaire du chapitre
- Les arbres de décision
- Les checklists
- Les 20 anti-patterns les plus fréquents
- La boîte à outils
- Glossaire
- Bibliographie sélective