Modéliser la couche sémantique

Le modèle sémantique est la couche entre votre entrepôt de données et l’agent Streya. Il définit, une seule fois, ce que vos données signifient — quelles tables comptent, comment elles se joignent, ce que « revenu » ou « client actif » veut réellement dire — afin que chaque réponse soit calculée à partir des mêmes définitions approuvées.

Aujourd’hui, les modèles sémantiques sont construits avec l’équipe Streya lors de l’intégration. Cette page explique de quoi le modèle est fait et quoi préparer pour que ce processus se déroule rapidement.

Les deux composantes de base

Les cubes modélisent les données. Chaque cube correspond à une table (ou à une requête) de votre entrepôt de données et définit :

• Dimensions — les champs servant à regrouper et à filtrer : dates, catégories, régions, statuts.
• Mesures — les indicateurs : revenus, nombre de commandes, panier moyen, clients distincts.
• Jointures — la façon dont ce cube se rattache aux autres (commandes → clients, commandes → produits).

Les vues assemblent les cubes pour les utilisateurs finaux. Une vue combine un ou plusieurs cubes en un seul ensemble de données soigné — uniquement les champs qui comptent, avec des noms clairs. Les vues sont ce que l’agent voit et analyse; les cubes sont la tuyauterie en dessous.

tables de l’entrepôt  →  cubes (modélisation)  →  vues (ensembles de données soignés)  →  agent

Un espace de travail typique compte une poignée de vues, chacune conçue autour d’une tâche : sales_analytics pour les questions de revenus, inventory_health pour les questions de stocks, et ainsi de suite.

Un indicateur, une définition

C’est la chose la plus importante qu’accomplit un modèle sémantique, et elle mérite qu’on s’y attarde : il devrait exister exactement un seul chemin vers chaque indicateur. Chaque indicateur clé de performance (KPI) qui compte pour votre entreprise — revenu net, clients actifs, marge — devrait avoir une définition unique et convenue, et cette définition devrait vivre dans le modèle et nulle part ailleurs.

La raison est simple. Quand un indicateur peut se calculer de deux façons, l’agent doit deviner laquelle vous aviez en tête — et chaque personne qui lit la réponse aussi. Deux définitions du « revenu net » ne vous donnent pas de la flexibilité; elles vous donnent deux nombres qui se contredisent, sans aucun moyen de savoir lequel est juste.

Prenons un cas limite concret : les commandes non exécutées comptent-elles dans le revenu net? Il y a un argument raisonnable dans chaque sens. Mais le rôle du modèle n’est pas de retenir les deux arguments — c’est de trancher la question. Décidez d’avance, oui ou non, encodez cette unique réponse dans la mesure, et tenez-vous-y. Ne définissez pas un net_revenue et un net_revenue_incl_unfulfilled en laissant l’agent choisir; choisissez celui que votre entreprise veut dire quand elle parle de « revenu net » et faites-en la définition.

Bien faire cet exercice est réellement difficile dans une vraie entreprise — les KPI sont souvent flous, portés par des équipes différentes ou calculés un peu différemment d’une feuille de calcul à l’autre. Cette difficulté est précisément ce qui justifie d’y consacrer du temps. Arrêter une définition unique pour chaque indicateur est le geste au plus fort effet de levier de toute la modélisation : chaque réponse que l’agent donnera en aval hérite de cette clarté.

Les descriptions : comment l’agent apprend à connaître votre entreprise

Chaque champ de cube et chaque vue peut porter une description, et ces descriptions sont lues par l’agent lorsqu’il analyse vos données. C’est là que vit votre connaissance d’affaires :

• Sur une vue : ce qu’est l’ensemble de données, son grain et quand l’utiliser. « Une ligne par (mois × client × produit). À utiliser pour les tendances de revenus et les questions de composition de la clientèle. »
• Sur un champ : ce qu’il signifie et comment l’utiliser. « Les retours sont enregistrés en quantités négatives. » « La devise est le CAD. » « Utilisez net_sales pour les rapports externes, pas gross_sales. »

C’est la différence entre une IA générique et une IA qui répond comme quelqu’un qui connaît votre entreprise. Plus vous en faites ressortir pendant la modélisation, meilleures seront les réponses.

Ce qui fait une bonne description de champ

Un nom de champ comme gmv ou acct_status ne dit presque rien à l’agent. Une bonne description fournit ce qu’un nouvel analyste aurait à demander à un collègue. Les éléments les plus utiles à inclure :

• Une définition d’affaires en langage courant. Ce que le champ représente réellement, dans les termes qu’emploie votre entreprise. « Valeur brute des marchandises — valeur totale des biens vendus avant rabais, retours ou frais. »
• Les termes équivalents et les acronymes. Les autres noms que les gens donnent à ce champ, pour que l’agent relie une question à la bonne colonne. « Aussi appelé GMV, chiffre d’affaires brut ou “ventes brutes” par l’équipe des finances. »
• La liste des valeurs, quand l’ensemble est fini. Pour les champs de statut, de catégorie ou d’énumération, précisez chaque valeur et sa signification. « active, trial, churned, paused. paused est une suspension temporaire et compte toujours comme un client; churned non. »
• Les conventions et les pièges. Conventions de signe, unités, devise, problèmes connus de qualité des données. « Les retours sont des quantités négatives. La devise est le CAD. »

Quoi préparer pour une séance de modélisation

Vous n’avez rien de technique à rédiger. Apportez :

1. Les questions auxquelles vous voulez des réponses. Cinq à dix vraies questions que votre équipe pose (« quels comptes sont en déclin? », « quelle est notre marge par canal? »). Le modèle est conçu à rebours, à partir de celles-ci.
2. Où vivent les données. Quelles tables ou extractions contiennent les ventes, les clients, les produits, les cibles.
3. Vos définitions. Comment vous calculez les indicateurs clés — ce qui compte comme revenu, quels statuts sont exclus, les particularités du calendrier financier.
4. Les pièges. Conventions de signe, codes d’article dupliqués d’un canal à l’autre, problèmes connus de qualité des données, tout ce dont vous avertiriez un nouvel analyste. Ces éléments deviendront des descriptions de champ.

Faire évoluer le modèle

Un modèle sémantique n’est jamais terminé au premier jour. Quand l’agent se trompe — utilise le mauvais indicateur, interprète mal une convention — c’est généralement une description qui manque, et la correction tient en une ligne. Signalez-le à votre contact Streya, ou notez-le directement dans une conversation; raffiner le modèle est une partie normale et continue de l’utilisation de Streya.

Aller plus loin

Quand vous serez prêt à lire ou à rédiger vous-même les fichiers du modèle :

• Référence des cubes — schéma YAML complet des cubes.
• Référence des vues — schéma YAML complet des vues.