Le modèle n’est plus le problème. Votre harness, si.

Combien de fois avez-vous changé de modèle en espérant que ça règle vos problèmes d’agent ? Chez OpenAI, une tâche Codex un peu lourde peut boucler plus de 100 fois — et une seconde de latence en trop par appel ajoute une demi-minute au total [1]. Le modèle ne change rien à ça. Ce qui change tout, c’est la couche qu’on met autour.

Ce qui se passe vraiment avant que le modèle voie un token

Un LLM prédit le prochain token. Point. Il ne peut pas lancer une commande shell, éditer un fichier, ni se souvenir de quoi que ce soit entre deux appels [1]. Or une tâche comme « trouve ce bug et fais passer les tests », c’est essentiellement des actions.

Entre votre requête et le GPU, il y a trois couches : le harness (qui construit le contexte, exécute les outils dans un sandbox et boucle), la couche API (auth, rate limits, tokenisation, checks de sécurité), et l’inférence. À chaque itération, tout est refait : l’historique est renvoyé, le texte retokenisé, le prompt reprocessé. Au vingtième appel d’outil, le harness renvoie le prompt initial, dix-neuf appels et dix-neuf résultats — juste pour ajouter une ligne à la fin.

Les optimisations d’OpenAI ne touchent pas au modèle. WebSockets persistants pour éviter de repayer les handshakes TCP+TLS, préfixes de prompt stables pour maximiser le cache, découverte d’outils différée, tokenisation du seul delta, checks de sécurité lancés en parallèle de l’inférence [1]. Du travail d’ingénierie système classique, appliqué à un nouvel objet.

Le harness n’est pas une chose, c’est deux

Martin Casado résume l’embarras collectif : moins de harness c’est mieux, ou le harness a une valeur propre ? Daniel Miessler propose la distinction qui débloque le débat.

Every harness carries some mix of WHAT and HOW—context about what you want, and instructions for how to get it. And those two halves age in opposite directions.

Le HOW pourrit. C’est la Bitter Lesson de Sutton qui se joue dans vos fichiers de config : plus les modèles deviennent bons, plus vos instructions pas-à-pas ont l’air stupides [2]. Le WHAT s’apprécie. Qui vous êtes, ce que vous construisez, pour qui, avec quelles contraintes, et à quoi ressemble « bien » chez vous. Un modèle plus intelligent en fait plus, pas moins.

Et c’est là que l’argument devient intéressant pour nous : les labos peuvent entraîner leurs modèles à être de meilleurs agents, ils le feront. Mais ils ne peuvent pas post-entraîner votre contexte dedans. Ça doit venir de l’extérieur, à chaque tâche.

Déléguer n’est pas une question de modèle, c’est une question de tâche

Corollaire direct côté management. PostHog balaie l’idée que la confiance suive la capacité du modèle :

Trusting your agents just because the models got smarter is like skipping your seatbelt because you got a nicer car.

Deux questions suffisent : la tâche est-elle facile à vérifier ? Est-elle facile à annuler ? Croisez les deux et vous obtenez quatre niveaux d’autonomie [3]. Niveau 0, l’agent est un assistant — pour le code sensible qu’on ne peut ni grep ni rollback. Niveau 1, human-in-the-loop, pour tout ce qui demande du goût. Niveau 2, délégation : c’est là que vit la majorité du travail dev aujourd’hui. Niveau 3, self-driving : les bumps de dépendances, les fixes de lint, la couverture de tests.

Le détail que je retiens : le réflexe de mettre un humain en garde-fou du niveau 2, c’est se transformer soi-même en goulot d’étranglement. La bonne réponse est d’encoder les garde-fous dans le pipeline — dry-run par défaut, credentials scopés, feature flags. Et quand l’autonomie manque, c’est souvent juste un déficit de contexte. Encore le WHAT.

Vérifiable, ça veut dire évaluable

« Facile à vérifier » n’arrive pas tout seul. C’est une infrastructure, et Airbnb en a fait une discipline : l’eval-driven development, l’équivalent GenAI du TDD [4]. La règle numéro un tient en une phrase : sortez 100 sorties de votre prototype et lisez-les. Catégorisez les erreurs réelles, construisez les evals à partir de là — pas depuis un tableau blanc.

Trois enseignements que je trouve directement actionnables. Trois à cinq juges LLM bien calibrés valent mieux que vingt-cinq bruyants, chacun sur une seule dimension. Un juge non calibré est pire que pas de juge, parce qu’il donne une fausse confiance : dataset doré de 50 à 100 exemples, avec des mauvais, et on vise 88-90 % d’accord avec l’humain. Et si vos experts métier ne sont pas d’accord entre eux sur un label, on s’arrête — on ne peut pas automatiser un désaccord humain.

Pour les systèmes agentiques, la sortie finale ne suffit pas : une bonne réponse peut masquer un raisonnement cassé ou une trajectoire absurde. Il faut évaluer au niveau du step, de la trajectoire et de la session.

Et un prompt, ça se déploie

Le pendant opérationnel est presque gênant tant il est évident. La plupart des équipes ne livreraient jamais du code sans CI. Puis elles modifient un prompt, regardent une sortie, et poussent en prod [5].

Un mauvais changement de code lève une exception. Un mauvais changement de prompt dérive de ton, sort du format, hallucine autrement — et renvoie un HTTP 200 parfaitement valide. Rien dans le cycle requête/réponse ne distingue une bonne sortie d’une sortie dégradée.

D’où l’eval gate, avec quatre choix de design qui font la différence entre un vrai contrôle et du théâtre : fail closed (pas d’eval = bloqué par défaut), vérifier le dernier run et pas n’importe lequel, exposer le statut en lecture seule, et retourner une raison actionnable — « bloqué : 3 cas de factualité sur 40 » plutôt que « bloqué » [5].

Pourquoi ça devient urgent, et pas juste élégant

On pourrait ranger tout ça au rayon hygiène d’ingénierie. Sauf que l’économie pousse dans le même sens. Dwarkesh Patel avance un raisonnement simple : les revenus des labos font x10 par an, la capacité de compute seulement x3 [6]. Les prix spot sont déjà +40 % depuis le creux de février, et Google paierait 900 M$ par mois pour 110 000 GPU louées à SpaceX — environ 2x le spot.

Sa conclusion : plus les modèles sont intelligents, mieux ils monétisent le même compute, donc plus le compute devient cher. Et à 20 $ l’heure de H100, utiliser un modèle plus faible devient absurde — il brûle plus de tokens pour le même résultat.

Traduction pour nos équipes : la métrique qui compte n’est pas le score au benchmark, c’est le coût par tâche réussie. GPT-5.6 Sol en reasoning max dépasse Fable 5 sur l’index coding d’Artificial Analysis pour moins de la moitié du prix [1]. Ce n’est pas un chiffre de modèle, c’est un chiffre de système.

Le harness, les evals, les niveaux d’autonomie : ce ne sont pas trois sujets. C’est le même, vu de trois angles. Ce qui vous appartient, ce n’est pas le modèle.

Alors, la vraie question du prochain sprint : combien de votre harness décrit ce que vous voulez, et combien décrit comment le faire ?

---

Sources

1. How ChatGPT Optimizes its Agent Loop: Harness, API, and Inference
2. The Answer to the Harness Question
3. How much can you delegate to agents?
4. Eval-driven development: Lessons from evaluating GenAI at scale
5. Treat prompt changes like code deploys
6. Why compute might get 10x more expensive in coming years

Pour aller plus loin

• “Stateful systems are incredibly hard to build”: How Perplexity thinks about AI agent sandboxes — la partie du harness dont personne ne parle : où le code des agents s’exécute réellement, et pourquoi l’état est le vrai problème.
• The 2026 Guide To Agent Observability Tools — panorama de l’outillage pour instrumenter des trajectoires d’agents, indispensable si vous voulez évaluer autre chose que la sortie finale.
• Snowflake launches AI agent governance layer to track activity, control costs — la même logique de garde-fous encodés dans le pipeline, mais vendue comme produit par un éditeur.
• Opus 5 on Vending-Bench: Once Again the Best Capitalist, Once Again Misaligned | Andon Labs — un rappel utile que « meilleur modèle » et « agent de confiance » sont deux axes distincts.
• How GPT-5.6 fuses frontier intelligence with frontier efficiency — le point de vue du labo sur le compromis capacité/coût, à lire en miroir de l’analyse de Dwarkesh.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.