Trois éditeurs, trois présentations, trois termes pour ce qui se trouve entre l’agent et vos données. L’un vend une couche sémantique, l’autre une ontologie, le troisième un graphe de connaissances. Ces termes ne sont pas interchangeables. Le premier définit des indicateurs, le deuxième définit le métier, le troisième stocke les faits. Et la vraie question est de savoir à qui appartiennent les définitions.
Trois termes, trois questions
Les définitions sont bien établies, et les éditeurs de catalogues de données les formulent clairement. Une couche sémantique répond à « comment calcule-t-on cet indicateur ? » : elle projette la logique métier sur les données pour que le chiffre d’affaires soit calculé de la même manière dans tous les outils.[1] Une ontologie répond à « quelles sont les choses de notre métier, et comment sont-elles liées ? » : elle définit les entités et leurs relations dans un schéma formel, lisible par la machine.[1:1] Atlan le résume : une couche sémantique vous dit quel est votre chiffre d’affaires, une ontologie vous dit ce qu’est un client.[1:2] Alation le dit dans l’autre sens : la couche sémantique répond à « quel est le chiffre ? », l’ontologie définit ce qui doit se passer quand un événement survient.[2]
Un graphe de connaissances est une troisième chose. L’ontologie définit le schéma ; le graphe stocke les instances, ce qui permet la recherche à travers les entités, la traçabilité et le parcours des relations.[1:3] L’un est la définition, l’autre la donnée.
Nous partageons ces définitions. Nous divergeons sur une question que les présentations évitent : qui écrit l’ontologie, et l’agent y est-il tenu ?
Ce que l’agent attend de la couche sémantique
Un chiffre calculé de la même manière à chaque fois. Atlan parle d’un accès gouverné et déterministe aux indicateurs, et note qu’un agent qui s’appuie sur une couche sémantique seule produit des résultats précis mais superficiels.[1:4] La couche sémantique sait additionner une colonne. Elle ne sait pas ce que représente la colonne, si le client du CRM est le compte du grand livre, ni pourquoi certaines exceptions existent.[3] Un agent qui a des formules mais aucun modèle du métier calculera la mauvaise chose correctement.
Ce que l’agent attend de l’ontologie
Les entités, les relations, les actions, les règles, et les cas particuliers qui représentent l’essentiel du travail, tous formulés explicitement, dans le vocabulaire de ceux qui font le travail, et contraignants pour la machine.[4] Ni déduits des données, qui n’enregistrent que ce qui a été mesuré. Ni devinés par un modèle, qui comblera les trous par une invention plausible. Définis, versionnés, débattus et possédés.
Deux mots comptent ici. Le premier est contraignant. Un vocabulaire que l’agent peut consulter est un dictionnaire. Un vocabulaire dont l’agent ne peut pas sortir est une contrainte, et seule une contrainte rend une action assez prévisible pour qu’une personne nommée la valide. Le second est possédé. L’ontologie est le seul artefact que les équipes métier et les ingénieurs modifient ensemble, et là où ils travaillent enfin à partir des mêmes définitions.[4:1] Une ontologie que les équipes métier ne peuvent pas modifier est une spécification écrite sur elles par quelqu’un d’autre.
Le graphe de connaissances est l’endroit où les définitions rencontrent la donnée. Un graphe sans ontologie est un tas de liens. Un graphe sous une ontologie explicite est une carte : chaque nœud est une instance de quelque chose que l’organisation a nommé, chaque relation une relation qu’elle a définie, et chaque chiffre remonte à sa ligne source.
Pourquoi l’ontologie doit être la vôtre
C’est là que nous divergeons des éditeurs : sur la propriété, pas sur les définitions.
Les modèles convergent vite. Le calcul se vend comme une commodité. Les talents circulent. Ce qui ne circule pas, c’est le modèle explicite de vos propres opérations : vos entités, vos règles, les exceptions ajoutées après un incident ou un courrier du régulateur, les mots de vos équipes.[5] Sa valeur s’accroît avec le temps : chaque exception résolue s’y ajoute, et chaque règle rendue explicite s’applique ensuite à tous les agents.[5:1]
Un éditeur qui détient ce modèle comme configuration de son produit détient votre avantage le plus durable comme une ligne de son contrat de renouvellement. Quand le produit part, la configuration part avec lui, et avec elle la raison d’être de vos processus. Une organisation qui garde un processus mais en perd la raison finit par suivre des règles que personne ne comprend.[6] Une ontologie écrite dans votre vocabulaire, sous une forme que vous pouvez emporter, survit aux personnes qui l’ont écrite.
Alation propose une couche supplémentaire au-dessus de l’ontologie, une « couche de contexte d’entreprise », qui indique à l’agent comment trancher les cas d’arbitrage et apprend de ses propres interactions.[2:1] Nous ne sommes pas d’accord. Une règle qu’un agent a apprise de son propre comportement est une règle que personne n’a définie ni validée. Les arbitrages reviennent à une personne nommée. La règle qui les tranche a sa place dans l’ontologie, écrite par ceux qui font le travail, et contraignante pour tous les agents qui suivent.
Notre position
Galahad ne déduit pas votre ontologie de vos données et ne laisse pas un modèle deviner la structure que vos systèmes n’ont jamais enregistrée. Nous ne détenons pas le modèle de votre métier comme notre configuration. Chaque déploiement sert une seule organisation, avec sa propre ontologie, qui vous appartient et que vous pouvez inspecter.[7] Si elle ne peut pas partir avec vous, elle n’a jamais été à vous.
Les questions à poser à un éditeur
- Montrez-moi l’ontologie. Est-ce un document que je peux lire, versionner et exporter, ou un paramètre de votre produit ?
- Qui la modifie : mes équipes, vos consultants, ou un modèle ?
- Le vocabulaire est-il contraignant pour l’agent, ou seulement indicatif ?
- Quand l’agent rencontre un cas que l’ontologie ne couvre pas, que fait-il, et qui est prévenu ?
- Si je mets fin au contrat, que me reste-t-il ?
Monarch repose sur une ontologie qui vous appartient : vos entités, vos règles, les mots de vos équipes. Voyez-le sur vos données.
Atlan, Ontology vs semantic layer : les ontologies définissent les concepts et relations du domaine dans un schéma formel, lisible par la machine ; les couches sémantiques projettent la logique métier sur les données pour des métriques cohérentes ; un graphe de connaissances stocke les instances que l’ontologie définit ; les couches sémantiques donnent un accès gouverné et déterministe aux métriques et, seules, des résultats précis mais superficiels. Source ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Alation, Semantic layer vs ontology vs enterprise context layer : la couche sémantique répond à « quel est le nombre », l’ontologie définit ce qui doit se passer ensuite quand un événement survient, et la couche de contexte d’entreprise livre aux agents autonomes le contexte de l’arbitrage et s’améliore à partir de leurs interactions. Source ↩︎ ↩︎
Galahad, l’entreprise : chaque déploiement sert une seule organisation, avec sa propre ontologie, qui vous appartient et que vous pouvez inspecter. Le lire ↩︎