Message Bus

Une dorsale de messagerie commune sur laquelle se branchent ERP, WMS, portail, TMS, lake analytique et hub EDI partenaires. Le pattern qui passe le graphe d'intégration de N² liens spaghetti à 2N branchements organisés.

Problème

Une entreprise typique a 10 à 20 applications qui doivent s'échanger des messages : ERP, gestion d'entrepôt (WMS), gestion de transport (TMS), CRM, comptabilité, portail fournisseur, lake analytique, plus le hub EDI vers les partenaires. Si chaque paire qui a besoin de communiquer le fait en point-à-point, on a N(N-1)/2 connexions — soit ~190 pour 20 applis. Chacune avec son format, son protocole, ses retries, ses erreurs. Le graphe devient ingérable, chaque changement casse plusieurs branches. Il faut une dorsale partagée.

Forces

Réduction du couplage N². Chaque application ne se branche qu'au bus (1 lien), pas à toutes les autres.
Format pivot. Le bus impose son enveloppe et ses types canoniques ; chaque appli ne traduit qu'une fois.
Routage central. Les règles de qui voit quoi sont déclarées dans le bus, pas dans les applis.
Single point of failure latent. Le bus doit être HA / clusterisé ; sa panne fige tout l'écosystème.
Goulot d'évolution. Changer le format canonique impacte tous les abonnés. Imposer un versionnement strict.

Solution

EIP §137 (Hohpe & Woolf, 2003) définit le Message Bus comme la combinaison de trois éléments : (a) une infrastructure de messagerie commune (broker / cluster), (b) un schéma canonique partagé qui définit l'enveloppe et les types acceptés (voir Modèle canonique), (c) un jeu de canaux nommés avec règles de routage. Toute application qui se branche doit accepter ces trois contraintes : parler le canonique, utiliser le broker, s'inscrire au catalogue de canaux.

plaintext topology.txt

Without bus (N²)                With bus (2N)
   ────────────────                ──────────────

   ERP ──── WMS                    ERP─┐
    \\     /                          │
     \\   /                       WMS ─┤
      \\ /        ┌────────────┐      │
       X         │   message  │       │
      / \\        │    bus     │      │
     /   \\        └────────────┘     │
    /     \\                          │
   TMS ──── PORTAL                TMS ─┤
   POS ──── FINANCE              POS ─┤
                                FIN ─┤
                              PORTAL ─┘

   shared envelope + canonical types + routing rules

Implémentation EDI

En contexte EDI, le bus est le cœur du hub d'intégration. Trois rôles typiques :

Bus d'événements internes. Topic Kafka / Service Bus topic / RabbitMQ exchange qui diffuse l'état des messages EDI (reçu, validé, traduit, livré). Chaque appli s'abonne à ce qu'elle veut.
Bus de payload canoniques. Topics edi.canonical.orders.in, edi.canonical.invoic.out ; sur ces topics circulent des messages au format canonique JSON, indépendamment de leur format d'origine (EDIFACT, X12, UBL, cXML).
Bus de notifications transverses. Topic edi.alerts.partner.down qui prévient toutes les applis qu'un partenaire est en panne ; le portail affiche un bandeau, le retry-scheduler met en pause, l'analytics annote.

json canonical-envelope.json

# Enveloppe canonique commune sur le bus
{
  "messageId": "01HVF8K3X1ABCDE0123456789",
  "messageType": "INVOIC",
  "schemaVersion": "1.4.0",
  "occurredAt": "2026-05-14T12:00:00Z",
  "source": "edi-hub.inbound.peppol",
  "destinations": ["erp.finance", "portal.supplier", "lake.analytics"],
  "tenantId": "ediverse-prod",
  "correlationId": "PO-12345",
  "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "payload": {
    "issuer": { "gln": "5798000000122", "name": "Acme SAS" },
    "buyer":  { "gln": "7300010000001", "name": "BuyMart" },
    "totals": { "net": 36000, "tax": 7200, "gross": 43200, "currency": "EUR" }
  }
}

Lecture : l'enveloppe canonique du bus porte les champs transverses (messageId, type, version, source, destinations, trace) ; le payload est typé selon messageType + schemaVersion. Tout consommateur du bus sait lire l'enveloppe ; il décide selon messageType s'il a un parseur pour le payload.

ESB vs. Message Bus

Le terme ESB (Enterprise Service Bus, popularisé par Chappell, 2004) ajoute au Message Bus une couche de transformation et de routage dans le bus lui-même. La pratique moderne (microservices + cloud, ~2015+) tend à garder le bus mince (le broker) et à déplacer la transformation dans des Translators distincts en pipeline pipes-and-filters. C'est la philosophie « smart endpoints, dumb pipes » (Fowler, 2014).

Anti-patterns

Bus sans canonique. Brancher un bus mais laisser chaque appli pousser son format propriétaire = on garde le couplage, on a juste centralisé la queue. Le canonique est indispensable.
Logique métier dans le bus. Reproduire les pires excès de l'ESB des années 2000 : règles de gestion embarquées dans les configurations de routage du bus, intransportable en cas de migration. Garder le bus mince.
Bus mono-tenant unique. Pour un opérateur SaaS, ne pas multi-tenanter le bus expose à des risques de fuite et d'isolation. Penser tenantId dans l'enveloppe ou brokers séparés.
Pas de HA. Le bus est par construction le single point of failure. Au moins en cluster 3 nœuds, idéalement multi-AZ.

Patterns liés

Message Channel — le bus est un assemblage de canaux nommés.
Modèle canonique — la base contractuelle du bus.
Message Router — le routeur central du bus.
Pipes and Filters — comment structurer les traitements au-dessus du bus.

Sources

Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Message Bus (§137). enterpriseintegrationpatterns.com — Message Bus
Chappell D. — Enterprise Service Bus, O'Reilly, 2004. L'extension ESB du concept de bus, avec transformation et orchestration embarquées.
Fowler M. — Microservices, "Smart endpoints and dumb pipes", martinfowler.com, 2014. martinfowler.com — Microservices
Newman S. — Building Microservices, O'Reilly, 2e éd. 2021. Discussion approfondie du choix bus de messages vs. choreography vs. orchestration.

Fondamentaux

Standards

Messages phares

Outils