LangChain contre LangGraph : ce que révèlent vraiment les dépendances des paquets
Une analyse au niveau des dépendances montre que LangGraph est une composante indispensable de LangChain, ce qui redéfinit le choix du framework en trois packages plutôt qu’en deux.
Le débat entre LangChain et LangGraph apparaît constamment dans les discussions techniques, et la réponse standard est presque toujours la même : optez pour LangChain lorsque vous avez besoin de chaînes d’actions et d’appels à des outils, et choisissez LangGraph lorsque vous avez besoin d’agents capables de gérer un état et d’exécuter des boucles. Cette réponse n’est pas fausse, mais elle repose sur une prémisse qui s’avère erronée à y regarder de plus près.
Une réponse plus précise se trouve en réalité sous nos yeux, directement dans les métadonnées du paquet lui-même.
Ce qu’une installation simple révèle
Essayez de lancer pip install langchain, puis examinez ce qui a réellement été enregistré sur le disque.
langchain-core==1.5.0
langgraph==1.2.9
pydantic==2.7.4
LangGraph est fourni automatiquement avec LangChain. Il ne s’agit pas d’un add-on optionnel que l’on peut omettre — c’est une dépendance obligatoire. En examinant le manifeste de langchain 1.3.14, seuls trois paquets sont indiqués comme des exigences strictes, et langgraph, dont les versions doivent être comprises entre 1.2.5 et inférieures à 1.3.0, fait partie de ceux-ci.
Essayez maintenant l’inverse : pip install langgraph. Cela télécharge langchain-core ainsi que les sous-paquets propres à LangGraph, mais langchain lui-même n’est jamais installé.
Cela signifie que la façon habituelle de voir les choses — en considérant cette décision comme un choix entre deux options uniquement — ne correspond pas à ce que votre gestionnaire de paquets permet réellement de faire. Installer LangChain garantit que LangGraph sera également installé. Aucune garantie inverse n’existe.
Trois paquets, pas deux
La plupart des comparaisons présentent cela comme une décision à deux volets. En réalité, il existe trois paquets distincts, et une fois que vous en nommez correctement chacun, la majeure partie de la confusion disparaît.
langchain-core constitue la base commune sur laquelle repose tout le reste. Il contient les types de messages, l’abstraction Runnable, BaseTool et RunnableConfig. À la fois langchain et langgraph dépendent directement de lui — rien dans aucun des deux paquets ne fonctionne sans lui.
langgraph est le véritable moteur d’exécution. Pensez-y comme une machine à états composée de nœuds, d’arêtes conditionnelles, d’un objet d’état partagé et de fonctionnalités de sauvegarde intermédiaire. Il a été conçu pour gérer les cycles, ce qui correspond essentiellement à la logique d’un boucle d’agent. Environ 40,2 % des fichiers sources de LangGraph importent directement langchain_core, ce qui montre qu’il ne s’agit pas d’une alternative concurrente à LangChain — il est construit sur les abstractions de base de LangChain.
langchain se situe au-dessus des deux en tant que package regroupant divers éléments. Il intègre des intégrations de modèles, des connecteurs de fournisseurs ainsi que des outils pratiques pour créer des agents en s’appuyant sur ces deux packages. C’est ce que vous installez si vous souhaitez utiliser ChatOpenAI ou ChatAnthropic directement, sans devoir écrire votre propre client HTTP depuis zéro.
Décrire cela comme des « chaînes linéaires contre des graphes à état » reflète une distinction ancienne qui n’existe plus dans le code. Une manière plus précise de l’exprimer aujourd’hui : LangGraph est le moteur qui effectue réellement le travail, tandis que LangChain constitue une couche de commodité qui regroupe ce moteur avec des intégrations de fournisseurs.
Le véritable choix que vous faites
Lorsque vous comprenez clairement la direction des dépendances — LangChain repose sur LangGraph, et jamais l’inverse — la question à laquelle vous répondez en réalité change de nature.
Cela cesse d’être « LangChain ou LangGraph ? » pour devenir : souhaitez-vous l’ensemble du framework langchain, avec ses intégrations de fournisseurs, ChatOpenAI, des outils d’aide à la création d’agents, ainsi que plus de 30 paquets optionnels supplémentaires ? Ou préférez-vous développer directement à partir de langchain-core et langgraph, en évitant cette couche supplémentaire ?
Les deux approches fonctionnent néanmoins sous LangGraph en arrière-plan. Ce qui diffère, c’est tout le reste qui est inclus dans votre environnement en même temps.
Si vous créez une image d’agent pour production où vous souhaitez un ensemble de dépendances bien délimité et facilement auditable, l’installation de langgraph ainsi que du client du fournisseur dont vous avez réellement besoin permet d’obtenir une image plus légère. Si vous travaillez rapidement sur un prototype et que vous voulez que ChatOpenAI fonctionne sans devoir créer manuellement un wrapper pour le fournisseur, pip install langchain[openai] vous y amène avec moins de configuration.
Un détail à souligner explicitement : langchain-core installe LangSmith, le client de suivi de LangChain, en tant que dépendance obligatoire. Il n’enverra aucune donnée à moins que vous ne le configuriez expressément pour cela. Cependant, si vous examinez précisément ce qui se trouve à l’intérieur de votre conteneur, il y est présent quel que soit le fait d’avoir activé ou non cette fonctionnalité.
Pourquoi ce choix importe au-delà de la taille d’installation
Une comparaison contrôlée a été menée entre LangGraph 1.2.9 et Pydantic AI 2.13.0 sur quatre tâches, pour un total de 160 exécutions utilisant gpt-4o. Les deux frameworks ont atteint une précision de 100 %. LangGraph a été légèrement plus rapide, d’environ 1,4 à 1,8 seconde en temps réel, un écart dû au mécanisme de conversion asynchrone en synchrone de Pydantic AI, mais la précision était identique pour les deux.
C’est le modèle sous-jacent qui a réellement influencé les résultats, et non le choix du framework. L’exécution des mêmes tâches avec gpt-4o-mini a entraîné un échec total — 0 sur 20 — pour une tâche impliquant des calculs de dates, un cas limite que le modèle plus grand a géré sans problème.
En bref : choisir entre LangChain et LangGraph revient principalement à décider dans quelle mesure vous souhaitez intégrer l’écosystème LangChain existant dans votre projet, puisque les deux reposent sur le même moteur de base. En revanche, choisir entre LangGraph et Pydantic AI signifie comparer deux bibliothèques véritablement distinctes — et les résultats ci-dessus indiquent que, avec gpt-4o, la précision n’est pas en faveur de l’une ou de l’autre, bien que l’écart de latence soit suffisamment important pour être mesuré dans votre propre configuration.
Lectures complémentaires
- Ce que LangChain automatise réellement une fois qu’on a créé un cycle d’agent — Explique comment LangChain, LangGraph et des SDK similaires encapsulent le même cycle d’agent développé de zéro, ainsi que les moments où s’appuyer sur un framework est avantageux ou préjudiciable.