Smart Proxy

Le proxy intelligent qui ajoute mTLS, retries, cache devant un service tiers.

Problème

Un partenaire EDI expose une API capricieuse — limite de 100 req/s, sans cache, sans observability. Comment l'utiliser de manière fiable depuis un système moderne ?

Forces

• On ne peut pas modifier le partenaire — il est imposé.
• Le contrat fonctionnel doit rester respecté.
• Les fonctionnalités transversales (retries, cache, traces) ne doivent pas polluer le code métier.
• Le proxy doit être transparent — le client appelle comme si rien.

Solution

Déployer un Smart Proxy (typiquement Envoy, NGINX+, Kong, AWS API Gateway) devant le service partenaire. Le proxy ajoute : circuit breaker, rate limiting client-side, caching avec TTL, mTLS upgrade, OpenTelemetry traces, retries avec backoff. Le client appelle le proxy comme s'il appelait le partenaire — transparent.

Implémentation EDI

En EDI, le Smart Proxy est crucial pour : (1) AS2 partenaires avec certificats à courte durée — proxy gère le rollover, (2) APIs douanes (NCTS, ICS 2) — caching aggressive sur les codes statiques, (3) PEPPOL discovery (SMP lookups) — caching 1h. Implémentation : Envoy sidecar avec custom filters, ou Kong avec plugins lua.

Anti-patterns

• Proxy qui altère la sémantique métier — il doit rester transparent.
• Cache trop agressif — données obsolètes envoyées en aval.
• Pas de monitoring du proxy — il devient un trou noir.

Patterns liés

• Circuit Breaker — fonctionnalité du proxy.
• Wire Tap — observation possible via proxy.

Sources

• Hohpe G., Woolf B. — EIP, Smart Proxy (p. 558). www.enterpriseintegrationpatterns.com/patterns/messaging/SmartProxy.html
• Envoy Proxy — Documentation. www.envoyproxy.io/docs