Le harness engineering rend un agent plus fiable en reliant le modèle au contexte, aux outils et aux contrôles dont il a besoin. Je détaille son rôle, sa boucle d’exécution et les éléments à prévoir pour construire un mini-harness Python vérifiable.
Pourquoi un modèle seul ne suffit-il pas ?
Un modèle seul ne dispose pas nécessairement du contexte du projet, d’un accès aux outils, d’une mémoire de session ni d’un mécanisme fiable pour vérifier son travail. Il génère une réponse à partir des informations présentes dans son contexte et de ses capacités disponibles. Si une information manque, il ne peut pas toujours la récupérer ni confirmer qu’elle est à jour.
Cette limite a des effets concrets. Un agent peut déclarer une tâche terminée sans avoir vérifié le résultat, par exemple après avoir proposé une modification sans l’avoir testée. Il peut aussi agir au-delà de l’intention de l’utilisateur si les autorisations, les limites de l’action ou les critères d’arrêt ne sont pas explicites. Ce ne sont pas des comportements systématiques, mais des risques à traiter dans la conception du système.
Comment réduire les tokens d’un prompt sans perdre en qualité ?
Le volume de contexte compte aussi. Ajouter davantage de documents ne garantit pas une meilleure réponse : les éléments utiles peuvent être noyés dans des informations secondaires, et certaines instructions peuvent être moins bien prises en compte. J’observe régulièrement qu’un contexte sélectionné et structuré est plus exploitable qu’un dépôt de données complet injecté sans distinction.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le harness répond à ces limites en organisant trois dimensions :
- Le contexte : les informations du projet, les consignes et la mémoire utile à la session.
- Les actions : les outils accessibles, leurs permissions et les conditions dans lesquelles l’agent peut les utiliser.
- La vérification : les contrôles qui permettent de confirmer qu’une action a réussi et que le résultat répond à la demande.
Le modèle produit des décisions et du contenu. Le harness encadre leur exécution et leur validation. C’est l’ensemble de ces mécanismes autour du modèle — contexte, outils, règles d’action et contrôles — que j’appelle un harness.
Que réunit un harness d’agent ?
Quels dépôts GitHub pour les AI agent skills ?
Un harness est l’environnement d’exécution et de contrôle qui relie le modèle aux informations et aux outils, organise ses étapes et vérifie les résultats. Le modèle propose des actions ; le harness lui fournit les moyens de les exécuter et contrôle ce qu’elles produisent. Cette séparation est essentielle : le modèle décide quoi proposer, le harness définit ce qui est accessible et comment l’exécution est encadrée.
Un harness réunit plusieurs éléments qui déterminent concrètement le fonctionnement de l’agent :
- Les instructions, qui précisent le rôle de l’agent et les règles à suivre.
- La récupération de contexte et la mémoire, qui apportent les informations utiles à la tâche et permettent de conserver des éléments pertinents entre les étapes.
- Les outils, qui donnent accès à des actions ou à des ressources que le modèle ne peut pas mobiliser seul.
- L’environnement contrôlé, dans lequel ces outils et actions sont exécutés.
- Les étapes du workflow, qui organisent l’enchaînement des opérations et indiquent quand le modèle doit intervenir.
- Les approbations ou les nouvelles tentatives, qui permettent de valider une action ou de la relancer lorsqu’un résultat ne convient pas.
- Les tests et les journaux, qui servent à vérifier le comportement de l’agent et à suivre les étapes de son exécution.
Le modèle ne contrôle donc pas seul son environnement. Il peut proposer l’appel d’un outil, mais c’est le harness qui l’exécute dans le cadre prévu, puis qui vérifie le résultat et décide si le workflow continue, s’arrête ou demande une nouvelle tentative.
Comment classer des textes en few-shot avec Scikit-LLM ?
Un même modèle peut se comporter très différemment selon son harness. Avec des instructions différentes, un contexte récupéré autrement, des outils plus limités ou des étapes de workflow distinctes, ses propositions et les résultats obtenus changent. En pratique, comparer deux agents uniquement par leur modèle est insuffisant : leur harness détermine une part importante de leur comportement réel.
Comment fonctionne la boucle de l’agent ?
Le harness construit le contexte, le modèle propose une action, le harness l’exécute puis vérifie le résultat avant un nouveau passage. À chaque itération, le contexte est actualisé avec les éléments utiles : résultat de l’action, état des outils, erreurs et contrôles déjà effectués. Le modèle ne repart donc pas d’une requête isolée ; il décide à partir de l’état courant du système.
La boucle suit un ordre précis. Le harness prépare les instructions et les données accessibles au modèle. Le modèle renvoie une action structurée, par exemple appeler un outil ou produire une réponse. Le harness valide cette action, l’exécute dans les limites définies, puis observe le résultat. Il compare ce résultat aux critères attendus et ajoute les observations au contexte. Si le travail n’est pas terminé, un nouveau passage commence avec ce contexte mis à jour.
Comment utiliser Gemini 4 Argon dans n8n ?
La boucle s’arrête lorsque les contrôles réussissent ou qu’une limite est atteinte : nombre d’itérations, durée, budget de tokens ou quota d’appels. Dans ce second cas, l’agent ne doit pas masquer l’échec. Il communique son état, les contrôles non satisfaits et, si nécessaire, demande une intervention humaine. Un arrêt propre fait partie du comportement attendu, pas d’une exception à traiter après coup.
Les tests et les journaux interviennent à des endroits distincts. Les tests vérifient le comportement du harness et la conformité des résultats à des critères définis. Ils ne garantissent pas, à eux seuls, que chaque décision du modèle est correcte. Les journaux enregistrent les entrées, actions, résultats et erreurs pour faciliter le diagnostic ; ils ne corrigent ni une action dangereuse ni une vérification manquante. Chez un client, c’est souvent l’absence de trace exploitable — plus que le modèle — qui rend les incidents difficiles à comprendre.
La fiabilité dépend donc de la boucle complète : contexte maîtrisé, actions encadrées, résultats vérifiés et limites explicites. Un modèle performant ne compense pas un harness qui exécute sans contrôler.
Comment le harness encadre-t-il les actions ?
Le harness encadre les actions de l’agent en organisant le workflow, en contrôlant l’environnement d’exécution et en vérifiant les résultats. Je le conçois comme la couche qui transforme une intention en opérations exécutables, avec des points de contrôle explicites entre les étapes.
Dans la pratique, il détermine quelles actions peuvent être lancées, dans quel contexte et avec quelles validations. Une approbation humaine peut être intégrée lorsqu’une action le nécessite. Une nouvelle tentative peut être prévue après un échec, sans relancer aveuglément une opération dont l’état est incertain. Les tests vérifient les comportements attendus avant et après l’exécution ; les journaux permettent de retracer les actions, les résultats et les erreurs.
Les limites de sécurité et de coût relèvent de la conception du harness. Il faut décider quels accès sont nécessaires, quelles actions doivent être soumises à validation et comment éviter des appels ou des traitements inutiles. Ces choix dépendent du cas d’usage. Je ne leur attribue pas de règles universelles : un agent interne qui résume des documents et un agent qui modifie des données de production n’ont pas le même niveau de risque.
L’architecture est présentée comme comprenant six couches, mais seule la première est précisée ici : des instructions claires. Je n’en déduis pas le contenu des cinq autres. Ces instructions doivent cadrer l’objectif, les contraintes et le comportement attendu ; le harness doit ensuite rendre ce cadre applicable dans l’exécution réelle.
Pour l’implémentation, je relie donc chaque étape du workflow à son environnement, à ses critères de validation et à la trace produite. C’est ce lien qui permet d’auditer un résultat, de distinguer une erreur de l’agent d’un échec d’exécution et de décider si une nouvelle tentative ou une approbation est pertinente.
Comment construire un mini-harness Python ?
Un mini-harness Python organise l’exécution d’un agent autour d’un bac à sable, de tests en lecture seule, d’une limite d’étapes, d’une sauvegarde de progression et d’une vérification finale. Le modèle propose une action ; le harness décide de l’exécuter, contrôle le résultat et actualise le contexte.
Voici un exemple autonome, sans dépendance externe. Le bac à sable est volontairement réduit à un espace mémoire contenant un seul fichier autorisé. La fonction de proposition remplace ici un appel au modèle.
import json
from pathlib import Path
MAX_STEPS = 3
CHECKPOINT = Path("progress.json")
# Le bac à sable est ici un espace mémoire, pas une isolation du système.
sandbox = {"files": {}}
def propose_action(context):
# Exemple déterministe à remplacer par votre mécanisme de génération.
return {
"type": "write",
"path": "result.txt",
"content": "ok"
}
def execute_action(action):
# Le harness contrôle les opérations autorisées avant exécution.
if action.get("type") != "write" or action.get("path") != "result.txt":
return {"ok": False, "error": "Action non autorisée"}
sandbox["files"][action["path"]] = action["content"]
return {"ok": True}
def run_readonly_tests():
# Ces contrôles lisent l’espace de travail sans le modifier.
return {
"result_exists": "result.txt" in sandbox["files"],
"content_is_ok": sandbox["files"].get("result.txt") == "ok"
}
def save_progress(context):
CHECKPOINT.write_text(json.dumps(context), encoding="utf-8")
context = {"step": 0, "tests": {}, "last_result": None}
status = "intervention requise"
for step in range(1, MAX_STEPS + 1):
proposal = propose_action(context) # Proposition du modèle.
execution = execute_action(proposal) # Exécution contrôlée par le harness.
tests = run_readonly_tests() # Contrôle en lecture seule.
context = {
"step": step,
"proposal": proposal,
"last_result": execution,
"tests": tests
}
save_progress(context)
if execution["ok"] and all(tests.values()):
# Vérification finale distincte des tests intermédiaires.
final_ok = sandbox["files"].get("result.txt") == "ok"
status = "terminé" if final_ok else "intervention requise"
break
else:
status = "limite atteinte : intervention requise"
print({"status": status, "context": context})La boucle actualise le contexte après chaque action et sauvegarde l’état. Elle s’arrête si les tests réussissent et que la vérification finale confirme le résultat, ou quand la limite est atteinte. Ici, la sauvegarde est locale et le « bac à sable » n’isole pas réellement le processus Python : cet exemple ne constitue pas une garantie de sécurité. En production, l’exécution doit être adaptée à votre environnement et toute action non validée doit pouvoir être soumise à une personne.
| Mécanisme | Rôle |
| Bac à sable | Restreint les opérations de l’exemple à un espace mémoire défini. |
| Tests en lecture seule | Contrôlent l’état sans le modifier. |
| Limite d’étapes | Empêche la boucle de continuer indéfiniment. |
| Sauvegarde | Conserve le contexte après chaque tentative. |
| Vérification finale | Confirme le résultat avant de déclarer l’exécution terminée. |
Que retenir avant de mettre un harness en production ?
Un modèle ne suffit pas à exécuter fiablement une tâche complexe : il lui faut du contexte, des outils et un système qui encadre ses actions. Le harness assemble ces éléments, actualise le contexte à chaque étape et vérifie les résultats avant de poursuivre ou de s’arrêter. Sa conception doit aussi rendre explicites les limites de workflow et les points où une intervention humaine peut être nécessaire. Pour démarrer, un mini-harness Python peut s’appuyer sur un bac à sable, des tests en lecture seule, une limite d’étapes, une sauvegarde de progression et une vérification finale. Vous obtenez ainsi un agent plus contrôlable et un résultat plus facile à valider.
FAQ
- Qu’est-ce que le harness engineering ?
C’est la conception du système qui entoure un modèle : contexte, outils, environnement d’exécution, workflow, état et contrôles. - Quelle est la différence entre un modèle et un harness ?
Le modèle propose des actions. Le harness lui fournit les informations et les moyens d’agir, exécute les actions et contrôle les résultats. - Comment fonctionne la boucle d’un agent ?
Le harness prépare le contexte, le modèle propose une action, puis le harness l’exécute et vérifie le résultat. La boucle recommence avec un contexte actualisé jusqu’à la réussite des contrôles ou l’atteinte d’une limite. - Quels éléments intégrer dans un mini-harness Python ?
Le mini-harness décrit ici comprend un bac à sable, des tests en lecture seule, une limite d’étapes, une sauvegarde de progression et une vérification finale. - Un harness garantit-il qu’un agent ne fera aucune erreur ?
Non. Il encadre l’exécution et vérifie les résultats, mais ne garantit pas à lui seul l’absence d’erreur. La conception doit prévoir des limites et, lorsque nécessaire, une intervention humaine.
A propos de l’auteur
Je suis Franck Scandolera, expert en automatisation IA et en conception de workflows agentiques. Je travaille sur des systèmes qui connectent les modèles aux données, aux outils métier et aux contrôles nécessaires pour rendre leurs actions vérifiables.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.