Agent Harness Engineering : la couche technique qui fiabilise vos agents IA en production (au-delà du prompt)

Un copilote interne pour une compagnie d'assurance doit aider les gestionnaires à traiter les demandes de sinistre. Il reçoit une question, interroge la base documentaire, rédige une réponse. Sauf qu'un mardi après-midi, il appelle l'outil de recherche interne… quinze fois de suite, avec des requêtes quasi identiques. Puis il rend une réponse bâtie sur les trois premiers résultats, sans jamais vérifier leur pertinence. Aucune erreur dans les logs. Aucun crash. Juste une réponse fausse, livrée avec assurance.

Ce scénario — inspiré de cas réels que nous rencontrons chez nos clients — illustre une vérité que beaucoup d'équipes découvrent trop tard : un agent IA bien prompté peut quand même échouer en production. Et il le fait silencieusement.

La bonne nouvelle : ces échecs ont des causes communes et une réponse structurée. Elle s'appelle le harness engineering — l'ingénierie du harnais de l'agent. Chez LangChain, cette approche a fait gagner 13,7 points à un agent de code sur Terminal-Bench 2.0, sans changer une seule fois de modèle. Cet article vous donne le framework, les patterns concrets et une checklist d'audit pour appliquer la même discipline à vos agents.

Le prompt ne suffit plus : pourquoi vos agents échouent en silence

Les systèmes agentiques ont changé d'échelle. Il y a deux ans, un « agent » était surtout un chatbot avec quelques appels d'outils. Aujourd'hui, ce sont des systèmes autonomes qui enchaînent des dizaines d'étapes : recherche, rédaction, exécution de code, appels d'API, vérifications. Plus la boucle d'exécution est longue, plus les petits défauts se cumulent — et plus les modes d'échec deviennent systémiques.

Trois familles d'échecs reviennent constamment dans les traces de production :

1. Les boucles infinies (doom loops). L'agent tente une approche, elle échoue, il retente la même approche avec une variation mineure. Dix fois. Quinze fois. Chaque itération consomme des tokens, du temps et de l'argent — sans jamais converger. Dans certaines traces publiées par LangChain, ce pattern apparaît plus de dix fois sur une seule tâche.

2. Les sorties jamais vérifiées. Le modèle écrit une solution, se relit, se trouve bon, et s'arrête. Les modèles actuels ont un biais bien documenté vers leur première solution plausible : ils ne rentrent pas spontanément dans une boucle d'auto-vérification (self-verification loop). Résultat : du code non testé, des réponses non sourcées, des calculs jamais contrôlés.

3. Les coûts de raisonnement incontrôlés. Les modèles à raisonnement peuvent dépenser plus du double de tokens selon le niveau demandé. Sans politique explicite, vous payez le maximum partout — ou pire, vous tombez en timeout parce que l'agent raisonne trop sur des sous-tâches simples.

Le point commun de ces trois échecs : ils ne se voient pas. Pas d'exception, pas d'erreur 500. L'agent répond, poliment, avec confiance. C'est précisément ce qui rend le prompt engineering insuffisant : le prompt est une instruction, pas un mécanisme. Vous pouvez écrire « vérifie toujours ton travail » en gras dans le system prompt — si aucun mécanisme ne force la vérification avant la sortie, une partie des exécutions passera au travers, surtout sur les tâches longues où l'instruction initiale s'est diluée dans le contexte.

C'est là que le harnais entre en jeu.

Qu'est-ce que le « harness » d'un agent IA ?

Le terme vient de l'équitation et de l'alpinisme : le harnais, c'est ce qui relie l'énergie brute (le cheval, le grimpeur, le modèle) à un système qui canalise cette énergie vers un objectif utile — en le protégeant de sa propre chute.

Appliqué aux agents, le harnais d'agent (agent harness) désigne tout ce qui entoure le modèle et structure son exécution :

• le system prompt, qui fixe le contrat comportemental ;
• la sélection d'outils (tool selection) : lesquels, avec quelles descriptions, quelles signatures ;
• les middlewares et hooks : du code déterministe qui intercepte les appels au modèle et aux outils, avant et après ;
• le flux d'exécution : qui décide quoi, quand la boucle s'arrête, ce qui est injecté dans le contexte.

Une distinction utile pour situer le concept par rapport aux pratiques que nous avons déjà couvertes sur ce blog :

Pratique	Question à laquelle elle répond	Nature
Prompt engineering	Comment formuler la tâche ?	Rédaction d'instructions
Context engineering	Quelles informations fournir, et quand ?	Assemblage du contexte
Harness engineering	Quels mécanismes garantissent le comportement ?	Ingénierie système

Le harness engineering ne remplace pas les deux autres — il les englobe et les outille. Là où le prompt dit à l'agent quoi faire, le harnais garantit que certains passages sont obligatoires : impossible de sortir sans vérification, alerte automatique après N modifications du même fichier, budget de raisonnement ajusté par phase.

La formulation de LangChain est parlante : le but du harnais est de mouler l'intelligence irrégulière du modèle (spiky intelligence) pour les tâches qui comptent. Un modèle peut être brillant sur un raisonnement arithmétique et naïf sur la gestion du temps ; excellent en génération de code et négligent en vérification. Le harnais compense systématiquement les points faibles, au lieu d'espérer qu'un meilleur prompt les masque.

Et c'est un travail d'ingénierie au sens plein : itératif, mesuré, outillé. Pas une couche de polish cosmétique.

Les 3 leviers concrets : system prompt, sélection d'outils, middleware

L'espace de conception d'un harnais est vaste : prompts, outils, hooks, skills, délégation à des sous-agents, mémoire… Pour rester actionnable, compressons-le comme l'ont fait les équipes de LangChain sur trois leviers principaux.

Levier 1 : le system prompt comme contrat de méthode

Le system prompt d'un agent en production ne décrit pas seulement ce qu'il faut faire — il décrit comment travailler. La différence est subtile mais décisive. Un prompt de tâche dit : « Corrige ce bug. » Un prompt de méthode dit :

1. Planifier et explorer : lire la demande, scanner l'environnement, construire un plan initial et définir comment la solution sera vérifiée.
2. Construire : implémenter le plan en pensant à la vérification — écrire les tests, y compris les cas limites, pas seulement le chemin nominal.
3. Vérifier : exécuter les tests, lire la sortie complète, comparer le résultat à ce qui était demandé (pas à son propre code).
4. Corriger : analyser les erreurs, revenir à la spécification initiale, corriger.

Ce protocole en quatre temps (planifier → construire → vérifier → corriger) transforme le prompt en méthode de travail. Nous détaillons ci-dessous comment le rendre contraignant, pas seulement suggestif.

Levier 2 : la sélection d'outils — moins, mais mieux

Chaque outil exposé à l'agent est une décision qu'il pourra prendre — et une occasion de se tromper. Trois règles pratiques :

• Descriptions non ambiguës. L'agent choisit ses outils sur la base de leurs descriptions. Une description vague (« search ») invite aux appels redondants ; une description précise (« Recherche full-text dans la base documentaire des sinistres. Retourne les 5 résultats les plus pertinents avec leurs scores. N'appeler qu'une fois par question. ») prévient les boucles dès la source.
• Assez d'outils pour agir, assez peu pour trancher. Un agent qui hésite entre quatre outils de recherche similaires finira par les appeler tous. Fusionnez ou supprimez les doublons fonctionnels.
• Des outils qui donnent du signal. Un outil d'exécution de tests qui retourne des erreurs lisibles alimente naturellement la boucle de correction. Un outil qui retourne « erreur » nourrit les conjectures.

Levier 3 : le middleware — du déterministe autour du probabiliste

C'est le levier le plus puissant, et le moins exploité. Un middleware (ou hook) est un morceau de code déterministe qui s'exécute autour des appels au modèle ou aux outils :

• avant un appel modèle : injecter du contexte (structure du répertoire courant, contraintes de temps, rappel de la spécification) ;
• après un appel d'outil : compter les usages, détecter les répétitions, reformater les sorties ;
• avant la sortie de l'agent : bloquer et relancer une passe de vérification si les conditions ne sont pas réunies.

Pourquoi c'est décisif : le prompt est probabiliste (le modèle peut l'ignorer), le middleware est déterministe (le code s'exécute, point). Toute règle critique — « pas de sortie sans test », « alerte après 5 modifications du même fichier » — doit vivre dans le middleware, pas seulement dans le prompt.

En synthèse :

Levier	Ce qu'il contrôle	Force	Limite
System prompt	La méthode de travail	Flexible, riche	Probabiliste
Sélection d'outils	Les actions possibles	Réduit la surface d'erreur	Ne garantit rien seul
Middleware	Les points de passage obligatoires	Déterministe, garanti	Nécessite du code

Patterns qui marchent : auto-vérification, détection de boucles, budget de raisonnement

Ces leviers se combinent en patterns éprouvés. En voici quatre que nous retrouvons dans toutes les architectures agentiques fiables.

Pattern 1 : la boucle d'auto-vérification forcée (build-verify loop)

Les modèles actuels sont d'excellentes machines à s'améliorer… à condition de recevoir un signal de retour. Ils n'ont simplement pas de tendance naturelle à entrer dans la boucle construire → tester → corriger. Deux mécanismes complémentaires :

• Au niveau du prompt : imposer explicitement les quatre phases (planifier, construire, vérifier, corriger) et exiger que les tests couvrent les cas limites, pas seulement le chemin nominal.
• Au niveau du middleware : un pre-completion checklist qui intercepte l'agent juste avant qu'il ne se déclare terminé, et lui impose une dernière passe de vérification contre la spécification initiale. L'agent ne peut pas sortir tant que la checklist n'a pas été honorée.

C'est ce duo prompt + hook qui fait la différence : le prompt enseigne la méthode, le hook la rend incontournable.

Pattern 2 : la détection de boucles infinies (loop detection)

Contre les doom loops, le pattern de LangChain est simple et transposable à presque toute stack : un middleware compte les modifications par fichier (ou par ressource) via les hooks d'appel d'outils. Au-delà de N modifications du même fichier, il injecte dans le contexte : « Vous avez modifié ce fichier N fois sans succès. Envisagez de remettre votre approche en question. »

Ce n'est pas magique — le modèle peut persister dans son erreur. Mais dans les expériences publiées, ce simple rappel suffit souvent à déclencher un vrai changement de stratégie. À noter : c'est une béquille volontaire, qui contourne les faiblesses actuelles des modèles. Quand les modèles progresseront, ces garde-fous deviendront probablement superflus. En 2026, ils font la différence entre un agent qui converge et un agent qui brûle votre budget.

Pattern 3 : le budget de raisonnement adaptatif (adaptive reasoning)

Les modèles à raisonnement proposent plusieurs niveaux d'effort cognitif. Les utiliser intelligemment change radicalement l'équation coût/qualité :

• Raisonnement maximal partout : qualité dégradée par les timeouts — dans l'étude citée plus bas, le niveau maximal permanent plafonne à 53,9 % contre 63,6 % pour un niveau élevé, simplement parce que les agents dépassent les limites de temps.
• Raisonnement minimal partout : économies immédiates, mais plans bâclés sur les tâches difficiles.
• Le « sandwich » de raisonnement : effort maximal sur la planification (bien comprendre le problème), effort modéré sur l'exécution, effort maximal sur la vérification finale. C'est le compromis optimal observé.

La logique : un bon plan fait gagner du temps sur tout le reste, et une vérification sérieuse évite de soumettre un travail incomplet. Entre les deux, l'exécution n'a pas besoin de philosopher.

Pattern 4 : l'injection de contexte d'environnement

Un agent qui découvre son environnement par tâtonnement commet des erreurs évitables : mauvais chemins, outils absents, conventions ignorées. Un middleware d'onboarding qui cartographie l'environnement au démarrage (structure des répertoires, outils disponibles, contraintes) réduit mécaniquement cette surface d'erreur. Même logique pour les contraintes métier : injecter les limites de temps et les critères d'évaluation permet à l'agent de s'autoréguler au lieu de les découvrir en l'échouant.

Le fil conducteur de ces quatre patterns : préparer et délivrer le contexte pour que l'agent puisse travailler en autonomie — et rendre certains passages obligatoires par du code, pas par la prière.

Étude de cas : +13,7 points sur Terminal-Bench sans changer de modèle

Si le harness engineering était une théorie, ces chiffres la feraient vaciller. Voici l'expérience que LangChain a publiée en février 2026.

Le dispositif. Leur agent de code en ligne de commande, deepagents-cli, évalué sur Terminal-Bench 2.0 : 89 tâches réelles couvrant le machine learning, le débogage, la biologie. Modèle figé pendant toute l'expérience : GPT-5.2-Codex. Orchestration via Harbor, chaque action tracée dans LangSmith (latence, tokens, coûts).

Point de départ : 52,8 % — un score solide, juste hors du top 30 du classement.

La méthode. Pas de changement de modèle, pas de fine-tuning. Uniquement des itérations sur le harnais, guidées par l'analyse systématique des traces : récupération des traces d'expérimentation, analyse parallèle des erreurs par des sous-agents, synthèse des causes d'échec, modifications ciblées du harnais. Une démarche proche du boosting en machine learning : se concentrer sur les erreurs des runs précédents.

Les changements appliqués sont exactement les patterns décrits plus haut : protocole de vérification en quatre phases dans le system prompt, checklist de pré-sortie forcée par middleware, contexte d'environnement injecté au démarrage, détection de boucles par comptage de modifications, budget de raisonnement en sandwich.

Résultat final : 66,5 %. Soit +13,7 points avec le même modèle — de quoi passer du top 30 au top 5 du leaderboard.

Deux enseignements pour toute équipe qui industrialise des agents :

1. Le harnais est un artefact d'ingénierie de premier ordre. Il se versionne, se teste, s'itère — exactement comme le code applicatif. Une équipe qui ne mesure l'amélioration de ses agents qu'en changeant de modèle laisse sur la table le levier le plus rentable.
2. L'observabilité est le carburant de l'itération. Sans traces exploitables, pas d'analyse d'échecs ; sans analyse d'échecs, les modifications du harnais sont des paris. C'est le même principe que pour n'importe quel système distribué : on n'améliore que ce qu'on mesure.

Checklist d'audit : 8 questions avant de mettre un agent en production

Avant d'exposer un agent à vos utilisateurs, passez-le à cette grille. Huit questions, deux minutes, beaucoup d'incidents évités.

1. Chaque outil a-t-il une description non ambiguë ? Vérifiez qu'elle précise le périmètre, le format de sortie et les cas d'usage — c'est la première protection contre les appels redondants.
2. Le system prompt définit-il un protocole de vérification explicite ? Pas seulement « sois rigoureux » : les phases concrètes (planifier, construire, vérifier, corriger) et les critères de réussite.
3. Existe-t-il un hook qui bloque la sortie sans vérification ? Si la seule barrière est une instruction dans le prompt, elle sera contournée. La règle critique doit être du code.
4. La détection de boucles est-elle en place ? Comptage des appels redondants ou des modifications répétées, avec injection d'un message de recadrage au-delà du seuil.
5. Le budget de raisonnement est-il adapté par phase ? Maximal sur la planification et la vérification, modéré sur l'exécution — plutôt qu'un niveau unique mal calibré.
6. Les traces sont-elles exploitables ? Pouvez-vous reconstruire une exécution complète (appels d'outils, contextes, coûts) à partir de vos logs d'observabilité ?
7. Un processus d'analyse d'échecs existe-t-il ? Qui examine les échecs, à quelle fréquence, et comment les conclusions alimentent-elles une modification du harnais ?
8. L'agent connaît-il ses contraintes ? Limites de temps, budget de tokens, environnement disponible : ce qui n'est pas injecté sera découvert à ses dépens.

Score honnête ? Moins de six « oui » : votre agent n'est pas en production, il est en chance.

Comment Brainum industrialise vos agents

Ces patterns ne sont pas académiques : ce sont ceux que nous appliquons quand nous concevons et fiabilisons des systèmes agentiques pour nos clients — copilotes métier, automatisations complexes, agents de traitement documentaire.

Notre approche, concrètement :

• Audit du harnais existant : analyse de vos traces, identification des modes d'échec (boucles, sorties non vérifiées, dérives de coûts) et chiffrage de leur impact.
• Conception du harnais : system prompt de méthode, sélection d'outils resserrée, middlewares de vérification et de détection de boucles, budget de raisonnement calibré.
• Observabilité et itération : mise en place du tracing, boucle d'analyse d'échecs, et amélioration continue mesurée sur vos cas d'usage — pas sur des benchmarks génériques.

Parce qu'un agent fiable n'est pas un agent bien prompté. C'est un agent bien harnaché.

Vous industrialisez des agents IA et ces modes d'échec vous parlent ? Discutons de votre cas.