ediverse

Tapez pour rechercher dans les standards, messages, outils et glossaire.

ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 01

Fondamentaux

— 02

Standards

— 03

Messages phares

— 04

Outils

Ambassador

Le sidecar qui prend en charge tout le hardening sortant — mTLS, retries, circuit breaker, observabilité — pour que l'application ne parle qu'à localhost.

Problème

Un service ERP doit envoyer des INVOIC à 50 partenaires hétérogènes : AS2 chez Walmart, AS4 chez Stellantis, SFTP chez Carrefour, HTTPS chez Amazon Vendor. Chacun a son schéma de retry, son certificat client, son endpoint, sa politique de timeout. Si le code applicatif embarque tout cela, il devient un nœud de configuration. La moindre rotation de certif déclenche un redéploiement applicatif.

Forces

  • Les protocoles sortants varient. AS2, AS4, SFTP, HTTPS, JMS — un par partenaire majeur, plus les versions.
  • Les patterns de fiabilité aussi. Retry, backoff, circuit breaker : configurés par partenaire selon son SLA.
  • Le code applicatif doit rester simple. Le métier n'est pas « envoyer en TLS 1.3 mutuel à walmart.com », c'est « émettre une INVOIC ».
  • Le langage applicatif peut manquer de bibliothèques. Python n'a pas le meilleur client AS2 ; un sidecar Java l'apporte.

Solution

Déployer aux côtés du conteneur applicatif un conteneur ambassadeur (typiquement Envoy ou un proxy custom). Le code métier appelle http://localhost:9090/partner/walmart en HTTP simple. L'ambassadeur gère : résolution DNS dynamique, terminaison mTLS, rotation de certificats, retries selon configuration partenaire, circuit breaker, export OpenTelemetry, mesure de latence. Le contrat entre l'app et l'ambassadeur est stable (localhost + path) ; la configuration externe évolue sans toucher au code. 

┌──────────────────────────────────────────────────────────┐
│  Pod                                                     │
│ ┌───────────────┐   localhost:9090   ┌─────────────────┐ │
│ │ App           │ ─────────────────▶ │ Ambassador      │ │
│ │ (HTTP plain)  │                    │ Envoy sidecar   │ │
│ └───────────────┘                    │ retries, mTLS,  │ │
│                                      │ circuit breaker │ │
│                                      └────────┬────────┘ │
└────────────────────────────────────────────────│─────────┘
                                                 │ mTLS
                                                 ▼
                          partenaires.edi (Walmart, Stellantis)

Implémentation EDI

Cas concret : dans un hub EDI Kubernetes, on déploie en sidecar un connecteur AS2 open-source (Mendelson AS2, OpenAS2, B2Bi de Sterling minimaliste). Le service applicatif Python publie un POST JSON sur localhost:8080/send/walmart ; l'ambassadeur convertit en AS2, signe S/MIME, chiffre, envoie via TLS 1.3, récupère le MDN signé, valide la signature, et republie l'événement sur Kafka. Rotation de certificat partenaire : kubectl rollout restart du sidecar, pas du service. Variante cloud : AWS App Mesh, Consul Connect, Linkerd — l'ambassadeur est généré automatiquement.

Anti-patterns

  • Ambassadeur transparent côté code. Si l'app doit quand même connaître les noms partenaires et leurs particularités, l'abstraction n'apporte rien. L'ambassadeur doit cacher la complexité, pas la déplacer.
  • Ambassadeur business logic. Mettre du mapping EDIFACT→JSON dans l'ambassadeur le transforme en Message Translator — autre pattern, à séparer.
  • Pas de circuit breaker. Sans coupure, l'ambassadeur retent à l'infini sur un partenaire down et bloque le code applicatif via timeouts.

Patterns liés

  • Sidecar — pattern parent ; l'ambassadeur est un sidecar spécialisé sortant.
  • Smart Proxy — la variante Hohpe, plus orientée ESB.
  • Circuit Breaker — toujours embarqué dans un ambassadeur production.
  • Service Mesh — l'ambassadeur généralisé par maillage.

Sources