Un agent IA a « terminé » : comment vérifier qu'il a vraiment fait le travail ?

Un agent IA qui affiche « terminé » ne vous dit qu'une chose : il a cessé de travailler. Pas que la tâche est réussie. C'est la confusion la plus coûteuse des projets IA en entreprise, parce qu'elle est invisible : le tableau de bord est vert, les logs sont propres, et pourtant le résultat est faux, incomplet ou inutilisable. Voici comment séparer « terminé » de « réussi », et ce que cela change concrètement dans la façon de concevoir et de recetter un agent.

Pourquoi « terminé » n'est pas « réussi »

Un agent est un programme qui boucle : il observe un état, choisit une action, l'exécute, puis décide s'il continue ou s'arrête. Le signal d'arrêt est produit par le modèle lui-même, souvent via un appel d'outil du type « finish » ou une réponse finale en langage naturel. Autrement dit, l'agent s'auto-déclare terminé.

Trois causes fréquentes de faux positifs :

• Arrêt prématuré : le modèle juge la tâche accomplie alors qu'il n'a traité que la moitié des éléments.
• Confusion entre action et résultat : l'agent a bien appelé l'API d'envoi, mais l'API a renvoyé une erreur qu'il n'a pas interprétée.
• Plausibilité confondue avec exactitude : la réponse finale est bien rédigée, structurée, convaincante — et fausse.

Un agent qui « termine » est un agent qui a décidé de s'arrêter. La vérification consiste à ne jamais croire cette décision sur parole.

Le principe : séparer l'exécution de la validation

La règle de base, simple et robuste : ne jamais laisser l'agent être juge de son propre travail. La validation doit être externe, déterministe quand c'est possible, et indépendante du modèle qui a produit le résultat.

Concrètement, cela veut dire que votre système comporte deux couches distinctes :

• une couche d'exécution (l'agent, avec ses outils) ;
• une couche de contrôle qui reçoit la sortie brute et vérifie des critères objectifs avant de considérer la tâche comme réussie.

Si l'agent produit un fichier, la couche de contrôle vérifie que le fichier existe, qu'il contient le bon nombre de lignes et que les colonnes attendues sont présentes. Si l'agent doit envoyer un courriel de confirmation, la couche de contrôle vérifie l'accusé de réception de l'API, pas le texte de l'agent. Si l'agent doit créer une fiche client, elle vérifie que l'identifiant existe réellement en base.

Des critères de réussite vérifiables, définis avant l'agent

Avant d'écrire une ligne de code, listez ce qui rend la tâche « réussie » aux yeux du métier. Pas « l'agent a répondu » mais « le devis contient un prix, une date de validité et les coordonnées du client, et le total correspond à la somme des lignes ».

Trois niveaux de contrôle, du plus fiable au plus souple :

• Contrôles déterministes : schémas de données, présence de champs obligatoires, cohérence arithmétique, existence d'un enregistrement en base, code de retour HTTP. À privilégier systématiquement.
• Contrôles par règles métier : montants dans les bornes autorisées, dates cohérentes, catégories appartenant à une liste fermée.
• Contrôles par modèle : un second modèle, avec une consigne différente et le résultat sous les yeux, évalue si la sortie répond à la demande. Utile pour le texte libre, mais à réserver aux cas où le déterministe ne suffit pas — et à calibrer sur des exemples réels.

L'erreur classique est de tout confier au troisième niveau. Un modèle qui évalue un autre modèle hérite des mêmes angles morts. Le déterministe d'abord, le modèle ensuite.

Tester l'agent sur des cas piégeux, pas seulement sur le cas nominal

Une évaluation d'agent IA en entreprise qui ne teste que des demandes bien formées ne mesure rien. Le vrai signal vient des cas limites :

• demandes incomplètes (un champ manquant dans le formulaire source) ;
• données contradictoires (deux adresses pour le même client) ;
• outils en panne (timeout, quota dépassé, réponse vide) ;
• demandes hors périmètre (l'agent doit-il refuser, escalader, demander une précision ?).

Pour chaque cas, définissez le comportement attendu — succès, échec propre, escalade vers un humain — et vérifiez que l'agent le produit. Un agent qui échoue proprement, en signalant ce qui manque, vaut mieux qu'un agent qui invente une réponse pour « terminer ».

Le tableau de bord qui compte : taux de réussite vérifiée

La métrique utile n'est pas « nombre de tâches terminées » mais taux de tâches terminées et validées par le contrôle. Affichez-les côte à côte. L'écart entre les deux est votre taux de faux positifs : c'est le chiffre qui doit guider vos itérations.

Ajoutez deux compteurs complémentaires : le taux d'escalade humaine (trop élevé = agent trop prudent ou mal outillé ; trop bas = agent trop confiant) et le coût moyen par tâche réussie, qui inclut les appels de vérification.

Ce que cela change pour votre projet

Un agent fiable n'est pas un agent plus intelligent : c'est un agent dont on a défini la réussite avant de le lancer, dont on vérifie la sortie à l'extérieur, et dont on mesure l'écart entre « terminé » et « réussi ». Cela ajoute du travail de conception, mais supprime la pire des situations : un système qui semble fonctionner et que personne n'ose plus superviser.

Parlons de votre cas

Si vous construisez ou prévoyez un agent IA et que la question du contrôle du résultat se pose, c'est le bon moment pour en discuter. Décrivez-moi la tâche, les données disponibles et ce que « réussi » signifie pour votre équipe : contact@hamzabelgacem.com. Nous regarderons ensemble quels contrôles mettre en place, sans sur-ingénierie.