L’idée qu’une intelligence artificielle puisse s’améliorer elle-même fait fantasmer et trembler depuis les années 60. Mais en 2026, la question n’est plus « est-ce que c’est possible ? » : elle est devenue « comment on architecture ça concrètement ? ». La réponse tient en deux mots : harness engineering. Derrière ce terme se cache la couche logicielle qui orchestre, vérifie et fait progresser un agent IA, bien au-delà du simple prompt.
Qu’est-ce que le harness engineering ?
Le concept d’auto-amélioration récursive (RSI, Recursive Self-Improvement) ne date pas d’hier. I. J. Good le théorise dès 1965, et Eliezer Yudkowsky le précise en 2008 : une IA utilise son intelligence actuelle pour améliorer les rouages mêmes qui produisent cette intelligence. Dans les LLMs modernes, cela ne signifie pas que le modèle réécrit directement ses poids. Cela signifie qu’il améliore le pipeline d’entraînement et le système de déploiement, ce qui permet à son successeur d’être plus performant.
Le harness engineering, c’est précisément la conception de ce système de déploiement. Là où les premiers frameworks agents se contentaient d’un empilement « LLM + mémoire + outils + planification », un harness intègre en plus la conception du workflow, l’évaluation, le contrôle des permissions et la gestion d’état persistant. On n’est plus dans une collection de templates de prompts : on est dans du runtime, de l’architecture système.
Les trois patterns incontournables d’un harness
L’analyse des agents de code comme Claude Code, Codex ou OpenCode fait émerger trois patterns récurrents. Ils ne sont pas optionnels si l’on vise des tâches longues et complexes.
Workflow Automation
Un harness digne de ce nom définit une boucle objectif : planifier, exécuter, observer, tester, améliorer, recommencer. Le dépôt autoresearch de Karpathy en est une démonstration limpide. Le modèle ne se contente pas de générer une réponse : il analyse ses propres trajectoires, détecte ses échecs et itère à travers un véritable runtime agent.
Système de fichiers comme mémoire persistante
Dans un rollout agentic de longue durée, les logs, les diffs de code, les résumés de papiers et les traces d’erreur dépassent vite la fenêtre de contexte du modèle. La solution ? Stocker l’état durable dans des fichiers. Lire, écrire et éditer le système de fichiers via des commandes bash est une compétence fondamentale pour un LLM. Un harness qui exploite ce pattern bénéficie directement des progrès de la capacité du modèle sous-jacent.
Sous-agents et jobs en arrière-plan
Un harness peut lancer plusieurs sous-agents en parallèle et surveiller des jobs backend. Utile quand l’agent principal doit explorer plusieurs hypothèses simultanément ou déléguer des sous-tâches sans polluer son contexte principal. Le point clé : rendre cette parallélisation explicite et inspectable. Si les sorties des sous-agents sont stockées sous forme de fichiers et de logs, le modèle peut reprendre après interruption et raisonner sur son propre historique d’exécution.
Le harness, un levier pour l’auto-amélioration récursive
La prédiction qui monte : le chemin court terme vers la RSI ne passera pas par un modèle qui réécrit ses propres poids. Il passera par un harness qui devient lui-même la cible d’optimisation. On passe d’un système avec des règles heuristiques à un système avec des mécanismes génériques, capable de s’améliorer de façon autonome.
On a déjà observé une dynamique similaire avec le prompt engineering : les astuces manuelles ont perdu en centralité à mesure que le fine-tuning et le raisonnement des modèles progressaient. Mais le besoin de spécifier des objectifs, des contraintes, du contexte et des critères d’évaluation n’a pas disparu. Le harness engineering suit la même trajectoire, à l’échelle du système entier.
Optimiser le harness : du prompt à l’architecture
L’optimisation d’un harness suit une progression claire :
- Prompts d’instruction
- Contexte structuré
- Workflow
- Code du harness
- Code de l’optimiseur
Plus le modèle devient puissant, plus on peut s’attaquer à des cibles complexes avec des méthodes génériques. Des travaux récents l’illustrent.
ADAS (Automated Design of Agentic Systems) formule la conception d’agents comme un problème d’optimisation. Un méta-agent propose de nouveaux workflows, les teste, et enrichit une archive des meilleures solutions.
AFlow représente le workflow agent comme un graphe et l’optimise via une recherche arborescente Monte Carlo (MCTS). Les résultats sur des tâches de QA, de code et de mathématiques montrent des gains nets par rapport aux designs manuels.
Meta-Harness va encore plus loin : l’objet optimisé n’est plus le contexte ou le workflow, mais le code même qui détermine ce qu’il faut stocker, retrouver et présenter au modèle. Le méta-harness est un harness qui optimise des harness. Les expériences sur TerminalBench-2 le confirment : une fois que la conception du harness devient un espace de recherche exécutable, un agent de code compétent peut exploiter le même espace que les ingénieurs humains.
STOP (Self-Taught Optimizer) a montré qu’un améliorateur peut s’améliorer lui-même de manière récursive, découvrant des stratégies comme les algorithmes génétiques ou le recuit simulé. Attention toutefois : le gain n’est au rendez-vous qu’avec des modèles suffisamment puissants (GPT-4). Avec GPT-3.5 ou Mixtral, les performances se dégradent. La récursivité seule ne suffit pas.
Les écueils à connaître avant de se lancer
Ne nous emballons pas. Construire un harness, c’est aussi hériter de tous les problèmes du génie logiciel classique, amplifiés par l’imprévisibilité d’un LLM.
D’abord, l’évaluateur faible. Une suite de tests incomplète qui rapporte un succès total est pire qu’un évaluateur faiblard : elle donne l’illusion que tout va bien, pendant que l’agent continue sur sa lancée erronée en production. Pas de crash, pas d’erreur visible. Juste une confiance qui s’effrite silencieusement.
Ensuite, le fossé démo-production. Gartner estime que 40 % des projets d’IA agentique seront annulés d’ici 2027. La raison n’est pas que les modèles régressent. C’est que la démo fonctionne à merveille, et que l’illusion se fissure une fois en conditions réelles.
Enfin, la hype des builders. Le secteur a un problème étrange : ceux qui construisent les outils sont plus excités que ceux qui les utilisent. Une démo qui déclenche des standing ovations dans un meetup ne garantit pas une adoption massive.
Ce qu’il faut retenir
- Le harness engineering est la couche d’orchestration complète autour d’un LLM : workflow, évaluation, permissions, mémoire persistante.
- Les trois patterns clés sont la boucle d’automatisation, le système de fichiers comme mémoire, et les sous-agents parallèles.
- L’auto-amélioration récursive passera à court terme par l’optimisation du harness, pas par la réécriture directe des poids du modèle.
- Des frameworks comme ADAS, AFlow et Meta-Harness automatisent déjà la recherche de meilleurs designs de harness.
- Sans modèle de base suffisamment puissant, la récursivité n’apporte rien. Et sans évaluateurs robustes, le harness devient un amplificateur d’erreurs silencieuses.
Si ces sujets vous parlent et que vous explorez l’agentique en prod, échangeons sur LinkedIn ou en commentaire. Je partage régulièrement mes retours terrain sur ce blog.