Le function calling est le mécanisme le plus courant par lequel les grands modèles de langage accèdent à des capacités externes : le développeur décrit d'abord au format JSON Schema « quelles fonctions existent et à quoi ressemblent leurs paramètres ». Quand le modèle a besoin de données ou d'une action en cours de conversation, il émet une demande d'appel structurée. Votre programme exécute la vraie fonction et renvoie le résultat pour que le modèle continue. L'essentiel en une phrase : le modèle ne décide que de « quoi appeler et quels paramètres remplir » — le code qui s'exécute vraiment est toujours le vôtre.
Quel problème résout-il vraiment ?
Un modèle ne produit nativement que du texte ; les choses « concrètes » comme vérifier la météo, lire une base de données ou passer une commande lui sont impossibles. Le function calling construit un pont entre les deux : le modèle comprend la demande en langage naturel, exprime « quelle fonction appeler et avec quels paramètres » dans un format structuré, et laisse l'exécution au programme. C'est exactement le socle sur lequel repose le tool calling.
À quoi ressemble un appel de fonction complet
- Définir : inclure dans la requête un tableau tools décrivant le nom, la description et la structure des paramètres (JSON Schema) de chaque fonction.
- Décider : quand le modèle a besoin d'une capacité externe, il ne répond pas directement mais renvoie des tool_calls : un nom de fonction plus des paramètres en JSON.
- Exécuter : votre programme interprète les tool_calls et invoque la vraie fonction — appel d'API, lecture de base de données ou exécution de script.
- Renvoyer : le résultat repart dans la conversation comme message tool, et le modèle en tire sa réponse finale.
Les briques essentielles
- Définitions tools : un « mode d'emploi » pour le modèle. Plus la description est claire, plus les paramètres sont justes — notez que description s'écrit pour le modèle, pas pour les humains.
- tool_choice : contrôle si le modèle « doit appeler / peut appeler / ne doit pas appeler » une fonction ; en pratique auto, none ou un nom de fonction précis.
- Appels parallèles : plusieurs tool_calls en une fois, pratique pour régler plusieurs tâches indépendantes en un seul tour.
- Contraintes structurelles : les paramètres doivent être du JSON valide ; une erreur de type échoue côté programme, les contraintes du Schema sont donc rigides.
Les vraies différences avec le tool calling, MCP et les appels de plugins
| Dimension | Function Calling | Tool Calling | MCP | Appels de plugins |
|---|---|---|---|---|
| Nature | Un mécanisme d'appel | Un terme générique | Un protocole de connexion | Un modèle de distribution des capacités |
| Qui définit les outils | Le développeur, dans la requête | Variable | Exposé par le serveur MCP | Empaqueté par la plateforme |
| Problème résolu | Comment le modèle initie un appel | Comment le modèle utilise des capacités externes | Comment découvrir et connecter les outils uniformément | Comment les capacités parviennent aux utilisateurs |
Le function calling a été popularisé par OpenAI en 2023, et la plupart des modèles courants proposent aujourd'hui des implémentations compatibles ; le tool calling est le seau plus large, qui contient aussi bien le function calling que l'exécution de code et les outils MCP. Retenez ceci : MCP s'occupe du « comment connecter », les plugins du « comment distribuer », le function calling du « comment initier » — les trois sont des maillons d'une chaîne, pas des remplaçants les uns des autres. La frontière avec les appels de plugins suit la même logique.
Limites et frontières
- Hallucinations de paramètres : le modèle peut inventer des noms de paramètres ou se tromper de type ; la validation côté programme est obligatoire.
- Tokens et latence : chaque appel ajoute un tour de conversation, et les définitions tools consomment elles-mêmes du contexte — beaucoup d'outils, c'est cher et lent.
- Lignes rouges de sécurité : ne jamais laisser le modèle déclencher directement des actions irréversibles comme effacer une base, transférer de l'argent ou envoyer des mails en masse ; les actions sensibles exigent une confirmation humaine.
- Maturité inégale : les modèles diffèrent dans la maturité de leur prise en charge du function calling ; les petits « parlent souvent sans jamais appeler » ou ratent le format.
Idées reçues
- « Le modèle exécute vraiment du code » — non. Il n'émet que des demandes d'appel ; l'exécution vit dans votre programme.
- « Le function calling, c'est MCP » — non. MCP est une couche protocole ; les outils qu'il expose peuvent quand même être utilisés par le modèle via des mécanismes comme le function calling.
- « Avec le function calling, les plugins sont inutiles » — les plugins distribuent des capacités aux utilisateurs, le function calling sert les développeurs ; des couches différentes.
- « Une fois défini, le modèle appellera toujours » — le défaut est auto ; si le modèle n'en voit pas le besoin, il n'appelle pas. Pour forcer, nommez explicitement la fonction.
FAQ
Q : Le function calling est-il la même chose que les paramètres d'outils des API des différents fournisseurs ?
R : Même lignée — « le modèle émet des appels structurés, le programme exécute » — avec des différences de noms de champs et d'emballage ; la migration consiste surtout à réécrire les définitions.
Q : J'utilise déjà MCP. Dois-je quand même me soucier du function calling ?
R : Oui. MCP règle comment les outils se connectent ; le function calling, comment le modèle initie les appels. Amont et aval, pas l'un ou l'autre.
Q : Le function calling peut-il invoquer des scripts locaux ?
R : Oui. Une fonction n'est qu'un point d'entrée de votre programme ; ce qu'il y a derrière ne regarde pas le modèle. Il dit seulement « laquelle, avec quels paramètres ».
