Agent Harness : Pourquoi ton infrastructure IA compte plus que ton modèle en 2026

TL;DR : Un Agent Harness est l'infrastructure logicielle qui entoure un modèle IA pour orchestrer des tâches longues et complexes. Philipp Schmid a formalisé le concept en janvier 2026. L'idée centrale : les meilleurs modèles convergent en performance sur les benchmarks, mais la différence se fait sur la durabilité : la capacité à suivre des instructions après 50+ appels d'outils. Ton setup Cursor + fichiers .md + MCP est déjà un Agent Harness. Il est temps de le traiter comme tel.

---

Agent Harness : infrastructure logicielle qui entoure un modèle IA pour orchestrer des tâches longues. Le Harness gère le cycle de vie de l'agent (prompts, outils, hooks), optimise l'utilisation du contexte et assure la fiabilité sur des centaines d'appels d'outils. C'est l'équivalent d'un système d'exploitation pour agents IA.

Le constat : le modèle ne suffit plus

Si tu as lu mon Build in Public #12, tu sais que j'ai audité Sam Tennis intégralement depuis mon IDE. La bonne nouvelle : le workflow a fonctionné. Des dizaines de requêtes PostHog via MCP, des analyses de funnels, des croisements de données sur la rétention. Le tout sans ouvrir un seul dashboard.

La mauvaise nouvelle : ce n'est pas le modèle qui a fait la différence. C'est tout ce qu'il y a autour. Mes fichiers de contexte, mes connexions MCP, mon architecture BMAD, mes règles de code. Si j'avais donné la même tâche au même modèle dans un chat vide, il aurait perdu le fil après 5 minutes.

En janvier 2026, Philipp Schmid a publié un article qui met un nom sur cette réalité : l'Agent Harness. Et c'est un concept que tout Vibe Coder devrait connaître.

---

1. Le concept : ton Cursor est un système d'exploitation

L'analogie qui clarifie tout

Schmid utilise une analogie informatique simple et efficace :

• Le Modèle (Claude, GPT, Gemini) = le CPU. La puissance brute de calcul.
• La fenêtre de contexte = la RAM. La mémoire de travail, limitée et volatile.
• L'Agent Harness = le Système d'Exploitation. Il gère le contexte, lance la séquence de démarrage (prompts, hooks), fournit les drivers (gestion des outils).
• L'Agent = l'Application. Ta logique métier qui tourne par-dessus.

Tu ne juges pas un ordinateur uniquement sur son CPU. Un processeur puissant avec un OS instable, c'est inutile. C'est la même chose avec l'IA : un modèle performant dans un environnement mal structuré va halluciner, dériver et perdre le contexte.

Claude Code : le premier Harness grand public

Claude Code est l'exemple le plus concret d'Agent Harness aujourd'hui. Ce n'est pas juste un chat avec un modèle. C'est une infrastructure complète :

• Persistance du contexte entre les sessions
• Exécution d'outils (système de fichiers, terminal, recherche)
• Gestion des sous-agents pour les tâches complexes
• Hooks de cycle de vie (pré/post exécution)

Schmid va plus loin : tous les coding CLIs sont des Agent Harnesses spécialisés. Cursor, Windsurf, Cline, Aider... Chacun implémente sa propre façon de gérer le contexte, d'orchestrer les outils et de maintenir la cohérence sur la durée.

La différence entre un bon et un mauvais setup dans Cursor, c'est la qualité de ton Harness personnel : tes fichiers .md, ton .cursorrules, tes connexions MCP. Le modèle est le même pour tout le monde. L'infrastructure autour, c'est la tienne.

---

2. Le vrai problème : la durabilité, pas l'intelligence

Pourquoi les benchmarks sont trompeurs

On passe notre temps à comparer les modèles sur des leaderboards. Claude bat GPT sur SWE-Bench. GPT reprend l'avantage sur AIME. Gemini surpasse les deux sur le multimodal. Les écarts entre les modèles de tête se resserrent à chaque release.

Mais ces benchmarks mesurent des tâches courtes. Un puzzle à résoudre en un ou deux essais. Personne ne teste ce qui se passe après le 50e appel d'outil. Personne ne mesure si le modèle suit encore tes instructions initiales après une heure de travail continu.

C'est la durabilité : la capacité d'un modèle à rester fiable, cohérent et aligné sur la durée. Et c'est exactement ce que les benchmarks actuels ne capturent pas.

Le model drift : le bug invisible

Le scénario classique : tu démarres une session Cursor. Les 20 premières minutes, tout est parfait. Le modèle respecte tes conventions, utilise les bons patterns, suit ton architecture. Et puis, petit à petit, il commence à dériver. Il oublie une règle. Il réintroduit un pattern que tu avais interdit. Il invente un import qui n'existe pas.

C'est le model drift. Plus la tâche est longue, plus le risque augmente. Un Agent Harness bien conçu combat ce phénomène en :

• Compactant le contexte : résumer les étapes passées pour libérer de la "RAM"
• Isolant les tâches : déléguer à des sous-agents avec un contexte frais
• Réinjectant les instructions critiques : rappeler les règles à intervalles réguliers

C'est exactement le rôle de mes fichiers tech_rules.md et .cursorrules sur Sam Tennis. Ils ne sont pas là pour expliquer des concepts au modèle. Ils sont là pour l'empêcher de dériver.

---

3. La Bitter Lesson : pourquoi la simplicité gagne toujours

Le principe

Rich Sutton a écrit un essai célèbre en IA : The Bitter Lesson. Sa thèse : les méthodes générales qui exploitent la puissance de calcul battent systématiquement le savoir codé en dur par des humains.

Appliqué aux agents IA, la leçon est brutale : chaque pipeline complexe, chaque logique de contrôle codée en dur, chaque garde-fou artisanal que tu construis aujourd'hui sera rendu obsolète par la prochaine mise à jour du modèle.

Les preuves en 2026

Vercel a publié un cas d'étude sur leur agent text-to-SQL interne. Ils avaient construit 16 outils spécialisés : validation de schéma, récupération d'erreurs, clarification d'intention, validateurs de syntaxe. Le système marchait, mais il était fragile et lent.

Leur décision : supprimer 80% des outils et donner au modèle un accès direct aux fichiers bruts via le terminal.

Les résultats :

• Taux de réussite : de 80% à 100%
• Temps de réponse : divisé par 3,5 (de 274s à 77s)
• Consommation de tokens : -37%
• Nombre d'étapes : -42%

Moins d'outils, moins de contrôle, de meilleurs résultats. La Bitter Lesson en action.

Vercel n'est pas un cas isolé :

• Manus a refactorisé son Harness 5 fois en 6 mois pour supprimer des hypothèses rigides
• LangChain a reconstruit son agent "Open Deep Research" 3 fois en un an

Ce que ça m'a appris sur mon propre setup

En relisant ma propre évolution sur Make Time, je retrouve la même trajectoire :

• BIP #2 : je donnais des prompts de 200 lignes avec des instructions ultra-détaillées. Résultat moyen.
• BIP #10 : j'ai externalisé tout ça dans des fichiers Markdown + connexion MCP Notion. Le code généré s'est amélioré immédiatement.
• File Engineering : j'ai appris à être concis. Réduire tech_stack.md de 120 à 35 lignes a augmenté la qualité. Moins de bruit, plus de signal.
• BIP #11 : la méthode BMAD m'a appris à laisser l'IA planifier au lieu de tout lui dicter.

À chaque étape, j'ai retiré du contrôle. Et à chaque étape, les résultats se sont améliorés. La Bitter Lesson, appliquée à mon scale de Solo Builder.

---

4. Les 3 principes : construire ton Agent Harness

Schmid conclut son article avec trois principes. Je les reprends ici avec mon interprétation pratique.

Principe 1 : Start Simple (Commence simple)

Ne construis pas de systèmes de contrôle massifs. Fournis des outils atomiques et robustes. Laisse le modèle faire le plan. Implémente des garde-fous, des retries et des vérifications.

En pratique dans Cursor :

• Un fichier tech_stack.md concis (35 lignes max)
• Un .cursorrules avec tes conventions de code
• Le MCP connecté aux outils que tu utilises vraiment (PostHog, Supabase, Notion)
• Pas de pipeline complexe entre toi et le modèle

C'est contre-intuitif. On a envie de tout cadrer, tout contrôler. Mais le message de Vercel est clair : le modèle avec accès aux données brutes surpasse le modèle emprisonné dans 16 outils spécialisés.

Principe 2 : Build to Delete (Construis pour supprimer)

Rends ton architecture modulaire. Chaque nouveau modèle va rendre une partie de ta logique obsolète. Tu dois pouvoir supprimer du code sans tout casser.

C'est exactement ce que j'ai vécu avec la méthode BMAD. Quand j'ai structuré Sam Tennis V2 avec des agents spécialisés (PM, Architecte, Dev, QA), j'ai découpé le système en modules indépendants. Quand Claude a amélioré sa gestion du contexte entre deux releases, j'ai pu supprimer un module de planification manuelle sans toucher au reste.

La règle : si tu ne peux pas supprimer un composant de ton setup en moins d'une heure, ton architecture est trop couplée.

Principe 3 : The Harness is the Dataset (Le Harness est le jeu de données)

C'est le principe le plus stratégique. L'avantage compétitif n'est plus dans le prompt. Il est dans les trajectoires que ton Harness capture.

Chaque fois que ton agent échoue à suivre une instruction en fin de session, c'est une donnée. Chaque dérive du modèle, chaque hallucination, chaque correction que tu apportes dans ton fichier rules.md enrichit ton Harness.

C'est la boucle feedback que j'ai décrite dans le guide File Engineering : à chaque bug résolu, tu demandes à l'IA "Comment aurais-je dû formuler ma demande pour éviter ce problème ?". La réponse va dans rules.md. Ton système s'améliore à chaque erreur.

Au bout de 12 chapitres de Build in Public, mon Harness personnel contient des dizaines de règles apprises par l'expérience. Personne ne peut copier ça. Ces règles encodent mes erreurs, mes projets, mes contraintes. C'est un avantage compétitif organique.

---

Conclusion : Le Harness, pas le modèle

Le prochain modèle qui sortira sera meilleur. Et celui d'après aussi. Les benchmarks vont continuer à s'améliorer. Mais si tu passes ton temps à choisir entre Claude et GPT au lieu de structurer ton environnement de travail, tu optimises le mauvais paramètre.

L'article de Schmid cristallise ce que j'ai constaté sur mes propres projets depuis un an : le Context Engineering a remplacé le Prompt Engineering. Le fichier .md bien structuré bat le prompt parfait. Le MCP connecté bat le copier-coller de données. L'architecture modulaire bat le monolithe hyper-optimisé.

Pour les Solo Builders, c'est une bonne nouvelle. Tu n'as pas besoin de l'infrastructure de Google pour construire un bon Harness. Tu as besoin de fichiers Markdown, d'un IDE connecté et de la discipline de documenter tes erreurs. C'est une compétence accessible. Et c'est celle qui fera la différence en 2026.

À très vite, Guillaume 👋

---

Questions fréquentes

C'est quoi un Agent Harness exactement ?

Un Agent Harness est l'infrastructure logicielle qui entoure un modèle IA pour gérer les tâches longues et complexes. Il gère les prompts, les outils, le cycle de vie de l'agent et optimise le contexte. L'analogie la plus claire : si le modèle est le CPU d'un ordinateur, l'Agent Harness est le système d'exploitation. Le concept a été formalisé par Philipp Schmid en janvier 2026.

Est-ce que Cursor est un Agent Harness ?

Oui. Cursor est un Agent Harness spécialisé pour le développement logiciel. Il gère le contexte (fichiers .md, .cursorrules), orchestre les outils (terminal, système de fichiers, MCP), et maintient la cohérence entre les sessions. La qualité de ton Harness Cursor dépend directement de la structure de tes fichiers de contexte et de tes connexions MCP. J'en parle en détail dans le guide File Engineering.

Quelle est la différence entre Context Engineering et Prompt Engineering ?

Le Prompt Engineering se concentre sur la formulation des instructions (le "comment dire"). Le Context Engineering se concentre sur la gestion de toutes les informations que le modèle reçoit (le "quoi donner") : prompts, mémoire, outils, données récupérées, historique. C'est un niveau d'abstraction au-dessus. Structurer un fichier tech_stack.md de 35 lignes chirurgicales, c'est du Context Engineering. Formuler un prompt parfait, c'est du Prompt Engineering. Le premier a plus d'impact que le second.

Comment je construis mon propre Agent Harness dans Cursor ?

Commence par 3 fichiers à la racine de ton projet : tech_stack.md (tes technologies, 35 lignes max), rules.md (les conventions de code), et tasks.md (les tâches en cours). Connecte au moins un MCP (Supabase, Notion, ou PostHog). Applique la boucle feedback : après chaque bug, mets à jour rules.md avec la leçon apprise. En quelques semaines, ton Harness connaîtra les subtilités de ton projet. Le processus complet est dans mon Build in Public #10.

---

Pour aller plus loin

• File Engineering : Le Guide d'Anthropic qui change tout
• Guide Cursor 2026 : de l'idée au code
• Protocol MCP : connecter l'IA à tes données
• Méthode BMAD : structurer le Vibe Coding
• Guide PostHog : comprendre tes utilisateurs
• Source originale : "The importance of Agent Harness in 2026" (Philipp Schmid)

---