Le manuel de terrain de l’ingénierie agentique

L’équipe d’ingénierie la plus productive d’OpenAI n’a pas écrit une ligne de code en cinq mois. Elle a livré environ un million de lignes, toutes écrites par Codex, dans à peu près quinze cents pull requests fusionnées, avec une équipe passée de trois ingénieurs à sept qui est devenue plus rapide par ingénieur en cours de route. Elle vient de publier ce qu’elle a appris, dans un billet intitulé Harness Engineering. C’est, pour un auditoire de dirigeants, le texte le plus utile qui existe en 2026 sur l’ingénierie agentique, et très peu de dirigeants l’ont lu.

Ceci est une traduction.

Un harnais, dans ce contexte, est l’ensemble des échafaudages, des outils, des environnements, de la documentation et des boucles de rétroaction qui permettent à un agent de faire du travail fiable dans votre base de code. Le modèle est le moteur. Le harnais est tout le reste de la voiture. La plupart des entreprises ont passé les dix-huit derniers mois à débattre de la permission de laisser les ingénieurs utiliser le moteur. OpenAI a passé ce temps à construire la voiture.

Voici les cinq principes publiés par l’équipe d’OpenAI, reformulés pour le dirigeant qui les financera.

1. Le travail d’ingénierie passe du code à l’environnement

La première observation doit s’installer avant que le reste puisse vouloir dire quelque chose. Les humains dirigent. Les agents exécutent. Le produit principal du travail de l’ingénieur n’est plus une fonction. C’est l’environnement dans lequel une fonction s’écrit : les outils que l’agent saisit, la structure sur laquelle il calque ses patrons, la rétroaction qu’il reçoit quand il se trompe. La semaine dernière, Andrej Karpathy a donné un nom à cette discipline sur la scène de Sequoia et l’a appelée ingénierie agentique. Le billet d’OpenAI, c’est à quoi elle ressemble en production, à grande échelle.

La conséquence pour le dirigeant est petite et têtue. L’ingénieur le plus fort de votre équipe en 2026 n’écrira peut-être presque aucun code applicatif. Il écrira les linters qui rendent le code applicatif possible. Il concevra le harnais de tests, la structure de la documentation, les guides d’exécution des agents. Si votre cadre de rémunération des ingénieurs seniors récompense encore les lignes commises, il récompense le mauvais artéfact. Récompensez le harnais.

2. L’architecture est un prérequis précoce, pas un luxe tardif

L’équipe d’OpenAI impose une stratification stricte dans chaque domaine d’affaires (Types → Config → Repo → Service → Runtime → UI), avec des directions de dépendances vérifiées mécaniquement et un petit ensemble d’arêtes transversales permises. Elle est explicite sur le pourquoi : c’est le genre d’architecture qu’on reporte habituellement jusqu’à avoir des centaines d’ingénieurs. Avec des agents codeurs, c’est un prérequis précoce.

C’est le renversement de courbe de coûts que personne ne chiffre encore. L’architecture stricte était autrefois une taxe que les petites équipes ne pouvaient pas se payer. La taxe se payait en temps humain : chaque revue de PR, chaque refactorisation, chaque débat sur « est-ce dans la bonne couche ? ». Les agents paient cette taxe à coût marginal nul. Une fois qu’une contrainte est encodée dans un linter maison, elle s’applique à chaque ligne de code pour toujours, et l’agent reçoit la violation en temps réel, avec des instructions de correction injectées directement dans son contexte.

La conséquence pour le dirigeant : la question « sommes-nous assez matures pour introduire des règles architecturales strictes ? » s’est inversée. La nouvelle question est « sommes-nous assez matures pour livrer vite sans elles ? ». Dans un environnement d’agents à haut débit, la réponse est non.

3. Le dépôt est le système de référence

OpenAI n’a aucun sentimentalisme là-dessus. Du point de vue de l’agent, tout ce à quoi il ne peut pas accéder en contexte pendant son exécution n’existe effectivement pas. Le fil Slack qui a aligné l’équipe sur un patron, le Google Doc avec la justification de conception, la décision architecturale que quelqu’un a prise à voix haute dans un corridor : tout cela est invisible pour le système qui écrit maintenant votre code.

Le remède est structurel. Leur dépôt contient un petit fichier AGENTS.md, une centaine de lignes, qui sert de table des matières pointant vers un répertoire docs/ structuré : des documents de conception avec statut de vérification, des plans d’exécution (actifs et terminés), des spécifications produit, des références, une fiche de qualité par domaine d’affaires. Ils font tourner un agent récurrent de « jardinage documentaire » qui repère la documentation périmée et ouvre des PR de correction. La documentation, dans ce modèle, n’est pas un commentaire sur le système. Elle fait partie du système.

La conséquence pour le dirigeant : les rédacteurs techniques, l’équipe de documentation de plateforme, le wiki interne à moitié aimé sont désormais de l’ingénierie porteuse. Financez-les comme telle. Les entreprises qui traitent la documentation comme des frais généraux en 2026 seront celles dont les agents sous-performeront face aux agents d’un concurrent sur le même modèle, pour des raisons que personne dans la pièce ne saura tout à fait nommer.

4. Rendre l’application lisible pour l’agent

C’est le principe le plus facile à manquer et celui qui a les plus grandes conséquences de second ordre. OpenAI a rendu son application démarrable par worktree git, pour que Codex puisse lancer et piloter sa propre instance isolée par changement. Ils ont branché le Chrome DevTools Protocol dans le runtime de l’agent, lui ont donné des compétences pour les instantanés du DOM et les captures d’écran, ont exposé les journaux et les métriques par une pile d’observabilité locale que l’agent peut interroger en LogQL et en PromQL.

Le résultat, c’est que des consignes comme assure-toi que le démarrage du service se termine en moins de 800 ms ou aucune span dans ces quatre parcours utilisateurs critiques ne dépasse deux secondes deviennent traitables. L’agent peut reproduire un bogue, le corriger, valider le correctif en pilotant l’application de bout en bout, et enregistrer une vidéo de la résolution. Ils rapportent des exécutions uniques de Codex travaillant sur une seule tâche pendant plus de six heures, souvent pendant que les humains dorment.

La conséquence pour le dirigeant : la lisibilité de votre application pour vos agents est désormais une propriété d’ingénierie de premier ordre, au rang de la fiabilité et de la sécurité. Si vos journaux et vos métriques vivent derrière un tableau de bord SaaS facturé à la requête que votre équipe consulte dans un navigateur, vos agents ne peuvent pas se permettre d’en apprendre à la vitesse qu’il leur faut. Une observabilité interne que l’agent peut interroger librement n’est plus une infrastructure optionnelle. C’est la fondation de tout le reste.

5. Encoder le goût mécaniquement ; ramasser les rebuts en continu

Codex, comme tout système d’appariement de patrons, reproduit ce qui existe déjà dans le dépôt, y compris les parties sous-optimales. L’équipe d’OpenAI a d’abord tenté de gérer cela avec un rituel de nettoyage du vendredi : chaque ingénieur passait vingt pour cent de sa semaine à nettoyer la « bouillie d’IA ». Ça n’a pas tenu à l’échelle. Évidemment que non. Le débit a monté ; le temps de nettoyage est resté plat ; la bouillie a gagné.

Ce qui tient à l’échelle, c’est d’encoder le goût une fois et de laisser l’agent l’imposer pour toujours. Ils appellent cela des « principes d’or » : des règles mécaniques et assumées qui gardent la base de code lisible et cohérente pour les exécutions d’agents à venir. Un ensemble de tâches Codex en arrière-plan balaie le dépôt à cadence régulière, ouvre des PR de refactorisation ciblées, la plupart révisables en moins d’une minute et fusionnées automatiquement.

La conséquence pour le dirigeant : la dette technique a changé de forme. Ce n’est plus un emprunt à taux élevé qu’on contracte sous la pression des échéances et qu’on rembourse en douloureuses rafales trimestrielles. Elle peut maintenant composer dans l’autre sens : le goût humain est capturé une fois et imposé en continu sur chaque ligne de code que l’agent écrit par la suite. La discipline qui fait composer le goût dépasse, et de loin, la discipline qui nettoie périodiquement après son absence.

Ce que c’est, et ce que ce n’est pas

Le billet d’OpenAI est prudent à un endroit où il aurait facilement pu verser dans l’hyperbole. Ce comportement dépend fortement de la structure et de l’outillage propres à ce dépôt et on ne doit pas présumer qu’il se généralise sans un investissement semblable. Ne lisez pas le manuel de terrain comme une recette à coller dans votre plan du T3. Lisez-le comme la description de ce qui devient possible quand une organisation construit réellement le harnais, et le portrait correspondant de ce qui devient impossible quand elle ne le fait pas.

La conversation inutile, dans la plupart des institutions, est encore : devrions-nous laisser nos ingénieurs utiliser l’IA ? La conversation utile, celle dont OpenAI vient de publier les notes de terrain, est : quelle fraction de notre investissement en ingénierie, ce trimestre, va dans le harnais plutôt que dans les fonctionnalités ? Les institutions qui trouveront le bon ratio d’ici 2027 auront l’air d’avoir été chanceuses. Elles n’auront pas été chanceuses. Elles auront financé le harnais pendant que tout le monde finançait le moteur.

Si l’IA est devenue plus rapide et que votre entreprise ne l’est pas devenue, c’est ici que l’écart allait toujours se mesurer.

Nous avons les moteurs. Il nous faut les voitures.

L’agent écrit le code. L’ingénieur écrit le monde dans lequel le code vit.