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

Sidecar

Le processus auxiliaire collé au conteneur applicatif — partageant localhost, mémoire ou volume — pour ajouter des capacités transverses sans recompiler.

Problème

Un connecteur AS2 écrit en Java 6 par un éditeur disparu fonctionne depuis 15 ans. On lui demande désormais de produire des logs structurés OpenTelemetry, de chiffrer en mTLS sortant moderne, de signer en SHA-256 au lieu de SHA-1, et d'exposer des métriques Prometheus. Le code source est partiellement perdu, l'éditeur n'existe plus, le JDK n'est plus supporté. Modifier le binaire est risqué : une régression coûte un mois d'INVOIC bloqués.

Forces

  • Le code applicatif est figé. Soit pour des raisons contractuelles (certification partenaire), soit techniques (binaire legacy), soit organisationnelles (équipe partie).
  • Les besoins transverses évoluent. mTLS, observabilité, conformité : standards qui changent tous les deux ans.
  • Le déploiement Kubernetes l'autorise. Un Pod peut embarquer plusieurs conteneurs partageant network et volumes — la brique technique du sidecar.
  • L'overhead opérationnel double. Deux conteneurs à surveiller, deux versions à coordonner.

Solution

Déployer le conteneur applicatif et un conteneur sidecar dans le même Pod. Le sidecar intercepte le trafic (proxy Envoy en mode iptables redirect), lit les fichiers de log via volume partagé, ou expose une API que le conteneur principal appelle en localhost. Il porte les concerns transverses — terminaison mTLS, signature crypto moderne, log shipping vers Loki, tracing OpenTelemetry, validation de schéma EDI. Le conteneur principal reste intouché. 

┌──────────────────────────────────────────────────────┐
│  Pod Kubernetes                                      │
│ ┌─────────────────┐   localhost   ┌────────────────┐ │
│ │ Conteneur app   │ ────────────▶ │ Sidecar Envoy  │ │
│ │ EDI translator  │   :15001      │ mTLS + logs    │ │
│ │ Java / Python   │ ◀──────────── │ trace export   │ │
│ └─────────────────┘               └────────────────┘ │
│ shared volume /var/log/edi  ⟶  Fluent Bit sidecar    │
└──────────────────────────────────────────────────────┘
                       │
              partenaire Walmart (mTLS sortant)

Implémentation EDI

Cas concret : un connecteur AS2 legacy (Sterling B2B ancien) tourne sur le port 8443 en HTTP/1.1, signe en SHA-1. On déploie devant lui un Envoy sidecar qui termine le mTLS moderne (TLS 1.3, certificats Let's Encrypt rotation 90 jours), réécrit les en-têtes AS2, et publie sur Kafka l'événement de réception via un filtre Lua. Walmart voit un endpoint moderne ; Sterling continue à parser ce qu'il reçoit. Autre cas : un sidecar Fluent Bit aspire les logs flat-file du connecteur OFTP2 et les pousse vers Elastic — le connecteur ne sait même pas qu'il est observé. Service Mesh (Istio, Linkerd) industrialise ce schéma à l'échelle d'un namespace entier.

Anti-patterns

  • Sidecar comme couteau suisse. Mettre dans un sidecar mTLS + logs + cache + business logic — il devient un autre monolithe couplé. Un sidecar = une responsabilité transverse.
  • Sidecar pour du code qu'on peut modifier. Si on contrôle le code applicatif, ajouter directement les bibliothèques OTEL/mTLS — pas la peine d'introduire un Pod doublé.
  • Couplage de cycle de vie ignoré. Le sidecar redémarre en boucle : le Pod entier redémarre, l'app aussi. Tester l'orchestration de démarrage (init containers, readiness probes).

Patterns liés

  • Ambassador — cas particulier : le sidecar proxy sortant.
  • Adapter — cas particulier : le sidecar qui normalise les logs ou métriques.
  • Service Mesh — l'industrialisation du sidecar à l'échelle cluster.
  • Smart Proxy — le cousin Hohpe, plus orienté ESB que cloud-native.

Sources