Blog | WeScale

Après le Loop Engineering : le Graph Engineering est-il la prochaine strate ?

Rédigé par Emmanuel Sciara | 29/10/2026

Cet article fait partie d’une série sur les termes “xxx engineering” des agents de code IA. Sa thèse : chaque nouveau terme (prompt, contexte, harness, boucle, graphe) ajoute une strate par-dessus la précédente au lieu de la remplacer, et chaque article se demande où intervient l’humain. Retrouvez les autres articles de cette série :

  1. « Agents de code IA : de la rédaction de prompts à la conception de systèmes »

  2. « Harness Engineering ou Agent = modèle + harness » [à paraître, titre de travail]

  3. « Loop Engineering ou piloter la boucle sans y être » [à paraître, titre de travail]

  4. « Après le Loop Engineering : le Graph Engineering est-il la prochaine strate ? » (cet article)

  5. « Qui a inventé quoi : l’origine des termes de l’ingénierie des agents » (article compagnon)

les cinq strates de l’article 1 · le graphe mis en évidence

Dans le premier article de cette série, nous avons présenté le schéma ci-dessus, avec une strate baptisée « Graphe ? (juillet 2026, contesté) », contestée parce qu’en juillet le mot « graphe » désignait encore quatre choses différentes et que rien ne prouvait qu’il s’agisse d’une strate à part. Cet article explore le point d’interrogation : le graph engineering est-il la prochaine strate au-dessus de la boucle, ou l’échelle s’est-elle arrêtée aux boucles… pour l’instant ?

Ce que le graphe ajoute à la boucle

Ce que fait une boucle

Une boucle fait avancer un seul fil de travail jusqu’à ce que sa condition d’arrêt soit remplie

Le résultat de chaque tour décide du tour suivant, sans qu’aucun humain ne relance l’agent entre les deux. Un même tour peut enchaîner plusieurs étapes : chez Mergify, Rémy Duthu donne un seul objectif par ticket, et l’agent enchaîne toutes les étapes, du plan et de la spec jusqu’aux tests et au push ; Rémy relit ensuite le résultat.

Une boucle peut aussi dérouler une liste, une tâche par tour, comme Geoffrey Huntley le fait avec sa boucle Ralph et son fichier de plan, fix_plan.md. Chaque étape peut avoir son propre contrôle ; la boucle s’arrête sur une seule condition de fin.

Ce que fait un graphe

Le graphe organise ce qui se passe entre les boucles

Cela comprend :

  • Quelle boucle s’exécute quand ;

  • Laquelle attend laquelle ;

  • Comment les résultats passent de l’une à l’autre ;

  • Comment leurs modifications sont mergées.

Une boucle qui est seule à écrire sur une branche particulière peut merger sa propre pull request, comme le font les agents Codex d’OpenAI ; dès que plusieurs boucles écrivent des modifications à intégrer dans une même cible, le merge devient l’intégration du travail des autres, que Cursor confie par exemple à un agent de merge dédié.

Les contrôles, les retry et la règle d’arrêt interne de chaque boucle relèvent toujours du loop engineering. Pour les distinguer des graphes, comptez les agents qui écrivent :

  • Un seul fil de travail qui écrit à la fois, quel que soit le nombre d’étapes ou de tâches successives, est une boucle ;

  • Plusieurs agents qui écrivent en parallèle des modifications destinées à une même cible (branche, tronc commun), si bien que leurs modifications doivent être intégrées, forment le niveau suivant (graphe), dès lors que cette coordination est conçue à l’avance, par un script ou un graphe de tâches, plutôt qu’improvisée par le modèle, car il faut alors décider ce qui tourne en parallèle, ce qui attend quoi et comment les modifications sont mergées. Les assistants en lecture seule, comme un sous-agent de relecture ou un évaluateur d’objectif, ne comptent pas, et des PR indépendantes mergées une à une par la CI et la merge queue habituelles restent des boucles.

Deux preprints récents définissent le graphe par sa structure plutôt que par le décompte des éditeurs : dans une revue de littérature, Yuyuan Feng et 34 coauteurs le construisent à partir de graphes explicites de tâches, d’agents et d’états du système, et la définition de Sandeco Macedo n’exige ni plusieurs modèles ni plusieurs agents, mais exclut une simple chaîne d’appels sans représentation explicite du graphe.

Dans l'approche présentée ici, une structure où un seul agent écrit reste une boucle, car un seul contrôle décide encore du résultat.

D’autres rangent les agents parallèles dans la boucle, comme Addy Osmani (aujourd’hui chez Anthropic, auparavant chez Google Cloud AI), qui compte les worktrees pour agents parallèles parmi ses composants. Cet article réserve la définition de « boucle » à un seul fil de travail, parce que c’est là que se trouve le contrôle.

Graphe de contrôle et graphe de tâches

Les outils d’agents de code proposent deux formes de graphes :

Graphe de contrôle

Chaque nœud est une tâche traitée par son propre agent, en une seule passe ou en boucle, et un script décide de ce qui s’exécute ensuite et transmet les résultats.

Dans les dynamic workflows de Claude Code, Claude écrit ce script et un runtime l’exécute : un agent par fichier sur une migration de 500 fichiers, chacun dans sa propre copie isolée. Réunir ces copies revient au script ou à un agent.

Un script qui ne fait que relancer une seule tâche (corriger jusqu’à ce que le type check passe) est une boucle écrite sous forme de code ; il devient un graphe de contrôle quand il fait travailler plusieurs agents qui écrivent et décident de leur ordre et de la façon dont leurs modifications sont réunies.

Graphe de tâches

Chaque nœud y est une tâche prise en charge par son propre agent ou sa propre boucle, et chaque arête indique quelle tâche en bloque une autre. Les agents prennent ce qui n’est pas bloqué.

Beads, créé par l’ingénieur chevronné Steve Yegge (passé par Amazon et Google), fonctionne ainsi. À l’inverse, une simple liste de tâches qu’une seule boucle traite l’une après l’autre (comme le fichier de plan de la boucle Ralph) n’est pas un graphe de tâches : ce n’est que le plan de travail de cette boucle, puisqu’un seul agent écrit.

Les agent teams de Claude Code (une fonction expérimentale, désactivée par défaut) forment un hybride avec un agent principal :

  • L’agent principal crée les tâches et peut les attribuer ;

  • Les coéquipiers prennent celles qui ne sont ni attribuées ni bloquées ;

  • Tous partagent le même arbre de travail et évitent les conflits en se répartissant les fichiers.

La différence entre les deux formes tient à qui distribue le travail : dans un graphe de contrôle, le script pousse les tâches vers les agents ; dans un graphe de tâches, les agents viennent chercher ce qui est débloqué. Les deux se combinent, comme dans les agent teams.

Dans le graphe de tâches, trois tâches mais deux agents : la troisième attend que celle qui la bloque soit terminée.

La plupart des produits ne proposent ni graphe de contrôle ni graphe de tâches : un agent principal découpe le travail et lance des sous-agents (Codex, Cursor, Devin, Amp), qu'il coordonne lui-même. Ces sous-agents peuvent écrire en parallèle, mais la coordination est improvisée par le modèle à chaque exécution : personne ne la conçoit, elle ne relève donc pas du graph engineering. C’est précisément elle que le preprint de Stanford et Cognition prennent en défaut.

Quand une équipe conçoit la hiérarchie de responsabilités (rôles, passages de relais, étape de merge), ces éléments entre les boucles relèvent eux aussi du graph engineering. Sinon, un humain coordonne à la main, comme avec le coding agent de GitHub Copilot, où quelqu’un attribue chaque ticket.

Le graphe n’est la prochaine strate que si la coordination est le goulot d’étranglement

Dans cette série, chaque strate s’est ajoutée à la précédente quand celle-ci est devenue assez bonne et que le goulot d’étranglement est remonté d’une strate. Le même test s’applique ici, en deux temps :

  • Le principal goulot d’étranglement s’est-il déplacé entre les boucles ?

  • Le travail de l’humain consiste-t-il désormais à concevoir ce qui s’y passe ?

Le graphe n’est la prochaine strate que si les deux réponses sont oui.

Si l’essentiel du temps d’une équipe sert encore à faire aboutir une seule boucle de façon fiable, un graphe ne fait qu’agencer des boucles peu fiables dans un ordre plus élaboré.

Les éléments qui appuient ce test, ci-dessous, datent de juin 2026 ou après et viennent de quatre types de sources :

  • Les éditeurs d’agents de code, qui décrivent leurs propres produits et leur usage : Anthropic (Claude Code), Cursor et Cognition (l’éditeur de Devin). Ils appuient l’idée qu’à grande échelle, le goulot d’étranglement et l’humain se sont déplacés entre les boucles (Cursor), que la coordination laissée à un agent principal coûte en précision (Cognition), et ils montrent à quoi ressemblent les deux formes de graphe dans les outils livrés (Anthropic) ;

  • Des ingénieurs qui décrivent leur propre pratique : Mergify, une entreprise qui vend des merge queues notamment à Mozilla, Elastic et Back Market, et qui a donc intérêt à ce que la relecture et le merge deviennent le goulot. Elle appuie l’idée que, même dans une petite équipe qui fait tourner beaucoup d’agents, le goulot passe de l’écriture du code à sa relecture, à la fin de chaque boucle plutôt qu’entre elles ;

  • Les enquêtes et la télémétrie : GitKraken, l’éditeur d’un client Git, qui a interrogé 554 personnes de sa propre communauté, et Jellyfish, une plateforme d’analyse pour les équipes d’ingénierie, qui publie les données de ses clients. Ils laissent penser que le goulot n’a pas bougé pour la plupart des équipes, puisque peu d’entre elles font tourner des agents en autonomie (GitKraken) et que presque toutes font encore relire chaque pull request par un humain (Jellyfish) ;

  • La recherche : un preprint du groupe d’Azalia Mirhoseini à Stanford, pas encore relu par des pairs. Il appuie l’idée que la coordination confiée aux sous-agents par défaut d’un agent coûte en précision, et qu’une coordination conçue pour le travail peut payer.

La plupart de ces sources ont un intérêt dans ce qu’elles rapportent, et aucune n’est une étude contrôlée de ce compromis.

Le goulot d’étranglement s’est-il déplacé ?

Oui, pour les équipes à grande échelle :

  • Cursor fait tourner des centaines d’agents de code en même temps ; avec la même tâche, les mêmes modèles et le même budget de temps, son ancien harness a cumulé plus de 70 000 conflits de merge avant d’être mis en pause, contre moins d’un millier pour le nouveau.

  • Les petites équipes se heurtent à des limites autour des agents : chez Mergify, un ingénieur qui fait tourner au moins dix sessions par jour (chacune dans son propre worktree et sur sa propre branche) a constaté que le goulot était passé de l’écriture du code à sa relecture, à la fin de chaque boucle plutôt qu’entre elles.

Probablement non, pour la plupart des équipes :

  • Dans l’enquête de juillet de GitKraken auprès de 554 développeurs et responsables, 28 % travaillent avec l’IA surtout en mode autonome, et 22 % n’utilisent pas d’agents au travail.

  • Sur plus de 1 300 entreprises, Jellyfish compte une médiane de 0,6 % de pull requests mergées sans aucune revue humaine : même quand des agents écrivent le code, un humain relit presque toujours avant le merge.

L’enquête de GitKraken compte les agents qui travaillent en autonomie, et les données de Jellyfish les merges sans relecture humaine, pas le nombre d’agents qui écrivent en parallèle. Or un développeur qui pilote lui-même cinq sessions interactives, chacune dans son worktree, fait déjà écrire plusieurs agents à la fois ; il n’apparaîtrait pourtant ni dans les 28 % de GitKraken, ni dans les 0,6 % de Jellyfish.

L’humain s’est-il déplacé ?

Oui, à grande échelle, vers ce qui se passe entre les boucles :

  • Les ingénieurs de Cursor ont conçu ce qui se trouve entre leurs agents : des planners qui découpent le travail, un agent de merge qui résout les conflits pour tous les autres, et leur propre système de gestion de versions.

  • Pour une migration de 500 fichiers, les dynamic workflows de Claude Code lancent un agent par fichier, chacun dans sa propre copie isolée, puis réunissent les modifications : un graphe de contrôle.

Chez Cursor, une personne écrit la spec, personne n’intervient pendant l’exécution, et le code est relu après coup. C’est déjà vrai pour une seule boucle : chez Mergify, un ingénieur relit lui-même chaque pull request poussée. La spec et la relecture ne distinguent pas le graphe de la boucle.

Non, quand les équipes s’en tiennent aux réglages par défaut :

  • Yuzhen Mao et ses collègues de Stanford ont constaté que Claude Code avec Opus 5.5 résolvait environ 72 % de dix longues tâches DeepSWE quand il travaillait seul, contre 50 % quand on lui demandait d’utiliser ses sous-agents, avec, dans ce second cas, un coût par tâche supérieur de 65 % (19,83 $ contre 12,01 $). Trois réserves :

  • L’écart ne vaut que sur un benchmark : sur dix tâches Terminal-Bench, Claude Code a perdu moins de deux points avec ses sous-agents (de 82 % à 80 %) ;

  • Une partie de l’écart mesure un réglage par défaut : beaucoup d’exécutions échouées ont atteint la limite d’inactivité de dix minutes que Claude Code appliquait alors au travail en arrière-plan dans les exécutions non interactives (la documentation actuelle indique que les sous-agents et workflows en arrière-plan tournent désormais jusqu’au bout) ;

  • Les auteurs ont un intérêt : ils proposent l’architecture à file de tâches partagée qu’ils comparent à Claude Code.

  • Cognition a observé la même chose avec Devin : « When the judgment is the deliverable, delegating it backfires. » (« Quand le jugement est le livrable, le déléguer se retourne contre vous. ») La coordination laissée au jugement d’un agent principal coûte en précision.

Une strate plausible, pas encore prouvée

Les enquêtes laissent penser que la plupart des équipes ne font pas encore tourner assez de boucles pour avoir besoin de les coordonner : leur travail se fait encore dans une seule boucle.

Les équipes qui font tourner beaucoup d’agents se heurtent à des limites à deux endroits :

  • Entre les boucles, au moment du merge, là où les agents entrent en collision à l’échelle de Cursor ;

  • À la fin de chaque boucle, à la relecture, comme par exemple chez Mergify.

Seul le premier relève du graph engineering, et les ingénieurs de Cursor conçoivent désormais ce qui se passe entre leurs agents. Pour les équipes de cette taille, le graphe est une prochaine strate plausible : leur goulot d’étranglement s’est déplacé, et l’humain aussi.

Ce qu’elles construisent dépend de la forme :

  • Des hiérarchies conçues à grande échelle : les planners et les workers de Cursor, avec le merge géré entre eux ;

  • Un graphe de contrôle quand le travail peut être listé à l’avance : un agent par fichier dans Claude Code ;

  • Un graphe de tâches, seulement à la pointe : disponible dans beads et dans les agent teams de Claude Code (expérimentales), mais hormis Yegge, aucune équipe n’a dit publiquement en faire tourner un en production depuis juin. Anthropic elle-même renvoie le travail aux nombreuses dépendances vers une session unique ou des sous-agents, alors que les dépendances sont justement ce que décrit un graphe de tâches.

Dans chaque cas, les équipes ont ajouté de la structure plutôt que d’en retirer. Conçue pour le travail, la coordination peut payer : la même étude de Stanford a montré que des agents partageant une même file de tâches et un même contexte battaient l’agent seul, avec 88 %.

Yegge joue dans une autre catégorie. Il a écrit en août que son premier orchestrateur, Gas Town, « fell apart at the seams with Opus 4.7 » (« est parti en morceaux avec Opus 4.7 ») : le nouveau modèle bricolait l’orchestrateur au lieu de faire le travail. Son successeur, Wheelhouse, fait tourner plus de 40 agents jour et nuit sur beads, intègre 120 à 150 commits d’un coup et garde plus de 700 tâches conçues en file d’attente pour le travail de nuit. Il ajoute bien plus de structure que Cursor : des agents à rôles, des règles écrites, une merge queue. Wheelhouse montre jusqu’où la coordination peut aller tout à la pointe, pas où en sont la plupart des équipes, et il est conçu pour une seule application, pas comme une couche que d’autres pourraient réutiliser.

La prochaine strate pourrait aussi arriver sous un autre nom. « Graphe » désignait quatre choses différentes dans le débat de juillet, selon le décompte de Turing Post. Hors du code, les graphes déclarés sont courants : LangGraph, Microsoft Agent Framework et Google ADK 2.0 modélisent les workflows d’agents sous forme de graphes, surtout pour des processus métier. Les outils d’agents de code appellent leurs versions sous-agents, listes de tâches, workflows, missions ou teams. Quel que soit le nom, le test reste le même : la coordination vous limite-t-elle davantage qu’une boucle prise isolément ?

Si le graph engineering est la prochaine strate, l’humain intervient entre les boucles, pour concevoir ce qui s’exécute quand et ce qui bloque quoi.

Le graphe s’imposera peut-être, ou le prochain buzzword arrivera avant la fin de cette série. Quand il arrivera, ne vous demandez pas comment il s’appelle. Demandez-vous où il fait intervenir l’humain.

À suivre dans la série : « Harness Engineering ou Agent = modèle + harness », sur la façon dont l’environnement est devenu le levier [article à paraître], et « Loop Engineering ou piloter la boucle sans y être », sur la frontière entre harness et boucle [article à paraître].

Sources
Voir l'article complet