Rejouer un flux en échec : playbook ops en six gestes

Un flux est en erreur. L'astreinte ouvre la console. La question n'est pas seulement « est-ce qu'il y a un bouton retry ». C'est : le message est-il encore là, et rejouer va-t-il créer un doublon chez la cible ?

Ce playbook suppose que vous avez déjà lu rejeu de flux : définition et dead letter queue. Ici : comment faire, pas pourquoi le mot existe.

Geste 1 : geler le bruit

• Noter heure, flux, environnement, identifiant message ou batch si visible.
• Vérifier si un retry automatique est en cours (ne pas empiler les relances).
• Alerter le propriétaire métier si 🔴 critique (moins de 24 h), pas après trois heures d'essais aveugles.

Geste 2 : lire l'erreur (vraiment)

• Étape fautive : entrée, transformation, livraison ?
• Transitoire (timeout, 503) ou donnée invalide (schéma, référence manquante) ?
• La cible a-t-elle partiellement accepté le message ?

Si l'erreur est « donnée invalide », rejouer sans corriger la source reproduit l'échec.

Geste 3 : vérifier l'idempotence

Avant tout rejeu¹ : la cible peut-elle recevoir le même événement deux fois sans dommage ? Si non : retrouver l'état côté cible (création partielle, idempotency key⁵) ou rejouer seulement la partie manquante.

Geste 4 : choisir le périmètre de rejeu

• Message unique : un enregistrement en DLQ² ou en échec isolé.
• Depuis l'étape N : le runtime conserve l'état intermédiaire.
• Recharge complète : dernier recours ; risque de double écriture⁴ plus élevé.

Documentez le choix dans le ticket incident. L'audit compte autant que le succès.

Geste 5 : rejouer et observer

• Rejeu¹ depuis la console, CLI ou supervision : une action tracée, pas un copier-coller Postman non loggé.
• Surveiller logs cible + volumes sortants pendant 15 à 30 min.
• Confirmer avec le métier sur un échantillon si données sensibles (commandes, paiements).

Geste 6 : clôturer et mettre à jour le runbook

• Cause racine en une phrase.
• Action corrective : fix code, fix donnée source, fenêtre maintenance.
• Si le geste a été improvisé : écrire la procédure pour le prochain astreinte.
• Rejouer les autres messages de la même cause après le fix, pas avant.

Checklist rapide (à coller dans le runbook)

• ☐ Message / batch identifié et toujours disponible
• ☐ Cause comprise (transitoire vs donnée)
• ☐ Idempotence³ vérifiée côté cible
• ☐ Périmètre de rejeu¹ choisi et tracé
• ☐ Métier informé si critique
• ☐ Post-mortem léger si 🔴 ou récidive

Limites des consoles iPaaS / ESB

Certaines plateformes offrent « resubmit » sans historique clair. Si vous ne voyez pas l'étape fautive, vous n'avez pas un rejeu¹, vous avez un pari. C'est un critère d'achat : voir critères d'acceptation runtime.

Portlane vise rejeu¹ depuis supervision avec message persisté. Produit en développement, pas doc opérationnelle livrée.

Pour aller plus loin

• Définition : rejeu de flux d'intégration
• Isoler les échecs : dead letter queue et patterns
• Choisir un runtime : critères d'acceptation
• Architecture : l'ESB est trop vieux

Questions fréquentes

Rejouer depuis le début ou depuis l'étape en échec ?

Depuis l'étape en échec quand le runtime le permet, sinon vous risquez une double écriture⁴ chez la cible. Si vous ne savez pas quelle étape a cassé, le problème est observabilité, pas procédure de rejeu¹.

Qui peut déclencher un rejeu en prod ?

Définissez-le à l'avance : ops de garde, intégration, ou les deux selon criticité. Un rejeu¹ sans rôle nommé devient soit « personne n'ose », soit « tout le monde clique ».

Faut-il rejouer toute la DLQ d'un coup ?

Rarement. Triez par cause (donnée invalide vs panne transitoire). Rejouer en masse sans tri reproduit la même erreur cent fois. Voir dead letter queue pour isoler avant de rejouer.

Comment Portlane gère le rejeu ?

Positionnement : message persisté, état visible, action depuis la supervision. Produit en développement. Cette page est un playbook générique, pas une doc d'exploitation Portlane.

Le rejeu compense-t-il l'absence de tests ?

Non. Le rejeu¹ sauve l'incident ; les tests évitent le prochain. Les deux sont nécessaires.

Glossaire

• ¹ Rejeu (replay) : reprendre le traitement d'un message déjà reçu après échec.
• ² DLQ (dead letter queue) : file des messages en échec définitif, en attente d'analyse.
• ³ Idempotence : opération rejouable sans effet de bord indésirable.
• ⁴ Double écriture : création ou mise à jour dupliquée chez la cible après un rejeu mal cadré.
• ⁵ Idempotency key : identifiant permettant à la cible de dédupliquer les requêtes.
• ⁶ Runbook : procédure d'exploitation pour incidents.
• ⁷ iPaaS : plateforme d'intégration cloud en abonnement.
• ⁸ ESB : bus de services d'entreprise.