Dans le premier texte de la série j’ai raconté le malaise qui m’a fait commencer à reconstruire la tech chez Prolog. À la fin, j’ai promis d’ouvrir chaque partie. Je commence par celle que j’ai mis le plus de temps à comprendre : le harness.
Un avertissement d’entrée, il n’y a pas de formule magique ici. C’est ce que j’ai lu, ce que j’ai vu d’autres entreprises faire, et ce qu’on essaie de faire, avec des réussites et des ratés.
J’ai passé des mois à chercher un nom pour une chose que je sentais et que je n’arrivais pas à dire.
Le mot qui me manquait
Je voyais des entreprises de trois personnes livrer ce qui demandait avant trente. Et je voyais que le gain n’était pas dans le modèle, parce que le modèle, tout le monde en utilise un à peu près pareil. Il était ailleurs, et je n’avais pas le mot.
En février 2026, OpenAI a publié un texte intitulé Harness Engineering et m’a donné le mot.
Leur définition s’ouvre sur deux lignes courtes : “Les humains dirigent. Les agents exécutent.” Et ce qui suit change la façon de penser : le travail principal d’une équipe d’ingénierie n’est plus d’écrire du code, mais de concevoir des environnements, de spécifier l’intention et de construire des boucles de feedback qui laissent les agents faire un travail fiable.
Chaque morceau là-dedans est un vrai travail. Concevoir l’environnement où l’agent tourne. Rendre clair ce qu’il faut faire, l’intention, plutôt que le pas à pas. Et monter les boucles qui disent à l’IA si elle a bon, pour qu’elle se corrige toute seule.
Remarquez ce qui a disparu de la phrase : écrire le code. Ce n’est pas OpenAI qui dit que le code n’a pas d’importance. C’est OpenAI qui dit que, quand l’IA en écrit la majeure partie, le travail humain monte d’une couche. Et quand quelque chose casse, la question change avec. Elle cesse d’être “réessaie, force un peu plus” et devient “quelle capacité a manqué dans l’environnement pour que l’IA ait bon”. Le bug cesse d’être la faute de l’IA (“elle est bête”) et devient une question sur ce qui manquait autour d’elle.
Le harness, donc, c’est organiser le code, le process et le travail pour que l’IA voie, comprenne et exécute. Ce n’est pas un outil qu’on achète. C’est une nouvelle façon de penser ce que l’équipe livre.
Le modèle est une chose, le harness en est une autre
La phrase la plus économe que j’ai trouvée pour fixer ça vient de Vivek Trivedy, ingénieur chez LangChain : “si ce n’est pas un modèle, alors c’est le harness”.
Le modèle, c’est le LLM brut. Opus, GPT, peu importe. Du texte entre, du texte sort, fin. Et le modèle, presque tout le monde l’a. C’est une commodité. L’écart entre celui qui gagne 10% et celui qui gagne 5x n’est pas dans le modèle.
Il est dans le harness. Le harness, c’est tout le reste : le code, les outils que l’IA peut appeler, le contexte qu’elle voit, les hooks, l’orchestration, le sandbox où elle tourne, la mémoire, les règles métier. Tout ce qui entoure le modèle dans le flux, avant que le travail n’arrive fini jusqu’à vous.
Harness n’a pas de bonne traduction en français. Harnais, amarrage, ça perd le sens. Je dis “l’infrastructure de l’agent” et voilà.
Vous avez peut-être déjà entendu “context engineering”. Ça en fait partie, la partie qui organise ce que l’IA voit. Le harness est plus grand : il inclut le contexte, mais aussi les outils, les hooks, le sandbox, la persistance, l’orchestration. Le contexte est un morceau ; le harness est le tout.
Modèle vs. harness
Le modèle est une commodité, presque tout le monde utilise le même. Ce qui sépare le gain de 10% de celui de 5x, c'est ce qui l'entoure.
Le harness, c’est rendre tout lisible pour l’IA
Si je devais résumer le harness à un seul principe, ce serait celui-ci : rendre tout lisible pour l’IA.
Dans le texte précédent j’ai raconté le diagnostic qui m’a marqué. Le contexte de Prolog vivait éparpillé. Un bout dans Notion, un autre dans Drive, un autre dans Jira, dans Figma. Il n’y avait pas de source unique. Chaque nouvelle conversation avec l’IA repartait de zéro, parce que l’information dont elle avait besoin était à cinq endroits et curée nulle part.
Quand on relit ça à travers la lentille du harness, le problème devient évident. L’IA ne voyait pas. Et ce qu’elle ne voit pas, elle ne l’utilise pas.
Peter Pang, CTO de CREAO, a raconté une décision qui paraît radicale et qui a tout son sens : il a réuni tout le code dans un seul monorepo. La raison n’était pas le rangement. C’était pour que l’IA puisse tout voir d’un coup.
C’est ça, le travail. Ce n’est pas un prompt malin, ce n’est pas un truc. C’est prendre ce qui est éparpillé, implicite, vivant seulement dans la tête des gens, et le rendre lisible à un endroit, écrit, accessible pour l’agent. Fastidieux parfois. Mais c’est exactement ça qui sépare le gain de 10% du gain de 5x.
La preuve : 3 ingénieurs, 1 million de lignes
Je me méfie du hype par nature. Alors ce qui m’a convaincu que ce n’était pas une mode, c’est un cas avec un chiffre.
L’équipe d’OpenAI qui a construit le Codex CLI, leur outil en ligne de commande, comptait trois ingénieurs. En quelques semaines, ils ont livré environ un million de lignes de code : application, infra, tooling, documentation. Et zéro ligne écrite à la main. La philosophie de l’équipe, énoncée par eux, était “aucun code écrit manuellement”. Ce furent environ mille cinq cents pull requests, toutes intégrées, aucune tapée par une personne. Les trois dirigeaient, l’IA construisait.
Pour ne pas confondre : OpenAI a Codex, qui est le modèle entraîné pour le code, et le Codex CLI, qui est l’outil. Les trois ont utilisé le modèle, à travers l’outil, pour construire l’outil lui-même. La chose qui se construit avec elle-même.
Et ça ne s’arrête pas là. Dans tout OpenAI, Codex relit 100% des pull requests de l’entreprise.
Ce qui a scellé l’affaire pour moi, ce n’était pas le chiffre d’OpenAI seul. C’était que Peter Pang, chez CREAO, est arrivé à la même conclusion par un chemin séparé, sans se concerter avec personne. Deux endroits différents décrivant la même chose. Quand ça arrive, en général ce n’est pas une mode. C’est un pattern.
Trois personnes qui dirigent, l'IA qui construit. Zéro code écrit à la main.
no manually-written code la philosophie affichée de l'équipe. Et dans tout OpenAI, le Codex révise 100% des pull requests.
AI-assisted, ce n’est pas la même chose qu’AI-first
Ici je dois être honnête sur là où en est Prolog.
Il y a une différence que presque personne ne perçoit entre utiliser l’IA pour assister le travail et mettre l’IA au centre de celui-ci.
L’AI-assisted, c’est l’humain au centre et l’IA branchée sur les bords. Même sprint, même board, même réunion, même flux. L’IA aide à l’intérieur du process qui existait déjà. Le gain est réel et il est petit : 10, 20%. C’est là que se trouve la majorité des entreprises. C’est là qu’en est Prolog aujourd’hui, et je ne vais pas faire semblant du contraire.
L’AI-first, c’est l’IA au centre et l’humain qui dirige. Vous partez du principe que l’agent est le constructeur principal et vous refaites le process, l’architecture et même l’organisation autour de ça. L’humain critique, valide, juge. Le gain est d’un autre ordre : 5x, 10x. C’est ce que font Codex, CREAO et Anthropic.
La différence, comme le résume Peter Pang, est multiplicative, pas incrémentale. Et c’est pour ça que le harness compte autant. On n’arrive pas à l’AI-first en branchant de l’IA sur ce qui existe déjà. On y arrive en reconstruisant pour que l’IA voie, comprenne et exécute. Autrement dit, en faisant du harness.
Et ce n’est pas qu’un problème d’ingénierie
La phrase d’OpenAI, “le travail principal n’est plus d’écrire du code”, a été écrite en pensant à l’ingénierie. Mais quand je l’ai relue en changeant le sujet, elle collait à tous les postes de la tech.
Le produit n’écrit plus seulement le document ; il rend l’agent capable de proposer la solution. Le design ne dessine plus seulement l’écran ; il rend l’agent capable de générer l’interface dans le système. Le QA ne fait plus seulement passer le test à la main ; il rend l’agent capable de valider. La data ne fait plus seulement tourner la requête ; elle rend l’agent capable de répondre à la question métier.
Pour chacun d’eux, la question devient la même : quelle capacité manque à l’agent pour faire ça, et comment je la rends visible et contrôlable pour lui.
Ce que j’en retiens
Le harness n’est pas un outil qu’on achète ni un meilleur modèle qu’on souscrit. C’est du travail. Le travail de prendre ce qui est dans la tête des gens et éparpillé dans dix systèmes et de le rendre lisible, à un seul endroit, pour qu’une machine puisse l’utiliser.
La partie fastidieuse, c’est qu’il n’y a pas de raccourci. La bonne partie, c’est que, étant du travail, ça se fait. On est en plein dedans : loin de l’AI-first, plus près qu’on ne l’était il y a deux mois. Je continuerai à raconter comment ça avance.
Sources
- OpenAI, Harness Engineering: leveraging Codex in an agent-first world (février 2026). D’où viennent la phrase “les humains dirigent, les agents exécutent” et le cas de l’équipe Codex CLI.
- Vivek Trivedy, LangChain, The Anatomy of an Agent Harness. La définition “si ce n’est pas un modèle, alors c’est le harness”.
- Peter Pang, CREAO, sur le fait de mettre l’IA au centre. Le monorepo pour que l’IA voie tout et la différence multiplicative.
- How OpenAI’s Codex Team Works and Leverages AI, Eng Leadership Newsletter. Les chiffres de l’équipe Codex.