De la requête SQL au dashboard Power BI : le pipeline le plus simple qui fonctionne vraiment

🎯 Situation

Un nouvel analyste a rejoint l'équipe d'un client et a posé une question simple : "Comment est-ce que je fais passer les données de notre base de données dans un rapport Power BI qui s'actualise automatiquement ?"

La plupart des réponses à cette question en ligne sautent directement à la connexion de Power BI à des tables brutes et à l'écriture de transformations dans Power Query. Ça fonctionne à petite échelle. À l'échelle production — avec plusieurs utilisateurs, des actualisations planifiées, et une logique métier qui doit être cohérente — ça crée des rapports fragiles qui se cassent quand les données sources changent.

Voici ce pipeline, étape par étape.

⚠️ Challenge : deux mauvaises approches

Avant la bonne approche, il vaut la peine de nommer les deux erreurs courantes — parce que les deux sont enseignées comme pratique standard dans les tutoriels d'introduction.

Les deux approches fonctionnent pour des prototypes et des rapports personnels. Aucune ne passe à l'échelle proprement pour un reporting d'équipe en production où plusieurs personnes partagent des dashboards construits sur des données cohérentes et gouvernées.

🔍 Le pipeline en 4 étapes

Étape 1 — Écrire la logique métier en SQL, pas dans Power Query

Créer une vue SQL dans ta base centrale qui gère toutes les jointures, filtres, agrégations et définitions de métriques. C'est la source unique de vérité pour ce KPI — la même vue dont on a parlé dans l'article sur les définitions de KPIs.

-- Step 1: Create a clean view in your database
-- This is what Power BI will connect to — not the raw tables

CREATE VIEW vw_monthly_sales AS
SELECT
    DATE_TRUNC('month', o.order_date)   AS month,
    p.category                          AS product_category,
    r.name                              AS region,
    COUNT(DISTINCT o.order_id)          AS order_count,
    SUM(ol.quantity)                    AS units_sold,
    SUM(ol.quantity * ol.unit_price)    AS gross_revenue,
    SUM(ol.quantity * ol.unit_price
        - ol.quantity * p.cost_price)   AS gross_margin
FROM orders o
JOIN order_lines ol  ON o.order_id  = ol.order_id
JOIN products    p   ON ol.product_id = p.product_id
JOIN regions     r   ON o.region_id = r.region_id
WHERE o.status = 'completed'
GROUP BY 1, 2, 3;

Cette vue joint quatre tables, filtre sur les commandes complétées, et produit un résumé mensuel propre. N'importe quel outil — Power BI, Excel, Python, Looker — peut l'interroger et obtenir les mêmes chiffres.

Étape 2 — Connecter Power BI à la vue, pas aux tables brutes

Dans Power BI Desktop : Obtenir des données → SQL Server (ou ta base de données) → entrer le serveur et la base → choisir la vue (vw_monthly_sales), pas les tables sous-jacentes. Mode Import ou DirectQuery selon le volume et les besoins d'actualisation. Pour la plupart des PME : mode Import avec actualisation quotidienne est le bon choix.

Étape 3 — Garder Power Query minimal

Une fois la vue propre, Power Query ne devrait presque rien faire : renommer les colonnes si nécessaire, définir les types de données, rien d'autre. Toute la logique de transformation reste en SQL. Si tu te retrouves à écrire du code M complexe dans Power Query, c'est un signal que la vue SQL a besoin de travail.

Étape 4 — Construire le modèle sémantique et planifier l'actualisation

Dans Power BI Service : publier le rapport → aller dans les paramètres du dataset → configurer l'actualisation planifiée (quotidienne à 6h est standard) → configurer une passerelle si ta base est on-premises. C'est tout. Le rapport se met à jour automatiquement chaque matin sans que personne n'y touche.

✓️ Pourquoi cette architecture dure

La raison pour laquelle ce pattern fonctionne à l'échelle, c'est la séparation des responsabilités — chaque couche a un seul rôle :

• Base de données (SQL) — stocke les données brutes, définit la logique métier via des vues, assure la cohérence pour tous les consommateurs
• Dataset Power BI — importe des données propres et pré-agrégées, définit le modèle sémantique (relations, hiérarchies, mesures DAX), gère les calculs côté utilisateur
• Rapport Power BI — visualise le modèle sémantique, gère la mise en page et l'interactivité, zéro logique métier ici

Quand le business change — une nouvelle région, un KPI redéfini, une nouvelle catégorie de produit — on met à jour la vue SQL. Tous les rapports construits sur cette vue se mettent à jour automatiquement à la prochaine actualisation. On ne touche pas au fichier .pbix.

Quand quelqu'un demande "où est le calcul du chiffre d'affaires ?" — la réponse est toujours la même : vw_monthly_sales, ligne 12. Pas "quelque part dans Power Query" ou "je crois que c'est dans la mesure DAX mais peut-être aussi dans la requête M".