Votre prestataire code avec un agent d’IA. Un agent est un programme qui s’appuie sur un modèle d’IA, le moteur qui comprend la demande et produit le code, pour écrire ce code, le lancer et le corriger. Certaines semaines, il livre en quelques jours ce qui en demandait plusieurs. D’autres semaines, il faut reprendre la moitié d’un écran. On vous propose alors de passer au modèle supérieur, celui qui obtient les meilleurs scores aux tests comparatifs du moment.
Le harness engineering consiste à construire tout ce qui entoure un modèle d’IA qui écrit du code : les consignes qu’il lit, les règles qui l’encadrent, les outils qu’on lui donne et les contrôles qui vérifient son travail de façon indépendante. Quand un agent donne des résultats inégaux, le problème se trouve souvent là, avant le modèle.
J’utilise des agents de code tous les jours, sur des logiciels de santé comme sur ce site. Ces articles sont eux-mêmes rédigés avec l’IA, à partir de la matière que je dicte, dans un harness que je vous montre plus bas.
Voici de quoi est fait un harness, les symptômes qui distinguent un problème de harness d’un problème de modèle, le moment où l’améliorer ne sert plus, et la séquence pour vérifier celui de votre équipe.
Le harness engineering, ou tout ce qui entoure le modèle
Harness signifie harnais en anglais, et l’image est juste : le cheval fournit la force, le harnais la dirige. Sur votre projet, le modèle d’IA écrit le code. Le harness fixe ce qu’il lit et ce qu’il a le droit de faire, et il prévoit les contrôles qui vérifient son travail.
Le terme s’est diffusé en février 2026, quand une équipe d’OpenAI a raconté 5 mois de développement d’un produit interne sans une ligne de code écrite à la main. Selon elle, ses agents ont écrit environ 1 million de lignes de code. Ils ont aussi soumis environ 1 500 demandes de fusion, c’est-à-dire des propositions de modification. Les agents les relisaient eux-mêmes, un humain n’intervenant qu’au besoin. L’équipe est passée de 3 à 7 ingénieurs, dont le travail a changé : préparer ce dont les agents ont besoin, dire précisément ce qui est attendu, et faire vérifier automatiquement ce qu’ils produisent. Elle le résume ainsi : les humains dirigent, les agents exécutent.
La plupart des harness se rangent en 4 familles de pièces, quels que soient les noms de fichiers. Le fichier de consignes, un simple fichier texte souvent nommé CLAUDE.md ou AGENTS.md, est la première chose que l’agent lit. La spécification, le plan et les tickets lui disent quoi construire. Un ticket est une fiche qui décrit une modification précise. Les notes de décision lui évitent de rouvrir ce qui a été tranché. Les tests automatiques et l’intégration continue, c’est-à-dire les tests lancés à chaque modification, peuvent bloquer une livraison quand ils échouent, si l’équipe les règle ainsi. La recette, enfin, est la vérification par un humain que le logiciel livré répond au besoin.
Le harness
Le modèle au centre, 4 familles de pièces autour
Le modèle
Le moteur d’IA, par exemple Claude chez Anthropic ou GPT chez OpenAI : il change tous les quelques mois.
-
Ce qu’il lit
Avant la première ligne de code.
- Le fichier de consignes
- La spécification
- Le plan et les tickets
-
Ce qui l’encadre
Les décisions déjà prises.
- Les notes de décision
- Les règles du projet
- Les contraintes techniques écrites
-
Ce qui lui donne des mains
Ce qu’il peut faire lui-même.
- L’accès au code
- Une copie de l’application pour tester sans risque
- Les outils pour lancer et observer l’application
-
Ce qui vérifie sans lui
Ce qui ne dépend pas de sa bonne volonté.
- Les tests automatiques
- Les hooks, petits programmes qui se déclenchent seuls
- L’intégration continue, les tests relancés à chaque modification
- La recette par un humain
Sur les forums de développeurs, une objection revient : tout cela ressemble à du génie logiciel classique sous un nouveau nom. Elle est fondée. Écrire ses conventions, tracer ses décisions et automatiser ses tests sont des pratiques anciennes. La nouvelle est bonne : un harness demande peu de technologie nouvelle et beaucoup de rigueur, et la rigueur se vérifie.
La différence tient au lecteur. Une convention écrite pour des humains finissait souvent dans un wiki que personne n’ouvrait. L’agent que vous faites travailler, lui, lit son fichier de consignes à chaque session, c’est-à-dire à chaque nouvelle conversation de travail. Par défaut, l’agent repart presque de zéro à chaque session : ce qui n’est pas écrit se perd. Chez vous, une règle manquante peut donc produire le même raté d’une session à l’autre, jusqu’au jour où quelqu’un l’écrit.
Les ingénieurs d’Anthropic ont décrit en novembre 2025 un harness pour un agent qui travaille sur de longues durées, parfois plusieurs jours. Au premier lancement, l’agent reçoit une consigne spéciale : écrire la liste des fonctionnalités à construire et ouvrir un journal d’avancement. À chaque lancement suivant, il n’avance que d’une fonctionnalité, la teste et note dans le journal ce qu’il a fait. La mémoire et le contrôle sont placés hors de l’agent, dans des fichiers et des tests que vous pouvez lire.
J’ai détaillé les 10 pièces du harness d’une application iPhone réécrite pour Android, avec la raison d’être de chacune. Cet article porte plutôt sur les décisions qu’un harness vous permet de prendre.
Changer de modèle ou corriger le harness : les symptômes qui tranchent
Quand un agent déçoit, changer de modèle est la réponse la plus tentante. La décision est rapide, elle tient en un réglage, et un modèle plus récent fait souvent mieux sur les tests comparatifs publiés. Votre problème vient pourtant rarement de là.
Dans ma pratique, une tâche bien cadrée sort aujourd’hui le plus souvent du premier coup avec les derniers modèles. Quand elle ne sort pas, je cherche d’abord ce qui manque autour. Sur cette réécriture Android, faute de trouver l’écran d’origine à reproduire, l’IA en a inventé un. J’ai ajouté au fichier de consignes une seule règle : « ne jamais inventer un écran qui n’existe pas ». Le problème n’est plus revenu sur ce projet.
Le comparatif ci-dessous range les symptômes les plus fréquents selon leur cause. Les 5 premiers désignent le harness. Le dernier seul justifie de regarder le modèle.
Le diagnostic
6 symptômes : 5 désignent le harness, 1 seul désigne le modèle
L’agent invente ce qui n’existe pas
Le harness- Ce que vous voyez
- Un écran, une fonction ou un tableau de données sortis de nulle part.
- Cause probable
- Aucune consigne ne lui dit où chercher la vérité, ni quoi faire quand il ne la trouve pas.
- Question à poser
- « Quelle règle lui dit de s’arrêter et de demander quand il ne trouve pas ? »
Il oublie une décision prise la semaine précédente
Le harness- Ce que vous voyez
- La façon d’organiser le logiciel, tranchée lundi, est remise en cause jeudi.
- Cause probable
- La décision n’est écrite nulle part : chaque session repart de zéro et peut trancher autrement.
- Question à poser
- « Où sont écrites les décisions sur l’organisation du logiciel, et l’agent les lit-il ? »
Il modifie trop de fichiers d’un coup
Le harness- Ce que vous voyez
- Le résultat fonctionne peut-être, mais personne ne peut le relire.
- Cause probable
- La tâche est trop grosse. Le plan ne découpe pas le travail en petites tâches que l’on peut vérifier une par une.
- Question à poser
- « Qui fixe la taille maximale d’une tâche, et que faites-vous quand elle est dépassée ? »
Il retient des langages ou des services que personne n’a choisis
Le harness- Ce que vous voyez
- Un service de base de données ou un langage que votre équipe ne maintient pas.
- Cause probable
- Aucune contrainte technique écrite : l’agent applique ses choix par défaut.
- Question à poser
- « Quelles contraintes techniques lui donnez-vous avant qu’il commence ? »
Il applique une règle là où elle n’a plus de sens
Le harness- Ce que vous voyez
- Un résultat raide, prévisible, conforme à la lettre et à côté du besoin.
- Cause probable
- Une consigne écrite pour un ancien modèle, moins capable, bride ou égare le modèle actuel.
- Question à poser
- « Quelle est la dernière règle que vous avez retirée, et pourquoi ? »
Le même échec revient alors que tout le reste est en place
Le modèle- Ce que vous voyez
- Consignes, découpage et contrôles existent, et la tâche échoue quand même.
- Cause probable
- La tâche dépasse ce que ce modèle sait faire aujourd’hui.
- Question à poser
- « Avez-vous essayé la même tâche avec un autre modèle, sans rien changer d’autre ? »
Le bon réflexe : corriger le harness d’abord, ou en retirer les règles devenues inutiles, changer de modèle ensuite, et seulement sur une tâche qui échoue avec un harness complet.
Le symptôme C mérite un chiffre. Sur la même réécriture, une dizaine de sessions ont été jetées entières parce que le code produit n’était plus relisible. J’en ai tiré un seuil : au-delà de 10 fichiers touchés dans une session, je ne relis plus sérieusement, et je refuse le résultat. Un modèle plus puissant n’aurait probablement pas rendu ces sessions plus faciles à relire.
Sans contrainte écrite, les modèles choisissent leurs langages de programmation et leurs services en ligne favoris, qui ne sont pas toujours les vôtres. Le symptôme D est détaillé dans l’article sur le spec-driven development, la méthode qui fait écrire la spécification avant le code.
Posez donc une question à votre équipe avant tout changement de modèle : la tâche échoue-t-elle encore avec des consignes, un découpage et des contrôles complets ? Si personne ne peut répondre, regardez d’abord le harness : rien ne prouve encore que le modèle soit en cause.
Un harness se construit avec les ratés, et s’élague quand le modèle progresse
Le harness le plus simple à vous montrer est celui de ce site. L’agent qui rédige ces articles travaille depuis juillet 2026 dans un harness rangé dans le dépôt du site, l’endroit où est stocké son code. Je dicte la matière, il écrit, puis je relis.
Le harness de ce site reprend les pièces du premier schéma. Le fichier de consignes fixe les sources à lire avant d’écrire. Un fichier de règles d’écriture en décrit 22, chacune avec un exemple refusé et un exemple retenu. Un script, un petit programme, les vérifie sur chaque article. Un hook, un script qui se déclenche tout seul, refuse ensuite d’enregistrer une modification qui ajoute une faute contre ces règles. Un second agent relit enfin le texte sans rien savoir du sujet, et signale chaque phrase qu’il a dû relire.
Aucune de ces pièces n’est née d’un plan. Chacune répond à un raté daté. En voici 3, dans l’ordre, et le schéma plus bas en montre un autre :
- 18 août 2026. Les mêmes retours de relecture revenaient d’un article à l’autre. Ils sont devenus des règles écrites, et un script qui les vérifie.
- 19 août 2026. Un article annonce 13 minutes de lecture dans la page, 11 sur sa carte de présentation, pour 15 minutes réelles. 6 articles sur 12 portent le même défaut. Une règle s’ajoute : le temps affiché doit correspondre au nombre de mots.
- 9 septembre 2026. Un article clair et documenté reste plat. Une règle exige depuis que chaque sujet parte d’une décision que le lecteur pourra prendre après lecture.
Ne cherchez pas combien de temps prend un harness : il n’est jamais vraiment terminé. Vous posez les bases, puis vous l’améliorez au fil des ratés et des retours de développement. Une demi-journée suffirait peut-être si vous saviez exactement ce que vous voulez y mettre. Personne ne le sait au départ, et chaque projet a ses propres contraintes techniques.
Vous n’avez pas à partir de zéro pour autant. De nombreux dépôts publics sur GitHub, la principale plateforme où les développeurs partagent leur code, proposent de bonnes bases : fichiers de consignes types, contrôles prêts à l’emploi, et skills, des fiches de méthode que l’agent applique à un type de tâche. Sur la réécriture Android, le harness a demandé plus de temps à construire que la première fonctionnalité complète livrée. C’est ensuite lui qui a permis d’aller vite pendant les 2 mois suivants.
Le cycle
Un harness grandit avec les ratés, et maigrit avec les modèles
-
Un raté
L’agent produit quelque chose que vous refusez.
Sur ce site21 août 2026 : un article de 3 400 mots rédigé d’un trait, sur un sujet tiré d’une liste sans que je l’aie validé, puis jugé sans intérêt.
-
Une règle écrite
La consigne entre dans le harness, avec l’exemple du raté.
Sur ce siteDepuis, le harness impose 2 validations obligatoires avant toute rédaction : le sujet, puis le plan.
-
Un contrôle automatique
Quand la règle se vérifie mécaniquement, un script la vérifie à la place d’un humain.
Sur ce site22 règles d’écriture vérifiées par un petit programme, qui bloque par défaut tout ajout d’infraction.
-
Une revue des règles
À chaque nouveau modèle ou nouveau retour, chaque règle doit encore prouver son utilité.
Sur ce site18 septembre 2026 : l’interdiction d’écrire « je » est levée. Elle rendait les textes impersonnels.
Règle gardée : elle reste, et le cycle reprend au prochain raté.
Règle retirée : le modèle n’en a plus besoin, et la garder le freinerait.
La 4e étape du cycle est celle que l’on oublie. Au début, j’avais tendance à tout écrire : spécifications détaillées, skills et consignes pour chaque cas. Plus les modèles deviennent intelligents, plus il vaut la peine d’élaguer ces instructions pour laisser le modèle exprimer ce qu’il sait faire. Une consigne écrite pour compenser la faiblesse d’un ancien modèle bride le suivant.
Une règle peut même devenir contre-productive. Sur ce site, une règle interdisait le « je » en dehors de l’encart consacré à mes offres. Elle visait les textes qui parlent de leur auteur au lieu de parler au lecteur. Elle a produit l’inverse de ce que je voulais : des articles où un tiers semblait raconter mon travail à ma place. Je l’ai levée le 18 septembre 2026.
Vos outils évoluent aussi vite que les modèles. Une consigne pertinente quand l’IA se trompait souvent devient inutile quand elle progresse. Posez-vous donc régulièrement la question : le temps investi dans le harness vaut-il encore ce qu’il apporte ?
J’applique la règle des 80/20 : 20 % de l’effort apporte 80 % du résultat. Je mets en place les bases qui apportent l’essentiel, et j’accepte que les 20 % restants se construisent par petites touches, sur du temps dédié. Je n’ai rencontré aucune équipe qui arrête de toucher à son harness. Prévoyez donc un temps fixe à chaque sprint, le cycle de quelques semaines au bout duquel l’équipe livre, plutôt qu’un grand chantier ponctuel.
Le script de contrôle applique d’ailleurs encore l’interdiction du « je ». Chaque passage écrit à la première personne doit porter une annotation dans le code de la page, invisible à l’écran, qui signale au script que l’exception est voulue. Un harness accumule donc, comme le code, des règles périmées qu’il faut nettoyer.
Le ticket est la pièce qui a le plus changé dans ma pratique. Je n’écris plus mes tickets pour des humains, mais pour des agents, et chacun porte 3 éléments :
- Les références dans le code. L’endroit exact que la modification va toucher.
- L’intention. Ce que la modification doit permettre à l’utilisateur ou au système.
- Ce qu’on ne veut pas. Les solutions écartées et les zones à ne pas modifier.
Donnez un ticket flou à un agent, et il choisira seul l’une des 1 000 façons de le réaliser. Écrit ainsi, le ticket n’en laisse qu’une poignée, et vous savez lesquelles.
Quand le harness est en place, le goulot passe en amont du code
En septembre 2026, j’ai passé une heure avec l’équipe technique d’un éditeur de logiciel pour les entreprises de santé. Sur le papier, son harness était déjà avancé, et vous pouvez le comparer au vôtre :
- 3 développeurs, tous sur Claude depuis 1 an, et l’IA écrit ou relit l’ensemble du code.
- Une relecture dans les 2 sens : l’IA code et un humain relit, ou l’inverse.
- Une mise en production automatique, c’est-à-dire une mise en service du logiciel pour les utilisateurs, dès que les tests passent.
- Des tests sur la partie serveur du logiciel, celle qui tourne en coulisse, presque tous écrits par l’IA, y compris sur un code ancien qui n’en avait aucun.
- Chaque modification rejoint en 1 à 2 jours le code partagé par toute l’équipe, ce qui évite presque toujours que 2 développeurs modifient la même chose en même temps.
L’équipe a même abandonné l’estimation des tickets : selon elle, avec l’IA, estimer la plupart des tâches coûtait plus cher que les réaliser.
Le harness de cette équipe avait des trous, qu’elle connaissait. Quand l’agent travaillait sur un ordinateur à distance plutôt que sur celui du développeur, il perdait du temps à réinstaller ses outils et n’arrivait pas toujours à lancer les tests. Aucun test automatique ne parcourait les écrans comme le ferait un utilisateur. Les fichiers de consignes existaient, sans que personne ait le temps de les travailler.
Le temps ne se perdait pourtant pas là. Les demandes simples et bien cadrées sortaient vite. Le temps partait en amont. Il fallait arbitrer entre des clients aux intérêts opposés, puis faire valider les choix d’architecture, l’organisation d’ensemble du logiciel, par les rares profils expérimentés de l’équipe. En aval, la recette arrivait tard. Les nouveautés partaient en service en restant masquées aux utilisateurs, et les 2 chefs de produit les vérifiaient à ce moment-là, avant de les ouvrir à tous.
Le goulot
Le harness accélère le code, et le goulot se déplace en amont et en aval
Avant l’IA
- Besoin
- Cadrage
- Codegoulot
- Vérification
- Recette
- Mise en production
Écrire et relire le code prenait souvent l’essentiel du temps. Tout le reste attendait les développeurs.
Avec un agent et un harness en place
- Besoin
- Cadragegoulot
- Code
- Vérification
- Recettegoulot
- Mise en production
Le code et la vérification vont vite. Le temps se perd dans les arbitrages produit, la validation des choix d’architecture et la recette.
J’observe le même déplacement sur mes projets. Une fois le harness en place, le problème se déplace surtout vers la recette et vers la coordination des livraisons, quand plusieurs développeurs ou plusieurs logiciels reliés entre eux livrent en même temps. Si vous améliorez encore le harness à ce stade, vous ne gagnez qu’à la marge, puisque le temps se perd ailleurs.
Mesurez donc où part le temps avant de financer un chantier pour améliorer votre harness. Si le code n’est plus le goulot, je vous recommande de choisir un seul problème précis, par exemple le cadrage des tickets avant développement. Expérimentez dessus, mesurez, puis continuez ou arrêtez selon le résultat.
Le métier des développeurs que vous employez bouge dans le même sens. On parle de Product Engineer, un développeur qui comprend l’impact produit de ce qu’il construit et en porte la responsabilité. Quand écrire du code coûte beaucoup moins cher, cette compréhension devient la compétence rare. L’article sur la direction technique quand le code ne coûte plus rien part du même constat.
Ce qu’un harness ne remplace pas dans un projet avec un agent IA
Un harness rend l’agent plus régulier, sans décider à votre place de ce qu’il faut construire. Une spécification produite par l’IA reste à juger par quelqu’un qui comprend ce qu’elle engage, comme le détaille l’article sur le spec-driven development. Les choix que l’IA fait dans la spécification sans les signaler ne se rattrapent pas avec un meilleur fichier de consignes. Ce fichier encadre la façon de travailler de l’agent. Ce qu’il faut construire relève de la spécification, et quelqu’un doit la juger.
Gardez aussi la recette humaine, que le harness ne remplace pas. Les tests automatiques vérifient que le code fait ce qu’on lui a demandé, sur les cas prévus. Seul un humain vérifie que votre demande correspondait au bon besoin, et la recette au fil des livraisons garde ce rôle.
Un agent peut aussi se brancher sur vos alertes d’erreur, pour proposer seul des corrections. Le prérequis est sévère : très peu de fausses alertes. Sinon, l’agent propose une correction à chaque alerte, y compris pour des erreurs qui n’en sont pas. Chaque tentative consomme des jetons, les morceaux de texte sur lesquels vous êtes facturé.
Je préfère un autre réglage. Le système rassemble le contexte de l’erreur et le pose devant un humain, qui décide d’un clic de lancer la correction. Aucune correction ne part seule en production : un agent qui touche la production sans contrôle humain prend un risque que le gain de temps ne justifie pas.
La relecture humaine devient facultative dans certaines équipes, comme chez OpenAI. Je garde pour ma part les demandes de fusion sur mes projets, davantage pour l’historique que pour la relecture. Quand une tâche est petite et bien cadrée, la relecture va vite et trouve peu de chose. Au-delà de 10 fichiers de code modifiés, je ne la fais plus sérieusement, et je jette la session. Demandez donc des tâches assez petites pour être relues, plutôt qu’une relecture ligne à ligne de tout. L’historique, lui, dit qui a décidé quoi, et quand.
Le harness d’un agent IA est un actif : il doit rester dans votre dépôt
Si un prestataire développe pour vous avec l’IA, son harness vaut presque autant que le code. Le contrat prévoit normalement que le code vous est cédé. Le harness du prestataire, lui, reste souvent sur son poste ou dans ses outils.
Le jour où il part, vous récupérez un logiciel bien plus difficile à faire évoluer avec les mêmes agents. Le risque ressemble à celui d’un logiciel qui tient sur une seule personne, avec une différence : les connaissances existent par écrit, mais chez quelqu’un d’autre, et vous n’y avez plus accès.
La propriété
Le même harness, sur le poste du prestataire ou dans votre dépôt
Le fichier de consignes
- Sur son poste
- Le prochain développeur repart sans les règles que les ratés ont appris.
- Dans votre dépôt
- Chaque agent, chez vous ou chez un autre prestataire, lit les mêmes règles.
Les spécifications et les plans
- Sur son poste
- Le logiciel reste, la raison de ses choix disparaît.
- Dans votre dépôt
- Une évolution repart de ce qui a été décidé, pas d’une supposition.
Les notes de décision
- Sur son poste
- Les mêmes questions se rouvrent et se tranchent autrement.
- Dans votre dépôt
- Une décision se conteste en connaissance de cause.
Les skills, fiches de méthode réutilisables
- Sur son poste
- La méthode de travail part avec la personne.
- Dans votre dépôt
- La méthode se transmet et s’améliore.
Les scripts de contrôle et les hooks
- Sur son poste
- Plus rien ne bloque une livraison défectueuse.
- Dans votre dépôt
- Les contrôles continuent de tourner, quel que soit celui qui code.
Le dépôt de ce site en donne un exemple simple. Le fichier de consignes y vit à côté du code. Le fichier s’appelle AGENTS.md, et un raccourci nommé CLAUDE.md, comme ceux de votre bureau, renvoie vers lui. Les agents d’OpenAI et d’Anthropic cherchent chacun l’un de ces 2 noms, et lisent donc exactement les mêmes règles. Changer d’agent ne demande donc pas de réécrire le fichier de consignes. Les skills et certains réglages propres à chaque agent restent, eux, à adapter.
Demandez la même chose à votre prestataire : consignes, spécifications, notes de décision, skills et scripts de contrôle conservés dans votre dépôt, au même titre que le code. Écrivez-le dans le contrat si besoin.
Vérifier le harness de votre équipe : la séquence, dans l’ordre
Vous n’avez pas besoin de lire du code pour vérifier un harness. Il vous suffit de poser des questions précises et de demander à voir. Suivez ces 7 étapes dans l’ordre, avant d’accepter un changement de modèle ou de financer un chantier sur le harness :
- 1Mesurez où part le temps. Prenez 3 demandes récentes et notez combien de jours chacune a passé dans chaque étape, du besoin à la mise en production. Si le code n’est pas l’étape la plus longue, le harness n’est pas votre priorité.
- 2Demandez à voir le fichier de consignes. L’agent le lit en premier. S’il n’existe pas, ou s’il tient en 3 lignes génériques, vous tenez probablement une cause importante de vos résultats inégaux.
- 3Demandez la dernière règle ajoutée, puis la dernière retirée. Une équipe qui travaille son harness sait dire quel incident a fait naître une règle, et pourquoi une autre a disparu. Une équipe qui ne retire jamais rien accumule des consignes que plus personne ne questionne.
- 4Vérifiez qu’un contrôle tourne sans l’agent. Au moins un test automatique doit bloquer une livraison défectueuse, sans que personne ait à y penser. Une consigne lue par l’agent ne garantit rien tant qu’aucun contrôle ne la vérifie.
- 5Vérifiez où vivent ces fichiers. Ils doivent se trouver dans votre dépôt, conservés avec le code et son historique, et non sur le poste d’un développeur ou d’un prestataire.
- 6Demandez une session ratée récente. Faites raconter ce qui a été jeté, puis ce qui a changé dans le harness ensuite. Une équipe qui n’a jamais rien jeté regarde probablement trop peu ce que l’agent produit.
- 7Décidez ensuite. Si l’étape 1 désigne le code, que les étapes 2 à 6 sont en ordre et que la même tâche échoue encore, essayez-la avec un autre modèle, sans rien changer d’autre. Changez de modèle si l’essai est concluant. Financez un chantier sur le harness si l’étape 1 désigne le code et que les étapes 2 à 6 révèlent des manques. Sinon, cherchez le goulot là où l’étape 1 l’a trouvé.
Votre équipe garde ses outils et ses habitudes. Vous gagnez de quoi juger si l’argent dépensé en modèles et en abonnements va au bon endroit.
Auteur de l’article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →Questions fréquentes sur le harness engineering
Qu’est-ce que le harness engineering ?
C’est la discipline qui consiste à équiper et encadrer un agent d’IA qui code : des consignes à lire, des règles à respecter, des outils à sa disposition et des contrôles indépendants de lui. OpenAI l’a popularisée début 2026, avec le récit d’un produit d’environ 1 million de lignes écrites par ses agents.
Quelle différence avec le context engineering et le spec-driven development ?
Le harness englobe les 2 autres. Le context engineering choisit ce que le modèle lit à chaque instant. Le spec-driven development écrit avant le code ce qu’il faut construire, comme l’explique l’article sur le spec-driven development. Le harness ajoute les outils que l’agent peut utiliser et les contrôles qui tournent sans lui, comme les tests automatiques qui bloquent une livraison.
Faut-il changer de modèle quand l’agent IA se trompe ?
Changer de modèle vient rarement en premier. Quand l’agent invente une fonction, contourne les règles du projet ou modifie trop de fichiers d’un coup, il manque le plus souvent une consigne ou un contrôle. Sur la réécriture d’une application, une seule règle écrite a suffi à faire cesser les écrans inventés. Changez de modèle quand le même échec revient avec un harness complet.
Améliorer le harness suffit-il à livrer plus vite ?
Améliorer le harness ne suffit pas toujours. Dans une équipe de 3 développeurs où l’IA intervient sur tout le code et où chaque modification validée part seule en production, le temps ne se perdait plus dans le code. Il se perdait dans les arbitrages produit et la validation des choix d’architecture. Mesurez où part le temps avant de financer le harness.
Combien de temps faut-il pour construire un harness ?
Ne comptez pas en jours : un harness s’ajuste en continu. Partez des bases partagées publiquement sur GitHub, mettez en place l’essentiel, puis réservez à l’équipe un temps régulier pour l’adapter au fil des ratés et des nouveaux modèles. Les équipes qui en tirent le plus continuent d’y travailler.
Le harness engineering est-il une mode ?
Le mot est récent, la pratique beaucoup moins. Écrire des consignes, tracer les décisions, automatiser les tests : les équipes de développement le font depuis longtemps. Ce qui change, c’est que l’agent IA lit ces règles à chaque session, et qu’un oubli se répète à chaque session tant que la règle n’est pas écrite.
À qui appartient le harness quand un prestataire développe pour vous ?
Il devrait vous appartenir, au même titre que le code. Consignes, spécifications, notes de décision et scripts de contrôle doivent vivre dans votre dépôt, l’endroit où est stocké votre code, et non sur le poste du prestataire. Sinon, son départ emporte les règles qui rendaient les agents efficaces sur votre logiciel, et l’équipe suivante devra les reconstruire.
Sources et documentation
Les retours de terrain présentés ici viennent de ma pratique. L’équipe de l’éditeur de logiciel en santé est volontairement anonymisée. Les références suivantes ont été consultées le 5 octobre 2026.
Retrouvez tous les Décryptages pour préparer vos décisions de développement et de direction technique.