Le Harness : le modèle n'est que le moteur

Vous avez probablement déjà entendu quelqu'un dire :

« Notre produit utilise GPT. »

Ou Claude. Ou Mistral. Ou Qwen.

Très bien.

Mais cela ne vous dit finalement pas grand-chose sur ce que fait réellement le produit.

Deux applications peuvent utiliser exactement le même modèle et pourtant avoir des capacités, des performances et même des comportements radicalement différents.

Pourquoi ?

Parce qu'entre votre application et le modèle se cache une couche dont on parle beaucoup moins : le Harness.

Et vous allez voir que c'est probablement l'une des couches les plus importantes de l'IA moderne.

Revenons à notre document

Dans le premier article de cette série, nous avions pris un exemple extrêmement simple : vous chargez un gros document et vous demandez :

« Fais-moi un résumé en 5 points. »

Nous avions alors vu qu'avant même que votre document arrive au modèle, du logiciel classique pouvait intervenir :

• ▸extraire le texte du PDF,
• ▸découper le document,
• ▸rechercher les passages intéressants,
• ▸construire le prompt,
• ▸envoyer les informations au modèle,
• ▸récupérer sa réponse,
• ▸éventuellement lui demander de recommencer.

À l'époque, j'avais simplement appelé cela la couche logicielle.

Aujourd'hui, un terme commence à s'imposer pour désigner plus précisément une grande partie de cette mécanique : le Harness.

Mais c'est quoi, un Harness ?

Pour vulgariser énormément :

« Le modèle réfléchit. Le Harness organise son travail. »

Imaginez un moteur posé au milieu de votre garage.

Même s'il développe 500 chevaux, vous n'irez pas très loin avec.

Il lui faut :

• ▸un volant,
• ▸une boîte de vitesses,
• ▸des roues,
• ▸des freins,
• ▸des capteurs,
• ▸un réservoir,
• ▸un tableau de bord,
• ▸et un conducteur ou un système capable de décider où aller.

Pour un modèle d'IA, c'est pareil.

Le modèle peut être extrêmement performant, mais il ne connaît pas spontanément vos documents internes, il ne possède pas l'accès à votre CRM, il ne sait pas forcément quand effectuer une recherche sur internet et il ne décide pas magiquement comment découper une tâche complexe en dix étapes.

Tout cela doit être organisé par du logiciel.

C'est le Harness.

Et cela change beaucoup de choses dans notre manière de regarder l'IA.

Un modèle seul est finalement assez limité

Prenons un LLM classique.

Vous lui fournissez du texte. Il vous fournit du texte.

C'est déjà impressionnant, évidemment.

Mais imaginons maintenant que vous lui demandiez :

« Dis-moi combien nous avons facturé au client Dupont cette année et compare cela avec l'année dernière. »

Votre modèle ne possède probablement aucune idée de qui est Dupont.

Il ne connaît pas votre logiciel de facturation.

Il ne possède pas les droits d'accès nécessaires.

Il ne sait pas quelle base de données interroger.

Et surtout, vous ne voulez probablement pas lui donner l'intégralité de vos données comptables à chaque question.

Il va donc falloir lui construire un environnement. Par exemple :

• 01comprendre que la question concerne la facturation ;
• 02identifier le client dans votre CRM ;
• 03appeler votre outil comptable ;
• 04récupérer uniquement les données nécessaires ;
• 05éventuellement effectuer un calcul ;
• 06transmettre les résultats au modèle ;
• 07vérifier que la réponse respecte le format attendu ;
• 08afficher le résultat à l'utilisateur.

Le modèle n'a réalisé qu'une partie du travail.

Tout le reste appartient au Harness.

Première fonction : donner le bon contexte

Vous avez peut-être entendu énormément parler de Prompt Engineering ces dernières années. Comment écrire le meilleur prompt ?

• ▸« Tu es expert-comptable depuis 25 ans… »
• ▸« Réponds étape par étape… »
• ▸« Si tu ne connais pas la réponse, dis-le… »

C'est utile.

Mais nous commençons à passer d'une logique de Prompt Engineering à une logique beaucoup plus large de Context Engineering.

La question devient moins :

« Comment dois-je formuler ma phrase ? »

et davantage :

« De quelles informations le modèle a-t-il réellement besoin pour accomplir cette tâche ? »

Parce que remplir sa fenêtre de contexte avec 300 pages inutiles est rarement une bonne idée.

Le Harness va donc pouvoir sélectionner les éléments intéressants :

• ▸les instructions de l'entreprise ;
• ▸l'historique pertinent de la conversation ;
• ▸certains documents ;
• ▸les résultats d'une recherche ;
• ▸les réponses d'un outil ;
• ▸le travail effectué lors des étapes précédentes.

Et ne transmettre au modèle que ce dont il a besoin à cet instant précis.

C'est ici que l'on retrouve notamment notre fameux RAG, dont nous avions déjà parlé. Au lieu de donner toute votre documentation au modèle : question → recherche des passages intéressants → modèle → réponse.

Le Harness orchestre la recherche.

Le modèle, lui, analyse les informations qu'on lui apporte.

Deuxième fonction : donner des outils à l'IA

C'est ici que les choses deviennent beaucoup plus intéressantes.

Un LLM peut désormais décider :

« Pour répondre à cette question, j'ai besoin d'utiliser cet outil. »

Cela peut être :

• ▸effectuer une recherche sur internet ;
• ▸interroger une base de données ;
• ▸lire un document ;
• ▸envoyer un e-mail ;
• ▸consulter un calendrier ;
• ▸exécuter du code ;
• ▸appeler votre CRM ;
• ▸lancer un autre logiciel interne.

Vous commencez alors à obtenir ce que l'on appelle communément un agent.

Prenons un exemple très simple. Vous dites :

« Organise-moi un rendez-vous avec Paul la semaine prochaine. »

Le modèle peut comprendre votre intention.

Mais le Harness doit lui permettre de :

• 01identifier Paul ;
• 02consulter votre calendrier ;
• 03récupérer les disponibilités ;
• 04éventuellement consulter le calendrier de Paul ;
• 05proposer un horaire ;
• 06attendre votre validation ;
• 07créer l'événement.

Et surtout… il faut empêcher l'IA de faire n'importe quoi.

Vous voulez probablement autoriser votre agent à consulter votre calendrier. Vous n'avez peut-être pas envie de lui permettre de supprimer l'intégralité de vos rendez-vous.

C'est également le rôle de cette couche logicielle.

MCP : la prise USB de nos agents ?

Évidemment, si chaque développeur doit construire une connexion différente pour chaque outil, nous allons rapidement recréer le magnifique monde des intégrations informatiques où chacun possède son API, son format et sa documentation de 453 pages.

C'est notamment pour répondre à ce problème que des protocoles comme MCP Model Context Protocol sont apparus.

L'idée est assez simple : standardiser la manière dont un agent peut découvrir et utiliser des outils ou des ressources.

C'est d'ailleurs pour cette raison que nous avons choisi chez SOCLE de construire nos agents autour de ce type de protocole : éviter autant que possible de recréer une intégration spécifique pour chaque nouvelle capacité.

Troisième fonction : décider quoi faire ensuite

Donner un outil au modèle est une chose.

Encore faut-il décider quand l'utiliser.

C'est ici qu'intervient ce que l'on appelle généralement la boucle agentique. Pour simplifier énormément : observer → réfléchir → agir → observer le résultat → recommencer.

Prenons la recherche d'un restaurant. Votre agent pourrait :

• 01comprendre que vous cherchez un restaurant italien ;
• 02utiliser un outil de recherche ;
• 03obtenir cinq résultats ;
• 04constater que vous aviez demandé un restaurant ouvert ce soir ;
• 05vérifier les horaires ;
• 06éliminer les restaurants fermés ;
• 07regarder leurs disponibilités ;
• 08vous présenter les trois meilleures propositions.

Nous ne faisons donc plus forcément utilisateur → modèle → réponse, mais utilisateur → modèle → outil → modèle → outil → modèle → réponse.

Et cela peut continuer pendant plusieurs dizaines d’étapes.

Le Harness est la mécanique qui maintient cette boucle en vie.

• ▸Il transmet les résultats.
• ▸Il conserve l'état.
• ▸Il contrôle le nombre d'itérations.
• ▸Il détecte les erreurs.
• ▸Il peut demander à l'IA de changer de stratégie.
• ▸Et surtout, il décide quand il est temps de s'arrêter.

Parce qu'un agent qui réfléchit éternellement est certes philosophiquement fascinant, mais économiquement assez catastrophique.

Et si un modèle ne suffisait pas ?

Nous pouvons aller encore plus loin.

Pourquoi utiliser le même modèle pour absolument toutes les tâches ?

Prenons une réunion enregistrée. Nous avons besoin de :

• ▸comprendre un fichier audio ;
• ▸distinguer les interlocuteurs ;
• ▸retranscrire leurs paroles ;
• ▸corriger certaines erreurs ;
• ▸comprendre le contexte métier ;
• ▸générer éventuellement une synthèse.

Un seul énorme modèle pourrait théoriquement essayer de tout faire. Mais ce n'est pas forcément la meilleure solution.

Chez SOCLE, par exemple, notre système de transcription combine plusieurs traitements : un agent spécialisé dans la reconnaissance vocale réalise la transcription, puis un agent LLM peut effectuer une correction contextuelle en tenant compte des interlocuteurs et des informations métier.

Chaque technologie est utilisée là où elle est pertinente.

C'est exactement l'intérêt de raisonner en écosystème d'agents plutôt qu'en modèle unique.

Le Multi-Agent

Et évidemment, parce que nous aimons toujours complexifier les choses dès qu'elles commencent à fonctionner, nous pouvons donner plusieurs agents à notre Harness.

Imaginez une équipe dans une entreprise. Vous avez :

• ▸un juriste ;
• ▸un développeur ;
• ▸un commercial ;
• ▸un comptable.

Vous pourriez engager une personne extrêmement intelligente et lui demander de devenir experte dans les quatre domaines. Ou utiliser plusieurs spécialistes et leur permettre de collaborer.

Dans un système multi-agent, le principe est similaire. Un agent peut recevoir la demande puis la transmettre à un autre agent plus spécialisé.

Le Harness devient alors une sorte de chef d’orchestre.

• ▸Qui travaille ?
• ▸Dans quel ordre ?
• ▸Quelles informations doivent être transmises d'un agent à l'autre ?
• ▸Doivent-ils travailler en parallèle ?
• ▸Qui vérifie le résultat ?

Chez SOCLE, nous utilisons notamment le protocole A2A Agent-to-Agent pour structurer ces échanges entre agents.

L'objectif reste le même : éviter que chaque nouvelle combinaison nécessite de reconstruire entièrement votre produit.

Quatrième fonction : choisir le bon modèle

Et c'est ici que vous allez comprendre pourquoi je vous expliquais, dans le chapitre précédent, qu'un modèle n'est finalement « qu'un algorithme ».

Votre produit n'a pas nécessairement besoin d'être marié à GPT, Claude ou Mistral jusqu'à ce que la mort vous sépare.

Le Harness peut constituer une couche d'abstraction entre votre application et vos modèles. Imaginez :

• ▸un petit modèle rapide pour classer une demande ;
• ▸un modèle spécialisé dans le code pour analyser un programme ;
• ▸un modèle plus puissant pour une tâche complexe ;
• ▸un modèle multimodal pour comprendre une image ;
• ▸un modèle local pour certaines données sensibles.

Votre utilisateur, lui, n'a absolument pas besoin de savoir qu'il vient d'utiliser quatre modèles différents. Il veut simplement que son problème soit résolu.

Et c'est un point qui nous tient particulièrement à cœur chez SOCLE : nous ne pensons pas qu'un produit IA devrait être construit autour d'un modèle. Il devrait être construit autour d'un besoin.

Les modèles deviennent alors des ressources que le système choisit selon la tâche à accomplir.

Le modèle le plus puissant n'est pas toujours le meilleur produit

C'est peut-être l'idée la plus importante de cet article.

Imaginons deux entreprises utilisant exactement le même modèle.

Entreprise A

Elle envoie directement votre question au LLM avec un énorme prompt de 15 pages.

Entreprise B

Son Harness :

• ▸identifie votre intention ;
• ▸récupère uniquement les documents nécessaires ;
• ▸sélectionne les bons outils ;
• ▸contrôle leurs permissions ;
• ▸utilise un modèle spécialisé pour une sous-tâche ;
• ▸vérifie le résultat ;
• ▸demande validation à un humain si nécessaire ;
• ▸trace toutes les étapes.

C'est aussi pour cela que comparer des solutions d'IA uniquement en disant « ils utilisent quel LLM ? » commence à devenir une question insuffisante.

C'est comme comparer deux voitures uniquement en demandant quelle quantité de chevaux développe le moteur. C'est important. Mais vous oubliez tout ce qu'il y a autour.

Human-in-the-loop : parfois, l'IA doit simplement demander

Autre élément particulièrement important dans un Harness : savoir quand ne pas agir seul.

Imaginez une IA utilisée dans un contexte juridique. Elle peut :

• ▸retranscrire un entretien ;
• ▸identifier les interlocuteurs ;
• ▸signaler une incohérence ;
• ▸proposer une correction.

Mais modifier définitivement un témoignage sans validation humaine serait évidemment une très mauvaise idée.

Le Harness peut donc introduire des points de contrôle : IA → proposition → validation humaine → suite du traitement.

C'est ce que l'on appelle le Human-in-the-loop.

Et contrairement à certaines visions très futuristes de l'IA, ce n'est pas nécessairement un défaut d'automatisation. C'est parfois exactement ce qui rend l'automatisation utilisable.

Chez l'un de nos clients dans le domaine juridique, nous utilisons justement cette approche : différentes étapes du traitement peuvent être vérifiées et corrigées par l'utilisateur avant validation.

Cinquième fonction : observer ce qu’il se passe

C'est probablement l'un des aspects les moins sexy de l'IA.

Et pourtant, si vous voulez mettre un système en production, il devient indispensable.

Votre agent vient de produire une mauvaise réponse. Pourquoi ? Est-ce :

• ▸le modèle ?
• ▸le prompt ?
• ▸le document récupéré par le RAG ?
• ▸une mauvaise réponse d'un outil ?
• ▸un problème de routage ?
• ▸une étape précédente qui s'est trompée ?
• ▸une information présente dans la mémoire ?
• ▸un autre agent ?

Si votre système consiste uniquement en question → grosse boîte noire → réponse, bonne chance.

Un Harness industriel doit donc également permettre de suivre le déroulement du traitement. Chez SOCLE, nous cherchons justement à rendre les différentes étapes observables.

• ▸Quel agent a été appelé ?
• ▸Quel outil ?
• ▸Quel document ?
• ▸Quel modèle ?
• ▸Combien de temps ?
• ▸Dans quel ordre ?

Cela permet de comprendre ce que fait réellement votre IA. Mais également de mesurer son coût.

Parce qu'une IA qui vous fait gagner 3 minutes de travail en consommant 12 € de calcul à chaque demande n'est peut-être pas le fantastique projet de transformation numérique annoncé dans le PowerPoint.

Et la sécurité dans tout ça ?

Dès que vous donnez des outils à une IA, la question devient évidemment critique.

Un chatbot qui hallucine une capitale est embêtant. Un agent connecté à votre système informatique qui hallucine une action est légèrement plus problématique.

Le Harness doit donc également pouvoir imposer des règles :

• ▸quels outils sont accessibles ;
• ▸quelles actions nécessitent une validation ;
• ▸quelles données peuvent être transmises ;
• ▸combien d'actions peuvent être réalisées ;
• ▸quels utilisateurs possèdent quels droits ;
• ▸quels résultats doivent être vérifiés.

Plus l'IA devient capable d'agir, plus cette couche devient importante.

La sécurité d'un système agentique ne peut donc pas reposer uniquement sur : « on a demandé gentiment au modèle dans le prompt de ne pas faire de bêtises. »

Ce serait pratique. Mais évitons.

Finalement, où se trouve l'intelligence ?

Quand ChatGPT est apparu, nous avons naturellement associé toute l'intelligence que nous observions au modèle. C'était logique.

Mais à mesure que nos systèmes deviennent plus complexes, la frontière devient beaucoup plus floue.

Une partie des performances provient du modèle. Une autre vient :

• ▸de la qualité des outils ;
• ▸du contexte qu'on lui fournit ;
• ▸de la mémoire ;
• ▸du RAG ;
• ▸du routing ;
• ▸de l'orchestration ;
• ▸des boucles de vérification ;
• ▸des autres modèles autour de lui.

Le système d'IA devient donc plus important que le simple modèle. Et c'est probablement l'évolution la plus intéressante que nous observons actuellement.

Nous sommes passés de « quel modèle utilisez-vous ? » à « quel système avez-vous construit autour de vos modèles ? »

En résumé

Il lui apporte :

• ▸du contexte ;
• ▸des documents ;
• ▸de la mémoire ;
• ▸des outils ;
• ▸des règles ;
• ▸une capacité à agir ;
• ▸d'autres agents ;
• ▸des mécanismes de contrôle ;
• ▸de l'observabilité.

Et surtout, il transforme un simple appel de modèle en véritable produit.

C'est aussi pour cela que chez SOCLE nous travaillons avant tout sur cette couche. Notre objectif n'est pas de créer le prochain modèle généraliste : d'autres entreprises dépensent déjà quelques milliards pour cela ;)

Notre travail consiste à permettre aux entreprises de construire autour de ces modèles des systèmes utilisables : agents, RAG, outils compatibles MCP, écosystèmes multi-agents basés sur A2A, contrôle humain et suivi des différentes étapes.

Le modèle devient ainsi une brique interchangeable au sein d'un système plus large.

Et cela nous amène naturellement au chapitre suivant. Parce que tout ce beau système les agents, les outils, les modèles appelés en cascade doit bien tourner quelque part.

Spoiler : ça consomme du béton, de l'électricité et du silicium.