Agent IA en panne : reprendre le travail sans envoyer deux fois

L’agent a préparé une relance client, puis l’outil d’envoi a cessé de répondre. Le tableau de suivi indique « erreur ». Faut-il cliquer sur relancer ? Si le message est parti avant la coupure, le client le recevra une seconde fois. Si personne ne relance alors qu’il n’est pas parti, le dossier restera oublié. Le statut technique ne tranche pas toujours ce qui s’est passé chez le destinataire.

Après une panne d’agent IA, vérifiez d’abord les effets déjà produits dans les outils métier, puis ne reprenez que les opérations dont l’état est connu. Un effet incertain doit rester bloqué pour rapprochement ou décision humaine. Redémarrer l’agent ne suffit pas à savoir ce qu’il faut refaire.

Arrêter la mauvaise boucle avant de chercher la cause

Lorsqu’un incident touche un agent qui agit sur des outils, suspendez ses nouvelles actions sur le périmètre concerné. Le responsable d’exploitation peut laisser fonctionner la lecture ou la préparation de brouillons si elles sont indépendantes du défaut. En revanche, les envois, les créations de commandes ou les changements sensibles ne doivent pas se répéter pendant le diagnostic.

Cette suspension des actions doit aussi couvrir les autres déclencheurs. Un bouton manuel, une tâche planifiée et un événement CRM peuvent lancer le même traitement. Si le premier est arrêté mais que les deux autres continuent, l’équipe croit avoir gelé l’incident alors que les dossiers se multiplient encore.

Notez l’heure de l’arrêt, les dossiers potentiellement touchés et le responsable de la reprise. Informez les opérateurs du traitement de secours : par exemple, les demandes urgentes passent en file manuelle. Il faut éviter que chacun crée sa propre relance pour compenser le silence du système.

Qualifier le résultat métier, pas seulement le message d’erreur

Pour chaque opération concernée, recherchez l’état dans le système destinataire. Un email apparaît-il dans le dossier des messages envoyés avec un identifiant ? Le CRM contient-il déjà la note attendue ? La commande possède-t-elle une référence de création ? Les traces de l’agent aident à chercher, mais la confirmation de l’outil métier est généralement plus proche de l’effet à vérifier.

• Succès confirmé : la preuve correspond au bon dossier et au contenu attendu. Marquez l’opération comme terminée ; ne la rejouez pas.
• Échec confirmé sans effet : une réponse fiable ou un contrôle adapté établit que l’action n’a pas eu lieu. Elle peut être réessayée selon la procédure autorisée.
• Effet incertain : la requête a pu être reçue, mais aucune preuve suffisante n’est disponible. Conservez cet état et faites arbitrer la suite.

L’absence immédiate d’un élément à l’écran n’est pas toujours une preuve d’échec : certains outils synchronisent leurs données avec retard. Le contrôle doit tenir compte de leur fonctionnement. Si aucune recherche fiable n’est possible, dites-le au responsable métier au lieu de transformer l’incertitude en autorisation de renvoyer.

Reconnaître la même opération après un redémarrage

Un identifiant d’opération relie la demande initiale, l’action tentée et sa preuve. Il doit désigner le travail métier, pas seulement une exécution de l’agent. « Relance du devis X à l’échéance convenue » reste la même opération même si le processus redémarre. Une nouvelle échéance ou un nouveau contenu validé constitue une autre action à distinguer.

Le registre de suivi conserve cet identifiant avec le dossier, le type d’action, l’état, les tentatives et la référence du résultat. Il doit survivre à la fermeture de la conversation. Sinon, le nouvel agent n’a plus que la consigne « relancer les devis » et ne sait pas lesquels ont déjà reçu un message.

Certains outils acceptent une clé d’idempotence : réutiliser la même clé peut empêcher la création répétée d’une opération, selon les règles et la durée de conservation du fournisseur. Tous ne le permettent pas. Une recherche avant écriture et une limitation des traitements concurrents réduisent alors le risque, sans garantir à elles seules l’absence de doublons. Ne promettez pas une exécution « une seule fois » sans preuve adaptée à chaque connecteur.

Un scénario de reprise sur une relance de devis

Exemple fictif : un agent tente d’envoyer une relance approuvée. La connexion expire avant le retour de l’outil. L’opération reste « effet incertain », et le déclencheur automatique ne doit pas la renvoyer simplement parce que la tentative a expiré.

L’opérateur recherche le message dans l’outil d’envoi, avec le destinataire, le devis et la plage horaire. S’il trouve le bon contenu et son identifiant, il rattache cette preuve à l’opération puis clôt la tentative. Un message adressé au même client mais portant sur un autre devis ne suffit pas.

Si le fournisseur confirme le rejet avant prise en charge, l’équipe peut autoriser un nouvel essai. Si le service reste inaccessible et que l’échéance approche, le commercial décide d’une prise de contact manuelle adaptée. Cette décision et son résultat sont consignés pour que l’agent ne reprenne pas ensuite une relance devenue inutile.

La reprise se termine quand les dossiers sont rapprochés et les exceptions attribuées, pas quand le voyant repasse au vert. Le service peut être à nouveau disponible tout en laissant derrière lui une file de demandes dont personne ne connaît l’état.

Ce que la fiche d’incident doit permettre de décider

Une fiche utile rassemble le périmètre suspendu, les dernières actions confirmées, les effets incertains et le mode manuel disponible. Elle indique qui peut arrêter le système, qui enquête dans les outils et qui autorise la remise en service. Un développeur peut confirmer le rétablissement du connecteur ; le responsable métier doit encore vérifier que les dossiers prioritaires sont correctement repris.

Ajoutez les conditions de réouverture : cause comprise ou mesure de confinement en place, test représentatif réussi, ancienne file réconciliée et absence de second producteur actif. Redémarrez sur un périmètre limité avant de réactiver tous les déclencheurs, lorsque le service permet cette progression.

Pour comprendre pourquoi ces mécanismes doivent persister au-delà d’une conversation, l’article sur les workflows d’agents durables pose le cadre. La fiche d’incident le traduit en responsabilités et décisions au moment où l’équipe doit reprendre le travail.

Tester l’interruption avant qu’elle touche un client

Dans un environnement contrôlé, coupez la connexion après réception d’une action par l’outil de test, mais avant son accusé de réception. Vérifiez que l’agent conserve un état incertain et ne recrée pas l’action au redémarrage. Testez aussi un échec certain avant envoi, puis un succès confirmé : ces trois situations ne doivent pas suivre le même chemin.

Ne provoquez pas ces essais sur des paiements réels, des messages clients ou des suppressions en production. Utilisez des comptes et des données de test autorisés. La recette avant mise en production doit intégrer ces scénarios avec un résultat attendu, un observateur et un critère de blocage.

Demandez enfin une démonstration simple : après l’incident simulé, l’opérateur peut-il expliquer ce qui a été fait, ce qui ne l’a pas été et ce qui attend une décision ? Si la réponse exige de deviner, le dispositif de reprise n’est pas prêt pour des actions sensibles.