4.5Dataflows & modèles composites
L'essentiel en 30 secondes
- Le dataflow = Power Query dans le cloud : des requêtes centralisées dans le Service, réutilisables par plusieurs rapports — préparer une fois, consommer partout.
- La connexion active à un modèle sémantique publié installe un seul modèle de vérité : les mesures définies une fois, consommées par tous.
- Le modèle composite combine un modèle central publié ET des tables locales (ex. un budget Excel) : puissant, à réserver aux vrais besoins — et soumis aux licences Pro/Premium.
Mini-cas filé — Zineb pense l'architecture d'équipe
Zineb, contrôleuse de gestion dans une PME agroalimentaire à Alger, remarque que trois rapports de l'équipe refont exactement le même nettoyage du référentiel produits et de la table de dates. Au lieu de corriger chaque fichier .pbix un par un, elle réfléchit en architecture. Elle applique la section : ce nettoyage répété devient un candidat dataflow (Power Query dans le Service, préparé une fois) ; le modèle de ventes, avec ses mesures clés, devient le modèle de vérité publié une fois et consommé par connexion active ; et un rapport qui doit ajouter son budget local utilisera un modèle composite. Elle écrit la feuille de route en trois lignes : dataflows (préparation) → modèle central (mesures) → rapports connectés. Elle note le jalon : ces briques demandent une licence Pro — les concepts se maîtrisent dès maintenant.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 4.5.
1. Mutualiser la préparation
Quand plusieurs rapports répètent le même nettoyage Power Query, il est temps de mutualiser : les dataflows déplacent la préparation dans le Service — une requête centrale (le référentiel produits nettoyé, la table de dates) que tous les rapports consomment. Préparer une fois, réutiliser partout : quand la règle change, on la modifie à un seul endroit. Zineb repère chaque nettoyage répété comme un candidat dataflow.
2. Un seul modèle de vérité
La connexion active à un modèle sémantique publié installe un seul modèle de vérité : les mesures clés sont définies une fois et consommées par tous les rapports branchés. Fin des « CA différents selon le rapport ». Zineb publie donc son modèle de ventes une seule fois, et ses rapports s'y connectent plutôt que de redéfinir chaque mesure.
3. Les modèles composites
Quand un rapport doit combiner un modèle central publié ET des données locales, les modèles composites le permettent : se connecter au modèle de vérité et ajouter sa table Excel de budget. C'est puissant mais plus complexe, à réserver aux vrais besoins. Zineb note aussi que ces briques d'équipe relèvent des licences Pro/Premium — les concepts s'apprennent dès maintenant, l'outillage suivra.
🔎 Exemple concret — 🔎 Exemple concret — La feuille de route d'équipe
Zineb écrit l'architecture cible en trois lignes :
Dataflows → préparer les référentiels une fois (produits, calendrier)
Modèle central → mesures clés définies une seule fois, publié
Rapports → connexion active au modèle (mesures toutes faites)
+ Composite → un rapport ajoute sa table budget locale.Lecture : chaque nettoyage répété est un candidat dataflow ; chaque mesure partagée, un candidat modèle central.
Leçon : ces briques structurent le travail d'équipe — leur intérêt naît à plusieurs rapports/auteurs.
Vocabulaire de la section
- Dataflow
- Power Query dans le cloud : des requêtes centralisées dans le Service, réutilisables par plusieurs rapports — préparer une fois, consommer partout.
Exemple simple : Zineb y centralise le nettoyage du référentiel produits.
Ce que ce n'est pas : refaire le même nettoyage dans chaque .pbix.
Réflexe : nettoyage répété → dataflow.
- Modèle sémantique (dataset)
- Le modèle publié (tables, relations, mesures) : d'autres rapports peuvent s'y connecter en direct (connexion active) sans dupliquer.
Exemple simple : Zineb publie son modèle de ventes une seule fois.
Ce que ce n'est pas : un modèle recréé dans chaque rapport.
Réflexe : publier une fois → réutiliser partout.
- Connexion active (Live)
- Le rapport consomme un modèle publié tel quel : un seul modèle de vérité, plusieurs rapports branchés.
Exemple simple : Les rapports de Zineb s'y connectent : les mesures arrivent toutes faites.
Ce que ce n'est pas : redéfinir les mesures dans chaque rapport.
Réflexe : un modèle de vérité → connexion active.
- Modèle composite
- Le mélange : connexion à un modèle publié + tables locales ajoutées (DirectQuery sur modèle sémantique) — flexibilité maximale, complexité en proportion.
Exemple simple : Zineb ajoute sa table budget locale au modèle central.
Ce que ce n'est pas : dupliquer tout le modèle pour une petite table.
Réflexe : central + local → composite (avec parcimonie).
- Un seul modèle de vérité
- Le principe d'architecture : les mesures clés définies UNE fois, consommées par tous — fin des « CA différents selon le rapport ».
Exemple simple : Zineb garantit un CA unique pour toute l'équipe.
Ce que ce n'est pas : des chiffres divergents d'un rapport à l'autre.
Réflexe : une définition, une seule fois.
En pratique — En pratique — Penser l'architecture d'équipe (exercice de conception)
- Inventoriez : combien de rapports de votre équipe refont le MÊME nettoyage (référentiels, calendrier, mapping) ? Chaque doublon est un candidat dataflow.
- Identifiez le modèle « de vérité » potentiel : quel modèle mérite d'être publié une fois et consommé par tous (connexion active) ?
- Si vous avez une licence Pro : testez la connexion à un modèle publié (Obtenir les données → Modèles sémantiques Power BI) — les mesures arrivent toutes faites.
- Écrivez l'architecture cible en 3 lignes : dataflows (préparation) → modèle central (mesures) → rapports connectés. C'est la feuille de route d'équipe.
Script pas-à-pas — penser l'architecture comme Zineb (7 min)
1) Listez les nettoyages répétés dans votre équipe (référentiel produits, table de dates, mapping) : chacun est un candidat dataflow. 2) Choisissez le modèle « de vérité » : celui dont les mesures méritent d'être définies une seule fois. 3) Si vous avez Pro, obtenez les données → Modèles sémantiques Power BI et connectez-vous à ce modèle : les mesures arrivent toutes faites. 4) Pour un besoin de données locales, prévoyez un modèle composite (central + table Excel). 5) Écrivez la feuille de route : dataflows → modèle central → rapports connectés.
Ces briques demandent une licence Pro/Premium : les concepts s'apprennent dès maintenant, l'accès suivra selon votre organisation.
Modèle copier-coller — ma feuille de route d'équipe
Nettoyages répétés : ___ → dataflow (préparation une fois)
Modèle de vérité : ___ → publié, mesures définies UNE fois
Rapports : connexion active au modèle central (mesures toutes faites)
Besoin local : ___ → modèle composite (+ table locale, si réel besoin)
Chaîne : dataflows → modèle central → rapports connectés.
Licences : Pro/Premium pour ces briques d'équipe.Dataflow
Zineb centralise le nettoyage du référentiel produits : un seul dataflow pour tous les rapports.
Modèle de vérité
Zineb publie son modèle de ventes une fois ; les rapports s'y connectent en connexion active.
Composite
Zineb ajoute sa table budget locale au modèle central, sans le dupliquer.
Fin des CA divergents
Zineb définit les mesures une seule fois : plus de « CA différents selon le rapport ».
✓ Bonnes pratiques
- Transformer chaque nettoyage répété en dataflow mutualisé.
- Publier un modèle de vérité consommé par connexion active.
- Réserver le composite aux vrais besoins (central + local).
✗ Pièges fréquents
- Dupliquer le même nettoyage dans dix .pbix isolés.
- Multiplier les modèles sources (« CA différents selon le rapport »).
- Adopter le composite sans nécessité (complexité en proportion).
Points clés à retenir
- Dataflow = Power Query mutualisé dans le cloud : préparer une fois, réutiliser partout.
- Connexion active à un modèle publié = un seul modèle de vérité, des rapports multiples.
- Le composite combine modèle central + données locales : à réserver aux vrais besoins.
- Ces briques structurent le travail d'équipe : leur intérêt naît à plusieurs rapports/auteurs.
Défi 48h — appliquez demain
Comme Zineb, listez les nettoyages répétés de votre équipe et désignez le modèle de vérité potentiel, puis écrivez l'architecture cible en trois lignes : dataflows → modèle central → rapports connectés. Notez en une phrase ce que la connexion active vous évitera.
- Je peux expliquer ce qu'est un dataflow et quand il s'impose.
- Je sais ce qu'apporte une connexion active à un modèle publié (un seul modèle de vérité).
- Je comprends ce qu'est un modèle composite et je le réserve aux vrais besoins.
Questions fréquentes
Dataflow ou requête dans le .pbix : comment trancher ?
Le critère est la réutilisation. Un usage = requête locale dans le .pbix ; plusieurs usages (plusieurs rapports/auteurs) = dataflow. Le bénéfice va au-delà du temps : quand la règle change, on la modifie une fois et tous les rapports en héritent.
Quelles licences pour tout cela ?
Les dataflows et les connexions actives à des modèles publiés demandent une licence Pro ; certaines options avancées relèvent de Premium/Fabric. C'est un sujet d'organisation : les concepts se maîtrisent dès maintenant, gratuitement.
Qu'apporte une connexion active à un modèle sémantique publié ?