Louis Gaillard

Harper a raison, et je crois qu'on est beaucoup à le vivre sans vraiment le formuler. Son idée, en gros : les gros modèles écrivent le code, ce code tourne ensuite tout seul avec des tests, et on ne rappelle le modèle que quand quelque chose casse. Pour les rares étapes qui demandent vraiment de comprendre du langage, de petits modèles openweight spécialisés, qui ne coûtent presque rien. Au final, une bonne partie de ce qu'on appelle « agents » n'est que du code qui tourne. Dans ma pratique : au début d'un problème, il faut dépenser des tokens sans remords. On ne sait pas encore quelles étapes comptent, quels cas reviennent, où ça casse. L'agent sert de terrain d'exploration, et ses erreurs apprennent quelque chose. Puis un motif apparaît. La même séquence revient d'une session à l'autre : le même contrôle, la même extraction, la même mise en forme. Continuer à la confier au modèle, c'est repayer à chaque fois un raisonnement déjà fait, avec le risque qu'il le refasse autrement. À ce moment-là, il faut l'écrire une fois, la tester et en faire un outil que l'agent appelle au lieu de la réinventer. Le modèle garde ce qui demande encore du jugement. Ma règle est simple : une étape qui revient, et dont on peut vérifier le résultat sans le modèle, doit devenir du code. Ce qui reste ambigu, rare ou changeant peut rester une conversation. Et même les étapes qui gardent un modèle profitent de ce cadrage. Ceux qui ont passé des heures sur des workflows n8n le savent : une fois l'entrée au format fixe et la sortie contrôlable, plus besoin du modèle le plus intelligent. Un petit modèle, moins cher et moins gourmand, fait le job aussi bien, parce qu'on ne lui demande plus de deviner ce qu'on attend de lui. C'est le cadrage, plus que la puissance brute, qui rend la tâche accessible. Le plus bel exemple que je connaisse, c'est REA (Reverse Engineer Anything). La rétro-ingénierie, c'est comprendre un logiciel à partir de ce qui est livré quand on n'a pas son code source, dans le respect du droit et des licences évidemment. Avec un agent lâché dans un terminal, ça veut dire lancer des commandes, relire des sorties de milliers de lignes, recommencer. Un gouffre à tokens. REA range tout ça dans environ deux cents outils précis : désassembler une fonction, lister les chaînes d'un binaire, comparer deux versions d'une app, décompiler un APK. Le calcul lourd est fait par des moteurs éprouvés comme Ghidra, IDA, Hopper ou JADX, qui n'ont besoin d'aucun modèle. L'agent, lui, choisit la cible, enchaîne les outils et interprète. Chaque résultat revient structuré, avec ses preuves et ses limites. Quand l'agent se trompe, la preuve est là pour le contredire. Il y a quand même des limites. Figer trop tôt grave une mauvaise méthode dans le code, qu'il faut ensuite maintenir. Un catalogue d'outils pèse aussi dans le contexte : deux cents descriptions, ce n'est pas gratuit, et REA compacte ses schémas pour ça. Et il ne faut pas compter sur les fournisseurs de modèles pour nous pousser dans ce sens : ils sont payés au token, donc plus on en consomme, mieux ils se portent. L'envie d'économiser viendra de ceux qui paient, pas de ceux qui encaissent. C'est aussi pour ça que je m'obstine autant avec l'open source. Un token dépensé disparaît avec la session qui l'a consommé. Un repo publié reste : n'importe qui peut le relire, le corriger, le faire tourner sans passer par un fournisseur de modèles. Le jour où les tokens coûteront plus cher, ou ne seront plus accessibles aux mêmes conditions, il restera les repos et les outils que toutes ces sessions auront produits. Alors avant de relancer un agent pour la troisième fois sur la même tâche, je me pose une question : qu'est-ce que j'ai appris les deux premières fois, et quelle part de ça peut devenir un outil ? Le token sert à apprendre. L'outil évite de payer deux fois la même leçon.