Policy paper · Mai 2026 · Par Riham Marii & Julien Achard

Architectures of Interoperability in Digital Trade

Vers un cadre technologiquement neutre pour intégrer plateformes, registres distribués et systèmes réglementaires. À partir d'une opération de crédit documentaire adossée à un connaissement électronique (LC – eBL), ce policy paper propose une architecture d'interopérabilité en quatre couches, la confronte aux déploiements réels et identifie les conditions d'un passage à l'échelle.

Digital TradeRéglementation
Télécharger le document (PDF)

01Un commerce encore structurellement papier

~36documents

Et 240 copies pour une transaction internationale type.

< 1 %numérisés

Part des documents commerciaux entièrement numérisés.

5,7 %d'eBL

Adoption du connaissement électronique en janvier 2025, contre 1,2 % en 2021.

13juridictions

Avec une législation fondée sur la loi type MLETR de la CNUDCI.

L'écart n'est plus d'abord technologique : la plupart des outils du commerce sans papier existent. La difficulté tient à leur déploiement fragmenté et à leur faible interopérabilité le long de la chaîne de transaction. Une donnée créée numériquement dans un système doit encore être ressaisie, reformatée ou revérifiée dans un autre.

La numérisation ne consiste pas à convertir des documents papier en PDF : il s'agit de créer la donnée une fois, sous une forme lisible par machine, et de la réutiliser en confiance, de la commande au paiement. L'opération LC – eBL est un cas d'école, car elle réunit commande, transport, douane, examen bancaire, paiement et libération des marchandises.

02Une architecture d'interopérabilité en quatre couches

Le papier traite la chaîne LC – eBL comme un système de données transactionnelles, structuré selon le modèle Buy – Ship – Pay de l'UN/CEFACT, et propose une architecture à quatre couches interdépendantes.

  1. Juridique et réglementaireReconnaissance des documents transférables électroniques : la loi type MLETR exige identification, intégrité, contrôle exclusif et transférabilité, sans imposer de technologie.
  2. Données et standardsAlignement sémantique (ce que signifient les données) et syntaxique (comment elles sont structurées et échangées) : UN/CEFACT, KTDDE de l'ICC DSI, DCSA, modèle de données de l'OMD.
  3. Identité et confianceIdentifiants persistants (LEI, vLEI), attestations vérifiables, signatures et cachets électroniques, horodatage : pour que le document soit fiable hors du système qui l'a émis.
  4. Connectivité et gouvernanceAPI ouvertes, accords multipartites, registres de suivi du contrôle : un modèle fédéré, sans plateforme unique.

03Ce qui fonctionne déjà, et où l'architecture reste incomplète

AvancéeCe qu'elle démontre
Standardisation de l'eBLDCSA eBL 3.0, ISO 5909:2026 (eBL sur DLT, aligné sur UN/CEFACT et MLETR) et KTDDE convergent : les données du document de transport sont largement identifiées.
Transfert d'eBL entre plateformes (mai 2025)Premier transfert standardisé entre CargoX et EdoxOnline (HMM, Suzano), sans retour au papier ni accord bilatéral, grâce à l'API PINT, à l'accord MSPIA et au registre de contrôle CTR.
Pilote LC – eBL de bout en bout (2025)Siemens, Commerzbank, Fr. Meyer's Sohn et une banque chinoise, via trace:original (Enigio) et TradeGo : traitement documentaire ramené d'environ deux semaines à moins de deux heures.

Ces jalons confirment que la phase « Ship » est la plus mature. Les écarts restent aux interfaces : Buy-to-Ship, où les données de facture ne sont pas encore réutilisables à l'échelle ; Ship-to-Border, où l'eBL et la déclaration en douane restent mal connectés ; Ship-to-Pay, où l'examen de la lettre de crédit repose encore sur des documents plutôt que sur des données.

Le goulot d'étranglement n'est pas technique mais institutionnel : la technologie existait, la contrainte était l'alignement des acteurs autour de standards et de cadres juridiques mutuellement reconnus.Enseignement du pilote Siemens – Commerzbank

04Vers un cadre mondial : séquencement et conditions de passage à l'échelle

Trois principes de séquencement : partir de documents « ancres » (l'eBL pour Ship, la présentation LC sous UCP 600 / eUCP / ISBP 745 pour Pay, la facture structurée pour Buy) ; travailler par cartographie des données communes plutôt que document par document ; viser une convergence fédérée et technologiquement neutre.

  1. Réforme juridique et reconnaissance accéléréeAccélérer l'adoption de MLETR, y compris dans les juridictions de droit civil et les grandes économies commerçantes comme le Japon et la Chine.
  2. Infrastructure d'identité, de vérification et d'échangeDéfinir des profils de confiance interopérables entre plateformes, douanes et banques.
  3. Sensibilisation, adoption bancaire et capacité de mise en œuvreSystèmes (e-présentation par API, connexion aux registres d'eBL), formation des examinateurs de documents et conduite du changement.
  4. Alignement sur les normes ISOISO 19845 / UBL, ISO 20197-1, ISO 5909, LEI, BIC… et l'accélération d'ISO 20022 pour le Trade Finance, plus riche que les messages MT 7xx.
  5. Gouvernance multilatéraleCoordonner organismes de normalisation, opérateurs et régulateurs, sans nouvelle institution : l'ICC DSI peut servir de plateforme de coordination.

À plus long terme, l'intégration de paiements programmables (CBDC de gros, dépôts tokenisés, ISO/TS 23516) permettrait un équivalent numérique de la livraison contre paiement, réduisant l'écart entre l'acceptation des documents et le paiement. mBridge, Agorá, Ubin+ et les expérimentations de la Banque de France en ont démontré des briques, sans encore d'intégration de bout en bout avec la chaîne documentaire.

Sources : Riham Marii et Julien Achard, Architectures of Interoperability in Digital Trade, policy paper, mai 2026, 28 pages (références : CNUDCI, ICC DSI, DCSA, ISO, OMD, OMC, UNESCAP, UN/CEFACT, BRI).

Un sujet à approfondir ?
Parlons-en.

Digitalisation du Trade Finance, eBL, MLETR, interopérabilité des plateformes : échangeons sur vos projets.

Prendre rendez-vous