Tool calling vs function calling vs agents : les vraies différences.

La terminologie autour de l'exécution adjacente aux LLM est véritablement confuse. Non pas parce que les ingénieurs manquent de rigueur, mais parce que trois communautés distinctes (chercheurs en ML, concepteurs d'API et équipes produit) ont colonisé les mêmes mots en même temps avec des sens différents. Ce glossaire trace une ligne nette entre chaque terme, vous donne du code qui rend la distinction concrète, et se termine par un guide de décision que vous pouvez réellement utiliser.

Pourquoi la terminologie est cassée

Trois vocabulaires sont arrivés en même temps et ont pointé vers des choses qui se chevauchent. OpenAI a nommé son mode de sortie structurée « function calling » en juin 2023, ce qui impliquait immédiatement une exécution qui ne se produit pas. Anthropic a nommé la même primitive « tool use », confondant l'intention et l'exécution dans l'autre sens. La communauté produit s'est emparée du mot « agent », un terme au sens chargé de plusieurs décennies en recherche IA, pour le pointer sur n'importe quoi, d'un chatbot avec mémoire à une simple boucle d'appel d'outil.

Le coût pratique : dans une réunion, personne ne sait ce que l'autre entend par ces mots. Les ingénieurs adoptent l'interprétation la plus généreuse ; les chefs de produit adoptent la plus ambitieuse. Au moment où un build est cadré, « nous utilisons le function calling pour prendre des actions » peut désigner trois architectures différentes avec des coûts, des latences et des modes d'échec distincts.

La solution est de s'engager sur des définitions qui distinguent les trois par propriété structurelle, pas par marque fournisseur. C'est exactement ce que fait la suite de cet article.

Function calling

Le function calling est la plus ancienne et la plus étroite des trois primitives. Son seul rôle est de rendre fiable l'extraction de données structurées depuis le langage. Avant son existence, on demandait au modèle de « répondre en JSON » et on parsait ce qui sortait en espérant que ça tienne. Le function calling vous donne une sortie validée par schéma, sans ambiguïté de parsing.

Le terme a été créé par OpenAI lors de la publication de leur API en juin 2023 et a immédiatement semé la confusion parce qu'il implique une exécution. Rien ne s'exécute. Le modèle produit un dict qui ressemble à un appel de fonction. Vous décidez d'appeler la fonction, de la journaliser, ou de la jeter.

L'équivalent chez Anthropic est les blocs de contenu tool_use avec un retour tool_result : le même pattern, une terminologie différente. Les deux se réduisent à une seule affirmation. Le modèle déclare l'intention, l'appelant agit.

import anthropic

client = anthropic.Anthropic()

# Declare the function signature. The model will emit this shape.
extract_order = {
    "name": "extract_order",
    "description": "Extract order details from a customer message",
    "input_schema": {
        "type": "object",
        "properties": {
            "product_id": {"type": "string"},
            "quantity":   {"type": "integer"},
            "shipping":   {"type": "string", "enum": ["standard", "express"]},
        },
        "required": ["product_id", "quantity"]
    }
}

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    tools=[extract_order],
    tool_choice={"type": "tool", "name": "extract_order"},
    messages=[{
        "role": "user",
        "content": "I need 3x SKU-7821, express please"
    }]
)

# Model emits structured intent. WE decide what to do with it.
tool_block = response.content[0]
order_data = tool_block.input
# }'product_id': 'SKU-7821', 'quantity': 3, 'shipping': 'express'}

# Nothing was executed. This is just a very reliable JSON extractor.
create_order(order_data)        # caller decides to run this

Tool calling

Le tool calling est du function calling avec une adresse de retour. Après que le modèle a émis un bloc tool use, vous exécutez la fonction et renvoyez un tool_result dans la conversation. Le modèle décide alors quoi faire ensuite : appeler un autre outil, demander une clarification, ou produire une réponse finale.

C'est le pattern qu'il vous faut pour les tâches mono-agent avec des effets de bord dans le monde réel. Interroger un enregistrement de base de données, appeler une API, lire un fichier, vérifier la météo. La boucle est implicite. Le modèle continue d'appeler des outils jusqu'à avoir de quoi répondre.

Le point de confusion : les gens disent « function calling » quand ils veulent dire « tool calling ». Techniquement, le function calling produit l'intention ; le tool calling est le cycle complet requête-exécution-retour. En pratique, quand quelqu'un dit « j'utilise le function calling », il veut dire tool calling. Demandez si le résultat revient au modèle.

import anthropic

client = anthropic.Anthropic()
messages = [{"role": "user", "content": "What's the current price of NVDA?"}]

# THE TOOL CALLING LOOP
while True:
    response = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        tools=[get_stock_price_tool],
        messages=messages
    )

    if response.stop_reason == "end_turn":
        break                    # model is done; extract final answer

    # Model wants to call a tool
    tool_uses = [b for b in response.content if b.type == "tool_use"]

    # Execute each tool call. WE run it, then return the result.
    tool_results = []
    for tu in tool_uses:
        result = execute_tool(tu.name, tu.input)  # actual execution
        tool_results.append({
            "type":        "tool_result",
            "tool_use_id": tu.id,
            "content":     result           # result goes BACK to model
        })

    # Feed result back. The model now knows what happened.
    messages += [
        {"role": "assistant", "content": response.content},
        {"role": "user",      "content": tool_results}
    ]

# Key difference from function calling: the model SAW the result.
final = extract_text(response.content)

Agents

« Agent » est le mot le plus surchargé de l'écosystème. Un chatbot avec mémoire se fait appeler agent. Une simple boucle d'appel d'outil se fait appeler agent. La définition utile est plus étroite : un système où le LLM pilote la séquence d'exécution, pas seulement une étape isolée.

La différence structurelle avec le tool calling : un agent maintient un état entre les tours, peut réviser son plan quand un outil échoue, et peut instancier des sous-tâches ou d'autres agents. C'est la différence entre demander à quelqu'un de chercher un fait et lui demander de faire une recherche et rédiger un rapport. Le second implique des décisions sur la façon de procéder qui n'étaient pas spécifiées à l'avance.

Les agents sont le bon choix quand le chemin vers l'objectif est inconnu ou variable. Si vous pouvez écrire le workflow comme un organigramme fixe, vous voulez probablement du tool calling orchestré, pas un agent. Les agents échangent la prévisibilité contre l'adaptabilité. Comprenez ce compromis avant d'adopter ce pattern.

from langgraph.graph import StateGraph, END
from typing import TypedDict, List

# STATE: persists across the entire agent run
class ResearchState(TypedDict):
    goal:       str
    plan:       List[str]    # agent generates this dynamically
    findings:   List[str]    # accumulates across turns
    iterations: int          # self-corrects if stuck
    done:       bool

# NODES: each is a model call that reads + writes state
def planner(state: ResearchState) -> ResearchState:
    # Model decides what to do next. Not pre-specified by the caller.
    plan = llm_plan(state["goal"], state["findings"])
    return {**state, "plan": plan}

def executor(state: ResearchState) -> ResearchState:
    # Runs tool calls determined by the planner, not hardcoded.
    results = [run_tool(step) for step in state["plan"]]
    return {**state,
            "findings": state["findings"] + results,
            "iterations": state["iterations"] + 1}

def evaluator(state: ResearchState) -> ResearchState:
    # Model self-assesses: is the goal met? Should I retry?
    done = llm_evaluate(state["goal"], state["findings"])
    return {**state, "done": done}

# GRAPH: model drives the control flow
graph = StateGraph(ResearchState)
graph.add_node("plan",     planner)
graph.add_node("execute",  executor)
graph.add_node("evaluate", evaluator)

# Conditional edge: agent decides whether to loop or finish
graph.add_conditional_edges("evaluate",
    lambda s: END if s["done"] or
              s["iterations"] >= 5 else "plan")

agent = graph.compile(checkpointer=MemorySaver())   # persistent state
result = agent.invoke({"goal": "research Q3 competitor pricing",
                         "findings": [], "iterations": 0})

Comparaison côte à côte

La page unique à afficher au-dessus du tableau blanc lors de la revue d'architecture. Douze dimensions, trois colonnes, la réponse à la plupart des questions « attendez, lequel on fait exactement ? ».

Guide de décision

Commencez par la primitive la plus simple qui satisfait l'exigence. Ne montez dans la pile de complexité que quand l'option plus simple ne peut structurellement pas faire le travail, pas simplement parce qu'elle exigerait un prompting plus soigneux.

Aide-mémoire pour la réunion client

Quand quelqu'un dit l'une de ces choses, voici ce qu'il veut probablement dire et ce qu'il faut clarifier ou corriger. À utiliser dans les réunions où la terminologie est déjà devenue structurante.

Épinglez cette section dans le document que vous partagez avec les parties prenantes avant la réunion de cadrage. Les 30 secondes d'alignement sur le vocabulaire évitent les 30 minutes de « attendez, par agent vous voulez dire quoi exactement ? » qui se produisent deux fois par appel sinon.

Si vous souhaitez un deuxième avis sur ce que vous construisez (du tool calling ou vraiment un agent), le formulaire de contact est la voie la plus rapide. Nous faisons des revues d'architecture de 30 minutes sur les systèmes agentiques en cours, gratuitement.