Couche sémantique : pourquoi vos chiffres divergent

Trois équipes affichent trois chiffres d'affaires parce que chacune calcule l'indicateur à sa manière, dans son outil, à partir de tables différentes, avec ses propres règles sur les remises, les avoirs, la devise et la date de référence. Aucune n'a tort. Une couche sémantique gouvernée résout le problème en définissant chaque indicateur une seule fois, en code, dans un endroit que tous les outils consultent. Sur un périmètre bien cadré, elle se met en place en trois à cinq semaines, pas en trimestres.

La scène que vous connaissez

Lundi matin, comité de direction. Le dashboard affiche 4,21 millions de chiffre d'affaires pour août. La directrice financière a 4,08 dans son reporting. Le directeur commercial annonce 4,35 dans son CRM. Vingt minutes passent à débattre de la source, la décision est reportée, quelqu'un est chargé de « réconcilier ».

Cette réunion coûte cher, et elle se répète chaque mois parce que la réconciliation traite les symptômes. Le mois suivant, les mêmes causes produisent de nouveaux écarts.

D'où viennent les écarts

En dix ans de ce genre d'enquête, les causes se répartissent presque toujours dans cinq familles.

Cause	Exemple typique	Qui a raison
Périmètre	Les ventes comptent les commandes signées, la finance les commandes facturées, le dashboard les commandes expédiées	Tout le monde, pour un usage différent
Règles de calcul	Avec ou sans remises, avoirs, frais de port, TVA	Personne tant que la règle n'est pas écrite
Date de référence	Date de commande, de facture, de paiement, d'expédition	Dépend de la question posée
Source	CRM, ERP, plateforme e-commerce, chacun avec ses retards de synchronisation	La source de référence par domaine, à décider
Jointures et doublons	Une commande multi-lignes comptée trois fois, un client présent en double	Le chiffre le plus bas, généralement

Le point commun : la définition vit dans la tête d'une personne ou dans une formule cachée d'un rapport. Elle n'est ni écrite, ni partagée, ni testée.

Ce qu'est une couche sémantique

Une couche sémantique est l'endroit unique où l'on déclare ce que signifient les indicateurs et les dimensions de l'entreprise, indépendamment de l'outil qui les affiche. Elle traduit « chiffre d'affaires net » en une formule précise sur des tables précises, avec des filtres explicites, et tous les consommateurs (dashboards, exports, agents IA, notebooks) passent par elle.

Deux implémentations dominent sur Google Cloud.

LookML, dans Looker. Des fichiers texte versionnés dans Git décrivent les vues (tables), les dimensions, les mesures et les explores (jointures). Une mesure s'écrit une fois et sert partout dans Looker, dans l'API et dans les agents Conversational Analytics.

measure: net_revenue {
  label: "CA net"
  description: "Montant HT des commandes facturées, remises et avoirs déduits. Date de référence : date de facture."
  type: sum
  sql: ${invoiced_amount_excl_tax} - ${discount_amount} - ${credit_note_amount} ;;
}

dbt, dans BigQuery. dbt porte les transformations (les tables de faits et de dimensions propres) et leurs tests. Sa couche métrique (MetricFlow) permet aussi de déclarer des métriques consultables par plusieurs outils. En pratique, sur une stack Looker, dbt prépare les tables et LookML porte la sémantique exposée aux utilisateurs.

Ce que « gouvernée » ajoute : un propriétaire par indicateur, une revue de code avant tout changement, un historique, des tests automatiques, et une règle simple : si ce n'est pas dans la couche sémantique, ce n'est pas un chiffre officiel.

Pourquoi les tableurs et les rapports ne suffisent pas

Un dictionnaire des indicateurs dans un wiki est utile mais il n'empêche rien : le rapport qui calcule autrement continue de tourner. Un champ calculé dans un rapport Looker Studio est une définition, mais locale et invisible des autres. Un modèle Power BI bien fait est une couche sémantique, mais chaque analyste peut en publier un autre.

La différence décisive est le point de passage obligé. Quand tous les outils lisent la même mesure, personne ne peut produire un autre chiffre sans le faire exprès, et si quelqu'un le fait, l'écart avec le chiffre officiel est visible et traçable.

La méthode en semaines, pas en trimestres

Les projets de « gouvernance des données » échouent quand ils veulent tout définir avant de livrer. La méthode ci-dessous inverse l'ordre : un indicateur contesté, une définition arbitrée, une mesure en production, puis le suivant.

Semaine 1 : choisir et arbitrer

Prenez l'indicateur qui a causé la dernière réunion difficile, presque toujours le chiffre d'affaires. Réunissez les trois personnes qui produisent les trois chiffres, deux heures, avec leurs formules. Faites-leur écrire ensemble une définition en une phrase, avec périmètre, règles, date de référence et source. Quand un désaccord persiste, ce sont deux indicateurs différents qui méritent deux noms : « CA facturé » et « CA commandé », par exemple.

Sortie : un document d'une page par indicateur, signé par un propriétaire métier.

Semaine 2 : préparer la table

Dans BigQuery, avec dbt, construisez ou corrigez la table de faits qui porte l'indicateur : une ligne par événement au grain décidé, les colonnes de montant explicites (invoiced_amount_excl_tax, discount_amount), les clés propres. Ajoutez les tests dbt : unicité de la clé, non-nullité des montants, cohérence avec la source.

C'est ici que se règlent les doublons et les jointures, une fois pour toutes, plutôt que dans chaque rapport.

Semaine 3 : déclarer et exposer

Écrivez la mesure dans LookML avec son label et sa description reprenant la définition signée. Créez ou corrigez l'explore. Branchez le dashboard de direction dessus. Comparez avec les trois anciens chiffres et documentez les écarts : ce document de réconciliation, produit une fois, met fin au débat.

Semaines 4 et 5 : élargir et verrouiller

Passez aux indicateurs suivants (marge, panier moyen, taux de conversion) avec la même méthode, plus vite parce que les tables et les conventions existent. Verrouillez : PR obligatoires sur le dépôt LookML, tests dbt en CI, retrait progressif des anciens rapports qui recalculaient l'indicateur.

Sur un périmètre de dix à quinze indicateurs et trois ou quatre sources, l'ensemble tient en trois à cinq semaines à condition d'avoir un interlocuteur métier disponible deux heures par semaine.

Ce que ça change concrètement

Ce qui s'observe en production : dans un grand groupe industriel, la couche sémantique Looker sur BigQuery sert les dashboards de direction depuis plusieurs années. Le changement le plus visible n'a pas été technique. Les réunions ont cessé de porter sur la provenance des chiffres, et quand un écart apparaît, la question est devenue « quel événement métier l'explique » plutôt que « quel fichier est le bon ».

Le second effet arrive plus tard : quand l'organisation veut brancher des agents conversationnels, la couche sémantique existe déjà. L'agent répond en exécutant la mesure gouvernée, pas en devinant une jointure.

Les erreurs qui font durer des trimestres

Vouloir définir les 200 indicateurs avant de livrer le premier. Le comité de gouvernance se réunit, personne ne décide, le projet meurt.

Confier la définition à la data sans le métier. Une définition techniquement correcte que la finance n'a pas signée sera contestée à la première réunion.

Dupliquer la sémantique. Une définition dans dbt, une autre dans LookML, une troisième dans un modèle Power BI : vous avez reconstruit le problème avec plus d'outils. Une seule couche exposée aux utilisateurs.

Oublier la description. Une mesure sans description oblige chacun à deviner. La définition signée en semaine 1 doit se retrouver mot pour mot dans le champ.

Ne pas retirer les anciens rapports. Tant que l'ancien fichier Excel existe, quelqu'un le présentera.

FAQ

Faut-il Looker pour avoir une couche sémantique ?

Non. dbt avec des tables de faits propres et des métriques déclarées est déjà une couche sémantique, consultable par Looker Studio, des notebooks ou d'autres outils. Looker ajoute l'exposition gouvernée aux utilisateurs finaux, la sécurité au niveau ligne et les explores. Le bon choix dépend du nombre de consommateurs et des exigences de gouvernance.

Combien de temps pour un premier indicateur fiable ?

Deux à trois semaines pour le chiffre d'affaires, si le propriétaire métier est disponible pour l'arbitrage. La suite va plus vite, chaque indicateur supplémentaire réutilise les tables et les conventions.

Que faire des chiffres historiques déjà publiés ?

Ne les réécrivez pas en silence. Publiez la nouvelle définition avec une date d'entrée en vigueur et une table de passage expliquant l'écart avec l'ancien chiffre sur les douze derniers mois. C'est le document qui rassure la direction.

Une couche sémantique ralentit-elle les analystes ?

Au début, oui, parce qu'ils ne peuvent plus inventer un champ dans leur coin. Après un mois, ils vont plus vite : les mesures existent, sont documentées, et ils n'ont plus à refaire les jointures. Les demandes de nouveaux champs passent par une PR, généralement traitée en un jour.

Et ensuite

Si la scène du lundi matin vous est familière, commencez par le document d'une page : un indicateur, trois formules côte à côte, une définition arbitrée. Le reste de la méthode se déroule à partir de là.

Voir l'offre Couche sémantique BigQuery, dbt, Looker, et pour aller plus loin : La stack dbt, BigQuery, Looker et Les prérequis de Conversational Analytics.