Harness-first — pourquoi le cadre prime sur le modèle

Tout le monde compare les modèles. Les benchmarks, les classements, les annonces. Chaque trimestre, un nouveau modèle « surpasse » le précédent et les fils LinkedIn s’enflamment.

Sauf que sur mes workflows en production depuis six mois, le facteur déterminant n’a jamais été le modèle.

Le succès d’un agent IA dépend moins du modèle que du cadre qui l’encadre. Deux niveaux à distinguer : le scaffold (architecture agent immédiate — prompt, outils, boucle) et le harness (discipline d’ingénierie qui maintient ce scaffold dans la durée, avec rules, hooks et gates). Sur SWE-bench, le même modèle varie du simple au double selon le scaffold. La nuance labo/production est réelle, mais la direction est claire : l’effort d’ingénierie consacré au choix de modèle est mieux investi dans le cadre.

Scaffold et harness : deux niveaux de cadre

Quand un agent LLM produit un résultat médiocre, le réflexe habituel est de changer de modèle. Le dernier modèle d’OpenAI ne convient pas — essayons celui d’Anthropic. Celui d’Anthropic hallucine — essayons celui de Google. Ce model-shopping est rarement la bonne réponse.

Deux termes circulent, pas toujours distingués. Le scaffold désigne l’architecture immédiate d’un agent : le system prompt, les outils disponibles, la boucle d’exécution qui enchaîne les appels au modèle. C’est ce que les équipes soumettent aux benchmarks. Le harness englobe le scaffold et s’étend à tout ce qui l’encadre dans la durée : fichiers de règles chargés automatiquement, hooks pré et post action, gates de validation, discipline TDD, stratégie de gestion du contexte. Le scaffold est une architecture. Le harness est la discipline d’ingénierie qui construit et maintient cette architecture au fil des semaines.

Sans scaffold, un modèle génère du texte. Avec lui, il devient un agent capable d’agir dans un environnement contraint. Le harness, lui, détermine si cet agent reste fiable six mois après sa mise en production.

Les données qui changent la perspective

Deux benchmarks récents isolent l’impact du scaffold — modèle constant, architecture agent variable.

SWE-bench Lite (2024-2025) évalue des agents sur la résolution de vrais tickets GitHub. Six équipes ont soumis des agents construits sur Claude 3.5 Sonnet aux benchmarks de code de cette période. Le leaderboard ne standardise pas la version exacte utilisée par chaque équipe, ce qui introduit un biais potentiel. Malgré cette réserve, l’amplitude des résultats reste parlante : de 23 % (SWE-agent) à 48,3 % (Globant Code Fix). Les différences de version du modèle n’expliquent pas à elles seules un facteur 2×. La variable dominante reste le scaffold.

CORE-Bench (Princeton, 2024) évalue des agents sur la reproductibilité de résultats scientifiques. Avec GPT-4o, un scaffold conçu pour la tâche atteint 60 % de réussite sur les tâches faciles, contre 35,6 % pour un scaffold généraliste. Sur les tâches difficiles, l’écart se creuse : 21,5 % contre 6,7 %. Même modèle, même benchmark, même jour. Le scaffold fait la différence entre un agent utilisable et un agent aléatoire.

Ces benchmarks sont des conditions de laboratoire — les chiffres exacts ne se transposent pas directement en production, où les contextes d’exécution varient d’un déploiement à l’autre. Mais la tendance qu’ils dessinent converge avec ce que plusieurs équipes ont documenté indépendamment sur le terrain : la qualité du scaffold a plus d’impact sur le résultat que le choix du modèle.

Six mois de terrain : ce que le harness change

Les benchmarks prouvent qu’à modèle constant, le scaffold fait l’essentiel de l’écart. Le harness prolonge cet effet dans la durée. Sur mes propres workflows Claude Code depuis six mois, deux cas l’illustrent.

Le TDD comme filet de sécurité. Le vibe coding — laisser un agent IA générer du code à partir d’instructions en langage naturel — produit des résultats spectaculairement différents selon que le modèle travaille « nu » ou encadré par un cadre de tests. Un modèle nu génère du code qui fonctionne en apparence. Il compile, il tourne, il répond. Le problème se révèle deux semaines plus tard : une régression silencieuse, un cas limite non couvert, un comportement qui a changé sans que personne ne le remarque. Le même modèle, encadré par un cycle TDD strict — écrire le test d’abord, vérifier qu’il échoue, itérer le code, ne jamais modifier le test — produit du code dont la fiabilité est mesurable. Pas parfait : le TDD ne garantit pas 100% de couverture. Mais la différence entre « aucun filet » et « filet structuré » est celle entre un agent dont on espère qu’il fonctionne et un agent dont on vérifie qu’il fonctionne.

Le brief structuré comme accélérateur. Pour une maquette fonctionnelle de site web, un modèle sans scaffold produit une interface générique qui nécessite des allers-retours prolongés. Le même modèle, encadré par un scaffold de conception — brief UX/UI pour identifier les parcours et les frictions, récupération des assets graphiques, puis approche TDD via spec-kit (un kit open-source qui structure le contexte, les parcours et les contraintes pour guider un agent de développement) — arrive au résultat attendu en une à deux itérations. Il y a six mois, la même tâche me prenait une demi-journée. Le delta n’est pas dans le modèle — il est dans la chaîne d’outils qui l’encadre.

Le TDD, le brief structuré, les rules, les hooks de validation forment ensemble le harness. Chacun est une pièce du scaffold ; ce qui les rend durables, c’est leur maintenance dans le temps. Tous contraignent la nature probabiliste du modèle pour le faire passer par le chas de l’aiguille — comme un canon à particules qui force un faisceau diffus à converger vers une cible précise.

Implications pratiques : où investir l’effort d’ingénierie

Le réflexe model-shopping a un coût d’opportunité. Chaque heure passée à comparer des benchmarks de modèles est une heure non investie dans le scaffold.

La colonne de gauche est un investissement en ingénierie. Elle produit des artefacts durables — des règles, des schémas, des pipelines de validation — qui s’améliorent avec le temps et restent utiles quand le modèle change. La colonne de droite est une consommation. Elle résout le problème du jour sans rien construire pour demain.

L’écart de coût est réel. Configurer un hook de validation prend une heure. Évaluer un nouveau modèle sur un workflow en production prend une semaine — et le résultat n’est valable que jusqu’au prochain modèle. Le harness capitalise. Le model-shopping dépense.

Pour un manager IT, la question budgétaire se reformule : l’ingénierie du harness est un investissement (elle produit des actifs réutilisables), le model-shopping est un coût opérationnel récurrent (il recommence à chaque release de modèle). Les équipes qui ont compris investissent dans le scaffold d’abord.

Ce que cette perspective ne voit pas

Le harness n’est pas éternel. Et c’est l’objection la plus sérieuse contre cette thèse.

Les modèles progressent vite. Le fossé entre les modèles « thinking » et la génération précédente est considérable. Ce qu’un modèle de 2024 ne pouvait pas faire sans un cadre complexe, un modèle de 2026 le fait parfois nativement. Une partie du harness devient du code mort à chaque saut de génération.

C’est vrai. Et c’est un mécanisme sain. Quand une nouvelle génération de modèle sort, il faut vérifier quels défauts ont disparu, lesquels persistent, et ajuster le cadre — lâcher la bride là où le modèle a gagné en fiabilité, renforcer là où de nouvelles capacités créent de nouvelles zones d’incertitude (ce qu’on découvre seulement après quelques jours, semaines d’utilisation).

Mais l’argument « attendons le prochain modèle » repose sur un malentendu. C’est ici que la distinction scaffold/harness compte. La couche qui compense les faiblesses du modèle — le scaffold au sens étroit — meurt effectivement à chaque saut de génération. Exemple concret : le méta-prompting. Il y a deux ans, une part significative du travail d’ingénierie consistait à écrire des méta-prompts — des prompts pour améliorer les prompts. Avec les modèles « thinking », cette couche a largement disparu. Dans mon usage, le mode conversationnel couvre aujourd’hui environ 80 % des cas courants ; il y a deux ans, il en couvrait à peine 20 %. Le méta-prompting résiduel ne sert plus que pour les cas particulièrement difficiles. C’est d’ailleurs pour cette raison que le « métier » de prompt engineer n’a pas eu le temps de s’installer — le besoin s’est résorbé plus vite que la compétence ne s’est constituée.

Mais la couche qui encode les contraintes métier — la validation des outputs, le partitionnement du contexte, les gates de qualité, le cycle TDD — cette couche, le harness au sens propre, survit parce qu’elle ne dépend pas du modèle. Elle dépend du problème.

Tant que les modèles resteront probabilistes — ce qui, disons, n’est pas pour tout de suite — l’habitude intellectuelle qui consiste à les encadrer sera une compétence structurante. Les techniques évolueront. La discipline restera.

Certaines tâches nécessitent par ailleurs des capacités de raisonnement que le scaffold ne compense pas — problèmes mathématiques complexes, analyse multimodale poussée, code dans des langages très rares. Le harness ne remplace pas la puissance brute. Mais la règle pratique tient : si le meilleur modèle disponible échoue avec un scaffold bien conçu, c’est probablement une limite du modèle. Dans tous les autres cas — la grande majorité — chercher d’abord du côté du cadre.

Ce que ça change concrètement

Un développeur qui construit des agents a intérêt à investir dans le cadre — scaffold immédiat puis harness durable, avec rules, hooks et boucles de validation — avant d’évaluer les modèles. Le delta SWE-bench (23 % → 48 %) montre que le scaffold a plus de levier que le modèle ; le harness prolonge cet avantage d’un trimestre à l’autre. Quand un nouveau modèle sort, la bonne question n’est pas « est-il meilleur ? » mais « quelles contraintes de mon scaffold sont devenues inutiles, et quelles nouvelles zones dois-je encadrer ? ».

Un consultant qui entend « notre agent ne fonctionne pas bien » a un réflexe à acquérir : auditer le scaffold avant de toucher au modèle. Neuf fois sur dix, le problème est une instruction ambiguë, un contexte surchargé ou une absence de validation. Le diagnostic « harness-first » est un cadre réutilisable d’une mission à l’autre.

Côté budget, la distinction est nette : l’ingénierie du harness produit des actifs (règles, pipelines, schémas de validation), le model-shopping produit une évaluation périmée au prochain trimestre.

Pour quelqu’un qui débute, la compétence qui aura le plus de valeur dans deux ans n’est pas la maîtrise d’un modèle spécifique — les modèles changent tous les trimestres. C’est la capacité à concevoir le scaffold qui rend n’importe quel modèle fiable dans un contexte donné.

Ce que j’en retiens

Le modèle est interchangeable. Le harness, lui, encode vos décisions métier.

Au rythme où les modèles changent, faire du model-shopping, c’est prendre le risque de laisser partir les trains sans monter à bord parce qu’on attend le plus rapide. Une équipe qui passerait tout son temps à évaluer le « meilleur modèle du trimestre » ne livrerait rien. L’habitude de construire et d’améliorer le harness en permanence n’empêche pas la sortie de route — mais elle en limite la probabilité et l’impact.

D’ici fin 2027, l’écart sera visible sur le time-to-production. Les équipes scaffold-first livreront plus vite et avec moins d’itérations parce qu’elles capitaliseront sur cet actif. Celles qui font du model-shopping recommenceront l’évaluation à chaque release. Le harness engineering est une discipline à part entière — et elle commence à peine à être nommée.