Voici comment l'utilisation d'outils fonctionne réellement sous le capot. Quand vous envoyez un message à une API comme Claude ou GPT-4, vous envoyez aussi une liste de définitions d'outils — chacune étant un schéma JSON décrivant le nom de la fonction, ses paramètres (avec types et descriptions), et ce qu'elle fait. Le modèle lit ces définitions comme partie de son contexte, et quand il détermine qu'appeler un outil aiderait à répondre à la question de l'utilisateur, il cesse de générer du texte et produit à la place un objet d'appel d'outil structuré : le nom de la fonction et les arguments qu'il veut passer. Votre code d'application exécute ensuite cette fonction (appelant une API, interrogeant une base de données, effectuant un calcul), et renvoie le résultat au modèle comme nouveau message. Le modèle lit le résultat et continue à générer sa réponse. Ce n'est pas le modèle qui « exécute du code » — c'est le modèle qui produit une sortie structurée que votre application interprète et sur laquelle elle agit.
La qualité de vos définitions d'outils compte énormément. Les modèles choisissent les outils en fonction de leurs noms et descriptions, donc un outil appelé search_docs avec la description « Recherche dans la base de connaissances interne les documents pertinents à partir d'une requête en langage naturel » sera utilisé de manière appropriée, tandis qu'un outil appelé sd sans description déroutera le modèle. Les descriptions de paramètres sont tout aussi importantes — si vous avez un paramètre date, spécifiez le format attendu (« ISO 8601, par ex. 2025-03-15 ») ou le modèle devinera. Dans l'API Claude, vous pouvez aussi ajouter un paramètre tool_choice pour forcer le modèle à utiliser un outil spécifique, le laisser choisir librement, ou empêcher toute utilisation d'outil. L'API d'OpenAI a des contrôles équivalents. Bien définir ces paramètres fait souvent la différence entre une intégration d'outils qui fonctionne de manière fiable et une qui casse sur les cas limites.
L'appel d'outils en parallèle est une fonctionnalité facile à négliger mais significative pour la performance. Quand un modèle a besoin de recueillir des informations de plusieurs sources — par exemple, vérifier la météo dans trois villes — il peut émettre plusieurs appels d'outils dans une seule réponse. Votre application les exécute simultanément et renvoie tous les résultats d'un coup. Claude, GPT-4 et Gemini prennent tous cela en charge. L'alternative (appels séquentiels, un par aller-retour) ajoute de la latence qui se compose rapidement. Si vous construisez une intégration d'outils, concevez votre couche d'exécution pour gérer des tableaux d'appels d'outils dès le départ.
Un piège courant est que l'utilisation d'outils n'est pas déterministe. Le même prompt avec les mêmes outils pourrait amener le modèle à appeler des outils différents, passer des arguments différents, ou choisir de ne pas utiliser d'outils du tout. Cela compte pour les tests et la fiabilité. Les systèmes en production incluent typiquement une logique de validation sur la sortie d'appel d'outil — vérifier que les paramètres requis sont présents, que les valeurs sont dans les plages attendues, que le nom de fonction correspond à un outil connu. Certaines équipes ajoutent un mécanisme de nouvelle tentative : si le modèle émet un appel d'outil mal formé, l'erreur est renvoyée comme résultat d'outil et le modèle a une chance de réessayer. Ce patron d'« auto-correction » fonctionne étonnamment bien en pratique et coûte beaucoup moins cher que d'essayer de prévenir toutes les erreurs en amont.
L'histoire de l'utilisation d'outils dans les modèles d'IA est étonnamment courte. OpenAI a introduit l'« appel de fonctions » en juin 2023 avec GPT-3.5 et GPT-4, et cela a immédiatement changé ce qu'il était possible de construire. Avant cela, les développeurs utilisaient l'ingénierie de prompt pour faire produire au modèle du JSON dans un format particulier, puis le parsaient avec des regex fragiles — cela fonctionnait, mais c'était fragile. Anthropic a livré l'utilisation d'outils pour Claude en 2024, suivie de Google pour Gemini. Les API ont convergé vers des designs très similaires : vous définissez des outils comme schémas JSON, le modèle produit des appels structurés, et vous gérez l'exécution. L'introduction de MCP fin 2024 a ensuite ajouté une couche standardisée de découverte et de transport par-dessus ce mécanisme, afin que les outils puissent être partagés entre les applications sans les redéfinir pour chacune.