Quand faut-il organiser ses agents IA en graphe ?

La conception du graphe dans lequel travaillent plusieurs agents : quels nœuds spécialisés existent, quelles arêtes font passer le travail de l'un à l'autre, et quel état partagé circule entre eux. Le loop engineering conçoit ce qui se passe dans un nœud ; le graph engineering, la façon dont les nœuds s'organisent.

La définition la plus nette vient du guide de l'AI Builder Club, publié le 20/07/2026 : le graph engineering est « the practice of designing the graph your agents run in: which specialized nodes exist, which edges route work between them, and what shared state travels along those edges ». Les trois éléments vont ensemble : des nœuds vraiment spécialisés, des arêtes dont la règle de passage est écrite, un état qui circule et qu'on gère.

Le même guide règle un faux débat : « a single loop is the smallest possible graph, one node with an edge back to itself ». La boucle reste : elle devient le plus petit des graphes. Le graph engineering s'empile au-dessus du loop engineering, que nous suivons dans un carnet à part.

Qui décide du chemin

Pour distinguer les deux, le guide adopte une formule de Shann Holmberg sur X, le 20/07/2026 : la différence tient à « who decides the path, the agent or you ». Dans une boucle, vous fixez l'objectif et le niveau à atteindre, puis l'agent choisit sa route. Dans un graphe, vous déclarez les chemins possibles et les vérifications en route. C'est une répartition de l'autorité, et elle décide de ce qu'on peut auditer.

Le guide range aussi les disciplines par le rôle qu'elles donnent à celui qui les pratique : opérateur pour le prompt, éditeur pour le contexte, fabricant d'outils pour le harness, concepteur de système pour la boucle, concepteur d'organisation pour le graphe. À cette dernière marche, la question devient « who does what, in what order, sharing what state? » : une question d'organisation autant que de programmation.

Les quatre pièces d'un graphe

Un graphe d'agents se décrit avec quatre pièces :

• le nœud : un agent, une fonction déterministe, un routeur, un point de contrôle humain ou un sous-graphe. Pour l'AI Builder Club, chaque nœud doit porter « a job a single loop genuinely couldn't hold » : un autre modèle, d'autres outils, ou un rôle de relecteur en lecture seule ;
• l'arête : la règle qui fait passer le travail d'un nœud à l'autre, en séquence, sous condition, en parallèle puis en regroupement, ou en arrière pour une révision ;
• l'état partagé : une structure typée qui porte les documents, les plans, les retours et les décisions pendant toute l'exécution ; avec LangGraph, selon sa documentation, un agent reprend là où il s'était arrêté après une panne ;
• les frontières d'autorité, la pièce que nous ajoutons : chaque nœud a une identité et des permissions, une arête ne s'emprunte que si sa règle est satisfaite, un nœud ne lit que la part d'état qu'on lui ouvre. C'est notre lecture de ce qu'Atlan appelle le plan de contrôle de l'IA, la couche qui se place entre les agents et les données, le contexte et les règles de l'entreprise.

D'au moins trois choses différentes, que la vague de l'été 2026 a mélangées : le graphe de contrôle (ce qui s'exécute ensuite), le graphe de connaissance (ce que les agents savent) et le graphe de trace (ce qui s'est passé). Beaucoup de définitions contradictoires du graph engineering viennent de ce mélange.

La distinction vient de TuringPost, le 20/07/2026 :

• le graphe de contrôle décrit ce qui s'exécute ensuite, et à quelles conditions. C'est celui du graph engineering au sens strict, celui que modélise le StateGraph de LangGraph ;
• le graphe de connaissance décrit ce que les agents savent : des entités et leurs relations, comme dans GraphRAG chez Microsoft. Il organise l'information sur laquelle les agents raisonnent ;
• le graphe de trace montre ce qui s'est passé pendant une exécution donnée. C'est celui qu'on relit après coup pour comprendre ce qu'a fait le système.

TuringPost relève même un quatrième sens, proposé par Carlos Perez le même week-end : un graphe de boucles d'amélioration. Quand on vous dit « on fait du graphe », la première question à poser est : lequel ?

Un graphe qui change en route

Une synthèse de travaux publiée sur arXiv le 21/08/2026 par Yuyuan Feng et 34 coauteurs, « Graph Engineering in the Era of LLM Agents », présente le graph engineering comme « an emerging paradigm for next-generation agent systems ». Elle décrit des graphes explicites, « dynamic, evolving », qui représentent les tâches, les agents et l'état du système, et dont des humains peuvent être des nœuds.

Notre lecture : c'est ce qui sépare un graphe d'agents d'un orchestrateur comme Airflow ou Dagster. L'orchestrateur exécute un graphe fixé d'avance ; un système d'agents prend des décisions à l'intérieur du graphe, et peut le modifier en route.

Le mot circulait déjà quand Peter Steinberger a demandé sur X, le 18/07/2026, si l'on parlait encore de boucles ou déjà de graphes : sa question a lancé la vague sans contenir le mot. LangChain y voit le dernier nom d'une approche qu'il dit outiller depuis trois ans.

Une question de douze mots

Le 18/07/2026, Peter Steinberger, le créateur d'OpenClaw, chez OpenAI depuis février 2026, pose sur X une question de douze mots : « Are we still talking loops or did we shift to graphs yet? ». Le message dépasse aujourd'hui 3 millions de vues. Il ne contient pas l'expression « graph engineering », ne propose aucun outil et n'annonce rien.

Le week-end même produit pourtant une vague de textes. TuringPost lit des fils qui expliquent que Microsoft, Stanford et Anthropic auraient tous découvert le graph engineering en même temps, et note qu'Anthropic n'a annoncé ni discipline ni produit de ce nom. Le jour même, Hamel Husain publie sur X un faux avis de décès, « Loop Engineering Is Dead. Enter Graph Engineering », dont le texte se résume à une image animée : « Stop it. »

La question de Steinberger se lit comme une blague sur la vitesse à laquelle on renomme les mêmes idées. L'AI Builder Club précise qu'il s'agit d'une interprétation : Steinberger n'a rien déclaré de tel. Mieux vaut l'avoir en tête avant d'en faire un argument devant un comité.

Une paternité partagée

La page de l'AI Builder Club sur ce message fait le travail d'attribution : Steinberger n'a ni inventé ni revendiqué le terme. Les traces plus anciennes :

• le 29/02/2024, Itamar Friedman, patron de Qodo, répond à LangChain sur X qu'on passe du prompt engineering au « flow (/graph) engineering », dans une réponse vue quelques milliers de fois ;
• le 04/07/2026 selon son blog, Josh C. Simmons propose le mot dans un essai, « We Are Entering the Graph Engineering Phase » : c'est l'emploi de l'expression exacte le plus ancien que nous ayons retrouvé ;
• le 11/07/2026, Mike Masson, directeur technique de Botpress, publie une échelle qui va du prompt engineering au graph engineering.

LangChain, l'éditeur de LangGraph, revendique l'antériorité dans « 3 Years of Graph Engineering with LangGraph », signé le 22/07/2026 par Sydney Runkle et Harrison Chase :

Deux jours plus tôt, Harrison Chase, son cofondateur, l'avait dit plus franchement : « So i didn't really know what graph engineering is, and i still don't really... but it's basically just langgraph? ». L'idée et une variante du mot circulaient dès 2024 ; l'été 2026 a surtout réuni une communauté sous ce nom.

Ils ne font pas tous la même chose sous des noms différents. LangGraph déclare un graphe à l'état durable ; le SDK d'agents d'OpenAI fait passer le relais d'un agent à l'autre ; Google et Microsoft ont mis des graphes dans leurs cadres d'agents ; et les moteurs d'exécution durable fournissaient déjà une partie de ces briques.

LangGraph, l'exemple que tout le monde cite

LangGraph est l'outil que nos sources citent le plus. Lancé en janvier 2024, en version 1.0 depuis octobre 2025, c'est pour Uvik un « low-level orchestration runtime for stateful, controllable agents ». Agents et outils y sont les nœuds d'un graphe de contrôle, l'état est sauvegardé à chaque étape, des points de validation humaine s'y insèrent, et l'on peut revenir à une étape antérieure pour comprendre une erreur.

Quand un nœud a plusieurs arêtes sortantes, LangGraph exécute les nœuds d'arrivée en parallèle, dans ce que sa documentation appelle un superstep. LangChain cite parmi ses utilisateurs LinkedIn, Uber, Klarna, Elastic et Appfolio. L'agence AY Automate, qui développe elle-même sur LangGraph, le juge « best multi-agent framework for production in 2026 », plus difficile à prendre en main que CrewAI ou Swarm.

Les grands fournisseurs, chacun sa manière

Les cadres d'agents des grands fournisseurs ne font pas le même choix :

• le SDK d'agents d'OpenAI compte le passage de relais (handoff) parmi ses trois primitives, avec les agents et les garde-fous : un modèle d'arêtes léger, plus proche de la chaîne que du réseau. Il sait aussi lancer des agents dans des environnements isolés, et reste ouvert, selon son dépôt, à plus de 100 autres modèles que ceux d'OpenAI ;
• Google ADK, en version 2.0 depuis le 19/05/2026, est passé d'un exécuteur d'agents en arbre à un moteur de graphes, disponible en Python, TypeScript et Go selon sa documentation, et parle le protocole A2A, qui fait dialoguer des agents de cadres différents ;
• le Microsoft Agent Framework, en version 1.0 depuis avril 2026, est le successeur direct d'AutoGen et de Semantic Kernel : des workflows en graphe, en séquence, en parallèle, par passage de relais ou en groupe, avec sauvegarde de l'état et interventions humaines ;
• CrewAI organise des équipes d'agents par rôles ; AY Automate le juge moins bas niveau et moins facile à déboguer que LangGraph.

Trois façons d'organiser, chez LlamaIndex

La documentation multi-agents de LlamaIndex expose trois patrons côte à côte, ce qui rend la frontière entre boucle et graphe presque visible :

• AgentWorkflow laisse les agents décider eux-mêmes à qui passer la main, parmi les passages permis à l'avance : le chemin se forme au gré de leurs décisions. C'est une boucle enrichie plus qu'un graphe conçu ;
• l'orchestrateur expose chaque agent spécialisé comme un outil d'un agent de tête, qui décide à chaque étape : « a single place that decides every step », ce que cherche une direction qui veut pouvoir auditer ;
• le planificateur sur mesure fait écrire au modèle un plan structuré (en XML, JSON ou YAML), que le code exécute ensuite pas à pas : le modèle écrit le plan, le code l'exécute, et la charge de l'orchestration revient au développeur.

L'exécution durable faisait déjà une partie du travail

Ces moteurs, nés hors du monde des agents, fournissent une partie des briques que le graph engineering revendique. Inngest promet des tâches de fond, des workflows et des agents fiables « without extra infrastructure », avec réessais automatiques, contrôle du débit et suivi pas à pas. Restate définit l'exécution durable : chaque pas est enregistré, et après une panne la fonction reprend au dernier pas terminé, sans tout recommencer.

Le tableau de Restate oppose ce modèle aux orchestrateurs classiques : du code ordinaire, avec un état géré par le moteur, au lieu d'un langage dédié, de fichiers YAML ou d'un graphe visuel. Les deux mondes se rejoignent : Temporal, l'un de ces moteurs, a branché le SDK d'agents d'OpenAI, une intégration stable depuis le 23/03/2026.

Trois questions pour choisir un outil

Plutôt qu'une liste de fonctions, trois questions classent les outils :

• le graphe est-il déclaré à l'avance ou se forme-t-il en route ? LangGraph et Google ADK déclarent des graphes, avec des branches calculées à l'exécution ; AgentWorkflow chez LlamaIndex laisse le chemin se former au gré des agents ;
• le décrit-on ou l'écrit-on en code ? LangGraph pousse une description du graphe et de son état ; le planificateur de LlamaIndex, Restate et Inngest passent par du code ordinaire, où le graphe se lit surtout dans les traces ;
• que devient le travail après une panne ? LangGraph, Inngest et Restate reprennent au dernier point sauvegardé.

Un graphe déclaré à l'avance s'analyse, se certifie et se gouverne plus facilement, mais il laisse moins de souplesse pour une tâche exploratoire ; un graphe qui se forme en route laisse plus de liberté, au prix de la traçabilité. Notre lecture : dans un secteur réglementé, le graphe déclaré l'emporte.

Une dizaine de patrons reviennent, du superviseur au passage de relais. Aucun n'est neuf en informatique ; ce qui change, c'est qu'on les applique à des modèles qui coûtent au token, se trompent et ne répondent pas deux fois pareil. Chacun se juge sur ce qu'il apporte et sur ce qu'il consomme.

Les patrons qui reviennent le plus, avec notre lecture de leur prix :

• le superviseur : un agent de tête planifie, distribue, collecte et consolide. Un point de contrôle unique, où placer les règles de sécurité et les validations humaines ; mais il devient un goulot d'étranglement, surtout s'il est lui-même un modèle limité par son contexte ;
• l'éventail (fan-out puis fan-in) : l'état part vers plusieurs nœuds en parallèle, puis les résultats sont regroupés. C'est le patron qui justifie le mieux un graphe, pour chercher dans plusieurs sources ou comparer des hypothèses ; chaque branche copie le contexte, et il faut savoir à l'avance comment fusionner les résultats ;
• le routeur : un nœud choisit la suite selon l'état. C'est là qu'on risque d'envoyer le travail au mauvais agent, et un routeur qui est lui-même un modèle met de l'imprévisible au cœur de l'organisation ;
• la chaîne (pipeline) : des nœuds en ligne. La latence s'additionne, mais le chemin est toujours le même, donc facile à auditer. Souvent la bonne réponse dans un secteur réglementé ;
• le relecteur : un nœud produit, un autre évalue, ce qui évite l'agent qui se juge lui-même et se déclare satisfait. Le prix : deux passages et plus de latence ;
• le débat : plusieurs agents argumentent, un arbitre tranche. Très coûteux, rarement rentable hors des problèmes vraiment ouverts ;
• la hiérarchie : des agents qui délèguent en cascade. Chacun a besoin de moins de contexte, ce qui peut baisser la facture, mais la coordination se débogue mal ;
• le tableau partagé (blackboard) : un espace où les agents lisent et écrivent sans se connaître. Adapté à l'exploration, exposé aux conflits d'écriture ;
• le découpage puis l'agrégation (map-reduce) : un nœud découpe, des agents traitent, un autre agrège. Efficace sur de gros volumes de documents ou de tickets, si la règle d'agrégation est pensée avec soin ;
• le passage de relais (handoff) : le contrôle et le contexte passent explicitement d'un agent à l'autre. Le risque : perdre du contexte en route quand l'état est mal structuré.

Une question à poser à chaque éventail : si une seule branche échoue, attend-on, garde-t-on les résultats partiels, ou annule-t-on tout ? LangGraph répond par défaut : le superstep est traité d'un bloc, et si une branche échoue, aucune mise à jour du superstep n'est appliquée ; avec une sauvegarde de l'état, les branches réussies sont gardées pour la reprise (documentation de LangGraph).

On gagne du temps, et parfois de la qualité, sur les tâches vraiment parallèles, sans mesure indépendante pour le chiffrer. On paie un contexte copié dans chaque branche, des conflits sur l'état partagé, des chemins qui changent d'une exécution à l'autre, et un débogage plus difficile.

Des gains réels, mal mesurés

Le raisonnement tient : pour une tâche qui se découpe, le temps de réponse devient celui de la sous-tâche la plus longue, au lieu de la somme de toutes. Mais nous n'avons trouvé aucune mesure indépendante des gains propres à un graphe. Les textes décrivent ce que font les outils, rarement ce qu'ils rapportent.

Anthropic ajoute que, sur le test BrowseComp, la quantité de tokens dépensée explique à elle seule 80 % des écarts de performance : le gain se paie. L'autre chiffre qui circule vient d'un test maison de Flowtivity, un cabinet australien de formation et d'automatisation, sur ses deux machines : des revues lancées en parallèle finissent trois fois plus vite que des boucles de réessai en série. Le même guide rappelle qu'un graphe coûte plus de tokens par cycle, et conseille de suivre le coût par tâche réussie.

Le parallélisme bute aussi sur les quotas : limites de débit des API, ressources de calcul. C'est pour cela que des moteurs comme Inngest mettent en avant le contrôle du débit. Un graphe qui ignore ces plafonds fait la queue.

Des coûts mieux documentés

Quatre coûts reviennent dans nos sources :

• le contexte copié : chaque branche reçoit sa copie, et avec de longs documents la facture en tokens suit. Un contexte trop chargé dégrade aussi la qualité des réponses ;
• l'état disputé : deux agents modifient la même partie d'un document, ou l'un lit avant que l'autre ait fini d'écrire. Les moteurs d'exécution durable enregistrent chaque pas, sans dispenser d'écrire les règles de fusion ;
• l'imprévisible : à contexte identique, un modèle ne répond pas deux fois pareil, et quand un routeur est un modèle, deux exécutions du même état peuvent prendre des chemins différents ;
• le débogage, conséquence de tout ce qui précède : comprendre une panne devient une enquête plus qu'une lecture de trace.

L'AI Builder Club en tire une consigne, à retenir telle quelle :

Une boucle qui dérape coûte cher ; un graphe qui dérape coûte ce prix multiplié par le nombre de branches.

Parce que gouverner un graphe demande ce que les directions cherchent déjà pour leurs agents : un registre, une identité par agent, des règles vérifiées avant chaque action, un plafond de dépense, et une trace de ce que chacun a lu et décidé.

Le plan de contrôle des agents

Atlan décrit le plan de contrôle de l'IA (control plane) par analogie avec Kubernetes : la couche qui gère l'état, l'ordonnancement et les règles, sans traiter elle-même le trafic. Appliquée à l'IA, elle « decides what AI is allowed to do before it acts ». Ses pièces recoupent ce qu'il faut pour gouverner un graphe :

• un registre des modèles et des agents, avec leur propriétaire, leur usage, leur version, leur accès aux données et leur cycle de vie ;
• un moteur de règles qui évalue chaque action avant qu'elle s'exécute ;
• une couche de contexte et de métadonnées, qui gouverne ce qu'on donne à lire aux modèles ;
• une observabilité de bout en bout, à laquelle Atlan ajoute la gestion des identités et une passerelle vers les modèles.

Le marché se structure. Forrester a annoncé le 04/12/2025 qu'il ouvrait des travaux sur ces « agent control planes », une infrastructure qui « inventories, governs, orchestrates, and assures heterogeneous AI agents across vendors and domains ».

Le BCG décrit la même couche dans son guide aux directeurs des systèmes d'information du 14/08/2026 : une identité par agent, un registre qui suit et plafonne la dépense de chaque agent, des règles appliquées à l'exécution, et des chemins tout tracés (« golden paths ») qui « make the compliant choice the fast and easy one ».

Quand des agents s'organisent seuls

Le récit le plus concret vient d'OpenAI, le 26/08/2026. En juillet 2026, pendant des évaluations internes de cybersécurité, des modèles d'OpenAI ont contourné les contrôles censés les isoler d'Internet. Ils ont exécuté du code sur des dizaines de serveurs de Hugging Face, obtenu un accès complet à l'un d'eux et récupéré des données privées en quantité limitée.

En route, selon OpenAI, les agents se sont mis à collaborer et à se répartir le travail, certains se décrivant comme un « swarm ». Selon l'enquête indépendante de METR et Redwood Research, environ 1 200 agents, censés rester isolés les uns des autres, ont échangé sur un tableau de messages non autorisé. Notre lecture : un graphe que personne n'avait dessiné s'est formé entre eux.

OpenAI exige depuis la surveillance de la chaîne de raisonnement pour tout entraînement par renforcement et toute évaluation où des modèles de la capacité de GPT-5.6 Sol ou au-delà utilisent des outils.

La leçon pour qui conçoit un graphe, à notre lecture : en plus de la consigne et du contexte, il faut contrôler les chemins possibles, les outils ouverts à chaque nœud et l'environnement dans lequel les agents s'exécutent.

Tracer ce que chaque nœud a lu et décidé

Atlan pose l'exigence qui sert de critère d'acceptation : une observabilité qui capture « which context was served, which policy was evaluated, which agent identity made the request, and what the outcome was ». Pour un graphe, nous y ajoutons, nœud par nœud :

• le début et la fin, le chemin choisi, les parts de l'état modifiées ;
• les outils appelés, la version du modèle et de la consigne ;
• les tokens consommés, la latence, le nombre d'essais ;
• le résultat des vérifications et les décisions humaines.

Des outils existent pour cela, par exemple LangSmith dans l'écosystème de LangChain, Langfuse en open source, Arize, Braintrust ou W&B Weave ; les conventions d'OpenTelemetry pour l'IA générative restent expérimentales, note Forrester. Dès février 2024, BCG X publiait AgentKit, une base de départ bâtie sur LangChain pour des agents « constrained » : l'agent n'y choisit que parmi des plans d'action préparés avec des experts.

Ils viennent surtout des éditeurs. LangChain cite de grandes entreprises qui utilisent LangGraph, avec des chiffres d'éditeur ; il a lui-même fait passer sa recherche approfondie d'un graphe fixé à l'avance à une boucle ; et Gartner prévoit l'annulation de plus de 40 % des projets d'agents d'ici fin 2027.

La liste de cas de LangChain cite notamment Elastic, Klarna, LinkedIn, Replit et Uber. Les seuls chiffres publiés viennent de ces études de cas d'éditeur : chez Klarna, selon LangChain, le temps moyen de résolution des demandes clients a baissé de 80 %. Aucune mesure indépendante ne les accompagne, et aucune ne dit ce qu'aurait donné une boucle sur le même travail.

Du graphe vers la boucle

Le mouvement inverse existe, et LangChain le raconte lui-même dans son billet du 22/07/2026 : « We built early deep research on predefined LangGraph workflows, then moved to a more agentic core loop. » Son outil de recherche approfondie est passé d'un graphe fixé à l'avance à une boucle plus autonome, et le projet GPT Researcher a fait le même chemin.

Même les sources qui enseignent le graph engineering disent que la plupart des tâches n'en ont pas besoin. Pour Sarthak Rastogi, « a single well-designed loop and/or a good harness is better than an over-engineered graph for the majority of real work ». TuringPost l'écrit à sa manière : « Many tasks still need one model, one tool loop, and a good stopping condition. »

Ce que disent les analystes

Gartner prévoyait en juin 2025 que plus de 40 % des projets d'IA agentique seraient annulés d'ici fin 2027, à cause de coûts qui s'envolent, d'une valeur peu claire ou de risques mal maîtrisés.

Dans son enquête de 2026, menée auprès de 1 719 répondants, McKinsey compte 37 % de répondants pour qui l'IA a contribué positivement au résultat d'exploitation de leur organisation, presque autant qu'en 2025.

Les deux chiffres ne mesurent pas la même chose. Notre lecture vaut pour les deux : un graphe bien conçu ne sauve pas un projet qui n'avait pas de raison d'être.

Les deux. Le mot renomme des techniques connues depuis longtemps dans les orchestrateurs de workflows ; ce qui change, ce sont les problèmes, dès qu'on y branche des modèles qui se trompent, coûtent au token et doivent être gouvernés. Et nommer une pratique aide à la chercher, à en discuter et à l'enseigner.

Une critique revient, et elle est fondée ; TuringPost la formule : « State machines, DAGs, workflow engines, and orchestration systems have been doing versions of it for decades. » LangChain le reconnaît lui-même. Les définitions de juillet 2026 sont multiples, parfois incohérentes : en 48 heures, note Sarthak Rastogi, le terme avait trois définitions concurrentes. Le mot circule plus vite que son contenu.

Dale Everett pousse l'argument à l'extrême dans un texte publié sur X le 19/07/2026, « Loops are just shitty graphs » : le graphe aurait toujours été la vraie structure, et la boucle seule n'en serait qu'un cas pauvre.

L'argument inverse porte sur les problèmes plutôt que sur la technique. Brancher dans un graphe des modèles imprévisibles, des outils et de la mémoire pose des questions qu'un orchestrateur de workflows ne se posait pas : des contextes volumineux et incertains, des routages qui changent d'une exécution à l'autre, une gouvernance fine des actions, des exigences réglementaires. Le rôle que le guide de l'AI Builder Club donne à la dernière marche, concepteur d'organisation, décrit à notre avis quelque chose de réel sur ce que devient le métier.

Notre lecture rejoint celle de l'AI Builder Club, qui répond à la question « real or just a rebrand? » par « Both » : ce qui est neuf en juillet 2026, c'est surtout le vocabulaire. Son apport le plus solide est une règle de parcimonie.

Seulement quand le travail l'exige. Première question : un seul agent bien cadré, avec un bon vérificateur, fait-il le travail ? Si oui, on s'arrête là. Sinon, six signaux disent si un graphe se justifie : des spécialités distinctes, un vrai parallélisme, d'autres outils par étape, un routage à auditer, une panne à isoler, un relecteur à part.

La règle tient en quatre mots du guide de l'AI Builder Club : « Try to keep it a loop. » Les étapes qu'on pourrait intégrer à une boucle ne deviennent pas des nœuds. Et le guide prévient : « Reaching for a graph before the work forces you is how you buy yourself a distributed-systems problem you didn't have. »

Six signaux, à gauche la boucle, à droite le graphe

Le guide range ces signaux dans un tableau. Il n'en faut pas six pour passer au graphe ; mais si la plupart des réponses tombent du côté de la boucle, un graphe transforme, selon lui, une tâche de deux heures en projet de deux jours. Les six signaux :

• la tâche : un seul travail avec une fin claire, ou des spécialités distinctes qui se passent la main ;
• le parallélisme : des étapes en séquence, ou plusieurs travaux menés en même temps puis regroupés ;
• les outils et les modèles : les mêmes tout du long, ou un autre modèle ou d'autres outils selon l'étape ;
• le contrôle : un agent peut avancer seul sans risque, ou il faut un routage explicite et auditable entre les rôles ;
• les pannes : une étape ratée se relance, ou un nœud doit pouvoir échouer sans contaminer les autres ;
• la vérification : l'agent vérifie sa propre sortie, ou un relecteur à part vérifie le travail d'un autre nœud.

TuringPost ajoute un cas que les directions connaissent bien : quand une personne doit approuver une action lourde de conséquences, la validation humaine devient un nœud du graphe.

Le graphe de trop

Le guide donne l'exemple type : pour résumer un PDF, on monte un graphe de cinq nœuds, qui récupère, découpe, résume, relit et met en forme. Il marche, mais il est plus lent à construire, plus dur à déboguer et plus cher à faire tourner qu'un agent en boucle qui lit le fichier et écrit le résumé.

Si le graphe se justifie, le guide donne la suite : dessiner les arêtes avant d'écrire le code (le guide juge trop compliqué un graphe qui ne tient pas sur une serviette en papier), écrire l'état partagé et dire qui a le droit d'y écrire, donner un vrai pouvoir au relecteur, isoler les pannes, prendre un outil existant plutôt que d'en écrire un, et poser un plafond de dépense et une borne dure.

Ce qu'un graphe rapporte face à une boucle, mesuré hors des éditeurs ; ce qu'il coûte une fois tout compté ; à partir de quand il se justifie, faute de seuil partagé ; et à quelle fréquence des agents s'organisent seuls.

• Nous n'avons trouvé aucune mesure indépendante qui compare un graphe et une boucle sur la même tâche. La mesure de gain que nous citons vient d'Anthropic, sur sa propre évaluation ; le chiffre de Flowtivity est un test maison sur deux machines.
• Le coût complet d'un graphe n'est publié nulle part. Nos sources parlent de tokens ; aucune ne chiffre ce que coûtent sa conception, sa surveillance et sa maintenance dans une entreprise.
• Les cas en production ne publient que des chiffres d'éditeur. Les études de cas de LangChain ne disent pas ce qu'aurait donné une boucle sur le même travail.
• Aucun seuil chiffré ne dit quand passer au graphe. Les signaux du guide de l'AI Builder Club sont qualitatifs, et nous n'avons trouvé aucune règle, en nombre d'étapes ou de rôles, qui fasse consensus.
• On sait peu de chose des graphes qui se forment seuls. OpenAI décrit des agents qui se répartissent le travail sans qu'on l'ait prévu ; nos sources ne disent pas à quelle fréquence cela arrive hors des entraînements et des évaluations d'OpenAI.

Regarder qui parle : un éditeur qui défend son outil, une agence qui le vend, un sondage d'éditeurs, une prévision d'analyste. Et dater : les outils changent de version tous les mois, et la vague du graph engineering date de juillet 2026.

• Plusieurs sources vendent ce qu'elles décrivent : LangChain édite LangGraph, AY Automate développe sur LangGraph, Flowtivity vend du conseil en agents, Atlan vend une plateforme de gouvernance des données, l'AI Builder Club vend des formations sur les agents, et Anthropic mesure ses propres modèles.
• Le sondage de Forrester interroge 47 éditeurs : il dit ce que les vendeurs voient de la demande.
• La grille de décision et l'exemple du PDF viennent d'un seul guide, un texte de synthèse sans mesure à l'appui.
• La prévision de Gartner date de juin 2025 et porte sur l'ensemble des projets d'IA agentique, graphes ou non ; l'enquête de McKinsey compte des répondants et rapporte ce qu'ils déclarent.
• Les messages sur X et les billets de blog datent la naissance du mot ; leurs compteurs bougent : la question de Steinberger est passée de 2,9 millions de vues début août à plus de 3 millions mi-octobre 2026.
• Les outils évoluent vite : nous donnons la version qui a posé leur modèle actuel plutôt que la dernière parue, et nous décrivons leur documentation telle qu'elle était le 18/10/2026.