Le harness, pas le modèle : ce qui détermine vraiment vos agents IA

Un agent passe du Top 30 au Top 5 d'un benchmark de référence. Sans changer de modèle. Sans un seul dollar supplémentaire de compute. Uniquement en reconfigurant ce qui entoure le modèle.

C'est l'expérience documentée sur Terminal Bench 2.0 par des équipes qui ont commencé à travailler sérieusement sur ce que le secteur appelle désormais le Harness Engineering. Une autre équipe a gagné 13,7 points sur le même benchmark en ajustant uniquement le system prompt, les outils disponibles et le middleware, avec un modèle identique. Ces chiffres posent une question inconfortable : si les équipes passent l'essentiel de leur temps à choisir et négocier leurs contrats de modèles, travaillent-elles sur le bon problème ?

Ce que les équipes confondent systématiquement

Quand un agent fait une erreur, le premier réflexe est d'accuser le modèle. Attendre la prochaine version. Switcher vers un concurrent. C'est compréhensible, mais la plupart du temps, c'est inexact.

Une analyse publiée par Google en mai 2026 sur le nouveau SDLC agentique propose une équation simple : Agent = Modèle + Harness. Le modèle est le moteur brut. Le harness, c'est la voiture, la route et le code de la route. Un moteur Formule 1 sans châssis, sans pneus et sans freins ne finit pas la course.

Le harness regroupe tout ce qui encadre le modèle : les fichiers d'instructions et de règles (CLAUDE.md, AGENTS.md), les outils et serveurs MCP auxquels l'agent peut accéder, les environnements sandbox d'exécution, la logique d'orchestration et de délégation entre sous-agents, les guardrails et hooks déterministes, et l'observabilité complète (logs, traces, coût, latence). Selon les mesures disponibles, le modèle représente environ 10% du comportement observable d'un agent en production. Le harness, les 90% restants.

La conséquence pratique : la plupart des échecs d'agents sont des échecs de configuration, pas des échecs du modèle. Un outil manquant. Une règle vague. Un guardrail absent. Un contexte saturé de bruit. Ce sont ces éléments que l'équipe contrôle, pas le fournisseur.

Le Factory Model : le développeur ne produit plus du code

Pour comprendre pourquoi le harness est central, il faut changer de cadre mental sur ce que produit un développeur en 2026.

Dans le modèle traditionnel, le développeur écrit du code. Dans le modèle agentique, le développeur conçoit le système qui produit du code. C'est ce que le rapport Google appelle le Factory Model : l'analogie d'un directeur d'usine qui ne fabrique pas lui-même chaque pièce, mais conçoit la chaîne d'assemblage, définit les contrôles qualité et s'assure que chaque sortie respecte les standards.

Le "Developer Zone" regroupe : définir les specs, concevoir les guardrails, valider les outputs. L'"Agent Factory Floor" exécute : un Planning Agent structure le travail, un Coding Agent implémente, un système de Tests & Verification valide, et les échecs sont renvoyés en feedback loop automatique. Le développeur n'est plus dans la boucle d'implémentation, il est dans la boucle de supervision.

Ce changement a une implication directe sur les compétences valorisées. La question n'est plus "combien de lignes de code écris-tu ?" mais "à quel point tes specs sont-elles précises, tes tests exhaustifs, tes guardrails bien calibrés ?" Les développeurs les plus efficaces dans les équipes qui ont adopté ce modèle sont ceux qui savent déléguer avec précision, pas ceux qui codent le plus vite.

Conductor et Orchestrator : deux modes, pas deux rôles

En pratique, un même développeur alterne entre deux postures selon la nature de la tâche. Le rapport Google les nomme conductor et orchestrator.

Le conductor travaille en temps réel, synchronisé, dans son IDE. Il voit le code apparaître, guide l'agent keystroke par keystroke, maintient un contrôle granulaire sur chaque changement. C'est le mode naturel pour du code complexe, du debugging sur des systèmes qu'on ne connaît pas bien, ou de l'exploration. Les outils qui supportent ce mode — GitHub Copilot, Cursor, Windsurf, Gemini Code Assist — sont aujourd'hui les plus répandus. Le risque est identifié : si le développeur dirige chaque keystroke, le gain de productivité de l'IA est mécaniquement limité.

L'orchestrator opère à un niveau d'abstraction supérieur. Il définit un objectif, l'assigne à un ou plusieurs agents, et revient examiner les outputs. Les agents travaillent en parallèle, en arrière-plan, parfois pendant des heures. Le développeur valide, corrige la trajectoire, approuve les PRs. Ce mode est adapté aux tâches bien définies : corrections de bugs documentés, implémentation de features contre des patterns établis, migrations de framework, génération de suites de tests. Les outils de ce registre incluent Google Jules, GitHub Copilot agent mode, et les terminaux agentiques comme Claude Code ou Codex CLI.

La plupart des développeurs utilisent les deux modes dans une même journée. Ce n'est pas un choix d'outil, c'est un choix de posture selon la tâche. La maturité opérationnelle d'une équipe se mesure notamment à sa capacité à distinguer explicitement quand utiliser l'un ou l'autre.

Le problème des 80% : ce que les benchmarks ne montrent pas

Les études de productivité annoncent régulièrement 25 à 39% de gains sur les tâches de développement. Une étude METR publiée en juillet 2025 apporte une nuance importante : des développeurs expérimentés utilisant des assistants IA (Cursor Pro + Claude 3.5/3.7) ont pris 19% de temps supplémentaire sur certaines tâches, en raison du temps passé à vérifier, débugger et corriger les outputs. La mise à jour de février 2026 nuance ce résultat : avec les outils late-2025, les développeurs sont probablement plus rapides, mais la biais de sélection (les développeurs refusaient de travailler sans IA) a rendu la mesure peu fiable. Ce que les deux études confirment : l'IA ne supprime pas le travail d'implémentation, elle le transforme en travail de review, guidage et vérification.

Ce paradoxe s'explique par ce que le même rapport nomme le "80% problem". Les agents génèrent rapidement environ 80% du code d'une feature. Les 20% restants — edge cases, gestion d'erreurs, points d'intégration, exigences de correctness subtiles — demandent une connaissance contextuelle profonde que les modèles actuels ne possèdent pas. Et la nature des erreurs a évolué : on ne voit plus de fautes de syntaxe. On voit du code qui "a l'air correct", passe les tests basiques, mais intègre des hypothèses fausses sur la business logic ou crée des charges de maintenance invisibles.

La posture qui fonctionne : utiliser l'IA pour ce qu'elle fait bien (implémentation rapide de tâches bien spécifiées) et réserver son attention aux domaines où elle échoue (exigences ambiguës, trade-offs architecturaux, vérification de correctness). Ne pas essayer d'aller plus vite en acceptant tout ce que l'agent produit. Aller plus vite en concentrant son expertise là où elle crée le plus de valeur.

Output evaluation vs trajectory evaluation : la distinction qui change tout en testing

Tester du code généré par un agent ne se limite pas à vérifier que les tests passent. C'est l'évaluation de l'output, et elle est nécessaire mais insuffisante.

Il faut aussi évaluer la trajectoire : la séquence complète d'appels d'outils et le raisonnement intermédiaire que l'agent a suivi pour arriver au résultat. Un output fluide qui a sauté ses étapes de vérification est plus dangereux qu'un output qui a clairement échoué — parce que la première erreur est invisible et arrive en production.

Les équipes qui ont mis en place cette double évaluation définissent des rubrics explicites : succès de la tâche, qualité d'utilisation des outils, conformité de trajectoire, absence d'hallucinations dans les dépendances, couverture des modes d'échec réalistes. La règle posée par Google pour les engineering leaders est claire : une démo qui fonctionne prouve que l'agent peut réussir une fois. Une suite d'evals avec rubric démontre qu'il réussit de façon fiable. Les deux ne sont pas interchangeables.

L'économie réelle du SDLC agentique

La conversation sur l'IA dans le développement commence et finit souvent par la vélocité. Pour un décideur, la métrique pertinente est le coût total de possession (TCO).

Le vibe coding — utiliser un agent avec un minimum de structure, en mode prompt-and-accept — semble peu coûteux : faible investissement initial, premiers résultats rapides. Mais cette approche accumule trois charges opérationnelles compounding : le token burn rate (des prompts non structurés créent des boucles d'essai-erreur qui brûlent des tokens à faible taux de succès au premier passage), la maintenance tax (du code généré par prompting ad hoc manque de cohérence structurelle et coûte des jours à débugger six mois plus tard), et le security remediation (sans harness d'évaluation automatique, la génération rapide de code crée une génération rapide de vulnérabilités, exponentiellement plus coûteuses à corriger en production qu'en phase de conception).

L'agentic engineering inverse ce modèle. L'investissement initial est plus élevé : concevoir les schemas d'API, construire les suites de tests déterministes, structurer le contexte de l'agent. En échange, le coût marginal par feature chute significativement. Les équipes qui ont croisé ce point d'inflexion rapportent que le vibe coding coûte 3 à 10 fois plus par feature sur la durée, contre l'agentic engineering sur une codebase mature.

Un levier complémentaire souvent sous-exploité : le model routing intelligent. Utiliser un grand modèle frontier pour les tâches à haute complexité (requirements, architecture, implémentation initiale) et router automatiquement vers des modèles plus petits et moins coûteux les tâches déterministes (génération de tests, revue de code stylistique, monitoring CI). Une factory bien conçue orchestre un écosystème multi-modèles plutôt que de tout passer par un seul modèle premium.

Ce que ça implique pour les équipes engineering

Trois implications pratiques se dégagent pour les équipes qui veulent passer du vibe coding à l'agentic engineering.

Traiter le context engineering comme une pratique d'ingénierie à part entière. Les fichiers de règles, system prompts, eval suites et bibliothèques de skills doivent être versionnés avec le projet, reviewés en PR, et appartenir à des ingénieurs nommés. Sans cette discipline, le harness dérive et le comportement des agents devient irreproductible d'un run à l'autre.

Distinguer explicitement le travail de prototypage du travail de production dans les normes d'équipe. Le vibe coding est valide pour l'exploration et les preuves de concept. L'agentic engineering est obligatoire pour tout ce qui ship. Laisser cette frontière floue produit des prototypes qui partent en production par accident.

Reframer le recrutement et le développement des compétences autour du jugement, pas de l'implémentation. À mesure que l'implémentation devient plus rapide et plus automatisée, le goulot d'étranglement se déplace vers la spécification, l'évaluation, le jugement architectural et la revue. Les ingénieurs les plus précieux dans les prochaines années seront ceux qui savent diriger des agents avec précision, pas ceux qui écrivent le plus de code.

La formule de conclusion du rapport Google capte l'essentiel : "Generation is solved. Verification, judgment, and direction are the new craft."

Sources

• Osmani, A., Saboo, S., Kartakis, S., "The New SDLC With Vibe Coding," Google, mai 2026
• METR, "Uplift Update: Measuring the Impact of AI Coding Tools," février 2026, https://metr.org/blog/2026-02-24-uplift-update/
• Osmani, A., "The Factory Model," https://addyosmani.com/blog/factory-model/
• Osmani, A., "The 80% Problem in Agentic Coding," https://addyo.substack.com/p/the-80-problem-in-agentic-coding
• Terminal Bench 2.0 — résultats d'optimisation harness documentés dans le paper Google
• Deloitte, "AI in Software Engineering: Productivity Gains 2025-2026" — projection 30-35% gains