Wire Tap

Brancher un observateur sur un canal existant sans le modifier — comme un mouchard sur une ligne téléphonique, mais légal et documenté. Chaque message passe par deux destinations : le récepteur original et l'observateur. Indispensable pour alimenter lake, audit et KPI sans toucher au pipeline métier.

Problème

Une fois un pipeline EDI en production, on veut souvent y brancher des consommateurs « parasites » : un data lake pour l'analytique, un Message Store pour l'audit, un moniteur temps réel pour le dashboard. Mais on ne veut pas modifier le pipeline existant — chaque changement présente un risque sur la production. Et on ne veut pas que la panne d'un observateur affecte le flux métier. Il faut un moyen de greffer des observateurs en lecture seule, fire-and-forget.

Forces

Non-intrusivité. Le canal source ne sait pas qu'il est tapé ; ajouter ou retirer un tap ne change rien.
Isolement des pannes. La défaillance d'un observateur ne bloque pas le pipeline métier. Tap = fire-and-forget.
Coût de duplication. Chaque tap = une copie du payload. Pour les gros messages, combiner avec Claim Check.
Risques de fuite. Un tap mal protégé devient un canal d'exfiltration. Sécuriser au même niveau que le flux principal.
Conformité RGPD. Le tap déplace les données personnelles vers de nouveaux contextes. Anticiper le DPIA.

Solution

EIP §547 (Hohpe & Woolf, 2003) définit le Wire Tap comme un composant inséré dans un canal qui : (a) reçoit chaque message, (b) le transmet inchangé au récepteur initial, (c) en envoie une copie sur un canal d'observation. En pratique, sur un broker moderne : c'est un consumer-group supplémentaire sur un topic Kafka, ou un fan-out RabbitMQ exchange, ou un Service Bus topic subscriber. Le tap doit être fire-and-forget côté source — si l'observer tombe, le canal continue.

plaintext topology.txt

┌──────┐                ┌──────┐
   │  A   │ ───────────▶  │  B   │
   └──────┘                └──────┘
              │
              │ wire tap = T-junction
              ▼
        ┌──────────┐
        │ observer │ ──▶ lake / store / audit
        └──────────┘
        (read-only copy, no impact on A→B)

Implémentation EDI

Quatre usages canoniques du wire tap en EDI :

yaml tap-config.yaml

# Configuration d'un wire tap sur Kafka
tap:
  source_topic: edi.canonical.invoic.canonical
  observer_topics:
    - lake.invoic.raw           # ingestion data warehouse
    - audit.invoic.replay       # message store
    - kpi.invoic.live           # dashboard temps réel
  copy_mode: full               # ou: headers-only, sampled-1%
  pii_redaction: enabled        # masque IBAN, e-mail, téléphone
  fire_and_forget: true         # n'impacte pas le canal source si observer down
  consumer_group: tap-fanout

Alimentation lake analytique. Chaque INVOIC qui passe sur edi.canonical.invoic.canonical est copiée dans lake.invoic.raw, ingérée en BigQuery / Snowflake / Athena pour les KPI métier (top fournisseurs, saisonnalité, taux d'erreur).
Message Store. Le tap alimente le Message Store pour l'archivage légal, indépendamment du retraitement métier.
Compliance et audit. Pour les flux fiscaux CTC (Italie, France), un tap dédié envoie une copie chiffrée à un partenaire de scellement / horodatage qui produit la preuve cryptographique requise par l'administration.
Observability temps réel. Un tap échantillonné à 1 % alimente un dashboard de monitoring (latence, taille, taux d'erreur) sans noyer Grafana sous le volume complet.

RGPD et masquage

Tout tap qui dirige des données vers un nouveau contexte (lake, analytics, dashboard) doit : (a) être justifié par une base légale (intérêt légitime, exécution contractuelle, obligation légale), (b) appliquer une minimisation — masquer ce qui n'est pas nécessaire à l'usage. Un dashboard KPI n'a pas besoin de l'IBAN ; le lake analytique n'a pas besoin du nom complet de l'acheteur particulier. Pseudonymiser ou hasher au moment du tap.

Anti-patterns

Tap synchrone bloquant. Si le canal source attend l'ACK de l'observer, la panne de ce dernier bloque le flux métier. Toujours fire-and-forget.
Tap qui modifie. Un tap qui altère le message brise l'invariant : deux versions du message circulent. Garder strictement read-only.
Pas de redaction. Copier des IBAN ou des adresses personnelles dans un lake non-encrypted ouvre un risque RGPD majeur.
Tap caché. Un tap non documenté est un risque de fuite. Catalogue obligatoire (qui tape quoi, vers où, pour quel usage).
Tap exhaustif là où échantillon suffit. Pour la télémétrie, échantillonner à 1-10 % suffit ; ne pas copier 100 % du payload.

Patterns liés

Message Store — alimenté par tap.
Publish-Subscribe Channel — un tap est essentiellement un subscriber supplémentaire.
Message History — le tap inscrit aussi son passage dans l'historique pour la traçabilité.
Claim Check — éviter la duplication des gros payloads au moment du tap.

Sources

Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Wire Tap (§547). enterpriseintegrationpatterns.com — Wire Tap
RGPD — Règlement (UE) 2016/679. Article 5 (minimisation), article 25 (privacy by design). Tout tap doit respecter ces principes dès la conception.
Apache Camel — Wire Tap EIP. L'implémentation open-source la plus utilisée du pattern. camel.apache.org — Wire Tap
AWS Kinesis Data Firehose. Service cloud moderne qui implémente nativement le pattern pour alimenter lake et analytics depuis un flux. aws.amazon.com/kinesis/data-firehose

Fondamentaux

Standards

Messages phares

Outils