Message Store

Un broker n'est pas un stockage à long terme. Le Message Store persiste chaque message — entrant, sortant, intermédiaire — dans un object store indexé, pour l'audit, le rejeu, l'historique et la preuve fiscale.

Problème

Un broker de messages (Kafka, RabbitMQ, Service Bus) est conçu pour des temps de séjour courts : heures à jours. Mais l'EDI demande de garder une trace pendant 5 à 10 ans (factures), 3 à 5 ans (commandes, livraisons), parfois plus en cas de litige. Et le métier veut pouvoir relire ce qui s'est passé un mois plus tôt — pour répondre à un audit, comprendre un écart, rejouer une journée perdue. Sans Message Store, ces capacités ne tiennent pas : le broker a déjà supprimé.

Forces

Découpler durée de vie. Le broker garde pendant la durée de traitement ; le store garde pendant la durée légale.
Indexer pour recherche. Trouver « tous les INVOIC de Carrefour en mars 2026 » exige un index (Elasticsearch, OpenSearch, Postgres + GIN, etc.).
Rejeu sans contamination. Si on veut rejouer un INVOIC en 2031, on lit depuis le store, on le réinjecte dans le pipeline — on ne contamine pas le broker historique.
Preuve fiscale. Le store est l'élément de preuve produit lors d'un contrôle. Hash, horodatage, signature détachée si possible.

Solution

EIP §555 (Hohpe & Woolf, 2003) définit le Message Store comme un composant qui écoute tous les canaux du pipeline et persiste chaque message — souvent via un Wire Tap pour ne pas perturber le flux. Le store typique combine : (a) un object store pour le payload binaire (S3, Azure Blob, GCS), (b) un index relationnel ou Elasticsearch pour les métadonnées et la recherche, (c) une politique de rétention pilotée par le type de message. Le store sert ensuite trois cas d'usage : audit (lecture forensique), rejeu (réinjection dans le pipeline), historique (consultation portail).

plaintext topology.txt

┌───────┐         ┌───────┐         ┌────────┐
   │ src   │ ───▶   │ pipe  │ ───▶    │ dest   │
   └───────┘         └───────┘         └────────┘
                        │
                        │ tap (copy)
                        ▼
                   ┌──────────┐
                   │ message  │
                   │  store   │  ──▶ replay, audit, search
                   └──────────┘
                   (object store + index)

Implémentation EDI

Le Message Store EDI typique stocke chaque message à trois étapes : raw (tel que reçu du partenaire), canonical (après parsing & validation), outbound (tel que livré au partenaire ou à l'ERP). Cela permet de répondre à toute question d'audit, quel que soit l'angle.

json store-record.json

# Enregistrement Message Store typique
{
  "storeId": "01HVF8K3X1ABCDE0123456789",
  "messageId": "inv-202605140001",
  "interchangeRef": "INV202605140001",
  "type": "INVOIC",
  "format": "EDIFACT D96A",
  "stage": "inbound.raw",                # ou inbound.canonical, outbound.partner
  "tenantId": "ediverse-prod",
  "from": "5798000000122",
  "to":   "7300010000001",
  "receivedAt": "2026-05-14T12:00:00.123Z",
  "sizeBytes": 4218,
  "sha256": "9a4b1c2def8b6a5e8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b",
  "storageUri": "s3://ediverse-store/2026/05/14/inv-202605140001.edi",
  "ackChain": [
    { "type": "CONTRL", "receivedAt": "2026-05-14T12:00:05Z" },
    { "type": "APERAK", "receivedAt": "2026-05-14T12:00:42Z" }
  ],
  "retentionUntil": "2036-05-14T00:00:00Z",
  "legalHold": false
}

Lecture : chaque enregistrement porte l'identifiant technique (messageId), l'identifiant métier (interchangeRef), l'étape du pipeline (stage), le hash et l'URI du payload. La chaîne d'accusés (ackChain) est attachée à l'historique pour reconstituer le statut complet. La retentionUntil est calculée à l'enregistrement à partir du type et de la juridiction (10 ans pour les factures en France).

Audit fiscal. Lors d'un contrôle, l'opérateur doit pouvoir restituer chaque INVOIC émise sur 10 ans, avec la preuve cryptographique de son contenu et de son envoi.
Litige client. « Vous n'avez jamais envoyé cette facture » — le store répond avec la copie exacte signée, et la chaîne MDN/AS2 ou NRR/AS4 prouve la réception.
Rejeu après bug. Un bug du translator a mal traduit 200 INVOIC pendant 2 jours. Identifier les messages affectés via index, ré-injecter via le store en pointant sur la version corrigée du translator.
Migration. Lors de changement de hub d'intégration, le store nourrit le nouveau hub en historique sans perdre la traçabilité.

Rétention et coût

Trois leviers :

Tiers de stockage. Hot ≤ 30 jours, Warm 30-365 jours, Cold (S3 Glacier, Azure Cool Blob) au-delà. Coût × 10 inférieur en cold, latence de lecture en heures — acceptable pour de l'audit ponctuel.
Compression. Les EDIFACT, X12, UBL se compressent à 10-20 % de leur taille originale (XML répétitif, structures fixes). Activer gzip / zstd par défaut.
Déduplication. Hasher chaque payload (SHA-256) et stocker une seule fois ; partager via référence. Particulièrement efficace pour les catalogues qui répètent les mêmes lignes.

Anti-patterns

Utiliser le broker comme store. Garder Kafka en rétention infinie peut sembler économique, mais on perd les capacités de recherche et de tiering. Garder le broker court, déléguer au store.
Pas d'index. Un object store sans index est un cimetière. La capacité de recherche définit la valeur du store ; sans elle, on ne peut pas répondre aux audits.
Pas de hash. Sans empreinte cryptographique, la preuve juridique est faible. Toujours SHA-256 minimum, idéalement hash horodaté par un tiers de confiance pour les flux fiscaux.
Rétention uniforme. Tous les types de messages n'ont pas la même obligation. Configurer par type+juridiction.

Patterns liés

Wire Tap — l'outil pour alimenter le store sans perturber le flux.
Message History — la chaîne de composants traversés, stockée dans le store.
Claim Check — partage la même infrastructure object-store + index.
Dead Letter Channel — la DLQ archive aussi dans le Message Store.

Sources

Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Message Store (§555). enterpriseintegrationpatterns.com — Message Store
Code général des impôts, article L102B (France). Obligation de conservation des factures électroniques pendant 10 ans.
UE — Directive 2014/55/UE et règlement d'exécution sur la facturation électronique B2G, qui imposent des capacités d'archivage et de preuve pour 10 ans.
AWS Architecture Blog — Archival patterns with Amazon S3 Glacier. Référence moderne pour la mise en œuvre cold + WORM. aws.amazon.com/glacier

Fondamentaux

Standards

Messages phares

Outils