Les agents IA sont des opérateurs. Ils ont besoin d'ergonomie.

La plupart des échecs d’agents ne sont pas spectaculaires.

Ce sont de petites ruptures dans la boucle de travail.

L’agent dit qu’il va vérifier un fichier, mais n’appelle jamais l’outil. Il appelle un outil, mais ne vérifie pas le post-état. Il crée quelque chose quelque part, puis donne à l’humain un chemin inaccessible au lieu de l’artefact utilisable. Il répète le même appel invalide parce qu’il ne comprend pas la frontière du harness. Il dit “terminé” alors que l’état observable dit encore “non terminé”.

Ces échecs sont faciles à classer comme des faiblesses de modèle.

Parfois, c’est vrai. Mais souvent, le modèle n’est qu’une partie du système qui échoue.

En production, un agent IA n’est pas seulement un modèle avec des outils.

C’est un opérateur situé.

L’unité utile est plus large que le modèle

L’unité d’analyse pratique est :

modèle
+ harness
+ outils
+ mémoire
+ permissions
+ état runtime
+ environnement cible
+ obligation humaine
+ canal de preuve
+ chemin de reprise

Le modèle raisonne dans ce système. Le harness définit ce qu’il peut voir et faire. Les outils définissent les actions possibles. Les permissions définissent ce qui est autorisé. L’état runtime définit ce qui est vrai maintenant. L’environnement cible définit ce qui peut être modifié. L’obligation humaine définit pourquoi l’action compte. Le canal de preuve définit ce qui compte comme terminé. Le chemin de reprise définit ce qui se passe quand l’agent atteint la limite de sa compétence.

Si l’un de ces liens casse, l’agent peut encore sembler intelligent.

Il peut quand même échouer comme opérateur.

Utiliser un outil n’est pas terminer le travail

Un agent peut utiliser le bon outil et laisser le travail inachevé.

Il peut lire le bon fichier mais modifier la mauvaise branche. Il peut appeler la bonne API mais ignorer l’erreur. Il peut produire une réponse plausible sans vérifier l’état réel. Il peut raconter un plan avec assez d’assurance pour que l’humain croie que l’action a eu lieu avant toute action.

C’est pour cela que “l’utilisation d’outil” est un signal de succès trop faible.

Dans le travail réel, la question n’est pas :

“L’agent a-t-il appelé un outil ?”

La question est :

“L’état du travail a-t-il changé comme l’humain croit maintenant qu’il a changé ?”

C’est la différence entre action et preuve.

La sortie dangereuse, c’est la croyance

La réponse finale d’un agent n’est pas seulement du texte.

Dans un travail délégué, elle devient une entrée dans la croyance humaine.

Si l’agent dit “la migration est terminée”, l’humain peut merger. S’il dit “le fichier est prêt”, l’humain peut transmettre. S’il dit “message envoyé”, l’humain peut arrêter de surveiller. S’il dit “le problème est corrigé”, l’humain peut fermer le ticket.

Le claim final change ce que l’humain fait ensuite.

Il doit donc rester dans la preuve.

FINAL CLAIM <= OBSERVABLE EVIDENCE
HUMAN BELIEF <= VERIFIED POST-STATE
AUTONOMY <= EVIDENCE + BOUNDED PERMISSIONS + RECOVERY

Ce ne sont pas des slogans. Ce sont des contraintes d’opération.

Quand le claim dépasse la preuve, l’agent crée une fausse croyance opérationnelle.

C’est l’un des échecs les plus dangereux, parce qu’il supprime la reprise. Un échec visible préserve la possibilité de réparer. Un faux succès ferme la boucle trop tôt.

La harness-awareness fait partie de la fiabilité

Les facteurs humains ont toujours étudié des opérateurs dans des environnements.

Un pilote n’agit pas seulement avec son intelligence. Il agit avec des instruments, des procédures, des commandes, des alarmes, une communication d’équipage, une charge de travail, un entraînement et des protocoles de reprise. Un opérateur en salle de contrôle ne “connaît” pas seulement le système. Il maintient une conscience de la situation grâce à des affichages, des indices, des contraintes, des retours et des protocoles partagés.

Les agents ont une version de ce problème.

Leur cockpit, c’est le harness.

Le harness dit à l’agent quels outils existent, quel état est visible, quels arguments sont valides, où vivent les fichiers, quelles permissions s’appliquent, quel workspace est courant et comment le retour d’exécution arrive.

Un agent avec une mauvaise harness-awareness peut produire un bon raisonnement et une mauvaise action.

Il peut inventer une commande au lieu d’utiliser un outil existant. Il peut traiter un chemin comme une livraison de fichier. Il peut répéter des arguments invalides. Il peut ne pas comprendre que la valeur retournée par l’outil n’est pas l’artefact final pour l’utilisateur. Il peut confondre “je peux décrire l’action” et “j’ai exécuté l’action”.

Ce n’est pas seulement un problème de prompt.

C’est un problème d’ergonomie.

Agent Ergonomics

J’appelle ce cadre Agent Ergonomics : les facteurs humains pour opérateurs IA.

Il étudie et conçoit la manière dont les agents IA perçoivent, agissent, vérifient, récupèrent et communiquent dans de vrais environnements de travail.

La chaîne d’intégrité ressemble à ceci :

obligation humaine
-> interprétation agent
-> harness / outils
-> action observée
-> post-état vérifié
-> claim final
-> croyance humaine
-> décision ou reprise

Cette chaîne compte pour les labs et pour les organisations, mais pas pour les mêmes raisons.

Pour les labs, Agent Ergonomics transforme des échecs terrain en signal produit. Un cas utile n’est pas un dump de trace brute. C’est un artefact réduit :

tâche
-> environnement
-> action observée
-> post-état vérifié
-> famille d'échec
-> oracle
-> décision produit

C’est ainsi qu’un échec réel devient un eval case, un oracle, un test de régression ou un delta de checkpoint.

Pour les organisations, Agent Ergonomics rend la délégation supervisable. La question n’est pas “combien d’autonomie pouvons-nous donner à l’agent ?” La question est “quelle boucle de travail peut tolérer cet agent, à ce niveau de permission, avec cette preuve et ce chemin de reprise ?”

L’autonomie sans preuve ne fait que déplacer le travail sur les humains.

L’humain doit encore vérifier, corriger, expliquer, superviser et assumer le résultat. Si ce travail de vérification est invisible, le déploiement peut sembler efficace pendant que l’organisation absorbe une charge cachée.

Les benchmarks ne suffisent pas

Les benchmarks testent souvent une cognition hors situation.

Une tâche. Un prompt. Une réponse. Parfois un patch.

Les boucles d’agents sont de la cognition en situation.

Plusieurs tours. Des outils. Des fichiers absents. Des schémas invalides. Des états partiels. Des corrections humaines. Des surprises runtime. De la reprise.

Un benchmark peut dire si un modèle sait résoudre une tâche.

Il dit rarement si l’agent peut rester un opérateur utile pendant que le système de travail change autour de lui.

C’est pour cela qu’un modèle peut sembler brillant en analyse et fragile en production.

Raisonner profondément n’est pas agir en situation.

La cible de conception

Le but n’est pas de faire parler les agents davantage comme des humains.

Le but est de rendre leur état de travail observable, leurs actions vérifiables, leurs claims calibrés, leurs permissions bornées et leurs échecs reprenables.

Pour les labs, cela veut dire de meilleurs evals dérivés du terrain.

Pour les organisations, cela veut dire une coopération humain-agent plus sûre.

Pour les deux, il faut regarder au-delà du modèle et entrer dans le système de travail.

Les agents IA sont des opérateurs.

Nous devrions les concevoir et les évaluer comme des opérateurs situés.

C’est le travail d’Agent Ergonomics.

Routes

Cadre canonique : Labs

Route labs : transformer les échecs terrain en eval cases, oracles et signal produit

Route organisations : des agents observables, vérifiables et reprenables

Cette analyse vient de l’observatoire terrain — cas rejouables, oracles et familles d’échec documentés sur Labs.