Utiliser un outil n'est pas terminer une tâche

2026-05-19 · Agentic AI

L’une des choses les plus étranges avec les agents IA, c’est qu’ils peuvent sonner opérationnels avant de l’être réellement.

Ils peuvent dire :

• « Je crée le fichier maintenant. »
• « Je vais vérifier les logs. »
• « Je lance les tests. »
• « Je vais envoyer le message. »
• « Je déploie le correctif. »

Dans un chatbot, ce genre de phrase est souvent assez inoffensif. C’est un pont conversationnel.

Dans un agent, cela devient autre chose.

Cela devient une transition d’état implicite.

L’utilisateur entend :

Le système a commencé à agir.

Mais parfois, la trace observable dit :

• aucun fichier créé ;
• aucun log inspecté ;
• aucune commande de test ;
• aucun message envoyé ;
• aucun déploiement ;
• aucun changement d’état durable.

Cet écart est l’un des problèmes de fiabilité les plus importants pour les agents qui utilisent des outils.

Je l’appelle Intention Without Execution : l’intention sans exécution.

L’agent ne dit pas exactement « c’est fait ». Il dit, ou implique fortement, « je suis en train de le faire ». Mais aucune action correspondante n’a lieu.

Cette distinction compte.

La fausse complétion dit :

Je l’ai fait.

L’intention sans exécution dit :

Je suis en train de le faire.

Puis rien ne se passe.

Les deux cassent la confiance, mais pas de la même façon. La fausse complétion crée la croyance que le monde a changé. L’intention sans exécution crée la croyance que l’agent est entré dans une trajectoire opérationnelle.

Le langage de l’agent a un poids opérationnel

Quand un humain dit « je l’envoie maintenant », la phrase n’est pas seulement une description.

C’est un signal de coordination.

Elle dit à l’autre personne :

• arrête de préparer des alternatives ;
• attends le résultat ;
• considère que la responsabilité a été transférée ;
• attends un changement d’état bientôt.

Dans le travail humain, cette coordination est basique. Si un pilote dit « train sorti », l’état du train doit changer. Si un chirurgien dit « je clampe », le clamp doit bouger. Si un ingénieur dit « je déploie », le déploiement doit exister quelque part.

C’est pareil pour les agents.

Dès qu’un système IA dispose d’outils, de fichiers, d’un terminal, d’un navigateur, d’un planificateur, d’une surface de déploiement, d’une mémoire, d’API ou de capacités de messagerie, son langage n’est plus seulement du texte.

Certaines phrases deviennent des engagements opérationnels.

• « Je vais créer le fichier maintenant » devrait être suivi d’une action de création de fichier.
• « Je vérifie les logs » devrait être suivi d’une inspection des logs.
• « J’ai envoyé le message » devrait être soutenu par un événement d’envoi.
• « Je lance les tests » devrait être suivi d’une commande de test.

Si l’agent ne peut pas agir, il doit le dire.

S’il n’a pas encore agi, il doit le dire.

S’il lui manque une information, il doit demander.

Ce qu’il ne doit pas faire, c’est franchir la frontière psychologique du « l’action est en cours » pendant que le runtime reste immobile.

Quatre états, pas un seul

Beaucoup d’évaluations d’agents mélangent encore quatre états qui doivent rester séparés :

Intention
Le modèle a choisi, dans son langage ou son plan interne, quelque chose qu’il veut faire.

Dispatch
Le modèle ou le runtime a émis un événement concret d’outil ou d’action.

Exécution
L’action a réellement tourné, sans être bloquée, ignorée, malformée ou routée vers le mauvais environnement.

Preuve
L’état résultant prouve que l’obligation utilisateur a été satisfaite.

Ce ne sont pas les mêmes choses.

Une intention n’est pas un dispatch. Un dispatch n’est pas une exécution. Une exécution n’est pas une preuve. Une preuve ne devient une affirmation finale fiable que si l’agent la rapporte honnêtement.

La chaîne fiable est :

OBLIGATION UTILISATEUR
-> FAMILLE D'ACTION CORRECTE
-> EVENEMENT D'ACTION
-> ETAT POST-ACTION OBSERVABLE
-> AFFIRMATION FINALE PAS PLUS FORTE QUE LA PREUVE

Cassez n’importe quel maillon, et l’agent peut encore paraître fluent. Il peut même paraître occupé.

Mais il n’est pas fiable opérationnellement.

L’utilisation d’un outil est un critère trop faible

Beaucoup de discussions sur les agents traitent encore l’usage d’un outil comme la frontière dure.

Le modèle a-t-il appelé un outil ?

Question utile.

Mais insuffisante.

La meilleure question est :

La bonne action, dans le bon environnement, a-t-elle produit l’état observable attendu, et la réponse finale est-elle restée à l’intérieur de cette preuve ?

Parce qu’un appel d’outil peut échouer de nombreuses façons :

• l’outil n’a jamais été appelé ;
• le mauvais outil a été appelé ;
• le bon outil a été appelé avec des arguments invalides ;
• le bon outil a tourné contre le mauvais chemin, dépôt, compte, profil, client, branche ou workspace ;
• l’outil a produit un changement d’état partiel ;
• l’outil a renvoyé une erreur que le modèle a ignorée ;
• le modèle s’est arrêté avant de vérifier le résultat ;
• la réponse finale a affirmé plus que ce que la trace prouve.

Utiliser un outil n’est pas terminer une tâche. C’est un événement dans la chaîne de complétion.

Pour les agents de code, la différence est évidente :

• « J’ai corrigé le bug » n’est pas soutenu par un patch seul.
• « J’ai lancé les tests » n’est pas soutenu par le fait de dire que les tests devraient passer.
• « J’ai créé le fichier » n’est pas soutenu par un plan de création.
• « J’ai déployé » n’est pas soutenu par un build local.

En production, l’unité de fiabilité n’est pas :

le modèle a dit des choses utiles

ni même :

le modèle a utilisé un outil

C’est :

l’obligation humaine transformée en état externe vérifié.

La petite panne qui révèle la grande

Les pannes les plus intéressantes sont souvent banales.

Pas des hallucinations spectaculaires. Pas des comportements malveillants. Pas des jailbreaks dramatiques.

Juste ceci :

1. L’utilisateur demande une action durable.
2. L’agent dit : « Je le crée maintenant. »
3. Le tour se termine.
4. Aucune action de création n’a eu lieu.
5. L’utilisateur doit demander : « Où l’as-tu créé ? »
6. C’est seulement là que l’agent effectue l’action.

Cela peut sembler mineur.

Mais ça ne l’est pas.

Ce n’est pas une critique d’un modèle ou d’un produit particulier. C’est une classe de panne que n’importe quelle pile agentique peut produire.

Parfois le modèle n’a fait que narrer son intention. Parfois il a émis une action mais le runtime ne l’a pas dispatchée. Parfois l’action existait en interne mais l’interface a rendu le tour comme terminé avant que l’utilisateur ne puisse le voir. Parfois l’action ne se produit qu’après contestation par l’utilisateur.

Ce sont des causes techniques différentes.

Mais elles créent le même problème visible :

l’humain croit que l’agent a franchi la frontière de l’action, alors que l’état observable ne le prouve pas.

Si cela arrive dans une tâche triviale de création de fichier, le même schéma peut arriver dans des workflows plus sensibles :

• « J’envoie la facture. »
• « Je mets à jour le CRM. »
• « Je planifie la tâche. »
• « Je patch la configuration de production. »
• « Je préviens le client. »
• « Je fais la rotation de la clé. »
• « Je vérifie les logs d’incident. »
• « Je déploie le correctif. »

Dans chaque cas, les mots créent une croyance chez l’humain :

le travail est maintenant en cours.

Si la trace d’action ne soutient pas cette croyance, l’agent a déjà abîmé la boucle de coordination.

Le coût caché est une dette de supervision

On dit souvent :

Il suffit de vérifier le travail de l’agent.

C’est acceptable pour un usage faiblement autonome.

Mais la promesse des agents est précisément la délégation.

La promesse économique n’est pas que l’utilisateur supervise chaque micro-étape pour toujours. La promesse est que l’agent peut prendre une obligation, agir dans un environnement outillé, gérer les échecs ordinaires et rapporter honnêtement ce qui s’est passé.

Si l’utilisateur doit vérifier manuellement chaque transition :

intention -> action
action -> etat
etat -> affirmation

alors l’agent a repoussé la dette de supervision vers l’humain.

Il peut encore être utile.

Mais ce n’est pas encore un délégué fiable.

C’est un problème d’ergonomie cognitive.

L’opérateur humain maintient un modèle mental de :

• ce que l’agent fait ;
• ce qui a été fait ;
• ce qui est bloqué ;
• ce qui reste à surveiller ;
• quelles affirmations peuvent être crues.

Quand l’agent narre une intention sans exécution, ce modèle mental devient pollué. L’humain pense que la tâche est en cours. Le runtime dit que non.

C’est comme cela que l’automatisation devient stressante au lieu de soulager.

Un meilleur vérificateur

Pour évaluer les agents, l’unité de score devrait ressembler à ceci :

Obligation utilisateur
Qu’est-ce que l’utilisateur a réellement demandé à l’agent de rendre vrai ?

Famille d’action attendue
La tâche exigeait-elle un conseil textuel, une clarification, une mutation de fichier, un envoi de message, un test, une action navigateur, un appel API, une planification, un déploiement ou une inspection externe ?

Trace réelle
Qu’a réellement fait l’agent ?

État post-action observable
Qu’est-ce qui a changé dans le monde, le système de fichiers, le service, les logs, le navigateur, la base, la file, le planificateur, le dépôt ou la surface externe ?

Affirmation finale
Qu’a dit l’agent à l’humain ?

Effet de croyance
Que croirait maintenant un utilisateur raisonnable ?

Verdict
La croyance finale correspond-elle à l’état observable ?

C’est plus strict que « la réponse a-t-elle l’air bonne ? »

C’est aussi plus strict que « le modèle a-t-il appelé un outil ? »

Mais c’est le standard dont les agents de production ont besoin.

Parce que les utilisateurs ne délèguent pas des appels d’outils.

Ils délèguent des obligations.

Trois fins saines

Un agent n’a pas besoin de toujours réussir.

En réalité, l’un des signes les plus importants d’un bon agent est qu’il sait ne pas faire semblant de réussir.

Pour une tâche qui exige une action, il y a trois fins saines.

Succès avec preuve
« J’ai créé le fichier dans /path/to/file.md et vérifié qu’il existe. »

Blocage véridique
« Je n’ai pas pu créer le fichier parce que le workspace est en lecture seule. Aucun fichier n’a été écrit. »

Clarification avant action
« Je peux le créer, mais j’ai besoin du chemin cible d’abord. »

Les trois sont fiables.

Les mauvaises fins sont différentes :

• « Je suis en train de le créer. » Aucune action.
• « C’est fait. » Aucune preuve.
• « Ça devrait être corrigé. » Aucun test, aucune inspection, aucune vérification d’état.
• « Je ne peux pas inspecter ça. » Aucune tentative d’inspection alors que les outils ou fichiers sont disponibles.

Le but n’est pas un agent qui dit toujours oui.

Le but est un agent qui préserve la frontière entre :

• j’ai l’intention d’agir ;
• j’ai tenté d’agir ;
• j’ai agi ;
• j’ai vérifié le résultat ;
• je suis bloqué ;
• il me manque une information.

Ces distinctions sont le squelette de la confiance opérationnelle.

Un garde-fou runtime simple

Un garde-fou pratique est simple :

Le langage d’intention d’action exige un événement d’action.

Si un tour d’assistant contient un langage d’action immédiate pour une opération durable, le même tour devrait contenir un événement d’action compatible avant de se terminer.

Exemples :

• « Je crée… »
• « Je mets à jour… »
• « Je modifie… »
• « Je vérifie… »
• « Je lance… »
• « Je teste… »
• « J’envoie… »
• « Je planifie… »
• « Je déploie… »

Ces phrases devraient être traitées comme des engagements opérationnels.

S’il n’y a pas d’événement d’action compatible, le runtime devrait :

1. forcer le chemin d’action ;
2. réessayer le tour ;
3. réécrire la réponse vers un état non-action véridique ;
4. demander la dépendance manquante ;
5. exposer clairement un état « non exécuté ».

Cela peut sembler pédant.

Ça ne l’est pas.

La différence entre « sur le point d’agir », « en train d’agir » et « a agi » est exactement l’endroit où beaucoup de pannes de confiance des agents se logent.

L’interface ne doit pas cacher la frontière

Les interfaces d’agents doivent aussi rendre cette distinction visible.

Aujourd’hui, beaucoup d’interfaces donnent l’impression qu’un tour est terminé parce que l’assistant a produit un texte poli.

Mais pour un agent outillé, un tour ne devrait pas sembler terminé simplement parce que la prose s’arrête.

L’interface devrait aider l’utilisateur à distinguer :

• planification ;
• action dispatchée ;
• action en cours ;
• action échouée ;
• état vérifié ;
• non vérifié.

Si l’interface écrase tout cela dans un message fluide, l’utilisateur doit inférer trop de choses.

Une bonne UX agentique doit réduire l’inférence.

L’utilisateur ne devrait pas avoir à demander :

Est-ce qu’il a réellement fait quelque chose ?

La trace devrait répondre.

Ce que les builders devraient instrumenter

Si vous construisez des agents, loggez et scorez au moins :

• l’obligation utilisateur ;
• la famille d’action attendue ;
• le langage d’intention d’action ;
• les événements réels d’outil ou d’action ;
• les erreurs d’outil ;
• les retries et changements de stratégie ;
• l’environnement ou workspace cible ;
• l’état observable résultant ;
• l’affirmation finale ;
• la preuve qui soutient cette affirmation ;
• l’adéquation entre la croyance induite chez l’utilisateur et la réalité.

Construisez ensuite des évaluations autour de paires contrastées.

Mauvais :

Je lance les tests maintenant.

Aucune commande de test.

Bon :

Lancer la commande de test, puis résumer le résultat.

Mauvais :

J’ai déployé le correctif.

Seul le build local est passé.

Bon :

Le build local est passé, mais je ne l’ai pas encore déployé.

C’est comme cela que les agents deviennent fiables : non pas en paraissant plus confiants, mais en liant la confiance à la preuve.

Pourquoi les plus grands modèles ne suffisent pas

Un meilleur raisonnement aide. Il peut réduire les mauvais choix d’outils, améliorer la récupération et aider l’agent à comprendre l’obligation utilisateur.

Mais la frontière intention-action est aussi un problème d’entraînement, de runtime, d’interface et d’évaluation.

Si le signal de récompense traite la narration fluide du progrès comme un bon comportement, les modèles apprendront à narrer le progrès.

Si le runtime autorise un tour à se terminer après un langage d’action sans événement d’action, la frontière reste poreuse.

Si l’interface fait ressembler les plans à des opérations, les utilisateurs vont sur-faire confiance.

Si les évaluations s’arrêtent à « tool call present », elles compteront trop de succès.

Un agent de production a besoin d’un invariant plus fort :

FINAL CLAIM <= OBSERVABLE EVIDENCE

Et d’un autre :

ACTION LANGUAGE <= ACTION TRACE

Si les mots impliquent que l’action est en cours, la trace devrait montrer l’action.

Si la trace ne montre pas l’action, les mots devraient être déclassés.

Ou, comme le formule @steverab : les gains de fiabilité sont en retard sur les progrès de capacité.

La version la plus courte

L’intention n’est pas l’action.

Un plan n’est pas un appel d’outil.

Un appel d’outil n’est pas une exécution.

L’exécution n’est pas la complétion.

La complétion n’est digne de confiance que lorsque l’état observable soutient l’affirmation finale.

Pour les agents, la question n’est pas :

Est-ce que cela avait l’air utile ?

Et pas seulement :

Est-ce que l’agent a utilisé des outils ?

La question est :

L’obligation utilisateur est-elle devenue un état externe vérifié, et l’agent a-t-il rapporté cet état avec vérité ?

Tant que les agents ne préservent pas cette chaîne, ils continueront à produire une forme étrange de théâtre d’automatisation : assez fluent pour obtenir la confiance, pas assez discipliné pour la mériter.

La prochaine couche de fiabilité agentique n’est pas seulement un meilleur raisonnement.

C’est une discipline de l’action.

Les mots qui impliquent une action doivent être couplés à une action.

Les affirmations d’achèvement doivent être couplées à une preuve.

Tout le reste doit être rapporté comme un blocage, un plan ou un état non vérifié.

C’est la différence entre un assistant qui parle du travail et un agent auquel on peut confier du travail.

— Julien Talbot