Changer le thème

Appel d'outils Agent en pratique : connecter l'IA aux API et services externes

Easton editorial illustration: tool-socket control board

Vous avez déjà vécu ça : vous voulez que l’IA consulte la météo, lise un fichier ou appelle une API, et elle vous répond « je ne peux pas accéder aux données externes ».

Frustrant, n’est-ce pas ?

Ce n’est pas que l’IA manque d’intelligence : il lui manque une capacité clé — l’appel d’outils. Aujourd’hui, voyons cette technologie qui transforme l’IA de « simple interlocuteur » en agent qui agit vraiment.


Qu’est-ce que l’appel d’outils IA ?

En bref, l’appel d’outils, c’est donner des mains à l’IA.

Un grand modèle classique ne répond qu’à partir de ses données d’entraînement. Vous demandez « quel temps fait-il à Pékin aujourd’hui ? », il répond « je ne peux pas obtenir de données en temps réel ». Avec l’appel d’outils, l’IA peut demander l’exécution d’une fonction — par exemple appeler une API météo — et vous renvoyer le résultat.

L’importance de cette capacité ? C’est le passage du « stratège qui ne fait que parler » au « général qui mène ses troupes sur le terrain ».

Trois approches dominantes

Sur le marché, trois schémas d’appel d’outils dominent :

ApprocheProduit représentatifCas d’usage
Function CallingOpenAI GPTSortie structurée, appels API simples
Tool UseClaudeChaînes d’outils complexes, tâches multi-étapes
MCPClaude CodeÉcosystème d’outils standardisé

Lequel choisir ? Selon vos besoins. Pour un scénario simple, OpenAI Function Calling suffit ; pour un système Agent complexe, Claude Tool Use convient mieux ; pour un écosystème d’outils, MCP est la tendance.


OpenAI Function Calling : de la découverte à la pratique

Commençons par OpenAI. Son Function Calling est concis : trois étapes essentielles :

  1. Définir les outils (indiquer à l’IA ce qui est disponible)
  2. L’IA choisit quel outil appeler (nom de fonction et paramètres)
  3. Vous exécutez l’outil et renvoyez le résultat

Un exemple complet

Imaginons un outil de consultation météo. Définissons d’abord le Schema de l’outil :

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Obtenir la météo actuelle d'une ville donnée",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {
                    "type": "string",
                    "description": "Nom de la ville, ex. « Pékin », « Shanghai »"
                },
                "unit": {
                    "type": "string",
                    "enum": ["celsius", "fahrenheit"],
                    "description": "Unité de température, Celsius par défaut"
                }
            },
            "required": ["city"]
        }
    }
}]

Notez le champ description — ne le négligez pas. L’IA s’en sert pour décider quand appeler l’outil. J’ai vu des gens écrire « get weather », et l’IA ne savait pas dans quel contexte l’utiliser. En passant à « Obtenir la météo actuelle d’une ville donnée », le taux de bon appel est passé de 60 % à 95 %.

Ensuite, envoyez la requête :

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "Il fait chaud à Pékin aujourd'hui ?"}
    ],
    tools=tools
)

L’IA renvoie une demande d’appel d’outil :

tool_call = response.choices[0].message.tool_calls[0]
# tool_call.function.name = "get_weather"
# tool_call.function.arguments = '{"city": "北京"}'

Puis vous exécutez l’appel réel et renvoyez le résultat :

# Exécuter votre appel API météo
weather_result = get_weather_from_api("北京")

# Renvoyer le résultat
final_response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "Il fait chaud à Pékin aujourd'hui ?"},
        response.choices[0].message,  # Demande d'appel d'outil de l'IA
        {
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": json.dumps(weather_result)
        }
    ]
)

L’IA formulera alors une réponse naturelle : « Il fait 28 °C à Pékin aujourd’hui, assez chaud — pensez à la protection solaire si vous sortez. »

Strict Mode : garantir la stabilité des sorties

En 2024, OpenAI a lancé Strict Mode, qui résout les problèmes d’instabilité de conformité au JSON Schema. L’activation est simple :

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "strict": True,  # Ajoutez cette ligne
        # ... autres champs
    }
}]

Une fois activé, les paramètres renvoyés respectent à 100 % le Schema défini. En production, activez-le : sinon vous risquez toutes sortes d’erreurs de parsing.


Claude Tool Use : une chaîne d’outils plus puissante

Claude Tool Use diffère d’OpenAI sur plusieurs points de conception importants.

Appels parallèles

Claude peut renvoyer plusieurs appels d’outils en une fois. Par exemple, si l’utilisateur demande « compare la météo de Pékin et Shanghai », Claude demandera deux appels get_weather d’un coup :

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "Compare la météo de Pékin et Shanghai"}],
    tools=tools
)

# response.content peut contenir deux blocs tool_use
for block in response.content:
    if block.type == "tool_use":
        print(f"Appel {block.name}, paramètres : {block.input}")

Très utile pour les tâches complexes. OpenAI prend aussi en charge le parallélisme, mais Claude le gère plus élégamment — il juge intelligemment quels appels peuvent être parallèles et lesquels doivent rester séquentiels.

Stratégie Tool Choice

Claude offre un contrôle plus fin sur le choix d’outils :

# Choix automatique (par défaut)
tool_choice = {"type": "auto"}

# Forcer l'utilisation d'un outil (pas de réponse sans outil)
tool_choice = {"type": "any"}

# Spécifier un outil précis
tool_choice = {"type": "tool", "name": "get_weather"}

Quand utiliser any ? Quand la question de l’utilisateur ne peut être répondue qu’avec un outil. Par exemple, consulter le statut d’une commande sans interroger la base de données est impossible — forcez alors l’IA à utiliser un outil.

Gestion des erreurs

L’échec d’un appel d’outil est la norme : timeout API, réseau instable, paramètres incorrects… Claude propose un mécanisme élégant :

tool_result = {
    "type": "tool_result",
    "tool_use_id": tool_use.id,
    "content": "Échec de l'appel API : timeout de connexion",  # Indiquez la cause à l'IA
    "is_error": True  # Marquer comme erreur
}

Face à l’erreur, l’IA tentera une autre approche ou donnera un message convivial. Bien mieux qu’une exception brute — l’utilisateur ne voit pas une pile d’erreurs techniques, mais « Désolé, le service météo est temporairement indisponible, réessayez plus tard ».


MCP : l’avenir de la standardisation des outils

Pour parler d’appel d’outils, impossible d’ignorer MCP (Model Context Protocol).

Pourquoi MCP ?

L’écosystème actuel est trop fragmenté. Connecter un outil GitHub à Claude, un outil Slack à ChatGPT — chaque intégration se développe séparément. MCP vise un standard unique : écrire l’outil une fois, l’utiliser partout.

L’architecture est simple :

MCP Client(Claude Code/Claude Desktop)

    MCP Server(fournisseur d'outils)

   External Tool/API

MCP en pratique avec Claude Code

Claude Code offre aujourd’hui le meilleur support MCP. La commande /mcp permet de configurer les outils :

# Ajouter un serveur MCP distant
claude mcp add my-server --transport sse --url https://api.example.com/mcp

# Ajouter un outil local
claude mcp add local-tool --command node ./my-tool.js

Une fois configuré, Claude Code découvre automatiquement les outils du serveur. Mentionnez le sujet en conversation, et il appellera l’outil.

Exemple concret : j’ai configuré un outil get-github-issues, puis demandé à Claude Code : « Quels sont les open issues de ce projet ? » Il a appelé l’outil et m’a présenté le résultat.

Je n’ai jamais perçu l’existence de l’outil — c’est l’état idéal de l’appel d’outils.


Pièges en production

L’appel d’outils semble simple, mais en production les embûches sont nombreuses.

Sécurité : ne laissez pas l’IA agir n’importe comment

L’IA peut appeler des API que vous ne souhaitez pas. Solutions :

  1. Niveaux de permissions : ne donnez que les outils nécessaires ; les opérations sensibles exigent une validation humaine
  2. Validation des entrées : vérifiez les paramètres générés par l’IA avant de les transmettre à l’API
  3. Audit des appels : enregistrez paramètres et résultats de chaque appel pour la traçabilité

Contre-exemple que j’ai vu : l’IA a transmis une saisie utilisateur arbitraire directement à une interface de requête base de données — résultat : injection SQL. Ce n’était pas l’IA qui injectait, mais elle avait relayé une entrée malveillante. Ne faites jamais confiance aux paramètres générés par l’IA.

Timeout et nouvelles tentatives

Les appels peuvent échouer. Définissez un timeout raisonnable et un mécanisme de retry :

async def call_tool_with_retry(tool_func, args, max_retries=3):
    for attempt in range(max_retries):
        try:
            return await asyncio.wait_for(
                tool_func(**args),
                timeout=10.0  # Timeout 10 secondes
            )
        except asyncio.TimeoutError:
            if attempt == max_retries - 1:
                return {"error": "Timeout de l'appel d'outil"}
            await asyncio.sleep(1)  # Attendre 1 seconde avant nouvel essai

Coût en tokens

Les définitions d’outils et les résultats consomment des tokens. Avec de gros volumes de données, le coût peut grimper. Quelques conseils :

  1. Descriptions concises : le description doit rester court mais clair
  2. Limiter les données renvoyées : filtrez la réponse API, ne gardez que les champs utiles
  3. Utiliser le cache : les mêmes requêtes peuvent être mises en cache quelques minutes

Pour conclure

L’appel d’outils est une capacité centrale des Agents IA. Sans lui, l’IA ne fait que théoriser ; avec lui, elle peut vraiment vous aider.

OpenAI Function Calling est simple et efficace pour débuter et les scénarios basiques ; Claude Tool Use est plus puissant pour les systèmes Agent complexes ; MCP est la tendance de standardisation, à suivre sur le long terme.

Lequel choisir ? Selon vos besoins. Quel que soit votre choix, réfléchissez d’avance à la sécurité, à la gestion d’erreurs et à l’optimisation des performances.


Références

FAQ

Quelle différence entre OpenAI Function Calling et Claude Tool Use ?
La principale différence porte sur les appels parallèles et la gestion d'erreurs. Claude peut nativement renvoyer plusieurs appels d'outils en une fois et juger intelligemment lesquels peuvent s'exécuter en parallèle. Pour les erreurs, Claude propose le marqueur `is_error` pour un dégradé gracieux. OpenAI est plus simple à prendre en main, adapté aux scénarios basiques.
Quand utiliser MCP plutôt que Function Calling direct ?
Choisissez MCP lorsque vous construisez un écosystème d'outils et souhaitez qu'une même base serve plusieurs plateformes IA. MCP fournit un protocole standardisé : écrivez l'outil une fois, et Claude, ChatGPT et d'autres clients peuvent l'utiliser sans redéveloppement.
Comment gérer l'échec d'un appel d'outil ?
Trois recommandations : 1) définir un timeout et des tentatives (par ex. 10 s, 3 essais max) ; 2) utiliser le marqueur `is_error: true` de Claude pour indiquer la cause à l'IA ; 3) prévoir un plan de repli, comme des données en cache ou un message convivial.
Comment empêcher l'IA d'appeler des API sensibles ?
Le niveau de permissions est crucial : ne donnez à l'IA que les outils nécessaires ; les opérations sensibles (paiement, suppression) exigent une validation humaine. De plus, ne faites jamais confiance aux paramètres générés par l'IA : validez-les avant de les transmettre à l'API.
Qu'est-ce que Strict Mode ? Faut-il l'activer ?
Strict Mode est une fonctionnalité OpenAI lancée en 2024 qui garantit que les paramètres renvoyés respectent à 100 % le JSON Schema défini. En production, activez-le fortement pour éviter les erreurs de parsing. Pour l'activer : ajoutez `"strict": true` dans la définition de la function.

7 min de lecture · Publié le: 21 mars 2026 · Mis à jour le: 30 juil. 2026

Commentaires

Connectez-vous avec GitHub pour laisser un commentaire

Easton BlogEaston Blog