Ce que LangChain vous offre réellement au-delà de simples appels d’outils

Les applications d’IA peuvent appeler directement une API LLM et contrôler chaque détail. Cette approche présente un réel avantage : le flux de contrôle est visible. Elle comporte cependant aussi un inconvénient. Dès que le produit dépasse une seule interaction de chat, beaucoup de code apparaît qui n’a pas vraiment de lien avec la logique du produit.

Les tâches typiques incluent :

• La définition d’outils et de schémas
• L’envoi des outils au modèle
• Gérer les réponses issues des appels aux outils
• Exécuter les fonctions demandées
• Renvoyer les résultats des outils
• Gérer l’historique des conversations
• Coordonner plusieurs appels aux outils
• Gérer le cycle modèle↔outil

Ces étapes sont excellentes pour apprendre. Dans une application de livraison, les répéter manuellement devient alors la tâche principale.

Des frameworks comme LangChain existent justement pour absorber cette répétition.

Le coût de tout faire manuellement

Imaginez un petit outil de calculatrice. Sans cadre, le chemin est à peu près le suivant :

User
  ↓
LLM API
  ↓
LLM requests calculator
  ↓
Our code detects the request
  ↓
Our code executes calculator()
  ↓
Our code sends the result back
  ↓
LLM generates the final answer

Avec un seul outil, tout reste gérable. Vingt outils, plusieurs modèles, un état de conversation persistant, des tentatives répétées et des workflows d’agents ramènent une « logique de produit simple » en un projet d’orchestration.

Les abstractions existent parce que cette infrastructure se développe plus rapidement que la liste des fonctionnalités.

Ce que LangChain apporte

LangChain fournit des structures communes pour les modèles, les outils, les messages et les environnements d’exécution des agents. Au lieu de configurer chaque étape manuellement, il suffit de décrire les capacités et de laisser le cadre gérer une grande partie du code générique.

Création d’un outil

Une fonction Python ordinaire devient un outil :

from langchain.tools import tool

def calculator(a: float, b: float, operation: str):
    """Perform a mathematical calculation."""
    if operation == "add":
        return a + b
    elif operation == "subtract":
        return a - b
    elif operation == "multiply":
        return a * b
    elif operation == "divide":
        if b == 0:
            return "Cannot divide by zero."
        return a / b
    return "Unknown operation."

Le corps de la calculatrice reste constitué de logique d’application. LangChain se contente de l’envelopper afin qu’un LLM puisse y accéder.

Connexion de l’outil à un modèle

from langchain_google_genai import ChatGoogleGenerativeAI

model = ChatGoogleGenerativeAI(
    model="gemini-3.5-flash-lite"
)
model_with_tools = model.bind_tools([calculator])

Puis, appelez-le :

response = model_with_tools.invoke(
    "What is 2 + 6?"
)

Le modèle peut répondre par une demande structurée d’outil telle que :

calculator(
    a=2,
    b=6,
    operation="add"
)

bind_tools() ne ne lance pas le calculateur. Il indique simplement la disponibilité : le modèle peut demander l’outil lorsque c’est nécessaire.

Où apparaît cette abstraction

Manuellement, l’ingénieur gère une longue chaîne de traitement :

Create function
     ↓
Create tool schema
     ↓
Send schema to LLM
     ↓
Receive tool call
     ↓
Extract arguments
     ↓
Execute function
     ↓
Create tool result
     ↓
Send result back to LLM
     ↓
Check if another tool call is needed
     ↓
Repeat

Avec LangChain, une grande partie de cette chaîne se trouve dans l’environnement d’exécution de l’agent. L’attention se porte alors sur :

What capability does my application need?
              ↓
        Define the tool
              ↓
      Give it to the model
              ↓
       Build the application

La complexité n’a pas disparu — elle a simplement été déplacée derrière une frontière.

Quels sont les véritables avantages

LangChain ne crée pas de mécanismes pour appeler des outils ; les API brutes le permettent déjà. L’avantage réside dans le fait de ne pas avoir à redévelopper les schémas, les boucles et la gestion de l’historique pour chaque fonctionnalité. Le temps est ainsi consacré aux questions liées au produit :

• Quelles actions l’assistant doit-il être capable d’exécuter ?
• Quels outils doivent faire partie du périmètre de fonctionnement ?
• Que se passe-t-il en cas d’échec d’un outil ?

Comment le reste de l’application doit-il réagir ?

Quelles règles métier doivent rester codées en dur ?

Faut-il que chaque projet utilise un framework ?

Pas toujours. Appeler des outils développés manuellement reste le meilleur moyen d’apprendre. Faire ce parcours une fois :

LLM
 ↓
Tool call
 ↓
Application
 ↓
Tool execution
 ↓
Tool result
 ↓
LLM

rend le comportement des frameworks ultérieurs moins mystérieux. Utiliser une abstraction sans connaître le problème qu’elle résout rend le débogage difficile.

Habitude durable : apprenez d’abord le fonctionnement interne, puis adoptez des abstractions afin que ce dernier ne doive pas être réécrit à chaque fois. Les équipes qui sautent cette première étape traitent souvent LangChain comme de la magie et stagnent lorsque le schéma d’un outil ou une politique de tentative échouée ne fonctionne pas correctement. Les équipes qui maîtrisent les deux compétences avancent plus rapidement sans perdre la capacité de revenir au niveau basique en cas d’incident en production.