Récupération après incident pour les agents d’IA : reprendre, compenser ou s’arrêter

L’échec d’un appel n’est pas l’échec de la tâche

Un agent peut devoir consulter des informations, modifier un enregistrement, puis communiquer le résultat. Si la réponse d’un outil échoue au milieu de ce flux, il ne suffit pas de décider s’il faut répéter le dernier appel. Il se peut que l’action n’ait jamais atteint le système externe ; elle peut aussi avoir été exécutée alors que seule la confirmation s’est perdue ; ou encore, la modification peut n’avoir été appliquée qu’en partie. Chaque situation appelle une décision différente.

Dans ce guide, récupérer signifie rapprocher l’objectif et l’avancement consignés par l’agent de l’état vérifiable de l’environnement, puis choisir une reprise sûre ou un arrêt explicite. L’unité d’analyse est la tâche en plusieurs étapes, et non une requête isolée. Réessayer un appel peut faire partie de la récupération, mais ne la définit pas.

La recommandation centrale est simple : avant de répéter une action dont le résultat est inconnu, vérifiez ce qui s’est passé hors de l’agent. S’il n’existe aucun moyen fiable de le vérifier, ne transformez pas l’incertitude en une seconde modification. Limitez les actions qui en dépendent et confiez le cas à une personne lorsque le coût d’une erreur dépasse celui de l’attente.

Cartographier les incidents : commencez par classer ce que vous savez

Une erreur explicite ne prouve pas toujours que le système externe est resté intact. De même, un délai d’attente dépassé indique seulement que l’agent n’a pas reçu de réponse à temps ; il ne permet pas, à lui seul, de savoir si l’opération a été menée à terme. Classez donc l’incident en fonction des éléments disponibles, et non de l’étiquette d’erreur renvoyée à l’agent.

Distinguez cinq situations. Dans le cas d’un échec confirmé, la réponse permet de conclure que l’action n’a pas été exécutée. Dans le cas d’un résultat ambigu, la requête a peut-être été reçue, mais aucune confirmation fiable n’est disponible. Dans le cas d’une réponse invalide, une réponse existe, mais son format ou son contenu ne permet pas de l’utiliser en toute sécurité. Dans le cas d’un état externe inattendu, le système indique quelque chose qui ne correspond pas à l’hypothèse sur laquelle repose le plan. Enfin, lors d’une interruption entre deux étapes, la tâche s’est arrêtée après un ou plusieurs effets confirmés, mais avant la fin du flux.

Ces catégories orientent la vérification suivante ; elles ne déterminent pas automatiquement la réponse. Si l’échec est confirmé et que l’opération peut être répétée sans risque, une nouvelle tentative peut être raisonnable. Si le résultat est ambigu, cherchez d’abord des éléments dans le système concerné. Si la réponse est invalide ou si l’état observé contredit le plan, suspendez les actions qui en dépendent jusqu’à ce que l’écart soit clarifié.

Avant de poursuivre : conservez les éléments nécessaires pour reconstituer la tâche

Un checkpoint, ou point de contrôle, est utile s’il permet de reconstituer ce que l’agent cherchait à faire et ce qu’il sait de chaque étape. Il n’est pas nécessaire de conserver tout son raisonnement ni chaque donnée disponible. Il est préférable de garder le minimum d’informations opérationnelles : identifiant de la tâche, objectif, contraintes pertinentes, ordre des étapes, outil et opération demandés, paramètres nécessaires à l’identification de l’opération, résultat reçu, statut de confirmation et dernière observation de l’environnement.

Consignez chaque étape avec un statut explicite, par exemple : en attente, demandée, confirmée, échouée avec éléments à l’appui ou résultat inconnu. Évitez de résumer ces états dans une note unique telle que « action terminée », qui pourrait effacer la différence entre intention et confirmation. Si le système externe permet de consulter l’objet modifié, conservez la clé nécessaire pour le retrouver et indiquez la date de la dernière observation.

Le checkpoint ne prouve pas que le monde externe est resté inchangé. C’est un instantané de ce que le processus a sauvegardé ; entre l’interruption et la reprise, une personne ou un autre système peut avoir modifié l’enregistrement. Lors de la restauration, vérifiez de nouveau les conditions nécessaires avant d’effectuer d’autres changements. La documentation de Microsoft sur les checkpoints de workflows traite de leur stockage et de leur restauration ; pour une mise en œuvre donnée, l’équipe doit vérifier quel état est conservé et comment il est réhydraté.

La conception doit également préserver les limites de la tâche : quel résultat constitue une réussite, quelles opérations ne doivent pas être répétées et quelles conditions imposent une escalade. Sans ces limites, un agent peut reconstituer les étapes techniques tout en poursuivant dans une direction qui n’est plus sûre.

Arbre de décision : reprendre, vérifier, repenser, compenser ou s’arrêter

La décision peut être formulée sous la forme d’un processus court. Commencez par identifier la dernière étape confirmée et la première étape restée incertaine. Demandez-vous ensuite s’il existe une consultation fiable permettant de connaître l’état externe. Si oui, consultez le système avant d’agir. Sinon, évaluez l’impact potentiel d’une répétition et l’existence d’un moyen sûr de lever l’ambiguïté. Si aucune solution de ce type n’existe, arrêtez-vous et demandez l’intervention d’une personne.

Reprendre signifie continuer à partir d’un point connu sans réexécuter les étapes déjà confirmées. C’est approprié lorsque l’état enregistré suffit, que les conditions pertinentes sont toujours valides et que les étapes restantes sont sûres. Vérifier consiste à consulter l’environnement pour déterminer ce qui s’est passé, et non à renvoyer la même commande. Repenser signifie modifier le plan parce que l’état actuel ne satisfait plus ses hypothèses. Compenser consiste à effectuer une action différente pour contrebalancer un effet antérieur. S’arrêter signifie ne plus rien modifier jusqu’à l’obtention d’une décision ou d’éléments suffisants.

Le guide d’AWS consacré aux checkpoints des systèmes d’agents avertit qu’une reprise sans garanties d’idempotence peut dupliquer des effets ou corrompre des données. Cet avertissement souligne une distinction pratique : enregistrer l’état d’exécution aide à reconstituer le flux, mais ne rend pas automatiquement sûre la répétition d’une opération.

Effets partiels : annuler ne signifie pas toujours revenir à l’état précédent

Dans une tâche composée, certaines étapes peuvent être achevées avant l’échec de la suivante. Si l’agent met à jour un enregistrement puis ne peut pas envoyer une notification, répéter tout le flux risque d’appliquer à nouveau la modification, de créer des enregistrements en double ou d’envoyer plusieurs messages. La récupération doit partir des effets confirmés et déterminer séparément quoi faire pour chacun d’eux.

Lorsqu’une opération est réversible, définissez à l’avance ce que signifie son annulation et comment vérifier que celle-ci a bien eu lieu. Ne supposez pas que « annuler » efface toute trace ni que le système permet de revenir exactement à l’état précédent. Dans certains processus, la réponse appropriée est une action compensatoire : par exemple, corriger un enregistrement au moyen d’une nouvelle opération plutôt que supprimer l’opération historique. Cette compensation peut elle aussi échouer et nécessite donc ses propres confirmations et limites.

Le modèle de saga, présenté par AWS pour les flux en plusieurs étapes, distingue la récupération vers l’avant — poursuivre ou réessayer — de la récupération vers l’arrière au moyen de transactions compensatoires. C’est une référence utile pour structurer des processus distribués, mais elle n’implique pas que tout effet d’un agent puisse être compensé de manière disponible ou sûre. Le choix dépend des règles du système et de l’impact de l’action.

Si une action ne peut pas être annulée de façon fiable, l’agent doit la traiter comme une limite de risque. Il peut consigner l’effet, empêcher que des étapes supplémentaires ne l’aggravent et demander une vérification. Il ne doit pas improviser une compensation qui n’a pas été définie pour ce cas.

Limites et escalade : quand arrêter l’agent

Une politique de récupération a besoin de conditions d’arrêt explicites. Parmi les signaux pratiques : impossibilité de consulter l’état permettant de savoir si une action a eu lieu ; changements incompatibles avec le plan ; réponses invalides répétées ; accumulation de tentatives sans progrès confirmé ; dépassement de l’impact ou du périmètre autorisé ; ou absence de compensation fiable pour un effet indésirable. Ce sont des critères de conception proposés, et non des garanties de sécurité automatiques.

Définissez aussi qui reçoit le dossier, de quelles informations cette personne a besoin et quelles actions elle peut autoriser. Une escalade utile devrait inclure l’objectif de la tâche, les étapes confirmées, le point incertain, les vérifications réalisées, les effets externes observés et l’option que l’agent aurait choisie. Évitez de présenter comme un fait une cause qui n’a pas pu être déterminée.

S’arrêter ne signifie pas nécessairement abandonner la tâche sans explication. L’agent peut préserver le checkpoint, signaler que la tâche est bloquée et expliquer clairement ce qui reste à vérifier. Si l’interface propose une action de reprise, celle-ci doit vérifier de nouveau les conditions pertinentes, et non supposer que l’environnement est resté dans le même état.

Testez la récupération au moyen d’interruptions contrôlées

Il ne suffit pas de tester le parcours normal ni de vérifier que le processus peut restaurer un checkpoint. Simulez des interruptions à différents moments : avant l’envoi d’une opération, après son envoi mais avant la réception d’une réponse, après la confirmation d’un effet mais avant l’étape suivante, et après l’observation d’un changement inattendu. Ajoutez des réponses tardives, invalides ou répétées si elles peuvent se produire dans l’environnement évalué.

Pour chaque scénario, définissez à l’avance le comportement attendu : ce qui doit être conservé, quelle consultation doit être effectuée, dans quelles conditions la reprise est sûre et quelle condition impose une escalade. Comparez ensuite le résultat réel à ce critère. L’évaluation doit couvrir aussi bien les erreurs dues à un excès d’initiative — par exemple, un doublon — que celles dues à un excès de prudence — par exemple, une tâche arrêtée alors qu’elle pouvait reprendre sans risque.

Pour le suivi, envisagez de mesurer la proportion de tâches achevées correctement, les effets dupliqués, les états incohérents, les tâches bloquées, le temps nécessaire pour lever une ambiguïté et la proportion d’escalades appropriées. Interprétez les indicateurs en tenant compte de la gravité de chaque cas : un faible taux de doublons ne prouve pas qu’une opération irréversible est sûre.

Servez-vous des résultats pour ajuster les checkpoints, les consultations de vérification, les limites de tentatives et les conditions d’arrêt. Distinguez les défaillances de l’agent, de l’outil et du système externe lorsque les éléments disponibles le permettent ; dans le cas contraire, consignez la cause comme indéterminée au lieu de forcer une attribution.

Ce que ce guide ne couvre pas

Ce guide porte sur la récupération d’une tâche d’agent qui traverse plusieurs étapes et peut modifier des systèmes externes. Il ne remplace ni la conception des nouvelles tentatives d’une API, ni les garanties d’idempotence d’une requête donnée, ni la reprise après une défaillance d’infrastructure. Ces sujets restent importants : un protocole de tâche peut s’appuyer sur eux, mais ne peut pas déduire leurs garanties si elles ne sont pas documentées.

Dans ce contexte, l’idempotence désigne une propriété à vérifier pour l’opération précise avant de supposer qu’il est sûr de la répéter ; il ne suffit pas de qualifier toute la tâche d’idempotente. De même, un checkpoint permet de conserver et de restaurer des informations sur le workflow, mais ne confirme pas à lui seul que le système externe a appliqué une modification. La thèse sur une architecture multi-agent tolérante aux pannes constitue un précédent d’une autre portée : elle porte sur le contrôle d’un robot mobile et ne fournit pas une recette directement applicable aux agents connectés à des services d’entreprise.

Pour finir, posez-vous ces questions dans cet ordre : qu’est-ce qui est confirmé ? Que peut-on vérifier hors de l’agent ? Quels effets se sont déjà produits ? Quelles étapes restent valables ? Existe-t-il une compensation sûre ? Quelle condition impose l’arrêt ? Si une réponse essentielle est inconnue et qu’agir risque d’aggraver la situation, préservez l’état, arrêtez-vous et faites remonter le cas.

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.