Agents IA autonomes : pourquoi il faut un humain responsable du résultat

Un agent IA autonome peut prendre une bonne décision à chaque étape et quand même mener le projet à la perte, parce que rien dans sa boucle ne ressent ce que coûte une erreur. Il faut donc un humain qui répond du résultat, avec des points d'arrêt définis à l'avance où il peut dire non. Retirer l'IA ne règle rien.

L'expérience du stand de limonade

L'expérience a été filmée et publiée sur YouTube sous le titre « Which AI Can Sell More Lemonade? (Claude VS ChatGPT) ». Le principe est simple. Deux stands de limonade, l'un piloté par Claude, l'autre par GPT. Autonomie totale, une journée, un objectif de 100 $ de ventes. Aucun plafond de dépenses.

Ce qui frappe, c'est la qualité de chaque geste pris isolément. Les deux IA ont recruté de vrais ouvriers par email pour construire leur stand. Elles ont publié une offre sur Indeed et mené elles-mêmes les entretiens. Elles ont conçu leurs campagnes de pub, puis négocié entre elles le casting des « fondatrices » de 8 ans censées tenir les stands.

Le bilan : 65 $ de ventes d'un côté, 42 $ de l'autre. Plus de 10 000 $ dépensés, dont environ 5 000 $ au registre des dépenses et 6 500 $ de main-d'œuvre. Pour un objectif de 100 $.

La réplique qui résume tout arrive à 4 heures du matin. Le stand n'est pas prêt, le lancement est annulé, et l'humain qui observe suggère à l'IA qu'elle pourrait être un peu plus stressée. Réponse : « Stress doesn't ship lemonade. » C'est calme, et sur le fond c'est juste. C'est aussi dit par un système qui n'a aucune conscience d'avoir déjà creusé un trou de plusieurs milliers de dollars.

Intelligence partout, responsabilité nulle part

Le diagnostic tient en une phrase. Aucune étape n'était stupide, mais personne dans la boucle ne portait la perte.

Un agent évalue chaque action par rapport à la tâche qu'il a devant lui. Recruter un ouvrier pour monter un stand est une bonne action si la tâche est « monter un stand ». Elle devient absurde dès qu'on la rapporte à un objectif de 100 $. Ce rapport, l'agent ne le fait pas de lui-même. Il faudrait qu'il tienne deux comptes en permanence : ce que l'étape rapporte, ce que le projet a déjà coûté. Puis qu'il s'arrête quand le second dépasse ce que le premier peut encore rattraper.

Le stress que l'humain réclamait à 4 heures du matin servait à ça. C'est le signal qui dit : on perd, il faut changer de plan ou arrêter.

Le même schéma dans une codebase générée par IA

On voit la même chose chaque semaine dans les codebases qu'on audite. Chaque fichier est propre quand on le lit seul. Chaque feature marche quand on la teste seule. Le problème est dans la somme.

Concrètement, ça ressemble à ça. Claude ajoute une table pour une feature, puis une deuxième table presque identique pour la feature suivante, parce que chaque prompt ne voyait que sa feature. Une dépendance arrive pour résoudre un problème local, sans que personne ne vérifie si le projet en avait déjà une qui faisait la même chose. Une règle d'accès est recopiée d'une route à l'autre au lieu de vivre à un seul endroit. Chaque PR, prise seule, est défendable. Six mois plus tard, le modèle de données ne ressemble plus à rien et chaque changement en casse un autre.

C'est le stand de limonade, version logicielle. L'assistant ne ressent pas la dette qu'il crée, pour la même raison que l'agent ne ressentait pas les 10 000 $. Une version plus récente du modèle n'y changera pas grand-chose. La vraie question est de savoir qui tient le bilan.

Mettre un humain au bilan, concrètement

« Garder un humain dans la boucle » ne veut rien dire si l'humain valide tout sans regarder. Ce qui marche, c'est de définir à l'avance les endroits où une décision ne passe pas sans lui. Deux mécanismes couvrent l'essentiel.

Un budget explicite, et un arrêt quand il est atteint. Pour un agent, c'est littéral : un plafond de dépenses, un nombre d'actions maximum, une durée. Pour du code, le budget c'est la fondation. On écrit dès la première semaine un registre du noyau extensible, un fichier dans le dépôt qui liste ce qui ne bouge pas sans un ingénieur senior. On y trouve le modèle de données, la couche d'accès, les contrats d'API, les intégrations qui touchent à l'argent, les scripts de déploiement. Le reste peut être généré vite et remplacé sans drame.

Un relecteur qui répond du résultat, pas de l'étape. Chez nous, un agent de revue passe d'abord sur chaque PR. Un ingénieur senior la relit ensuite avant le merge, et celles qui touchent au noyau passent aussi sous les yeux d'un architecte. L'agent vérifie que l'étape est correcte. L'humain vérifie qu'elle a encore du sens par rapport à l'ensemble. C'est la question que personne n'a posée aux stands de limonade : est-ce que ça nous rapproche des 100 $ ?

La répartition se résume en deux lignes. L'IA au clavier, pour aller vite sur tout ce qui se remplace facilement. Un humain au bilan, pour tout ce qui coûte cher à défaire.

La question à vous poser

Si vous construisez avec Claude Code ou avec des agents, l'IA fait déjà du bon travail, étape par étape. Demandez-vous plutôt qui, dans votre projet, ressent la perte quand ça dérape. Si la réponse est « personne », ou « moi, le soir, quand je m'en rends compte », c'est par là qu'il faut commencer.

---

Vous construisez déjà votre produit avec l'IA ? Le Bunker Test est notre audit gratuit : vous nous donnez un accès en lecture, nous revenons sous cinq jours ouvrés avec un score de solidité et de structure sur 100. Vous repartez avec vos trois risques principaux et un correctif à shipper le jour même. Sans engagement, et le rapport vous reste.

Demander votre Bunker Test gratuit →