Un agent rédige un rapport, crée un fichier, puis envoie un message. C’est alors que le processus s’interrompt. Au redémarrage, la conversation indique : « J’envoie maintenant le résultat. » Le message est-il parti ? Faut-il recréer le fichier ? Un historique de conversation fluide ne répond pas à ces questions.
Le 19 octobre 2026, Vercel a publié durable-harness. Le projet enregistre les étapes et les résultats d’un agent afin que le travail puisse être repris, et traite les outils interrompus différemment selon leur propriété de rejeu. Cette publication est l’occasion de réfléchir plus attentivement à l’état du travail. L’exemple de cet article est notre propre modèle, et non un test que nous aurions mené sur le projet.
Intention, appel et résultat sont trois choses différentes
Une intention décrit ce qui est censé se produire ensuite. Un appel lancé montre que le travail a commencé. Seul un résultat enregistré documente ce que votre propre processus en sait. Si l’on confond ces niveaux, un redémarrage peut facilement produire du travail en double ou sauter quelque chose qui n’a jamais été terminé.
Pour le rapport, l’entrée « Export terminé » ne suffit donc pas. Elle doit faire référence aux données d’entrée utilisées et au fichier réellement créé. Si le document source change, un export antérieur peut encore exister sans être pour autant le bon résultat. La réutilisation commence par une attribution claire.
Step: export-17
Input: bericht-v3
State: completed
Result: bericht-v3.pdf
Next step: notificationIl s’agit d’une fiche de contrôle lisible, et non d’un format d’API. Elle montre la différence essentielle entre un nom de fichier mentionné dans une conversation et un résultat traçable d’une étape précise. Dans un processus réel, le fichier correspondant devrait exister de manière vérifiable.
Un redémarrage sûr connaît les états incertains
Prenons trois moments auxquels le processus pourrait s’interrompre. Avant l’export, il n’existe encore aucun résultat. Après l’export mais avant le message, le fichier peut être réutilisé. Pendant l’envoi du message, la situation est plus délicate : le destinataire l’a peut-être déjà reçu alors que la confirmation manque dans votre propre journal.
L’état local « aucune confirmation enregistrée » ne prouve donc pas « non envoyé ». Répéter aveuglément l’étape pourrait transformer l’incertitude en message en double. Un processus raisonnable marque cette étape comme incertaine et vérifie auprès du service externe, à condition que celui-ci propose une requête de statut adaptée.
C’est précisément là que les actions diffèrent. Relire un fichier existant ne change normalement rien pour le destinataire. Un nouveau message, une nouvelle commande ou un nouveau paiement peut en revanche déclencher un nouvel effet. Un journal durable ne résout pas ces différences à la place du système externe.
L’idempotence est une propriété de l’opération
Une opération répétable doit être identifiable de telle sorte que la même requête ne crée pas accidentellement une nouvelle tâche. Si un service prend en charge une clé prévue à cet effet, la même opération logique doit conserver la même clé. Une clé générée à nouveau à chaque redémarrage perdrait précisément ce lien.
Que cela fonctionne de manière fiable, et comment, dépend du contrat de service réel. Un framework d’agents ne peut pas rendre une action répétable sans risque simplement en lui donnant une étiquette rassurante. Et « exactement une fois » n’est pas non plus une conséquence gratuite du stockage durable des journaux.
Un petit test d’interruption en dit plus qu’une exécution réussie
Dans votre propre environnement de développement, un exercice inoffensif s’impose : remplacez d’abord l’étape d’envoi par un journal local, interrompez le processus aux trois moments mentionnés et observez quels états existent au redémarrage. Notez à l’avance quelles étapes peuvent être répétées et lesquelles nécessitent une vérification. N’utilisez pas de vrais paiements ni de vrais messages pour cette première investigation.
L’enseignement ne réside pas dans un taux de réussite inventé. Il réside dans la capacité à nommer les frontières d’état de votre propre processus. Durable-harness constitue une approche technique concrète à cet égard. Un bon redémarrage commence cependant toujours par la même question : qu’est-ce qui s’est produit de manière démontrable, et où ne savons-nous pas encore ?
Sources et état
Recherche et documentation à la date du 25 octobre 2026. Rendre chaque harness durable.
