Rejeu de flux : ce que c'est, ce que les plateformes promettent, et ce que Portlane vise

Un flux plante. L'ops ouvre la console, lit un message d'erreur, et quelqu'un dit « on relance ». Ce geste anodin décide si vous exploitez une plateforme, ou si vous bricolez sous pression.

Le rejeu¹ (replay), en intégration, consiste à reprendre le traitement d'un message ou d'un événement déjà reçu, après un échec ou une correction, sans dépendre du hasard ni d'une copie Excel sauvée « au cas où ». Ce n'est pas un bouton magique : c'est une propriété du runtime (conservation du message, état visible, action contrôlée).

Définition, approches courantes (retry silencieux, logs seuls, console éditeur), et où Portlane se place. Produit encore en développement : thèse d'exploitation, pas brochure de disponibilité.

Définition utile, pas marketing

Un rejeu¹ digne de ce nom suppose trois choses :

• Persistance : le message n'a pas disparu quand le worker est tombé.
• Observabilité : on sait quel flux, quelle étape, quelle erreur.
• Action : on peut renvoyer le traitement, en entier ou depuis l'étape fautive, avec une trace.

Sans ces trois, vous avez un espoir de retry⁶, pas un rejeu¹.

Ce que le rejeu n'est pas

• Pas un simple cron qui « rappelle » la source. Utile parfois, mais ce n'est pas rejouer le même événement déjà capturé.
• Pas coller le JSON dans Postman à la main. Ça sauve un incident. Ça ne scale pas, et ça ne s'audite pas.
• Pas la dead letter queue seule. La DLQ³ isole l'échec ; le rejeu¹ est l'acte de le retraiter. Les deux vont ensemble : voir dead letter queue et patterns d'intégration.

Comment le marché le traite (en pratique)

• Retry automatique : la plateforme réessaie N fois. Bien pour les blips réseau. Insuffisant si la donnée est invalide ou la cible en maintenance longue.
• Console d'erreurs iPaaS⁴ : on voit l'échec, parfois on « resubmit ». Qualité très variable selon l'éditeur ; la logique reste dans le format propriétaire.
• Jobs studio (Talend et cousins) : souvent relance du job, pas rejeu message-par-message. Le diagnostic dépend de l'expert qui lit le studio.
• Scripts maison : tout est possible, rien n'est garanti, sauf si quelqu'un a posé une vraie file d'attente².

Le point commun des mauvaises surprises : le message vivait en mémoire ou dans un log illisible. Quand la machine tombe, l'histoire tombe avec.

Ce que Portlane vise

Portlane part d'un chemin simple (recevoir, orienter, transformer, livrer) avec des files d'attente² fiables entre les étapes. Le rejeu¹ n'est pas un accessoire marketing : c'est la conséquence de ne pas perdre le message.

• Persistance : le message attend ; une panne ne l'efface pas.
• Supervision⁷ : santé, événements, ce qui a échoué, lisible hors boîte noire.
• Rejeu depuis l'ops : action sur un échec connu, pas improvisation Postman.
• Logique en Python : corriger la transformation, rejouer, sans dépendre du seul expert studio.

Portlane vs « les autres » n'est pas « on a un bouton de plus ». C'est que le rejeu¹ est un effet du modèle (files + code + supervision), pas un plugin collé après coup. Encore en développement actif.

Rejeu, côte à côte

• Retry opaque Marché : souvent N tentatives puis abandon. Portlane : retries possibles, mais l'échec reste inspectable et rejouable.
• Conservation du message Marché : variable (mémoire, log, store éditeur). Portlane : file d'attente² comme source de vérité du transit.
• Qui peut rejouer Marché : souvent l'expert plateforme. Portlane : ops / intégrateur sur une supervision claire (objectif produit).
• Après correction du code Marché : parfois reconfigurer le recipe. Portlane : corriger le Python, redéployer, rejouer le message.

Comment trancher chez vous

• Prenez le dernier incident réel. Le message était-il encore là ?
• Combien de temps pour comprendre l'étape fautive sans l'expert introuvable ?
• Le « rejeu » a-t-il risqué une double écriture chez la cible ?
• Si trois réponses sont floues : vous n'avez pas un rejeu¹, vous avez une tradition orale.

Pour aller plus loin

• Isoler les échecs : dead letter queue et patterns
• Le modèle de chemin : l'ESB est trop vieux
• Le récit produit : pourquoi nous construisons Portlane

Le rejeu¹ n'est pas un détail d'architecture. C'est souvent la différence entre une nuit d'astreinte improvisée et une exploitation qui tient.

Questions fréquentes

Rejeu et relance manuelle, c'est la même chose ?

Non. Une relance manuelle, c'est souvent « on relance le job et on espère ». Un rejeu¹ digne de ce nom repart d'un message ou d'un événement conservé, avec traçabilité : quoi, quand, pourquoi ça a échoué, et ce qui a été renvoyé.

Faut-il tout rejouer depuis le début du flux ?

Rarement. L'idéal : rejouer à partir de l'étape qui a cassé, sans réécrire deux fois chez la cible si le message avait déjà été livré. Ça suppose idempotence⁵ côté cible ou un garde-fou côté runtime.

Les iPaaS gèrent-ils tous le rejeu ?

À des degrés très variables. Certains offrent des retries automatiques, d'autres une console d'erreurs, d'autres presque rien hors logs. Le mot « rejeu » dans une slide ne dit pas si le message a survécu à la panne.

Comment Portlane aborde le rejeu ?

Messages en file d'attente² fiable, état visible, rejeu depuis la supervision⁷. Le message n'est pas censé disparaître en mémoire. Produit encore en développement actif : positionnement, pas promesse de bascule lundi matin.

Le rejeu remplace-t-il les tests ?

Non. Le rejeu¹ sauve l'exploitation. Les tests (et une logique relisible) évitent de rejouer la même erreur tous les mardis. Les deux se complètent.

Glossaire

• ¹ Rejeu (replay) : reprendre le traitement d'un message ou événement déjà reçu, après échec ou correction.
• ² File d'attente : mécanisme qui stocke les messages en attendant leur traitement.
• ³ Dead letter queue (DLQ) : file où aboutissent les messages qui ont définitivement échoué, pour analyse et rejeu contrôlé.
• ⁴ iPaaS : plateforme cloud d'intégration fournie en service, en général sous abonnement.
• ⁵ Idempotence : propriété d'une opération qui peut être rejouée sans effet de bord indésirable (ex. double création).
• ⁶ Retry : nouvelle tentative automatique après un échec transitoire.
• ⁷ Supervision : vue sur la santé des moteurs, des flux et des événements d'échec.