Glossaire

Définitions des principaux termes métier et techniques utilisés dans Ormuz. Chaque terme renvoie vers la page de référence correspondante pour aller plus loin.

Modèle métier

Objet plateforme: Ressource persistante représentant une entité métier — tiers, facture, paiement, limite de crédit, etc. Tout objet plateforme est typé, identifié et produit des événements lors de ses transitions d'état. Voir le modèle métier.
Identifiant: Chaîne opaque préfixée par le type de l'objet (pty_, inv_, cs_…) exposée dans le champ id de chaque ressource. Stable, utilisable dans l'API, les webhooks et les processus.
Référence source: Champ source_reference libre accepté par la plupart des objets plateforme. Permet de stocker votre propre identifiant (numéro de commande ERP, référence CRM) directement sur l'objet, sans table de correspondance tierce.
Brouillon d’objet (draft): Valeur d’objet plateforme préparée avant sa persistance : même type métier que l’objet cible, mais sans identifiant. Le mode draft appartient au type de donnée du processus et ne doit pas être confondu avec un objet persistant dont le statut métier serait lui-même draft. Voir Principes fondamentaux du modèle métier.
Party: Société ou individu identifié dans la plateforme — acheteur, fournisseur, partenaire. C'est l'objet racine auquel se rattachent les contacts, les commandes, les factures et les décisions de crédit. Préfixe : pty_.
Party contact: Personne physique associée à une party, portant ses informations d'identité et de contact. Un contact peut avoir un ou plusieurs rôles (représentant légal, autorisateur de paiement…). Préfixe : ptc_.
Checkout session: Session de paiement ou de demande de crédit initiée par votre plateforme et complétée par l'acheteur via une parcours utilisateur. Expose directement le champ url pour rediriger l'acheteur. Préfixe : cs_.
Dossier d'onboarding: Dossier d'entrée en relation client regroupant la collecte de données, les vérifications de conformité (KYC/KYB) et la décision d'acceptation finale. Préfixe : obc_.
Facture: Document financier émis par votre plateforme, portant un montant dû, une échéance et un lien vers la party acheteur. Peut être rapprochée d'un ou plusieurs paiements. Préfixe : inv_.
Créance (receivable): Montant dû par un acheteur, produit d'une facture ou d'une ligne de crédit utilisée. La créance porte l'état de recouvrement et sert de base à la réconciliation des paiements.
Paiement PSP: Paiement enregistré côté provider (Stripe, virement bancaire…) et importé dans Ormuz. Un paiement PSP est ensuite alloué à une ou plusieurs créances via une réconciliation. Préfixe : psp_.
Paiement: Paiement plateforme, rapproché d'une créance ou d'une facture. Indépendant du provider source : représente le flux financier du point de vue d'Ormuz après réconciliation. Préfixe : pay_.
Limite de crédit: Plafond de crédit accordé à une party ou un groupe de tiers, avec historique et motif de la décision. Consommée par les commandes et factures en cours. Préfixe : crl_.
Exposition crédit: Montant de crédit actuellement utilisé par une party — somme des créances en cours non encore réglées. Mise à jour automatiquement au fil des transactions.

Orchestration

Processus (définition de processus): Programme d'orchestration composé de nodes reliés par des routes. Un processus est versionné et peut être exécuté plusieurs fois en parallèle. Voir Le modèle des processus.
Révision: Version publiée d'une définition de processus. Chaque modification d'un processus crée une nouvelle révision ; les instances en cours continuent sur la révision qui les a démarrées.
Instance de processus: Exécution concrète d'un processus pour un contexte donné — un acheteur, une commande, un dossier. Une instance progresse à travers les nodes jusqu'à sa complétion ou son annulation. Préfixe : pci_.
Node: Unité d'exécution atomique dans un processus. Chaque node a un type (connecteur, action utilisateur, routeur, timer…), des paramètres d'entrée et des sorties typées. Voir les nodes Core et les nodes fournis par les extensions.
Binding: Câblage typé entre la sortie d'un node et l'entrée d'un autre. Les bindings transportent des objets plateforme ou des scalaires sans que vous ayez à manipuler les identifiants manuellement. Voir Entrées, sorties et bindings.
Route: Lien conditionnel entre deux nodes définissant le chemin d'exécution à emprunter. Un routeur expose plusieurs routes ; une seule est activée à chaque exécution selon la condition évaluée.
Déclencheur (trigger): Événement ou condition qui démarre automatiquement une nouvelle instance de processus. Un déclencheur peut écouter un événement plateforme (création d'une facture, complétion d'un paiement…) ou être appelé directement via l'API.
Timer: Événement temporel déclenché à une date absolue ou après un délai. Les timers peuvent démarrer une branche d'exécution parallèle ou reprendre une instance en attente après expiration d'un délai.
Parcours utilisateur: Page web servie par Ormuz pour les interactions utilisateur. L'instance se met en pause quand elle atteint une action utilisateur et reprend automatiquement après la complétion. Voir Parcours utilisateurs.
Action utilisateur: Node qui met une instance en pause et ouvre une page hébergée pour recueillir l'interaction d'un utilisateur final — formulaire, choix, collecte de mandat, vérification OTP. Préfixe de l'objet action : pua_.
Decision: Artefact versionné qui encapsule une politique déterministe derrière des inputs et outputs typés. Une Decision calcule ; le processus orchestre les effets à partir de son résultat. Voir Comprendre les Decisions.
Decision Run: Évaluation observable d’une révision immuable de Decision avec un snapshot d’input explicite. Le Run conserve l’identité exacte de la logique exécutée et, lorsque demandée, sa trace.
Agent: Artefact opérationnel versionné composé d’un objectif, d’instructions générales et d’une ou plusieurs activités métier. Voir Comprendre les Agents.
Activité d’Agent: Unité exécutable d’un Agent. Elle porte ses consignes, son contrat d’entrée/sortie, ses tools, ses guardrails et sa politique d’accès à la mémoire.
Rôle Agent: Namespace optionnel déclaré par un processus pour conserver une continuité de Mémoire Agent entre plusieurs Agent Tasks. Le rôle ne sélectionne jamais l’Agent ni sa révision ; chaque Agent Task porte directement cette dépendance.
Mémoire Agent: Ressource de contexte de travail appartenant à une Agent Definition. Elle peut être réutilisée entre plusieurs Runs et plusieurs révisions du même Agent, sans devenir une source de vérité métier. Dans un processus, elle peut être mappée explicitement ou résolue à partir d’un rôle Agent.
Agent Run: Exécution observable d’une activité appartenant à une révision précise d’Agent. Un Run expose son statut, ses résultats, ses appels de tools et ses diagnostics selon les règles de protection applicables.
Tool d’Agent: Capacité explicitement accordée à une activité d’Agent pendant un Run. Son contrat est conçu pour l’usage agentique et reste indépendant d’un éventuel node de processus équivalent. Un tool peut lire ou agir selon son contrat et ses permissions ; sa présence sur une activité ne donne aucun droit aux autres activités.
Niveau de risque d’un tool: Classification statique low, medium ou high du maximum de conséquence métier qu’un tool peut produire. Ce niveau n’accorde aucun droit et reste distinct de la classification des données, de l’autorité et du coût.
Sous-workflow (subworkflow): Processus délégué depuis un processus parent. Le parent attend la complétion du sous-workflow avant de reprendre son exécution, ce qui permet de décomposer des orchestrations complexes en processus réutilisables.

API et intégration

Clé API: Jeton d'authentification utilisé dans le header Authorization pour appeler l'API REST d'Ormuz. Les clés sont créées depuis la console et peuvent être limitées à des périmètres spécifiques.
Webhook: Notification HTTP envoyée par Ormuz vers une URL que vous configurez, lors d'un événement plateforme. Chaque livraison est signée ; Ormuz garantit une livraison au moins une fois avec rejeu automatique. Voir Recevoir des webhooks.
Événement plateforme: Message structuré émis par Ormuz lors d'une transition d'état d'un objet — invoice.issued, payment.matched, onboarding_case.completed… Chaque événement contient l'objet concerné dans son intégralité. Voir le catalogue des événements.
Provider: Service tiers utilisé via une extension — paiement, KYC, signature électronique, open banking, données ou financement. Dans la documentation générique, providerdésigne ce prestataire métier et non le moteur IA d’un Agent.
Provider de modèle: Capacité d’exécution IA proposée aux Agents et exposant une liste de modèles. Le provider de modèle sélectionné sur une révision d’Agent est distinct d’un provider métier utilisé via une extension.
Connecteur: Node d'orchestration qui interagit avec un provider tiers — déclenche un paiement Stripe, lance une vérification KYB, initie une signature électronique. Les paramètres et sorties de chaque connecteur sont documentés dans la page de sa extension.
Mode d'intégration: Façon dont votre plateforme interagit avec Ormuz : en pilotant les processus directement via l'API, en déléguant un parcours complet via une checkout session, ou en combinant les deux. Voir Modes d'intégration.
Permission de node: Autorisation que vous accordez explicitement à un node d'intégration pour qu'il lise ou modifie un type d'objet métier dans son propre comportement, au-delà de ce que montrent ses entrées et sorties. Elle est vérifiée jusqu'au moment de l'accès et peut être retirée à tout moment. Voir Permissions des nodes.
Correspondance d'objet: Lien technique entre un objet d'un fournisseur et l'objet Ormuz qu'il représente, enregistré pour une configuration d'intégration donnée. Il permet la réconciliation et la relecture de cette cible exacte, sans jamais ouvrir d'accès plus large. Voir Correspondances d'objets.

← PrécédentDoctrine IA