— 16 mai 2026 · 13 min de lecture

Architecture EDI ISGo 2026 : event-driven, polyglote, observable

Comment construit-on un hub EDI moderne en 2026, sans répliquer les ESB monolithiques des années 2010 ni s'égarer dans le micro-services à outrance ? Voici l'architecture de référence ISGo : ingest multi-protocole, pipeline event-driven, event store canonique, machines à états par partenaire, observabilité multi-tenant. Une synthèse des principes Hohpe-Woolf, Kleppmann, Newman appliqués à un domaine où l'asynchrone et l'audit pèsent plus que la latence sub-seconde.

Couche 1 : ingest multi-protocole

La couche d'ingest reçoit les messages entrants depuis l'ensemble des protocoles partenaires. Les adapters dédiés normalisent l'entrée vers un format interne unique avant toute écriture durable :

• AS2 gateway (RFC 4130/6362) : réception S/MIME, vérification MDN, persistance du payload signé pour audit.
• AS4 gateway (OASIS ebMS 3.0 / PEPPOL eDelivery) : réception ebMS, vérification receipt signé, archivage du couple message + receipt.
• OFTP2 connector (RFC 5024) : pour les partenaires automotive et ENX, avec gestion des EERP.
• SFTP/FTPS pollers : pour les partenaires legacy, en pattern Polling Consumer (EIP §494).
• HTTP/REST endpoints : pour les API modernes (factures portails publics, webhooks PEPPOL).

Chaque adapter émet, dès réception, un événement EdiMessageReceived sur le bus interne (Kafka topic edi.ingress.raw), portant l'ID corrélation, l'hash du payload, les métadonnées partenaire et l'horodatage. Le payload brut est stocké dans un object store immuable (S3 avec Object Lock pour l'inalterabilité fiscale).

Couche 2 : pipeline de normalisation

Le pipeline de normalisation est la chaîne de transformation qui amène un message brut (EDIFACT, X12, UBL, JSON propriétaire) vers le modèle canonique interne. C'est l'incarnation du pattern Pipes and Filters appliqué à l'EDI.

Les étages typiques :

• Parser : ouvre le document, vérifie la syntaxe, émet SyntacticallyValid ou SyntacticallyInvalid.
• Validator : applique les règles sémantiques (Schematron, JSON Schema, EN 16931), émet SemanticallyValid.
• Translator : convertit vers le canonical model — pattern Message Translator.
• Enricher : résout référentiels (GLN, GTIN, partner master), pattern Content Enricher.
• Business validator : applique les règles métier propres au client (limites de crédit, contrôles autorisations).

Chaque étage est un service stateless qui consomme un topic et publie sur le suivant. Le scaling horizontal suit le pattern Competing Consumers. Les échecs partent sur le Dead Letter Channel dédié à chaque étage, avec retry à backoff exponentiel jitter.

Couche 3 : event store canonique

Au cœur du hub, un event store immuable consigne tous les événements de domaine : InvoiceReceived, InvoiceValidated, InvoiceTranslated, InvoiceRoutedToErp, InvoiceAckedByErp, InvoiceArchived, ainsi que les états d'erreur correspondants. Cette consignation suit le pattern Event Sourcing (Fowler 2005, Young 2010).

Plusieurs read models sont dérivés du log par projection :

• Operational dashboard : liste des messages en cours par état, partenaire, type.
• Partner-facing tracking portal : le partenaire suit ses propres messages depuis sa console dédiée.
• Fiscal archive : vue immuable consultable 10 ans avec lien vers le payload signé d'origine.
• Analytics warehouse : alimentation continue d'un data warehouse pour les KPI volumétriques, temps de cycle, SLA, churn.

L'event store typique en 2026 : Kafka pour le log append-only, EventStoreDB ou un fork PostgreSQL adapté pour les snapshots de read models. Le pattern CQRS sépare strictement writes (commands) et reads (projections).

Couche 4 : machines à états partenaires

Chaque partenaire EDI a son lifecycle technique, généralement modélisable en machine à états explicite : prospection → spec-exchange → cert-exchange → connectivity-test → production-pilot → production-active → archived. Cette state machine, persistée et observable, est l'épine dorsale du partner management dans un hub multi-tenant.

Le pattern State Machine appliqué aux partenaires complète celui appliqué aux messages. Les transitions sont déclenchées soit manuellement (validation par opérateur) soit automatiquement (succès d'un test de connectivité, expiration d'un certificate). Les workflow engines candidats : Camunda 8, Temporal, AWS Step Functions, Spring State Machine.

Couche 5 : observabilité multi-tenant

Un hub EDI moderne instrumente tous les flux avec OpenTelemetry (traces, metrics, logs) corrélés par un traceId stable. Chaque message porte son traceId dès l'ingest, et chaque service injecte ses spans dans la trace partagée. Le pattern Correlation Identifier est fondamental.

Le découpage multi-tenant impose :

• Tagging systématique : chaque metric, chaque log porte tenant_id, partner_id, document_type.
• Isolation des dashboards : chaque tenant voit uniquement ses flux.
• SLO par tenant : latence, taux d'erreur, taux d'ack délivrés. Le pattern Bulkhead isole les ressources pour qu'un tenant en panne n'affecte pas les autres.
• Alerting différencié : la priorité d'un incident dépend du tenant impacté et de son contrat.

Pourquoi polyglote ?

Un hub EDI moderne est rarement écrit en une seule pile technique. Les raisons :

• Bibliothèques de parsing matures : Java domine les parsers EDIFACT (Smooks, Mendelson, BOTS), Python excelle en scripting d'enrichissement, Go pour les services haute-performance d'ingest, Rust pour les composants cryptographiques.
• Compétences disponibles : forcer Java sur un nouveau composant alors que l'équipe maîtrise Go ralentit la livraison.
• Encapsulation par service : chaque service expose une API stable (gRPC, REST), l'implémentation reste libre. Newman, Building Microservices, 2e éd. 2021, codifie ce principe.

La contrepartie : une stricte standardisation des contrats (Protobuf schemas, OpenAPI specs, AsyncAPI specs), une CI/CD unifiée mais polyglotte, et une plateforme commune (Kubernetes, observability stack, secret management).

Sécurité : Zero Trust by default

Le pattern Zero Trust Architecture (NIST SP 800-207) s'applique à l'EDI moderne : chaque appel inter-service est mTLS authentifié et autorisé, les secrets sont rotés via Vault/KMS, les certificats partenaires sont gérés en pipeline, les flux sensibles sont chiffrés au repos via KMS (pattern Secrets Management).

Le pattern Defense in Depth empile : WAF en bord, mTLS service mesh, IAM granulaire, audit logs immuables, séparation des environnements (prod, pre-prod, dev isolés).

Conclusion : un patron architectural mature

L'architecture ISGo 2026 n'a rien de révolutionnaire : elle consolide des patterns connus (Hohpe-Woolf 2003, Fowler 2014, Newman 2015, Kleppmann 2017, Burns 2017) et les applique avec rigueur à un domaine — l'EDI — où l'audit, la conformité fiscale et la robustesse pèsent autant que la performance. Pour un éditeur ou un département EDI, c'est le standard de référence pour 2026-2030. Les évolutions à venir (post-quantique, AI-assisted mapping, observabilité unifiée eBPF) viendront s'ajouter, mais les couches sont posées.

Voir aussi les articles sur les patterns EDI, l'EDI à l'heure des API et la foundation architecture moderne.