Couche sémantique, ontologie, contexte : qui définit « client » ?

Le plus difficile n'est pas de compter. C'est de décider ce qui mérite d'être compté.

Une équipe pose à son assistant analytique une question en apparence simple : « Combien de clients actifs avons-nous ? » L'assistant renvoie immédiatement un chiffre. Un second outil en renvoie un autre. Les deux requêtes s'exécutent. Aucune base de données ne proteste.

Avant de débattre du modèle le plus intelligent, examinez la question. Qu'est-ce qu'un client : une personne, un compte, un foyer ou un contrat ? Qu'est-ce qui le rend actif ? Quelle date s'applique ? La réponse exige une définition, pas seulement une explication plus convaincante.

Couche sémantique, ontologie, contexte, couche métier : ces termes décrivent des responsabilités utiles. Ils ne forment pas un ensemble universel de cases étanches. L'exemple qui suit est fictif, et l'architecture proposée est une approche de conception, pas l'annonce de nouvelles capacités DUKE.

Faites le test avant de nommer les couches

Imaginez cet instantané, daté du 30 septembre 2026. La correspondance d'identité est supposée vérifiée pour l'exemple. P-007 est la même personne sur les trois lignes. C-101 et C-102 sont deux contrats distincts, tous deux actifs à cette date.

Fiche CRM | Personne | Contrat | Statut
R-001      | P-007    | C-101   | Actif
R-002      | P-007    | C-101   | Actif
R-003      | P-007    | C-102   | Actif

Trois comptages corrects de trois choses différentes. Les appeler tous « clients » ne les rend pas interchangeables.

La bonne réponse n'est pas forcément « un ». C'est d'établir l'unité visée. Si la métrique approuvée compte les personnes titulaires d'au moins un contrat actif, la réponse est un. Si la demande porte sur les contrats actifs, c'est deux. Si la question opérationnelle concerne les fiches CRM à revoir, les trois lignes comptent. « Clients actifs » reste incomplet tant que le sens métier n'est pas fixé.

Le schéma dit où vivent les données

Le schéma physique fournit tables, colonnes, types et clés. Ici, il indique où sont stockés person_id, contract_id et status. Il ne dit pas, à lui seul, si un rapport commercial doit compter des personnes ou des contrats.

Première recommandation : rendre explicite l'unité physique de chaque jeu de données. Un export CRM peut contenir plusieurs représentations d'un même contrat sans prouver que l'entreprise a gagné un client. Avant de générer du SQL, écrivez ce que représente une ligne et comment les jointures peuvent changer cette unité.

Test : joindre une autre table ne doit jamais changer silencieusement ce que l'on compte.

La couche sémantique donne son sens à la mesure

Une couche sémantique analytique centralise mesures, dimensions et relations pour que les outils consomment une définition cohérente. dbt décrit ainsi son Semantic Layer : des métriques définies sur des modèles et réutilisées en aval, avec des modèles sémantiques qui décrivent entités et dimensions [D1][D2].

Ici, nous enregistrerions un contrat de métrique : nom, responsable métier, unité, population, règle de statut, date de référence et implémentation. Par exemple : « personnes vérifiées distinctes ayant au moins un contrat actif à la date de référence ». Une autre métrique peut compter les contrats actifs, mais sous un autre nom.

Le test pratique est l'exécution. La requête appelle-t-elle réellement la définition approuvée ? Une définition rangée dans un document ne garantit pas que chaque requête écrite à la main la respecte. Nous conserverions la version de la métrique et la requête exécutée avec la réponse, pour relier le chiffre à la définition utilisée.

L'ontologie décrit le domaine, pas seulement une formule

Une ontologie exprime des concepts et leurs relations. La présentation OWL 2 du W3C décrit classes, propriétés et individus dotés d'un sens formel. C'est un repère utile, pas une obligation d'adopter OWL [D3].

Ici, Personne, Contrat et Fiche CRM sont des concepts différents. Une personne détient un contrat. Une fiche CRM représente une information sur cette relation. Une personne peut aussi être bénéficiaire d'un autre contrat ; ce rôle ne doit pas être confondu avec celui de souscripteur.

Cette représentation ne fabrique pas de preuve d'identité. Nous avons posé que P-007 était vérifié. Dans un vrai système, rapprocher deux fiches d'une même personne exige un processus de résolution d'identité, une traçabilité et une gestion de l'incertitude. Certains produits emploient « ontologie » plus largement : Palantir décrit une ontologie opérationnelle incluant objets, relations, actions et fonctions [D6]. C'est un périmètre produit, pas une règle générale.

Le contexte, c'est ce que l'agent reçoit pour cette tâche

Le contexte peut contenir la demande, les définitions retenues, des informations de schéma, des résultats d'outils et l'historique utile. L'approche d'Anthropic de l'ingénierie du contexte porte sur la sélection et l'entretien de l'information utile pendant le travail de l'agent. Elle ne donne pas la même autorité à tous les documents disponibles [D4].

Pour notre question, nous fournirions la version approuvée de la métrique, la date demandée, les identifiants pertinents et toute ambiguïté non résolue. Nous n'ajouterions pas en vrac un vieux glossaire commercial, un message informel et la définition approuvée sans distinguer leur statut.

« La source de vérité gouverne la définition. La fenêtre de contexte en présente la partie utile à l'agent. »

« Couche métier » a besoin d'un qualificatif

Dans SAP BusinessObjects, une business layer est un ensemble d'objets de métadonnées associés à des définitions SQL ou MDX. Ses dimensions et mesures recouvrent ce que d'autres produits appellent sémantique analytique [D5]. Dans une discussion applicative, la logique métier peut au contraire désigner des conditions d'éligibilité, des plafonds de remise ou des règles d'approbation. Demandez quel sens est visé avant d'ajouter une case au schéma d'architecture.

La distinction compte quand on passe de « compter les clients actifs » à « leur envoyer une offre ». Être client actif n'établit pas l'éligibilité à l'offre. Une action exige ses propres conditions et contrôles. Des plateformes implémentent une logique d'action réutilisable avec validation, comme les action types de Palantir [D7] ; cet exemple ne dit rien de ce que d'autres produits ont livré.

Suivez une question à travers le système

• 1. Fixer l'unité et la date de référence.
• 2. Identifier la définition analytique approuvée.
• 3. Vérifier les relations et la correspondance d'identité qu'elle exige.
• 4. Confirmer ce que l'agent a réellement reçu.
• 5. Examiner la requête exécutée et l'explication renvoyée.

Pour une action proposée, étendez la revue à l'éligibilité, l'autorisation, l'approbation et l'exécution, sans confier ces contrôles à la seule formulation d'un prompt. Le test d'acceptation devrait inclure une demande volontairement ambiguë : un système qui demande « des personnes ou des contrats ? » fait quelque chose d'utile. Il doit aussi résister à une fiche CRM en double sans gonfler une métrique par personne, et à un changement de date sans appliquer le statut du jour au passé. Ce sont des tests proposés pour l'exemple, pas des résultats de benchmark.

Comptez les responsabilités, pas les couches

L'objectif n'est pas d'acheter quatre produits parce que quatre noms figurent sur un schéma. Un système plus petit peut combiner plusieurs responsabilités, à condition que leur propriété et leur comportement restent explicites. Demandez ce qui définit la métrique, ce qui modélise les objets, ce qui fournit le contexte et ce qui encadre l'opération. Puis testez ces responsabilités avec une question dont la simplicité apparente cache un choix important.

Un, deux ou trois clients ? Dites-nous d'abord ce que vous comptez.

Références principales

• [D1] dbt Labs, dbt Semantic Layer.
• [D2] dbt Labs, Semantic models.
• [D3] W3C, OWL 2 Web Ontology Language: Overview.
• [D4] Anthropic, Effective context engineering for AI agents.
• [D5] SAP, Business layers (SAP BusinessObjects).
• [D6] Palantir, Ontology overview.
• [D7] Palantir, Action types overview.