Better Harness : l’outil de Qoder pour auditer les workflows des agents de code

Better Harness est un projet open source de Qoder conçu pour examiner et améliorer le workflow qui entoure un agent de programmation. L’idée n’est pas d’évaluer une réponse isolée du modèle ou un unique diff de code, mais d’observer l’ensemble du dispositif : consignes du dépôt, règles, outils, permissions, scripts, tests, contrôles de livraison et, lorsqu’elles sont disponibles, traces de sessions réelles. L’objectif est d’identifier des failles de processus, de proposer une correction limitée et de pouvoir en vérifier l’effet lors d’une analyse ultérieure. 124

Qoder a annoncé l’ouverture du projet sur GitHub le 28 juillet 2026, selon les informations publiées à cette période. 5

Évaluer le cadre de travail, pas seulement le modèle

Un agent de code ne travaille jamais seul : il opère dans un environnement composé de documentation du dépôt, de spécifications, d’outils, de contrôles d’accès, de tests, de revues humaines et de mécanismes de mise en production. Qoder désigne cet environnement par le terme harness, que l’on peut comprendre comme le cadre opérationnel de l’agent. Il peut notamment inclure des instructions de dépôt, des règles, des compétences (skills), des hooks, des plugins, des connecteurs, des scripts, des commandes de test, des vérifications de livraison et des étapes de revue humaine. 2

Cette distinction est importante : même un modèle performant peut produire des résultats peu fiables si les attentes sont ambiguës ou si le workflow est mal instrumenté. Un dépôt peut contenir une commande de test sans indiquer clairement à quel moment l’agent doit l’exécuter. Il peut aussi disposer d’un fichier de règles que l’agent n’utilise jamais. Better Harness cherche donc les faiblesses opérationnelles, plutôt que de considérer qu’un simple fichier de configuration prouve l’existence d’un processus efficace. 145

Les trois couches du cadre Better Harness

Qoder présente Better Harness comme un cadre à trois niveaux : des pratiques d’ingénierie, un modèle d’évaluation et une implémentation utilisable dans des projets réels. 5

1. Les pratiques de Harness Engineering

La première couche couvre les mécanismes concrets qui structurent le travail d’un agent : gestion des sessions, usage en ligne de commande, observabilité, règles, compétences, configuration MCP, mémoire, hooks et automatisation. 5

Elle répond à des questions très pratiques :

• l’agent reçoit-il un objectif, des contraintes et le contexte du dépôt suffisamment clairs ?
• ses droits et ses chemins d’exécution sont-ils correctement encadrés ?
• les tests, contrôles et revues sont-ils reliés aux modifications qu’il effectue ?
• les leçons tirées d’une tâche peuvent-elles devenir des actifs durables du projet, plutôt que disparaître à la fin d’une session ?

L’analyse commence par une cartographie du harness existant : objectifs, contexte, points d’entrée d’exécution, boucles de retour, mécanismes de livraison et conservation des apprentissages. 1

2. L’évaluation de l’Agent Work Loop

La deuxième couche transforme ces pratiques en évaluation de cinq dimensions liées à la livraison : compréhension de la tâche, exécution contrôlée, validation des changements, livraison fiable et capitalisation des apprentissages. 14

La question ne devient donc plus seulement : « L’agent a-t-il produit du code crédible ? » Elle devient : le workflow de bout en bout peut-il produire de manière répétée des modifications compréhensibles, contrôlées, validées, livrables et enrichies par l’expérience passée ?

Le modèle cherche les points de rupture dans cette boucle : un mécanisme manquant, une intégration déconnectée, une étape qui n’a jamais été exécutée ou une preuve insuffisante du résultat. 1

3. Une implémentation exécutable

La troisième couche vise à rendre ces principes opérationnels, et non simplement documentaires. Better Harness s’exécute via un agent de code, collecte des preuves issues du projet et, lorsque le contexte le permet, des sessions, puis produit des améliorations priorisées et des prochaines étapes vérifiables. 4

Les documents actuels du projet mentionnent dix adaptateurs hôtes. Les informations relatives au lancement citaient notamment Claude Code, Codex, Qoder et Cursor parmi les environnements pris en charge. 56

Cette compatibilité pouvant évoluer, il convient de vérifier la documentation des adaptateurs pour un hôte précis. Les sources fournies ne permettent notamment pas d’établir une prise en charge d’OpenClaw.

Trois types de preuves, analysés séparément

L’un des éléments centraux de Better Harness est la séparation entre la collecte des éléments observables et l’évaluation finale. Qoder indique que son flux principal recueille d’abord les données brutes, puis les transmet à trois sous-agents indépendants et en lecture seule avant d’agréger les résultats. 1

Les trois perspectives sont les suivantes :

• Project Harness : les fondations d’ingénierie du dépôt, telles que les instructions, scripts, contrôles et mécanismes de livraison ;
• Agent Customization : les règles, compétences, hooks et autres réglages propres à l’agent ;
• Session Evidence : les traces de ce que l’agent a effectivement fait durant un travail réel, lorsque ces données existent.

Cette séparation permet de distinguer un processus prévu d’un processus observé. Les éléments du dépôt ou de la configuration peuvent montrer qu’une capacité est disponible ; les traces de session peuvent indiquer si elle a réellement été mobilisée de manière appropriée lors d’une tâche. 14

Avoir une capacité ne signifie pas qu’elle fonctionne

Le principe le plus utile du cadre est simple : l’existence d’un artefact ne prouve pas son efficacité.

Prenons une suite de tests automatisés. Sa présence démontre qu’un mécanisme de validation est potentiellement disponible. Elle ne démontre pas que l’agent a exécuté les tests pertinents après une modification, qu’il a interprété correctement leur résultat, ni que ce résultat a empêché une livraison défectueuse. Le même raisonnement vaut pour les règles, les hooks, les compétences ou les étapes d’approbation. 15

Les rapports de Better Harness cherchent donc à conserver une chaîne de preuve explicite. Les lacunes étayées deviennent des constats priorisés, assortis d’un impact, d’un résultat attendu, d’une correction circonscrite et de critères d’acceptation. Les éléments manquants restent visibles au lieu d’être convertis silencieusement en score rassurant. 46

Pour chaque constat, une équipe doit pouvoir examiner :

1. ce qui a été observé dans le projet, la configuration ou les traces de session ;
2. pourquoi cela pose problème dans la boucle de livraison ;
3. quelle correction ciblée est proposée — règle, compétence, hook, script, automatisation ou étape de validation humaine ;
4. comment vérifier cette correction une fois appliquée.

Une boucle d’amélioration continue

Better Harness n’est pas présenté comme un audit ponctuel. Son fonctionnement est itératif :

1. cartographier le harness actuel ;
2. détecter les points de rupture et les manques de preuves ;
3. créer une tâche de correction limitée pour un constat étayé ;
4. valider la correction à partir de critères d’acceptation définis ;
5. relancer l’analyse pour examiner les nouvelles preuves. 14

L’outil peut ainsi montrer qu’un workflow a été modifié et déterminer si de nouvelles observations justifient une meilleure évaluation. Il ne démontre pas, à lui seul, qu’une correction est la cause d’une amélioration des performances de l’agent dans tous les dépôts ou tous les environnements. Les matériaux de Qoder insistent sur les preuves observées et les limites explicites, plutôt que sur une preuve causale à partir d’une variation de score. 46

Que conclure de l’examen initial de 30 projets GitHub ?

Les informations de lancement indiquent que le cadre a été appliqué à un exercice initial portant sur 30 projets GitHub réels. 5 Il faut surtout y voir une application exploratoire du cadre, et non une démonstration contrôlée selon laquelle Better Harness améliorerait tous les agents de code ou tous les dépôts.

La documentation primaire disponible étaye le modèle de preuves, la structure des constats et la logique de correction itérative. En revanche, les sources fournies ne donnent pas assez de détails primaires pour évaluer indépendamment la sélection des 30 projets, le protocole de notation ou les résultats agrégés. Cette limite est importante lorsqu’il s’agit de comparer Better Harness à des benchmarks formels ou d’en tirer des conclusions générales sur les performances. 14

Vers une ingénierie des agents plus mesurable

L’ambition plus large de Qoder est de faire du Harness Engineering une infrastructure de qualité pour le développement logiciel assisté par IA : vocabulaire partagé, contrôles de workflow, preuves observables, dimensions de livraison comparables et cycles d’amélioration reproductibles. 12

Better Harness en propose une traduction concrète. L’outil permet aux équipes d’inspecter les conditions dans lesquelles les agents travaillent, de discuter à partir de preuves plutôt que d’impressions et de vérifier, lors d’exécutions suivantes, si une correction de workflow tient réellement ses promesses. Sa valeur n’est pas de garantir qu’une modification améliorera systématiquement les résultats, mais de rendre les workflows d’agents inspectables, discutables et réfutables. 46