Axel Vincent
FREN
← Écrits

Harness engineering : la performance des agents de code est un problème d'environnement

25 mars 2026 · 10 min de lecture

IAIngénierieLeadership

La plupart des équipes corrigent la sortie de leurs agents en écrivant de meilleurs prompts. Plus d'instructions, plus d'exemples, plus de contraintes entassées dans un AGENTS.md ou un CLAUDE.md. Ça ne marche presque jamais. Ajouter des instructions ne règle pas le problème : ça ajoute seulement du signal que le modèle doit pondérer contre tout ce qu'il a appris des dépôts publics.

La solution n'est pas un meilleur prompt. C'est un meilleur environnement.

Le harness engineering, c'est la pratique consistant à construire l'infrastructure — types, tests, règles de lint, observabilité, boucles de feedback — qui contraint et guide les agents de code depuis l'extérieur. Plutôt que de dire à l'agent quoi faire, on conçoit l'environnement pour qu'il se corrige lui-même via sa propre chaîne d'outils. OpenAI a construit un produit d'un million de lignes de cette façon : zéro ligne écrite par un humain, livrée à de vrais utilisateurs. Leur constat a été immédiat : « Les premiers progrès ont été plus lents que prévu, non parce que Codex en était incapable, mais parce que l'environnement était sous-spécifié. » Le travail principal de leur équipe d'ingénierie est devenu la construction de l'infrastructure qui rend une bonne sortie automatique.

Vous avez déjà résolu ce problème#

Tout CTO, tout ingénieur a déjà intégré un développeur junior. Personne ne lui écrit un document de dix pages avant de partir.

On construit un environnement dans lequel le junior peut livrer sans danger. Des tickets clairs, au périmètre bien défini. Des vérifications automatiques qui attrapent les erreurs avant la revue de code. L'accès aux outils qui lui permettent de vérifier son propre travail. Une base de code structurée de telle sorte que faire les choses correctement soit plus simple que l'inverse.

C'est exactement ça, le harness engineering. Le mode d'emploi est identique. L'agent est simplement plus rapide, moins cher et infatigable. Ce qu'il partage avec le junior, c'est la limite de fond : de la compétence sans jugement.

La métaphore du développeur junior se traduit directement en décisions d'infrastructure :

  • Système fortement typé : le code ne compile pas si l'agent se trompe de forme de données
  • Tests : comment l'agent sait-il qu'il a fini ? Les tests lui donnent une définition du « terminé » qu'il peut vérifier
  • Règles de lint avec messages de remédiation : des garde-fous que l'agent peut lire et exploiter
  • Observabilité et logs : l'agent peut se débugger lui-même
  • Accès navigateur (Playwright, Chrome DevTools) : l'agent peut voir ce qu'il a construit. Sans ça, le travail front-end se fait à l'aveugle
  • Tickets petits et détaillés. Moins de périmètre, moins de jugement requis
  • Couches d'architecture imposées : un sens de dépendance que l'agent ne peut pas enfreindre

Personne ne pilote un junior en lui tendant tout le backlog en espérant que ça passe. On cadre le travail, on automatise les vérifications, et on s'assure qu'il a les outils pour valider sa sortie avant qu'elle n'arrive jusqu'à vous. Les agents ont besoin de la même structure. Non parce qu'ils sont incompétents, mais parce qu'il leur manque le jugement nécessaire pour repérer qu'ils dérivent.

Les frontières qui comptent#

Le harness engineering n'est pas un outil unique. C'est un ensemble de frontières, chacune fermant un mode de défaillance.

Elles se répartissent en trois catégories : les frontières qui empêchent les mauvaises sorties, celles qui permettent à l'agent de vérifier son propre travail, et celles qui cadrent le travail pour que les erreurs restent contenues.

Empêcher les mauvaises sorties#

Le coût de l'absence de ces frontières est mesurable. Les agents produisent davantage de bugs. Toutes les équipes avec lesquelles j'ai travaillé ont les données pour le prouver. CodeRabbit l'a quantifié sur 470 dépôts GitHub : 1,7 fois plus de bugs que les humains au global, 75 % d'erreurs de logique et de correction en plus. Les opérations d'entrées/sorties excessives étaient 8 fois plus nombreuses dans le code généré par IA.

La recherche de CodeScene affine le seuil : l'IA est à son meilleur dans des bases de code dont le score de Code Health atteint 9,5 ou plus. En dessous, « l'IA opère en mode auto-destructeur, écrivant souvent du code qu'elle ne saura pas maintenir de façon fiable par la suite ». Ce ne sont pas des défaillances de modèle. Ce sont des défaillances d'environnement.

À quoi ressemble la prévention, concrètement ? L'agent se trompe sur une forme de données. Le code ne compile pas. Fin de l'histoire. Aucune ambiguïté, aucun prompt nécessaire. Le vérificateur de types le rejette avant même la première exécution. C'est pour cette raison qu'OpenAI impose le parsing aux frontières sur chaque forme de données entrant dans le système : l'agent choisit comment valider, mais la validation n'est pas négociable.

Les types attrapent les erreurs de forme. Les règles de lint attrapent tout le reste de ce qui est analysable statiquement : une requête base de données dans la mauvaise couche, une route sans middleware de validation, une variable d'environnement lue en dehors du fichier de configuration. Le choix de conception décisif : le message d'erreur est écrit pour l'agent. Il est chirurgical, cadré et actionnable. L'agent le lit, se corrige, et poursuit. Coût nul en fenêtre de contexte tant que la règle ne se déclenche pas. J'ai traité ce motif en détail dans un article précédent.

Les couches d'architecture imposées — des sens de dépendance stricts, validés par des linters et des tests structurels — limitent ce que l'agent peut atteindre. La base de code d'OpenAI impose un modèle en couches rigide par domaine métier (Types → Config → Repo → Service → Runtime → UI), avec pour seules exceptions des interfaces transverses explicites. C'est cette contrainte qui autorise la vitesse sans dérive architecturale.

Permettre à l'agent de vérifier son propre travail#

Un agent capable de contrôler sa propre sortie n'a pas besoin d'un humain dans la boucle à chaque itération.

Le mode de défaillance le plus courant est d'une simplicité trompeuse. LangChain a observé que les agents écrivaient une solution, relisaient leur propre code, confirmaient que « ça a l'air bon », et s'arrêtaient là. Ajouter des consignes de vérification — compiler, lancer les tests, comparer à la spécification, corriger — a radicalement changé le résultat. Les modèles sont d'excellentes machines à s'améliorer, mais ils n'ont aucune tendance naturelle à entrer dans la boucle construire-vérifier. C'est le harness qui les y pousse.

Le système Honk de Spotify le confirme à grande échelle. En faisant tourner des agents en arrière-plan sur des milliers de composants logiciels, ils ont construit des vérificateurs déterministes doublés d'une couche de jugement par LLM. Ce juge oppose son veto à environ 25 % des sessions d'agents. Une fois signalés, les agents se corrigent d'eux-mêmes dans la moitié des cas environ. Leur conclusion est sans détour : « Sans ces boucles de feedback, les agents produisent souvent du code qui, tout simplement, ne fonctionne pas. »

OpenAI a branché logs, métriques et traces sur son runtime d'agents via une pile d'observabilité locale, éphémère par worktree, interrogeable en LogQL et PromQL. Avec ce contexte disponible, des prompts du type « assure-toi que le démarrage du service tient sous 800 ms » deviennent traitables. Sans lui, l'agent est aveugle à tout ce qui se passe après la compilation.

La même logique vaut pour la couche visuelle. Branchez Playwright ou le Chrome DevTools Protocol, et l'agent peut lancer l'application, prendre des captures, les comparer aux maquettes, et itérer. Une boucle de QA complète, sans œil humain.

Cadrer le travail#

Un essai randomisé a montré que des mainteneurs open source expérimentés étaient en réalité 19 % plus lents avec l'IA, tout en étant convaincus d'être 20 % plus rapides. Un écart de perception de 39 points. Une autre étude n'a vu que 8 % des invocations agentiques aboutir à une pull request fusionnée.

Une étude UCSD/Cornell a synthétisé ces résultats. Leur conclusion centrale : les développeurs professionnels qui obtiennent des résultats déploient des stratégies de contrôle explicites. Ils planifient, ils supervisent, ils valident. Les agents fonctionnent sur des « tâches petites, directes, bien définies » et échouent sur des « tâches complexes exigeant une connaissance du domaine ».

Ce n'est pas une limite à contourner. C'est une contrainte avec laquelle concevoir. Des tickets petits et détaillés limitent le rayon d'explosion. Plus le ticket est cadré précisément, moins l'agent a besoin de jugement. Un monorepo aide également : tout est trouvable au même endroit, sans avoir à deviner où vit le code ni comment les packages s'articulent.

Mais certains travaux ne peuvent pas être découpés assez petit. Les décisions d'architecture qui traversent tout le système, la résolution de problèmes inédits où la bonne réponse n'est pas encore claire, les refactorisations transverses qui touchent à tout. Ceux-là demandent encore un humain aux commandes. Le harness ne supprime pas le besoin de jugement. Il le concentre là où il compte vraiment.

D'abord les frontières, ensuite la délégation#

Symphony, l'orchestrateur d'agents open source d'OpenAI, l'annonce sans détour dans son README : « fonctionne au mieux dans des bases de code ayant adopté le harness engineering ». Symphony interroge un gestionnaire de tickets, crée des espaces de travail isolés par ticket, et exécute les agents de code en autonomie. Sans harness, il ne ferait qu'envoyer des agents dans le chaos.

OpenAI rapporte des exécutions uniques de Codex travaillant sur une seule tâche pendant plus de six heures, souvent pendant que les humains dorment. L'agent valide la base de code, reproduit un bug, implémente un correctif, pilote l'application pour le vérifier, ouvre une PR, répond aux retours, et fusionne le changement. Ce niveau d'autonomie ne tient que parce que le harness rattrape ce que l'agent ne voit pas.

Avant de systématiser tout cela, OpenAI passait 20 % de chaque semaine d'ingénierie à nettoyer de la « bouillie IA ». Une fois leurs standards encodés dans des linters, des tests structurels et des refactorisations récurrentes pilotées par des agents, ce nettoyage est devenu automatique. Le harness n'a pas seulement amélioré la qualité de sortie. Il a récupéré le temps humain qui partait en supervision.

La discipline a changé de place#

Construire du logiciel exige toujours de la discipline. Mais la discipline a changé de place.

Elle n'est plus dans l'écriture du code. Elle est dans l'échafaudage, les boucles de feedback, les contraintes qui maintiennent la cohérence d'une base de code pendant que des agents génèrent des milliers de lignes par jour. Les meilleurs managers ne micro-gèrent pas la production. Ils construisent des systèmes où une bonne production est le comportement par défaut. Ils cadrent le travail clairement, automatisent les vérifications, donnent à leur équipe les outils pour valider ses propres résultats, et imposent les frontières qui comptent tout en laissant de l'autonomie à l'intérieur.

Les agents de code ont besoin exactement de la même chose. Pas de meilleurs prompts. Pas de meilleurs modèles. D'un meilleur environnement — un environnement où faire les choses correctement est plus simple que l'inverse.

Ne confondez pas un bon harness avec un pilote automatique. C'est toujours vous qui décidez de ce qui se construit, et pourquoi. Mais concevez l'environnement, et l'agent suivra.

Si vous mettez ces pratiques en place dans le flux de travail de votre équipe, j'écris régulièrement sur le sujet. Suivez-moi sur @AxelVincent_ et écrivez-moi si vous voulez en parler.

Références#