OpenAI met en open source tout le socle de Codex : CLI, SDK, sandbox et Agent Harness

Si vous avez déjà essayé de construire votre propre agent de code, vous le savez : le modèle ne représente, avec un peu de chance, qu'un tiers du travail. Le reste, c'est l'outillage : où l'agent écrit ses fichiers, ce qu'il a le droit d'exécuter, comment ne pas perdre le contexte à la troisième heure d'une tâche. Chez OpenAI, tout cela est disponible en open source sur GitHub, et on peut y jeter un œil dès maintenant.

Précisons d'emblée, pour ne pas alimenter le battage : le dépôt openai/codex existe depuis longtemps. Il ne s'agit pas d'une publication soudaine des coulisses de l'entreprise. Mais l'auteur de la chaîne @cgevent attire à juste titre l'attention sur son ampleur : ce n'est pas un client de chat, mais une infrastructure logicielle pour les tâches de longue durée. La dernière mise à jour, selon l'auteur, date d'il y a cinq heures : le projet est donc bien vivant, et non une vitrine abandonnée.

Ce que contient le dépôt

Le dépôt rassemble plusieurs couches. Codex CLI est un agent qui fonctionne via le terminal. Codex SDK est un ensemble d'outils permettant d'intégrer Codex dans sa propre application. App Server est le composant serveur par lequel le client dialogue avec l'agent et pilote son travail. Skills est le mécanisme qui permet de brancher des instructions et des processus de travail spécialisés, c'est-à-dire un moyen « d'apprendre » vos règles à l'agent. Enfin, Sandbox assure l'isolation de l'exécution des commandes et la limitation de l'accès au système.

Autrement dit, c'est presque un kit complet de composants pour construire son propre agent de code, sans avoir à réinventer chacun d'eux à partir de zéro.

Agent Harness : pourquoi y jeter un œil

Le plus intéressant, c'est l'architecture de l'Agent Harness. On désigne ainsi la couche logicielle qui entoure le modèle de langage. Elle détermine quels outils l'agent peut utiliser, comment le contexte est conservé, comment l'exécution des tâches est organisée et quelles actions sont autorisées.

Prenons un exemple simple. Vous demandez à l'agent : « Mets à jour les dépendances et répare les tests qui échouent ». Le modèle propose une commande à lancer. C'est alors que le harness entre en jeu et répond à des questions délicates. Peut-on exécuter cette commande sans confirmation ? Dans quelle isolation ? Que renvoyer au modèle d'une longue sortie de terminal ? Comment enregistrer l'état pour reprendre au même endroit après un plantage, au lieu de tout recommencer ?

C'est précisément là que la plupart des agents faits maison échouent. Non pas parce que le modèle est bête, mais parce que le harness n'a pas réfléchi aux droits, aux limites et à la mémoire. En lisant les sources, on voit comment s'en sort l'équipe qui développe l'un des agents de code les plus populaires, au lieu de deviner à partir de descriptions marketing.

Limites et enseignements pratiques

Il faut évaluer lucidement ce que l'on obtient. C'est le code du harness, pas les poids du modèle ni toute l'infrastructure interne d'OpenAI. Le dépôt évolue vite, si bien que les détails d'implémentation deviendront obsolètes plus vite que l'article qui en parle. Avant d'emprunter des morceaux de code pour un produit commercial, vérifiez la licence. Et ne copiez pas aveuglément les mécanismes d'isolation : la sécurité d'un sandbox dépend de votre environnement, pas seulement du code.

Que faire concrètement :

— Pour les développeurs : ouvrez Sandbox et regardez comment les commandes et l'accès aux fichiers sont limités. C'est l'enseignement le plus transposable pour tout agent qui exécute du code.

— Pour les product managers : étudiez la façon dont sont conçus la confirmation des actions et les droits. L'équilibre entre autonomie et contrôle est une décision produit, et chez Codex elle est déjà traduite en code.

— Pour les fondateurs : si vous construisez un agent sur le modèle d'un tiers, votre valeur réside précisément dans le harness. Une bonne référence fait gagner des semaines d'essais et d'erreurs.

La conclusion est simple : l'information n'est pas une ouverture soudaine, mais le rappel qu'un excellent aide-mémoire d'architecture est à la vue de tous depuis longtemps. Il vaut la peine de le lire avant d'écrire votre première boucle « modèle — outil — résultat ».