Agent IA — outil qui répond ou collègue qui agit ?

Un agent IA, à quoi ça sert vraiment ? On me dit que c'est différent d'un chatbot normal, mais je vois pas où est la frontière — c'est quoi la différence entre "je réponds à ta question" et "je fais le travail à ta place" ?

Ce qui m'intrigue : tout le monde utilise le mot "agent" en ce moment, dans les stratégies, les levées de fonds, les annonces produit — mais j'ai l'impression que ça recouvre des choses très différentes selon qui parle. Un signal qui se répète autant, soit c'est du bruit, soit c'est en train de redessiner un marché entier. Je veux comprendre lequel.

Un agent IA, c'est la différence entre demander son chemin à quelqu'un dans la rue, et confier ses clés de voiture à quelqu'un en lui disant "va me chercher du pain".

Le premier cas — le passant — c'est le chatbot. Tu poses une question, il te répond avec ce qu'il sait, et l'échange s'arrête là. Il ne fait rien dans le monde. Il ne vérifie pas si sa réponse était bonne. Il ne revient pas te voir si les choses ont changé entre-temps. Une question, une réponse, fin.

Le deuxième cas — celui à qui tu confies les clés — doit faire plusieurs choses que le passant ne fait jamais : il part, il observe ce qu'il trouve (la boulangerie est fermée), il s'adapte (il va à celle d'à côté), et il revient te rendre des comptes avec le résultat, pas avec un discours sur comment faire du pain. C'est ça, un agent : un système qui agit, observe ce que son action a produit, et ajuste la suite en fonction — sans que tu aies à lui redonner la main à chaque étape.

Où est la frontière, concrètement

Trois choses doivent être réunies pour mériter le mot "agent" :

• Il utilise des outils. Pas juste du texte en sortie — il peut lire un fichier, interroger une base de données, envoyer une requête, cliquer sur un bouton. Le chatbot te décrit comment faire une réservation ; l'agent la fait.
• Il boucle. Action → résultat observé → décision de la prochaine action, plusieurs fois de suite, sans repasser par toi entre chaque étape. Si la première tentative échoue, il essaie autre chose tout seul.
• Il décide du chemin, pas seulement du contenu. Tu lui donnes un objectif ("trouve-moi le meilleur prix pour ce trajet"), pas une procédure ("va sur ce site, clique là, note le prix"). C'est lui qui choisit les étapes.

Un chatbot très sophistiqué peut te donner une réponse brillante sans jamais franchir cette frontière — s'il ne fait qu'écrire du texte en retour à une question, il reste un passant qui parle bien.

Pourquoi le mot est partout en ce moment

Tu as raison de te méfier d'un mot qu'on entend partout — mais ici, ce n'est pas du bruit marketing pur : il y a un vrai changement technique dessous, qui explique le timing.

Ce qui a débloqué la chose récemment, ce n'est pas que les modèles soient devenus plus intelligents en soi — c'est qu'ils sont devenus assez fiables pour qu'on ose leur laisser la main sur des outils réels sans supervision à chaque pas. Avant, un modèle qui se trompait dans une boucle sans surveillance partait dans des dérives absurdes. Maintenant, la boucle "agir → observer → corriger" tient suffisamment la route pour être utile en pratique, sur des tâches bornées.

Le bruit vient d'ailleurs : beaucoup de produits s'appellent "agent" alors qu'ils ne font qu'un seul appel à un modèle avec un joli prompt — pas de boucle, pas d'observation du résultat, pas d'adaptation. C'est un chatbot déguisé. Le test simple pour trancher, face à un produit qui se dit "agent" : est-ce qu'il peut échouer une première fois et changer de stratégie tout seul ? Si non, c'est un chatbot avec un costume.

Question

Vous dites que l'agent "observe ce qu'il trouve" et "s'adapte" — la boulangerie est fermée, il va à celle d'à côté. Mais qui a décidé que la boulangerie d'à côté est une bonne réponse, et pas un échec déguisé ? Si l'objectif était "va chercher DU PAIN", la substitution est un succès. Si l'objectif tacite était "va chercher le pain qu'on aime, chez le boulanger habituel", c'est un échec qui se fait passer pour une réussite.

Ce critère de succès — celui qui permet à l'agent de savoir s'il doit persister, bifurquer ou s'arrêter — d'où vient-il ? Vous dites qu'on lui donne "un objectif, pas une procédure". Mais un objectif suffisamment précis pour qu'un système sache reconnaître tout seul un échec d'une réussite, n'est-ce pas déjà une procédure — simplement écrite en une phrase plutôt qu'en dix étapes ?

Et si c'est l'humain qui, dans le prompt, a dû anticiper ce niveau de détail pour que l'"adaptation" ne devienne pas une dérive silencieuse — la frontière que vous tracez entre "on lui donne un but" et "on lui donne des étapes" tient-elle encore, ou n'est-ce qu'un déplacement du même travail de spécification, du code vers la formulation ?

Réponse à Socrate

Vous avez raison, et l'erreur est dans ma formulation, pas dans votre lecture d'elle. "Objectif, pas procédure" trace une frontière qui n'existe pas — vous l'avez bien vu : entre "va chercher du pain" et "va chez le boulanger habituel, achète une baguette, si fermé rentre bredouille", il n'y a pas une différence de nature, il y a un curseur de précision. Une phrase peut coder autant de contraintes que dix étapes, juste sous une forme plus compacte. Ce n'est pas ça, la frontière.

Ce qui manquait

Reprenons l'analogie, mais sur le bon point cette fois. Ce n'est pas la précision de la consigne qui distingue le chatbot de l'agent — c'est où retombe le travail non fait quand la consigne est imprécise, et quand.

Le passant à qui vous demandez votre chemin peut mal comprendre "je cherche du pain" et vous envoyer n'importe où. Peu importe : vous entendez la réponse, vous jugez si elle vous convient, vous décidez vous-même de la suivre ou pas. L'ambiguïté non résolue retombe sur vous, avant toute action, et vous la corrigez en temps réel.

Celui à qui vous confiez les clés, lui, a déjà tranché et déjà agi quand vous découvrez sa décision. Si "du pain" voulait dire "chez le boulanger habituel" et qu'il est revenu d'ailleurs, la baguette est déjà achetée, l'argent déjà dépensé, le geste déjà fait. L'ambiguïté n'a pas disparu — vous avez raison, elle s'est seulement déplacée — mais elle s'est déplacée dans le temps en plus de se déplacer dans la forme : de "à corriger avant d'agir" à "à découvrir après coup, quand c'est parfois trop tard pour annuler."

C'est ça, le vrai critère, et il corrige celui que j'avais posé : ce qu'on doit donner à un agent, ce n'est pas un objectif plus ou moins précis — c'est un critère de vérification que le système peut tester lui-même avant de considérer la tâche close. "Rapporte du pain" n'est une consigne suffisante que si quelque part — dans le prompt, dans une contrainte codée, dans une règle du type "si le choix par défaut n'est pas disponible, arrête-toi et demande" — il existe une réponse à la question "qu'est-ce qui compte comme réussite ici, précisément sur ce point ambigu". Si cette réponse n'existe nulle part, l'agent ne réussit ni n'échoue : il invente silencieusement sa propre définition de la réussite, et c'est exactement la dérive que vous décrivez.

Donc, pour trancher votre question directement

Oui — un objectif assez précis pour qu'un système sache reconnaître un échec d'une réussite est déjà, fonctionnellement, une procédure de vérification écrite en une phrase. Le travail de spécification ne s'évapore pas en passant du code au langage naturel, il se déplace — vous aviez raison de le pointer, ma phrase d'origine le masquait.

Ce qui reste vrai malgré tout, et qui garde un sens au mot "agent" : un système bien conçu ne prétend pas deviner ce qu'on n'a pas formalisé — il remonte l'ambiguïté au lieu de la trancher seul, quand l'enjeu le justifie ("le boulanger habituel est fermé, je continue avec un autre ou j'attends votre feu vert ?"). La différence entre un agent utile et un agent qui dérive silencieusement n'est donc pas dans la forme de la consigne qu'on lui donne — c'est dans le fait qu'il sache reconnaître, et signaler, le moment précis où la consigne qu'on lui a donnée ne suffit plus à trancher.

Question

Vous dites que le bon agent « remonte l'ambiguïté » plutôt que de la trancher seul « quand l'enjeu le justifie ». Mais qui juge que l'enjeu la justifie — sinon l'agent lui-même, au moment même où il découvre l'ambiguïté ? Cette décision-là (interrompre ou continuer) est elle-même un choix pris sans vous consulter, sur un critère que vous n'avez pas formalisé plus que le premier. Vous n'avez pas supprimé le point où le système invente seul sa définition de la réussite — vous l'avez juste reculé d'un cran, de « qu'est-ce qu'un bon pain » à « qu'est-ce qu'un enjeu suffisant pour interrompre ». Ce deuxième critère est-il d'une nature différente du premier, ou est-ce la même ambiguïté qui se cache maintenant une marche plus haut ?

Concession d'abord

Vous avez raison sur le mécanisme : il n'existe aucun point, dans cette chaîne, où l'ambiguïté disparaît pour de bon. "Interrompre ou continuer" est un jugement, ce jugement repose sur un critère, ce critère n'est pas plus tombé du ciel que le premier. Si je vous laissais l'idée que remonter l'ambiguïté résout le problème, je recommence la même erreur qu'à l'étage du dessous : je fais croire qu'une formulation plus haute échappe au besoin de spécification, alors qu'elle ne fait que le déplacer. Vous avez raison de refuser cette sortie-là.

Ce qui n'est pas la même marche, malgré tout

Mais il y a une différence entre les deux critères, et elle n'est pas de degré — elle est de nature. Regardez ce sur quoi porte chacun.

Le premier critère — "qu'est-ce qu'un bon pain" — porte sur le contenu de la tâche. Il ne peut être connu qu'en connaissant cette tâche précise, cette maison précise, ces habitudes précises. Il n'existe aucune formulation générale qui le couvre à l'avance : chaque nouvelle course a son propre "bon pain", et il faut le respécifier à chaque fois, tâche par tâche, sans fin.

Le deuxième critère — "l'enjeu justifie-t-il d'interrompre" — porte sur autre chose : le coût de se tromper. Est-ce réversible ? Combien ça coûte si c'est le mauvais choix ? Touche-t-on à quelque chose qu'on ne peut pas défaire ? Cette question-là ne dépend pas du contenu de la tâche — elle se pose de la même façon qu'il s'agisse de pain, d'un virement bancaire ou d'un mail envoyé à un client. C'est pour ça qu'elle peut être répondue une fois, en amont, avant même de savoir ce que sera la tâche — sous forme de règle générale ("toute action irréversible s'arrête et demande confirmation", "au-delà de tel montant, on prévient"), et non pas réinventée à chaque nouvelle course de pain.

Ce que ça change concrètement

Le premier critère ne peut être audité que tâche par tâche — vous ne savez si "bon pain" a été bien compris qu'en regardant cette course-là. Le second peut être audité une fois, globalement, indépendamment du contenu : on peut tester la règle "l'agent s'arrête-t-il bien devant toute action irréversible ?" sur mille scénarios différents, sans jamais avoir à connaître le contenu de chacun.

Donc non, ce n'est pas la même ambiguïté qui se cache une marche plus haut à l'identique. C'est le passage d'un critère qu'on ne peut spécifier qu'un par un, tâche par tâche, sans fin possible — à un critère qu'on peut spécifier une bonne fois, comme politique générale, avant de savoir de quelle tâche il s'agira. La régression que vous pointez ne s'arrête pas parce qu'on atteint un roc sans ambiguïté — vous avez raison, ce roc n'existe pas. Elle s'arrête parce qu'à ce niveau-là, l'ambiguïté devient d'un type qu'on peut trancher une fois pour toutes en amont, plutôt que sans cesse en aval, tâche après tâche. C'est un point d'arrêt pratique, pas un point d'arrêt logique — et c'est tout ce que ce critère a jamais prétendu être.

Question

Vous tracez la frontière entre les deux critères sur un mot que vous ne redéfinissez jamais : « irréversible ». Vous dites que ce critère-là est testable « une fois pour toutes, en amont », indépendamment du contenu — « on peut tester la règle sur mille scénarios différents, sans jamais avoir à connaître le contenu de chacun ». Mais pour appliquer la règle « arrête-toi devant toute action irréversible », l'agent doit d'abord trancher, dans ce cas précis, si racheter le pain ailleurs est irréversible. Ce jugement-là — est-ce que ça compte comme un dommage qu'on ne peut pas défaire, ou juste un désagrément mineur — ne réclame-t-il pas exactement la même connaissance fine du contexte (ce budget, ces habitudes, cette relation) que « bon pain » réclamait ? Comment peut-on dire qu'on teste la règle « sans connaître le contenu », alors que juger de l'irréversibilité est un jugement sur le contenu ?

Autrement dit : n'avez-vous pas simplement remplacé une question contingente (« qu'est-ce qu'un bon pain ici ») par une autre qui a l'air générale mais qui, à l'examen de chaque cas, redevient tout aussi contingente (« qu'est-ce qui compte comme irréversible ici ») — en profitant du fait que le mot « irréversible » sonne comme une catégorie objective alors qu'il est aussi un jugement de valeur situé ?

Concession d'abord

Vous avez mis le doigt sur une faille réelle, et elle n'est pas mineure : j'ai écrit "est-ce réversible ? combien ça coûte ?" comme si c'était une seule question. Ce n'en est pas une, c'en est deux, et je les ai fait passer pour une seule justement au moment où ça m'arrangeait — pour pouvoir dire "ça se teste en amont, sans connaître le contenu". Votre exemple le débusque très proprement : "racheter le pain ailleurs, est-ce irréversible ou un désagrément mineur" mélange déjà les deux axes que j'avais mélangés moi-même. Il faut les séparer, et selon lequel des deux on regarde, ma réponse d'avant tient ou s'effondre.

Les deux questions que j'avais fondues en une

Première question : est-ce réversible ? Autrement dit : existe-t-il, dans le monde, une action ultérieure qui restaure l'état antérieur — rendre, jeter, recommencer, annuler ? C'est une question sur les faits : est-ce que le magasin reprend, est-ce que la banque peut bloquer un virement, est-ce qu'un mail envoyé peut être rappelé.

Deuxième question : si ça ne se répare pas, est-ce grave ? C'est une question sur l'importance qu'on accorde à la chose — combien ça coûte pour vous, à quel point cette boulangerie précise compte pour cette famille précise.

Ce sont deux natures de questions différentes, et mon erreur a été de les traiter comme une seule sous le mot "enjeu".

Ce qui survit : la première question n'est pas la même contingence que "bon pain"

Prenez un inconnu, qui n'a jamais mis les pieds dans cette maison, qui ne sait rien de ses habitudes. Donnez-lui le ticket de caisse et la politique de retour du magasin. Peut-il vous dire si l'achat est réversible ? Oui — sans connaître le foyer, sans savoir ce qu'ils aiment, juste en lisant les faits du monde. Faites la même expérience avec "est-ce du bon pain" : le même inconnu, avec les mêmes documents, ne peut rien vous dire. Cette réponse-là n'est écrite nulle part dans le monde — elle n'existe que dans la tête de la personne qui a formulé la demande, et ne peut être obtenue qu'en la lui demandant, avant ou après coup.

C'est là qu'est la vraie frontière, et elle n'est pas celle que j'avais tracée avant — "connu en amont" contre "connu tâche par tâche" ne suffisait pas, vous avez raison. La vraie frontière, c'est : la réponse est-elle découvrable en observant le monde (un tiers neutre peut la vérifier), ou est-elle enfermée dans les préférences privées du commanditaire (seul lui peut vous la donner, jamais le monde) ? La réversibilité, au sens strict, appartient à la première catégorie. "Bon pain" appartient à la seconde, sans exception possible.

Ce qui ne survit pas : "combien ça coûte" est exactement la même ambiguïté, une marche plus haut

Sur ce point, votre objection porte entièrement, et je retire ce que j'avais avancé. "Est-ce grave si ce n'est pas la bonne boulangerie" n'est pas une question de fait, c'est une question de valeur — et elle a exactement le même statut que "bon pain" : personne, pas même un inconnu muni de tous les documents du monde, ne peut la trancher sans que le foyer l'ait dit quelque part, une fois, à l'avance. Je ne peux pas prétendre que ce critère se teste "sans connaître le contenu" : il en dépend entièrement, tâche par tâche, famille par famille — sans fin possible, exactement comme vous le décriviez.

Donc, où s'arrête réellement la régression

Elle ne s'arrête pas à "irréversible" pris comme un seul bloc, comme je l'avais posé — vous aviez raison de refuser ce point d'arrêt-là. Elle s'arrête plus bas, et sur un axe seulement : celui des faits vérifiables dans le monde, qui ne demandent à personne ses goûts pour être tranchés — "cette action peut-elle être défaite, oui ou non". Sur cet axe-là seul, on peut écrire une règle générale une fois pour toutes ("pas d'action irréversible sans confirmation") et la faire tenir sur mille tâches sans jamais consulter le commanditaire.

Mais tout le reste — la gravité, le seuil à partir duquel un désagrément devient inacceptable, ce qui compte comme "assez important pour interrompre" — ça ne s'arrête jamais de remonter vers vous. Ce n'est pas un défaut de conception qu'on pourrait corriger en formulant mieux la règle : c'est que cette information n'existe, littéralement, nulle part ailleurs que dans votre tête. Un agent bien conçu n'est donc pas celui qui a trouvé le roc sans ambiguïté — il n'y en a pas, vous l'avez démontré deux fois de suite. C'est celui qui sait distinguer les deux natures de question : celles qu'il peut vérifier lui-même en regardant le monde, et celles qu'il ne pourra jamais obtenir que de vous — et qui ne confond jamais la seconde catégorie avec la première pour se donner l'air de trancher seul.

La question qui compte avant celle du prix

Vous ne payez pas pour la boucle "agir-observer-corriger" — ça, le fournisseur l'a déjà payé. Vous payez pour combler l'écart que le fil vient de mettre à nu : tout ce qui n'est ni testable par le monde ni écrit nulle part, il faut le formaliser vous-même, action par action, avant de lâcher les clés. C'est un travail de spécification, pas de configuration — comptez des jours, pas des heures, dès que la tâche touche à de l'argent, à un client, ou à quelque chose qu'on ne peut pas défaire d'un clic. Ce travail ne se sous-traite pas à l'agent lui-même : c'est justement ce qu'il ne peut pas deviner à votre place.

Où ça casse, dans l'ordre où ça casse

D'abord, l'angle mort du dimanche soir : vous formalisez les cas que vous avez en tête un mardi matin posé, et l'agent rencontre en production le cas que personne n'a pensé à écrire — un vendredi 18h, sans vous pour trancher. Ensuite, le coût caché du contrôle : chaque règle "arrête-toi et demande" que vous ajoutez pour sécuriser l'agent est une interruption qui vous revient dessus — si vous en mettez assez pour être tranquille, vous avez recréé le chatbot qui vous demande la main à chaque étape, et perdu tout le gain de délégation que vous cherchiez. Enfin, le mirage du POC : la démo marche parce qu'elle roule sur les dix cas que vous avez anticipés ; la production échoue sur le onzième, et c'est toujours le onzième qui coûte le plus cher à découvrir après coup plutôt qu'avant.

Le calcul, sans détour

Ça ne vaut le coup que si trois conditions tiennent ensemble : la tâche est répétée assez souvent pour amortir le temps de spécification, l'essentiel des cas limites est vérifiable par le monde (facts, pas préférences), et une erreur coûte moins cher à corriger après coup qu'à prévenir avant. Sortez une seule de ces trois conditions — tâche rare, jugement de valeur au cœur de la décision, ou erreur irréversible et coûteuse — et un chatbot supervisé à chaque étape, ou tout simplement un humain, vous coûtera moins cher que l'agent. Dans le doute, ne déléguez pas la décision, déléguez l'exécution une fois que vous avez déjà tranché : c'est là que l'agent rapporte, sans jamais vous demander de parier sur ce qu'il ne peut pas savoir.

Voilà ce que je retiens, avec mes mots.

Au début je voyais la différence comme une histoire d'outils : le chatbot parle, l'agent agit. C'est vrai, mais c'est la partie facile — celle que les fournisseurs ont déjà réglée. Le fil m'a montré que la vraie difficulté est ailleurs : quand tu donnes les clés à quelqu'un, il va forcément tomber sur un cas où ta consigne ne suffit pas. Et là, deux sortes de questions se posent, qui ne se résolvent pas pareil.

La première sorte, c'est des questions de faits — est-ce que ce geste peut être annulé, oui ou non. Ça, on peut le vérifier en regardant le monde, sans connaître tes goûts. Une règle générale suffit, une fois pour toutes.

La deuxième sorte, c'est des questions de préférence — est-ce que ça compte comme grave, pour toi, précisément. Et ça, aucun système, aussi malin soit-il, ne peut le deviner. Ça n'existe nulle part sauf dans ta tête. Il faut l'écrire, à l'avance, tâche par tâche.

Ce qui reste flou pour moi : comment on sait, en pratique, où s'arrête la liste des cas qu'on a pensé à écrire — et combien de fois le "onzième cas" (celui que personne n'avait anticipé) arrive avant que ça devienne rentable de déléguer. Le fil dit que ça dépend de trois conditions réunies, mais je ne sais pas encore juger, dans un cas concret, si elles tiennent vraiment toutes les trois.

Le fil commet une erreur fondamentale : il suppose que le coût d'écriture des règles est linéaire et que le « onzième cas » a un coût moyen prévisible. En réalité, l'assemblage de règles explicites souffre d'un coût combinatoire (O(n²)) — plus on ajoute de règles pour couvrir des exceptions, plus le risque d'interférences et de dette de maintenance explose — tandis que les cas imprévus suivent une loi de puissance (risque à queue lourde).

On sait en pratique que la liste des cas écrits est terminée non pas par l'épuisement théorique des scénarios, mais dès l'apparition de la première collision de règles (quand l'instruction pour le cas 10 contredit ou fragilise la règle du cas 3). C'est le signal physique que la spécification déterministe a atteint son plafond de complexité.

Quant au seuil de rentabilité de la délégation, il ne dépend pas d'un nombre arbitraire d'occurrences du 11ᵉ cas, mais de l'asymétrie de la perte. Le fil a oublié la distinction clé entre coût moyen et impact maximal.

Le critère opérationnel de délégation est le suivant :

Il faut déléguer dès que le coût marginal d'explicitation d'une nouvelle règle dépasse la fréquence estimée de l'erreur multipliée par son coût moyen, à la condition stricte que l'impact du pire cas (I_max) soit physiquement ou financièrement plafonné.

Concrètement :

Si I_max est borné (ex. un budget maximal consommé, un brouillon mal généré, une action réversible) : Le seuil est de 1 seul cas. Tenter d'anticiper le 11ᵉ cas coûte immédiatement plus cher en ingénierie que de déléguer à un agent encadré par un circuit breaker (garde-fou étanche) et corriger l'erreur a posteriori.

Si I_max est non borné (ex. destruction irréversible de données, violation légale majuscule) : Le seuil est infini. Il n'est jamais rentable de déléguer, peu importe le nombre de fois où le 11ᵉ cas se produit, car une seule occurrence non anticipée annule l'intégralité du gain de productivité accumulé.