LangChain vs LangGraph : quel outil pour votre workflow ?

LangChain vs LangGraph : lequel choisir pour votre application ?

Choisissez LangChain pour une boucle d’agent configurable. Utilisez directement LangGraph lorsque vous devez concevoir le processus qui l’entoure. Pour décider, posez-vous trois questions : qui choisit l’étape suivante, quelles données doivent survivre à une interruption et quelles responsabilités d’exploitation souhaitez-vous prendre en charge ?

Pour démarrer un assistant de support qui consulte des commandes et répond aux questions, utilisez create_agent de LangChain. Vous fournissez le modèle, les outils et les instructions ; l’abstraction d’agent gère les échanges répétés entre le modèle et les outils. Ajoutez un middleware, c’est-à-dire du code exécuté autour de ces échanges, pour appliquer une règle ou demander une validation.

Si votre application utilise déjà LangChain, conservez-le tant que vous ne pouvez pas nommer une exigence de workflow difficile à exprimer avec cette abstraction. Ajouter une mémoire conversationnelle ou faire valider un appel d’outil ne suffit pas : les agents LangChain actuels proposent déjà ces deux fonctions grâce à LangGraph. Documentation des agents LangChain.

En revanche, si l’application doit valider une demande, réunir des éléments justificatifs, attendre l’intervention d’un opérateur, exécuter une action autorisée puis vérifier le résultat, envisagez un workflow LangGraph sur mesure. Ces étapes traduisent des règles métier que vous pouvez rendre explicites, tout en laissant un agent effectuer le travail plus souple à l’intérieur d’une étape.

Les conditions d’utilisation des bibliothèques figurent sur les pages produit de LangChain et de LangGraph. La comparaison fonctionnelle s’appuie sur la présentation du moteur d’exécution et la documentation du middleware de validation de l’éditeur. Il s’agit d’une recommandation d’architecture, pas d’un classement de rapidité.

LangChain et LangGraph : quel rôle joue chacun aujourd’hui ?

LangChain fournit les composants et l’abstraction d’agent ; LangGraph fournit le moteur d’orchestration avec état sur lequel ils reposent. Les considérer comme deux solutions concurrentes à substituer l’une à l’autre conduit à des migrations inutiles.

LangChain : une couche d’agent configurable

LangChain présente create_agent comme un « cadre d’exécution minimal et hautement configurable ». Ce cadre désigne tout ce qui entoure le modèle : instructions, outils disponibles et contrôles du comportement. La même présentation précise que « les agents de LangChain sont construits sur LangGraph ». Présentation de LangChain.

Son atout est de fournir une structure de départ utile. Pour un assistant de suivi des commandes, vous pouvez exposer votre fonction de consultation existante comme un outil et encadrer son utilisation par des règles. Inutile de construire la boucle à la main avant de travailler sur le produit.

Sa limite tient à l’adéquation de cette structure au besoin. Un dossier traité dans la durée, avec des étapes métier nommées, peut devenir difficile à comprendre si chaque transition se retrouve enfouie dans des prompts, des conventions d’utilisation des outils et des middlewares. C’est une question de maintenabilité : cela ne signifie pas que les agents LangChain ne savent ni gérer des embranchements ni conserver un état. La bibliothèque est gratuite ; l’accès aux modèles et l’infrastructure choisie restent des coûts distincts.

LangGraph : un moteur de workflow que vous pilotez

LangGraph se définit comme un « framework et moteur d’orchestration de bas niveau » pour les agents avec état dont l’exécution peut durer longtemps. Un nœud est une unité de travail ; une arête détermine la prochaine étape ; l’état rassemble les informations transmises entre ces étapes. Vous pouvez combiner de la logique applicative classique avec des décisions prises par un modèle. Présentation de LangGraph.

LangGraph prend l’avantage lorsque le workflow fait lui-même partie du produit. Un modèle peut rédiger une réponse, tandis que le code applicatif détermine si une validation est nécessaire et si l’action approuvée a déjà été exécutée.

Sa limite est la responsabilité qu’il vous confie. À vous de concevoir un état pertinent, les transitions et le comportement en cas d’échec. Des frontières mal définies produisent un logiciel confus, même sous forme de graphe. LangGraph est lui aussi gratuit et s’utilise sans LangChain ; conserver les composants de modèles et d’outils de LangChain reste souvent pratique.

Un compromis pratique consiste à intégrer un agent LangChain dans un processus plus large. Gardez cette abstraction pour les tâches souples qui mobilisent des outils et explicitez la séquence métier autour d’elle là où c’est nécessaire.

Agents LangChain et LangGraph : où placer le contrôle ?

LangChain simplifie la boucle de l’agent ; LangGraph donne un contrôle explicite sur l’enchaînement des étapes métier. La persistance de l’exécution et la validation humaine sont des capacités communes, dont la configuration reste déterminante.

Boucles d’agent et validation des appels d’outils : avantage LangChain

Un assistant qui consulte une commande, explique son statut et propose une réponse entre bien dans le cadre de la boucle modèle-outils. Ajouter une validation avant qu’un outil envoie la réponse reste dans ce cadre : HumanInTheLoopMiddleware peut suspendre les appels d’outils configurés et accepter une approbation, une modification des arguments ou un rejet. Il utilise la persistance de LangGraph pour conserver l’état interrompu. Documentation de la validation humaine.

Pour une application LangChain existante, l’évolution reste donc assez ciblée : configurez la politique de validation et un mécanisme persistant de sauvegarde des points de contrôle, puis reliez la décision en attente à votre application. Le middleware ne construit pas la file des demandes à examiner et ne décide pas quel salarié a le droit d’approuver : ces responsabilités restent du ressort de l’application.

Étapes métier explicites : avantage LangGraph

Choisissez un graphe sur mesure lorsque l’étape suivante doit découler du dossier métier, plutôt que du prochain outil proposé par le modèle. Prenons l’intégration d’un fournisseur : réunir les justificatifs, vérifier les champs obligatoires, soumettre une exception à un opérateur, puis activer le fournisseur seulement après validation.

Un graphe peut représenter directement ces transitions. Le nœud de collecte des justificatifs peut toujours appeler un agent LangChain. La validation et l’activation peuvent être des fonctions classiques aux résultats explicites. La capacité documentée de LangGraph à combiner des étapes déterministes et des étapes pilotées par des agents fait ici la différence. Présentation de LangGraph.

Le critère de bascule est concret : descendez d’une couche lorsque rendre l’état et les transitions explicites lève une incertitude récurrente sur ce que l’application a le droit de faire ensuite. Un prompt plus long, davantage d’outils ou une réponse lente du modèle ne suffisent pas, à eux seuls, à établir ce besoin.

Persistance et reprise : un socle commun, une conception plus ou moins exigeante

Un checkpointer sauvegarde l’état du workflow d’un fil d’exécution pour permettre sa reprise ultérieure. Un store conserve des informations définies par l’application et partagées entre plusieurs fils, comme une préférence utilisée dans des conversations distinctes. Ces mécanismes répondent à des besoins de persistance différents. Documentation de la persistance.

Quelle que soit l’approche, choisissez un stockage adapté à la panne que vous devez pouvoir surmonter. InMemorySaver conserve les points de contrôle dans le processus en cours et les perd au redémarrage. Il permet de montrer un état conversationnel ou une interruption ; il ne démontre pas la capacité à reprendre après la disparition du processus de travail. Un mécanisme de sauvegarde de production adossé à une base de données, ou la persistance gérée par Agent Server, répond à cette exigence de stockage.

Distinguez aussi un point de contrôle d’une confirmation d’exécution d’une action externe. Enregistrer « prêt à activer le fournisseur » ne prouve pas que le système fournisseur a accepté l’activation. Conservez l’identifiant externe et le résultat dans un enregistrement applicatif dont vous pourrez vérifier la cohérence.

L’éditeur documente ce comportement de reprise et la nécessité de rendre les effets de bord idempotents, c’est-à-dire de permettre la répétition d’une opération sans répéter son effet métier. Utilisez, par exemple, un identifiant d’opération stable pour qu’une tâche reprise ne puisse pas créer deux fois le même fournisseur. Règles d’interruption et de réexécution.

LangChain vs LangGraph en Python : une même tâche simple

Pour consulter simplement le statut d’une commande, LangChain exprime la même intention avec moins de code d’orchestration. Le graphe sur mesure rend visible le parcours entre modèle et outils ; il devient utile lorsque ce parcours doit évoluer.

Ces exemples utilisent le même modèle, le même prompt, le même outil en lecture seule et la même entrée. La commande provient d’un jeu de données local explicitement fictif. Installez langchain[anthropic] et langgraph ; pour appeler réellement le modèle, votre application doit disposer de ANTHROPIC_API_KEY. L’identifiant du modèle est celui des exemples actuels de la présentation de LangChain et du guide de démarrage LangGraph de l’éditeur. Les deux extraits ont été vérifiés localement avec un modèle simulé par script afin de contrôler l’exécution de l’outil et la sauvegarde de l’état. Cette vérification porte sur l’assemblage des composants, pas sur le comportement ni les performances du modèle réel.

Enregistrez cette configuration commune dans common.py :

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain : utiliser la boucle existante

Exécutez ce code dans un script séparé, à côté de common.py :

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

L’agent repose déjà sur le moteur d’exécution du graphe. Lui passer un checkpointer n’impose pas de remplacer create_agent par un graphe écrit à la main. Configuration de l’agent.

LangGraph : déclarer la même boucle

Exécutez ce script alternatif à côté du même fichier common.py :

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

L’arête conditionnelle dirige un appel d’outil demandé vers tools, ou termine l’exécution lorsque le modèle produit une réponse finale. Le nœud des outils rend ensuite la main au modèle. C’est le schéma de boucle explicite du guide de démarrage LangGraph, avec les composants fournis pour gérer les nœuds d’outils.

Les deux extraits utilisent volontairement une mémoire limitée au processus et ne montrent que le cas d’une lecture réussie. Aucun ne constitue une procédure de déploiement, une configuration de base de données persistante ou une politique complète de gestion des erreurs. Une configuration identique ne garantit pas des réponses du modèle identiques mot pour mot.

Pour cette tâche, choisissez LangChain. Un graphe sur mesure devient utile lorsque le besoin suivant modifie le processus : validation obligatoire avant la consultation, file distincte pour les exceptions ou étape d’approbation nécessitant son propre état et ses propres résultats.

LangSmith et déploiement LangGraph : quels tarifs prévoir ?

Le choix de la bibliothèque ne détermine pas un tarif d’hébergement différent. La décision payante porte sur les services LangSmith et l’environnement de déploiement nécessaires. Les tarifs et la documentation produit ci-dessous ont été vérifiés sur les pages en ligne de l’éditeur le 13 octobre 2026.

LangChain, LangGraph et LangSmith : des rôles distincts

LangSmith est la plateforme de traçage, d’évaluation et de déploiement qui entoure votre application. Une trace enregistre une exécution de l’application et peut contenir ses appels au modèle ainsi que d’autres étapes. Elle se distingue du point de contrôle qui permet de reprendre l’application. Tarifs et définitions LangSmith.

Les deux bibliothèques sont gratuites. Les exécuter sur une infrastructure que vous exploitez suppose toujours de budgéter les appels aux modèles, le calcul, le stockage et l’exploitation. Souscrire à LangSmith est une décision séparée ; sa documentation de déploiement prend explicitement en charge les applications LangGraph et LangChain.

Ce sont les conditions publiées sur langchain.com/pricing. Le calculateur de cette page précise que l’offre Plus inclut 10K traces au total : ajouter des utilisateurs n’implique pas d’obtenir un quota supplémentaire pour chacun. Il affiche 0.005 LSU par trace supplémentaire dans la configuration d’observabilité présentée. Cette valeur ne doit pas être généralisée à toutes les options de conservation des traces.

Les traces de base sont conservées 14 jours ; les traces étendues sont conservées 180 jours et entraînent un supplément. Une conservation plus longue et les services d’évaluation sont des choix budgétaires distincts, pas des avantages gratuits liés au choix d’un graphe. FAQ sur les tarifs.

Options de déploiement : possibilités et limites

Cloud est l’option gérée, accessible à partir de l’offre Plus. LangChain exploite l’infrastructure. Au sein de Cloud, la page publique des tarifs propose des déploiements Serverless et Dedicated, aux tailles Small, Medium et Large. Environnements de déploiement.

Serverless convient aux tâches intermittentes, en arrière-plan ou tolérantes à la latence. Les ressources peuvent descendre à zéro en l’absence d’activité, et Plus inclut un petit déploiement. Dedicated convient aux applications destinées aux clients qui exigent une disponibilité constante, avec une infrastructure toujours active, une mise à l’échelle automatique, des sauvegardes et une haute disponibilité. Ce sont les usages préconisés par l’éditeur, pas des mesures de performances issues de ce comparatif. FAQ sur les tarifs de déploiement.

Une limite pratique compte dans le plan de migration : vous pouvez modifier la taille d’un déploiement, mais pas son type après sa création. Passer de Serverless à Dedicated exige donc de basculer vers un autre déploiement, et pas simplement d’ajuster sa taille. Les ressources Serverless sont par ailleurs facturées tant qu’elles sont provisionnées, y compris pendant l’inactivité qui précède leur réduction. La possibilité de descendre à zéro ne signifie pas que chaque seconde sans requête est gratuite. Fonctionnalités de la plateforme Cloud.

Hybrid conserve le plan de contrôle géré, tandis que vous exploitez l’infrastructure des agents. Le plan de contrôle est le service qui gère les déploiements ; le plan de données exécute les agents et les services dont ils dépendent. L’auto-hébergement avec plan de contrôle place les deux dans votre environnement. La page des tarifs réserve les options hybrides et auto-hébergées à Enterprise, avec une tarification sur mesure. Aucun montant mensuel fixe public ne peut être utilisé à sa place. Tarifs et environnements de déploiement.

Agent Server en mode autonome constitue une autre option d’exploitation, sans plan de contrôle et avec des services sous-jacents que vous fournissez. Sa documentation exige une licence LangSmith, PostgreSQL et Redis. Cette option se distingue de l’intégration de la bibliothèque gratuite LangGraph dans votre propre application. La documentation déconseille également de déployer ce serveur autonome dans un environnement serverless capable de descendre à zéro ; le produit Cloud Serverless géré correspond à une configuration distincte. Agent Server en mode autonome.

À charge de travail égale, le coût est le même avec les deux frameworks

La page publique fixe le prix à $1.00 par LSU, pour LangChain Standard Unit, et publie les unités de facturation suivantes pour le déploiement :

• Calcul du runtime : 0.0675 LSU / vCPU-hr.
• Mémoire du runtime : 0.0090 LSU / GiB-hr.
• Calcul de la base de données : 0.177 LSU / vCPU-hr.
• Mémoire de la base de données : 0.025 LSU / GiB-hr.

Ces tarifs s’appliquent à la consommation facturable des ressources des déploiements Serverless et Dedicated supplémentaires. Tarifs de déploiement publiés.

Pour un agent LangChain comme pour une application LangGraph sur mesure, le calcul mensuel de l’offre Plus suit la même formule : $39 × nombre d’utilisateurs, auxquels s’ajoute, pour chaque ressource, le nombre d’heures facturables multiplié par le tarif ci-dessus, puis les frais de modèles, de traçage et les autres consommations applicables. Déduisez les ressources de déploiement incluses avant de calculer la part facturable. Ne convertissez pas des requêtes ou des nœuds de graphe en heures de ressources sans mesures à l’appui.

Voici des calculs fondés sur les tailles publiées par l’éditeur : ce sont bien des montants calculés, pas des prix de forfait annoncés. Un déploiement Serverless Small supplémentaire dispose de 1 vCPU et 2 GiB de ressources de runtime, soit 1 × 0.0675 + 2 × 0.0090 = $0.0855 par heure provisionnée. Un déploiement Dedicated Small comprend 3 vCPU et 6 GiB pour le runtime, plus 1 vCPU et 4 GiB pour sa base de données, soit 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335 par heure provisionnée. Ces estimations dépendent de la taille choisie et précèdent toute mise à l’échelle supplémentaire ou tout autre service. Elles utilisent le tableau des tailles et les tarifs publiés.

Pour un seul utilisateur Plus avec ce profil de ressources Dedicated maintenu constant, le sous-total mensuel est $39 + $0.5335 × heures provisionnées, avant les autres frais mentionnés. La formule est identique pour les deux frameworks. Pour garantir un montant mensuel, il faut connaître le temps réel d’allocation des ressources et la mise à l’échelle de votre déploiement.

À charge de travail égale, aucun seuil tarifaire ne fait basculer l’avantage d’un framework à l’autre. L’écart calculé est de $0 lorsque le nombre d’utilisateurs, les ressources facturables, l’usage des modèles et des outils ainsi que la politique de traces sont identiques. Repenser un workflow peut modifier ces quantités, mais le nom de la bibliothèque n’accorde aucune remise et ne démontre pas une baisse de la facture de tokens.

Passer de LangChain à LangGraph sans tout réécrire

Faites migrer la partie de l’orchestration qui exige davantage de contrôle et conservez les composants qui fonctionnent. Le vrai coût de la migration vient de la refonte de l’état, du comportement et de la reprise, pas du changement d’une instruction d’import.

Distinguez d’abord la mise à niveau d’une ancienne API du choix d’un graphe sur mesure. Le guide de migration actuel recommande langchain.agents.create_agent à la place de l’ancien constructeur langgraph.prebuilt.create_react_agent. Suivre cette migration ne revient pas à abandonner le socle LangGraph. Une application ancienne peut d’abord tirer parti des capacités actuelles de LangChain, avant d’avoir besoin d’une orchestration sur mesure. Guide de migration LangChain.

Ne faites pas migrer un assistant LangChain qui fonctionne simplement parce que les graphes paraissent mieux adaptés à la production. Si la boucle, le middleware et le stockage persistant répondent aux exigences, un graphe sur mesure ajoute du travail de conception sans bénéfice démontré.

La dépendance technologique se joue elle aussi à plusieurs niveaux. Les composants réutilisables de modèles et d’outils peuvent rester en place pendant que l’état du graphe et le flux de contrôle évoluent. L’infrastructure hébergée ajoute ses propres contraintes : dans Cloud, l’accès à la persistance passe par Agent Server et la base de données hébergée n’est pas directement accessible. Tenez compte de cette limite d’accès dans tout projet futur d’export ou de changement d’hébergement. Détails de la persistance Cloud.

Si votre choix porte plutôt sur l’orchestration par graphe face à une abstraction d’équipe de spécialistes, lisez LangGraph vs CrewAI. Pour explorer d’autres solutions, consultez le comparatif des frameworks d’agents IA.

Les questions à se poser avant de choisir

Utilisez la checklist d’audit des workflows métier avec l’IA pour définir la tâche, le périmètre de validation et le responsable de l’exploitation avant de changer l’orchestration.