ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Data Mesh appliqué à l'EDI

Sortir du hub EDI centralisé qui devient un monolithe à équipe bottleneck — pour rendre les domaines métier propriétaires de leurs flux EDI.

Problème

Un hub EDI monolithique qui traite toutes les commandes, toutes les expéditions, toutes les factures, tous les paiements et tous les statuts logistiques d'une organisation finit par concentrer dans une seule équipe d'intégration la connaissance fonctionnelle de tous les domaines métier. Cette équipe devient le bottleneck de toute évolution fonctionnelle : nouveau partenaire, nouveau message, nouvelle règle réglementaire. Le hub vieillit, accumule de la dette, devient fragile.

Forces

  • Chaque domaine métier connaît mieux ses flux. Le domaine Commandes connaît les variantes d'ORDERS Walmart, les acquittements PEPPOL, les règles de validation client. Le domaine Paiements connaît PAYMUL/BANSTA, SEPA, SWIFT.
  • L'organisation a déjà des silos métier (Achats, Logistique, Finance, Paye). Le mesh épouse la structure existante, ne la combat pas.
  • Un domaine doit pouvoir évoluer indépendamment. Le domaine Paye doit pouvoir intégrer JOBAPP/JINFDE sans coordonner avec le domaine Logistique.
  • Mais la conformité reste transverse. La preuve fiscale, le RGPD, la cybersécurité sont des préoccupations de la plateforme, pas du domaine.

Solution

Appliquer les quatre principes Data Mesh de Dehghani au paysage EDI :

  1. Domain ownership — chaque domaine métier (Commandes, Expéditions, Facturation, Paiements, RH) est propriétaire de ses flux EDI : il pilote ses mappings, ses validations, ses SLA partenaires.
  2. Data as a product — chaque domaine publie ses événements sous forme de produit avec un schéma versionné, une documentation et un SLA. edi.events.orders.v3 est un produit, pas un effet de bord.
  3. Self-service platform — une plateforme centrale fournit les briques transverses (connecteurs AS2/AS4/SFTP, validateur, observabilité, archivage fiscal) que les domaines consomment.
  4. Federated computational governance — un conseil transverse définit les standards (idempotence, schéma, sécurité, partner onboarding) que tous les domaines doivent respecter.

Implémentation EDI

En pratique : le domaine Commandes possède son pipeline EDIFACT ORDERS / X12 850 / UBL Order, publie un produit orders.v1 consommable par d'autres domaines (Stocks, Préparation). Le domaine Facturation possède INVOIC, en publie un produit invoices.v2. La plateforme centrale fournit Sterling B2B, un schema registry, une observabilité Datadog, un archivage S3 immutable pour la preuve fiscale. La gouvernance transverse impose l'idempotence (UNB CTRL stable), l'identifiant correlation (TraceId), le format de log standardisé. Chaque domaine a son équipe d'intégration interne ; aucun domaine ne dépend fonctionnellement d'un autre pour livrer une évolution.

Anti-patterns

  • Mesh sans plateforme. Cinq domaines qui réinventent chacun leur AS2 produisent cinq incidents différents pour le même partenaire.
  • Plateforme sans gouvernance. Sans standard transverse, on observe deux domaines qui modélisent le même partenaire différemment — la traçabilité bout-en-bout devient impossible.
  • Domain ownership sans data product. Les domaines possèdent leurs flux mais ne les exposent à personne — l'effet est le silo, l'opposé du mesh.
  • Mesh imposé top-down. Sans adhésion des équipes métier, le mesh devient un nouvel acronyme qui décore le même monolithe.

Patterns liés

  • Modèle canonique — chaque produit publie son schéma canonique.
  • Event Sourcing — base technique de la publication de produits événementiels.
  • Message Broker — l'infrastructure neutre sur laquelle les domaines publient.

Sources