Le blog développeurs de Google a publié le 2 septembre un article sur l'ingénierie des harnais (harness engineering), signé Shir Meir Lador. Le texte propose une définition assez directe du harness : l'ensemble des composants déterministes qui enveloppent le grand modèle de langage — couche d'orchestration, bac à sable d'exécution, persistance d'état, outils de validation en font tous partie.
L'article s'ouvre sur un chiffre frappant : dans un produit expérimental interne d'OpenAI, la part de code écrit à la main était de zéro ligne — trois ingénieurs ont construit et mis en production une version bêta interne en s'appuyant uniquement sur du code généré par le modèle. L'autrice s'en sert pour poser le vrai problème : il ne réside pas dans les capacités du modèle, mais dans la structure qui le maintient à l'intérieur d'un processus maîtrisable.
Rênes, œillères et piste de course
L'article file la métaphore hippique : le modèle est le cheval, le harness est la piste, les œillères et les rênes, chargés de le faire courir dans une seule direction.
"The harness is composed of all the deterministic components that wrap the LLM."
Le harness est constitué de l'ensemble des composants déterministes qui enveloppent le grand modèle de langage.
Cette définition déplace une partie du travail longtemps classé sous "prompt engineering". Pour contraindre le comportement d'un modèle, il n'existe que deux voies : l'écrire dans le prompt, ou l'écrire dans le code qui l'entoure. La première dépend de la discipline du modèle lui-même — changer de modèle oblige à tout réajuster ; la seconde est une contrainte dure, qui reste valable d'une génération de modèle à l'autre. Au cours de l'année écoulée, la plupart des équipes qui ont construit des produits à base d'agents ont testé les deux voies, et payé le prix des deux. Cette ligne dans le prompt, "ne modifie pas les fichiers de test" — passé la trentième relance dans un long contexte, le modèle commence à devenir sélectivement aveugle à cette consigne.
Trois principes de conception
Des frontières strictes. Enfermer l'agent dans un bac à sable, sans lui laisser la moindre chance de toucher aux données de production. Dans la démonstration de l'article, l'agent ne peut écrire des fichiers que dans le répertoire ./sandbox ; toute opération qui dépasse cette limite n'est tout simplement jamais exécutée.
Boucle de réparation. Les erreurs ne devraient pas être renvoyées directement à un humain. Quand un test échoue, le harness renvoie le journal nettoyé au modèle pour qu'il corrige lui-même son code. ADK 2.0 s'appuie ici sur un workflow basé sur un graphe : l'étape de validation est elle-même un nœud de routage dans ce graphe ; un passage échoué redirige automatiquement le flux de contrôle vers le nœud de génération, sans qu'il soit nécessaire d'écrire à la main une logique de nouvelle tentative dans le code d'orchestration.
Une structure de dépôt découvrable par paliers. Plutôt que d'écrire un fichier d'instructions de plusieurs milliers de lignes et de le déverser d'un coup sur l'agent, organiser le dépôt pour qu'il puisse s'y enfoncer couche par couche, en découvrant le contexte au fur et à mesure de ses besoins.
Le SDK Antigravity qui l'accompagne s'occupe du côté environnement local : il délimite les frontières du workspace tout en offrant une mémoire persistante. Ensemble, les deux outils couvrent deux questions : "où l'agent s'exécute-t-il" et "comment revient-il sur la bonne voie quand il se trompe".
Le plafond de cinq passages et cet interrupteur
La boucle d'auto-guérison de la démonstration boucle un cycle complet : l'agent écrit du code dans un bac à sable restreint, lance automatiquement les tests, le test échoue, le journal est renvoyé, l'agent corrige, puis relance. Le plafond est fixé à cinq passages ; une fois ce seuil atteint, le harness coupe le processus — l'autrice appelle ça un kill switch.
Ce chiffre cinq est la donnée la plus concrètement utile de tout l'article. Le mode d'échec typique d'une boucle d'auto-guérison, c'est le modèle qui oscille entre deux états d'erreur, brûlant des tokens à chaque passage sans jamais converger. Fixer un plafond strict revient à admettre par avance que le modèle échouera parfois, et à rendre le problème à un humain plus tôt. Sans cet interrupteur, une boucle partie en vrille peut cramer tout un budget en une nuit, sans surveillance.
Comparé aux frameworks d'agents à la mode au premier semestre de cette année, le déplacement du centre de gravité est assez net. Les premiers frameworks parlaient surtout d'orchestration : comment enchaîner plusieurs agents, répartir les tâches, faire circuler les messages. On parle désormais de validation et de frontières : où se déroule l'exécution, comment les erreurs remontent, quand s'arrêter. Le premier sujet répond à "est-ce que ça tourne" ; le second répond à "peut-on vraiment lui faire confiance sur un projet réel".
Pour les équipes qui ne s'appuient pas précisément sur la pile technique de Google, l'ADK 2.0 et le SDK Antigravity en tant qu'outils précis ne seront pas forcément utilisables tels quels — mais les trois principes, eux, se copient sans modification. Bac à sable, boucle de réparation, contexte découvrable par paliers : aucun agent codeur maison n'y échappe, la seule question est de les concevoir dès le départ ou de les rajouter après coup, une fois que l'agent aura supprimé les fichiers de test une première fois.
Sources : blog développeurs de Google, CocoLoop, documentation des projets ADK et Antigravity SDK ; la définition du harness, les trois principes de conception et le plafond de cinq passages ont été vérifiés dans l'article original, les chiffres de zéro ligne de code manuel et de trois ingénieurs sont cités tels que rapportés dans le texte.