PORTLANE
← Ressources

Glossaire

Dead letter queue et Enterprise Integration Patterns : le vocabulaire qui évite de paniquer à 2 h

Écrit par le fondateur de Portlane · 18 juillet 2026 · 9 min de lecture

La dead letter queue¹, c'est l'endroit où votre SI avoue qu'un message a cassé, pour pouvoir le comprendre, puis le rejouer.

Un message échoue trois fois. Puis il disparaît des écrans « happy path ». Si personne ne sait où il est allé, vous n'avez pas d'intégration robuste, vous avez de l'espoir.

Une dead letter queue¹ (DLQ, file de lettres mortes) est une file d'attente⁴ où aboutissent les messages qui n'ont pas pu être traités après les tentatives prévues. On les met de côté pour ne pas bloquer le trafic sain, les analyser, corriger, puis éventuellement les rejouer.

La DLQ¹ se relie aux Enterprise Integration Patterns³ (EIP), le vocabulaire classique de l'intégration d'entreprise. Ce qui compte pour une ETI¹⁰ en exploitation. Portlane n'implémente pas « tous les patterns » ; il en assume quelques-uns volontairement.

Définition utile : la DLQ

  • Rôle : isoler les messages en échec définitif (ou quasi) du chemin nominal.
  • Contenu utile : payload, métadonnées, motif d'erreur, horodatage, nombre de tentatives.
  • Suite logique : analyse, correction (code, mapping, cible), puis rejeu contrôlé.

Sans DLQ¹, les échecs se mélangent aux succès dans les logs, ou pire : ils disparaissent. Avec une DLQ mal tenue, vous avez une décharge. L'outil ne remplace pas la discipline.

Ce que la DLQ n'est pas

  • Pas une poubelle à ignorer. Si personne ne la regarde, c'est une perte de données différée.
  • Pas un substitut aux retries. Les retries⁶ gèrent le transitoire (réseau, 503). La DLQ¹ gère ce qui reste après.
  • Pas la supervision complète. Elle dit « ce message a échoué ». Elle ne remplace pas la santé des moteurs ni le journal d'événements.

Enterprise Integration Patterns : de quoi on parle

Les EIP³ (Gregor Hohpe & Bobby Woolf) cataloguent des solutions récurrentes : comment découpler des systèmes, router un message, le transformer, gérer les erreurs. Ce n'est pas un produit. C'est un dictionnaire d'architecture, encore cité parce que les problèmes n'ont pas changé de nom.

Quelques patterns utiles dès qu'on parle DLQ¹ et runtime :

  • Message Channel / Queue : le message attend dans une file ; producteur et consommateur ne se parlent pas en direct.
  • Pipes and Filters⁸ : le traitement est une chaîne d'étapes (recevoir → orienter → transformer → livrer).
  • Content-Based Router : on oriente selon le contenu du message.
  • Dead Letter Channel² : le canal (souvent une file) pour les messages impossibles à traiter. La DLQ¹ en est l'implémentation courante.
  • Idempotent Receiver : la cible (ou le runtime) tolère un rejeu⁵ sans double effet catastrophique.
  • Retry⁶ : nouvelle tentative sur erreur transitoire, avant d'abandonner vers la dead letter channel².

Vous n'avez pas besoin d'afficher le livre sur le bureau. Vous avez besoin que votre plateforme ne réinvente pas ces idées sous un jargon éditeur opaque.

DLQ et EIP, dans une exploitation réelle

  • Le chemin nominal utilise des files entre étapes (découplage).
  • Le retry⁶ absorbe le bruit réseau.
  • La dead letter channel² / DLQ¹ recueille ce qui reste.
  • Le rejeu⁵ referme la boucle après correction.
  • L'idempotence⁷ évite que le rejeu⁵ crée deux commandes.

C'est une chaîne. Couper un maillon ramène à l'astreinte improvisée.

Où se place Portlane

Portlane assume un Pipes and Filters⁸ simple, des files d'attente⁴ fiables, une gestion d'échec visible et un rejeu⁵ côté supervision, donc une dead letter channel² dans l'esprit, pas un catalogue EIP³ complet.

  • Oui : chemin linéaire, files, échecs inspectables, logique Python versionnée.
  • Non : prétendre couvrir les dizaines de patterns du livre, ni un ESB⁹ de médiation universelle.

Portlane est encore en développement actif. Cet article fixe un vocabulaire d'exploitation. Pour le débat bus central : qu'est-ce qu'un ESB et l'ESB est trop vieux.

Checklist demi-journée

  • Où vont les messages après N échecs aujourd'hui ?
  • Peut-on lire payload + erreur sans l'expert plateforme ?
  • Y a-t-il une alerte quand la DLQ¹ grossit ?
  • Le chemin de rejeu⁵ est-il documenté, ou oral ?

Pour aller plus loin

La DLQ¹ et les EIP³ ne sont pas du jargon pour architectes. C'est le minimum pour que « ça a planté » redevienne une phrase actionnable.

Questions fréquentes

Une dead letter queue est-elle obligatoire ?

Pas au sens juridique. En revanche, sans endroit où poser les messages qui ont définitivement échoué, vous mélangez le trafic sain et le poison. L'exploitation devient du tri dans les logs.

DLQ et rejeu, c'est la même chose ?

Non. La DLQ¹ isole et conserve l'échec. Le rejeu⁵ est l'acte de retraiter ensuite. L'une sans l'autre : soit vous stockez sans agir, soit vous rejouez sans savoir ce qui a cassé. Voir le rejeu de flux.

Les Enterprise Integration Patterns, c'est encore d'actualité ?

Oui. Les EIP³ (Hohpe & Woolf) nomment des problèmes qui n'ont pas disparu : découplage, routage, erreurs, idempotence. Les outils changent ; les patterns restent un vocabulaire utile.

Portlane implémente-t-il tous les EIP ?

Non, et ce n'est pas l'objectif. Portlane vise un chemin étroit (recevoir, orienter, transformer, livrer) avec files d'attente⁴ et gestion d'échec exploitable, sans catalogue académique de patterns. En développement actif.

Faut-il une DLQ par flux ou une DLQ globale ?

En pratique, une isolation par flux (ou par domaine) évite qu'un poison d'un flux mineur noie le diagnostic d'un flux critique. Une DLQ fourre-tout devient vite une décharge.

Glossaire

  • ¹ Dead letter queue (DLQ) : file où aboutissent les messages en échec définitif, pour analyse et rejeu.
  • ² Dead Letter Channel : nom EIP du canal réservé aux messages impossibles à traiter.
  • ³ Enterprise Integration Patterns (EIP) : catalogue de patterns d'intégration d'entreprise (Hohpe & Woolf).
  • ⁴ File d'attente : stockage temporaire des messages entre producteur et consommateur.
  • ⁵ Rejeu : retraitement contrôlé d'un message déjà reçu.
  • ⁶ Retry : nouvelle tentative sur erreur transitoire.
  • ⁷ Idempotence : rejouer sans créer d'effet de bord indésirable.
  • ⁸ Pipes and Filters : traitement en chaîne d'étapes successives.
  • ⁹ ESB : bus de services d'entreprise.
  • ¹⁰ ETI : entreprise de taille intermédiaire en France.

Voir l'approche Portlane sur les flux

Files fiables, échecs visibles, rejeu. Python chez vous. Positionnement produit, développement actif.