Harness Engineering : le banc d’essai qui transforme un modèle d’IA en agent logiciel fiable

Pourtant, deux équipes peuvent utiliser le même modèle et obtenir des résultats radicalement différents. Dans une équipe, l’agent produit une fonctionnalité cohérente, respecte l’architecture, lance les bons tests et corrige ses erreurs. Dans l’autre, il modifie les mauvais fichiers, invente des conventions, génère des tests superficiels et laisse derrière lui une dette technique que quelqu’un devra payer plus tard. Le modèle n’a pas changé. Le cadre de travail, oui.

C’est tout l’enjeu du Harness Engineering, ou ingénierie du harnais. Le terme désigne l’ensemble des mécanismes qui entourent un modèle d’IA pour lui permettre de comprendre son environnement, d’utiliser des outils, de produire des changements vérifiables et de corriger ses erreurs.

Pour un développeur, cela signifie concevoir une boucle d’exécution fiable autour de l’agent. Pour une direction ou une équipe produit, cela signifie transformer une capacité de génération impressionnante en une capacité de livraison maîtrisée.

Le sujet n’est donc pas uniquement : « Quel modèle devons-nous utiliser ? » La question devient : dans quel environnement ce modèle peut-il produire du logiciel que nous sommes prêts à maintenir ?

TL;DR

• Un modèle de langage génère des propositions. Un agent agit dans un environnement.
• Le harness regroupe les règles, outils, mémoire, sandbox, tests et boucles de feedback qui encadrent cette action.
• Le prompt donne une direction ; le contexte fournit les informations ; le harnais organise le système complet.
• Les contrôles déterministes restent la première ligne de défense. Les contrôles sémantiques les complètent sans les remplacer.
• La valeur vient de la capacité à produire rapidement du code vérifiable, traçable et réversible.

1. Générer du code n’est pas encore développer un logiciel

Une démonstration d’IA donne souvent une impression trompeuse. On demande à un modèle de créer une page, une API ou un composant ; quelques secondes plus tard, le code apparaît et semble convaincant. Puis on place la même demande dans un projet réel : le dépôt contient plusieurs années d’historique, des conventions implicites, des dépendances externes, des variables d’environnement, des contraintes de sécurité et des tests qui ne s’exécutent pas tous à la même vitesse.

Dans ce contexte, produire du code n’est que le début du travail. L’agent doit comprendre la demande, identifier la partie du système concernée, vérifier les conventions, choisir les bons fichiers, parfois poser une question, modifier le code, exécuter les contrôles, interpréter les erreurs et expliquer le résultat.

Une simple complétion textuelle ne suffit pas. Un modèle de langage ne possède pas spontanément la mémoire de l’entreprise, la responsabilité du produit ou l’intuition d’un développeur qui connaît les conséquences d’une mauvaise décision. Il manipule les informations qui lui sont accessibles au moment de l’exécution. Si une règle importante n’est pas visible, elle risque de ne pas exister pour lui.

Le piège consiste alors à répondre à chaque échec par un prompt plus long. Si l’agent utilise une mauvaise commande, il faut peut-être améliorer l’outil. S’il modifie une mauvaise couche, il faut peut-être ajouter une règle d’architecture testable. S’il répète la même erreur, il faut peut-être enrichir le feedback. Le problème n’est pas toujours le raisonnement du modèle. Souvent, c’est l’absence de système autour de lui.

2. Qu’est-ce que le Harness Engineering ?

Le mot harness vient notamment de l’ingénierie physique. Dans un véhicule, un wiring harness distribue l’énergie et les signaux. Dans les tests, un test harness permet d’actionner un composant, de simuler ses dépendances et de mesurer son comportement dans un environnement contrôlé.

Le logiciel classique utilise cette logique avec des programmes appelants, des données de préparation, des bouchons de dépendances, des simulateurs, un moteur d’exécution et un système de rapport. Le composant testé croit parfois dialoguer avec une base de données ou un service distant, alors qu’il reçoit une réponse simulée et reproductible.

Avec les agents IA, la notion s’élargit : le harnais organise le travail du système qui produit le logiciel. Il détermine ce que l’agent peut voir, faire et modifier, les outils qu’il peut appeler, les contrôles qu’il doit déclencher et la manière dont les erreurs lui sont renvoyées.

Une définition opérationnelle serait donc la suivante :

Le Harness Engineering consiste à concevoir l’environnement, les outils, les règles et les boucles de contrôle qui permettent à un agent IA d’agir de manière fiable dans un système logiciel réel.

Cette définition est plus large qu’un framework d’agents : elle couvre compréhension, action, vérification, correction, traçabilité et arrêt. Dans son analyse du sujet, Martin Fowler distingue notamment le harnais intégré par le fournisseur de l’agent et celui construit par l’équipe qui l’utilise. Le dépôt, les scripts, les règles et les contrôles forment cette couche adaptée au projet.

3. Prompt Engineering, Context Engineering et Harness Engineering

Ces trois notions cherchent à améliorer les résultats d’un modèle, mais ne travaillent pas au même niveau.

Approche	Question principale	Exemple
Prompt Engineering	Que dois-on demander au modèle ?	« Ajoute une pagination à cette liste. »
Context Engineering	Quelles informations dois-on lui fournir ?	Architecture, règles métier, fichiers et documentation pertinents.
Harness Engineering	Dans quel système l’agent peut-il agir et comment vérifier son travail ?	Outils, permissions, sandbox, tests, feedback et boucles de correction.

Le prompt formule l’objectif ou le résultat attendu. Il clarifie l’intention humaine, mais ne peut pas porter à lui seul l’architecture, la procédure de déploiement, les conventions et les exceptions historiques d’un projet.

Le contexte rend disponibles les informations nécessaires : fichiers du dépôt, contrats d’API, schémas, tickets, décisions d’architecture ou erreurs précédentes. Une fenêtre remplie d’informations inutiles augmente toutefois le bruit et le coût. Le bon contexte est l’information pertinente, au bon moment, dans un format que l’agent peut parcourir et vérifier.

Le harnais organise le système de travail : ordre des opérations, permissions, outils, isolation, persistance des artefacts, contrôles, réinjection des erreurs, limites de temps et de coût, et validation humaine lorsque nécessaire.

Un prompt peut demander à l’agent de lancer les tests ; un harnais peut rendre cette étape automatique et bloquer la suite si les tests échouent. Un prompt peut demander de ne pas modifier une couche ; le harnais peut vérifier les dépendances et refuser le changement. Un prompt peut demander de ne pas utiliser de données réelles ; le harnais peut lancer l’agent dans un environnement isolé. Le prompt explique. Le harnais rend la règle observable et, lorsque c’est possible, exécutable.

4. Trois analogies pour comprendre le concept

Le simulateur de vol

Un pilote ne s’entraîne pas à une panne moteur avec des passagers à bord d’un avion de ligne. Il utilise un simulateur qui reproduit suffisamment l’environnement pour rendre l’exercice utile, tout en permettant de provoquer des situations dangereuses sans les subir dans le monde réel.

Un agent de développement peut travailler de la même manière : dépôt isolé, base de données de test, services simulés et commandes contrôlées. Il peut reproduire un bug et vérifier le comportement sans toucher à la production. Le harnais apporte ici isolation et répétabilité.

Le harnais d’attelage

Un modèle puissant ressemble à un moteur capable de produire beaucoup d’énergie, mais qui ne sait pas nécessairement où la diriger. Le harnais transmet les commandes et rend cette puissance exploitable. Sans contrôle, un agent peut enchaîner les commandes et consommer des tokens sans se rapprocher du bon résultat. L’objectif est de rendre ses actions observables, corrigeables et proportionnées.

L’atelier industriel

Imaginez un apprenti extrêmement rapide, capable de lire des milliers de pages en quelques secondes, mais qui ignore les habitudes de l’atelier, les machines fragiles et les tolérances critiques. On organise son poste, on lui donne des outils adaptés, on installe des butées, on vérifie les pièces et on lui indique immédiatement la cause d’une erreur.

Le Harness Engineering consiste à concevoir cet atelier logiciel : l’agent garde ses décisions locales, mais les erreurs coûteuses sont détectées tôt et les règles importantes ne reposent plus uniquement sur la mémoire d’un expert.

5. Anatomie d’un harnais pour agent de développement

Un harnais ne se résume pas à un fichier AGENTS.md, à un serveur MCP ou à un script de test. Ces éléments ne sont que des composants d’un système plus large.

5.1. Les guides : agir avant l’erreur

Les guides, ou contrôles feedforward, donnent à l’agent les informations et les outils qui augmentent la probabilité d’une bonne décision dès la première tentative.

On y trouve les conventions de contribution, les règles d’architecture, les critères d’acceptation, les procédures de démarrage, les commandes de test, les règles de sécurité et les contrats d’API.

Le fichier AGENTS.md est utile comme point d’entrée : où trouver les informations, comment démarrer le projet et quelles commandes utiliser. Il devient moins utile lorsqu’il se transforme en manuel interminable. Dans son retour d’expérience, OpenAI explique avoir préféré un fichier court, utilisé comme table des matières vers une base de connaissances structurée dans le dépôt.

5.2. Les outils et leurs frontières

Un agent devient opérationnel lorsqu’il peut agir. Mais chaque action augmente aussi la surface de risque : lire un fichier, consulter une API, pousser une branche ou lancer une migration ne présentent pas le même niveau d’impact.

Le harnais doit donc définir les outils et paramètres accessibles, les ressources visibles, les actions irréversibles qui nécessitent une confirmation, ainsi que les formats de sortie et journaux à conserver.

La conception d’un outil est aussi importante que le modèle qui l’utilise. Une erreur vague oblige l’agent à deviner ; un message précis, la cause probable et la commande de vérification fournissent un feedback exploitable. Une commande limitée, idempotente et testable vaut parfois mieux qu’une interface générale.

5.3. Le bac à sable et la reproductibilité

Un agent ne devrait pas toucher directement à la production pour démontrer qu’une modification fonctionne. Le harnais peut utiliser des conteneurs, des worktrees Git, des bases temporaires, des données synthétiques et des services simulés. L’objectif est de rendre le comportement suffisamment proche, contrôlé et répétable pour détecter les erreurs pertinentes.

La reproductibilité est une condition de confiance. Un harnais bien conçu permet de savoir quelle version du code a été testée, avec quelles dépendances, dans quel environnement et avec quels contrôles.

5.4. Le système de fichiers comme mémoire durable

Les agents travaillent souvent dans des boucles longues : ils planifient, explorent le dépôt, exécutent des commandes, reçoivent des erreurs et reprennent leur travail plus tard. Tout conserver dans la fenêtre de contexte est inefficace : les informations se mélangent et le coût augmente.

Le système de fichiers peut alors servir de mémoire de travail durable : plan d’exécution, journal des décisions, résultats de commandes, rapports de tests, état d’avancement, diffs intermédiaires et conclusions transmises à un sous-agent.

Cette mémoire peut être inspectée par un humain et versionnée avec le projet. Il ne s’agit pas de tout enregistrer, mais de conserver les artefacts utiles à la reprise, à l’audit et à la compréhension du travail.

5.5. Les capteurs de feedback

Les capteurs, ou contrôles feedback, observent l’action de l’agent. Ils peuvent valider le résultat, signaler une erreur ou proposer une correction : compilation, types, linter, tests, analyse de dépendances, sécurité ou frontières entre modules.

Un capteur utile ne renvoie pas seulement « échec ». Il fournit un signal compréhensible par l’agent et par l’humain. Un linter personnalisé peut indiquer la règle violée, le fichier concerné, l’exemple attendu et la commande à relancer. Sans feedback, l’agent répète ses erreurs ; sans guide préalable, il découvre trop tard des contraintes importantes. Un harnais équilibré combine anticipation et observation.

6. Deux axes de contrôle : déterministe et inférentiel

Une manière pratique d’analyser un harnais consiste à croiser le moment du contrôle et la nature de son mécanisme.

	Contrôle computationnel	Contrôle inférentiel
Avant l’action	Templates, scripts d’initialisation, règles de structure, codemods	Principes d’architecture, documentation, exemples, instructions sémantiques
Après l’action	Compilation, types, linters, tests, analyse statique, règles de dépendance	Revue par un modèle, analyse de cohérence, vérification de l’intention métier

Les contrôles computationnels

Les contrôles computationnels sont rapides, reproductibles et peu coûteux. Ils conviennent aux règles exprimables sans interprétation :

• un fichier doit respecter une syntaxe ;
• un type doit être compatible ;
• un module ne doit pas importer une couche interdite ;
• un test doit produire un résultat attendu ;
• une dépendance vulnérable ne doit pas être introduite ;
• une variable sensible ne doit pas apparaître dans le dépôt.

Ils ne savent pas toujours si la fonctionnalité répond au besoin réel. Mais lorsqu’une règle est exprimable de manière déterministe, il est préférable de la confier à une machine spécialisée plutôt qu’à un modèle probabiliste.

Les contrôles inférentiels

Les contrôles inférentiels utilisent un modèle pour analyser une intention ou une cohérence difficile à réduire à une règle formelle. Un agent critique peut chercher une incohérence métier, une solution surdimensionnée ou une divergence avec la demande.

Cette capacité ne fournit pas une garantie absolue : le modèle évaluateur peut se tromper ou manquer un problème. Il faut l’utiliser comme une couche supplémentaire, pas comme le seul arbitre.

Une bonne règle pratique est la suivante : les contrôles déterministes doivent fermer les portes qui peuvent être fermées mécaniquement. Les contrôles inférentiels peuvent aider à explorer les zones où l’interprétation humaine reste nécessaire.

7. La boucle de pilotage d’un agent

Le harnais transforme une demande en une séquence contrôlée :

1. L’agent vérifie l’état du dépôt.
2. Il identifie les documents, fichiers et outils pertinents.
3. Il reformule la tâche et signale les ambiguïtés.
4. Il produit un plan d’exécution.
5. Il réalise une modification limitée.
6. Le harnais exécute les contrôles appropriés.
7. Les erreurs sont renvoyées sous une forme exploitable.
8. L’agent corrige ou demande une décision humaine.
9. Le résultat est enregistré, présenté et éventuellement soumis à revue.

Cette boucle ressemble à un workflow classique, mais l’agent peut enchaîner les cycles de recherche, modification et vérification sans attendre une intervention après chaque commande. L’autonomie ne doit toutefois pas être confondue avec l’absence de limites : le harnais doit arrêter une boucle trop longue, limiter les tentatives, demander une validation pour une action destructive et escalader lorsque les signaux sont contradictoires.

Une boucle qui recommence indéfiniment n’est pas un agent autonome. C’est une dépense automatisée.

Le feedback réduit le travail mécanique de revue. Si l’agent détecte une erreur de typage, une violation de frontière ou un test en échec, le développeur peut se concentrer sur le besoin, l’architecture et les arbitrages.

8. Pourquoi le sujet devient stratégique pour l’entreprise

L’intérêt du Harness Engineering n’est pas de construire une machinerie complexe pour le plaisir de la complexité. Les agents réduisent le coût marginal de production du code, mais peuvent augmenter le coût de vérification et de maintenance. Il devient possible de créer plusieurs variantes, d’ouvrir de nombreuses pull requests et de lancer des tâches en parallèle. Le goulot d’étranglement se déplace : la question n’est plus seulement « Combien de lignes pouvons-nous produire ? », mais « Combien de changements pouvons-nous vérifier, comprendre et maintenir ? »

Le Shift-Left appliqué aux agents

Le principe du Shift-Left consiste à déplacer les contrôles vers le début du cycle de développement. Plus une erreur est détectée tôt, moins elle demande de contexte pour être corrigée. Une correction immédiate peut être traitée alors que l’agent possède encore le contexte de la modification ; une erreur tardive oblige à reconstruire le raisonnement.

Il faut éviter de présenter des ratios de coût comme des lois universelles : la relation dépend du projet et de la capacité de diagnostic. L’idée robuste est simple : les erreurs détectées près de leur origine sont généralement plus faciles à comprendre et moins coûteuses à corriger.

L’exemple publié par OpenAI

Dans son retour d’expérience sur un produit développé avec Codex, OpenAI indique que l’équipe a produit environ un million de lignes de code avec trois ingénieurs au départ, sans écriture manuelle de code, et estime avoir réduit le temps de construction à environ un dixième du temps conventionnel. Ces chiffres décrivent une expérience précise, pas une promesse transposable.

L’enseignement est ailleurs : les humains ont consacré leur temps à concevoir les environnements, abstractions, règles et boucles de feedback. Comme les agents peuvent reproduire des patterns imparfaits, l’équipe a ajouté une forme de « garbage collection » technique. L’IA ne supprime donc pas l’ingénierie ; elle la déplace vers le système qui rend la production de code fiable.

Les indicateurs à suivre

Une organisation devrait mesurer autre chose que les lignes produites ou les pull requests fusionnées. Des indicateurs plus utiles sont :

• le délai entre une modification et son feedback ;
• le nombre moyen d’itérations avant validation ;
• le taux de tâches terminées sans intervention humaine ;
• les régressions détectées avant intégration ;
• le coût moyen d’une tâche en tokens et en temps machine ;
• le temps consacré aux corrections de dérive architecturale.

Le bon indicateur n’est pas « l’agent a écrit beaucoup de code », mais « l’équipe livre plus vite sans augmenter le risque et la dette qu’elle devra supporter demain ».

9. Deux exemples concrets de harnais

SWE-bench : évaluer un agent dans un environnement reproductible

SWE-bench évalue la capacité de modèles à résoudre de vrais problèmes logiciels issus de dépôts GitHub. Le modèle reçoit un dépôt et la description d’un problème, produit un patch, puis celui-ci est appliqué et évalué avec les tests du projet.

Ce benchmark montre pourquoi l’évaluation ne peut pas se limiter à demander au modèle si son code semble correct. Il faut un état initial, un environnement, une procédure d’application et une méthode de validation. Le projet utilise Docker pour rendre les évaluations plus reproductibles et conserve les journaux d’exécution. Sans environnement contrôlé, un score peut refléter une différence de dépendances plutôt qu’une progression du modèle.

Dans une équipe, on peut appliquer la même logique à une échelle plus modeste : sélectionner des tâches réelles, figer un état du dépôt, définir les critères d’acceptation, exécuter les tests et conserver les traces.

Un dépôt d’entreprise rendu lisible par les agents

Un autre cas consiste à traiter le dépôt comme le système de référence de l’équipe. Les décisions importantes, les règles d’architecture, les plans d’exécution et les procédures nécessaires pour modifier le produit doivent être découvrables, versionnés et reliés au code.

Une structure possible peut ressembler à ceci :

AGENTS.md
ARCHITECTURE.md
docs/
├── design-decisions/
├── product-specs/
├── execution-plans/
├── references/
└── quality/
scripts/
├── check-architecture
├── check-docs
└── test-affected

Le fichier d’entrée reste court. Les règles détaillées se trouvent dans des documents spécialisés et des scripts vérifient les liens ainsi que les contraintes critiques. Le dépôt devient alors plus lisible pour l’agent, mais aussi pour les humains : un environnement compréhensible par une machine peut améliorer l’onboarding d’un nouveau développeur.

10. Déployer un harnais par niveaux de maturité

Ne commencez pas par une architecture gigantesque de sous-agents, de mémoire vectorielle et d’évaluateurs multiples. La maturité se construit progressivement.

Niveau 1 : rendre les règles explicites

Identifiez les règles déjà présentes dans les échanges de l’équipe : commandes, conventions, dépendances interdites, tests, décisions d’architecture et pièges connus. Documentez-les dans le dépôt, avec un propriétaire et une date de révision.

Niveau 2 : automatiser les contrôles mécaniques

Automatisez formatage, lint, compilation, types, tests rapides, secrets, dépendances et frontières de modules. Sélectionnez les contrôles qui protègent réellement le projet et rendez leurs messages compréhensibles.

Niveau 3 : isoler les tâches

Lancez les modifications agentiques dans des environnements isolés : branches ou worktrees dédiés, bases temporaires, données synthétiques et secrets minimaux. L’agent doit pouvoir échouer sans rendre l’environnement global inutilisable.

Niveau 4 : introduire la boucle de correction

Configurez l’agent pour qu’il exécute les contrôles pertinents après chaque étape significative. Renvoyez-lui les erreurs utiles, limitez les tentatives et conservez les artefacts de travail. Il est souvent plus rentable d’améliorer la qualité du feedback que d’ajouter un nouveau modèle évaluateur.

Niveau 5 : mesurer des tâches réelles

Construisez un petit jeu de tâches représentatives : ajout d’une route, correction d’une régression, modification d’un écran, migration contrôlée ou évolution d’un module. Faites-les exécuter régulièrement et mesurez les résultats.

Niveau 6 : augmenter progressivement l’autonomie

L’autonomie doit être gagnée par les preuves. Une tâche sans impact peut être automatisée plus largement qu’une migration de données ou qu’une modification de sécurité. Définissez des niveaux : proposition, exécution supervisée, pull request automatique, fusion sous conditions, puis exécution récurrente pour les tâches à faible risque. L’objectif n’est pas de supprimer l’humain, mais de le faire intervenir là où son jugement apporte une vraie valeur.

11. Les erreurs à éviter

Le fichier d’instructions interminable

Un document géant donne l’impression que l’équipe a tout formalisé, mais devient difficile à lire, maintenir et vérifier. Les informations se contredisent et les règles importantes se perdent. Préférez une entrée courte, une documentation structurée et des règles testables.

Tout confier à un autre LLM

Un agent qui écrit du code, un second qui le relit et un troisième qui valide la revue peuvent être utiles. Mais trois avis probabilistes ne deviennent pas une preuve. Les modèles évaluateurs complètent les contrôles déterministes ; ils ne remplacent ni les tests fonctionnels, ni la sécurité, ni la validation métier.

Donner trop de permissions

Un agent qui peut supprimer une base, modifier des secrets et déployer en production possède une capacité disproportionnée pour une tâche ordinaire. Les permissions doivent être limitées par environnement, par outil et par étape, et les opérations irréversibles doivent être explicites.

Mesurer la vitesse plutôt que la qualité du flux

Produire dix pull requests au lieu de deux n’est pas nécessairement un progrès. Si les développeurs passent ensuite leurs journées à comprendre, corriger et nettoyer ces changements, la productivité affichée est trompeuse. Il faut mesurer le temps de feedback, le taux de régression, le coût de reprise et la capacité à maintenir le résultat.

Croire que des tests générés prouvent la fonctionnalité

Un agent peut générer une suite de tests qui valide son propre comportement incorrect. Les tests doivent donc être relus, diversifiés et confrontés à des critères métier. Un test vert signifie que le scénario testé est vert ; pas que le produit répond automatiquement au besoin réel.

12. Ce que le harnais ne peut pas résoudre

Le Harness Engineering améliore le cadre de travail, mais ne transforme pas une spécification floue en besoin clair. Si personne ne sait définir la fonctionnalité, l’agent peut produire une implémentation propre mais inutile. Si l’architecture ou les données de test sont mauvaises, le harnais peut ralentir la dégradation sans supprimer la dette ni la fausse confiance.

Il faut également traiter les données externes, les dépendances et les documents consultés comme des sources potentiellement non fiables. Permissions minimales, validation des entrées, séparation des privilèges, journaux et capacité de révocation restent indispensables.

Le harnais n’est pas une garantie magique. C’est un système de réduction du risque : il transforme des erreurs imprévisibles en erreurs détectables, des conventions implicites en règles visibles et des corrections répétitives en contrôles réutilisables.

Conclusion — Le prochain avantage compétitif sera l’environnement de travail

La course au modèle le plus puissant ne va pas disparaître, mais elle ne suffira plus à différencier durablement les équipes. Ce qui devient difficile à reproduire, c’est l’environnement qui permet d’utiliser ces modèles dans un projet réel : connaissance du domaine, conventions, outils, données de test, garde-fous, boucles de feedback et méthodes de mesure.

Le Harness Engineering formalise cette idée. Un agent n’est pas seulement un modèle auquel on ajoute quelques outils : c’est un système qui doit percevoir un environnement, agir dans ses limites, recevoir des signaux, corriger sa trajectoire et laisser des traces vérifiables.

Pour les développeurs, l’architecture, les scripts, les tests et la documentation deviennent donc encore plus importants. Pour les décideurs, l’investissement dans l’IA ne doit pas être évalué uniquement à partir du prix du modèle ou du nombre de tokens, mais aussi à partir du cadre qui transforme cette capacité en logiciel exploitable.

La vraie question n’est plus : « Quelle IA va écrire notre code ? » C’est : quel système allons-nous construire pour que cette IA puisse travailler vite sans dégrader le logiciel qu’elle produit ? Les équipes les plus efficaces ne seront pas nécessairement celles qui auront le modèle le plus spectaculaire, mais celles qui auront construit le meilleur environnement pour le faire travailler.

Références et ressources

• Harness engineering for coding agent users — Martin Fowler
• Harness engineering: leveraging Codex in an agent-first world — OpenAI
• SWE-bench — dépôt officiel
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — article de recherche
• DeepSeek Harness — présentation du projet