LangGraph.js : orchestrer des agents avec état, sans framework haut niveau

Le problème : un agent n'est pas une chaîne d'appels

Une séquence linéaire question, appel de modèle, réponse suffit pour une démonstration. Elle ne suffit plus dès qu'une tâche dure, qu'elle doit survivre à un redémarrage, ou qu'un humain doit valider une étape intermédiaire. Le README présente LangGraph comme un cadre d'orchestration bas niveau pour des agents contrôlables, et cite Replit, Uber, LinkedIn et GitLab parmi ses utilisateurs. Ces noms servent d'illustration, pas de preuve technique. Le public visé est précis : des développeurs qui savent déjà appeler un modèle et qui veulent décider eux-mêmes du chemin parcouru entre deux appels. La documentation précise que la bibliothèque peut être utilisée sans LangChain, ce qui compte si vous refusez d'hériter d'une pile d'intégrations pour un seul graphe.

Un graphe, un état partagé, des transitions explicites

Le README décrit la bibliothèque comme un cadre d'orchestration bas niveau, avec des architectures personnalisables, de la mémoire longue durée et des interruptions pour supervision humaine. Le modèle sous-jacent est un graphe : des nœuds qui exécutent du code, des arêtes qui décident du nœud suivant, et un état qui traverse l'exécution. Le README indique que l'interface publique s'inspire de NetworkX, et que la conception est inspirée de Pregel et d'Apache Beam. Ces références situent le projet : on est plus près d'un moteur de calcul par étapes que d'un enchaîneur de prompts. La mémoire est présentée en deux couches, une mémoire de travail pour le raisonnement en cours et une mémoire persistante entre sessions. Le point de contrôle de l'état est ce qui rend la reprise possible, et c'est aussi ce qui impose de réfléchir à ce que vous sérialisez.

Installation et premiers repères

Le README donne une commande unique :

npm install @langchain/langgraph @langchain/core

Le paquet principal est @langchain/langgraph. Le README renvoie vers la référence API JavaScript et vers une documentation d'ensemble. Il mentionne aussi un cours d'introduction gratuit sur LangChain Academy et un dépôt d'exemples consacré au streaming. En revanche, le README fourni ici ne contient aucun exemple de définition de graphe, aucune signature de méthode, aucune clé de configuration. Impossible donc de décrire précisément la déclaration d'un nœud ou d'un point de contrôle à partir de ce seul matériau. C'est une limite du document, pas nécessairement de la bibliothèque, mais elle change ce que vous pouvez planifier avant d'ouvrir la documentation complète.

Ce que l'exécution durable implique vraiment

Le README annonce une exécution durable : des agents qui persistent à travers les échecs et reprennent exactement là où ils s'étaient arrêtés. Cette promesse a un coût de conception. Un état qui doit être rejoué après une panne doit être sérialisable, et les effets de bord d'un nœud doivent être pensés pour un monde où ce nœud peut être réexécuté. Si votre nœud envoie un courriel, écrit dans une base ou facture une API, la reprise devient un problème de conception, pas une option offerte par la bibliothèque. Le README ne traite pas ce point. Il faut le traiter soi-même, et c'est précisément le genre de décision qu'un cadre bas niveau laisse à l'utilisateur. C'est un choix assumé, pas un défaut caché, mais il faut le savoir avant de promettre une reprise automatique à une équipe.

Interruptions et mémoire : deux mécanismes, deux responsabilités

Les interruptions permettent, selon le README, d'inspecter et de modifier l'état de l'agent à n'importe quel moment de l'exécution. C'est le socle de la validation humaine : le graphe s'arrête, un opérateur regarde, corrige ou approuve, puis l'exécution continue. La mémoire longue durée est présentée comme persistante entre sessions. Ces deux mécanismes supposent un stockage d'état durable. Le README ne nomme pas de backend, ne décrit pas de schéma et ne donne aucune clé de configuration de persistance. Si votre contrainte est de garder l'état dans un système précis, ou de ne rien écrire hors de votre infrastructure, cette zone reste à documenter par vos soins. Un lecteur qui cherche une réponse toute faite sur le stockage ne la trouvera pas ici.

Quand LangGraph.js n'est pas le bon outil

Le README est explicite : pour construire rapidement des agents, il renvoie vers Deep Agents, un paquet de plus haut niveau bâti sur LangGraph, capable de planifier, d'utiliser des sous-agents et de s'appuyer sur un système de fichiers. Autrement dit, le projet lui-même indique la limite de son propre usage. Si votre besoin est un agent qui planifie et délègue, écrire le graphe à la main est du travail évité par une couche supérieure. Deuxième cas défavorable : un flux strictement linéaire sans état durable, où un graphe ajoute de la structure sans rien résoudre. Troisième cas : une équipe sans compétence TypeScript, puisque le dépôt est en TypeScript et que la bibliothèque Python équivalente existe séparément, avec sa propre documentation. Le choix de langage précède ici le choix d'outil.

Deep Agents : la comparaison utile

La différence entre les deux paquets est une différence de niveau d'abstraction, pas de fonction. Deep Agents est décrit comme un paquet de plus haut niveau construit sur LangGraph, destiné aux agents qui planifient, utilisent des sous-agents et exploitent un système de fichiers. LangGraph.js, lui, donne les primitives d'orchestration et laisse l'architecture à l'utilisateur. Concrètement : avec Deep Agents, la structure de l'agent est fournie ; avec LangGraph.js, elle est à écrire. Le second est plus flexible et plus exigeant. Le README présente cette relation comme un conseil d'orientation, pas comme une alternative concurrente. Si vous hésitez entre les deux, la question à trancher n'est pas laquelle est la meilleure, mais qui, dans votre équipe, doit décider du chemin d'exécution.

Maintenance, versions et licence

Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial et la modification, avec conservation de l'avis de licence. Ce texte n'est pas un conseil juridique : faites vérifier votre cas si la redistribution est au programme. Sur les versions, les publications récentes visibles concernent les paquets annexes @langchain/react, @langchain/vue et @langchain/svelte, tous en 1.0.36-rc.1. Le suffixe rc signale une version candidate, pas une version stable. Cela ne dit rien de la stabilité du paquet principal @langchain/langgraph, dont aucune version n'apparaît dans la liste fournie, mais cela indique que l'écosystème de liaisons front-end bouge encore. Le dépôt n'est pas archivé et le dernier push observé date de septembre 2026. Une mise à niveau de LangGraph.js peut donc entraîner celle de @langchain/core, et inversement. Vérifiez les versions de ces deux paquets ensemble avant de figer un lockfile.

Conclusion éditoriale

LangGraph.js convient aux équipes TypeScript qui doivent contrôler explicitement les transitions d'état, les interruptions et la reprise après échec, et qui acceptent d'écrire elles-mêmes l'orchestration. Il ne convient pas à qui veut un agent fonctionnel en quelques lignes : la documentation renvoie dans ce cas vers Deep Agents. Avant d'adopter, vérifiez deux points précis : le comportement de reprise après un redémarrage du processus, et la stabilité des paquets annexes, dont les versions publiées portent le suffixe rc.

Sources officielles

1. langchain-ai/langgraphjs on GitHub
2. License: MIT
3. Project website
4. README
5. Releases