Modèles sémantiques : partager les mêmes indicateurs en BI

Deux tableaux de bord affichent un chiffre d’affaires différent. Les deux utilisent pourtant les données du même entrepôt. Après vérification, l’un retranche les remboursements, l’autre conserve les commandes annulées et leurs dates de référence ne sont pas identiques.

Cette situation fictive résume un problème très concret pour une équipe data : partager des tables ne suffit pas à partager la définition des indicateurs. Les modèles sémantiques et les couches sémantiques, ou semantic layers, permettent de rendre ces règles explicites et de les réutiliser.

Le sujet mérite d’être traité indépendamment de l’IA. Une direction commerciale, un contrôleur de gestion et un analyste doivent déjà pouvoir comprendre ce que mesure un chiffre. Voici comment fonctionne cette couche, où elle peut servir et comment commencer avec un exemple de ventes reproductible.

Qu’est-ce qu’un modèle sémantique ?

Un modèle sémantique décrit les données avec les concepts utilisés par le métier : commandes, clients, canaux, chiffre d’affaires, panier moyen. Il précise les relations entre ces objets et les calculs autorisés.

Concrètement, un rapport demande « le chiffre d’affaires net par canal sur cette période ». Le moteur applique les filtres, les relations et la formule du modèle, puis renvoie une table de résultats. Le rapport décide de leur présentation. Dans Power BI, le modèle sémantique constitue ainsi une ressource distincte du rapport qui le consulte. Présentation des modèles Power BI.

Trois notions aident à le concevoir :

• Le grain indique ce que représente une ligne : une commande, une ligne de commande ou un solde quotidien.
• Les dimensions permettent de filtrer et de regrouper : date, canal, magasin, catégorie.
• Les mesures calculent un résultat dans ce contexte : somme, nombre de commandes ou ratio.

Un modèle physique organise le stockage des données. Le modèle sémantique organise leur interprétation et leur interrogation. Les deux peuvent s’appuyer sur une modélisation en étoile, avec des faits et des dimensions. Guide de Microsoft sur le schéma en étoile.

Modèle sémantique et semantic layer : quelle différence ?

Le modèle contient les définitions. La couche sémantique est le dispositif qui les met à disposition des consommateurs : moteur de calcul, accès, interfaces et gestion des versions, selon la solution.

Elle peut être intégrée à votre outil BI ou servir plusieurs outils. Par exemple, dbt Semantic Layer définit des métriques dans le projet dbt et s’appuie sur MetricFlow pour leur interrogation. Les intégrations réellement disponibles doivent être vérifiées pour les consommateurs visés. Documentation dbt.

Un dictionnaire décrivant le chiffre d’affaires reste utile. Pour que la règle soit effectivement partagée, les rapports doivent appeler le calcul maintenu dans le modèle, au lieu de recopier chacun une formule.

Le même besoin, avec des calculs dispersés ou un modèle partagé

Prenons une enseigne qui suit ses ventes web et magasins.

Avec des calculs dispersés, chaque rapport choisit ses filtres, ses jointures et son traitement des retours. Une correction de définition demande de retrouver les différentes implémentations, de les modifier et de vérifier leurs résultats.

Avec un modèle partagé, l’équipe définit une mesure nommée précisément, par exemple « CA net HT des commandes payées, retours connus déduits ». Les rapports réutilisent cette mesure et choisissent leurs axes d’analyse.

Point à décider	Calculs dans chaque rapport	Modèle partagé
Commandes retenues	Filtre à maintenir dans chaque copie	Règle portée par la mesure
Retours et remises	Traitement susceptible de diverger	Définition et préparation communes
Correction	Recherche des copies concernées	Modification du modèle et contrôle des consommateurs
Analyse par canal	Formule locale possible	Même mesure, contexte de filtre différent

Un modèle commun ne garantit pas des chiffres identiques lorsque les filtres, les droits ou la fraîcheur des données diffèrent. Il permet de rendre ces différences explicables. Avant de conclure à une erreur, comparer aussi la période, le périmètre et la version du modèle.

Deux définitions peuvent être légitimes. Les ventes à la date de commande et les encaissements à la date de paiement répondent à des questions différentes. Leur donner des noms distincts est souvent plus utile que d’imposer un indicateur ambigu appelé « revenu ».

Qu’est-ce qu’une équipe data peut y gagner ?

Le premier gain attendu est la diminution des corrections répétées. Il se mesure par le nombre d’implémentations à modifier lorsqu’une règle change et par le temps nécessaire pour les contrôler.

Le deuxième est une analyse plus facile à réutiliser. Un analyste peut construire un nouveau rapport à partir de mesures déjà définies. Mesurer le délai de création et le nombre de calculs locaux ajoutés permet de voir si le modèle couvre réellement les besoins.

Le troisième est une meilleure traçabilité des désaccords. On peut identifier la définition, ses exclusions et son responsable. Suivre les incidents de chiffres contradictoires aide à vérifier ce bénéfice.

Ces gains ont un coût : formalisation des règles, maintenance, tests, accompagnement et éventuellement service supplémentaire. Une couche partagée peut aussi diffuser une erreur à plusieurs rapports. Un petit périmètre utile, avec un responsable identifié, constitue donc un meilleur premier investissement qu’un catalogue exhaustif jamais adopté.

Trois cas d’usage concrets

Réconcilier les ventes entre commerce et finance

Les entrées sont les commandes, remises et remboursements. Le travail consiste à définir des indicateurs distincts pour le suivi commercial et les besoins financiers, puis à expliquer leur rapprochement.

Le résultat attendu est un tableau où l’écart peut être décomposé : statut, date, taxes, retours ou frais. La réussite se mesure au temps passé à expliquer cet écart et à la réduction des calculs parallèles. Le modèle ne tranche pas à lui seul une convention de gestion.

Donner plusieurs vues à partir d’un socle commun

Une direction régionale veut un rapport par magasin, le siège une synthèse par canal. Les deux peuvent réutiliser le même modèle, avec des visuels et des filtres différents.

L’équipe data maintient les mesures une fois et vérifie les accès. Le test utile consiste à comparer deux rapports sur le même périmètre autorisé. Le partage ne dispense pas de tester les rôles : un filtre de présentation ne constitue pas un contrôle d’accès.

Définir un taux de service logistique

Une équipe suit les livraisons à l’heure. Elle doit choisir le niveau de mesure : commande complète, colis ou ligne. Une commande partiellement livrée peut donner des résultats différents selon ce choix.

Le modèle expose le nombre d’unités éligibles et le nombre servi dans les délais, puis calcule leur ratio. L’évaluation porte sur les cas limites : livraisons fractionnées, dates promises modifiées, annulations. Additionner des taux locaux ou en faire une moyenne simple risque de produire un total trompeur.

Tutoriel : trois mesures de ventes avec Power BI

L’atelier fournit six commandes synthétiques, deux canaux et trois remboursements. Il comprend une commande annulée, une commande entièrement remboursée et deux remboursements sur la même commande.

Le script de préparation et les calculs de référence ont été exécutés localement en Python et SQLite. Les formules DAX ci-dessous ont été relues, mais pas exécutées dans Power BI pour cet article. Les valeurs attendues permettent de vérifier cette dernière étape dans votre environnement.

1. Écrire le contrat de mesure

Pour cet exercice, les règles sont les suivantes :

Élément	Convention retenue
Grain	Une ligne par commande
Population	Statut paid uniquement
Montant	Hors taxes, moins remises et remboursements connus
Temps	Date de commande ; retours rattachés à la commande d’origine
Devise	EUR uniquement
Nombre de commandes	Commandes payées, même entièrement remboursées
Panier net moyen	CA net HT divisé par le nombre de commandes payées

C’est une convention pédagogique de suivi commercial. Elle ne représente pas une règle universelle de comptabilisation. Un retour enregistré plus tard peut modifier le montant d’une ancienne période : si vous devez figer une clôture, il faut prévoir un historique adapté.

2. Générer les données et vérifier le grain

Télécharger le script de l’atelier. Avec Python 3.10 ou supérieur, sans dépendance supplémentaire :

python3 atelier-metriques.py atelier-ventes

Sous Windows, python peut remplacer python3. Le script crée un dossier neuf avec FactCommandes.csv, DimCanal.csv, DimDate.csv et attendus.json. Il refuse d’écraser un dossier existant. Il ne contacte aucun service.

Avant l’export, il agrège les remboursements par commande puis les rattache aux commandes. Cette étape préserve le grain :

WITH retours AS (
    SELECT commande_id,
           SUM(remboursement_ht_centimes)
               AS remboursement_ht_centimes
    FROM remboursements
    GROUP BY commande_id
)
SELECT c.*,
       COALESCE(r.remboursement_ht_centimes, 0)
           AS remboursement_ht_centimes
FROM commandes c
LEFT JOIN retours r USING (commande_id);

Dans ces données, une jointure directe avec les remboursements répète la commande C1. Le calcul naïf donne 550 € au lieu de 450 €. Le script vérifie les deux résultats pour rendre l’erreur visible. Un SUM(DISTINCT montant) ne serait pas une correction générale : deux commandes différentes peuvent avoir le même montant.

3. Construire le modèle dans Power BI Desktop

Installer Power BI Desktop sur un environnement Windows pris en charge. Dans Obtenir des données > Texte/CSV, importer les trois CSV. Vérifier le séparateur virgule et les noms des tables : FactCommandes, DimCanal et DimDate.

Dans Power Query, typer les deux colonnes de date en Date, les montants en Nombre entier, les identifiants et le statut en Texte. Les montants restent en centimes jusqu’au calcul.

Créer deux relations actives, avec filtrage à sens unique depuis la dimension :

• DimCanal[canal_id] vers FactCommandes[canal_id], un-à-plusieurs ;
• DimDate[date] vers FactCommandes[date_commande], un-à-plusieurs.

Vérifier les relations proposées automatiquement. Les clés du côté « un » doivent être uniques. Fonctionnement des relations Power BI.

La table de dates contient seulement les deux jours de l’exercice. Pour des analyses temporelles en production, prévoir un calendrier complet adapté aux périodes et fonctions utilisées.

4. Ajouter les trois mesures

Créer chaque mesure séparément dans le modèle :

CA net HT =
SUMX(
    FILTER(FactCommandes, FactCommandes[statut] = "paid"),
    FactCommandes[montant_ht_centimes]
        - FactCommandes[remise_ht_centimes]
        - FactCommandes[remboursement_ht_centimes]
) / 100

Commandes payées =
COUNTROWS(
    FILTER(FactCommandes, FactCommandes[statut] = "paid")
)

Panier net moyen =
DIVIDE([CA net HT], [Commandes payées])

SUMX évalue ici le montant net sur les lignes retenues. DIVIDE évite une division brute lorsque le dénominateur est nul ou vide. Formater les montants en euros et le nombre de commandes en entier. SUMX, DIVIDE.

Ajouter une description aux mesures avec leurs conventions. Le nom seul ne peut pas contenir toutes les exclusions.

5. Contrôler les résultats et les cas limites

Créer une matrice avec DimCanal[canal] en lignes et les trois mesures en valeurs, sans autre filtre. Les calculs de référence donnent :

Canal	CA net HT	Commandes payées	Panier net moyen
Web	90 €	2	45 €
Magasin	360 €	3	120 €
Total	450 €	5	90 €

Le total du panier moyen doit être recalculé : 450 / 5 = 90 €. La moyenne simple de 45 € et 120 € donnerait 82,50 €, car les canaux n’ont pas le même nombre de commandes.

Filtrer ensuite le 1er septembre : le CA net attendu est 170 €. La commande annulée ne doit pas entrer dans les mesures. C4 reste une commande payée avec un montant net nul. Sans commande éligible, le panier moyen doit rester vide.

Le script contrôle également l’unicité des commandes, les références de canaux et le rejet d’un doublon de clé. Ces contrôles portent sur ce petit jeu synthétique ; ils ne démontrent pas la qualité de vos sources réelles.

6. Réutiliser le modèle dans un autre rapport

Lorsque le résultat est validé, publier le modèle dans un espace de travail de test autorisé. Créer ensuite un second rapport connecté à ce modèle sémantique existant, sans réimporter les CSV ni recopier les mesures.

Cette étape nécessite les droits et licences adaptés à votre environnement, notamment l’autorisation de construire sur le modèle. Microsoft documente la connexion à un modèle partagé.

Comparer les deux rapports avec les mêmes filtres et le même accès. Pour un test en service à partir de fichiers locaux, configurer leur actualisation si nécessaire ; la publication ne rend pas votre dossier local accessible en permanence.

Après l’essai, conserver le contrat et les résultats utiles, puis supprimer les fichiers et ressources de test devenus inutiles.

Faut-il ajouter une couche sémantique à votre architecture ?

Si vos usages sont concentrés dans Power BI, commencer par un modèle partagé existant peut suffire. Si plusieurs outils doivent consommer les mêmes métriques, évaluer une couche commune sur un parcours réel : définition, requête, droits, actualisation et correction.

Le choix dépend aussi des compétences et du coût de fonctionnement. Tester les connecteurs, les fonctions de calcul, les performances et les limites de chaque solution avant de déplacer des mesures déjà fiables.

Pour démarrer, choisir un indicateur qui crée aujourd’hui des désaccords. Réunir ses consommateurs, écrire ses variantes légitimes, définir son grain et construire un petit jeu de référence. Puis vérifier qu’un deuxième rapport peut le consommer sans recréer sa formule. C’est un résultat concret sur lequel une équipe data peut décider de poursuivre.