Fonctionnalité

Sémantique : relier le métier aux produits de données

Jochen Christ

Co-Founder & CTO, Entropy Data · 2026-04-16

Un schéma indique comment les données sont stockées. Une couche sémantique indique ce qu'elles signifient. Cette page explique ce qu'est une couche sémantique, comment la fonctionnalité Semantics d'Entropy Data la modélise, et comment l'ontologie obtenue se relie aux produits de données et aux Data Contracts.

Le problème

La plupart des plateformes de données savent très bien vous dire quelle table, quelle colonne et quel type. Elles savent beaucoup moins bien vous dire ce que tout cela veut dire. Or les questions qui ralentissent les équipes sont justement de ce second ordre :

• Trois équipes disposent d'une colonne customer_id. Désignent-elles les mêmes clients ? Les commandes passées sans compte sont-elles incluses ?
• La finance et le produit publient tous deux un Gross Merchandise Value. Les chiffres diffèrent. Quelle formule fait foi ?
• Un nouvel analyste a besoin des données de suivi d'expédition. Chercher « shipment » dans une douzaine de schémas remonte quarante colonnes. Lesquelles sont canoniques ?

Ce sont des problèmes de sémantique, pas de schéma, et ils passent mal à l'échelle à mesure que le nombre de produits de données, d'équipes et d'outils d'IA augmente.

Ce qu'est une couche sémantique

Une couche sémantique est une définition nommée et gouvernée de votre domaine, indépendante de toute table ou de tout système particulier. Elle repose sur deux éléments principaux :

• Les concepts : les objets de votre activité, à savoir les entités, les propriétés et les métriques.
• Les relations : la façon dont ces concepts se relient entre eux et aux champs des Data Contracts.

Les concepts

Chaque concept possède un identifiant stable, un nom lisible, une description et un IRI qui permet d'y faire référence depuis des outils externes. Le concept Editorial Object d'EBU Core Plus, par exemple, porte l'IRI suivant :

http://www.ebu.ch/metadata/ontologies/ebucoreplus#EditorialObject

Les concepts vivent dans des espaces de noms (main par défaut) et se déclinent en quatre types :

• Entity (EntityType) : les noms communs de votre domaine. Customer, Order, Article, Shipment.
• Property (ValueType) : un attribut de type primitif. Marqué shared: true, il devient une propriété partagée réutilisable, rattachée à une ou plusieurs entités : Customer Email, SKU, Order ID. Défini une seule fois, référencé à plusieurs endroits.
• Metric (MetricType) : une grandeur mesurable dotée d'une unité, d'un sens d'amélioration et, éventuellement, d'une formule. Gross Merchandise Value, Conversion Rate, Order Fulfillment Time.
• Group (GroupType) : un conteneur pour organiser les concepts par domaine ou par sujet. Sales, Fulfillment, Catalog, Controlling.

Les concepts portent les métadonnées dont dépendent la gouvernance et l'outillage IA : type de données, classification (par exemple PII, sensible, restreint), indicateurs « requis » et « unique », exemples, énumérations, expressions régulières, noms et descriptions multilingues et tags.

Les concepts en YAML

L'ontologie complète s'édite en YAML, ce qui est pratique pour les modifications en masse, la revue de code et le versionnement dans Git. Chaque concept dispose également de son propre éditeur YAML. Le format suit la spécification d'ontologie d'Apache Ossie. Voici un extrait de l'ontologie retail de démonstration :

version: 0.2.0.dev0
name: main
ontology:
  - concept: Order
    id: order
    type: EntityType
    group: Sales
    description: A confirmed purchase placed by a customer in the online shop.
    custom_properties:
      owl:equivalentClass: http://schema.org/Order
    relationships:
      - name: order_id
        type: hasProperty
        roles:
          - concept: Order ID
      - name: customer_id
        type: hasProperty
        roles:
          - concept: Customer ID
      - name: order_status
        type: hasProperty
        roles:
          - concept: order_status
      - name: currency
        type: hasProperty
        roles:
          - concept: currency
  - concept: order_status
    id: order.order-status
    type: ValueType
    extends:
      - String
    description: Lifecycle state of the order.
    enum: [pending, confirmed, shipped, delivered, cancelled, returned]
  - concept: currency
    id: order.currency
    type: ValueType
    extends:
      - String
    description: ISO 4217 currency code of the order total.
    pattern: ^[A-Z]{3}$
    examples: [EUR, USD]

Trois détails méritent l'attention. Une entité référence ses propriétés par des relations hasProperty : Order ID et Customer ID sont des propriétés partagées, définies une fois avec shared: true puis réutilisées d'une entité à l'autre, tandis que order_status et currency sont des propriétés de la commande, chacune étant un composant ValueType à part entière. Une propriété exprime son type de données en étendant un type de valeur intégré comme String, Decimal ou DateTime. Enfin, l'entrée owl:equivalentClass dans custom_properties aligne le concept sur une ontologie externe (schema.org ici), ce qui garde le modèle interne interopérable avec des standards comme GoodRelations ou FIBO.

Des métriques avec formules

Une métrique consigne son unité, le sens dans lequel elle s'améliore et son mode de calcul. La finance, le produit et les outils d'IA disposent ainsi d'une définition unique sur laquelle s'accorder.

ontology:
  - concept: Gross Merchandise Value
    id: gmv
    type: MetricType
    group: Controlling
    description: Total value of all placed orders before refunds, returns, and discounts.
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount)"

  - concept: Average Order Value
    id: average_order_value
    type: MetricType
    group: Sales
    unit: EUR
    better_when: higher
    formula: "SUM(order.total_amount) / COUNT(DISTINCT order.id)"

Les relations

Les concepts se relient entre eux par des relations orientées et typées. Les types les plus courants sont hasProperty, relatedTo, measures et derived_from ; le sous-typage s'exprime avec extends. Une relation se déclare sur le concept qui joue son premier rôle, ce concept est donc implicite : roles ne liste que les autres participants, et verbalizes porte des tournures en langage naturel que les agents IA peuvent exploiter.

ontology:
  - concept: Customer
    relationships:
      - id: customer_places_order
        name: places
        type: relatedTo
        roles:
          - concept: Order
        multiplicity: OneToMany
        verbalizes:
          - "{Customer} places {Order}"

  - concept: Average Order Value
    relationships:
      - id: aov_derived_from_gmv
        name: derived_from
        type: derived_from
        roles:
          - concept: Gross Merchandise Value
        verbalizes:
          - "{Average Order Value} derived from {Gross Merchandise Value}"

La page de chaque concept affiche ses arêtes entrantes et sortantes, ce qui permet de parcourir l'ontologie dans les deux sens. La vue diagramme présentée en haut de cette page restitue le même espace de noms sous forme de graphe interactif, avec déplacement, zoom et accès direct à la page de n'importe quel concept d'un simple clic sur son nœud.

Des traductions en plusieurs langues

Chaque concept, propriété et relation peut porter la traduction de son nom et de sa description dans autant de langues que nécessaire. Les traductions sont stockées comme des entrées custom_properties marquées par la langue, telles que name@de ou description@fr, exposées via le point d'accès SPARQL et affichées dans l'interface selon la langue choisie par l'utilisateur. Une même ontologie peut ainsi servir des analystes anglophones, des product managers francophones et des auditeurs germanophones à partir d'une source unique.

ontology:
  - concept: Customer
    id: customer
    type: EntityType
    group: Customers
    description: A natural person who places orders in the online shop.
    custom_properties:
      name@de: Kunde
      name@fr: Client
      description@de: Eine natürliche Person, die Bestellungen im Online-Shop aufgibt.
      description@fr: Une personne physique qui passe des commandes dans la boutique en ligne.

Les ontologies sectorielles livrées avec Entropy Data sont traduites d'emblée. EBU Core Plus, par exemple, fournit libellés et descriptions en anglais, en allemand et en français pour chaque classe et chaque propriété.

Relier les produits de données et les Data Contracts

Une couche sémantique n'a d'utilité que si les données qui l'implémentent pointent vers elle. Entropy Data s'appuie sur le mécanisme authoritativeDefinitions de l'Open Data Contract Standard pour relier les concepts aux données qui les concrétisent, à trois niveaux :

1. Sur un produit de données (ODPS), pour le représenter dans son ensemble.
2. Sur un Data Contract ou sur l'un de ses objets de schéma.
3. Sur un champ précis à l'intérieur d'un schéma de contrat.

Le même lien peut s'écrire directement en YAML ODCS. Extrait d'un contrat de démonstration sur les expéditions :

properties:
  - name: shipment_id
    businessName: Shipment ID
    logicalType: string
    primaryKey: true
    authoritativeDefinitions:
      - type: "semantics"
        url: "https://demo.entropy-data.com/my-organization/semantics/main/shipment_id"
  - name: order_id
    authoritativeDefinitions:
      - type: "semantics"
        url: "https://demo.entropy-data.com/my-organization/semantics/main/order_id"

Le marqueur type: "semantics" indique à Entropy Data que l'URL pointe vers un concept sémantique, et le lien apparaît alors comme une référence cliquable sur la page du contrat. Sur la page du concept, Entropy Data liste à son tour tous les produits de données et Data Contracts qui le référencent : une question comme « quels jeux de données contiennent des adresses e-mail de clients ? » trouve ainsi une réponse immédiate.

À quoi sert Semantics

Une recherche par le sens

Les consommateurs cherchent Shipment et trouvent tous les produits de données qui implémentent ce concept, quel que soit le nom des colonnes sous-jacentes.

Des définitions cohérentes d'une équipe à l'autre

Une seule définition de Customer Email est référencée par plusieurs Data Contracts. Il suffit de passer sa classification à « sensible » pour que toutes les références soient mises à jour.

Une source de vérité unique pour les métriques

Le GMV, le taux de conversion et les marges sur coûts variables disposent de définitions canoniques assorties de formules, ce qui supprime l'ambiguïté qui s'accumule habituellement dans les tableurs.

Du contexte pour les agents IA

Les LLM ignorent ce que votre entreprise entend par Active Customer ou Contribution Margin 2. Lorsque des agents accèdent aux données via notre serveur MCP, Semantics leur fournit ce contexte : ils font les jointures sur les bonnes clés et s'appuient sur les bonnes définitions de métriques.

Démarrer avec une ontologie sectorielle

Nul besoin de modéliser votre domaine en partant de zéro. Entropy Data est livré avec des ontologies prêtes à importer pour plusieurs secteurs. Ouvrez Studio, allez dans Semantics et utilisez Add → Import Industry Standard :

• GoodRelations (e-commerce)
• FIBO (finance)
• EBU Core Plus (médias)
• CGMES (énergie)
• IDMP (pharmacie)
• EPCIS (chaîne d'approvisionnement)
• IATA ONE Record (fret aérien)
• TM Forum SID (télécoms)

Vous pouvez aussi téléverser vos propres fichiers RDF/OWL (Turtle, OWL, RDF/XML, N-Triples, N3, JSON-LD), ou interroger l'ontologie par programmation via le point d'accès SPARQL exposé sur /api/semantics/sparql.

Standards ouverts : Apache Ossie

Entropy Data s'engage en faveur des standards ouverts pour la couche sémantique et a rejoint le projet Apache Ossie, anciennement l'initiative Open Semantic Interchange (OSI). Apache Ossie est un effort open source, indépendant de tout éditeur, visant à normaliser l'échange de modèles sémantiques entre plateformes de BI, agents IA et outils d'analyse, afin qu'une même définition d'entité ou de métrique reste cohérente dans tout votre écosystème. Nous prendrons en charge nativement le futur standard Ossie Ontology dans Semantics, aux côtés de l'Open Data Contract Standard et de l'Open Data Product Standard de Bitol pour les Data Contracts et les produits de données.

La place de Semantics dans Entropy Data

• Marketplace s'appuie sur les concepts sémantiques pour la recherche.
• Studio est l'espace où les experts métier et les Data Product Owners entretiennent les concepts et les relient aux contrats.
• Governance réutilise les classifications sémantiques (PII, sensible, etc.) dans des politiques transverses.
• Le serveur MCP s'appuie sur Semantics pour ancrer les appels d'outils des LLM dans votre vocabulaire métier.

Pour commencer

Semantics est disponible derrière un feature flag :

• Entropy Data Cloud : écrivez-nous pour l'activer sur votre organisation.
• Auto-hébergé : définissez APPLICATION_SEMANTICS_ENABLED=true, puis redémarrez l'application.

Pour essayer Semantics sans rien installer, ouvrez la démo et rendez-vous dans Studio → Semantics. La démo embarque les principaux standards sectoriels : allez dans Studio → Semantics → Add → Import Ontology pour explorer les standards fournis ou téléverser votre propre ontologie.

À propos de l'auteur

Jochen Christ

LinkedIn de Jochen Christ

Co-Founder & CTO, Entropy Data

Jochen construit des outils pour faire travailler ensemble les données, les gens et l'IA. Il est l'auteur du site Data Mesh Architecture, mainteneur de la Data Contract CLI et membre du TSC du projet Bitol de la Linux Foundation, qui héberge l'Open Data Contract Standard.

Échanger avec Jochen →