Ressources · Exemples

Paiements contextuels

Une extension téléchargeable et autonome qui illustre la couche d'ontologie contextuelle appliquée aux paiements ISO 20022 — contexte de liaison par source, transformations par propriété, contrats de données, ancres de normes et alias de concepts selon la direction. Elle inclut ses propres données de démonstration.

L'exemple Paiements contextuels est une démonstration téléchargeable et interactive d'une ontologie contextuelle. Contrairement à toutes les autres extensions d'exemple, elle inclut ses propres données de démonstration sous forme de sources de données déclaratives : un déploiement pleinement opérationnel ne nécessite donc aucun import CSV. (Une solution de repli CSV est proposée ci-dessous pour les environnements de développement local où le réconciliateur de sources de données ne fonctionne pas.)

Vous découvrez le sujet ? Lisez d'abord Ontologies contextuelles : ce qu'est une ontologie contextuelle, quand vous en avez réellement besoin et quel problème elle résout. Cette page est la démonstration ; l'autre en explique le pourquoi.

Le scénario

Vous gérez des opérations de paiement. Votre ontologie canonique contient un concept Payment et quelques concepts de parties (Counterparty, Beneficiary, Originator). Les données arrivent toutefois d'un système bancaire central sous la forme d'un relevé ISO 20022 pacs.008, dans lequel :

les montants sont exprimés en centimes entiers (1234556), et non en euros,
les horodatages sont en UTC, et non dans votre fuseau de comptabilisation,
et le terme « Counterparty » désigne une partie différente selon que le transfert est entrant ou sortant.

Une liaison simple aplatirait tout cela et le perdrait. Cette extension enregistre au contraire le contexte de la source, normalise les valeurs avec des transformations déclarées, ancre les concepts à ISO 20022 / FIBO / LEI et enregistre des alias dépendant de la direction, de sorte que chaque Payment projeté soit fiable et explicable. Il vous suffit ensuite de l'installer et de la voir fonctionner.

Ce que l'exemple démontre

Un concept canonique Payment alimenté par un relevé ISO 20022 pacs.008, modélisé pour que chaque valeur projetée porte son sens. Chaque point correspond à un élément constitutif :

bindingContext — la liaison de paiement indique que ce flux est un relevé ISO 20022 pacs.008 provenant de core_banking_x, comptabilisé en BE, avec une confiance de correspondance de 96 %, valide à partir du 2025-01-01.
transformMap — des transformations par propriété superposées à la correspondance de colonnes plate : amount_minor, exprimé en unités mineures entières, est divisé par 100 pour produire amount en unité majeure ; settled_at_utc, en UTC, est normalisé vers Europe/Brussels. Les deux sont marquées avec perte afin d'apparaître dans la provenance.
dataContract — paymentId, amount et currency doivent être projetés ; currency doit respecter ISO 4217 ; amount doit être positif. Le contrat appartient à payments-platform-team.
anchors — des ancres de normes sur les types d'objets et les propriétés (ISO 20022 FIToFICstmrCdtTrf/IntrBkSttlmAmt/Ccy, FIBO LegalEntity, ISO 17442 LEI) rendent un concept trouvable par son identifiant externe.
aliases — la démonstration phare de la réconciliation : le même terme local "Counterparty" se résout vers un concept canonique différent selon le contexte.

Réconciliation, pas de gagnant imposé. Le résolveur d'alias présente tous les candidats correspondants, classés par spécificité du contexte puis par confiance ; il ne réduit jamais des sources divergentes à un enregistrement doré silencieux. Il en va de même pour les liaisons : la divergence est consignée dans l'enveloppe provenance, et non masquée.

Télécharger

L'extension est une archive .scrydon-extension.tar.gz téléchargeable ; elle n'est pas préinstallée avec la plateforme.

contextual-payments.scrydon-extension.tar.gz — dernière version.
scrydon-pack-contextual-payments-1.0.3.scrydon-extension.tar.gz — version figée.

L'archive contient trois types de contenu : l'ontologie et deux sources de données déclaratives (iso20022_pacs008_payments, core_banking_counterparties) qui chargent les lignes de démonstration. Ni API externe ni identifiants : les sources de données émettent des lignes statiques intégrées selon une planification.

Installer

Charger l'extension

Téléchargez l'archive ci-dessus. Dans votre déploiement Scrydon, ouvrez Settings → Platform → Extensions → Sources, cliquez sur Upload a pack (one-off), déposez le .tar.gz sur la zone de dépôt, cochez l'acceptation de l'extension non signée, puis cliquez sur Upload. Elle apparaît dans le catalogue de votre organisation sous le nom Contextual Payments v1.0.3, avec trois contributions : 1 ontologie, 2 sources de données.

L'activer pour un environnement d'espace de travail

Ouvrez Analytics → Marketplace et installez Contextual Payments pour votre environnement d'espace de travail actif. Les deux sources de données sont planifiées par environnement d'espace de travail par le réconciliateur de sources de données de la plateforme.

Attendre la première exécution

Les sources de données émettent leurs lignes lors de la première exécution planifiée (cela peut prendre jusqu'à une minute après l'installation, le temps que le réconciliateur les planifie). Une fois l'exécution passée, deux tables gérées apparaissent sous Analytics → Tables : iso20022_pacs008_payments (6 lignes) et core_banking_counterparties (5 lignes).

Aucune table après une ou deux minutes ? Les sources de données intégrées ne chargent des lignes que si le réconciliateur de sources de données et le planificateur Dapr de la plateforme fonctionnent, ce qui n'est souvent pas le cas dans un environnement de développement purement local. Si iso20022_pacs008_payments et core_banking_counterparties n'apparaissent jamais sous Analytics → Tables, importez manuellement les mêmes données de démonstration :

Téléchargez les deux fichiers CSV :
- iso20022_pacs008_payments.csv (6 paiements)
- core_banking_counterparties.csv (5 contreparties)
Analytics → Tables → upload pour chacun. Nommez chaque table exactement iso20022_pacs008_payments / core_banking_counterparties : les liaisons se résolvent en faisant correspondre ce nom logique, et un autre nom les laisse not ready.

Les colonnes CSV sont exactement celles que référencent les liaisons : dès que les tables existent, les liaisons se résolvent automatiquement et les ISSUES de /graph disparaissent.

Vous mettez à niveau une copie antérieure ? Recharger l'extension ne suffit pas : vous devez aussi la réactiver pour l'environnement d'espace de travail. L'installation suit un modèle en deux étapes (ADR 2026-05-30-two-stage-packs-install-vs-instantiate) :

Étape 1 — charger le .tar.gz via Settings → Platform → Extensions → Sources → Upload a pack (one-off) installe ou met à jour l'ontologie au niveau de l'organisation et ses liaisons.
Étape 2 — Analytics → Marketplace → install for this workspace-environment installe une copie distincte au niveau de l'espace de travail de l'ontologie et des liaisons. C'est cette copie que le workbench et /graph affichent (elle est libellée « … (Workspace · <env>) »).

Un nouveau chargement ne réconcilie que la copie de l'Étape 1 (organisation). Pour appliquer le correctif à la copie de l'espace de travail que vous consultez réellement, adoptez la nouvelle version dans l'espace de travail. Lorsqu'un nouveau chargement rend disponible une version plus récente du catalogue, une option « Newer version available → Update to v<x> » apparaît à deux endroits :

l'Ontology Designer (/ontology) affiche une bannière Update au-dessus du workbench lorsque l'ontologie sélectionnée est en retard sur la version du catalogue de son extension ;
Analytics → Marketplace affiche un bouton Update to v<x> sur la ligne de l'extension.

Cliquer sur Update relance l'activation de l'espace de travail à la dernière version, ce qui réconcilie en place identityColumns / columnMap / transformMap / bindingContext / source de la liaison de l'espace de travail : aucune dissociation manuelle, aucune suppression préalable. (Les mises à jour ne sont jamais appliquées silencieusement : un propriétaire de l'espace de travail clique sur Update pour les adopter, de sorte qu'une ontologie d'espace de travail personnalisée n'est jamais écrasée à votre insu.)

Les instances silver_table sont projetées à la lecture, directement depuis la table de la source de données ; rien n'est matérialisé. Dès que la liaison de l'espace de travail est réconciliée, un rafraîchissement de /graph affiche donc les valeurs corrigées. Il n'y a aucune donnée promue obsolète à nettoyer.

Si vous avez installé une version précoce dont les identityColumns étaient erronées, vous avez peut-être vu chaque paymentId s'afficher comme null, avec une issue « Table missing columns: paymentId » sur /graph. Il s'agissait d'un défaut de l'extension : les colonnes d'identité doivent être la colonne physique payment_id de la table, et non le slug de propriété paymentId. Il est corrigé dans la v1.0.2, et la v1.0.3 ajoute les types de liens qui relient le graphe. Chargez la dernière version, réactivez-la pour l'espace de travail (ou cliquez sur Update dans l'ontologie), puis actualisez. Le nom de fichier de la version figée change à chaque publication : un nouveau téléchargement n'est donc jamais servi depuis le cache de votre navigateur.

Parcourir la démonstration

Les étapes ci-dessous supposent que les deux tables existent (après l'exécution des sources de données ou l'import CSV ci-dessus). Le travail sur les liaisons ne nécessite aucune rédaction de CSV : l'extension fournit l'ontologie, le contexte, les transformations et les alias.

Voir la liaison se résoudre automatiquement avec son contexte

Ouvrez Ontology → Bindings et cliquez sur la ligne de la liaison Payment (silver_table → iso20022_pacs008_payments) pour la développer : cliquez n'importe où sur la partie gauche de la ligne, à côté du chevron ▸. (Les liaisons d'objets peuvent être développées même sans colonne associée.) Comme le source.table de la liaison correspond au nom de table de la source de données, elle se résout automatiquement : l'en-tête affiche un badge de contexte de source core_banking_x · 96%, la liaison est Ready, et elle projette déjà avec les transformations appliquées.

Un clic pour débloquer l'édition. Un bouton Pick table apparaît sur la ligne. La liaison est Ready et projette correctement sans lui, mais tant que vous n'avez pas cliqué dessus, la correspondance de colonnes s'affiche sous forme de liste en lecture seule (aucun sélecteur de transformation, aucune édition). Cliquez sur Pick table et sélectionnez iso20022_pacs008_payments (déjà mise en évidence comme correspondance) pour résoudre l'identifiant de la table ; le bloc de correspondance de colonnes devient alors l'éditeur modifiable utilisé dans les deux étapes suivantes. Il s'agit d'une contrainte d'interface, et non de données : les transformations fournies s'exécutent à la projection dans tous les cas.

Dans la ligne développée, le premier bloc est le formulaire Source context (au-dessus de l'éditeur de correspondance de colonnes ; il n'y a pas de bouton distinct). Ce que vous devez voir : un ensemble de champs libellés déjà remplis, car l'extension a fourni le contexte de cette liaison. Ce sont les métadonnées qui disent « ce flux est un relevé sortant de virement ISO 20022 provenant du système bancaire central belge, et nous sommes sûrs à 96 % de la correspondance », et elles sont apposées sur chaque valeur que cette liaison projette.

Les champs, et ce que chacun indique à un consommateur en aval :

Champ (dans le formulaire)	Valeur	Signification
Source system	`core_banking_x`	Le système amont qui a produit ces lignes
Standard	`ISO20022` · type de message `pacs.008`	Le format de message auquel le flux se conforme
Jurisdiction	`BE`	Le lieu de comptabilisation des paiements
Business process	`credit_transfer`	L'événement métier que représente le flux
Currency semantics	`minor_units`	Les montants arrivent en centimes entiers (d'où la transformation `divide_by_100`)
Mapping confidence	`0.96`	Le degré de certitude que cette source correspond au concept canonique `Payment`
Valid from	`2025-01-01`	La date d'entrée en vigueur de cette correspondance

Pourquoi est-ce important : le même Payment canonique pourrait être alimenté par un second système utilisant pacs.009, des montants décimaux et une autre juridiction. Enregistrer le contexte de ce flux permet aux analyses et à l'IA de distinguer deux valeurs amount et d'expliquer l'origine de chacune, au lieu de les aplatir silencieusement en une colonne ambiguë. (Vous pouvez modifier n'importe quel champ et cliquer sur Save pour constater l'aller-retour ; le badge de l'en-tête se met à jour en conséquence.)

Examiner les transformations par propriété

Une fois que vous avez cliqué sur Pick table (étape précédente), le bloc de correspondance de colonnes devient l'éditeur modifiable : une ligne par propriété associée, avec un menu déroulant Transform à côté de chacune. Deux d'entre elles sont présélectionnées ; ce sont les transformations fournies par l'extension :

amount ← amount_minor, transformation divide_by_100. La valeur 1234556 du flux est projetée en 12345.56.
settlementTimestamp ← settled_at_utc, transformation timezone_normalize (Europe/Brussels). L'instant UTC est décalé vers la juridiction de comptabilisation.

Pour toutes les autres propriétés, le menu indique No transform (identity). Vous pouvez modifier une transformation et cliquer sur Save pour créer la vôtre.

Les deux transformations fournies sont marquées avec perte : le provenance.lossyProperties d'une lecture les liste donc, ce qui permet aux appelants de voir que la valeur projetée est une approximation dérivée, et non l'octet brut de la source.

Vous ne voyez pas les menus déroulants ? L'éditeur modifiable n'apparaît qu'après la résolution de la table (Pick table). Avant cela, vous obtenez une liste source → property en lecture seule, qui n'affiche pas les transformations.

Vérifier que le contexte accompagne les lectures

La confiance de 96 % et le contexte de source accompagnent désormais chaque instance projetée au lieu d'être supprimés : chaque lecture porte une enveloppe provenance (confidence, bindingContext, lossyProperties). Où l'observer :

Dans le graphe — cliquez sur un nœud d'instance dans /graph (étape suivante). Le panneau de détail affiche une section Provenance : la confiance de correspondance, le contexte de source et les propriétés qui sont des approximations avec perte.
Dans le workbench Bindings — le badge de contexte de source core_banking_x · 96% dans l'en-tête de la liaison (étapes précédentes) en est le reflet par liaison.
Via l'API — POST /api/ontology/kernel/objects/query (la surface objects.query du SDK d'ontologie) renvoie chaque ligne avec son enveloppe provenance.
Vérifié en CI — apps/api-ontology/src/kernel/source-backed/silver-table.test.ts prouve les transformations contextuelles et la provenance, tandis que les tests de requête d'objets source-backed prouvent que l'enveloppe franchit la frontière de lecture gouvernée.

(Facultatif) Explorer le graphe

Ouvrez /graph (Analytics → Graph). Ce que vous voyez d'abord est le schéma, et non les données : un nœud par type d'objet (Payment, Counterparty, Originator, Beneficiary), avec l'en-tête 4 TYPES · 2 LINK TYPES.

Liens. Deux types de liens structurent le réseau de paiements : Payment —Initiated by→ Originator et Payment —Sent to→ Beneficiary (chaque ligne pacs.008 porte les deux extrémités, donc une ligne = un lien). Counterparty n'a aucun lien dur : il est réconcilié avec Originator/Beneficiary par les alias contextuels ci-dessous, et c'est tout l'intérêt : la relation vit dans la couche de contexte, et non dans une clé étrangère.
Nombre d'instances. Chaque nœud de type affiche son nombre d'instances (Payment 6, Counterparty 5, Originator 6, Beneficiary 6) dès que les tables existent ; avant cela, il indique — (inconnu).
ISSUES signifie qu'une liaison est not ready : elle ne parvient pas à résoudre sa table source. Tant que les deux tables n'existent pas (exécution des sources de données ou import CSV ci-dessus), c'est attendu ; une fois qu'elles existent, le compteur tombe à 0.
Pour voir les instances : cliquez sur un nœud de type (par exemple Payment) et appuyez sur Expand instances dans le panneau latéral (ou double-cliquez sur le nœud). Ses lignes s'affichent sous forme de nœuds d'instance. La barre de recherche en haut permet d'accéder directement à une instance précise.
Pour voir la provenance : cliquez sur un nœud d'instance. Le panneau de détail affiche une section Provenance : la confiance de correspondance (96%), le contexte de source (core_banking_x, ISO20022, pacs.008, BE…), et une ligne Lossy listant amount et settlementTimestamp (les propriétés transformées). Les liaisons simples (non contextuelles) n'affichent pas de section Provenance.

Résoudre un terme selon son contexte (la démonstration phare)

Ouvrez Ontology → Aliases. Les quatre alias de l'extension apparaissent dans la liste Registered aliases (source imported). Faites défiler jusqu'au panneau Test resolution en bas, saisissez le terme local Counterparty dans le champ d'alias, puis remplissez les champs de contexte :

Contexte saisi	Se résout en	Pourquoi
`standard = ISO20022`, `direction = outgoing`	Beneficiary	Dans un transfert sortant, la partie avec laquelle vous traitez est le bénéficiaire crédité.
`standard = ISO20022`, `direction = inbound`	Originator	Dans un transfert entrant, il s'agit du donneur d'ordre débiteur.
`sourceSystem = kyc_system`	Counterparty	Dans le référentiel KYC, il s'agit de l'enregistrement durable de l'entité juridique.

Le même terme, trois concepts canoniques différents, présentés avec leur confiance et classés selon la spécificité de la correspondance du contexte. C'est le comportement de réconciliation contextuelle rendu visible.

(Facultatif) Suggérer une correspondance avec l'IA

Si votre organisation dispose d'une intégration LLM configurée, développez une liaison, cliquez sur Pick table pour ouvrir l'éditeur modifiable (la même contrainte que pour les transformations : le bouton Suggest with AI se trouve dans cet éditeur), puis cliquez sur Suggest with AI. Il profile les colonnes de la table liée, demande au modèle de la plateforme de les associer au type d'objet de la liaison, puis affiche une liste à examiner (property ← column [transform] confidence%). Apply N préremplit l'éditeur pour que vous le relisiez et cliquiez sur Save. C'est consultatif : rien n'est publié sans validation humaine.

Pourquoi cet exemple est intéressant

Le sens, pas les colonnes — une requête de conformité portant sur les « virements sortants de plus de 10 000 € comptabilisés en BE » peut s'appuyer sur le contexte de liaison pour savoir quel flux, quelle direction et quelle sémantique de montant ont produit chaque valeur, et expliquer les divergences entre sources au lieu de les masquer.
Ancré dans les normes — les ancres ISO 20022 / FIBO / LEI rendent un concept trouvable par son identifiant externe, sans imposer au vocabulaire local de correspondre à la norme.
Autonome — les sources de données intégrées font de toute l'extension une démonstration en un clic : installez, attendez une exécution, et la projection contextuelle est en ligne.

Pages associées

Ontologies contextuelles — ce qu'est une ontologie contextuelle et quand vous en avez besoin (le concept derrière cet exemple).
Liaisons sensibles au contexte — le guide de création qui accompagne cette extension (concepts, référence complète des champs, enveloppe provenance).
Créer des ontologies — le guide de base des ontologies typées.
Fraude Intelligence — l'ontologie typée de base appliquée aux données de criminalité financière.
Ontology → Packs — comment les extensions sont distribuées et installées.

À suivreBase de connaissances contextuelle entre les étapesUn pack de démonstration téléchargeable — un process flow dont l'étape de workflow écrit une note dans la base de connaissances propre à l'instance en cours avec <start.processFlow.knowledgeBaseId>, et dont une étape ultérieure la relit. Téléchargez-le, installez-le, démarrez une instance, exécutez les deux étapes.