En 2026, une nouvelle forme de consensus apparaît dans l’industrie de l’IA : ce qui détermine si un produit d’IA est bon ou non n’est plus le modèle lui-même, mais la couche située autour du modèle, appelée « harness ». Quand les modèles de base utilisés par Claude Code, Cursor et OpenClaw se rapprochent de plus en plus, ce qui creuse réellement l’écart entre les produits, c’est la conception du harness. Le blog technique de Martin Fowler, l’annonceur responsable produit d’Anthropic trq212, ainsi que les déclarations récentes d’Andrej Karpathy pointent tous dans la même direction : le prochain champ de bataille de l’IA, c’est l’Ingénierie du Harness.
Qu’est-ce qu’un Agent Harness
Un agent IA peut être décomposé en deux parties : le modèle (Model) et le harness. Le modèle est le cerveau, chargé de comprendre le langage et d’effectuer le raisonnement. Le harness, c’est tout ce qui existe en dehors du modèle : appels d’outils, gestion de la mémoire, assemblage du contexte, persistance de l’état, gestion des erreurs, garde-fous de sécurité, planification des tâches, gestion du cycle de vie.
Prenons une analogie intuitive : le LLM est un cheval, et le harness est l’équipement du cheval — les rênes, la selle et la structure de connexion entre le cheval et la carriole. Sans l’équipement, même un cheval très puissant ne peut pas tirer la carriole. Un agent IA fonctionne pareil : même si le modèle est très intelligent, sans un bon harness, il ne peut pas accomplir de manière fiable des tâches réelles.
Akshay Pachaar propose dans un tweet largement relayé une autre analogie : « Un LLM nu ressemble à un CPU sans système d’exploitation — il sait calculer, mais il ne peut pas faire quoi que ce soit d’utile par lui-même. » Le harness, c’est ce système d’exploitation.
Pourquoi l’Ingénierie du Harness est soudain devenue aussi importante en 2026
Il y a trois raisons :
Premièrement, les capacités des modèles tendent à s’homogénéiser. L’écart entre GPT-5.4, Claude Opus 4.6 et Gemini 3.1 Pro sur la plupart des tests de référence s’est déjà réduit à quelques points de pourcentage. Quand le modèle n’est plus le goulot d’étranglement, la différenciation produit se déplace naturellement vers la couche harness.
Deuxièmement, l’agent passe de l’expérimentation à la production. En 2025, la plupart des agents étaient des démos ; en 2026, les agents doivent tourner dans des environnements d’entreprise — ils doivent gérer la reprise après interruption, des exécutions longues, des tâches multi-étapes, le contrôle des permissions. Tout cela relève du harness.
Troisièmement, les LLM sont nativement sans état. À chaque nouvelle session, tout repart de zéro : le modèle ne se souvient pas de la conversation précédente. Le harness est chargé de persister la mémoire, le contexte et l’avancement du travail, afin que l’agent puisse travailler continûment comme un véritable « collègue ».
Les composants clés d’un Harness
Un harness d’agent complet comprend généralement les couches suivantes :
Composant Fonction Analogies Orchestration Loop Contrôle la boucle « pensée → action → observation » de l’agent La boucle principale d’un système d’exploitation Tool Management Gère les outils que l’agent peut utiliser (lecture/écriture de fichiers, appels API, opérations de navigateur, etc.) Pilote/driver Context Engineering Détermine quelles informations envoyer au modèle à chaque appel, et lesquelles découper Gestion de la mémoire State Persistence Enregistre la progression du travail, l’historique des conversations, les résultats intermédiaires Disque dur Error Recovery Détecte les échecs et retente automatiquement ou fait marche arrière Gestion des exceptions Safety Guardrails Limite le périmètre des actions de l’agent pour éviter les opérations dangereuses Pare-feu Verification Loops Permet à l’agent de s’auto-vérifier sur la qualité de ses sorties Tests unitaires
Trois couches d’ingénierie : Prompt, Context et Harness
Les pratiques d’ingénierie autour des LLM peuvent être réparties en trois couches concentriques :
La couche la plus interne est le Prompt Engineering — la conception des instructions envoyées au modèle, qui détermine « comment il raisonne ». C’est la compétence dominante en 2023.
La couche intermédiaire est le Context Engineering — la gestion de « ce que le modèle voit ». Elle détermine quelles informations envoyer dans la fenêtre de contexte, et à quel moment, ainsi que quelles informations doivent être découpées. Avec l’extension de la fenêtre de contexte jusqu’à des millions de tokens, l’importance de cette couche apparaît à partir de 2025.
La couche la plus externe est le Harness Engineering — elle englobe les deux premières, en plus de toute l’infrastructure de base de l’application : orchestration des outils, persistance de l’état, récupération après erreurs, boucles de vérification, mécanismes de sécurité, gestion du cycle de vie. C’est le champ de bataille central en 2026.
Exemple : pourquoi le même modèle se comporte si différemment selon les produits
Claude Opus 4.6 peut, dans Claude Code, passer une petite heure à restructurer l’ensemble de la base de code. Mais en branchant le même modèle via une API sur un harness rudimentaire, il peut ne même pas réussir à effectuer une correction de bug qui traverse plusieurs fichiers. La différence n’est pas dans le modèle : elle est dans le harness.
Que fait le harness de Claude Code ?
Recherche automatique dans toute la base de code pour trouver les fichiers pertinents, au lieu de demander à l’utilisateur d’en spécifier un par un
Lire le contenu des fichiers avant de modifier, puis exécuter des tests pour valider après modification
En cas d’échec des tests, analyser automatiquement l’erreur et retenter
Se connecter à des outils externes via MCP (GitHub, bases de données, etc.)
Système de mémoire : conserver les préférences utilisateur et le contexte du projet d’une session à l’autre
Stratégie d’Advisor : faire coopérer des modèles ayant des capacités différentes, chacun dans son rôle
Tout cela, c’est le mérite du harness.
Feedforward et Feedback : deux modes de contrôle du Harness
D’après l’analyse du blog technique de Martin Fowler, les mécanismes de contrôle du harness se répartissent en deux catégories :
Feedforward (contrôle en amont) — fixer des règles avant l’action de l’agent afin de prévenir les sorties indésirables. Par exemple : les règles de conduite dans le system prompt, les listes blanches d’outils, les autorisations d’accès aux fichiers.
Feedback (contrôle en retour) — vérifier les résultats après l’action de l’agent, et autoriser l’auto-correction. Par exemple : exécuter des tests pour confirmer que le code est correct, comparer les sorties au format attendu, détecter les hallucinations et régénérer.
Un bon harness utilise les deux types de contrôle à la fois : il limite le périmètre des actions tout en conservant de la flexibilité.
Industrialisation du Harness Engineering : comment le fait Anthropic
Les mises à jour produit intensives lancées par Anthropic en avril 2026 sont presque toutes de la « productisation » de l’ingénierie du harness :
Managed Agents — transformer l’infrastructure du harness (sandbox, planification, gestion de l’état) en service managé, et faire en sorte que les développeurs n’aient plus qu’à définir le comportement de l’agent
Advisor strategies — architecture de mélange de modèles au niveau du harness, qui détermine automatiquement quand il faut consulter un modèle plus puissant
Cowork édition entreprise — fournir un harness complet aux utilisateurs non techniques (contrôle des permissions, gestion des dépenses, analytics d’utilisation), afin qu’ils n’aient pas besoin de comprendre la technologie sous-jacente
Les formulations du responsable produit d’Anthropic trq212 sont les plus précises : « Le prompting est une compétence pour dialoguer avec l’agent, mais il est médié par le harness. Mon objectif central est d’augmenter la bande passante entre l’humain et l’agent. »
Ce que cela signifie pour les développeurs : nouveaux métiers et nouvelles compétences
L’Ingénierie du Harness devient un domaine d’ingénierie indépendant. L’ensemble de compétences dont elle a besoin est différent de celui de l’ingénierie backend traditionnelle ou de l’ingénierie ML :
Comprendre les limites de capacité des LLM et leurs modes d’échec
Concevoir des processus fiables d’appels d’outils et de gestion des erreurs
Gérer la context window — quoi insérer, quand
Construire de l’observabilité — tracer les trajectoires décisionnelles de l’agent et l’utilisation des outils
Concevoir la sécurité — limiter le périmètre des actions de l’agent sans étouffer ses capacités
Pour ceux qui apprennent le Vibe Coding ou utilisent des outils IA pour développer, comprendre la notion de harness vous aidera à mieux collaborer avec les agents IA — parce que vous saurez si le problème vient du modèle ou du harness, et comment améliorer les résultats en ajustant les paramètres du harness (plutôt qu’en modifiant sans cesse le prompt).
Conclusion : la bataille pour les infrastructures de la prochaine décennie
La concurrence des modèles d’IA ne s’arrêtera pas, mais les gains marginaux diminuent. La concurrence au niveau du harness ne fait que commencer : celui qui saura construire le harness le plus fiable, le plus flexible et le plus sûr, pourra transformer les mêmes capacités de modèle en une meilleure expérience produit.
C’est aussi ce qui explique pourquoi Anthropic, OpenAI et Google passent de « sociétés de modèles » à « sociétés de plateforme » — ce qu’ils vendent n’est plus seulement une API de modèle, mais une infrastructure complète de harness. Pour les développeurs, comprendre l’ingénierie du harness n’est pas une option : c’est une compétence fondamentale pour construire des produits à l’ère de l’IA.
Cet article « Qu’est-ce que l’Ingénierie du Harness ? Le prochain champ de bataille de l’IA n’est pas le modèle, mais l’architecture en dehors du modèle » est apparu en premier sur la chaîne ABMedia.
