Boucles contre graphes : deux approches pour concevoir des agents d’IA
Ingénierie des boucles versus ingénierie des graphes pour les agents d’IA : fonctionnement de chacune de ces architectures, quand choisir l’une plutôt que l’autre, ainsi qu’une liste de contrôle à utiliser avant la mise en production.
Sources: Loop Engineering vs. Graph Engineering: The Architecture Shift Quietly Reshaping AI Agents
Deux termes à la mode, une question d’architecture
Tout ceux qui suivent les agents d’IA capables de rechercher sur le Web, d’appeler des outils, d’écrire du code ou d’exécuter des workflows de manière autonome ont probablement rencontré récemment deux termes : l’ingénierie de boucles et l’ingénierie de graphes. Ils ressemblent à du marketing, mais ils renvoient à une véritable décision structurelle.
Imaginons un agent qui consomme 40 000 tokens et six minutes en temps réel pour résoudre une question qui aurait dû être résolue en trois étapes seulement. Il n’y a rien de mal avec le modèle ou la demande formulée. Le problème réside dans la conception, car l’agent ne peut pas savoir s’il a déjà tenté quelque chose. Il se contente de répéter les étapes de réflexion, d’action et d’observation, sans garder de trace de son propre processus.
Ce type d’échec fait passer la conception des agents hors de la catégorie des prompts pour les placer dans le domaine de l’architecture logicielle. Une fois vu sous cet angle, presque tous les systèmes d’agents mis en production reposent sur l’un de deux modèles : les boucles et les graphes. Ce qui suit explique ce qu’est chacun d’eux, comment ils sont construits, où ils échouent, et pourquoi le passage d’un modèle à l’autre modifie la façon dont les ingénieurs abordent ces systèmes, au-delà d’un simple changement d’outils.
Ce qu’un agent fait réellement
À tout moment donné, un agent effectue l’une de trois actions : il réfléchit (une appel à un LLM), il agit (un appel à un outil), ou il décide de la prochaine étape. L’ingénierie des agents consiste principalement à relier ces trois actions entre elles.
Pendant les premières années des agents LLM, presque tout le monde les concevait de la même manière, sous forme de boucle. C’était le choix évident. Les agents de type ReAct fonctionnaient ainsi dès le début, et c’est encore ainsi qu’Anthropic décrit l’agent le plus simple : un modèle qui utilise des outils de manière autonome en boucle.
Plus tard, les agents ont dû gérer des tâches plus complexes et plus volumineuses : plusieurs sous-agents spécialisés, des tentatives répétées, des validations humaines et des règles métier imbriquées. Une simple boucle ne suffisait plus pour gérer tout cela. Les équipes voulaient analyser la structure du processus plutôt que de compter sur le fait que la boucle aboutirait finalement à une solution, et ce besoin a donné naissance à l’ingénierie de graphes, qui représente le processus à l’aide de nœuds et d’arêtes, sans le laisser dépendre d’itérations répétées.
Aucun de ces modèles n’est incorrect. Ils répondent à des problèmes différents, donc chacun mérite d’être examiné en détail.
Une analogie tirée de la cuisine
Imaginez qu’on vous apprenne à cuisiner. L’ingénierie par boucles consiste en une instruction répétée : goûter la soupe, ajouter du sel si nécessaire, goûter à nouveau, et continuer jusqu’à ce que ce soit parfait. Il s’agit d’un cycle d’action, de vérification et, le cas échéant, de répétition. C’est simple, prévisible et facile à visualiser.
L’ingénierie graphique ressemble à une recette complète avec des branches. Coupez les légumes pendant que quelqu’un d’autre fait bouillir de l’eau. Lorsque tout est prêt, combinez-les. Si celui qui goûte souhaite plus d’épices, renvoyez la marmite à l’étape d’assaisonnement ; sinon, servez-la. Il n’y a pas ici une seule séquence d’étapes. Plusieurs chemins existent, certaines étapes se déroulent en même temps, d’autres dépendent d’une décision, et seules certaines reviennent en arrière lorsque quelque chose ne va pas.
Que signifie l’ingénierie par boucles
Une boucle est la méthode originale et la plus simple pour créer un agent. Elle fonctionne en un cycle continu :
- Recevoir les entrées, c’est-à-dire la question ou l’objectif de l’utilisateur.
- Réfléchir à ce qu’il convient de faire ensuite, ce qui correspond à l’étape de raisonnement du modèle.
- Agir, ce qui signifie généralement appeler un outil, exécuter du code ou rechercher des informations.
- Observer les résultats de l’action entreprise.
- Revenir à l’étape 2 et continuer jusqu’à ce que l’agent juge que l’objectif a été atteint.
Les gens appellent souvent cela un cycle de réflexion, d’action et d’observation, et de nombreux premiers agents ont été conçus sur cette base. Dans le cadre de la pratique de l’ingénierie en boucle, on considère l’agent comme un cycle répétitif unique : le modèle raisonne, choisit une action, l’exécute, étudie le résultat et l’enregistre dans son propre contexte, avant de recommencer jusqu’à ce qu’il conclue que la tâche est terminée ou qu’un plafond a été atteint.
Quelques points expliquent sa popularité :
- Celui-ci constitue la base du célèbre modèle ReAct (raisonnement combiné à l’action) proposé par Yao et ses collaborateurs, où les traces de raisonnement sont entremêlées aux actions, et un modèle n’a pas besoin de terminer tout son raisonnement à l’avance.
- La plupart des frameworks d’agents définissent également un « agent » de cette manière, comme un cycle de contrôle doté d’une fenêtre de contexte partagée et d’une interface de appel d’outils.
- Il suffit de quelques lignes de code pour en créer un. L’état correspond à la conversation menée jusqu’alors, et il n’y a qu’une seule condition de sortie. Un assistant de codage qui modifie un fichier ou un agent de recherche qui continue ses recherches jusqu’à être satisfait n’a pas besoin de quelque chose de plus complexe.
- Les directives d’Anthropic le confirment : commencez par l’approche la plus simple qui fonctionne, et n’ajoutez de structure que lorsque la tâche l’exige.
Le problème, c’est que tout ce sur quoi le boucle doit raisonner, y compris ce qu’elle a déjà essayé, ce qui a échoué et quel était l’objectif, doit se trouver à l’intérieur d’une fenêtre de contexte en perpétuelle expansion. Le processus ne dispose pas de mémoire distincte ; il ne conserve que des enregistrements.
Comment la boucle est constituée
Le flux s’exécute de bout en bout de cette manière.
Étapes par étapes :
- Une tâche effectuée par l’utilisateur démarre la boucle avec un objectif.
- Lors de l’étape de réflexion, le modèle lit le prompt du système, l’historique de la conversation ainsi que la dernière observation, puis décide de la suite des opérations.
- Vérifier si « la tâche est terminée ? » ne relève pas d’un système distinct ; c’est le modèle lui-même qui, en se basant sur son contexte, détermine si elle est achevée.
- Si elle n’est pas terminée, le modèle choisit un outil et l’appelle.
- Le résultat ou l’erreur de l’outil est renvoyé sous forme d’observation.
- Cette observation est ajoutée au contexte, et le cycle reprend avec une histoire légèrement plus longue à chaque itération.
- Lorsque le modèle a évalué le travail effectué, la boucle se termine et restitue la réponse finale.
Une version concise en Python montre à quel point peu de code est nécessaire.
def run_agent(task: str, tools: list, max_iterations: int = 10) -> str:
context = [{"role": "user", "content": task}]
for step in range(max_iterations):
response = llm.generate(context, tools=tools)
if response.is_final_answer:
return response.content
tool_result = execute_tool(response.tool_call)
context.append({"role": "assistant", "content": response.content})
context.append({"role": "tool", "content": tool_result})
return "Stopped: max iterations reached"
Que signifie l’ingénierie de graphes
L’ingénierie de graphes représente de manière explicite le processus de l’agent. Il s’agit d’un ensemble de nœuds, chacun étant une unité de travail telle qu’une appel à un LLM, un appel à un outil ou un élément de logique métier, reliés par des arêtes qui sont soit fixes, soit conditionnelles. Tous les nœuds lisent et écrivent dans un objet d’état partagé et typé. En bref, le flux de travail devient une carte de étapes connectées avec des chemins entre elles, remplaçant ainsi un cycle répétitif unique.
Un nœud peut être l’un de ceux-ci :
- un agent, une intelligence artificielle spécialisée ayant une tâche précise comme la recherche, l’écriture ou l’analyse
- un appel à un outil, par exemple une recherche sur le web, un calcul ou une requête de base de données
- un point de décision qui choisit le prochain chemin
- un point de fusion qui combine les résultats de plusieurs chemins
Plusieurs chemins peuvent s’exécuter en parallèle, et d’autres sont conditionnels et ne sont suivis que si un test est réussi. Les boucles restent possibles, mais elles n’apparaissent que là où elles sont nécessaires, en tant que mécanisme contrôlé qui fait revenir l’exécution à quelques étapes précédentes sans refaire aveuglément tout le processus.
Pourquoi les graphes sont attrayants
- Parallélisme. Les tâches indépendantes peuvent s’exécuter simultanément sans attendre dans une file d’attente.
- Départementalisation. Le flux de travail peut prendre différentes directions en fonction de la situation, sans se limiter à la répétition des mêmes étapes.
- Spécialisation. Chaque nœud peut être un agent expert doté d’une seule spécialité, ce qui correspond davantage à la manière dont une équipe humaine répartit le travail.
- Essais ciblés. Lorsqu’une étape, comme une vérification de qualité, échoue, seule cette étape fait revenir l’exécution pour être refaite, tandis que tout le reste reste inchangé.
LangGraph est un framework basé sur cette idée, qui modélise les flux de travail en tant que graphes dirigés cycliques à états. Un graphhe peut encore contenir des boucles, car un nœud peut être relié à un nœud précédent, ce qui permet les tentatives répétées et l’itération. Ce qui change, c’est que la boucle devient simplement l’un des nombreux arcs représentés sur une carte que l’on peut consulter, et elle cesse d’être l’ensemble de l’architecture.
Cela correspond étroitement à la distinction établie par Anthropic entre les flux de travail, où les LLM et les outils suivent des chemins de code prédéfinis contrôlés par les développeurs, et les agents, où le modèle dirige dynamiquement son propre processus. Un graphe peut représenter les deux dans une seule structure, avec des chemins fixes lorsque la prévisibilité est importante et des branches dirigées par le modèle là où la flexibilité est avantageuse, et la différence apparaît sur le diagramme.
Comment le graphe est construit
Prenons le même type de problème : un agent qui doit rechercher, écrire du code, examiner son propre résultat, puis le reconstruire, et représentons cela sous forme de graphe.
Passons en revue les étapes :
- START est le point d’entrée dans le graphe.
- Un nœud routeur lit l’état actuel et choisit un chemin. Il peut s’agir d’un simple
if/else, ou d’une appel à un LLM qui classe la requête.
Voici un pseudocode simplifié dans le style retenu par la plupart des frameworks de graphe.
from graph_engine import StateGraph, START, END
def router(state: dict) -> str:
return state["task_type"] # "research" | "code" | "review"
def research_agent(state: dict) -> dict:
state["results"]["research"] = do_research(state["query"])
return state
def code_agent(state: dict) -> dict:
state["results"]["code"] = write_code(state["query"])
return state
def review_agent(state: dict) -> dict:
state["valid"] = validate(state["results"])
return state
def aggregator(state: dict) -> dict:
state["final_output"] = merge(state["results"])
return state
graph = StateGraph(schema=AgentState)
graph.add_node("router", router)
graph.add_node("research_agent", research_agent)
graph.add_node("code_agent", code_agent)
graph.add_node("review_agent", review_agent)
graph.add_node("aggregator", aggregator)
graph.add_conditional_edges("router", {
"research": "research_agent",
"code": "code_agent",
"review": "review_agent",
})
graph.add_edge(["research_agent", "code_agent", "review_agent"], "aggregator")
graph.add_conditional_edges("aggregator", {
"valid": END,
"invalid": "router", # explicit retry edge
})
app = graph.compile()
app.invoke({"query": "...", "results": {}, "task_type": "code"})
En plaçant les deux modèles côte à côte, le contraste devient plus facile à observer.
Pourquoi l’industrie passe des boucles aux graphes
Ce changement n’a pas été soudain. Les boucles ont rencontré de réelles limites lorsque les gens ont tenté de créer des systèmes plus ambitieux, pour plusieurs raisons.
Le travail réel ne se déroule pas en ligne droite. La recherche, le support client, l’analyse financière et les flux de contenu prennent tous des chemins différents. Si la question concerne la facturation, on suit une voie, et s’il s’agit d’un problème technique, on emprunte une autre. Une boucle force tout cela dans une longue chaîne de conditions, ce qui devient rapidement chaotique.
Les systèmes multi-agents avaient besoin d’une structure meilleure. Lorsqu’un système comptait plusieurs agents, comme un chercheur, un résumérateur et un vérificateur de faits, une seule boucle ne pouvait pas indiquer que deux agents devaient travailler en même temps ou que l’un ne devait s’exécuter que si une vérification échouait. Un graphe permet de représenter cela naturellement.
La visibilité et la confiance deviennent plus importantes avec le temps. Autrefois, lorsque les agents s’occupaient de tâches à haut risque, les équipes avaient besoin d’une vue étape par étape de ce qui se produisait. Un graphique peut être dessiné et indiqué pour montrer précisément où une exécution s’est bien déroulée ou mal, tandis qu’une boucle est un bloc opaque qui exécute le même code vingt fois.
Coût et vitesse. Chaque itération inutile consomme du temps et souvent de l’argent réel, car chaque étape de réflexion correspond à une appel à un modèle de langage. Exécuter des étapes indépendantes en parallèle et ne reprendre que la partie à corriger est clairement plus efficace.
Les tests et la maintenance deviennent plus simples. On peut construire, tester et modifier un graphique nœud par nœud. Une boucle très complexe repose généralement sur une logique tout ou rien, ce qui rend sa modification en toute sécurité après le lancement plus difficile.
Choix entre les deux
Un cadre décisionnel approximatif suit.
Préférez une boucle lorsque :
- la tâche a un seul objectif : un seul agent, une seule finalité et un seul ensemble d’outils
- un prototype préliminaire doit être vérifié avant d’investir des fonds dans l’architecture
- le nombre d’étapes est faible et assez prévisible
- une seule personne est responsable de l’ensemble, sans besoin de transmettre quoi que ce soit à une autre équipe
Recourir à un graphe lorsque :
- deux ou plusieurs agents ou rôles spécialisés sont impliqués
- les tentatives de répétition, les solutions de secours ou les approbations humaines doivent être auditable
- des parties du processus peuvent s’exécuter en parallèle avant de devoir être fusionnées
- l’exécution doit être traçée, vérifiée à des points clés ou reprise à partir d’un point donné, ce que une transcription rejouée ne peut pas offrir
- des personnes ou des équipes distinctes gèrent des segments séparés, le graphe servant de cadre d’accord entre elles
Voici un test pratique. Si le code d’une boucle contient un commentaire du type « à ce stade, nous aurions déjà dû essayer X », c’est un signe que vous modélisez un graphe à l’intérieur d’une boucle de manière inadéquate, et il est probablement temps de dessiner ce graphe.
Il ne s’agit pas vraiment d’un choix binaire. Il s’agit plutôt d’adapter l’outil à la tâche. Un chatbot de base qui répond aux questions une par une, ou un petit script qui répète une action précise jusqu’à ce qu’elle soit terminée, conviennent à une boucle. Une tâche avec plusieurs étapes imbriquées, plusieurs agents spécialisés collaborant, des travaux parallélisables ou un besoin de visibilité claire sur ce qui s’est passé et pourquoi conviennent à un graphe. Une option raisonnable par défaut est de commencer par une boucle et de passer à un graphe dès que la logique « si ceci alors cela » devient difficile à suivre.
Une liste de contrôle pour la production
Avant de déployer l’un ou l’autre modèle, ces habitudes se révèlent utiles :
- Fixez des limites aux étapes. Les deux modèles nécessitent un disjoncteur, car un agent sans limite n’a aucune limite sur la facture.
- Rendez le critère de finition testable. La condition de sortie doit être quelque chose que des tests peuvent vérifier, et non une intuition du modèle.
- Instrumentez chaque étape. Attribuez à chaque appel à un LLM et à chaque appel à un outil son propre span OpenTelemetry ou équivalent, et évitez un seul span pour toute l’exécution.
- Versionnez le graphe. Conservez les définitions dans un système de contrôle de version comme n’importe quel code, car un changement discret d’arête modifie discrètement le comportement.
- Validez l’état aux frontières des nœuds. Vérifiez les schémas typés de l’état en entrée et en sortie de chaque nœud afin d’arrêter rapidement les données mal formatées.
En résumé
Une boucle représente la conception minimale, avec un seul contexte, un seul cycle et le modèle qui dirige le flux de contrôle. Elle convient aux agents spécialisés et à vocation unique. Un graphe, quant à lui, décrit le processus à travers des nœuds, des états et des arêtes que l’on peut dessiner, ramifier, exécuter en parallèle et réessayer délibérément.
Le changement fondamental n’est pas que les graphes soient meilleurs. Il s’agit d’un passage d’une pensée procédurale, qui se demande ce qui vient ensuite, à une pensée déclarative, qui se demande quelle est la forme du système. Les graphes s’accordent bien avec la discipline de suivi et d’observabilité dont ont besoin les systèmes de production, tandis que les boucles s’accordent bien avec une itération rapide.
La plupart des systèmes de production se transforment en fin de compte en graphes construits à partir de boucles, essentiellement des machines à états dont les nœuds sont de petits cycles de style ReAct. Cela fait des deux modèles des niveaux d’agrandissement différents au sein d’une même architecture, et non des concurrents. Pour tout projet d’agent actuel, une question pertinente est de savoir si tout fonctionne encore comme une seule grande boucle ou s’il est temps de le représenter sous forme de graphique.
Lectures complémentaires
- Des boucles d’agents aux graphes de flux de travail : état typé, portes de validation et récupération bornée — Pourquoi les agents à exécution prolongée dépassent les limites d’une seule boucle, et comment des nœuds explicites, des arêtes, des artefacts typés, des transitions vérifiées et des permissions par nœud en font des systèmes fiables.
- Ingénierie Agent Harness : état, vérification et contrôle autour du modèle — Une vue en temps de exécution des agents en production : pourquoi les prompts et le contexte ne suffisent pas, et comment un état durable, des mécanismes de contrôle, des vérifications et une capacité d’observation comblent ces lacunes.