Pourquoi l'exécution en style heredoc convient mieux aux agents IA qu'un REPL en 2026

Les premiers agents de code ont révélé quelque chose d'étonnamment puissant : donnez à un agent l'accès à Bash, et il peut presque tout faire — écrire du code, rassembler du contexte, gérer des workflows Git complets.

Cette observation a nourri un mouvement plus large vers le tout-CLI. Les interfaces en ligne de commande sont devenues la façon standard de rendre des applications complexes accessibles aux agents IA, donnant naissance à un slogan familier :

La CLI est tout ce dont vous avez besoin.

Mais il y a un coût caché. Les agents utilisent souvent un terminal à peu près comme le ferait un humain : lancer une courte commande, inspecter le résultat, puis décider quoi faire ensuite. Plus les tâches se complexifient, plus ça crée d'allers-retours entre le modèle et ses outils — donc plus d'appels au LLM, plus de contexte gaspillé, et plus de temps passé à attendre.

Plutôt que de demander aux agents d'assembler des scripts shell compliqués, on préfère qu'ils coordonnent leurs tâches dans un langage de programmation qu'ils connaissent déjà. Ça mène à une architecture légèrement différente :

Garder la CLI comme point d'entrée universel, mais utiliser le code comme véritable interface avec le logiciel.

L'agent soumet un bloc de code qui contient les opérations, décisions et traitements de données qui seraient autrement répartis sur plusieurs cycles d'interaction. Le runtime local exécute ensuite le workflow.

ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and les orchestrer.

Dans cet article, on compare heredoc et REPL, deux façons d'exécuter du code via une CLI, et on partage les résultats expérimentaux d'ego-browser. Avec le heredoc, l'agent a terminé les mêmes tâches en 44 % de cycles d'exécution en moins, avec 35,5 % d'appels d'outils en moins, pour un coût 21,6 % plus bas.

« La CLI, c'est tout ce qu'il faut » — et après ?

L'idée que « la CLI, c'est tout ce qu'il faut » suppose que le modèle sait déjà utiliser cette CLI.

Pour des outils bien connus comme Git, Docker ou FFmpeg, ce n'est en général pas un problème. Les modèles ont vu d'innombrables commandes, tutoriels, scripts et messages d'erreur pendant leur entraînement, et connaissent déjà les arguments et la façon dont les commandes s'assemblent.

Mais quand on construit une toute nouvelle CLI pour des agents, la situation change. Chaque CLI a ses propres sous-commandes, arguments, formats de sortie et sémantique d'erreur. Pour le modèle, c'est en gros un nouveau mini-langage. Même avec une documentation complète, le modèle doit d'abord apprendre les règles, puis comprendre par des appels répétés comment les commandes s'assemblent.

Exposez plutôt les mêmes capacités comme une API JavaScript, ou dans n'importe quel autre langage : le modèle doit toujours apprendre les nouveaux concepts métier, mais il n'a plus besoin de réapprendre le flux de contrôle, les structures de données ou la composition. Boucles, conditions, gestion d'exceptions et traitement de données restent dans un langage de programmation qu'il connaît déjà.

Prenez une tâche simple : ouvrir une page web et lire son titre principal. Si ego-browser exposait une interface classique à base de commandes, l'agent aurait besoin de plusieurs étapes pour la terminer :

# First call: open the page
ego-browser open https://example.com

# Tool response: the page is open

# Second call: locate the main heading
ego-browser find --role heading

# Tool response: a heading was found

# Third call: read the heading
ego-browser read --role heading

Après chaque étape, l'agent attend l'outil, lit le résultat et décide quoi faire ensuite.

L'interface de code qu'utilise réellement ego-browser lui permet d'exprimer tout le workflow d'un coup :

await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);

Les deux approches obtiennent la même chose. L'interface de style commande divise le processus en plusieurs cycles d'interaction modèle-outil ; l'interface de code permet à l'agent d'écrire une seule fois le processus complet et de le transmettre au runtime local.

C'est exactement l'idée de conception mentionnée plus tôt : garder la CLI comme point d'entrée universel, mais utiliser le code comme véritable interface avec le logiciel. Ça conserve l'avantage de la CLI — facile à appeler et à intégrer — tout en laissant le modèle utiliser les compétences de programmation qu'il a déjà, pour composer et orchestrer.

Quand la CLI devient une passerelle vers le code

Une fois qu'une CLI accepte du code, la question suivante est : comment l'agent doit-il transmettre ce code à l'environnement d'exécution ?

À strictement parler, heredoc est une syntaxe d'entrée shell et REPL un mode d'exécution d'interpréteur ; les deux ne sont pas à la même couche d'abstraction. Ce que cet article compare vraiment, c'est l'exécution de code en une passe via un heredoc dans ego-browser, contre une session interactive persistante construite sur un REPL. Par souci de concision, on les appellera simplement heredoc et REPL à partir de maintenant.

Une option, c'est le heredoc. Dans ego-browser, l'agent soumet un bloc entier de JavaScript d'un coup :

ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF

Le shell transmet le code à ego-browser, attend qu'il se termine, reçoit le résultat, et se termine. Pour l'agent, ça se comporte comme un appel d'outil classique :

Submit command → wait for process → receive result

Un REPL fonctionne différemment : l'interpréteur reste actif, ce qui permet à l'agent de saisir du code à plusieurs reprises en conservant les variables et l'état de la session :

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

En termes de puissance d'expression, les deux sont pour ainsi dire équivalents. Un REPL peut exécuter un programme complet avec boucles, conditions et gestion d'exceptions en une fois, et un heredoc peut ne soumettre qu'une seule ligne.

La vraie différence, c'est le cycle de vie du processus. Avec un heredoc, le processus se termine dès que le code a fini de s'exécuter ; un REPL garde l'interpréteur en vie, en attente d'une nouvelle entrée. Ça veut aussi dire que les deux imposent des exigences différentes aux outils d'agent. Un heredoc tourne directement sur le modèle requête-réponse classique :

submit the command → wait for the process to exit → get the result

Un REPL demande plus à l'outil : des processus persistants, la gestion de session, une entrée continue, l'interruption et la récupération. La plupart des outils Bash embarqués dans les agents n'ont pas ces capacités. Parmi les produits grand public actuels, seul Codex les gère raisonnablement bien. Et le support de l'outil n'est qu'une condition nécessaire pour utiliser un REPL — ça ne détermine pas comment le modèle va réellement l'utiliser. Même quand les deux environnements peuvent exécuter le même code, le modèle peut quand même écrire du code différemment dans chacun.

Comment les modèles écrivent du code dans chaque environnement

En théorie, un modèle a la même capacité de programmation dans les deux environnements. En pratique, on a observé une différence de comportement constante :

• Dans un REPL, le modèle a tendance à saisir le code de façon incrémentale.
• Dans un heredoc, il génère plus souvent un programme complet en une seule passe.

Les logiciels pour humains doivent tenir compte de l'ergonomie. Les logiciels pour agents ont besoin d'une discipline similaire : appelons ça ingénierie de l'expérience modèle. Une interface doit fonctionner avec les modèles de schémas comportementaux développés lors de la formation.

Le contraste entre REPL et heredoc reflète la distribution de leurs données d'entraînement.

Les exemples de REPL viennent en général de tutoriels, de sessions de débogage et d'échanges question-réponse. Leur schéma typique est exploratoire :

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Les blocs de code heredoc ressemblent plus à des scripts ou des fichiers source. Ils ont des limites de début et de fin explicites, ce qui pousse le modèle à produire un workflow continu :

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

Ça ne veut pas dire qu'un REPL est incapable d'exécuter des programmes complets. Le modèle pourrait soumettre le même bloc de code à un REPL en une seule fois.

La distinction est contextuelle. Un REPL encourage un exécuter, observer, continuer modèle. Un heredoc encourage un organiser d'abord, puis exécuter modèle.

Cette tendance détermine aussi où vit le flux de contrôle. Dans un REPL, le modèle découpe plus souvent la tâche en plusieurs étapes et décide quoi faire après chaque résultat. Dans un heredoc, il place plus souvent boucles, conditions, filtrage et traitement de données directement dans le programme, et laisse le runtime local s'en charger.

Ce que les expériences ont montré

Parmi les outils d'agent grand public qu'on pouvait intégrer de façon fiable, Codex offrait les capacités d'exécution qu'exige un REPL persistant. On a donc construit un benchmark automatisé sur le SDK Codex : le même agent a réalisé quatre types de tâches de navigateur réelles, via REPL et via heredoc, et on a agrégé les résultats sur plusieurs runs pour comparer.

Les tâches étaient :

• X trending-post analysis (a typical social media scraping workload): Collecte les posts originaux d'OpenAI des sept derniers jours, exclut les posts épinglés, les reposts et les réponses, classe les cinq premiers par vues, et calcule leurs taux d'engagement et la moyenne globale.
• Candidature chez OpenAI : Trouve le bon poste en infrastructure cloud à San Francisco, télécharge un CV, remplis le formulaire de candidature, et arrête-toi avant l'envoi final.
• Calcul de prêt Redfin : Filtre les biens à Austin par type et par prix, ouvre le premier résultat après le tri, change l'apport à 20 %, et récupère la mensualité estimée mise à jour.
• Recherche de vol Expedia : Trouve un vol aller simple sans escale de JFK à MIA, sélectionne l'option la moins chère d'une compagnie donnée, saisis les informations du passager, et arrête-toi avant le paiement.

These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.

Les deux approches ont mené à bien la plupart des tâches. Le heredoc a atteint un taux de réussite de 77,5 %, contre 75,0 % pour le REPL. La différence de fiabilité était modeste.

La vraie différence, c'était l'efficacité :

• Le temps de complétion moyen a chuté de 35.0%.
• Le temps de complétion médian a chuté de 30.7%.
• Les appels d'outils ont chuté de 35.5%.
• La consommation de jetons a chuté de 29.8%.
• Le coût moyen a chuté de 21.6%.

Bien qu'un REPL puisse réutiliser l'état d'exécution, cet avantage n'a pas réduit le nombre d'interactions. En pratique, l'agent en heredoc a fait moins d'appels d'outils.

Les résultats correspondaient à nos observations précédentes. Une fois dans un REPL, l'agent exécutait souvent un petit bout de code, examinait le résultat, puis décidait quoi faire ensuite. Les boucles, filtres et décisions qui auraient pu tenir dans un seul programme étaient au contraire répartis sur plusieurs échanges modèle-outil.

Les deux environnements offrent une puissance d'expression similaire. Leur différence d'efficacité vient surtout de la façon dont leurs schémas d'interaction façonnent le comportement de l'agent. Au moins sur ces quatre tâches d'agent de navigateur, le heredoc a poussé plus systématiquement le modèle à organiser un programme complet, à intégrer boucles, filtrage et décisions dans le code, et à éviter les allers-retours superflus d'une prise de décision étape par étape.

On a aussi vérifié si ce schéma tenait à plus grande échelle, en comparant ego-browser à un produit d'automatisation similaire basé sur REPL, sur le dataset Odysseys. Contrairement à l'expérience contrôlée ci-dessus, cette comparaison opposait deux produits complets plutôt que le même modèle sur deux interfaces. Elle reste donc utile comme comparaison d'efficacité globale, mais ses différences ne peuvent pas être attribuées entièrement au heredoc contre le REPL.

Ce n'est pas une victoire définitive pour le heredoc

On ne pense pas que le heredoc soit intrinsèquement supérieur au REPL.

Notre conclusion dépend des capacités des modèles, de la distribution de leurs données d'entraînement, et de la conception des outils d'agent telle qu'elle existe en 2026.

Les agents d'aujourd'hui sont en général meilleurs pour produire un bloc de code complet en une passe. Leurs outils shell sont aussi conçus autour d'un cycle de vie simple : soumettre une commande, attendre qu'elle se termine, renvoyer le résultat. Dans ces conditions, le heredoc facilite la réduction des cycles d'interaction et le déplacement du flux de contrôle vers du code exécuté localement.

Ces conditions peuvent changer vite.

Les futurs outils d'agent pourraient offrir des sessions persistantes fiables, des sorties structurées et une récupération d'état robuste. Les agents n'auraient alors plus besoin de gérer eux-mêmes les invites du REPL, l'état du process et les sessions interrompues. Un entraînement ciblé pourrait aussi apprendre aux modèles à soumettre des programmes complets de façon proactive dans un REPL, plutôt que de tomber dans une interaction étape par étape inutile.

Si ça arrive, les REPL pourraient garder les avantages de la réutilisation d'état et du retour immédiat sans exiger plus d'appels modèle. Ils pourraient même devenir le meilleur choix pour des tâches à initialisation coûteuse, à état de longue durée, ou à workflow vraiment exploratoire.

C'est pourquoi le titre précise 2026. Nous ne prétendons pas avoir découvert une loi permanente. Il s’agit d’un jugement technique ponctuel basé sur les modèles et les outils d’agent disponibles aujourd’hui.