LangChain comme composant d'un agent IA

LangChain est souvent présenté comme un framework complet pour les applications LLM — et il l'est. Mais il peut aussi s'utiliser autrement : comme une boîte à outils modulaire, dont on extrait certains composants (tools, retrievers, memory, chains) pour les intégrer dans un agent existant. Si vous construisez déjà un agent IA et que vous cherchez des briques prêtes à l'emploi, voici comment exploiter LangChain sans adopter le framework entier. Pour une vue d'ensemble des outils pour agents IA, consultez notre panorama dédié. Pour maîtriser LangChain dans sa globalité, le guide complet LangChain couvre l'architecture, LCEL et les agents de bout en bout.

Les composants LangChain utiles pour les agents

LangChain (v0.3+) est structuré en packages séparés, ce qui facilite l'usage modulaire :

langchain-core : composants fondamentaux — Runnable, PromptTemplate, ChatMessage, BaseTool. Dépendance légère, sans LLM-provider.
langchain-openai / langchain-anthropic : intégrations LLM spécifiques.
langchain-community : intégrations tierces (vector stores, APIs, tools communautaires).
langchain : agents, chains, memory — la couche d'orchestration.

Cette séparation est clé : vous pouvez installer uniquement langchain-core et langchain-openai pour avoir les tools et les prompts, sans embarquer tout le reste. Concrètement, une installation minimale ressemble à ceci :

# Installation minimale : juste les briques de base
pip install langchain-core langchain-openai

# Pas besoin du package "langchain" complet (agents, chains, memory)
# tant que vous gérez vous-même l'orchestration

L'intérêt de cette approche est double. D'abord, vous réduisez la surface de dépendances : langchain-core n'embarque ni les centaines d'intégrations de langchain-community, ni la couche d'orchestration de langchain. Ensuite, vous évitez le verrouillage architectural — votre agent reste piloté par votre propre boucle (ou par un autre framework), et LangChain n'intervient que pour fournir des objets utilitaires. Voici les composants les plus utiles dans un contexte d'agent.

Composant	Package	Rôle dans un agent
`@tool` (décorateur)	`langchain-core`	Transformer une fonction Python en tool appelable par un LLM
`ChatPromptTemplate`	`langchain-core`	Construire des prompts structurés réutilisables
`BaseRetriever`	`langchain-core`	Requêter un vector store pour du RAG
`ConversationBufferMemory`	`langchain`	Maintenir l'historique conversationnel
LCEL (`	`)	`langchain-core`

LangChain Tools dans un agent personnalisé

Le décorateur @tool est l'une des fonctionnalités les plus utiles de LangChain indépendamment du reste du framework. Il transforme n'importe quelle fonction Python en un outil que n'importe quel agent compatible OpenAI function calling peut appeler.

from langchain_core.tools import tool

@tool
def rechercher_documentation(query: str) -> str:
    """Recherche dans la documentation technique. Utiliser pour les questions sur l'API ou les configurations."""
    # votre logique de recherche ici
    return f"Résultats pour : {query}"

@tool
def calculer_cout(tokens_input: int, tokens_output: int, modele: str = "gpt-4o") -> float:
    """Calcule le coût estimé d'un appel LLM en dollars. Préciser le modèle si différent de gpt-4o."""
    tarifs = {"gpt-4o": (0.005, 0.015), "gpt-4o-mini": (0.00015, 0.0006)}
    if modele not in tarifs:
        return -1.0
    prix_in, prix_out = tarifs[modele]
    return (tokens_input / 1000 * prix_in) + (tokens_output / 1000 * prix_out)

La docstring est ce que le LLM lit pour décider d'utiliser l'outil ou non. Soyez explicite : décrivez quand utiliser le tool, pas juste ce qu'il fait.

Ces tools LangChain s'intègrent directement dans un AgentExecutor LangChain, mais aussi dans tout système compatible avec le schéma OpenAI :

# Récupérer le schéma JSON compatible OpenAI function calling
schema = rechercher_documentation.args_schema.schema()
openai_tool = rechercher_documentation.as_openai_tool()

Cela permet d'utiliser des tools LangChain dans un agent construit from scratch avec openai SDK, sans aucune dépendance à langchain au runtime.

Lorsque le LLM décide d'appeler un de ces tools, vous récupérez l'argument depuis la réponse et vous exécutez le tool manuellement. La boucle minimale ressemble à ceci :

import json

# Le modèle a renvoyé un tool_call dans response.choices[0].message.tool_calls
for call in response.choices[0].message.tool_calls:
    args = json.loads(call.function.arguments)
    # invoke() exécute la fonction Python sous-jacente du tool LangChain
    if call.function.name == "calculer_cout":
        resultat = calculer_cout.invoke(args)
        print(resultat)

La méthode .invoke() est le point d'entrée standard de tout Runnable LangChain : elle valide les arguments contre le schéma déduit des annotations de type, puis appelle la fonction. Vous obtenez ainsi la validation « gratuite » du tool sans avoir à orchestrer quoi que ce soit côté LangChain.

Notez aussi que @tool infère automatiquement le schéma JSON à partir des annotations de type et de la docstring. Pour un contrôle plus fin (descriptions par paramètre, contraintes), passez un modèle Pydantic via args_schema :

from pydantic import BaseModel, Field
from langchain_core.tools import tool

class CoutArgs(BaseModel):
    tokens_input: int = Field(description="Nombre de tokens en entrée")
    tokens_output: int = Field(description="Nombre de tokens en sortie")
    modele: str = Field(default="gpt-4o", description="Identifiant du modèle")

@tool(args_schema=CoutArgs)
def calculer_cout_v2(tokens_input: int, tokens_output: int, modele: str = "gpt-4o") -> float:
    """Calcule le coût estimé d'un appel LLM en dollars."""
    ...

Les descriptions de champ Pydantic se propagent dans le schéma JSON exposé au LLM, ce qui améliore sensiblement la qualité des appels d'outils.

LangChain Retrievers pour le RAG

Un retriever LangChain encapsule la logique de recherche dans un vector store et expose une interface unifiée : retriever.invoke("ma question") retourne une liste de Document. Le même code fonctionne avec Chroma, Pinecone, Qdrant ou pgvector — seul le retriever change.

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
from langchain_core.documents import Document

# Indexer des documents
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
documents = [
    Document(page_content="LangGraph gère les workflows avec état et cycles.", metadata={"source": "docs"}),
    Document(page_content="CrewAI orchestre des agents collaboratifs avec des rôles définis.", metadata={"source": "docs"}),
]
vectorstore = Chroma.from_documents(documents, embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# Requête depuis l'agent
resultats = retriever.invoke("quel framework pour des agents avec état ?")
for doc in resultats:
    print(doc.page_content)

Pour un pipeline RAG complet dans un agent, le retriever s'intègre comme un tool :

from langchain_core.tools import tool

@tool
def recherche_base_connaissance(question: str) -> str:
    """Recherche dans la base de connaissance interne. Utiliser avant de répondre à des questions techniques spécifiques."""
    docs = retriever.invoke(question)
    if not docs:
        return "Aucun document pertinent trouvé."
    return "\n\n".join(doc.page_content for doc in docs)

L'agent appelle ce tool comme n'importe quel autre, sans connaître le détail du vector store derrière.

LangChain Memory

La mémoire LangChain maintient l'historique conversationnel entre les tours d'un agent. Elle s'intègre dans les AgentExecutor mais peut aussi alimenter manuellement le contexte d'un prompt.

from langchain.memory import ConversationBufferWindowMemory

# Garde les 5 derniers échanges (évite l'explosion du contexte)
memory = ConversationBufferWindowMemory(
    k=5,
    memory_key="chat_history",
    return_messages=True
)

# Ajouter manuellement un échange
memory.chat_memory.add_user_message("Qu'est-ce que LangGraph ?")
memory.chat_memory.add_ai_message("LangGraph est une extension de LangChain pour les workflows avec état.")

# Récupérer l'historique formaté pour le prompt
historique = memory.load_memory_variables({})["chat_history"]

Types de mémoire disponibles :

Type	Quand l'utiliser
`ConversationBufferMemory`	Sessions courtes (< 10 tours)
`ConversationBufferWindowMemory`	Sessions longues, garder N derniers échanges
`ConversationSummaryMemory`	Sessions très longues, résumé automatique
`ConversationSummaryBufferMemory`	Hybride : buffer récent + résumé de l'ancien historique

Pour la persistance entre sessions (redémarrages), connectez à Redis :

from langchain_community.chat_message_histories import RedisChatMessageHistory
from langchain.memory import ConversationBufferMemory

history = RedisChatMessageHistory(session_id="user-42", url="redis://localhost:6379")
memory = ConversationBufferMemory(
    chat_memory=history,
    memory_key="chat_history",
    return_messages=True
)

Avec cette configuration, l'historique survit aux redémarrages de l'agent.

LangChain Chains et LCEL

LCEL (LangChain Expression Language) est la syntaxe moderne pour composer des pipelines de traitement. L'opérateur | enchaîne des Runnable : la sortie de l'un devient l'entrée du suivant.

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Pipeline de synthèse : prompt → LLM → parser
prompt_synthese = ChatPromptTemplate.from_messages([
    ("system", "Résume le texte suivant en 3 bullet points en français. Sois factuel."),
    ("human", "{texte}")
])

chain_synthese = prompt_synthese | llm | StrOutputParser()

# Utilisation dans un agent comme sous-routine
resume = chain_synthese.invoke({"texte": "LangChain est un framework..."})

LCEL supporte nativement le streaming, le batch et l'async sans changer l'interface :

# Streaming — utile pour afficher la réponse en temps réel
for chunk in chain_synthese.stream({"texte": "..."}):
    print(chunk, end="", flush=True)

# Batch — traiter plusieurs inputs en parallèle
resultats = chain_synthese.batch([
    {"texte": "Article 1..."},
    {"texte": "Article 2..."},
])

# Async — dans un contexte FastAPI ou asyncio
resume = await chain_synthese.ainvoke({"texte": "..."})

Pour des pipelines conditionnels, RunnableBranch permet d'aiguiller selon la valeur d'une variable :

from langchain_core.runnables import RunnableBranch, RunnableLambda

router = RunnableBranch(
    (lambda x: x["langue"] == "fr", chain_fr),
    (lambda x: x["langue"] == "en", chain_en),
    chain_fr  # fallback
)

Intégration avec d'autres frameworks

Les composants LangChain sont conçus pour être interopérables. Deux intégrations particulièrement courantes :

LangChain + LangGraph

LangGraph utilise LangChain sous le capot et consomme nativement les tools, retrievers et chains LangChain. Un tool @tool LangChain peut être passé directement au graph :

from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o")

# Tools LangChain réutilisés dans LangGraph
agent = create_react_agent(
    model=llm,
    tools=[rechercher_documentation, calculer_cout, recherche_base_connaissance]
)

result = agent.invoke({"messages": [("human", "Quel est le coût pour 10k tokens sur gpt-4o ?")]})

Vous pouvez ainsi construire la couche outil avec LangChain et déléguer l'orchestration à LangGraph dès que votre agent a besoin de cycles ou d'état persistant.

LangChain + SDK natif OpenAI

Pour un usage encore plus léger, les tools LangChain s'exportent au format OpenAI function calling :

import openai

client = openai.OpenAI()

# Convertir les tools LangChain au format OpenAI
tools_openai = [t.as_openai_tool() for t in [rechercher_documentation, calculer_cout]]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Combien coûte 5000 tokens sur gpt-4o ?"}],
    tools=tools_openai,
    tool_choice="auto"
)

Cette approche élimine toute dépendance à langchain au runtime tout en conservant la DX du décorateur @tool pour définir les outils.

Quand utiliser LangChain comme composant plutôt que comme framework

Adopter LangChain comme simple brique modulaire est pertinent dans des situations précises. À l'inverse, dès que votre besoin d'orchestration grandit, l'écosystème complet (ou LangGraph) devient plus rentable.

Situation	Approche recommandée
Vous avez déjà une boucle d'agent maison et voulez juste normaliser vos tools	`langchain-core` + `@tool` + `as_openai_tool()`
Vous faites du RAG mais gérez l'orchestration ailleurs	`langchain-core` retrievers + un vector store
Vous avez besoin de cycles, d'état persistant, de checkpoints	LangGraph
Vous voulez du multi-agents, du human-in-the-loop, du tracing	Framework complet + LangSmith
Vous composez quelques étapes LLM déterministes	LCEL seul (`prompt \| llm \| parser`)

La règle pratique : tant que votre agent reste une boucle « appel LLM → appel tool → réinjection du résultat » sans branchements complexes, LangChain comme composant suffit largement. Le jour où vous avez besoin de reprendre l'exécution après une interruption, de gérer des chemins conditionnels durables ou de paralléliser plusieurs sous-agents, migrez l'orchestration vers LangGraph — vos tools @tool et vos retrievers, eux, restent inchangés. C'est précisément l'avantage de l'approche modulaire : la couche outil est réutilisable quel que soit l'orchestrateur.

Conclusion

LangChain ne se résume pas à un framework tout-ou-rien. Ses composants — tools, retrievers, memory, chains LCEL — sont des briques autonomes que vous pouvez intégrer dans n'importe quel agent, qu'il soit construit avec LangGraph, un SDK OpenAI natif, ou un framework custom. Le décorateur @tool seul justifie l'installation de langchain-core : il normalise la définition des outils et génère automatiquement le schéma JSON requis par les LLM. Si vous avez besoin de modularité sans adoption complète du framework, commencez par là.

Vous voulez aller plus loin avec LangChain ? Consultez notre guide complet sur LangChain pour maîtriser tous les aspects du framework.