Comment vérifier qu’un agent IA a vraiment terminé une tâche

Vous avez demandé à Claude Code, Codex ou à un autre agent de classer des fichiers, de modifier un tableur ou de créer des enregistrements métier. L’agent répond « terminé » et aucune erreur évidente n’apparaît. Cela prouve que l’exécution s’est arrêtée proprement, pas que le résultat métier a été enregistré.

Une acceptation fiable commence par l’état final attendu. Relisez ensuite les données dans les systèmes de destination et contrôlez les effets manquants comme les effets inattendus. Si le résultat reste inconnu, interrogez les registres avant de rejouer tout le flux.

Pourquoi un appel réussi ne prouve pas la fin de la tâche

Plusieurs signaux peuvent rassurer : l’outil renvoie success, le processus sort avec le code 0, un rapport est produit ou le dernier message affirme que tout est fait. Ils ne répondent pourtant pas aux questions essentielles :

• le bon fichier existe-t-il au bon endroit avec le bon contenu ;
• toutes les lignes ou tous les enregistrements ont-ils été persistés ;
• des doublons, commandes, notifications ou fichiers supplémentaires ont-ils été créés ;
• un job asynchrone est-il encore en attente ou l’écriture a-t-elle été annulée ensuite ;
• l’agent a-t-il seulement lu une donnée sans effectuer la mise à jour requise ?

Le ThinkingBox-Bench v1.0 public de Microsoft est un benchmark synthétique, pas un taux d’incident en production. Il regroupe 507 tâches exécutables dans cinq domaines et n’accepte une tentative que si les contrôles de l’état final, des effets de bord et des propriétés de dialogue prévues réussissent. La documentation de la version ne donne aucun crédit partiel. Les états « partiel » et « non vérifié » ci-dessous sont des catégories opérationnelles, pas des notes du benchmark.

Définissez un contrat d’acceptation avant l’exécution

La vérification est plus simple lorsque les conditions finales sont écrites à l’avance :

Élément	À définir	Exemple
État obligatoire	Objets, champs, volumes et relations attendus	120 fichiers renommés, 120 ID uniques dans le tableur
État interdit	Modifications et effets qui ne doivent pas se produire	Ne pas supprimer les sources, ne pas envoyer un second courriel, ne pas modifier les autres onglets
Source de vérité	Système dont l’état stocké décide l’acceptation	Dossier cible, cellules réelles, CRM ou statut du ticket
Identité de reprise	Clé qui identifie cette opération précise	Un operation_id ou numéro de commande rattaché à la tâche/opération actuelle ; l’ID client, le nom de fichier, l’ID d’objet et le hash du manifeste identifient les objets interrogés, pas cette opération à eux seuls

Décrivez le résultat métier, pas l’activité de l’agent. « L’outil de tableur a été appelé » n’est pas un état final. « L’onglet contient 120 lignes, des ID uniques et des totaux réconciliés » en est un.

Définissez également l’ordre des opérations irréversibles. Effectuez et contrôlez d’abord les modifications récupérables ; envoyez ensuite le courriel, la commande ou le paiement. Une panne précoce ne doit pas imposer de rejouer aveuglément l’étape sensible aux doublons.

Conservez les preuves minimales d’exécution

Gardez les éléments permettant de relier une exécution à ses écritures :

• la demande initiale, la portée autorisée et l’état attendu ;
• les heures de début et de fin, le répertoire de travail et le manifeste des cibles ;
• l’ID de session de l’agent et tout job ID retourné ;
• un operation_id ou une autre clé métier unique ;
• les volumes, versions, champs clés ou hashes avant exécution ;
• les erreurs, timeouts, refus d’autorisation et étapes omises.

Le raisonnement privé du modèle n’est pas nécessaire. Il faut des entrées reproductibles, des identifiants, une portée et l’état de destination. N’inscrivez jamais de clé API, de token ou de secret client dans ce journal.

Attendez l’état final du système, pas le dernier message

Les imports, rapports et écritures externes peuvent continuer après la réponse. Enregistrez le job ID et interrogez le système de référence à intervalles raisonnables jusqu’à un succès, un échec, une annulation ou un timeout défini.

Notez la progression et la dernière mise à jour. Si le système est éventuellement cohérent, prévoyez une fenêtre de stabilisation puis relisez. Ne concluez pas à l’échec parce qu’une écriture récente n’est pas encore visible, mais n’attendez pas sans limite. Sans preuve décisive à l’expiration, l’état est non vérifié, pas « non exécuté ».

Relisez le résultat en six niveaux

1. Confirmez que l’objet existe et appartient à cette exécution

Contrôlez chemin, nom, ID, heure de modification et version. Un ancien fichier du même nom n’est pas une preuve. Un nouvel enregistrement rattaché au mauvais client ne convient pas davantage.

2. Contrôlez le contenu et les invariants métier

Vérifiez volumes, unicité, totaux, champs requis, relations et format. Pour un tableur : ID, lignes et sommes. Pour des fichiers : manifeste, taille, hash ou échantillon. Pour un enregistrement : statut, montant, propriétaire et période.

3. Utilisez le système de référence

Le résumé de l’agent, le terminal et le cache sont des indices. L’acceptation vient du système qui stocke le résultat : service de fichiers, cellules, CRM, tickets, base ou registre de paiement.

4. Vérifiez tous les effets obligatoires

Une tâche peut nécessiter un fichier, une mise à jour d’index, un enregistrement associé et une notification. Contrôlez chaque élément avec la même identité métier. Un effet obligatoire absent signifie une réalisation partielle.

5. Cherchez ce qui ne devait pas exister

Recherchez lignes et enregistrements en double, courriels supplémentaires, fichiers supprimés, modifications hors périmètre et écritures sur le mauvais objet. Un effet inattendu doit interrompre la reprise automatique.

6. Réconciliez les systèmes

Si la tâche traverse fichiers, feuilles et applications, limitez d’abord chaque requête à l’operation_id ou au périmètre de la tâche actuelle, puis vérifiez les ID client et objet, l’état ou la version requis et le manifeste. La correspondance d’un identifiant d’objet ne prouve pas que cette opération a été appliquée. Comparez les ensembles d’ID et listez les éléments manquants et supplémentaires.

Classez le résultat en quatre états

État	Quand l’utiliser	Action suivante
Terminé	Toutes les conditions sont vérifiées et aucun effet supplémentaire inacceptable n’existe	Conserver les preuves et fermer
Partiel	Une partie est confirmée mais des éléments précis manquent	Réparer uniquement les manques
Non vérifié	Système inaccessible, en cours de stabilisation ou preuve insuffisante	Interroger ou attendre, sans rejouer à l’aveugle
Effet inattendu	Doublon, suppression, changement hors périmètre ou mauvais objet	Arrêter l’automatisation et faire contrôler

« Non vérifié » ne veut pas dire « échoué ». Cela veut dire que le résultat n’est pas encore connu.

Décidez la reprise dans cet ordre

1. Interrogez d’abord cette opération. Limitez la recherche dans la source de vérité avec l’operation_id ou le numéro de commande, puis combinez le nom de fichier, l’ID client ou objet et l’état ou la version requis. Trouver l’objet seul ne prouve pas cette écriture.
2. Trouvez la frontière déjà réalisée. Listez les objets corrects et manquants.
3. Réparez de façon idempotente. Si la même clé ne peut pas créer un second résultat, envoyez seulement les manques. Sinon, ne rejouez pas automatiquement une action irréversible.
4. Séparez enregistrements, notifications et transactions. Si l’enregistrement existe mais pas le courriel, renvoyez uniquement le courriel. Si le courriel est parti et l’enregistrement incertain, interrogez d’abord.
5. Arrêtez-vous devant un effet inattendu. Corrigez ou annulez l’objet erroné avant toute reprise.

Règle courte : rejouez seulement après avoir confirmé l’absence ; après une écriture partielle, complétez uniquement les manques ; si le résultat est inconnu, interrogez ; si l’état est erroné, arrêtez.

Exemple : fichiers, tableur et CRM

Cet exemple est hypothétique ; ce n’est ni un incident client ni un journal de production reproduit.

L’agent doit renommer 120 fichiers, écrire 120 lignes, créer 12 synthèses dans un CRM puis envoyer un courriel. La relecture montre des fichiers et des lignes corrects, seulement 9 enregistrements CRM et un courriel déjà envoyé.

L’état est partiel. La reprise sûre consiste à :

• interroger le CRM avec l’operation_id et les 12 clés attendues ;
• identifier les 9 existants et créer seulement les 3 manquants avec des clés de déduplication ;
• réconcilier les 12 ID finaux avec les synthèses de fichiers et de tableur ;
• ne pas renommer à nouveau, ne pas réécrire 120 lignes et ne pas renvoyer le courriel.

Si le CRM ne peut pas être interrogé, classez le résultat non vérifié. Une reprise complète pourrait créer des doublons et une seconde notification.

Copiez ce registre d’acceptation

Champ	Contenu à enregistrer
Tâche et portée	Action, destinations autorisées et changements interdits
État final attendu	Objets, champs, volumes, relations et statuts
Identité d’exécution	Session, job ID, operation_id et clés métier
Preuve de référence	Objets de destination, heure de requête, ID et liens
Effets manquants	Objets ou actions obligatoires absents
Effets supplémentaires	Doublons, suppressions, changements hors périmètre, notifications en trop
État d’acceptation	Terminé, partiel, non vérifié ou effet inattendu
Suite	Fermer, attendre, réparer, rejouer, annuler ou transférer à une personne

Joignez listes d’ID, différences et heures de requête. « Vérifié » sans données ne suffit pas.

BetterToken fournit la connexion au modèle, pas l’acceptation métier

Pour connecter Claude Code via BetterToken, suivez le guide actuel de configuration et de vérification. Une réponse normale sans erreur de connexion ou de modèle confirme la configuration ; elle ne prouve pas que le fichier, le tableur ou l’enregistrement externe a atteint l’état attendu.

Les identifiants de session aident à retrouver l’exécution, mais l’acceptation repose sur les systèmes de destination. Disponibilité du modèle, réponse réussie ou consommation de tokens ne prouvent pas la fin du travail métier.

Fermez seulement après trois questions

1. L’état final attendu apparaît-il dans le système de référence, et pas seulement dans la description de l’agent ?
2. Les manques, doublons et autres effets inattendus ont-ils été contrôlés ?
3. Si le résultat est inconnu, sera-t-il recherché par clé unique avant toute réparation ou reprise ?

Fermez uniquement lorsque les trois réponses sont claires. Avant la prochaine exécution à fort impact, copiez le registre, renseignez l’état final, les interdits et l’identité de reprise. Cette préparation coûte moins cher que la correction d’une opération dupliquée.