Gabriel Jarry

← Tous les billets

Ce qu’on ne veut pas coder, on le paie en tokens

· Cet article existe aussi en anglais · Accessibilité Grand public

Une question à une seule réponse

Dix-huit. C’est la bonne réponse, la seule. Même modèle, même fichier, une question qui n’en admet qu’une. Selon la marge que je laissais à l’agent, j’ai obtenu dix-huit, quatorze, ou une fois cent dix-sept. Rien ne bougeait sauf sa liberté de manœuvre. Et la facture, elle, comptée en tokens : ces unités de texte qu’on paie à la machine chaque fois qu’elle réfléchit.

De cette petite expérience, je tire une conviction plus large. L’IA agentique rejoue l’erreur de jeunesse du cloud, et on la règle au token.

Revenons à la question. Elle portait sur un bout de programme : combien de ses fonctions renvoient un certain genre de résultat ? Une réponse exacte, dix-huit, et qui se compte, comme on compterait les CDD dans une pile de contrats. L’ennui tient à un détail : quatre de ces fonctions sont écrites dans une tournure inhabituelle (une forme condensée, une lambda, le genre d’écriture qui dit la même chose autrement). Cherchez la trace au mot près, vous en manquez justement quatre, et vous plafonnez à quatorze. Lire une page sans en comprendre la grammaire, c’est rater ce qui est formulé autrement. J’ai donc posé la même question quatre fois au même petit modèle, en changeant à chaque tour ce que je l’autorisais à faire. Huit essais par variante, sur un fichier figé à une version publique, pour que la mesure soit refaisable. Voici ce que chaque façon coûte, et ce qu’elle vaut.

  • L’agent qui lit tout. Il parcourt le code lui-même, page après page. Juste à tous les coups, mais lent et coûteux : il s’y reprend à une quinzaine de fois en moyenne pour reconstituer ce qu’un index, la table d’un livre préparée d’avance, donnerait d’un coup.
  • L’agent bricoleur. On lui laisse la trousse générique (recherche par mot-clé, droit de tout combiner comme un virtuose) mais pas l’outil dédié qui comprend la grammaire du code. C’est l’objection qu’on entend partout : un bon bricolage suffit, non ? Les données disent non, et pas « un peu moins bien ». Sur huit essais, cinq tournent autour de quatorze, trois s’effondrent à cinq. Presque jamais le bon compte, et imprévisible d’une fois sur l’autre.
  • L’agent outillé, mais lâché dans la nature. Il appelle le bon outil, celui qui donne la réponse exacte, puis part en roue libre : il élargit la zone tout seul, fouille d’autres dossiers, relance, recompte. Une fois sur deux il ne rend même pas un décompte exploitable. Un des essais a affirmé cent dix-sept fonctions : il avait étendu sa recherche, de son propre chef, à tout un dossier au lieu du seul fichier demandé.
  • L’agent outillé, mais tenu en laisse. Il appelle le bon outil, une fois, sur la bonne zone, et s’arrête là. Dix-huit sur dix-huit, à chacun des huit essais, les quatre fonctions difficiles comprises. Aucune variation. Et sept fois moins cher que l’agent qui lit tout.

On pourrait croire ce dernier gagnant d’avance, puisqu’il appelle l’outil qui sert aussi de référence. Ce serait mal voir. La bonne réponse, dix-huit, je l’ai établie à part, recoupée à la main et par deux autres voies. L’outil ne décrète pas la vérité ; il la trouve à coup sûr, quand l’agent bricoleur, avec accès au même code, plafonne à quatorze. Le partage n’est pas « l’outil a raison parce que c’est l’outil ». Il est plus simple : une question à réponse exacte se traite avec ce qui la calcule, pas avec ce qui la devine.

J’attendais un facteur cent : le fantasme de l’ingénieur, l’outil parfait contre l’agent qui peine. Le vrai écart est de sept. Pour un résultat plus fiable, sept fois moins cher, c’est déjà un marché qu’on signe sans hésiter. Mon attente était démesurée ; le gain, lui, tient bon.

Restait l’autre moitié de l’histoire, celle qui m’a surpris. Le quatrième agent avait exactement le même outil que le troisième. Tout se joue dans le cadre : un périmètre fixé, un nombre d’étapes borné, l’interdiction de re-vérifier sa propre sortie. Laquelle des trois brides porte l’essentiel de l’effet ? Je ne l’ai pas démêlé, et je me garderai d’en faire une loi. Ensemble, elles transforment un agent erratique en agent exact. Le troisième, lui, était libre. Il a redéfini sa tâche, et s’est perdu.

Une erreur de catégorie

Sous ce résultat, une faute simple. Compter ces fonctions n’est pas affaire d’appréciation : réponse unique, vérifiable, toujours la même. Une tâche mécanique, au sens où une calculatrice l’est : mêmes entrées, même sortie, à tous les coups. La confier à une machine qui devine, même très douée, c’est comme tirer à pile ou face pour savoir si 17 est un nombre premier.

Le piège est insidieux. Le probabiliste sait imiter le déterministe ; il rend souvent la bonne réponse. Mais « souvent » n’est pas « toujours ». Et lâché en liberté, il ne se contente pas de répondre : il réinterprète la question. C’est exactement ce qu’a fait le troisième agent. Personne ne lui avait demandé de fouiller tout le dépôt. Il a décidé seul que c’était la bonne lecture de la tâche.

Le même mouvement que le cloud

Cette tentation a un précédent économique exact : le cloud. Avant lui, on achetait des serveurs, un capital payé une fois. Le cloud a changé ce capital en charge : on loue le calcul à l’heure, on ne possède plus rien, on paie à l’usage. Un progrès décisif, le plus souvent. Son piège porte un nom : le lift-and-shift. Vous posez votre vieille application telle quelle sur des machines louées, sans rien repenser, et vous découvrez la facture : payer à l’heure, sans fin, ce qu’un peu de travail aurait figé une bonne fois.

L’IA agentique rejoue ce film, un cran plus haut. Ce n’est plus le calcul qu’on loue, c’est le raisonnement, facturé au mot que la machine produit, le fameux « token ». Écrire un programme se payait une fois ; relancer un agent se paie à chaque fois. Lui faire relire un module entier pour une question qu’un index trancherait d’un coup, c’est le même lift-and-shift. Le compteur de tokens, lui, tourne à chaque exécution.

La dette d’outillage, payée en tokens

Pourquoi le fait-on quand même ? La raison est réelle, et ce n’est pas de la paresse. Un outil fiable a un coût d’entrée. Le geste vite fait ne coûte rien ; l’outil robuste, celui qui ne trébuche sur aucun cas tordu et qu’on relance mille fois sans surprise, coûte à écrire. L’agent, lui, abolit ce coût d’entrée : il fait le travail tout de suite, sans qu’on fabrique rien. Voilà le marché caché. Ce qu’on ne veut pas, ou ne peut pas, payer en développement, on le paie en tokens.

On m’objectera que les agents écrivent déjà des petits programmes pour ces tâches : pour compter, chercher, renommer. C’est précisément la bonne réponse : écrire un programme, c’est figer le résultat au lieu de le re-deviner. L’agent qui code n’a jamais été le problème. Le problème, c’est celui qui refait la même tâche au jugé, sans jamais figer ni vérifier son outil. Coder, c’est se ranger du bon côté de la ligne. Le coût d’écrire l’outil se paie une fois et s’amortit dès les premiers usages, comme une recette qu’on écrit une fois pour la refaire cent. Et le plus souvent l’outil existe déjà : l’agent n’a qu’à s’en servir.

Parfois, la roue libre est rationnelle. Une tâche unique, jetable, ne mérite pas son outil. Le piège, c’est quand le jetable devient récurrent. On re-paie alors le token à chaque exécution d’une tâche qu’une bonne fois aurait close. Et l’addition se paie deux fois, puisqu’un agent laissé libre ne rend jamais tout à fait le même résultat : on perd l’argent, et la confiance dans le chiffre obtenu.

La ligne de partage

De là, un test de décision simple. Devant une tâche, demandez-vous : a-t-elle une réponse vérifiable et stable ? Lister, compter, renommer, vérifier un format, tracer des dépendances : tout cela est déterministe. L’agent ne devrait pas le refaire au jugé : il devrait fabriquer l’outil, puis l’appeler. Quand la tâche demande au contraire de juger une situation ouverte, de rédiger, d’explorer l’inconnu, alors le jugement faillible reprend toute sa place.

Ma mesure ajoute une condition que je n’avais pas vue venir. Le bon outil ne suffit pas ; encore faut-il border l’agent autour. Le régime qui a déraillé avait pourtant le bon analyseur ; on l’avait juste laissé libre de réinterpréter sa tâche.

Border l’outil ne veut pas dire lui faire aveuglément confiance. La confiance se gagne, et elle se gagne par les tests : c’est tout le sens de l’avoir écrit une fois pour de bon. Mon décompte de dix-huit, je l’ai recoupé par trois méthodes avant d’en faire une référence. Songez au pire des cas : un outil déterministe mais faux rend une réponse fausse, et reproductible ; plus personne ne la remet en question. D’où la règle, en une phrase : vérifie un résultat déterministe avec du déterministe. Un outil testé, un second passage, un schéma, un invariant. Jamais un modèle qu’on laisse recompter à l’intuition : il rouvrirait la porte qu’on venait de fermer.

La discipline qui en découle est concrète, et c’est la mienne au quotidien. Appeler un analyseur plutôt que lire le code de tête. Confier la réécriture d’un symbole à un outil qui ne se trompe pas, jamais à la main. Faire passer le travail de l’agent par une porte de qualité mécanique, au lieu de le laisser juger seul. Le geste, à chaque fois, est le même : retirer au modèle la décision qui a une bonne réponse, et la lui rendre seulement là où il n’y en a pas. Rien de tout cela n’est nouveau. C’est l’hygiène ordinaire de l’ingénieur, appliquée à un collaborateur qui se trouve être une machine.

Une illustration, pas une loi

Soyons honnête sur la portée. Une mesure, un seul petit modèle, une seule tâche, huit essais par régime : c’est une illustration, pas une preuve. Un modèle plus puissant déraillerait sans doute moins, et l’écart de coût dépend de la tâche. Je n’en tire pas une science. J’en tire une direction, et elle s’accorde avec ce que le bon sens d’ingénieur sait déjà.

Car l’IA agentique n’est pas un piège. C’est une bascule économique réelle, et souvent un progrès. Elle rejoue simplement l’erreur de jeunesse du cloud : confondre « la machine peut le faire » avec « la machine devrait le faire ». Le cloud a fini par apprendre à trier ce qui gagne à l’élasticité et ce qui vaut mieux rester figé. L’agentique n’en est pas encore là. Toute la discipline tient dans ce tri : reconnaître ce qui doit rester déterministe, le borner fermement, et payer une fois en code ce qu’on refuserait de re-payer indéfiniment en tokens. Une IA qu’on laisse deviner ce qu’elle pourrait calculer, c’est un taxi qu’on laisse refaire le même tour de pâté de maisons : le compteur grimpe, on revient au point de départ. À un moment, il faut couper le moteur.

Pour aller plus loin

Si l’essentiel vous suffit, vous pouvez vous arrêter ici. Ce qui suit est pour qui veut les sources et le détail de la mesure.

L’idée que le modèle gagne à déléguer aux outils ce qu’il fait mal n’est pas neuve. Toolformer le résume d’une phrase : les modèles de langage « peinent sur des fonctions basiques comme l’arithmétique ou la recherche factuelle, là où des modèles spécialisés bien plus simples excellent ».

Quelques précisions de reproductibilité, pour qui veut refaire le calcul plutôt que me croire sur parole. Le modèle était Claude Haiku, volontairement un petit modèle, là où l’effet est le plus visible ; un modèle plus puissant déraillerait sans doute moins. L’outil dédié du quatrième agent est ast_search, l’analyseur de code d’axm-forge, la boîte à outils que je développe ; le shell générique des autres agents, c’est grep et consorts. Le module mesuré est figé à une version publique. Le protocole détaillé, les trente-deux exécutions brutes et le code sont sur la page de mesure.