Près de 9 pilotes d'agents IA sur 10 n'atteignent jamais la production — et, contrairement au récit courant, non parce que les entreprises ont choisi un « mauvais » modèle. Il manque quelque chose qui, en 2026, a gagné son propre nom : le harness. Un harness est la couche que l'on construit autour du modèle — règles, outils, limites de permissions, mécanismes de vérification et monitoring — et c'est elle, et non le modèle lui-même, qui décide de plus en plus si l'IA rapporte de l'argent. Dans ce texte, j'explique ce qu'est un harness, d'où il vient et pourquoi il vaut la peine de comprendre ce concept, quelle que soit la taille de l'entreprise.
Pourquoi le marché ne regardait que le modèle
Ces deux dernières années, le marché a vécu de la question de savoir quel modèle est le meilleur. Compréhensible — les modèles impressionnaient et il était facile de croire qu'il suffisait de choisir le bon pour que le reste s'arrange. Mais la maturation de cette technologie a pris une autre direction que ne le suggéraient les gros titres.
Une expérience le montre bien. L'équipe de LangChain a amélioré l'efficacité de son agent de programmation de près de 14 points de pourcentage sans changer le modèle une seule fois. Elle n'a changé que ce qui l'entoure : boucles d'autovérification, manière de fournir l'information et mécanismes d'interception des erreurs. Autrement dit — le même moteur, un autre harness, un résultat totalement différent.
D'où vient le harness et pourquoi un nouveau nom
Le terme a été popularisé début 2026 par Mitchell Hashimoto — cocréateur de Terraform, un homme aux racines dans l'infrastructure, pas dans le marketing IA. Il a décrit un principe simple : quand un agent commet une erreur, ne corrige pas le cas isolé, mais construis autour de lui une solution grâce à laquelle il ne commettra plus jamais cette erreur. Le mot harness signifie littéralement « harnais » ou « échafaudage » — je le laisse en original, car c'est ainsi qu'on en parle en pratique. D'où la formule devenue retentissante : Agent = Modèle + Harness.
En toute honnêteté, certains praticiens font la grimace. Les tests, le monitoring ou le contrôle des permissions existaient en ingénierie logicielle bien avant ce terme. Ils ont raison sur le fond. Mais le nom a sa valeur — il donne aux conseils d'administration un mot commun pour un travail qui se perdait jusqu'ici quelque part entre « IT » et « innovation », et qu'on peut désormais planifier et financer consciemment.
En pratique, un harness, ce sont plusieurs couches : l'ensemble de règles que l'agent lit au départ, l'accès aux outils, les limites de permissions, les boucles de vérification et le monitoring. Claude Code, Cursor, GitHub Copilot ou Codex sont aujourd'hui précisément des harnesses prêts autour des modèles — tout un environnement de travail, pas un « chat avec le modèle ».
Deux harnesses — et un seul est votre avantage
Ici apparaît la distinction la plus importante pour un décideur. Certains harnesses sont construits par les fournisseurs de modèles — sécurité intégrée, gestion des outils, gestion du contexte. C'est la couche qui devient vite un standard et que vous recevez dans le prix de l'outil. Inutile de la recréer.
La seconde couche, vous la construisez vous-même — pour votre processus précis. Vos règles, vos données, vos garde-fous, votre définition de ce que « bien fait » veut dire. Et c'est précisément cette couche qui est le véritable avantage, car elle consigne le savoir de votre organisation et devient, à chaque correction, plus difficile à copier. Le modèle, vous pouvez le changer comme un moteur. Cette couche, non.
D'où une conclusion simple : le premier harness, confiez-le au fournisseur. Le second, ne le confiez pas à un projet de conseil ponctuel, car c'est en lui que demeure la mémoire institutionnelle de l'entreprise.
Ce qui marche vraiment
Les études montrent le même schéma sous différents angles. Le code produit par un agent sans supervision s'en sortait mal en maintenabilité — quel que soit le modèle utilisé. Le même code avec supervision humaine et une couche de contrôle s'en sortait plusieurs fois mieux. La différence n'était pas faite par le modèle, mais par ce qui l'entourait : limites, tests, contrôle de périmètre. Pas de magie technologique, juste l'effet d'un processus mûr.
Ma conclusion pour les conseils et les dirigeants
Quelle que soit la taille de l'entreprise, le principe est le même. Cessez de trancher sur le modèle à standardiser — misez sur une couche portable de règles et traitez le modèle comme un moteur interchangeable. Toute la différence réside dans ce que vous construisez autour de lui, et c'est dans cette couche qu'il vaut la peine d'investir d'abord, car c'est elle qui intercepte les erreurs quand le modèle se trompe.
L'échelle ne change que le poids de ce travail, pas sa direction. Dans une grande organisation, votre propre harness est un actif pluriannuel, pas un projet de conseil ponctuel — et il a besoin d'une personne qui en répond ; dans les entreprises qui le prennent au sérieux, un tel rôle est devenu la norme. Dans une petite entreprise, le même harness tient dans un fichier de règles décrivant votre processus, une liste de ce que l'agent ne doit pas faire, un mécanisme vérifiant le résultat et un simple enregistrement de ce qui s'est passé. Ce sont des heures de travail, pas un grand déploiement. D'où la conclusion simple pour une plus petite entreprise : n'achetez pas de « transformation agentique » à un fournisseur qui promet tout — utilisez le harness prêt que donnent des outils comme Claude Code, Cursor ou Copilot, et ajoutez votre propre couche mince pour un processus précis. De préférence un où il est facile de vérifier si le résultat est bon — généralement le marketing, la vente ou le service client.
Il y a encore une raison de commencer maintenant, et elle concerne les deux groupes. À partir d'août 2026, les exigences de l'UE pour les systèmes d'IA à haut risque commencent à s'appliquer — entre autres dans le recrutement, le scoring ou la surveillance des employés. L'échéance est parfois repoussée dans les débats réglementaires, mais planifier pour la date la plus précoce est simplement plus sûr. Une couche de vérification, de journalisation et de supervision humaine est, au passage, une infrastructure de conformité, pas seulement d'innovation. Et chaque régulateur posera une question quelle que soit la taille de l'entreprise : celle d'une courte politique d'usage de l'IA pour l'équipe.
Ne demandez pas : « Quel modèle d'IA choisir ? ». Demandez plutôt : « Que construirons-nous autour du modèle pour pouvoir s'y fier ? ». Car avant qu'un modèle ne commence à rapporter de l'argent, quelqu'un doit construire autour de lui une couche qui le tient en bride.
Chère lectrice, cher lecteur. Si vous estimez que le sujet ci-dessus concerne votre entreprise et souhaitez échanger avec moi dans le cadre du Conseil sur la façon de bâtir une telle couche autour de l'IA dans la réalité de votre organisation, prenez contact. Leszek Giza.