Agent de support en production : Temporal, saga et circuit breaker protègent les remboursements des pannes

Un client écrit : « Mon colis n'est pas arrivé, remboursez-moi. » L'agent capable de répondre s'écrit en une soirée : une boucle, trois outils, et tout marche en démo. Puis le processus redémarre au milieu d'un remboursement, le fournisseur du modèle tombe pendant une demi-heure, et le client clique deux fois sur « envoyer ». On découvre alors que l'agent n'est qu'une petite partie du système. La dernière partie de la série sur Habr assemble ce système pas à pas, et sa grande valeur est que chaque composant apparaît en réponse à une panne précise.

D'un fichier unique à l'API, au worker et à Temporal

La version initiale garde l'historique de la conversation dans la mémoire du processus. Un redémarrage efface toutes les conversations, les clients sont servis un par un, et si le processus plante entre l'appel à refund_payment et la réponse, personne ne sait si l'argent a été rendu ou non.

Première étape : séparer le script en une API et un worker. L'API reçoit le message, l'écrit en base et répond aussitôt au chat. Elle n'appelle pas le modèle, donc répond en quelques millisecondes. La boucle de l'agent vit dans des workers distincts, que l'on peut ajouter selon la charge. L'historique est désormais en base et survit aux redémarrages.

Mais un worker peut quand même tomber en plein milieu d'une demande. Rejouer le remboursement est dangereux : on peut payer deux fois. Ne pas le rejouer l'est aussi : on peut ne pas payer du tout. C'est là qu'intervient Temporal : il consigne chaque étape dans un journal, et un autre worker reprend au même endroit sans réexécuter les étapes déjà terminées. La boucle de l'agent vit dans un workflow, tandis que les appels au modèle et aux outils deviennent des activities.

Deux précisions importantes. Temporal possède sa propre base, et l'on n'y stocke pas les données métier des clients : le journal d'une exécution est limité à 51 200 événements ou 50 Mo. Les workers exécutant votre code, c'est vous qui les lancez ; le service Temporal ne les exécute pas. Quant au Workflow ID, c'est vous qui le définissez : prenez l'id de la conversation, et un renvoi ne créera pas de doublon. Seulement, ne mettez pas de données personnelles dans l'ID, il est visible dans l'interface et les logs.

Le retry n'est pas un circuit breaker

Quand le fournisseur du modèle est en panne pendant une demi-heure, Temporal relance honnêtement l'activity. Cent workers et mille demandes ouvertes martèlent à l'unisson l'API tombée, et quand elle revient, toute la file s'abat sur elle.

Le retry est conçu pour une panne qui passe en quelques secondes. Pour une défaillance longue, il faut un circuit breaker. Il compte les échecs, s'ouvre après un seuil et renvoie immédiatement une erreur sans solliciter le service, puis laisse passer un appel d'essai au bout d'un moment. L'état du disjoncteur doit être partagé par tous les workers, sinon chacun redécouvrira à son tour que le fournisseur est tombé. Sa place est donc dans la passerelle LLM, entre les workers et les fournisseurs. LiteLLM, par exemple, retire un modèle de la rotation après une série d'échecs, bascule sur un modèle de secours et stocke l'état dans Redis.

Conseil pratique de l'auteur : faites en sorte que l'activity distingue deux types d'erreurs. Les erreurs temporaires sont rejouées par la politique de Temporal. L'erreur « disjoncteur ouvert » ne doit pas être retentée : c'est le workflow qui décide de basculer sur un modèle de secours, d'attendre ou de transmettre la demande à un opérateur. Les mêmes disjoncteurs se placent devant le service de livraison et le système de paiement.

Saga, opérateur et routeur

Un remboursement touche trois systèmes sans transaction commune : l'étiquette chez le service de livraison, l'argent chez le prestataire de paiement, la notification au client et la mise à jour de la commande. C'est une saga : chaque étape a sa compensation. Le concept clé est le point de non-retour (pivot transaction). Avant le remboursement, les étapes peuvent être annulées ; après, l'e-mail au client et la mise à jour de la commande doivent être menés à terme, quel que soit le nombre de retries nécessaires. Chaque action reçoit une clé d'idempotence, par exemple l'id de la décision, et le prestataire de paiement ne débitera pas l'argent une seconde fois.

Le modèle ne doit pas valider seul les grosses sommes. Le workflow affiche la décision dans la console de l'opérateur et attend un signal. L'attente est inscrite dans le journal et n'occupe pas de worker, si bien que l'opérateur peut répondre une heure plus tard.

La dernière étape concerne le coût. Toutes les demandes ne nécessitent pas une boucle d'agent complète. Un routeur basé sur un petit modèle envoie la FAQ vers un appel unique, la question « où est ma commande » vers une chaîne prédéfinie, et seul un remboursement litigieux arrive à l'agent. Le principe est simple : prendre le niveau de complexité le plus bas qui résout la tâche de façon fiable.

Que faire de tout cela

Inutile de construire tout le schéma d'emblée. L'auteur conseille explicitement d'ajouter un composant quand apparaît la douleur qu'il soigne. Si vous avez un seul client à la fois et pas d'argent en jeu, une base de données suffit. Dès qu'apparaissent des effets de bord comme les paiements, il faut de l'idempotence et du durable execution. Dès qu'apparaît une dépendance à un fournisseur externe, il faut un disjoncteur partagé.

Il y a aussi des limites. Le code de l'article est du pseudocode. L'affirmation selon laquelle l'agent web Codex tourne sur Temporal vient du fournisseur lui-même, et l'auteur n'a pas trouvé de confirmation indépendante. Mais comme carte des défaillances typiques d'un système agentique, le texte est utile à quiconque met un agent en production. Commencez par vous demander ce qui se passe si le processus tombe après l'appel le plus risqué.