Tiers de confiance souverain · Conforme EU AI Act
Orchessia Trust
Produit · Comment ça marche

Du code à la preuve, en huit étapes invariantes.

Ces étapes sont la séquence exacte exécutée par le code Orchessia Trust en production. Chaque étape produit un artéfact cryptographique vérifiable indépendamment, par n'importe quel régulateur, sans appel à notre infrastructure.

Évaluer mon expositionDemander une démo
Flux end-to-end · 8 étapesSéquence opérationnelle V1.0

Le parcours d'une décision IA, du KYC à la vérification offline.

Chaque étape est appelée via une API REST ou SDK Node/Python. Les latences sont mesurées en production.

  1. 01
    Étape

    Onboarding KYC du responsable

    OCR piece d'identité + reconnaissance faciale + liveness + WebAuthn. Validation eIDAS substantiel.

    Service identity-coreEndpoint POST /kyc/enroll
    Produit
    identité_responsable (UUID)
    Durée
    ~15 min, une seule fois
  2. 02
    Étape

    Liaison agent ↔ humain

    Le responsable signe un binding JWS liant la clé de l'agent IA à son identité KYC.

    Service identity-bindingEndpoint POST /bind
    Produit
    binding JWS Ed25519
    Durée
    < 1 sec
  3. 03
    Étape

    Emission du mandat opérationnel

    Mandat signé définissant : allowed_actions, limites quantifiées, régime de supervision.

    Service proof-engineEndpoint POST /mandates
    Produit
    mandat JWS canonique JCS
    Durée
    < 1 sec
  4. 04
    Étape

    Vérification temps reel de chaque action

    L'agent demande l'autorisation. Vérification du binding + mandat + limites. Retour ALLOW / HOLD / BLOCK.

    Service policy-engineEndpoint POST /authorize
    Produit
    décision d'autorisation
    Durée
    < 20 ms
  5. 05
    Étape

    Enregistrement de la décision signée

    Agent signe sa décision + hash canonique input/output. Insertion dans le registre WORM.

    Service proof-engineEndpoint POST /décisions
    Produit
    décision JWS + feuille Merkle
    Durée
    < 50 ms
  6. 06
    Étape

    Horodatage par TSA souveraine

    Aggregation des feuilles, calcul racine Merkle, signature TSA RFC 3161, ancrage au batch precedent.

    Service proof-anchorBatch automatique 5 min ou 100 décisions
    Produit
    TimeStampToken CMS + batch sealed
    Durée
    Cycle 5 min
  7. 07
    Étape

    Génération automatique du dossier conformité

    Rapport QMS (Art. 17), déclaration EU de conformité (Art. 47), Annexe IV technique générés a la demande.

    Service complianceEndpoint GET /reports/qms
    Produit
    PDF Annexe IV signé
    Durée
    < 30 sec
  8. 08
    Étape

    Vérification indépendante par le tiers

    Régulateur, juge, citoyen affecte vérifié hors-ligne avec CLI ou portail web. Aucun appel a Orchessia Trust.

    Service vérifier-cli / vérifier-webverify <proof.cap>
    Produit
    verdict OPPOSABLE / INVALIDE
    Durée
    < 30 sec
Pipeline cryptographique

Sept primitives, une chaîne de garde unique.

Du condensat à la conservation WORM, la preuve gagne en force probante à chaque étape. Tout repose sur des standards IETF/ETSI auditables.

  1. I.

    Identification de la personne responsable

    identité_responsable

    Vérification d'identité eIDAS niveau substantiel : piece officielle, correspondance biometrique, contre-mesure anti-usurpation.

    Cryptographie · Ed25519 · ArcFace · SCRFD
  2. II.

    Liaison cryptographique de l'agent

    binding JWS

    La clé de signature de l'agent est cryptographiquement liee a la personne responsable identifiée.

    Cryptographie · Ed25519 · JCS RFC 8785
  3. III.

    Emission du mandat

    mandat JWS

    Mandat signé par la personne responsable : périmètre d'actions autorisées, limites quantifiées, modalités de supervision.

    Cryptographie · Ed25519 · Canonical JSON
  4. IV.

    Traçage de la décision

    décision JWS

    Pour chaque décision, condensat canonique de l'entree et de la sortie, signature par l'agent, régime de supervision applique.

    Cryptographie · SHA-256 · JCS · Ed25519
  5. V.

    Inclusion dans l'arbre de Merkle

    merkle proof

    La feuille est calculee et chainee a la racine du batch precedent.

    Cryptographie · Merkle SHA-256 natif
  6. VI.

    Horodatage qualifiable

    TST CMS

    TimeStampToken au format RFC 3161 émis par l'autorité d'horodatage souveraine Orchessia Trust.

    Cryptographie · RFC 3161 · ECDSA P-256 · CMS
  7. VII.

    Conservation probante

    WORM row

    Inscription dans un registre Write Once Read Many. Conservation legale dix ans minimum.

    Cryptographie · PostgreSQL triggers · hash-chain
  8. VIII.

    Vérification indépendante

    verdict

    Vérification offline par tout tiers : autorité, juridiction, expert judiciaire, déployeur, personne affectee.

    Cryptographie · openssl ts -verify · WebCrypto
Arbre de Merkle

Vérification d'inclusion en O(log n).

Chaque décision est une feuille de l'arbre de Merkle. La racine est ancrée par horodatage TSA. Un auditeur peut vérifier qu'une décision unique appartient à un batch sans charger le batch complet.

Pourquoi Merkle
Vérifier une décision parmi un million n'exige que la racine du batch et le chemin d'inclusion (≈ 20 condensats SHA-256). La preuve fait moins de 1 kilooctet. Tout régulateur peut la vérifier en quelques millisecondes.
ARBORESCENCE DE VÉRIFICATION
Racine scelléeh0h1h0h1h2h3e0e1e2e3e4e5e6e7
Chemin d'inclusionEmpreinteRacine scellée
Pour démontrer qu'un événement est inclus dans le registre, il suffit de fournir le chemin navy vers la racine scellée — sans dévoiler les autres éléments.
Chaîne de batches scellés

Toute altération rétroactive est détectable.

Chaque batch contient le condensat du batch précédent. Modifier une décision passée nécessite de réécrire toute la chaîne. C'est mathématiquement détectable, même avec accès à la base de données.

Append-only au niveau SGBD
Les triggers PostgreSQL BEFORE UPDATE/DELETE refusent toute écriture sur un batch déjà scellé. La modification est une exception SQL, pas une convention applicative.
CHAÎNE DE REGISTRES SCELLÉE
Registre 1Registre 2Registre 3Registre 4T+00'T+05'T+10'T+15'
Chaque registre incorpore l'empreinte du registre précédent. Toute altération rétroactive invalide la chaîne entière.
Les registres sont scellés en chaîne. La propagation d'intégrité rend détectable toute modification d'un registre passé.
Vérification indépendante

Hors-ligne, par n'importe quel tiers qualifié.

À l'étape 8, n'importe quel régulateur, auditeur, ou personne affectée peut vérifier la preuve avec notre vérificateur CLI (~5 Mo) ou directement avec openssl ts -verify. Aucun appel à notre infrastructure n'est nécessaire.

Vérificateur CLI
~5 Mo binaire statique

Téléchargé une fois, exécuté hors-ligne. Vérifie binding, signature, racine Merkle, TST, chaîne de batches.

openssl ts -verify
OpenSSL ≥ 1.1.1

Outil standard distribué dans toutes les distributions Linux/Unix. Compatibilité native avec nos TimeStampTokens.

WebCrypto navigateur
V1.1 — T4 2026

Le portail public de vérification s'exécute intégralement côté client. Aucune donnée transmise.

Pas de boîte noire
Les primitives utilisées (Ed25519, ECDSA P-256, SHA-256, RFC 3161, RFC 7515, RFC 8785) sont toutes publiques et standardisées. Aucun composant propriétaire n'est requis pour vérifier.

Voir le pipeline en action sur vos données.

Atelier de 90 minutes : nous instrumentons un flux IA pilote chez vous et vous repartez avec une preuve vérifiable offline.

Demander une démoVoir les options d'intégration