›Le harness pèse autant que les weights. Peut-être plus.

La question qu'on ne pose pas assez

Depuis deux ans, le marché de l'IA s'est organisé autour d'une question unique : quel modèle choisir ? GPT-4o ou Claude 3.7 ? Mistral Large ou DeepSeek V3 ? Les équipes techniques passent des heures sur des comparatifs, des tableaux, des évaluations internes. Et c'est légitime — le modèle compte.

Sauf que cette question est incomplète. Un modèle de langage, pris seul, ne peut rien faire. Il répond à un prompt, produit du texte, et s'arrête là. Pour qu'il devienne un agent capable de corriger un bug, d'écrire une suite de tests ou d'analyser une base de code complète, il a besoin d'une infrastructure autour de lui. Cette infrastructure, c'est ce que les praticiens de l'agentique appellent le harness.

Le harness, c'est tout ce que le modèle ne fait pas seul : la gestion du contexte sur une longue tâche, l'accès aux fichiers et aux outils de développement, la mémoire de travail entre les étapes, la détection et la correction des erreurs en cours de route, et la capacité à ne pas perdre de vue l'objectif initial quand les logs commencent à s'accumuler. Sans harness, même le meilleur modèle du moment échoue sur les tâches réelles.

Agent = Modèle + Harness

L'équation est simple, mais ses implications sont profondes. Si on considère le modèle comme le moteur d'un véhicule, le harness est tout le reste : le châssis, la boîte de vitesse, les capteurs, le tableau de bord. Un moteur haute performance posé sur un sol nu ne mène nulle part. C'est la voiture entière qui transporte des passagers.

Concrètement, un harness bien construit gère trois choses que le modèle ne peut pas gérer seul.

La première est la fenêtre de contexte. Sur une tâche longue, le modèle reçoit progressivement des dizaines de milliers de tokens : messages précédents, fichiers lus, sorties de commandes, traces d'erreur. Sans gestion active, l'objectif initial se noie dans ce bruit. Les chercheurs appellent ça le « context rot » ou le phénomène « lost in the middle » : le modèle voit le début et la fin de son contexte avec précision, mais ce qui se trouve au centre perd de l'influence. Le harness résout ça en sélectionnant, résumant et structurant activement l'information pertinente.

La deuxième est l'orchestration des outils. Un agent de développement interagit avec des fichiers, des APIs, des terminaux, des bases de code. Chaque appel d'outil peut échouer, renvoyer un format inattendu ou déclencher une cascade d'effets. Le harness joue un rôle de médiateur : il valide les appels avant exécution, gère les erreurs de façon structurée, et empêche les « hallucinations d'outils » où le modèle invente des réponses plutôt que d'en attendre de vraies.

La troisième est la persistance de l'état. Une tâche complexe prend plusieurs minutes, parfois davantage. L'agent peut être interrompu, le contexte peut être tronqué, une étape peut échouer. Le harness gère les checkpoints, la reprise après interruption, et les mécanismes de validation humaine quand c'est nécessaire. Sans ça, l'agent recommence depuis zéro à chaque problème.

Ce que dit Terminal-Bench 2

Le plus court chemin vers la réalité, c'est les benchmarks. Terminal-Bench 2 est aujourd'hui la référence pour évaluer les agents de développement : il mesure la capacité d'un agent à mener des workflows complets en ligne de commande jusqu'à leur résolution, sur des tâches représentatives du travail d'ingénierie réelle. Ce n'est pas un benchmark de compréhension de texte ou de raisonnement abstrait. C'est un test de l'agent complet, modèle plus harness, face à des problèmes concrets.

Les résultats sont éloquents. Avec le même modèle sous-jacent, un harness optimisé fait passer le taux de succès en première tentative (pass@1) de 69,7 % à 77,0 %. Pour référence, Codex-CLI, dont le harness a été conçu manuellement par des ingénieurs expérimentés, atteint 71,9 %. Un harness mieux pensé dépasse donc un harness manuel avec plusieurs mois de développement derrière lui, sans aucun changement sur le modèle.

Ce chiffre mérite qu'on s'y arrête. Sur Terminal-Bench 2, la différence entre un agent qui réussit sept tâches sur dix et un agent qui en réussit presque huit n'est pas dans le modèle. Elle est dans la façon dont ce modèle est encapsulé, outillé et guidé. Pour une équipe de développement de cinquante personnes qui utilise cet agent toute la journée, cette différence de sept points de pass@1 se traduit en dizaines de tâches quotidiennes qui aboutissent au lieu d'échouer.

Le même constat se retrouve sur SWE-bench, l'autre benchmark de référence pour la résolution d'incidents logiciels réels sur des dépôts GitHub. Un harness mieux conçu y permet également de réduire la consommation de tokens de 12 % par rapport à une configuration initiale. Moins de tokens pour un meilleur résultat : c'est à la fois plus efficace et moins coûteux.

Pourquoi le même modèle donne des résultats si différents selon le terminal

Cette question déroute souvent les équipes qui s'attendent à ce qu'un modèle se comporte de façon identique d'un outil à l'autre. Si un développeur obtient de bons résultats avec Claude directement via l'API et des résultats médiocres avec un outil de coding intégré utilisant le même modèle, c'est rarement un problème de modèle. C'est un problème de harness.

Plusieurs facteurs expliquent cet écart. La façon dont le contexte de la tâche est transmis au modèle varie énormément d'un outil à l'autre. Certains injectent les fichiers en bloc au début de la conversation ; d'autres les envoient progressivement selon la pertinence. Certains incluent l'historique complet des messages ; d'autres le tronquent ou le résument. Le modèle, lui, traite ce qu'on lui donne — s'il reçoit du bruit, il produit du bruit.

La gestion des erreurs joue aussi un rôle critique. Quand une commande shell échoue avec un message d'erreur cryptique, comment le harness le présente-t-il au modèle ? Envoie-t-il le log brut, ou interprète-t-il l'erreur pour guider la correction ? Relance-t-il automatiquement, ou attend-il une instruction explicite ? Ces décisions d'architecture déterminent si l'agent rebondit efficacement ou tourne en rond.

Enfin, la façon dont les outils de développement sont exposés au modèle — lecture de fichiers, écriture, exécution de tests, recherche dans le codebase — conditionne toute la qualité du raisonnement. Un modèle qui peut lire un fichier de façon granulaire (par fonction, par bloc logique) travaille mieux qu'un modèle qui doit ingérer le fichier entier à chaque fois. Ce n'est pas de la magie : c'est de l'ingénierie d'infrastructure.

Pourquoi Souver a fait du harness un pari stratégique

Quand on construit une suite IA pour des grands comptes français, on peut choisir de concurrencer les labs américains sur les weights. C'est perdu d'avance. Anthropic, OpenAI et Google ont des milliers d'ingénieurs dédiés à l'entraînement des modèles, des milliards de dollars de compute, et plusieurs années d'avance sur les données propriétaires. Ce n'est pas un terrain où une startup peut gagner.

La vraie question pour Souver n'était pas « quel modèle construire ? » mais « quelle infrastructure construire pour que les meilleurs modèles open-weights du moment produisent des résultats d'un niveau frontalier ? » C'est une question d'ingénierie, pas de compute. Et c'est là que le terrain est équitable.

Concrètement, cela se traduit par une approche où le modèle est traité comme une pièce interchangeable. Kimi, DeepSeek, Qwen, Mistral, Llama : ce qui change d'un modèle à l'autre, c'est principalement la performance sur certaines tâches, la longueur de contexte et le coût d'inférence. Le harness, lui, reste stable. Et c'est le harness qui détermine si l'agent conduit réellement une tâche de développement jusqu'à son terme, ou s'il s'arrête à mi-chemin en produisant un résultat plausible mais incomplet.

Cette décision est aussi cohérente avec le positionnement souveraineté de Souver, éclairé par l'audition d'Arthur Mensch à l'Assemblée. Les modèles open-weights de qualité frontière existent maintenant sur le marché, et plusieurs d'entre eux se servent de façon performante sur des GPU SecNumCloud hébergés en France. Mais un bon modèle sur une bonne infrastructure ne suffit pas si le harness est médiocre. La souveraineté technique n'a de sens que si le résultat est à la hauteur des outils US que les équipes utilisaient avant. Et pour ça, le harness est non-négociable.

Ce que ça change concrètement pour les équipes

Pour un DSI ou un RSSI qui évalue des outils IA pour ses équipes de développement, ce cadre change la façon de poser les questions. La question pertinente n'est pas « quel modèle utilisez-vous ? » mais « comment gérez-vous le contexte sur une session de travail longue ? », « comment l'agent se comporte-t-il quand les tests échouent en cascade ? », « que se passe-t-il si la connexion est interrompue en plein milieu d'une tâche ? »

Les réponses à ces questions déterminent la fiabilité réelle de l'outil en production. Un taux de succès de 77 % sur Terminal-Bench contre 69 % ne semble pas énorme sur le papier. Mais sur cinquante développeurs qui utilisent l'agent toute la journée, ça représente des dizaines de tâches qui aboutissent chaque jour au lieu d'être relancées manuellement.

Il y a aussi la question du coût. Un harness efficace consomme moins de tokens pour atteindre le même résultat, parce qu'il évite les boucles inutiles, les relances redondantes et le bruit de contexte. Sur un déploiement à l'échelle d'une grande équipe, cette efficacité se traduit directement en coûts d'inférence. Ce n'est pas un détail de confort — c'est un facteur de viabilité économique.