Éviter les actions en double lors des nouvelles tentatives d’un agent IA

Votre agent a demandé la création d’un ticket, puis l’appel a expiré : faut-il recommencer ? Vultr décrit les appels d’outils dans les parcours IA ; ce guide s’intéresse à leur reprise lorsque le résultat d’une action n’est pas encore connu.

1. Repérer les opérations qui modifient un état

Listez les outils accessibles à votre agent et distinguez la consultation des actions : créer un ticket, envoyer une notification ou enregistrer une demande. Pour chaque action, identifiez le système qui conserve le résultat et le moyen de le retrouver.

Un délai dépassé indique que votre application n’a pas reçu de résultat à temps. Il ne suffit pas à établir que l’action n’a jamais été réalisée. Prévoyez donc trois états de suivi : succès confirmé, échec confirmé et résultat inconnu.

Définissez ce qui représente une même intention utilisateur. Deux nouvelles tentatives de création du même ticket doivent être reliées, alors que deux tickets volontairement distincts ne doivent pas être fusionnés. Cette distinction appartient à la logique de votre application, pas à une appréciation improvisée du modèle.

2. Prévoir une reprise contrôlée

Vérifiez si le service appelé propose une clé d’idempotence ou un mécanisme équivalent. Suivez sa documentation pour la portée de la clé, sa durée de conservation et le traitement d’une requête répétée. Ne supposez pas qu’ajouter un en-tête arbitraire active cette protection.

Lorsque ce mécanisme existe, conservez la même clé pour les tentatives d’une même action. Votre application doit la gérer durablement et la relier au résultat. Une nouvelle clé à chaque essai annulerait l’intérêt de ce rapprochement.

Voici une fiche de suivi possible :

Si le service n’offre pas cette garantie, prévoyez une recherche fiable de l’action existante avant toute reprise. Un registre local aide au suivi mais ne suffit pas, à lui seul, à empêcher deux créations concurrentes à distance. En cas d’incertitude persistante, suspendez la reprise et demandez une vérification.

3. Tester la réponse perdue

Utilisez un environnement de test sans destinataires réels. Faites réussir une action simulée, puis perdez volontairement sa réponse côté application. Relancez le parcours et observez si l’agent retrouve le résultat ou crée un doublon.

Testez également deux tentatives concurrentes et une reprise après redémarrage de l’application. Vérifiez le nombre d’objets réellement créés dans le système cible, pas seulement le message final de l’agent. Contrôlez que les deux actions volontairement différentes restent possibles.

Documentez les cas qui nécessitent une intervention humaine. Le résultat attendu est une action unique pour une intention unique, avec un état honnête lorsqu’elle reste incertaine. Réutilisez ce scénario lorsque vous changez un outil, sa politique de nouvelle tentative ou la façon de stocker les identifiants.

Sources : Vultr

Sur les réseaux sociaux

Retrouvez-le dans nos publications

Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.

• Voir sur Facebook
• Voir sur Instagram