Function Calling et Tool Use : Intégrer les API aux LLM

Figure 1 - Diagramme de séquence du flux complet de function calling Pour approfondir, consultez Agents IA Edge 2026 : Privacy, Latence et Architecture PLAM.

JSON Schema pour définir les tools

Chaque tool est défini par un JSON Schema qui décrit son interface. Ce schéma sert de contrat entre votre application et le LLM. Il doit être aussi précis que possible : une bonne description et des types stricts réduisent considérablement les erreurs d'appel.

Perspectives et evolution

// Définition d'un tool - JSON Schema
{
  "name": "get_weather",
  "description": "Récupère la météo actuelle pour une ville donnée. Retourne la température en Celsius et les conditions.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "Nom de la ville (ex: 'Paris', 'Lyon')"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Unité de température souhaitée"
      }
    },
    "required": ["city"]
  }
}

Parallel Function Calling et Forced Tool Use

Les LLM modernes supportent le parallel function calling : au lieu de faire un seul appel à la fois, le modèle peut générer plusieurs tool calls simultanément dans une seule réponse. Par exemple, si un utilisateur demande "compare la météo à Paris et Londres", le modèle génèrera deux appels get_weather en parallèle au lieu de deux tours séquentiels. Cela divise la latence par deux ou plus.

Le forced tool use (ou tool_choice) permet de contraindre le modèle à utiliser un tool spécifique, ce qui est indispensable dans les pipelines déterministes où chaque étape doit obligatoirement appeler une fonction donnée.

Votre organisation est-elle prête à faire face aux attaques basées sur l'IA ?

3Implémentation Multi-Provider

Les trois principaux fournisseurs de LLM (Anthropic, OpenAI, Mistral) implémentent le function calling avec des syntaxes légèrement différentes mais un concept identique. Voici les implémentations comparées pour le même cas d'usage : une fonction de recherche dans une base de connaissances.

Claude (Anthropic API)

import anthropic

client = anthropic.Anthropic()

# Définition des tools (Anthropic syntax)
tools = [{
    "name": "search_knowledge_base",
    "description": "Recherche dans la base de connaissances interne. "
        "Utiliser pour répondre aux questions sur les produits.",
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "La requête de recherche"},
            "top_k": {"type": "integer", "description": "Nombre de résultats", "default": 5}
        },
        "required": ["query"]
    }
}]

# Appel avec tools
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    tools=tools,
    messages=[{"role": "user", "content": "Quelles sont les fonctionnalités du produit X ?"}]
)

# Traitement du tool_use
if response.stop_reason == "tool_use":
    tool_block = next(b for b in response.content if b.type == "tool_use")
    result = search_knowledge_base(**tool_block.input)  # Exécution locale
    
    # Renvoi du résultat au LLM
    final = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        tools=tools,
        messages=[
            {"role": "user", "content": "Quelles sont les fonctionnalités du produit X ?"},
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": [{
                "type": "tool_result",
                "tool_use_id": tool_block.id,
                "content": json.dumps(result)
            }]}
        ]
    )

GPT (OpenAI API)

from openai import OpenAI
import json

client = OpenAI()

# Définition des tools (OpenAI syntax)
tools = [{
    "type": "function",
    "function": {
        "name": "search_knowledge_base",
        "description": "Recherche dans la base de connaissances",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "top_k": {"type": "integer", "default": 5}
            },
            "required": ["query"]
        }
    }
}]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Fonctionnalités du produit X ?"}],
    tools=tools
)

# OpenAI utilise tool_calls dans le message assistant
if response.choices[0].finish_reason == "tool_calls":
    tool_call = response.choices[0].message.tool_calls[0]
    args = json.loads(tool_call.function.arguments)
    result = search_knowledge_base(**args)
    
    # Message tool avec tool_call_id
    final = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "user", "content": "Fonctionnalités du produit X ?"},
            response.choices[0].message,
            {"role": "tool", "tool_call_id": tool_call.id,
             "content": json.dumps(result)}
        ],
        tools=tools
    )

Différences clés entre providers

Bien que le concept soit identique, les différences de syntaxe sont significatives pour les développeurs travaillant en multi-provider :

Mise en oeuvre et bonnes pratiques

• ▹Anthropic utilise input_schema et des content blocks typés (tool_use, tool_result). Le tool_result est envoyé dans un message de rôle user.
• ▹OpenAI utilise parameters et un rôle dédié tool pour les résultats. Les arguments sont une string JSON à parser.
• ▹Mistral suit une syntaxe très proche d'OpenAI avec le wrapper type: function et le rôle tool.

4Patterns Avancés

Au-delà de l'utilisation basique, le function calling ouvre la porte à des patterns architecturaux poussés qui constituent le coeur des systèmes IA modernes en production.

Parallel Tool Use

Le parallel tool use permet au LLM de générer plusieurs appels de fonctions simultanément dans une seule réponse. Votre application peut alors exécuter ces appels en parallèle (via asyncio.gather en Python) et renvoyer tous les résultats en une seule fois. Ce pattern est essentiel pour les requêtes qui impliquent plusieurs sources de données indépendantes.

# Traitement parallèle des tool calls (Anthropic)
import asyncio

async def handle_parallel_tools(response):
    tool_blocks = [b for b in response.content if b.type == "tool_use"]
    
    # Exécution parallèle de tous les tools
    tasks = [execute_tool(block.name, block.input) for block in tool_blocks]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    
    # Construction des tool_results
    tool_results = []
    for block, result in zip(tool_blocks, results):
        if isinstance(result, Exception):
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "is_error": True,
                "content": f"Erreur: {str(result)}"
            })
        else:
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": json.dumps(result)
            })
    return tool_results

Chained Function Calls (appels chaînés)

Dans un appel chaîné, le modèle utilise le résultat d'un premier tool call comme paramètre pour un second. Par exemple : d'abord appeler search_user(email) pour obtenir un user_id, puis appeler get_orders(user_id). Ce pattern implique plusieurs tours d'échange LLM/application et constitue la base des workflows agentiques. Pour approfondir, consultez Comment Choisir sa Base.

Tool Choice Strategies

Le paramètre tool_choice contrôle le comportement du modèle vis-à-vis des tools :

• ▹auto (défaut) : le modèle décide librement s'il utilise un tool ou non. Idéal pour les assistants conversationnels où certaines questions ne nécessitent pas de tools.
• ▹any (Anthropic) / required (OpenAI) : le modèle est forcé d'utiliser au moins un tool. Utile dans les pipelines où chaque étape doit produire un appel structuré.
• ▹tool spécifique : force l'utilisation d'un tool précis, par son nom. Indispensable pour les étapes déterministes d'un workflow (ex: toujours appeler validate_output en fin de pipeline).

Error Handling et Retry Patterns

La gestion d'erreurs est critique dans les systèmes avec function calling. Deux stratégies complémentaires s'imposent. Premièrement, le retry avec feedback : lorsqu'un tool call échoue, vous renvoyez l'erreur au LLM via le champ is_error: true, et le modèle peut corriger ses arguments et réessayer. Deuxièmement, le circuit breaker : après N échecs consécutifs sur le même tool, vous désactivez temporairement le tool et demandez au modèle de répondre avec les informations disponibles.

Streaming avec Tools

Le streaming de réponses avec function calling présente un défi particulier. Avec Anthropic, les content blocks de type tool_use arrivent progressivement : d'abord le nom de l'outil, puis le JSON des arguments par fragments. Votre code doit buffer les fragments JSON jusqu'à recevoir l'événement content_block_stop, puis parser et exécuter. Ce pattern est essentiel pour les applications temps réel qui affichent les réponses textuelles en streaming tout en gérant les tool calls de manière transparente.

5Définir des Tools Efficaces

La qualité de vos tools détermine directement la qualité des interactions de votre LLM avec le monde extérieur. Un tool bien défini sera appelé correctement dans 95%+ des cas ; un tool mal décrit génèrera des erreurs constantes et une expérience utilisateur dégradée.

Best practices JSON Schema

Voici les règles éprouvées pour définir des tools que les LLM utilisent correctement :

• ▹Descriptions précises et actionnables : ne pas écrire "Gère les utilisateurs" mais "Recherche un utilisateur par son email ou son ID. Retourne le profil complet ou null si non trouvé." Le LLM s'appuie sur la description pour décider quand et comment utiliser le tool.
• ▹Utiliser les enums quand possible : au lieu de "type": "string" pour un statut, préférer "enum": ["active", "inactive", "pending"]. Les enums contraignent le modèle et éliminent les erreurs de format.
• ▹Séparer required et optional : ne rendez requis que les paramètres strictement nécessaires. Les paramètres optionnels avec des valeurs par défaut sensibles permettent au modèle de simplifier ses appels.
• ▹Éviter les nested objects profonds : les LLM ont plus de difficulté à générer correctement des structures JSON profondément imbriquées. Préférez aplatir les schémas quand c'est possible (max 2-3 niveaux).
• ▹Nommer clairement les tools : utilisez la convention verbe_nom (get_weather, create_ticket, search_documents). Évitez les noms ambigus comme "process" ou "handle".