Avez-vous déjà vécu cette situation ?
Le même Claude, le même GPT-4o — une personne l'utilise pour écrire 1 million de lignes de code en 5 mois, tandis qu'une autre n'arrive même pas à le faire fonctionner de manière stable pendant deux heures.
Les modèles sont identiques, mais les résultats sont diamétralement opposés.
Où se trouve le problème ?
J'ai récemment lu une série d'articles d'OpenAI, d'Anthropic, de Martin Fowler et de Phil Schmid, et j'ai constaté qu'ils parlent tous de la même chose.
Ils appellent cela le Harness Engineering.
En termes simples, il s'agit de construire un « système d'exploitation » pour votre Agent.
D'abord, comprendre ce qu'est un Harness
Phil Schmid a fait une excellente analogie dans un article de blog sur HuggingFace.
Imaginez un système d'Agent comme un ordinateur.
Le modèle est le CPU, fournissant la puissance de calcul brute. La fenêtre de contexte est la RAM, stockant temporairement les informations. L'Agent est l'application qui s'exécute par-dessus.
Alors, quel est le système d'exploitation ?
Le Harness est le système d'exploitation.
Sans OS, même le CPU le plus puissant n'est qu'une puce. Vous ne pouvez pas taper sur une puce.
De même, sans Harness, même le modèle le plus intelligent n'est qu'une boîte de dialogue. Si vous le laissez exécuter une tâche complexe pendant une heure, que se passe-t-il s'il oublie le contexte ? Qui l'empêche d'écrire du code de mauvaise qualité ? Et s'il commet une erreur sans même s'en rendre compte ?
Ce ne sont pas des problèmes que vous résolvez en « passant à un modèle plus intelligent ».
Martin Fowler a dit quelque chose qui m'a marqué : les Harnesses pourraient devenir des « modèles de service » à l'avenir. Tout comme vous démarrez un nouveau projet aujourd'hui avec un modèle de service, vous démarrerez un nouvel Agent avec un modèle de Harness.
Je pense que cette prédiction a de fortes chances de se réaliser.
Pourquoi cela explose-t-il soudainement en 2026 ?
Parce que les modèles sont désormais suffisamment puissants.
En 2024, tout le monde rivalisait pour savoir quel modèle était le plus intelligent. En 2026, l'écart entre les modèles de premier plan est devenu très faible. Si vous donnez le même problème à Claude et à GPT, leurs scores ne diffèrent que de quelques points.
Mais si vous les laissez travailler pendant 8 heures d'affilée, l'écart apparaît.
Cet écart ne réside pas dans le modèle lui-même ; il réside dans le « harnais » qui l'entoure.
L'équipe Codex d'OpenAI a une statistique stupéfiante. Ils ont utilisé Codex pour construire un produit complet — 5 mois, 1 million de lignes de code, zéro ligne écrite à la main. Tout au long du processus, ils ont constaté que le goulot d'étranglement n'était plus « le modèle peut-il écrire du code ? »
Le goulot d'étranglement était de savoir si les humains pouvaient relire le code assez rapidement.
La vitesse de sortie du modèle a dépassé la vitesse de relecture humaine. À ce stade, à quoi sert d'optimiser le modèle ? Vous devriez optimiser le processus de relecture, le contrôle qualité et les contraintes architecturales.
C'est ce que fait le Harness.
Les trois piliers
Alors, que contient réellement un Harness ?
Après avoir lu ces articles, j'ai constaté que, bien que les termes varient, il y a trois piliers fondamentaux.
1. Boucle d'évaluation fermée
C'est ce sur quoi Anthropic insiste le plus.
L'idée centrale est simple : Un Agent ne peut pas s'évaluer lui-même.
Pensez-y : si un stagiaire termine un rapport et que vous lui demandez comment il s'en est sorti, il dira « c'est correct ». Vous avez besoin d'une personne indépendante pour évaluer.
Anthropic appelle cela le « Développement piloté par l'évaluation ». D'abord, définissez ce à quoi ressemble un « bon travail », puis laissez l'Agent le faire, et enfin, faites évaluer par un évaluateur indépendant.
Le développement piloté par l'évaluation est la version Agent du TDD. Écrivez d'abord les tests, puis le code. Sauf qu'ici, les « tests » sont pour l'Agent.
L'évaluateur ne regarde pas seulement le code. Il utilise réellement le produit — en utilisant Playwright pour cliquer sur des boutons, remplir des formulaires et exécuter des tests — puis juge en fonction de critères clairs.
Il y a un cas fascinant ici.
L'Opus 4.5 d'Anthropic a trouvé une faille dans une politique de réservation lors d'un test de réservation de vol, trouvant une solution meilleure que la réponse standard.
Mais l'évaluateur l'a marqué comme un « échec ».
Pourquoi ? Parce que l'évaluateur ne s'attendait pas à une solution aussi créative. Il n'y avait qu'une seule réponse standard, et parce que l'Agent en a trouvé une meilleure, il a été pénalisé.
Cette histoire montre deux choses : premièrement, les Agents sont assez intelligents pour trouver des solutions auxquelles les humains n'ont pas pensé. Deuxièmement, la boucle d'évaluation ne vérifie pas seulement l'Agent ; elle vérifie aussi l'évaluation elle-même. Si votre évaluateur est trop rigide, il devient le goulot d'étranglement.
Autre donnée : Opus 4.5 a initialement obtenu un score de 42 % sur CORE-Bench. Après avoir corrigé les bugs de notation et assoupli les contraintes du scaffold, le score est passé à 95 %.
Souvent, ce n'est pas que le modèle n'est pas assez bon ; c'est que votre Harness a des problèmes.
En utilisant cette méthode, Anthropic a fait construire un jeu complet par un Agent en 6 heures pour 200 $.
2. Contraintes architecturales
C'est la spécialité de l'équipe Codex d'OpenAI.
Vous dites à un stagiaire « le code doit être en couches », il acquiesce, puis écrit immédiatement la logique d'interface utilisateur dans la couche de base de données.
Parler ne sert à rien.
L'approche d'OpenAI est de l'appliquer mécaniquement via des linters et l'IC. Le code qui enfreint les règles architecturales est immédiatement rejeté, sans même passer par une relecture.
Leur stratification du code ressemble à ceci : Types → Config → Service → UI. Chaque couche ne peut dépendre que de la couche supérieure, jamais l'inverse. Cette règle n'est pas seulement écrite dans un document ; elle est écrite dans un linter pour une vérification automatique.
Encore mieux, ces linters sont eux-mêmes générés par Codex.
L'Agent écrit ses propres règles, puis les suit.
Martin Fowler a dit, après avoir lu l'article d'OpenAI :
« Accroître la confiance et la fiabilité nécessite de contraindre l'espace des solutions. Cela signifie renoncer à une partie de la flexibilité de « générer n'importe quoi ». »
Plus il y a de contraintes, plus c'est fiable.
Cela semble contre-intuitif, mais les données parlent d'elles-mêmes. LangChain a fait une expérience : sans changer le modèle, en changeant uniquement le Harness, le taux de réussite de Terminal Bench 2.0 est passé de 52,8 % à 66,5 %. Vercel est allé plus loin, en supprimant 80 % des outils de l'Agent, ce qui a entraîné moins d'étapes, des vitesses plus rapides et de meilleurs résultats.
Moins d'outils conduisent souvent à de meilleures performances — cette conclusion a été vérifiée à plusieurs reprises dans le domaine des Agents.
3. Gouvernance de la mémoire
Ce pilier est moins discuté, mais je pense qu'il est le plus important à long terme.
PrismerCloud a fait un travail approfondi dans cette direction.
Le problème est le suivant : lorsque plusieurs Agents partagent une base de connaissances, l'Agent A écrit une expérience, et l'Agent B la lit comme une vérité. Mais que faire si l'Agent A s'est trompé ?
L'hallucination d'un Agent peut polluer tous les Agents via la base de connaissances partagée.
L'approche de PrismerCloud consiste à construire un « Moteur d'évolution ». Chaque expérience d'Agent est d'abord enregistrée comme un « signal ». Une fois vérifiée, les signaux sont distillés en « gènes », qui sont continuellement optimisés en fonction des résultats réels.
En termes simples, les gènes sont des connaissances vérifiées et efficaces. Si ce n'est pas vérifié, cela ne compte pas.
Il y a une statistique intéressante : 3 lignes d'invite plus un système de mémoire fonctionnent à peu près aussi bien que 200 lignes d'invites expertes soigneusement conçues. De plus, le premier évolue, tandis que le second est statique.
Cela signifie que si votre système de mémoire est bon, vous n'avez pas besoin d'invites complexes. L'Agent s'améliorera naturellement avec le temps.
Bonus : Résistance à l'entropie
Ce n'est pas un pilier indépendant, mais cela mérite d'être mentionné.
Les systèmes d'Agents se dégradent naturellement avec le temps. Les documents expirent, les architectures sont contournées, et les bases de connaissances se remplissent d'informations obsolètes.
L'approche d'OpenAI consiste à exécuter périodiquement un « Agent de refactorisation » pour rechercher les incohérences documentaires et les violations architecturales. Ils l'ont dit le mieux :
« Lorsqu'un Agent a des difficultés, nous le traitons comme un signal : trouvez ce qui manque, réinjectez-le dans la base de code, et laissez toujours Codex écrire le correctif. »
Lorsqu'un Agent a des problèmes, ne vous contentez pas de réparer l'Agent — réparez le Harness. Cet état d'esprit est essentiel.
Qui fait cela ?
Le domaine est divisé en deux voies : les projets open source que vous pouvez utiliser dès aujourd'hui, et les pratiques internes des entreprises commerciales dont vous ne pouvez qu'apprendre la méthodologie.
Projets Open Source : Prêts à l'emploi
LangChain DeepAgents : Probablement le projet open source le plus proche d'un « Claude Code universel ». Planification, opérations sur les fichiers, délégation de sous-agents, compression automatique du contexte — prêt à l'emploi. 115 000 étoiles sur GitHub.
DeerFlow 2.0 : De ByteDance. Open-sourcé en mars, il a atteint 39 000 étoiles en un mois. Il se présente comme un « SuperAgent Harness ». C'est une réécriture complète de la v1 avec exécution en bac à sable, mémoire persistante et systèmes de compétences basés sur LangGraph.
OpenHands : Spécialisé pour les Agents de codage. Il a atteint 77,6 % sur SWE-bench Verified. Il est indépendant du modèle et utilise Laminar pour l'observabilité, traçant chaque action de l'Agent.
SWE-agent : De Princeton et Stanford. Il se concentre sur la perfection du développement « piloté par l'évaluation ».
Goose : Open-sourcé par Block (Square/Cash App). Un Agent général sur machine qui peut installer des dépendances, exécuter des tests et gérer des fichiers.
PrismerCloud : Se concentre sur la gouvernance de la mémoire et le moteur d'évolution. C'est la solution la plus mature pour empêcher la pollution par les hallucinations dans les systèmes multi-agents.
Cognee : Un moteur de mémoire piloté par un graphe de connaissances pour les Agents qui aide à établir des connexions sémantiques entre les données.
Pratiques Commerciales : Apprendre la méthodologie
Claude Code + Agent SDK : La référence d'Anthropic pour un Harness général. Il n'est pas seulement utilisé pour le codage ; ils l'utilisent pour la recherche, la création vidéo et la prise de notes.
OpenAI Codex : La pratique ultime en matière de contraintes architecturales. 1 million de lignes de code sans aucune écriture manuelle, reposant sur des linters auto-générés et des relectures par les pairs des Agents.
Une leçon qui m'a marqué
Rich Sutton a écrit un article classique intitulé « The Bitter Lesson ». L'essentiel est que les méthodes générales exploitant le calcul surpassent toujours, à long terme, les méthodes spécifiques conçues par l'homme.
Cette leçon se vérifie à nouveau dans le domaine des Agents.
Manus a refactorisé son Harness 5 fois en 6 mois. LangChain a réarchitecturé 3 fois en un an. Vercel a supprimé 80 % de ses outils.
Construire pour détruire.
La « logique intelligente » que vous écrivez aujourd'hui pourrait être obsolète demain lorsque le modèle sera mis à niveau. Votre architecture doit être modulaire et prête à être abandonnée.
Phil Schmid a dit quelque chose qui mérite d'être retenu :
« L'avantage concurrentiel n'est plus l'invite ; ce sont les trajectoires capturées par votre Harness. Chaque succès et chaque échec sont des données pour former la prochaine génération. »
Plus votre Harness fonctionne longtemps et plus il accumule de trajectoires, plus votre Agent devient puissant. Vous ne pouvez pas rattraper votre retard en changeant simplement de modèle.
Les trois étapes
Considérez la place du Harness dans l'ingénierie de l'IA de cette manière.
L'ingénierie des invites résout « quoi dire ». Une interaction unique.
L'ingénierie du contexte résout « quoi savoir ». Fournir des références et un historique.
L'ingénierie du Harness résout « comment travailler en continu, de manière stable et à grande échelle ». Les boucles d'évaluation garantissent la qualité, les contraintes architecturales garantissent les règles, et la gouvernance de la mémoire garantit l'accumulation d'expérience.
Sans Harness, un Agent peut se souvenir des choses mais n'a aucune supervision, ce qui mène au chaos. Lorsque les trois couches sont en place, vous avez un personnage qui peut vraiment travailler à long terme.
OpenAI, Anthropic et LangChain le font déjà.
Sources : OpenAI Harness Engineering, Anthropic Demystifying Evals, Phil Schmid (HuggingFace) The Importance of Agent Harness in 2026, Martin Fowler Harness Engineering, LangChain Agent Frameworks.
