Quand l'appel direct ne suffit plus

Relier deux systèmes par un appel direct fonctionne tant que les deux répondent. Le jour où le destinataire est indisponible — maintenance, saturation, coupure réseau — l'appel échoue, et la question devient : que fait-on du message ? Le perdre n'est pas acceptable, le réessayer en boucle non plus, et le stocker quelque part revient à réinventer une file d'attente.

C'est le rôle d'un intermédiaire de messages. L'émetteur dépose et poursuit son travail ; le destinataire consomme à son rythme, et rattrape son retard quand il revient. Les deux systèmes cessent de dépendre de la disponibilité l'un de l'autre.

Fonctionnalités principales

• Publication/consommation d’événements (SO, facture, stock, livraison).
• Routage par clés (routing keys) et échanges topic.
• Dead Letter Queues, re-tentatives et parkings d’erreurs.
• Traçabilité : corrélation, idempotence, horodatage.
• Scalabilité horizontale des workers.

Données échangées (exemples)

• Messages JSON : en-têtes (correlation_id, retry), payload (document Odoo minimal).
• Événements de statut (créé, confirmé, expédié, facturé, annulé).

Questions fréquentes

Faut-il cela pour deux systèmes seulement ?

Rarement. Un appel direct avec quelques tentatives suffit quand le volume est modeste et les deux côtés fiables. L'intermédiaire se justifie quand plusieurs consommateurs écoutent le même événement, quand les débits sont irréguliers, ou quand une interruption ne doit rien faire perdre.

À quoi sert une file d'erreurs ?

À isoler ce qui ne passe pas. Un message qui échoue systématiquement — donnée invalide, référence inconnue — finit dans une file à part au lieu de bloquer les suivants. Quelqu'un l'examine, corrige la cause, et le rejoue.

Comment éviter les doublons ?

En rendant le traitement rejouable : un même message traité deux fois doit produire le même résultat qu'une seule. C'est une propriété à construire dans le consommateur, pas une garantie du transport, et c'est le point que les intégrations improvisées oublient.