Quand un outil échoue : comment éviter qu’un agent répète une action

Le problème : une action peut avoir lieu sans que sa confirmation parvienne à l’agent

Un agent qui utilise des outils peut lancer une opération dans un autre système, puis perdre la connexion avant de recevoir une réponse claire. La tâche se trouve alors dans une situation ambiguë : l’agent ignore si le système cible a appliqué la modification, mais l’absence de confirmation ne prouve pas non plus que ce n’est pas le cas. Réexécuter la même action sans vérifier l’état peut créer un doublon ou aggraver les conséquences.

Ce problème est différent d’une nouvelle génération de réponse. Dans une conversation, une répétition peut produire un texte différent ; lorsqu’un outil modifie un enregistrement, réserve un rendez-vous ou change un fichier, la répétition peut créer un second effet externe. La procédure de récupération doit donc commencer par déterminer ce qui s’est passé, et non par répéter automatiquement l’instruction d’origine.

Ce guide propose une discipline opérationnelle, mais ne garantit pas que tous les systèmes permettent une récupération. La possibilité de vérifier, d’arrêter ou de compenser dépend des outils concernés et des fonctions qu’ils documentent. Si l’état cible n’est pas observable, l’agent doit considérer l’incertitude comme une raison de suspendre le processus ou de le faire remonter, et non comme une autorisation de faire une supposition.

Délimiter le flux avant de concevoir la récupération

Décrivez la tâche comme une suite d’étapes concrètes et indiquez les outils utilisés à chacune d’elles. Pour chaque étape, précisez si elle se limite à lire des informations, si elle écrit ou modifie un état, ou si elle peut produire un effet externe difficile à annuler. Cette classification permet de concentrer les contrôles sur les étapes où une répétition pourrait avoir des conséquences.

Il ne suffit pas de classer un outil en fonction de son nom. Une même intégration peut proposer une consultation et une opération d’écriture. Il ne suffit pas non plus de décrire l’intention générale de l’agent : « gérer un rendez-vous » peut comprendre la recherche de disponibilités, la création d’une réservation et l’envoi d’une notification. Chaque opération peut avoir un état différent et nécessiter une décision de récupération distincte.

Déterminez également quelle observation permet de considérer chaque étape comme achevée. Pour mettre à jour un enregistrement, il peut être nécessaire de le relire et de vérifier les champs concernés. Pour une réservation, il peut falloir consulter le système afin de voir si un rendez-vous correspondant aux données attendues existe. Pour une modification de code, on peut vérifier le contenu du fichier ou l’état de la modification. Ce sont des modèles de conception à adapter aux capacités réelles de chaque système.

Avant d’autoriser une écriture, définissez son périmètre : quelle entité l’agent peut modifier, quelles données il peut changer et quelles actions dépassent ses autorisations. Les permissions limitent les dommages potentiels, mais elles ne prouvent pas qu’une action précédente a réussi et ne rendent pas une répétition sûre. La sélection des outils doit préserver cette distinction entre autorisation et connaissance de l’état.

Classer l’état avant de prendre une décision

Après une défaillance, consignez la dernière observation fiable et classez l’étape interrompue. Une taxonomie pratique distingue quatre états : l’action n’a pas commencé ; le résultat est confirmé ; le résultat est incertain ; ou la tâche n’est que partiellement achevée. La classification doit s’appuyer sur les éléments disponibles, et non sur l’explication que l’agent préférerait donner.

« Non commencée » signifie qu’il existe suffisamment d’éléments pour conclure que l’étape n’a pas été envoyée ou n’a pas démarré. « Confirmée » signifie qu’une réponse ou une consultation ultérieure permet de vérifier le résultat attendu. « Incertaine » signifie qu’il manque des éléments pour déterminer si l’action a été exécutée. « Partielle » indique que certaines étapes ou certains effets sont achevés alors que d’autres restent en attente. En cas d’hésitation entre deux catégories, retenez la plus prudente et ne transformez pas l’incertitude en confirmation.

La distinction est importante, car la conduite à adopter change. Si l’étape n’a pas commencé, il peut être possible de la lancer, sous réserve des permissions et des règles du flux. Si elle est confirmée, il ne faut pas la répéter uniquement pour obtenir une réponse plus explicite. Si son état est incertain, consultez d’abord le système cible ; s’il n’existe pas de consultation fiable, arrêtez le processus ou faites-le remonter. Si le travail n’est que partiellement achevé, ne reprenez qu’à partir d’un état vérifié, en tenant compte des effets déjà produits.

Il ne faut pas confondre l’état de l’agent avec celui du système externe. Un point de contrôle peut enregistrer les étapes tentées par le flux ou les réponses reçues, mais ces informations peuvent devenir obsolètes si un autre processus modifie la cible ou si la confirmation s’est perdue. Le point de contrôle aide à retrouver le contexte ; à lui seul, il ne prouve pas quel est l’état actuel.

Avant de répéter, consultez la cible et recherchez les signes d’un doublon

La première question opérationnelle n’est pas « puis-je rappeler l’outil ? », mais « que puis-je observer maintenant dans le système concerné ? ». Si une consultation autorisée est possible, recherchez l’objet ou la modification liée à la tâche à l’aide des données qui permettent de l’identifier. Vérifiez la concordance des attributs pertinents et l’absence d’un résultat équivalent. Évitez de vous fier à un seul indice s’il ne permet pas de distinguer l’opération en cours d’autres opérations similaires.

Une requête peut comporter un identifiant d’opération ou une référence propre à la tâche. Si le système documente un moyen de consulter l’opération ou de reconnaître les requêtes en double, utilisez ce mécanisme conformément à sa documentation. Ne supposez pas que tous les outils acceptent une clé d’idempotence, qu’un identifiant empêche la répétition des effets, ou qu’un résultat portant le même texte correspond nécessairement à la même action.

La détection des doublons exige des critères explicites. Pour la mise à jour d’un enregistrement, comparez son identifiant et les champs que vous souhaitiez modifier. Pour un rendez-vous, vérifiez les données qui distinguent la réservation et son état actuel. Pour une modification de code, inspectez le fichier ou l’état de la modification avant d’appliquer un nouveau changement. Il s’agit d’exemples de vérification, et non de fonctions garanties d’un fournisseur donné.

Si la consultation de l’état n’est pas disponible, fournit des informations incomplètes ou ne permet pas de distinguer une opération antérieure, l’incertitude demeure. Dans ce cas, définissez une condition d’arrêt. L’absence de réponse vérifiable ne doit pas se transformer en supposition favorable, surtout lorsqu’une deuxième exécution pourrait créer un effet supplémentaire.

Choisir entre poursuivre, compenser, s’arrêter ou faire remonter le cas

Poursuivez lorsque l’état antérieur est suffisamment connu, que l’étape en attente relève du périmètre autorisé et que son résultat peut être vérifié. Reprendre signifie continuer à partir du dernier état vérifié, et non rejouer toute la séquence depuis le début. Si le flux comporte plusieurs étapes, identifiez celles qui sont confirmées et celles qui n’ont pas encore commencé afin de ne pas refaire un travail ayant déjà produit des effets.

Une compensation vise à corriger un effet confirmé au moyen d’une autre action. Elle n’est pas toujours possible et ne rétablit pas nécessairement la situation initiale à l’identique. Avant de la concevoir, vérifiez que le système documente cette opération, que le compte est autorisé à l’effectuer et que la modification ne touchera pas un état ultérieur. Si vous ne pouvez pas confirmer ces conditions, ne présentez pas la compensation comme une annulation garantie.

S’arrêter est une décision valable lorsque l’action suivante risque d’aggraver une situation incertaine, dépasse le périmètre autorisé ou ne peut pas être vérifiée de manière suffisante. Il est approprié de faire intervenir une personne lorsqu’il faut interpréter des éléments ambigus, approuver une action à fort impact, évaluer une compensation ou décider du traitement d’une modification qui ne peut pas être annulée sans risque. La suspension doit conserver le contexte minimal nécessaire à l’examen du cas.

Définissez à l’avance les conditions qui nécessitent une intervention humaine. Par exemple : état incertain d’une écriture sans moyen de consulter la cible ; opération dont les conséquences sont importantes et dont la répétition pourrait dupliquer un effet ; compensation non documentée ; permissions insuffisantes pour vérifier ; ou divergence entre l’état enregistré par le flux et le système cible. Ajustez ces seuils à l’impact et aux obligations de l’environnement au lieu d’appliquer une règle unique à toutes les actions.

Exemples pratiques : réservation et modification de code

Lorsqu’il réserve un rendez-vous, si l’agent perd la réponse après l’envoi de la demande, il reste possible qu’un rendez-vous existe déjà. L’agent doit consulter l’état de la réservation au moyen des capacités réellement disponibles et vérifier si le rendez-vous attendu apparaît. S’il trouve un résultat correspondant, il ne doit pas créer une autre réservation pour compenser l’absence de confirmation. S’il ne peut pas distinguer une opération déjà réalisée d’une opération toujours en attente, il doit interrompre la tentative automatique et demander un examen selon la politique du service.

La vérification doit aussi tenir compte du fait que l’état peut changer entre la consultation et l’action suivante. Le flux ne doit donc pas traiter une observation ancienne comme une garantie permanente. Si l’outil propose une référence d’opération ou une consultation d’état documentée, utilisez-la ; sinon, limitez vos conclusions à ce qui a réellement été observé. N’affirmez pas à l’utilisateur que le rendez-vous est confirmé si les éléments disponibles montrent seulement que l’agent a essayé de le demander.

Pour une modification de code, le risque ne se limite pas à répéter une écriture dans le même fichier. Son contenu peut avoir changé depuis le point de contrôle, ou une partie de la tâche peut avoir été appliquée tandis qu’une autre est restée en attente. Avant de le modifier à nouveau, inspectez son état actuel et comparez le changement prévu au résultat observable. Si la modification est déjà présente, évitez de la réappliquer à l’aveugle. Si l’état diverge ou ne peut pas être reconstitué, arrêtez le flux afin d’examiner ce qui doit être conservé et ce qui peut être corrigé.

Dans les trois exemples, l’agent doit décrire le résultat avec précision : tentative effectuée, effet vérifié, résultat incertain ou intervention requise. La description du processus ne doit pas présenter un appel d’outil comme une tâche achevée.

Conserver le contexte utile sans le confondre avec l’état actuel

Pour reprendre une tâche, il n’est pas nécessaire de conserver indistinctement toute la conversation. Enregistrez les informations opérationnelles qui permettent de reconnaître la tâche et de reconstituer les décisions : l’identifiant ou la référence de la tâche, s’il en existe un ; l’étape en cours ; l’outil et l’opération invoqués ; la dernière réponse observée ; l’état classé ; les vérifications effectuées et leur moment ; les effets confirmés ; et la raison de toute suspension ou remontée. Consignez également ce qui reste en attente et les limites d’autorisation applicables.

Évitez de conserver des données sensibles qui ne sont pas nécessaires à la récupération. Définissez qui peut consulter l’enregistrement, combien de temps il est conservé et comment il est supprimé ou protégé conformément aux règles de l’environnement. Il ne faut pas inventer une durée de conservation universelle : elle dépend des exigences applicables en matière de confidentialité, d’audit et d’exploitation. Si l’enregistrement contient des données personnelles ou des détails sur les systèmes, limitez sa portée et son accès.

La mémoire conversationnelle et le point de contrôle d’une tâche ont des fonctions différentes. La première peut aider à replacer la demande de l’utilisateur dans son contexte ; le second devrait représenter l’état opérationnel observé par le flux. Aucun des deux ne remplace une consultation du système cible lorsque la tâche dépend d’un effet externe susceptible d’avoir changé. Considérez la mémoire comme un indice pour orienter la récupération, et non comme une preuve suffisante que le monde extérieur n’a pas changé.

Ajoutez des horodatages ou l’ordre des observations lorsque ces éléments sont nécessaires à l’interprétation de l’enregistrement. Si une autre personne ou un autre processus peut modifier le système, une lecture antérieure peut être devenue obsolète. Lors de la reprise d’une opération sensible, vérifiez à nouveau les données pertinentes au lieu de supposer que le point de contrôle est toujours à jour.

Permissions et autonomie : limiter ce que l’étape de récupération peut faire

Concevez les permissions afin que chaque opération dispose du périmètre minimal nécessaire. Si l’agent a seulement besoin de vérifier un résultat, ne supposez pas qu’il doive pouvoir modifier d’autres enregistrements ou annuler des opérations. Si une compensation nécessite une permission différente, séparez-la de la consultation et définissez la condition qui en autorise l’usage. Cette organisation rend visible la différence entre observer, agir et corriger.

La récupération ne doit pas élargir l’autonomie au seul motif que le flux a échoué. Un agent autorisé à effectuer une première modification n’est pas automatiquement autorisé à exécuter des actions supplémentaires, à l’annuler ou à modifier des objets associés. Précisez quelles décisions peuvent être prises automatiquement, lesquelles nécessitent une approbation et quelles informations doivent être communiquées à la personne pour qu’elle puisse se prononcer.

L’approbation humaine doit porter sur une action précise et s’appuyer sur les éléments disponibles. Au lieu de demander une autorisation générale pour « résoudre le problème », expliquez quel état a été observé, ce qui n’a pas pu être confirmé, quelle action est proposée et quels effets elle pourrait avoir. Si des informations essentielles manquent, l’étape suivante consiste à les obtenir ou à s’arrêter, et non à demander une approbation qui masquerait l’incertitude.

Les permissions réduisent l’éventail des actions possibles ; elles ne résolvent pas à elles seules les défaillances partielles. Gardez distincts les garde-fous de périmètre, les mécanismes de consultation et les règles de récupération. Une conception fiable a besoin de ces trois éléments lorsque la tâche peut produire des modifications externes.

Tester des défaillances reproductibles avant le déploiement

Les tests doivent simuler non seulement des erreurs d’outil, mais aussi la dissociation entre l’exécution et sa confirmation. Un cas important est celui où le système cible applique une modification, mais où l’agent ne reçoit pas la réponse. Le test vérifie que le flux consulte la cible ou s’arrête, plutôt que de répéter automatiquement l’action. Si l’environnement de test ne permet pas de reproduire ce comportement, consignez cette limite et vérifiez au moins la politique applicable en cas d’incertitude au moyen de réponses ambiguës contrôlées.

Prévoyez également des confirmations tardives. Par exemple, l’agent peut suspendre le processus et commencer une vérification au moment où la réponse de l’opération initiale arrive enfin. Vérifiez que cette réponse tardive met à jour l’état de façon cohérente et ne déclenche pas une deuxième exécution. Testez aussi le cas inverse : la première opération n’a pas eu lieu et le flux dispose d’éléments suffisants pour lancer l’étape en attente conformément à ses règles.

Ajoutez des scénarios comprenant des doublons, un état partiel, l’indisponibilité de la consultation de la cible, des permissions insuffisantes et une compensation non documentée. Pour chacun, définissez le résultat attendu avant le test : quelles actions l’agent peut effectuer, lesquelles il doit éviter, ce qu’il doit enregistrer et à quel moment il doit faire remonter le cas. Un test qui vérifie uniquement que l’agent répond ne démontre pas que la récupération est sûre.

Utilisez des résultats vérifiables. Comptez les opérations d’écriture exécutées, vérifiez l’état final dans le système cible, repérez les doublons et examinez si des effets ont dépassé le périmètre autorisé. Évaluez séparément la tâche initiale et la récupération : le fait que l’utilisateur obtienne finalement un résultat ne suffit pas à démontrer que le flux a évité une répétition ou respecté ses limites.

Répétez les tests lorsque les outils, les permissions, la politique de reprise ou le format des points de contrôle changent. Consignez les versions et les conditions pertinentes afin de rendre les résultats reproductibles. Ne considérez pas la réussite d’un test comme une garantie contre toute défaillance future : elle démontre uniquement le comportement observé dans les scénarios définis.

Évaluer le flux et préparer le déploiement

Évaluez la récupération à l’aide de plusieurs indicateurs, et non d’une simple étiquette de réussite. Examinez le nombre de répétitions d’écritures, le nombre de résultats finaux vérifiés, le nombre de cas correctement arrêtés et le nombre d’actions ayant dépassé les permissions. Analysez également les remontées pour déterminer si elles contenaient assez de contexte et si elles ont été déclenchées dans les situations prévues.

Interprétez les indicateurs avec les cas de test et l’impact possible. Un faible taux de répétition ne prouve pas que le système est sûr si des tâches ambiguës n’ont pas été détectées. Un état final correct ne suffit pas non plus s’il a été obtenu au prix d’une action dupliquée ou d’une compensation non autorisée. Définissez à l’avance les résultats acceptables et les défaillances qui empêchent le déploiement.

Avant d’autoriser des actions à plus fort impact, mettez la procédure à l’essai au moyen d’opérations à faible risque ou dans un environnement de test approprié. Confirmez que les consultations d’état fonctionnent, que les permissions suffisent pour vérifier sans accorder un pouvoir d’action excessif, que les enregistrements permettent de reconstituer les événements et que les suspensions sont transmises à une personne en mesure de décider. Si une dépendance n’est pas disponible, réduisez le périmètre de l’automatisation au lieu de supposer que l’agent saura la résoudre.

Les sources disponibles comprennent de la documentation sur le dépannage des outils ainsi que des conseils généraux sur la gestion des incidents et la reprise après sinistre. À elles seules, elles n’établissent pas le comportement d’une intégration précise lorsqu’une réponse est perdue, ne disent pas si elle permet de détecter les doublons ni si une opération peut être annulée. Ces points doivent être vérifiés pour chaque système avant de transformer une recommandation de conception en consigne opérationnelle.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.