Harness IA : mesurer les gains au-delà du bruit
Une étude sur 447 tâches montre que les écarts entre harness IA peuvent relever du bruit. Apprenez à mesurer score, coût et fiabilité avant de migrer.
Harness IA : mesurer les gains au-delà du bruit
Changer de harness IA améliore-t-il vraiment un agent ?
Quand un agent d'IA réussit plus de tâches après une mise à jour, ce n'est pas toujours le "modèle" qui a progressé. Le harness peut avoir bougé aussi : les instructions, les outils disponibles, ou même la façon dont le contexte est géré. Et même si rien n'a changé sur le papier, une nouvelle exécution peut donner un résultat différent.
Une étude basée sur 447 tâches aide à remettre ça en perspective. En rejouant une configuration identique, les auteurs voient que le résultat change sur 13 % des tâches. Changer de harness produit un taux de bascule du même ordre. Autrement dit : si on compare deux scores sans mesurer le bruit des relances, on risque de conclure trop vite.
Voici ce que l'étude a testé, ce qu'on peut en tirer sur les performances et les coûts, et une façon simple d'évaluer un changement de harness avant de le mettre en production.
Ce que l'étude a réellement comparé
Un harness, c'est la couche qui encadre un modèle pendant l'exécution : instructions système, outils fournis, format des échanges et gestion du contexte. Deux équipes peuvent donc utiliser le même modèle et obtenir des comportements différents si les outils ou les règles d'exécution ne sont pas les mêmes.
L'étude « What Does a Harness Buy? Tokens, Mostly », publiée en prépublication par Yangze Liu et Zhongyi Han, compare trois harness : Claude Code, mini-SWE-agent et OpenCode. Claude Code est le plus "lourd" : un préambule assez long, des outils typés pour manipuler des fichiers et faire de la recherche, et une compaction automatique du contexte. mini-SWE-agent est volontairement plus léger : un outil bash et peu de gestion de contexte. OpenCode se place au milieu : outils typés et préambule plus court.
Les chercheurs testent cinq modèles sur SWE-bench Verified, un benchmark constitué de problèmes issus de dépôts GitHub et vérifiés par des tests. Après exclusion de huit tâches dépendant de services externes, il reste 492 tâches. Deux modèles sont évalués sur un ensemble de 447 tâches, et les cinq modèles sont aussi évalués sur un sous-ensemble de 45 tâches difficile. Claude Opus 5, utilisé comme référence haute, n'apparaît que dans Claude Code.
Le détail méthodologique qui compte le plus, même s'il est moins visible que le classement des outils : les auteurs refont dix fois des exécutions avec le même modèle, le même harness, les mêmes tâches et les mêmes réglages. Cette répétition sert à estimer la variabilité d'une relance à l'autre. Sans ça, quand deux configurations diffèrent de quelques points, on ne sait pas si le harness a vraiment changé quelque chose ou si on observe simplement le caractère non déterministe des exécutions.
Enfin, c'est une prépublication, non évaluée par les pairs, sur une famille de benchmark et trois outils. Le résultat est utile pour orienter des décisions, mais ce n'est pas une règle universelle valable pour tous les agents et tous les contextes.
Pourquoi le harness change aussi la facture
Le harness ne décide pas seulement ce que l'agent "peut" faire. Il influence aussi la quantité de tokens envoyés au modèle à chaque étape, donc le coût.
Dans l'étude, à modèle et tâches identiques, le coût par tâche varie jusqu'à un facteur trois selon le harness. La différence se voit dès le premier appel : chaque interaction inclut généralement un préambule "fixe" (instructions système, description des outils et règles de fonctionnement). Les auteurs mesurent environ 16 000 tokens pour Claude Code, 7 000 pour OpenCode et moins de 1 000 pour mini-SWE-agent. Ensuite, les tokens des sorties d'outils et la croissance du contexte ajoutent aussi de la dépense, mais moins que cette base répétée.
En pratique, le coût du préambule dépend du nombre d'étapes. Si un agent fait vingt appels, il renvoie des instructions presque identiques vingt fois. Au final, le coût ne dépend donc pas uniquement de la difficulté ou du prix par million de tokens : il dépend aussi du nombre d'itérations, de la longueur du contexte, et de la façon dont le fournisseur facture réellement l'entrée et la sortie.
Du coup, une comparaison uniquement basée sur le taux de réussite est fragile. Si deux harness donnent des résultats dans une marge similaire, mais que l'un coûte trois fois plus cher par tâche, alors la "complexité" doit apporter un bénéfice opérationnel clair : éviter des échecs coûteux, réduire les interventions humaines, ou améliorer la sécurité. Sinon, l'aspect "plus sophistiqué" n'est pas un argument.
Pour une équipe qui déploie des agents en production, l'indicateur utile est souvent le coût par tâche correctement résolue. Il faut aussi regarder le taux d'escalade vers un humain et le temps de résolution. Un agent moins cher à l'appel peut coûter davantage au total s'il multiplie les tentatives, ou s'il échoue sur les cas importants.
Le calcul doit intégrer réussites, échecs et reprises. Un coût moyen peut masquer le fait qu'un harness consomme beaucoup sur les tâches difficiles. Avant de trancher, segmentez par type de demande : une moyenne globale peut sembler correcte tout en cachant un poste de dépense (ou un risque qualité) concentré sur quelques catégories.
Comment évaluer un changement dans votre équipe
Avant de migrer, l'objectif est simple : séparer trois effets - la variabilité naturelle des exécutions, l'effet du harness, et l'effet du modèle. Si vous changez plusieurs éléments à la fois, vous obtenez un score, mais rarement une explication exploitable. Une bonne évaluation doit permettre de savoir ce qui a vraiment changé, et si le bénéfice vaut le coût.
1. Mesurez votre bruit de référence
Prenez un échantillon représentatif de vos tâches réelles, puis exécutez deux fois la même configuration : même modèle, même harness, mêmes consignes, mêmes paramètres. Comparez tâche par tâche, pas seulement la moyenne. Notez les réussites qui deviennent des échecs, les échecs qui deviennent des réussites, et surtout les catégories qui bougent le plus.
Une relance ne suffit pas toujours à capturer toutes les variations, mais c'est mieux qu'un essai unique. Si les enjeux sont élevés ou si les écarts attendus sont faibles, multipliez les répétitions et augmentez la taille d'échantillon. La quantité nécessaire dépend de la variabilité que vous observez et de l'écart que vous cherchez à détecter.
2. Comparez une seule variable à la fois
Pour isoler l'effet du harness, gardez le modèle et les tâches fixes. Pour isoler l'effet du modèle, gardez le harness identique. Cette discipline paraît évidente, mais dans les tests internes, on mélange souvent mise à jour du modèle, nouveau prompt, et modification des limites d'outils. Résultat : impossible d'attribuer le gain à une cause précise.
Quand un écart apparaît, vérifiez aussi les conditions d'exécution : plafond de sortie, limite de contexte, nombre d'étapes, comportement en cas de dépassement, disponibilité des outils, et politique de reprise. Un "effet harness" peut en réalité venir d'un timeout, d'une règle d'arrêt, ou d'un outil indisponible.
3. Mesurez la qualité et le coût en même temps
Pour chaque configuration, suivez au minimum : taux de résolution, bascules entre répétitions, tokens consommés, coût en euros par tâche, et taux d'intervention humaine. Ajoutez le temps de traitement si c'est important pour l'utilisateur ou pour l'exploitation.
Évitez de chercher un chiffre unique qui "efface" les compromis. Un harness plus cher peut limiter des échecs sur des tâches à forte valeur. Un autre peut être intéressant sur les demandes simples et moins adapté aux cas qui demandent une longue séquence d'outils. Le découpage par type de tâche aide à décider si une configuration suffit, ou s'il faut plutôt router vers plusieurs configurations.
4. Fixez une règle de décision avant le test
Définissez avant le test ce qui compte comme amélioration "assez grande" pour justifier une migration : seuil minimal, coût maximal acceptable, et cas où une régression est bloquante. Sans seuil, l'équipe risque de retenir après coup l'indicateur qui "tombe bien".
La règle doit aussi tenir compte des coûts de migration, de la maintenance, et des nouvelles dépendances opérationnelles.
Un repère utile : traitez tout gain inférieur à votre bruit de relance comme non prouvé. Si le gain se reproduit, cherchez ensuite le mécanisme : meilleure récupération d'erreur, gestion du contexte, fiabilité des outils, ou autre changement concret. Vous saurez alors si vous achetez une capacité utile, pas juste une différence de score difficile à reproduire.
Ce que l'étude ne permet pas de conclure
Ces résultats ne prouvent pas que l'ingénierie des harness est inutile. Le harness définit les outils, les limites et les mécanismes de récupération. L'étude montre même un cas où la gestion des sorties contribue à un écart défavorable pouvant atteindre neuf points. Le point, c'est plutôt d'exiger une preuve proportionnée au coût et à la complexité.
L'étude ne dit pas non plus que le modèle explique tout à lui seul. Dans cette expérience, changer de modèle fait basculer 22 % des tâches, plus que le changement de harness. Mais une part de la variabilité reste à comprendre. Le résultat dépend de la combinaison entre modèle, instructions, outils, contraintes d'exécution et nature des tâches.
Les limites de l'étude doivent rester visibles. C'est une prépublication, centrée sur SWE-bench Verified et trois harness. Le grand ensemble de 447 tâches concerne seulement deux modèles. Le modèle de référence fermé n'a été évalué que dans Claude Code, donc la comparaison complète est limitée. Pour OpenCode, la limite de temps sur les modèles locaux n'est pas contrôlée. Enfin, l'essai sur Terminal-Bench 2.1 ne porte que sur une migration avec un seul modèle, ce qui ne suffit pas pour généraliser à tous les agents et tous les usages.
Pour une entreprise française ou européenne, le benchmark technique ne remplace pas les contraintes de production. Confidentialité, traçabilité, et obligations RGPD peuvent peser dans le choix d'un outil. Et un gain de quelques points n'a pas la même valeur selon que l'agent aide un développeur en interne ou intervient sur un processus métier sensible.
La conclusion pratique est donc volontairement prudente : si le changement de harness améliore le score de moins d'environ cinq points, considérez le résultat comme incertain tant qu'il n'a pas été reproduit dans votre environnement. Ce seuil vient du niveau de résolution de cette étude, pas d'une règle fixe. Mesurez votre variabilité et vos tâches avant d'en faire un critère.
Conclusion : mesurer avant de migrer
Un changement de harness peut modifier le comportement d'un agent, mais un score qui bouge ne suffit pas à dire que le système s'améliore vraiment. Dans cette étude, les relances identiques et les changements de harness font basculer les résultats sur une proportion comparable de tâches. En revanche, le coût peut varier fortement selon les instructions et les outils renvoyés à chaque étape.
Avant une migration, mesurez votre bruit de référence, comparez une seule variable à la fois, et suivez le coût par tâche résolue. Si le gain est faible, reproduisez-le avant de le présenter comme un progrès. Puis identifiez le mécanisme qui le produit : c'est ce qui permet de décider si le changement mérite d'être gardé en production.
Comment interpréter les écarts de performance
Le résultat principal porte sur les bascules tâche par tâche : à relance égale, l'issue change sur 13 % des tâches (médiane). Remplacer le harness produit le même taux de bascule. Changer de modèle, lui, change davantage le résultat : 22 % des tâches basculent.
Ces chiffres ne veulent pas dire que le score global bouge de 13 ou 22 points. Une tâche réussit parfois puis échoue, et une autre fait l'inverse. Le score agrégé peut donc rester proche, même si, sur le terrain, les cas individuels changent. Pour un produit, cette nuance compte : une moyenne stable ne garantit pas que les mêmes utilisateurs (ou les mêmes catégories de demandes) bénéficient réellement du système.
Sur les 447 tâches, Claude Code et mini-SWE-agent, pourtant très différents en complexité, restent proches à cinq points près pour les deux modèles comparés. Les écarts mesurés sont de -1,8 et -1,4 point, avec des intervalles à 90 % dans une marge d'environ ± cinq points. Dans ce cadre précis, impossible de dire que l'option la plus lourde est clairement plus performante.
OpenCode, en revanche, accuse un retard qui peut aller jusqu'à neuf points sur le grand ensemble. Une partie de l'écart vient d'une limite de sortie : quand le raisonnement devient long, Claude Code pousse le modèle à continuer, alors qu'OpenCode s'arrête. Ce n'est pas la preuve que "ce" harness serait intrinsèquement meilleur partout. C'est surtout un exemple de la façon dont une règle opérationnelle peut plafonner un agent.
La taille de l'échantillon joue aussi. Avec les taux de bascule observés, 45 tâches suffisent à détecter un écart de 13 points seulement "en gros" une fois sur deux. Il faut beaucoup plus : près de 447 tâches pour départager un écart de cinq points. Même si une avance annoncée de 2,4 points peut être réelle, ce protocole ne suffit pas pour l'établir sans ambiguïté.
À retenir : un petit écart de score ne prouve pas grand-chose. Il faut le mettre en regard du bruit mesuré avec des relances identiques, puis vérifier que ça se reproduit avec un échantillon adapté.