Un auteur de Habr propose une recette pour les agents IA : le « terminé » doit être prouvé
Habr a publié un article sur le principal point douloureux des agents IA en production : un « terminé » convaincant, sans résultat réel derrière. L'auteur propose de déplacer l'attention de la qualité de la réponse vers la recette du travail effectué. On pardonne à un assistant une formulation maladroite, mais un agent qui modifie des données de production doit prouver son résultat par l'état du système, et non par son propre rapport. Nous avons analysé la thèse et en avons tiré un schéma de vérification applicable. Le rapport d'un agent est du texte, pas un fait. Les critères de clôture d'une tâche se définissent avant le lancement. Il faut vérifier l'état du système et le périmètre des modifications.
Traité par IA depuis Habr AI ; édité par Hamidun News
L'erreur la plus coûteuse d'un agent IA en production ressemble à un succès : un bref « terminé », sans rien derrière. L'auteur d'un article récent sur Habr propose de déplacer l'attention de la qualité de la réponse vers la recette du travail : que doit-il se passer, précisément, pour qu'une tâche puisse être considérée comme close ? La thèse de l'introduction est tranchée. Un assistant qui propose des formulations peut se voir pardonner un paragraphe raté. Un agent qui modifie des données de production, non.
Le fragment en accès libre ne contient ni benchmarks ni méthodes concrètes : ils restent réservés à la version complète sur Habr. Mais la façon de poser la question est juste et mérite d'être analysée, car c'est précisément là que passe aujourd'hui la frontière entre démo et production.
Pourquoi « terminé » ne prouve rien
L'assistant produit un texte, l'humain le lit et décide quoi en faire. Le point de contrôle est intégré au processus. L'agent, lui, agit seul : il écrit dans le CRM, corrige des tableaux, lance des scripts, envoie des e-mails. Son rapport « tâche accomplie » reste un texte généré, comme n'importe quelle autre réponse d'un modèle. Il peut correspondre à l'état du système, ou non.
La suite du scénario est connue. Un collègue va vérifier, découvre des écarts, refait le travail à la main et s'explique auprès des personnes concernées. Le coût de l'erreur passe de l'agent aux humains, et ce de manière invisible : dans les statistiques d'automatisation, la tâche figure comme exécutée.
La recette plutôt que la confiance
La logique de la recette est empruntée à l'ingénierie classique. Les critères de clôture d'une tâche sont fixés avant le lancement et vérifiés sur l'état du système, et non sur le compte rendu de l'agent. L'enregistrement a bien été créé. Le champ voulu a été modifié. Le nombre de lignes touchées correspond à celui attendu. Rien d'autre n'a été modifié.
En pratique d'ingénierie, on distingue généralement trois niveaux de vérification :
- résultat : l'état cible est atteint, et cela se voit dans le système lui-même ;
- périmètre : la comparaison de l'état avant et après ne montre que les modifications prévues ;
- trace : le journal des actions de l'agent permet de reconstituer ce qu'il a fait, et dans quel ordre.
Ces niveaux se complètent. Un résultat sans contrôle du périmètre laissera passer des modifications parasites, et un journal seul, sans vérification du résultat, se réduit à un beau récit de ce qui aurait dû se passer.
Quelles métriques suivre ?
Tant que la recette n'est pas mesurée, la discussion reste au niveau des impressions. Voici l'ensemble minimal d'indicateurs pour une équipe qui lance un agent dans un processus de production :
- taux de faux « terminé » : tâches déclarées closes mais qui n'ont pas passé la vérification ;
- part des tâches acceptées sans correction humaine ;
- temps humain de vérification d'une tâche ;
- part des tâches dont la vérification est automatisée ;
- nombre de retours en arrière sur les modifications sur une période donnée.
Il importe de considérer ces chiffres ensemble. Si l'agent clôt beaucoup de tâches mais que le temps de revérification manuelle augmente, l'économie est fictive.
Par où commencer en pratique
Choisissez une tâche que l'agent exécute déjà et, avant le prochain lancement, notez ses critères de clôture sous une forme vérifiable. Si un critère ne peut pas être contrôlé par un script ou une requête, il est trop flou et devra être reformulé.
Ensuite, séparez le vérificateur de l'exécutant. Une vérification lancée par le même agent, qui en interprète lui-même le résultat, reproduit le problème initial. Une simple requête sur la base de données ou la comparaison d'extractions avant et après est plus fiable qu'un auto-rapport.
Enfin, gardez l'humain dans un rôle de contrôleur par échantillonnage là où l'erreur coûte cher : modifications massives de données, opérations de paiement, envois externes. Pour le reste, une recette automatique suffit, avec un seuil clair au-delà duquel la tâche repart en vérification manuelle.
L'idée de l'auteur de Habr se résume à une règle simple : l'agent n'obtient le droit de dire « terminé » qu'accompagné d'une preuve. Pour un marché où les agents sont déployés en masse dans les processus de production, c'est un standard sensé et peu coûteux.
Delegate Deep Research, Coding & Workflows to an AI Agent
Deploy autonomous multi-step execution with NomadNet Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and complex task orchestration.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.