— Patterns d'intégration
Patterns d'intégration EDI
Cent quarante patterns architecturaux que toute équipe d'intégration EDI redécouvre tôt ou tard. Ils existent dans la littérature d'architecture logicielle générique — Enterprise Integration Patterns de Hohpe et Woolf, Circuit Breaker de Fowler, articles AWS sur le backoff, RFC IETF, Sagas de Garcia-Molina & Salem, Bulkhead de Nygard, semantics de livraison de Kleppmann, Debezium CDC, Data Mesh de Dehghani, Raft d'Ongaro & Ousterhout, Zero Trust de NIST SP 800-207 — mais leur déclinaison concrète aux flux EDIFACT, X12 et UBL/AS4 n'est jamais documentée au même endroit. Cette section comble ce manque, couvrant vingt familles de patterns du couplage faible à la résilience, du monitoring synthétique à la sécurité Zero Trust en passant par eventing détaillé et passage à l'échelle.
Fiabilité
-
Pattern · 01
Acquittements (functional ACK, MDN, EERP)
Trois niveaux d'accusé empilés — protocole, fonctionnel, métier — pour distinguer « j'ai reçu les octets », « la syntaxe est bonne », « j'ai pris en compte ».
Lire le pattern → -
Pattern · 02
Idempotence et déduplication (récepteur)
Une commande ne doit jamais être livrée deux fois. Référence de contrôle UNB, ISA13, MessageId AS4 — comment fixer la fenêtre d'unicité.
Lire le pattern → -
Pattern · 03
Idempotency Key (émetteur)
Le pendant émetteur : générer, persister et réutiliser une clé stable avant tout retry. Sans elle, la dédup récepteur ne sert à rien.
Lire le pattern → -
Pattern · 04
Retry, backoff exponentiel et circuit breaker
Quand le partenaire ne répond pas : exponentiel + jitter + plafond, circuit breaker pour ne pas amplifier les pannes, dead-letter queue.
Lire le pattern →
Sémantiques de livraison
-
Pattern · 05
At-Least-Once Delivery
La sémantique par défaut de tout EDI réaliste : livraison garantie au moins une fois, doublons possibles, à dédoublonner côté récepteur. Kleppmann chap. 11.
Lire le pattern → -
Pattern · 06
At-Most-Once Delivery
Le pendant fire-and-forget : zéro ou une livraison, jamais deux. Réservé aux flux non-critiques (télémétrie, IFTSTA non-réglementaire). Kafka acks=0.
Lire le pattern →
Architecture
-
Pattern · 07
Modèle canonique interne
Un schéma JSON pivot pour éviter le problème du mapping n × m entre partenaires : chaque partenaire ne parle qu'au canonique.
Lire le pattern → -
Pattern · 08
Flux d'exception et matrice d'escalade
Quand la validation échoue, quand l'accusé est absent, quand le partenaire diverge : catalogue des sorties de boucle.
Lire le pattern → -
Pattern · 09
Event Sourcing
Stocker l'historique complet des événements métier comme journal append-only et reconstruire l'état courant par rejeu. Fowler 2005, Young 2010.
Lire le pattern → -
Pattern · 10
CQRS — Command Query Responsibility Segregation
Séparer le modèle d'écriture du modèle de lecture. Sur un hub EDI : un côté commande encaisse, un côté lecture publie KPI, tracking, journal fiscal.
Lire le pattern → -
Pattern · 11
Data Mesh appliqué à l'EDI
Les quatre principes Dehghani (domain ownership, data as a product, self-service platform, federated governance) appliqués à un hub EDI multi-domaines.
Lire le pattern →
Canaux
-
Pattern · 12
Message Channel
Le conduit nommé entre émetteur et récepteur — la brique de base de toute messagerie EDI (AS2, AS4, SFTP, Kafka). EIP §60.
Lire le pattern → -
Pattern · 13
Point-to-Point Channel
Un émetteur, un récepteur exclusif. La sémantique par défaut de l'AS2 et de la majorité des connexions EDI bilatérales. EIP §103.
Lire le pattern → -
Pattern · 14
Publish-Subscribe Channel
Un émetteur, plusieurs abonnés indépendants. Le modèle de diffusion SBDH/PEPPOL multi-cibles et des événements internes du hub. EIP §106.
Lire le pattern → -
Pattern · 15
Competing Consumers
N consommateurs concurrents tirent depuis un même canal pour passer à l'échelle horizontalement. Le pattern de scaling des parsers et validateurs en hub à fort volume. EIP §502.
Lire le pattern → -
Pattern · 16
Message Endpoint
Le point de raccordement code métier ↔ système de messagerie EDI — la couche d'abstraction qui rend AS2/AS4/SFTP interchangeables. EIP §95.
Lire le pattern → -
Pattern · 17
Datatype Channel
Un canal, un type — la règle qui rend les consumers prévisibles et le routage simple (edi.orders, edi.invoices…). EIP §111.
Lire le pattern → -
Pattern · 18
Invalid Message Channel
Le canal des messages bien formés mais sémantiquement invalides — distinct du Dead Letter Channel des erreurs techniques. EIP §115.
Lire le pattern → -
Pattern · 19
Guaranteed Delivery
L'assurance broker qu'aucun message ne se perd même en cas de crash — Kafka acks=all, min.insync.replicas=2. EIP §122.
Lire le pattern →
Topologie
-
Pattern · 20
Pipes and Filters
Composer le pipeline en étages atomiques (parse → valider → enrichir → traduire → livrer) reliés par des canaux. EIP §70.
Lire le pattern → -
Pattern · 21
Message Bus
Une dorsale commune où se branchent ERP, WMS, TMS, portail, lake et hub EDI. Le passage de N² liens spaghetti à 2N organisés. EIP §137.
Lire le pattern → -
Pattern · 22
Message Store
Persister chaque message qui passe pour l'audit, le rejeu, l'historique, la preuve fiscale 10 ans. EIP §555.
Lire le pattern →
Routage
-
Pattern · 23
Message Router
Aiguillage stateless d'un message vers un canal selon ses en-têtes — type, partenaire, environnement. Le pattern fondateur du routage EDI (EIP §109).
Lire le pattern → -
Pattern · 24
Content-Based Router
Le routeur qui inspecte la charge utile pour décider de la destination : pays de livraison, montant total, devise. EIP §230.
Lire le pattern → -
Pattern · 25
Splitter
Éclater un message composite en plusieurs messages atomiques. Un INVOIC EDIFACT de 100 factures devient 100 messages. EIP §259.
Lire le pattern → -
Pattern · 26
Aggregator
Recomposer un message à partir de plusieurs messages liés : 15 DESADV consolidés en un INVOIC mensuel. EIP §268.
Lire le pattern → -
Pattern · 27
Dynamic Router
Routeur qui apprend ses règles à l'exécution — chaque consumer s'annonce avec ses capacités, le routeur met à jour sa table. EIP §243.
Lire le pattern → -
Pattern · 28
Message Filter
Le filtre sélectif — drop silencieux des messages ne correspondant pas aux critères, à ne pas confondre avec le router. EIP §237.
Lire le pattern → -
Pattern · 29
Resequencer
Remettre dans l'ordre des messages reçus en désordre selon un sequenceId — utile après split parallèle. EIP §283.
Lire le pattern → -
Pattern · 30
Composed Message Processor
Splitter + Router + Aggregator dans un pipeline structuré — pour traiter un INVOIC à 100 lignes en parallèle. EIP §294.
Lire le pattern → -
Pattern · 31
Scatter-Gather
Fan-out/fan-in — demander à 5 fournisseurs en parallèle (REQOTE) et agréger leurs réponses. EIP §297.
Lire le pattern →
Transformation
-
Pattern · 32
Message Translator
Convertir un message d'un schéma vers un autre : EDIFACT ORDERS vers JSON canonique, X12 850 vers SAP IDoc. EIP §85.
Lire le pattern → -
Pattern · 33
Normalizer
Détecter le format d'un message entrant (EDIFACT, X12, cXML, UBL) et l'orienter vers le bon Translator. La porte d'entrée d'un hub. EIP §352.
Lire le pattern → -
Pattern · 34
Content Enricher
Injecter dans un message les champs qu'il ne porte pas : résoudre un GLN en adresse, un GTIN en libellé produit. EIP §336.
Lire le pattern →
Processus
-
Pattern · 35
Process Manager
Orchestrer le cycle PO → ORDRSP → DESADV → INVOIC → REMADV en machine à états stateful avec timers et compensations. EIP §312.
Lire le pattern → -
Pattern · 36
Routing Slip
Le message porte son propre itinéraire ; chaque étape lit la suivante et transmet. Modèle classique du cXML PunchOut. EIP §301.
Lire le pattern → -
Pattern · 37
Saga Choreography
Saga sans orchestrator central : chaque service réagit aux événements de domaine et émet les siens. PO ↔ ASN ↔ INVOIC ↔ REMADV en mode pub/sub.
Lire le pattern →
Résilience
-
Pattern · 38
Back-pressure
Quand l'aval ne suit pas, ralentir l'amont — TCP RWIN, Kafka quotas, Reactive Streams request(n), AS4 503 + Retry-After. Reactive Streams 2015.
Lire le pattern → -
Pattern · 39
Bulkhead
Isoler les pools de threads, de connexions et de mémoire par partenaire EDI : un Walmart en panne n'affecte plus Carrefour, Stellantis, BNP. Nygard Release It! 2018.
Lire le pattern → -
Pattern · 40
Rate Limiter
Plafonner le débit accepté par partenaire pour protéger l'aval. Token bucket / leaky bucket, HTTP 429 + Retry-After, Kafka quotas. RFC 2697, 6585.
Lire le pattern →
Observabilité
-
Pattern · 41
Wire Tap
Greffer un observateur passif sur un canal pour alimenter lake, audit, KPI sans perturber le flux métier. EIP §547.
Lire le pattern → -
Pattern · 42
Message History
Le message porte la liste de tous les composants qu'il a traversés — versions, horodatages, actions. La pierre angulaire du débogage distribué. EIP §551.
Lire le pattern →
Endpoints
-
Pattern · 43
Dead Letter Channel
Le canal où va un message qui ne peut pas être traité : syntaxe cassée, format inconnu, validation échouée. Empêcher les pertes silencieuses. EIP §119.
Lire le pattern → -
Pattern · 44
Claim Check
Externaliser un gros payload dans un object store et ne passer qu'une référence dans la queue. Pour les INVOIC de 100 MB. EIP §358.
Lire le pattern → -
Pattern · 45
Circuit Breaker
Quand un partenaire EDI est down, ne pas le marteler — ouvrir le circuit, échouer rapidement, sonder avant de rétablir. Fowler, 2014.
Lire le pattern → -
Pattern · 46
Polling Consumer
Le consumer pull qui interroge à intervalle régulier — le polling SFTP/FTPS legacy. EIP §494.
Lire le pattern → -
Pattern · 47
Event-Driven Consumer
Le consumer push prévenu en temps réel — le standard Kafka/SQS/SNS moderne. EIP §498.
Lire le pattern → -
Pattern · 48
Transactional Client
L'atomicité métier ↔ messaging — l'Outbox pattern qui garantit que message envoyé = DB committée. EIP §484.
Lire le pattern →
Styles de message
-
Pattern · 49
Command Message
Le message-ordre — une intention claire d'action (ORDERS = passe la commande). EIP §145.
Lire le pattern → -
Pattern · 50
Document Message
Le message-document — un fait métier qui circule, pas une commande (INVOIC, DESADV, PRICAT). EIP §147.
Lire le pattern → -
Pattern · 51
Event Message
Le message-notification — pub/sub temps réel, le pattern du Kafka moderne (OrderConfirmed, InvoicePaid). EIP §151.
Lire le pattern →
Management & monitoring
-
Pattern · 52
Control Bus
Le canal admin parallèle au canal métier — démarrer, arrêter, reconfigurer un composant à chaud. EIP §540.
Lire le pattern → -
Pattern · 53
Test Message
Le canari synthétique — INVOIC de test toutes les 5 min pour vérifier que la chaîne respire. EIP §569.
Lire le pattern → -
Pattern · 54
Channel Purger
Le bouton 'vider la queue' — outil ops contrôlé avec archive et audit obligatoires. EIP §572.
Lire le pattern → -
Pattern · 55
Smart Proxy
Le proxy intelligent qui ajoute retries, cache, mTLS, observability devant un service partenaire. EIP §558.
Lire le pattern → -
Pattern · 56
Detour
Le détour optionnel — activer/désactiver une étape (audit, A/B test) sans redéployer. EIP §545.
Lire le pattern →
Corrélation & coordination
-
Pattern · 57
Return Address
Le message porte l'adresse de retour de la réponse plutôt que de la déduire d'un annuaire. AS2 Receipt-Delivery-Option, AS4 ReplyPattern. EIP §159.
Lire le pattern → -
Pattern · 58
Correlation Identifier
Chaque réponse pointe la requête d'origine pour fermer la boucle : AK1/AK2 du 997, UCI/UCM de CONTRL, Original-Message-ID de MDN. EIP §163.
Lire le pattern → -
Pattern · 59
Format Indicator
Le message déclare son format et sa version dès la première ligne : UNH S009, GS08, Content-Type AS2. EIP §180.
Lire le pattern → -
Pattern · 60
Recipient List
L'émetteur calcule la liste exacte des destinataires par message : SBDH multi-Receiver, modèle 5-coins PEPPOL pour la CTC. EIP §249.
Lire le pattern →
Endpoints & receivers
-
Pattern · 61
Selective Consumer
Le filtrage côté queue plutôt que côté code — JMS selectors, Kafka headers — pour éviter de pull-and-drop. EIP §515.
Lire le pattern → -
Pattern · 62
Durable Subscriber
Le subscriber pub/sub qui conserve son inscription offline — Kafka consumer groups, JMS clientId. EIP §522.
Lire le pattern → -
Pattern · 63
Idempotent Receiver
La déduplication côté consumer — distincte de l'idempotency producer, complémentaire pour at-least-once brokers. EIP §528.
Lire le pattern → -
Pattern · 64
Service Activator
Le pont entre la queue async et une API legacy sync — la passerelle Camel/Spring Integration classique. EIP §532.
Lire le pattern → -
Pattern · 65
Messaging Bridge
Le pont entre deux brokers hétérogènes — pour migrer progressivement d'AS2 Sterling vers Kafka sans rupture. EIP §133.
Lire le pattern →
Composition & translation
-
Pattern · 66
Envelope Wrapper
Le pattern racine de l'EDI — UNB/UNH, ISA/GS, SBDH — l'enveloppe qui porte identification, routage, ack, signature. EIP §330.
Lire le pattern → -
Pattern · 67
Content Filter
L'élagage du message (vs Message Filter qui jette le message entier) — drop PII inutiles, métadonnées internes, lignes verbeuses. EIP §342.
Lire le pattern → -
Pattern · 68
Mapping
L'artefact qui matérialise les correspondances champ-à-champ entre schémas — base du Message Translator et du Canonical Model.
Lire le pattern → -
Pattern · 69
Transactional Channel
Le canal qui couple commit DB et commit broker — XA chez IBM MQ, Outbox sur Kafka. Alias topologique du Transactional Client.
Lire le pattern → -
Pattern · 70
Message Broker
Le hub étoile qui découple N émetteurs et M receveurs — un seul point d'échange au lieu d'un maillage N×N. EIP §322.
Lire le pattern →
Topologie & infrastructure
-
Pattern · 71
Process Engine
Le runtime BPMN/workflow qui fait tourner les Process Managers EDI longue durée — Camunda, Temporal, Step Functions.
Lire le pattern → -
Pattern · 72
Saga Orchestration
Long-running transaction avec compensations explicites — la voie pragmatique sans XA, multi-systèmes (Garcia-Molina/Salem, 1987).
Lire le pattern → -
Pattern · 73
Outbox (architectural)
La table tampon qui transforme deux écritures non-coordonnées (DB + broker) en une écriture atomique côté DB — pattern dominant ERP→Kafka.
Lire le pattern → -
Pattern · 74
Inbox (architectural)
Le miroir de l'Outbox côté consumer — un journal des évènements consommés pour éviter qu'un retry broker ne re-déclenche un side effect.
Lire le pattern → -
Pattern · 75
Change Data Capture
Capturer les changements d'une DB en temps réel via WAL/binlog (Debezium) — la voie non-intrusive pour brancher un ERP legacy sur un hub EDI moderne.
Lire le pattern →
Eventing
-
Pattern · 76
Event-Carried State Transfer
L'évènement contient l'état complet — Fowler 2017. Les consommateurs reconstituent leur cache local sans appel synchrone vers le producteur.
Lire le pattern → -
Pattern · 77
Event Notification
Évènement minimaliste (id + type + timestamp) ; le consommateur intéressé rappelle l'API du producteur pour les détails. Le pendant léger de l'ECST.
Lire le pattern → -
Pattern · 78
Transactional Outbox (deep dive)
Le Transactional Outbox en détail : schéma de la table, choix polling/CDC, gestion de l'ordre, idempotence, purge, observabilité.
Lire le pattern → -
Pattern · 79
Transactional Inbox (deep dive)
Le miroir consommateur : table inbox qui enregistre l'idempotency key avant tout side effect, retraitement sûr en mode at-least-once.
Lire le pattern → -
Pattern · 80
CDC pipeline (deep dive)
Pipeline CDC bout-en-bout : source connector, schema registry, SMT, sink connectors, monitoring du lag. Pour transformer un ERP legacy en source de vérité streaming.
Lire le pattern →
Concurrence & passage à l'échelle
-
Pattern · 81
Leader Election
Élire un seul nœud parmi N pour exécuter une tâche qui ne tolère pas la concurrence (poller unique, ordonnanceur). ZooKeeper, etcd, Raft, Kubernetes Lease.
Lire le pattern → -
Pattern · 82
Consensus (Raft)
Algorithme de consensus distribué d'Ongaro & Ousterhout (2014). Décompose le problème en élection de leader, réplication du log et sûreté. Base de etcd, Consul, CockroachDB.
Lire le pattern → -
Pattern · 83
Consistent Hashing
Placement de clés sur un anneau virtuel qui minimise le rééquilibrage lors d'ajouts/retraits de nœuds. Karger et al. 1997, base d'Amazon Dynamo, Cassandra, des CDN.
Lire le pattern → -
Pattern · 84
Sharding
Partitionnement horizontal des données pour passer à l'échelle au-delà des limites d'une instance unique. Stratégies : par hash, par range, par lookup.
Lire le pattern → -
Pattern · 85
Partition Tolerance (CAP)
Le P du théorème CAP (Brewer 2000). Un système distribué doit continuer à fonctionner malgré le partitionnement réseau, en choisissant entre cohérence et disponibilité.
Lire le pattern →
Sécurité
-
Pattern · 86
Zero Trust Architecture
Architecture sans périmètre de confiance : chaque requête est authentifiée, autorisée et chiffrée. NIST SP 800-207, BeyondCorp Google, Forrester 2010.
Lire le pattern → -
Pattern · 87
Defense in Depth
Empiler plusieurs couches de défense indépendantes plutôt que de tout miser sur une barrière unique. NIST SP 800-53, NSA, OWASP.
Lire le pattern → -
Pattern · 88
Principle of Least Privilege
Chaque acteur reçoit le minimum strict de droits nécessaires à sa fonction. Saltzer & Schroeder 1975. Conséquences pour IAM, comptes de service Kubernetes, partenaires EDI.
Lire le pattern → -
Pattern · 89
Secrets Management
Cycle de vie des secrets (cred, clés, certificats) : génération, stockage chiffré, distribution, rotation, révocation, audit. Vault, KMS, Secrets Manager.
Lire le pattern → -
Pattern · 90
Mutual TLS Pattern
Authentification bidirectionnelle par certificats X.509 — RFC 8446 (TLS 1.3). Brique cryptographique du Zero Trust et de tout flux EDI AS2/AS4.
Lire le pattern →
Résilience & migration
-
Pattern · 91
Feature Flag
Découpler le déploiement d'une nouvelle version (mapping, validateur) de sa visibilité en production. LaunchDarkly, Unleash, taxonomie Hodgson 2017.
Lire le pattern → -
Pattern · 92
Blue-Green Deployment
Deux environnements identiques en parallèle, bascule atomique par le routeur de trafic. Le pattern de déploiement infrastructure sans downtime. Fowler 2010.
Lire le pattern → -
Pattern · 93
Canary Release
Rollout progressif (1% → 10% → 50% → 100%) avec surveillance SLO et rollback automatique. Sato 2014, SRE Google §16. Le pattern de référence pour le rollout EDI 2026.
Lire le pattern → -
Pattern · 94
Dark Launch
Le trafic est dupliqué vers la nouvelle version, ses résultats sont comparés à l'ancienne sans être renvoyés au partenaire. Github Scientist, Facebook Engineering.
Lire le pattern → -
Pattern · 95
Chaos Engineering
Injecter délibérément des défaillances en production contrôlée pour valider la résilience. Netflix Chaos Monkey, principles of chaos, Rosenthal et al. 2020.
Lire le pattern →
Workflow & processus
-
Pattern · 96
State Machine (cycle de vie partenaire)
Variante du pattern State Machine pour le cycle technique d'un partenaire EDI : prospect, scoped, certs, tested, production-active, archived. Complément du State Machine message.
Lire le pattern → -
Pattern · 97
Temporal Workflow
Workflow long-running en code, exécution durable, retry automatique, sleeps durables. Fork de Cadence (Uber), adopté par Stripe, Snap, Doordash, HashiCorp Vault.
Lire le pattern → -
Pattern · 98
Step Functions
Workflow déclaratif géré (AWS Step Functions ASL, Google Cloud Workflows, Azure Logic Apps) pour sagas EDI cloud-native sans maintenir un orchestrateur.
Lire le pattern → -
Pattern · 99
Compensating Action
L'opération inverse qui annule sémantiquement une étape déjà commitée dans une saga. Pilier des Long Lived Transactions (Garcia-Molina & Salem 1987).
Lire le pattern → -
Pattern · 100
Retry With Jitter
Backoff exponentiel + composante aléatoire pour briser la synchronisation des clients et éviter les retry storms. Marc Brooker AWS 2015, intégré dans toutes les bibliothèques modernes.
Lire le pattern →
Transactions distribuées
-
Pattern · 101
Two-Phase Commit (2PC)
Protocole atomique distribué formalisé par Jim Gray (1978). Phase 1 prepare, phase 2 commit ou abort. Bloquant si coordinateur tombe, fondement historique des transactions XA.
Lire le pattern → -
Pattern · 102
Three-Phase Commit (3PC)
Variante non-bloquante de 2PC proposée par Dale Skeen (1981). Phase pre-commit insérée. Bloquant sous partition réseau, rarement utilisé en production.
Lire le pattern → -
Pattern · 103
Paxos consensus
Algorithme de consensus distribué formalisé par Leslie Lamport (1989, publié 1998). Brique de Google Chubby, Cassandra LWT, Spanner. Réputé difficile à comprendre.
Lire le pattern → -
Pattern · 104
Byzantine Fault Tolerance
Famille de protocoles tolérant des nœuds malveillants. Origine Lamport-Shostak-Pease 1982, PBFT Castro-Liskov 1999. Quorum minimal 3f+1, base des blockchains permissionnées.
Lire le pattern → -
Pattern · 105
Vector Clocks
Structure capturant l'ordre causal des événements distribués (Mattern 1989, Fidge 1988, sur Lamport 1978). Brique d'Amazon Dynamo, Riak pour détecter les écritures concurrentes.
Lire le pattern →
Stream processing
-
Pattern · 106
Tumbling Window
Fenêtre temporelle fixe sans chevauchement. Pivot des agrégations périodiques (volume horaire, KPI quotidiens, rapports fiscaux). Akidau Dataflow 2015, Flink, Spark, Kafka Streams.
Lire le pattern → -
Pattern · 107
Sliding Window
Fenêtre temporelle glissante à pas plus petit que sa taille. Pivot pour métriques continues (moyenne mobile, taux d'erreur 5 dernières min). Akidau Dataflow 2015.
Lire le pattern → -
Pattern · 108
Session Window
Fenêtre activity-based démarrée à un évènement, fermée après gap d'inactivité. Adapté aux interactions discontinues (batch INVOIC d'un partenaire). Akidau Dataflow 2015.
Lire le pattern → -
Pattern · 109
Watermarks
Mécanisme de progression du temps stream : « tous évènements ≤ T sont arrivés ». Compromis exactitude/latence dans tout système out-of-order. Akidau Dataflow 2015.
Lire le pattern → -
Pattern · 110
Exactly-Once Semantics
Garantie de traitement « exactement une fois » dans un pipeline streaming distribué. Combine idempotence, checkpointing Chandy-Lamport, transactions Kafka, 2PC sink.
Lire le pattern →
Messaging reliability
-
Pattern · 111
CQRS pour streams d'événements B2B
Séparer le modèle d'écriture (commandes EDI, sagas, ACK) du modèle de lecture (KPI, tracking, journal fiscal) sur un hub B2B. Young 2010, Fowler 2011.
Lire le pattern → -
Pattern · 112
Event Sourcing avec journal EDI append-only
Persister chaque événement métier EDI dans un journal immuable, reconstruire l'état par rejeu, archivage fiscal 10 ans natif. Fowler 2005, eIDAS.
Lire le pattern → -
Pattern · 113
Saga : chorégraphie vs orchestration
Critères de choix entre topologie pub/sub décentralisée et orchestrator centralisé pour les sagas EDI long-running. Garcia-Molina 1987, Temporal, Camunda.
Lire le pattern → -
Pattern · 114
Compensating Transactions
L'opération inverse métier qui annule sémantiquement une étape commitée de saga : ORDRSP négatif, CRDADV, contre-virement SEPA. Pilier des sagas.
Lire le pattern → -
Pattern · 115
Transactional Outbox
Atomiciter DB+broker sans XA via une table outbox locale drainée par polling ou CDC Debezium. Le pattern dominant ERP→Kafka en 2026.
Lire le pattern → -
Pattern · 116
Transactional Inbox
Le miroir consumer de l'Outbox : dédupliquer at-least-once en inscrivant l'id message dans la même TX que le side effect. Vasters, Helland.
Lire le pattern → -
Pattern · 117
Idempotent Receiver pour flux EDI
Idempotence métier sur clés contractuelles EDIFACT/X12/UBL (UNB 0020, ISA13, BT-1, AS4 MessageId) avec fenêtres dédup partenaire. EIP §528.
Lire le pattern → -
Pattern · 118
Message Deduplication Ledger
Registre unifié de déduplication cross-broker pour un hub multi-tenant : hot Redis, cold PostgreSQL partitionné, archive S3. Helland 2012.
Lire le pattern → -
Pattern · 119
Dead-Letter Queue : variantes et runbooks
Cinq variantes opérationnelles modernes : retry étagé, DLQ par cause, parking lot, sonde de fuite, runbook de retraitement. AWS SQS, Kafka, Spring.
Lire le pattern → -
Pattern · 120
Poison Message Handling
Détecter le message qui plante systématiquement le consumer (poison pill), isoler dans une quarantine queue, analyser en sandbox. Nygard, OWASP ReDoS.
Lire le pattern →
Pourquoi tout le monde les redécouvre
L'EDI est un domaine où les standards de transport (AS2, AS4, OFTP2) et les standards de message (EDIFACT, X12, UBL) sont publics, mais les pratiques d'intégration — comment retenter un envoi, où dédupliquer, quand abandonner, comment éclater un batch — restent dans les têtes des architectes et dans les manuels partenaires privés. Chaque nouvelle équipe d'intégration finit par buter sur les mêmes pièges : le 997 X12 que l'on confond avec l'ORDRSP, le control reference number que l'on ré-utilise, l'INVOIC géant qui sature la queue, la commande qui passe deux fois pendant un incident. Cette section codifie ces pièges et leur solution.
Liste de lecture
- Hohpe G., Woolf B. — Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions, Addison-Wesley, 2003. Le catalogue fondateur. Les patterns Message Idempotency, Guaranteed Delivery, Dead Letter Channel et Canonical Data Model qu'on cite dans cette section viennent de ce livre. enterpriseintegrationpatterns.com
- Fowler M. — Circuit Breaker (martinfowler.com, 2014). La description canonique du pattern reprise depuis dans toutes les piles cloud-native. martinfowler.com/bliki/CircuitBreaker.html
- RFC 5681 — TCP Congestion Control (IETF, septembre 2009). La référence du backoff exponentiel dans la pile IP, à laquelle renvoient toutes les bibliothèques HTTP modernes. rfc-editor.org/rfc/rfc5681
- AWS Architecture Blog — « Exponential Backoff And Jitter » (Marc Brooker, 2015). L'article de référence sur pourquoi le jitter casse les retry storms. aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter
- Walmart Supplier Center — Walmart EDI Guidelines. Les manuels d'EDI Walmart formalisent depuis 30 ans les pratiques d'ACK, de retransmission et d'escalade qui ont diffusé dans toute la grande distribution. supplier.walmart.com/edi
- OpenPEPPOL — PEPPOL Reception Profile — codifie l'usage de l'accusé AS4 NRR dans le réseau, transposable comme référence pour tous les schémas de receipt cryptographique.
- Index canonique en ligne enterpriseintegrationpatterns.com/patterns/messaging — la page d'accueil du catalogue EIP en ligne, qui sert de référence canonique pour chaque pattern de routage et de transformation cité dans cette section.
- Apache Camel — EIP Reference. L'implémentation open-source de référence des patterns Hohpe : routing, splitter, aggregator, normalizer. Utile pour vérifier les choix d'implémentation modernes. camel.apache.org — EIP
- Nygard M. — Release It! Design and Deploy Production-Ready Software, Pragmatic Bookshelf, 2007 (2e éd. 2018). Les patterns de stabilité (bulkhead, circuit breaker, timeout, fail fast) appliqués aux pipelines de messagerie.