Ce que LangChain automatise réellement une fois qu’on a créé un cycle d’agent
Explique comment LangChain, LangGraph et d’autres SDK similaires encapsulent le même cycle d’agent de base construit à partir de zéro, et quand s’appuyer sur un framework est avantageux ou préjudiciable.
Jusqu’ici, vous avez assemblé un agent complet à partir de matériaux bruts — le boucle, la mémoire, les outils, les sous-agents, les connecteurs — en utilisant uniquement le SDK Anthropic standard. Aucun framework n’est visible.
C’est précisément le moment de parler des frameworks, car quelque chose d’utile se produit maintenant : puisque vous avez construit tout le mécanisme vous-même, aucun framework ne vous semblera plus mystérieux.
Les noms que vous entendez constamment
LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. Le SDK OpenAI Agents.
Chacun d’eux possède sa propre terminologie et sa propre manière de structurer ce qui semble être la même tâche de base. Si vous êtes nouveau dans ce domaine, le grand nombre d’options peut paraître déroutant.
Il existe une idée clé qui dissipe cette confusion :
Chacun de ces frameworks recouvre exactement la même boucle que vous avez déjà construite précédemment dans cette série.
C’est vraiment tout le secret. Aucun d’eux ne contient de magie cachée. Au fond, ils exécutent tous la même séquence : envoyer des messages, examiner la raison d’arrêt, exécuter des outils, puis renvoyer les résultats. C’est le même cycle que vous comprenez déjà parfaitement.
Imaginez cela comme la cuisine. Une fois que vous avez appris à préparer un plat à partir d’ingrédients crus, vous connaissez chaque étape, vous pouvez goûter et ajuster en cours de route, et si le goût n’est pas bon, vous savez exactement ce qu’il faut changer. Un framework ressemble plutôt à un kit de repas — les légumes sont déjà coupés, la sauce est prémixée, et il suffit de tout assembler en quelques minutes. C’est plus rapide, certes. Mais si la sauce ne fonctionne pas, vous n’avez aucun moyen de la corriger, car vous ne l’avez jamais préparée vous-même et vous ne savez pas ce qu’elle contient.
C’est l’équilibre que propose tout framework : vous sacrifiez un peu de contrôle en échange d’une vitesse accrue.
Voir par soi-même
Examinons le même agent implémenté deux fois — une fois manuellement, une fois à l’aide d’un framework.
Voici à peu près à quoi ressemble votre agent en utilisant le SDK brut, la version que vous comprenez désormais parfaitement :
messages = [{"role": "user", "content": user_message}]
while True:
# call the API — this runs again every time the model asks for a tool
response = client.messages.create(
model="claude-sonnet-4-6",
tools=tools,
messages=messages,
) # if the model is done, stop
if response.stop_reason == "end_turn":
break # otherwise it asked for a tool: run it, append the result, loop again
messages.append(response_as_message)
messages.append(tool_result_message)
C’est précisément la boucle présentée plus tôt dans cette série. L’appel à l’API se trouve à l’intérieur d’une boucle while car il est exécuté répétitivement — une fois pour la réponse initiale, puis à nouveau après chaque retour de résultat d’outil — jusqu’à ce que le modèle indique qu’il a terminé.
Comparez maintenant cela à l’agent plus ou moins identique construit avec LangChain :
from langchain.agents import create_agent
agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})
Cinq lignes au lieu de trente. En apparence, cela semble être une amélioration évidente.
Mais remarquez ce qui a disparu. La boucle a disparu. La vérification de stop_reason a disparu. Le traitement manuel des messages a disparu. Aucune de ces logiques n’a vraiment disparu — elles continuent de fonctionner, mais elles sont maintenant cachées à l’intérieur de create_agent où on ne peut plus les voir.
Lorsque tout se passe bien, vous gagnez du temps. Lorsqu’un problème survient, vous êtes bloqué à déboguer un processus que vous ne pouvez pas examiner.
Cette tension est en réalité toute l’essence des frameworks. Tout le reste n’est que des détails ajoutés par-dessus.
Ce que vous faites réellement vs ce que fait le framework
C’est là que les gens ont souvent la surprise. Une fois que vous utilisez un framework, vous ne regardez jamais directement stop_reason. Vous ne vérifiez jamais la présence d’un bloc tool_use. Vous n’ajoutez jamais manuellement un tool_result. Vous n’écrivez jamais la boucle du tout.
Au lieu de cela, votre tâche se résume à trois étapes :
- Rédigez les fonctions de vos outils, exactement comme vous le feriez avec le SDK brut.
- Enregistrez ces fonctions auprès de l’agent à l’aide d’une commande comme
create_agent(tools=[...]). - Appelez
agent.invoke(...)une seule fois.
C’est tout le flux de travail : vous connectez les outils et déclenchez l’appel une seule fois.
Dans le cadre de cet appel unique, le framework exécute silencieusement tout le cycle que vous avez construit précédemment : envoi des messages, vérification de la raison d’arrêt, détection du besoin d’un outil par le modèle, invocation de votre fonction, ajout du résultat, boucle à nouveau, et répétition de ce cycle jusqu’à ce que le modèle renvoie finalement end_turn. Ce n’est qu’à ce moment-là qu’il vous transmet la réponse finale.
Ainsi, un framework ne cache pas seulement la boucle elle-même — il cache l’ensemble du mécanisme qui permet au départ l’appel d’outils. Quelqu’un qui apprend les agents en partant d’un framework ne saurait même pas qu’une raison d’arrêt comme end_turn existe, ni que les appels d’outils sont résolus par des itérations répétées. Pour lui, cela ressemblerait simplement à « J’ai enregistré un outil et il a été utilisé automatiquement ».
C’est parfait tant que l’appel d’outil fonctionne correctement. Lorsque celui-ci commence à se comporter de manière anormale, on se retrouve face à une boîte noire, car on n’a jamais vu le mécanisme qui fonctionne en arrière-plan. Vous, en revanche, avez construit ce mécanisme de vos propres mains ; vous savez exactement ce qui s’y passe.
LangChain, LangGraph — quelle est la différence ?
Ces deux noms reviendront constamment, alors voici la version courte.
LangChain est le framework lui-même. Il fournit des définitions d’outils, des connexions de modèles ainsi que la fonction create_agent — le même raccourci permettant de cacher les boucles évoqué précédemment.
LangGraph est un environnement de exécution de niveau inférieur sur lequel repose LangChain. On l’utilise lorsque l’on a besoin d’un contrôle plus fin : mettre en pause un agent afin qu’un humain puisse valider une étape, coordonner des logiques de branchement entre plusieurs agents, ou conserver l’état du système pour que un serveur tombé en panne puisse reprendre exactement là où il s’était arrêté.
Un modèle mental simple : LangChain constitue le point d’entrée rapide et de haut niveau. LangGraph est ce à quoi on recourt lorsque ce point d’entrée ne suffit pas. Depuis la fin de 2025, LangChain a été reconstruit sur LangGraph, de sorte que ces deux outils ne sont plus concurrents — ils représentent plutôt deux couches d’un même système, l’une simple et l’autre puissante.
Si vous commencez tout juste, vous n’en avez probablement pas besoin pour l’instant. Le SDK brut que vous connaissez déjà peut vous permettre d’aller très loin, de manière surprenante.
Lorsqu’un framework est utile
Les frameworks ne sont pas intrinsèquement une embûche. Dans certaines situations, en faire usage est véritablement la bonne décision.
Vous avez besoin d’intégrations prêtes à l’emploi. Supposons que votre agent doive récupérer des enregistrements depuis un stock vectoriel Pinecone et des documents depuis Google Drive. Écrire ces connexions vous-même à l’aide du SDK brut est possible, mais fastidieux. LangChain les fournit déjà prêts à l’emploi — il suffit de les importer et de les connecter. Cela représente un réel gain de temps.
Vous développez un prototype sous délai. Votre manager souhaite voir une démonstration fonctionnelle demain matin. À ce stade, les détails internes n’ont pas encore d’importance — il vous faut simplement quelque chose de fonctionnel rapidement. Une configuration en cinq lignes peut vous y amener dès ce soir.
Il vous faut une orchestration véritablement complexe à mettre en place. Imaginez un agent qui s’arrête au milieu d’une tâche, attend que quelqu’un clique sur « approuver » avant de libérer un paiement, puis reprend exactement là où il s’était arrêté — même après une redémarrage du serveur. Certains frameworks offrent ce comportement prêt à l’emploi. Le recréer de zéro représente un effort d’ingénierie considérable.
Lorsqu’un framework nuit
Le débogage devient difficile. Imaginez que votre agent renvoie parfois une réponse vide sans que vous puissiez en comprendre la raison. Dans du code que vous avez écrit vous-même, vous ajouteriez une instruction d’affichage, suivriez la boucle et trouveriez le problème en quelques minutes. À l’intérieur d’un framework, ce même bug se trouve quelque part dans la fonction create_agent — du code qui n’est pas le vôtre. Vous vous retrouvez donc à fouiller dans le code source du framework sur GitHub rien que pour comprendre ce que fait votre propre agent.
L’abstraction commence à présenter des failles. Les frameworks sont optimisés pour les cas courants. Supposons que vous ayez besoin que les résultats d’un outil soient formatés de manière non standard, ou qu’une politique de tentative soit adaptée à votre configuration spécifique. Le framework n’a jamais été conçu pour cela. Vous devez alors recourir à des solutions de contournement complexes simplement pour le forcer à faire ce que trente lignes de code écrits vous-même auraient pu gérer directement.
Vous finissez par apprendre l’outil plutôt que le concept. Commencer avec un framework vous enseigne « comment LangChain fonctionne », et non la manière dont les agents opèrent réellement. Par la suite, l’API de LangChain évolue — ce qui arrive fréquemment — et vos connaissances deviennent obsolètes du jour au lendemain. Le cycle abordé précédemment dans cette série n’a pas changé depuis la création initiale des agents, et il ne changera pas.
La règle à suivre
Commencez avec le SDK brut. Construisez la boucle manuellement. Ainsi, vous savez précisément ce que fait votre agent et pouvez suivre chaque étape lorsque quelque chose ne fonctionne pas. Pour la plupart des agents, c’est vraiment tout ce dont vous aurez besoin.
Intégrez un framework uniquement lorsqu’il résout un problème spécifique mieux que vous ne pourriez le faire — une intégration prête à l’emploi, un état qui survit aux pannes, des étapes d’approbation impliquant un humain. Utilisez-le délibérément pour cette raison précise, et non par défaut.
N’optez pas pour un framework juste pour éviter d’apprendre la boucle. C’est le véritable piège. En sautant cette étape, vous finissez par avoir une boîte noire basée sur des concepts que vous n’avez jamais vraiment maîtrisés.
Comprenez d’abord la boucle. Après cela, un framework devient un outil que vous choisissez consciemment — et non une béquille sur laquelle vous vous appuyez parce que vous n’avez jamais appris les fondamentaux.
Pourquoi cette série a tout construit de zéro
C’est précisément la raison pour laquelle nous avons attendu jusqu’à maintenant avant d’utiliser des frameworks.
Si cette série avait commencé par « installer LangChain, appeler create_agent », vous auriez eu un agent fonctionnel sans en comprendre réellement le fonctionnement. Vous n’auriez pas su ce qu’est un bloc tool_use, pourquoi les résultats de appels de outils en parallèle sont regroupés dans un seul message, ou pourquoi la logique d’autorisation doit se trouver dans un hook.
Désormais que ces bases vous appartiennent déjà, le vocabulaire de n’importe quel framework se traduit instantanément. Ce qu’il appelle son « agent » n’est en réalité rien d’autre que ce même cycle sous-jacent. Ce qu’il nomme « mémoire » n’est rien de plus que la liste en cours des messages que vous connaissez déjà. Ce qu’il qualifie de « outils » correspond directement aux blocs tool_use que vous gérez manuellement. Et ce qu’il promeut comme « middleware » n’est qu’un autre nom pour les points d’ancrage que vous avez créés vous-même.
C’est cette position qui vaut la peine d’être atteinte. Pas « Je connais LangChain » — mais « Je comprends comment fonctionnent les agents, et LangChain n’est qu’un moyen d’exprimer cela. »
Les frameworks continueront à évoluer. De nouveaux apparaissent tous les quelques mois. Le cycle sous-jacent reste constant. Construisez votre compréhension sur la partie qui ne change pas.
Lectures complémentaires
- Chatbot vs AI Agent : Que ce qui vraiment les sépare au-delà du LLM — Découvrez pourquoi la véritable différence entre les chatbots et les agents IA réside dans l’architecture du système qui les entoure — outils, planification et actions — et non dans le LLM lui-même.
- Comprendre les agents IA : objectifs, outils, mémoire et la boucle de l’agent — Une explication adaptée aux débutants sur les différences entre les agents IA et les chatbots, abordant les composants clés, la boucle de décision, les niveaux d’autonomie et les cas d’usage concrets.