← Tous les articles

Les agents veulent compiler

Les agents d’IA commencent à compiler. Partout dans la pile, à la mi-2026, la même séparation se déploie dans toutes les directions : le modèle décide, et c’est autre chose qu’un modèle qui exécute. Au lieu d’agir en direct au sein de la boucle du modèle, les agents produisent un artefact déterministe — un plan, un DAG, un script de flux de travail — qu’ils confient à un environnement d’exécution capable de le rejouer, de le reprendre et de l’auditer comme un logiciel ordinaire. Le modèle devient la partie frontale d’un compilateur, qui analyse une intention brouillonne pour la transformer en représentation intermédiaire. Les environnements d’exécution déterministes en deviennent la partie dorsale. L’agentivité en direct est requalifiée : c’est le mode coûteux que l’on réserve à l’exploration, aux défaillances inédites et au goût. {.answer-block}

Le 1er juillet, un Show HN a été publié avec un titre qui se lit comme une thèse : « Coding agent that compiles intent into deterministic DAG before running ». Le projet s’appelle Rigorix, un environnement d’exécution en Rust qui se présente comme « un environnement d’exécution déterministe pour agent de codage, au service d’une ingénierie logicielle par IA reproductible et auditable » et qui résume sa répartition des tâches en une phrase : « Le LLM génère le code ; Rigorix régit l’exécution »3. Quatorze points, un commentaire, facile à faire défiler sans s’arrêter. Je m’y suis arrêté parce que c’est la troisième fois en autant de semaines que je vois la même forme se déployer sous un angle différent — et c’est cette forme, et non tel ou tel outil, qui constitue le véritable sujet.

TL;DR

  • Anthropic a tracé la ligne canonique en décembre 2024 : les flux de travail s’exécutent « through predefined code paths », les agents « dynamically direct their own processes »1. C’était un embranchement décidé par un humain au moment de la conception. Il se déplace désormais vers l’exécution, et c’est le modèle qui choisit.
  • Les flux de travail dynamiques de Claude Code confient au modèle l’écriture d’un script d’orchestration en JavaScript qu’un environnement d’exécution lance en dehors de la conversation : reprenable avec des résultats mis en cache, comparable par diff aux exécutions précédentes, enregistrable comme une commande que l’on relance2.
  • La même forme surgit de trois autres directions : des outils indépendants qui compilent des tâches en langage naturel en DAG exécutables (Rigorix)3, des frameworks qui refusent d’exécuter un graphe non compilé (LangGraph)4, et une infrastructure d’exécution durable qui enveloppe les boucles d’agent dans des flux de travail rejouables (Temporal)5.
  • La compilation apporte ce qu’elle apporte toujours : mise en cache, reconstructions incrémentales, artefacts comparables par diff, revue avant exécution. Elle coûte ce qu’elle coûte toujours : un jugement figé au moment de la compilation.
  • L’agentivité en direct l’emporte encore pour l’exploration, les états d’erreur inédits et le goût. La règle de fonctionnement : la première exécution relève de la recherche, chacune des suivantes aspire à devenir une compilation.

L’embranchement relevait de la conception. Il passe à l’exécution.

L’antériorité, ici, c’est « Building Effective Agents » de Anthropic, publié le 19 décembre 2024, encore la taxonomie de référence du domaine. Le texte définit les flux de travail comme « systems where LLMs and tools are orchestrated through predefined code paths » et les agents comme « systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks ». Son conseil pour trancher : « workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale »1.

Pendant dix-huit mois, cette phrase s’est lue comme un menu. Vous, le concepteur du système, choisissiez la colonne de gauche ou celle de droite avant d’écrire la moindre ligne. Le tournant de 2026, c’est que le menu se replie en une chaîne de traitement. L’agent effectue sa passe flexible, pilotée par le modèle, une seule fois, au moment de la planification, et le produit de cette passe est un flux de travail : des chemins de code prédéfinis, générés à la demande, pour cette tâche précise. Vous obtenez la flexibilité de l’agent au moment de la compilation et la prévisibilité du flux de travail au moment de l’exécution, depuis le même système, par phases.

La question « flux de travail ou agent ? » reçoit la même réponse que les compilateurs ont donnée à « flexibilité ou vitesse ? » : les deux, séparés par un artefact.

Trois signaux, une seule direction

D’abord, l’environnement est devenu déterministe

La couche du cadre d’agent y est parvenue avant les agents. Les Hooks se déclenchent sur des événements du cycle de vie avec des codes de sortie que le modèle ne peut pas négocier. Les règles de permission s’évaluent avant l’appel de l’outil, pas après. Toute la discipline de l’architecture d’agent en 2026 tient dans une coque déterministe autour d’un cœur stochastique, avec cet aveu sans détour : pour tout ce qui doit se produire à chaque fois, on a cessé d’interroger le modèle et on a commencé à imposer la règle à la frontière. Le déterminisme est d’abord arrivé par les bords.

Ensuite, l’artefact durable a supplanté la conversation

Le deuxième signal, c’est ce qui survit à une session. Les conversations s’évaporent ; le contrôle, la spécification, le test persistent, et les agents s’optimisent si fort par rapport à eux que le contrôle devient la spécification. La leçon sous-jacente : la transcription n’est pas le résultat. L’artefact l’est, car c’est la seule chose que la prochaine session, le prochain agent et le prochain ingénieur puissent saisir. Une fois qu’on l’admet pour la vérification, l’admettre pour les plans d’exécution n’est plus qu’un petit pas. Si le contrôle durable survit à la conversation qui l’a produit, le plan durable aussi.

Désormais, le plan lui-même est l’artefact

Le troisième signal est le signal nouveau, et c’est le propos de cet article. Les agents se sont mis à produire leur exécution comme un artefact de première classe au lieu de la réaliser en direct.

Claude Code en a fait une surface de produit. Un flux de travail dynamique est « a JavaScript script that orchestrates subagents at scale » : Claude écrit le script pour la tâche que vous décrivez, et un environnement d’exécution le lance en arrière-plan pendant que la session reste réactive. La documentation est explicite sur ce qui a changé de mains : « Un flux de travail fait passer le plan dans le code ». Dans leur propre tableau comparatif, la réponse à « qui décide de la prochaine étape » n’est pas Claude. C’est le script. Chaque exécution écrit ce script dans un fichier que vous pouvez ouvrir, comparer par diff au script d’une exécution précédente, modifier et relancer. Interrompez une exécution puis reprenez-la, et « agents that already completed return their cached results, and the rest run live »2.

Rigorix construit la même forme depuis le camp indépendant, et son architecture se lit comme un manuel de compilation : la planification passe par la classification de l’intention, puis l’extraction des paramètres, puis la génération du DAG ; un moteur piloté par des gabarits exécute le graphe sous des garde-fous de risque, des budgets et des permissions, avec des enveloppes d’audit signées par HMAC pour la traçabilité. Sa définition du bénéfice est précise : « Repeatable means the same intent produces the same execution structure under the same templates and policies »3.

Les frameworks y étaient déjà, cachant la même idée derrière un verbe d’API. LangGraph modélise la logique d’agent sous forme de nœuds (« functions that encode the logic of your agents ») reliés par des arêtes, et sa documentation énonce l’exigence en gras : « You MUST compile your graph before you can use it ». Compilez avec un checkpointer et « LangGraph saves checkpoints at super-step boundaries », ce qui rend reprenable une exécution laissée à mi-parcours4.

Et la couche d’infrastructure est arrivée par le bas. Temporal, la plateforme d’exécution durable, enveloppe les boucles de raisonnement des agents dans des flux de travail dont la progression persiste en dehors de tout processus : « Temporal keeps track of application progress and stores all Activity results », si bien qu’un agent qui plante « picks up where it left off » au lieu de raisonner de nouveau depuis zéro. Son intégration avec l’Agents SDK d’OpenAI, annoncée le 30 juillet 2025, a fait de cet enveloppement une voie prise en charge plutôt qu’un motif que l’on bricole à la main.

Outil indépendant, surface de produit, framework, infrastructure. Quatre directions, une seule forme : le modèle décide, l’artefact exécute.

Prenez l’analogie du compilateur au pied de la lettre

Dans les textes sur l’IA, les analogies sont d’ordinaire décoratives. Celle-ci est porteuse, car c’est d’elle que découlent les prédictions.

La partie frontale d’un compilateur analyse le source, vérifie la sémantique et émet une représentation intermédiaire. C’est exactement la phase de planification que déroulent ces systèmes : la classification de l’intention de Rigorix, c’est l’analyse syntaxique ; l’extraction des paramètres, l’analyse sémantique ; la génération du DAG, la production de code. Le script de flux de travail, c’est la représentation intermédiaire (IR). La partie dorsale fait ensuite ce que font les parties dorsales : elle ordonnance le parallélisme, impose des limites de ressources (Claude Code plafonne une exécution à 16 agents simultanés et 1 000 au total2) et pratique la mémoïsation. Quatre conséquences en découlent.

Les plans obtiennent des caches de compilation. La sémantique de reprise, c’est de la compilation incrémentale. Claude Code renvoie les résultats d’agents mis en cache lors d’une reprise ; l’argument de Temporal auprès des concepteurs d’agents, c’est que la reprise au point de défaillance préserve les tokens au lieu de relancer le modèle pour régénérer le travail perdu5. L’étape suivante, ce sont des phases de plan adressées par leur contenu : relancer un flux de travail dont les premières phases sont inchangées les sautera, comme make saute les objets inchangés.

Les plans se comparent par diff. La documentation des flux de travail vous invite à comparer par diff le script d’une exécution à celui d’une exécution précédente2. Dès lors que le plan est du texte, sa dérive devient visible comme l’est la dérive de code, et « l’orchestration de cette migration a changé depuis le trimestre dernier » devient un événement examinable dans une pull request, et non un chantier d’archéologie à travers les transcriptions.

Le plan devient la surface de revue. Avant qu’un flux de travail ne s’exécute, Claude Code affiche les phases prévues et propose « View raw script » avant tout consentement2. C’est la pièce qui rejoint la trajectoire de la revue. J’ai soutenu que les agents ont supplanté le relecteur, pas la relecture : le travail humain s’est déplacé de l’inspection des diffs vers la prise en charge de l’intention. Le plan compilé est l’artefact où se produit cette revue déplacée, car c’est le seul endroit où l’intention est lisible avant que l’exécution ne dépense quoi que ce soit. Vous ne pouvez pas passer en revue dix mille décisions prises en direct. Vous pouvez passer en revue un script de quarante lignes. Attendez-vous à ce que la validation des grandes opérations d’agents migre de l’approbation du diff après coup vers l’approbation du plan en amont.

La dérive déclenche une recompilation, pas un rafistolage. Quand un plan compilé échoue parce que le monde a changé — une API renommée, une dépendance mise à jour —, le mauvais réflexe est de modifier le DAG à la main. Cela revient à corriger du code objet. La bonne boucle relance la partie frontale : même intention, nouvel environnement, plan neuf. Les environnements d’exécution durables absorbent déjà la défaillance transitoire à l’intérieur de l’artefact grâce aux nouvelles tentatives ; la dérive de l’environnement est la classe de défaillance qui s’échappe vers le compilateur. Les cadres d’agent se doteront de détecteurs de dérive qui invalideront les plans comme les systèmes de build invalident les caches, et « recompiler en cas de dérive » deviendra une boucle permanente plutôt qu’un sauvetage manuel.

Là où chaque mode l’emporte

Dimension Agentivité en direct (modèle dans la boucle) Exécution compilée (artefact dans la boucle)
Nature de la tâche Inédite, terrain inconnu Forme connue, exécutions répétées
Gestion des défaillances Les erreurs inédites reçoivent un jugement neuf Les défaillances anticipées font l’objet de nouvelles tentatives déterministes
Profil de coût Raisonnement complet à chaque étape, à chaque exécution Raisonner une fois à la planification, exécuter à bas coût
Auditabilité Une transcription que l’on reconstitue après coup Un script et des journaux que l’on inspecte avant et après
Répétabilité Redémarrer, c’est redécider Rejouer, avec le travail terminé mis en cache
Jugement Actuel, appliqué sur l’instant Figé au moment de la compilation
L’emporte quand On explore, on débogue, on décide de ce que l’on veut Migrations, audits, rattrapages de données, tout ce qui s’exécute deux fois

Le tableau trace une frontière, pas un classement. Tout ce qui se trouve sous la frontière est sur le point de devenir bien moins cher et bien plus fiable. Tout ce qui se trouve au-dessus reste coûteux, comme il se doit.

Ce que la compilation n’achète pas

Trois choses restent en direct, et faire mine du contraire, c’est précisément ainsi que ce schéma finira survendu.

L’exploration. Dans une base de code que l’on ne connaît pas, ou face à un problème réellement nouveau, le plan est la découverte. Il n’y a encore rien à compiler, parce que décider est le travail. Compiler avant de comprendre produit un artefact assuré de votre ignorance, et l’environnement d’exécution l’exécutera à la perfection.

Les états d’erreur inédits. Un plan compilé gère les défaillances que son auteur a anticipées. Les politiques de nouvelle tentative sont des réponses déterministes à des ennuis attendus. Quand l’ennui est imprévu, la nouvelle tentative déterministe est une boucle, pas un remède, et le bon geste est de remonter vers la partie frontale, où un modèle peut regarder l’erreur réelle et réfléchir.

Le goût. Un flux de travail est un jugement figé au moment de la compilation, et un jugement figé vieillit. Un jugement neuf exécuté de façon négligée l’emporte sur un jugement périmé exécuté à la perfection, car la version périmée échoue avec assurance. Personne ne devrait compiler la décision portant sur la sensation que le produit doit procurer.

Il y a aussi un avertissement à reprendre du côté de la vérification. Un DAG est une surface de contrôle, et tout ce que le plan omet cesse silencieusement de faire partie du travail — la même dynamique qui fait des tests visibles la spécification de fait. La compilation concentre tout le jugement du modèle sur une tâche dans un seul artefact, ce qui concentre le travail humain sur la prise en charge de cet artefact. La revue ne disparaît pas quand le plan se compile. Elle se déplace vers la planification, et elle dispose d’une seule page à fort effet de levier.

La position

La règle qui me guide désormais est simple : la première exécution d’une tâche relève de la recherche et mérite un agent en direct ; la deuxième exécution est une compilation et mérite un artefact. Claude Code livre cette règle sous forme d’UX : faites écrire le flux de travail une fois par Claude, enregistrez le script de l’exécution comme une commande, relancez-le à l’infini2. Rigorix la livre sous forme de gouvernance. Temporal la livre sous forme d’infrastructure. LangGraph l’a livrée des années plus tôt sous la forme d’un verbe d’API que personne n’a lu comme un manifeste.

Les agents veulent compiler pour la même raison que les programmeurs. Décider est coûteux et précieux. Exécuter devrait être ennuyeux, inspectable et gratuit à répéter. L’industrie a passé 2024 et 2025 à prouver que les modèles savent décider. Le travail de 2026 consiste à s’assurer qu’ils n’aient à décider qu’une seule fois.

À retenir

  • La première exécution est de la recherche, la deuxième est une compilation. Menez une tâche inédite avec un agent en direct ; dès qu’elle se répète, figez-la dans un artefact et cessez de payer pour un jugement neuf sur un problème déjà résolu.
  • Compilez d’abord les 80 % ennuyeux. Corvées de publication, campagnes de migration, lots de traduction, passes d’audit : forte répétition, vérification peu coûteuse. L’exploration, le débogage et le goût restent en direct.
  • Adoptez la boucle « recompiler en cas de dérive ». Quand un flux de travail compilé casse parce que le monde a changé, ne rafistolez pas l’artefact à la main. Renvoyez le modèle régénérer le plan face à la nouvelle réalité, passez le diff en revue, figez de nouveau.
  • Passez le plan en revue, pas la transcription. Dès lors que l’exécution est déterministe, le plan est la page à plus fort effet de levier du système. Lisez-le comme vous liriez un script de migration, car c’est exactement ce qu’il est.

FAQ

Qu’est-ce que cela signifie, pour un agent d’IA, de compiler son plan ?

Cela signifie que la sortie de l’agent est un artefact déterministe et inspectable — un script de flux de travail ou un DAG — plutôt qu’une suite d’actions en direct. Le modèle effectue son raisonnement au moment de la planification et émet l’artefact ; un environnement d’exécution qui n’est pas un modèle le lance avec une sémantique de rejeu, de reprise et d’audit. Les flux de travail dynamiques de Claude Code (un script en JavaScript écrit par le modèle et exécuté par un environnement d’exécution) et Rigorix (des tâches en langage naturel compilées en DAG exécutables) en sont des exemples déjà disponibles.

Quelle est la différence entre un flux de travail d’IA et un agent d’IA ?

Les définitions canoniques de Anthropic (2024) : les flux de travail sont « systems where LLMs and tools are orchestrated through predefined code paths », tandis que les agents « dynamically direct their own processes and tool usage ». La mise à jour de 2026, c’est que la frontière devient une phase à l’intérieur d’un seul système, au lieu d’un choix entre deux systèmes : l’agent effectue sa passe dynamique une fois, au moment de la planification, et génère lui-même les chemins de code prédéfinis.

Les flux de travail d’agents compilés valent-ils mieux que les agents autonomes ?

Pour des tâches répétées et bien formées, oui : un flux de travail compilé coûte moins cher par exécution, se reprend avec des résultats mis en cache et se passe en revue avant de s’exécuter. Pour l’exploration, les états d’erreur inédits et les décisions de jugement, non : un plan compilé est un jugement figé au moment de la compilation, or ces tâches réclament un jugement appliqué sur l’instant. Le partage pratique se fait au nombre d’exécutions : gardez la première exécution en direct, compilez tout ce que vous exécuterez deux fois.

Quels outils compilent aujourd’hui l’intention d’un agent en artefacts déterministes ?

Quatre exemples vérifiés en juillet 2026. Les flux de travail dynamiques de Claude Code : le modèle écrit un script d’orchestration en JavaScript, un environnement d’exécution le lance, et les scripts enregistrés deviennent des commandes réutilisables. Rigorix : un environnement d’exécution open source en Rust qui compile des tâches en langage naturel en DAG exécutés sous des contraintes de politique, de budget et de permission. LangGraph : les graphes doivent être compilés avant d’être exécutés, avec des points de contrôle aux frontières des super-étapes. Temporal : des flux de travail à exécution durable qui persistent la progression de l’agent et reprennent au point de défaillance.

Sources


  1. Anthropic, « Building Effective Agents », anthropic.com/engineering/building-effective-agents (19 décembre 2024). Définit les flux de travail comme « systems where LLMs and tools are orchestrated through predefined code paths » et les agents comme « systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks », et recommande que « workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale ». 

  2. « Orchestrate subagents at scale with dynamic workflows », documentation de Claude Code, code.claude.com/docs/en/workflows (consulté en juillet 2026). Un flux de travail dynamique est « a JavaScript script that orchestrates subagents at scale » ; « A workflow moves the plan into code ». L’environnement d’exécution lance le script en dehors de la conversation, l’écrit dans un fichier qui peut être lu, comparé par diff aux exécutions précédentes, modifié et relancé ; les exécutions interrompues reprennent, les agents déjà terminés renvoyant leurs résultats mis en cache ; les exécutions sont plafonnées à 16 agents simultanés et 1 000 au total ; les scripts enregistrés dans .claude/workflows/ s’exécutent comme des commandes slash. Nécessite Claude Code v2.1.154 ou une version ultérieure. 

  3. Rigorix OSS, github.com/arman-jalili/rigorix-oss, publié sous le titre « Show HN: Coding agent that compiles intent into deterministic DAG before running », news.ycombinator.com/item?id=48741332 (1er juillet 2026). Un environnement d’exécution en Rust, sous double licence MIT/Apache-2.0, qui « compiles natural-language development tasks into executable Directed Acyclic Graphs (DAGs) ». La planification déroule la classification de l’intention, l’extraction des paramètres, puis la génération du DAG ; l’exécution repose sur un moteur de DAG piloté par des gabarits ; la gouvernance couvre les garde-fous de risque, les budgets, les permissions et des enveloppes d’audit signées par HMAC. Le README définit sa garantie ainsi : « the same intent produces the same execution structure under the same templates and policies ». 

  4. Documentation de la Graph API de LangGraph, docs.langchain.com/oss/python/langgraph/graph-api (consulté en juillet 2026). Les nœuds sont « functions that encode the logic of your agents » ; les arêtes déterminent quel nœud s’exécute ensuite ; « You MUST compile your graph before you can use it » ; la compilation avec un checkpointer « saves checkpoints at super-step boundaries », ce qui permet une exécution reprenable. 

  5. Temporal, « Production-ready agents with the OpenAI Agents SDK + Temporal », temporal.io/blog/announcing-openai-agents-sdk-integration (30 juillet 2025). Les boucles d’agent enveloppées dans des Temporal Workflows persistent leur progression de façon durable : « Temporal keeps track of application progress and stores all Activity results », si bien qu’une application redémarrée « picks up where it left off » au lieu de relancer le modèle pour régénérer le travail perdu. 

Articles connexes

Le contrôle devient la spécification

Des agents de code qui construisent pour le test : score de l'oracle quasi parfait, bibliothèque livrée morte. Ce que vo…

10 min de lecture

Les agents supplantent le relecteur, pas la relecture

Un article de 2026 soutient que les agents de codage ont mis fin à la relecture humaine de code. J'exécute le pipeline q…

11 min de lecture

Votre agent écrit plus vite que vous ne pouvez lire

Cinq groupes de recherche ont publié sur le même problème cette semaine : les agents IA produisent du code plus vite que…

21 min de lecture