Conduit

Ce qu'ediverse considère « in-scope » pour Conduit

• Approfondissement des 5 patterns actuels. Études de cas réelles (anonymisées) sur des grands distributeurs, des OEM automobiles, des Access Points PEPPOL. Métriques observées, MTTR observés, anti-patterns détectés en audit.
• 10 à 15 patterns supplémentaires centrés sur l'opération : monitoring distribué (signaux dorés appliqués à l'EDI), reconciliation comptable, partner onboarding, gestion de catalogues, schéma de versionnement des mappings, blue/green deployment d'un mapping.
• Modèles de référence sectoriels. Architecture type d'un Access Point PEPPOL, d'une plateforme EDIFACT automobile (Stellantis, VW), d'un fournisseur HIPAA, d'un opérateur cXML (Ariba/SAP Business Network).
• Patterns d'intégration avec les LLM et les agents — mapping assisté, validation conversationnelle, génération automatique de DocOps depuis le canonique.

Ce qu'ediverse ne couvrira pas

• Implémentations concrètes en code propriétaire. ediverse documente les patterns, pas les solutions des éditeurs. Si vous voulez du code Mulesoft, Boomi ou Workato, ce n'est pas ici.
• Concurrence avec OAGi ou OpenPEPPOL. Ces organisations publient des canoniques officiels — ediverse les documente et y renvoie, mais ne tentera pas de produire un standard concurrent.
• Plateforme SaaS ou outil propriétaire. ediverse reste une plateforme éditoriale open knowledge, pas un produit. Les patterns sont accompagnés d'outils diagnostiques côté navigateur (validateurs), pas de runtime d'exécution.
• Conseil sur mesure ou benchmark vendor. Le contenu publié est généraliste et public ; un audit de plateforme ou un comparatif d'éditeurs sort du périmètre ediverse.

Pourquoi « Conduit » ?

Un conduit, en anglais comme en français, désigne le canal d'écoulement entre deux espaces — un terme volontairement neutre qui décrit ce qu'un système d'intégration EDI fait réellement : canaliser des messages métier entre des organisations différentes sans en imposer la sémantique. Le nom évite le langage de produit ou de plateforme, et signale qu'ediverse écrit sur l'architecture, pas sur des outils.

La V5+ pourra renommer la section si une meilleure étiquette s'impose. Pour l'instant, Conduit suffit comme marqueur.

Liste de lecture en attendant

• Hohpe G., Woolf B. — Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions (Addison-Wesley, 2003). Le catalogue de référence qui sous-tend la quasi-totalité des patterns de cette section. enterpriseintegrationpatterns.com
• Fowler M. — Patterns of Enterprise Application Architecture (Addison-Wesley, 2002). Pour les patterns applicatifs côté ERP, qui complètent les patterns d'intégration.
• Newman S. — Building Microservices (2nd edition, O'Reilly, 2021). Les chapitres sur la résilience inter-services se transposent directement aux flux EDI.
• Kleppmann M. — Designing Data-Intensive Applications (O'Reilly, 2017). Le chapitre sur la réplication et la cohérence éventuelle éclaire les questions d'idempotence en EDI.
• Google SRE Book — la lecture des chapitres monitoring et incident response est gratuite et directement utile pour la matrice d'escalade EDI. sre.google/books
• OAGi BODs documentation — pour ceux qui veulent adopter un canonique standard plutôt que d'en construire un. oagi.org
• OASIS — AS4 Profile of ebMS 3.0 v1.0. Bien que centré sur le transport, ce document est aussi un excellent exemple de design pattern « just-enough » à étudier. docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile

Navigation transversale

• Patterns d'intégration EDI — les 5 patterns actuellement documentés.
• Fondamentaux EDI — le parcours d'onboarding pour les nouveaux arrivants.
• Comparaison des cinq protocoles — AS2, AS4, OFTP2, SFTP, VAN.
• Catalogue des standards — EDIFACT, X12, cXML, OCI, UBL/PEPPOL et la famille AS2/AS4/OFTP2.
• Glossaire — les acronymes et concepts à connaître avant de lire les patterns.