LangGraph : quand la logique d'agent devient un graphe

La plupart des agents IA commencent leur vie sous la forme d’un script : une suite d’instructions qui appelle un modèle, traite sa réponse, appelle un outil, puis recommence. Cette forme linéaire suffit tant que la tâche est simple et qu’elle se déroule d’un trait. Elle montre ses limites dès que l’agent doit s’arrêter, reprendre, boucler, attendre une validation humaine ou revenir en arrière sur une décision. C’est là qu’une autre représentation s’impose : le graphe.

LangGraph, développé par l’équipe à l’origine de LangChain, part d’une idée simple : la logique d’un agent n’est pas une ligne, c’est un graphe dont les nœuds sont des étapes et les arêtes des transitions. Cette représentation change profondément ce qu’on peut faire, car elle rend explicite ce que le script cache : l’état à chaque instant, et les chemins possibles d’un état à l’autre.

Cet article explique ce qu’apporte concrètement cette représentation en graphe, les trois capacités qu’elle débloque, et les critères qui permettent de savoir si LangGraph est le bon choix pour un projet donné.

Un graphe, c’est d’abord un état explicite

Dans un script, l’état de l’agent est dispersé dans des variables locales, implicites, qui disparaissent dès que le programme s’arrête. Dans un graphe, l’état est un objet central, explicite, qui circule entre les nœuds et que l’on peut inspecter à tout moment. Cette différence paraît abstraite, elle est pourtant décisive dès que l’agent doit s’arrêter en cours de route.

Un exemple le montre. Un agent de support traite un ticket, génère une réponse, et doit attendre qu’un humain la valide. Avec un script, cette attente oblige à écrire de la logique de persistance et de reprise à la main. Avec LangGraph, l’état est simplement sauvegardé, le graphe se met en pause, et il reprend exactement là où il s’était arrêté quand la validation arrive. Cette capacité de reprise, appelée checkpointing, est fournie par le framework plutôt qu’écrite à la main par le développeur, avec une sauvegarde de l’état dans une base comme PostgreSQL en production.

L’état explicite rend aussi le comportement observable. On peut examiner ce que l’agent a décidé à chaque étape, reconstituer le chemin emprunté, comprendre pourquoi il a pris telle branche. LangSmith ou Langfuse affichent ce chemin nœud par nœud, avec les entrées et sorties de chaque appel au modèle. Cette observabilité manque cruellement aux scripts, où l’on se retrouve à ajouter des journaux après coup pour tenter de reconstituer ce qui s’est passé (on revient sur ce sujet dans logs et traces d’un agent).

Des arêtes conditionnelles et des boucles naturelles

La seconde chose que le graphe apporte, c’est la capacité à exprimer des branchements et des boucles sans code de contrôle fragile. Dans un script, chaque condition est un « si » écrit à la main, et l’enchaînement des conditions finit par former un enchevêtrement difficile à suivre. Dans un graphe, les transitions sont déclarées, et le framework se charge de les parcourir.

Concrètement, LangGraph permet de définir des arêtes conditionnelles : après un nœud, le prochain nœud dépend d’une décision, par exemple la sortie du modèle. On peut aussi définir des boucles : revenir à un nœud précédent tant qu’une condition n’est pas remplie, avec un garde-fou pour éviter la boucle infinie. Cette expressivité correspond exactement au besoin des agents, qui alternent réflexion et action jusqu’à atteindre un but ou abandonner.

Cette déclarativité a un avantage majeur : le chemin que peut prendre l’agent devient lisible et testable. On peut raisonner sur le graphe comme sur un plan, voir quelles transitions sont possibles, identifier les boucles sans issue. Là où un script force à lire le code ligne par ligne pour comprendre ce qui peut arriver, le graphe expose sa structure d’un coup d’œil.

La validation humaine intégrée au flot

La troisième capacité décisive est l’intégration native de la validation humaine. La plupart des agents ne doivent pas tout décider seuls : une action irréversible, une réponse sensible, une décision coûteuse méritent une validation. Avec un script, cette validation interrompt le flot et oblige à gérer la reprise à la main. Avec LangGraph, l’interruption est un mécanisme de première classe.

On marque un nœud comme interruptible, le graphe s’arrête avant de l’exécuter, et il attend une décision externe. Cette décision peut venir d’un humain qui valide, modifie ou rejette, ou d’un autre système. Une fois la décision prise, le graphe reprend avec l’état mis à jour. C’est le mécanisme du human-in-the-loop, l’un des patterns qui rendent un agent IA fiable, rendu naturel par la représentation en graphe.

Cette capacité ne supprime pas la complexité, mais elle la déplace : au lieu de l’écrire soi-même dans du code de gestion d’état, on la déclare dans le graphe. Le développeur se concentre sur ce qui doit être validé, et non sur la mécanique de l’interruption et de la reprise.

Quand LangGraph est le bon choix

Reste la question pratique : faut-il adopter LangGraph pour tous ses agents ? Non. Un agent simple, qui traite une requête d’un trait sans boucle ni interruption, se développe très bien avec du code ordinaire, et ajouter un framework serait une complexité gratuite. LangGraph devient utile à partir du moment où l’on a besoin d’au moins une de ces trois choses : un état à reprendre, des boucles et branchements non triviaux, ou des validations humaines.

Le critère se formule simplement : la complexité est-elle dans le raisonnement ou dans le flux ? Si la difficulté tient au raisonnement du modèle, à la qualité des prompts et des données, un framework de graphe n’aidera pas. Si la difficulté tient au flux, à l’enchaînement des étapes, aux reprises et aux validations, alors la représentation en graphe apporte une vraie valeur.

Il faut enfin garder à l’esprit que LangGraph est un outil parmi d’autres dans un paysage qui bouge vite. L’OpenAI Agents SDK et le Claude Agent SDK conviennent bien à un agent centré sur un modèle et ses outils, CrewAI à une organisation en équipe d’agents aux rôles définis. Les outils eux-mêmes peuvent être exposés via MCP, ce qui les rend réutilisables quel que soit le framework. Et pour de l’automatisation de processus métier, un outil visuel peut suffire (voir notre comparaison n8n vs LangGraph). Le choix d’un framework doit se faire sur les besoins du projet, pas sur la tendance du moment. La bonne démarche consiste à commencer simple et à n’adopter la représentation en graphe que lorsque la complexité du flux la justifie.

En pratique : choisir et construire

Choisir la bonne architecture pour un agent, en graphe ou non, demande d’avoir déjà vu des agents en production et de savoir où se situe réellement la complexité. Un test rapide : dessinez le flux de votre agent sur une feuille. S’il tient en une ligne droite, un script suffit. S’il comporte des pauses en attente d’un humain, des retours en arrière ou des boucles avec condition de sortie, la question LangGraph mérite d’être posée.

Sur chaque agent qu’on met en production, la règle reste la même : c’est le flux qui choisit l’outil, pas l’inverse. Si vous avez un agent à concevoir et que vous hésitez sur l’architecture, c’est le genre d’arbitrage qu’on tranche dès le cadrage quand on construit un agent IA : on part du flux réel et on vous laisse un code lisible, testable et reprenable par votre équipe.