Pourquoi les agents d’IA ont besoin de preuves avant de réessayer

Comment éviter qu’une réponse perdue n’entraîne une action en double

Un agent d’assistance autorisé à effectuer un seul remboursement envoie la demande, mais perd la connexion. Il ne reçoit aucune confirmation de réussite et tente d’envoyer à nouveau la demande de remboursement. Si la demande initiale a abouti, cette nouvelle tentative peut entraîner un deuxième remboursement.

Il s’agit d’un cas purement hypothétique. Cet exemple illustre un problème que la seule précision du modèle ne permet pas de résoudre. Quelles mesures un agent doit-il prendre s’il ne peut pas déterminer si son action précédente a modifié l’état de l’environnement ?

Unite.AI a étudié la fiabilité des agents au-delà des modèles. Les problèmes de reprise méritent leurs propres règles dans ces discussions. Avant de tenter une deuxième fois une action lourde de conséquences, un agent doit confirmer ce qui s’est passé ou disposer d’une garantie valide contre les effets en double.

L’absence de réponse ne permet pas de conclure à un échec

L’absence de réponse ne permet pas d’établir qu’une action a échoué. Elle n’indique pas si une erreur s’est produite avant l’exécution, si l’action a été menée à bien sans accusé de réception ou si le processus est toujours en cours.

Il s’agit d’un problème courant dans les systèmes distribués, comme l’explique Amazon. Amazon explique pourquoi les mécanismes de nouvelle tentative doivent comporter des protections spécifiques contre la répétition d’effets secondaires. Les agents ajoutent une nouvelle entité décisionnelle au processus de reprise de votre système. Ils peuvent prendre d’autres décisions sur la manière de remédier aux erreurs.

Ces décisions peuvent modifier le fonctionnement de l’entreprise. Par exemple, réessayer un remboursement pour un montant différent ne constitue pas simplement une nouvelle tentative de la même demande. De même, choisir un autre prestataire de paiement lorsque le premier a cessé de répondre ne revient pas simplement à réitérer la même demande.

Les équipes doivent distinguer l’autorisation d’exécuter une action de l’autorisation de remédier à une issue incertaine. L’approbation initiale ne signifie pas que l’exécution de l’action une nouvelle fois est sans risque.

Des recherches récentes mesurent le risque

Un préprint de septembre 2026, intitulé « Where Does Exactly-Once Live? », a présenté le banc d’essai LIMBO et évalué 25 930 épisodes sur neuf modèles. Les services simulés ont été testés dans des situations d’accusés de réception perdus, de traitement retardé et de livraisons en double.

Sur les 1 279 épisodes où un effet en double a été généré lors du test principal des auteurs, les agents ont indiqué avoir terminé avec succès dans 90 % des cas. Un agent peut donc signaler une réussite alors même qu’un traitement incorrect a eu lieu.

Ces résultats reposent sur des bancs d’essai contrôlés et ne permettent pas d’estimer les taux de défaillance en production. Les services étaient simulés et plusieurs analyses étaient exploratoires. Les équipes devraient évaluer les résultats des actions des agents séparément de leurs déclarations de réussite.

L’article explique également pourquoi la vérification de l’état actuel peut ne pas suffire. Une demande encore en cours de traitement peut prendre effet après la vérification. Même une réponse indiquant un statut vide ne signifie pas que la demande ne finira pas par prendre effet.

Les tentatives répétées doivent correspondre à la même intention

Un service destinataire peut reconnaître les tentatives répétées d’une même opération au moyen d’une clé d’idempotence. Si cette méthode est correctement prise en charge, elle garantit que les tentatives répétées ne produisent pas d’effets supplémentaires. La clé d’idempotence doit rester la même à chaque nouvelle tentative.

La documentation de l’API de Stripe présente des exemples des mécanismes et des limites des clés d’idempotence. Pour l’API v1, les clés peuvent être supprimées après au moins 24 heures. La réutilisation d’une clé supprimée entraîne une nouvelle demande. Stripe vérifie également que les paramètres fournis par le demandeur correspondent à ceux de la demande initiale.

En pratique, l’idempotence doit être mise en œuvre dans votre couche d’intégration, et pas seulement dans une consigne. Avant de déclencher une opération, consignez l’opération approuvée. Enregistrez son identifiant, les paramètres exacts, la référence du prestataire, le cas échéant, ainsi que le statut de l’opération.

Pour un remboursement, enregistrez le lien entre l’approbation et la transaction d’origine, ainsi que tous les identifiants de remboursement renvoyés par le prestataire. Rechercher un remboursement du même montant constitue une preuve moins convaincante, car deux demandes légitimes peuvent porter sur le même montant. Un délai peut également s’écouler entre une demande de remboursement et son apparition dans les résultats de recherche. La demande initiale peut encore être en cours de traitement.

Lorsqu’un agent ou un processus de travail redémarre, la couche d’exécution doit conserver cette identité. Elle doit rejeter toute demande modifiée présentée comme la même opération. Une telle modification constitue une nouvelle action qui, selon les règles du flux de travail, nécessite une nouvelle décision d’approbation.

Les descriptions des outils ne suffisent pas

En plus des descriptions des outils, vérifiez le contrat du service destinataire concernant la prise en charge de l’idempotence. Testez sa mise en œuvre pour confirmer quelles garanties sont effectivement respectées.

Considérez l’incertitude comme un état opérationnel

Figure 1. Processus de reprise proposé pour les actions lourdes de conséquences. Toute nouvelle tentative nécessite également une autorisation à jour.

Une fois l’achèvement confirmé, le processus consigne le résultat et se poursuit sans répéter l’action. Une non-exécution confirmée ne permet une nouvelle tentative que si aucune demande initiale n’est encore en attente et que l’autorisation est toujours en vigueur.

Un résultat non résolu soulève bien d’autres questions. Si le fournisseur offre une garantie valide contre les effets en double, vous pouvez autoriser une nouvelle tentative de la demande initiale avec la même clé. Sinon, suspendez toute écriture et faites le point au moyen d’une requête d’état, auprès du fournisseur ou avec l’aide d’un opérateur autorisé. Une vérification non concluante ne suffit pas à justifier une nouvelle tentative.

Il peut également être justifié de suspendre le processus lorsque le fournisseur documente les délais de traitement et de visibilité. En l’absence de tels délais, le simple écoulement du temps ne permet pas de confirmer que l’action n’a pas été exécutée. Vous devez définir qui prend en charge les cas non résolus et à quel moment ces personnes doivent les examiner.

Remédier à une défaillance peut nécessiter un autre processus métier

Si un remboursement aboutit, mais que la notification envoyée ensuite au client échoue, relancer l’ensemble du processus risque de déclencher un nouveau remboursement. Le rétablissement devrait viser à achever l’étape inachevée tout en conservant la trace du travail déjà effectué.

Si des mesures correctives s’imposent pour des actions déjà réalisées, Microsoft fournit des indications sur les transactions compensatoires. Chaque application détermine la manière appropriée de corriger les erreurs. Une compensation ne rétablit pas nécessairement la situation initiale, et la compensation elle-même peut échouer.

De plus, l’annulation d’une transaction peut entraîner des frais. Corriger un message ne permet pas de garantir que personne n’a vu une version antérieure. Par conséquent, toute opération de rétablissement doit définir explicitement les limites de ce que l’agent peut annuler, modifier ou s’engager à faire. Les décisions qui dépassent ces limites doivent être transmises à une personne disposant de l’autorité nécessaire.

Testez la deuxième tentative avant le déploiement

Choisissez un outil pouvant avoir des conséquences importantes et effectuez des tests de rétablissement ciblés dans un environnement de test. Après une exécution réussie, supprimez la réponse à la demande initiale. Différez l’exécution de la première demande jusqu’à la vérification de son état. Pendant le rétablissement, redémarrez le processus de travail. Attendez que la durée de conservation de la clé expire avant de réessayer. Modifiez un paramètre lors de tentatives répétées.

Évaluez les enregistrements métier obtenus au lieu de vous fier uniquement aux réponses des outils. Consignez les effets en double, les opérations non résolues, le travail non effectué, le temps nécessaire au rétablissement et les interventions manuelles supplémentaires. Calculez le coût par tâche correctement achevée à partir du coût total du processus, y compris les annulations de transactions et les mesures de réparation destinées aux clients.

Testez également une véritable deuxième demande semblable à la demande initiale. Assurez-vous que votre système évite les doublons sans empêcher l’exécution de nouvelles tâches. Évaluez séparément la prévention des doublons et l’achèvement des tâches. Sinon, un agent qui met fin à toutes les tâches pourrait sembler sûr tout en ne produisant que peu ou pas de valeur.

La question d’évaluation doit être formulée clairement. Le système a-t-il été en mesure d’expliquer :

• Quelle opération était autorisée ?
• Quels éléments permettaient d’établir le résultat de cette opération ?
• Pourquoi était-il permis de réessayer ?

Lorsqu’un agent suspend son activité en raison d’une incertitude non résolue, il peut sembler moins efficace dans les démonstrations. Toutefois, en production, cette suspension peut préserver l’intention initiale du client. Une persistance utile signifie que le système achève les tâches autorisées sans les exécuter silencieusement en double.