Vous transmettez le message d’un utilisateur à l’API GPT et, au lieu d’une réponse en langage naturel, le modèle vous renvoie un objet JSON structuré indiquant exactement quelle fonction appeler et avec quels arguments. C’est l’appel de fonctions — et cela change le type d’applications que vous pouvez construire avec des LLM.
La plupart des développeurs entendent « appel de fonctions » et supposent que le modèle exécute du code pour eux. Ce n’est pas le cas.
Avec l’appel de fonctions, le LLM n’exécute pas la fonction lui‑même. Il identifie la fonction appropriée, rassemble tous les paramètres requis et fournit l’information dans un format JSON structuré.
Votre application reste responsable de l’exécution de la logique réelle. Le modèle vous indique simplement quoi exécuter et avec quelles entrées.
Cette distinction est plus importante qu’il n’y paraît, et elle influence tout, de l’architecture de votre intégration à votre approche de la sécurité.
Ce qu’est réellement l’appel de fonctions — et ce que les gens confondent encore
L’appel de fonctions (également appelé appel d’outils) offre un moyen puissant et flexible permettant aux modèles OpenAI d’interfacer des systèmes externes et d’accéder à des données en dehors de leurs données d’entraînement.
La dénomination est la première source de confusion. Les gens pensent que le modèle exécute quelque chose. Ce n’est pas le cas.
Il existe de nombreux noms et explications pour l’appel de fonctions, mais tout se résume à une phrase : « l’appel de fonctions est un type de capacité de sortie structurée d’un grand modèle de langage ». Les LLM n’appellent aucune fonction par eux‑mêmes ; ils suggèrent quelle fonction vous devriez appeler parmi les fonctions prédéfinies que vous fournissez au LLM dans une invite.
La deuxième source de confusion concerne l’ancienne surface d’API.
Les paramètres functions et function_call ont été déconseillés avec la sortie de la version 2023-12-01-preview de l’API. Le remplacement de functions est le paramètre tools.
Si vous suivez un tutoriel qui utilise l’ancien paramètre functions, vous utilisez déjà une syntaxe obsolète. Utilisez plutôt tools et tool_choice.
Une fonction est un type spécifique d’outil, défini par un schéma JSON. Une définition de fonction permet au modèle de transmettre des données à votre application, où votre code peut accéder à des données ou effectuer des actions suggérées par le modèle.
C’est ce schéma qui confère à l’appel de fonctions son avantage en termes de fiabilité par rapport à une simple invite — vous n’espérez pas que le modèle formate correctement la sortie, vous imposez la structure au niveau de l’API.
Comment fonctionne l’appel d’outils dans l’API OpenAI — étape par étape
L’appel d’outils est une conversation multi‑étapes entre votre application et un modèle via l’API OpenAI. Le flux d’appel d’outils comporte cinq grandes étapes : envoyer une requête au modèle avec les outils qu’il pourrait appeler...
Voici à quoi ressemble chacune de ces étapes en pratique.
Étape 1 : Définir les schémas de vos fonctions. Vous décrivez chaque fonction disponible comme un objet JSON dans le paramètre tools. Le schéma comprend le nom de la fonction, une description en langage naturel que le modèle utilise pour décider quand l’invoquer, et un bloc parameters qui suit les conventions de JSON Schema.
Plus votre description est détaillée — en termes de situations dans lesquelles la fonction peut et doit être appelée — mieux c’est. Notez toutefois que les descriptions de fonctions font partie de l’invite et consomment donc des jetons.
Étape 2 : Envoyer la requête. Vous appelez l’API Chat Completions avec le message de l’utilisateur et votre liste tools. Le modèle voit les deux.
Étape 3 : Le modèle décide s’il doit appeler une fonction.
Un appel de fonction correspond à un type particulier de réponse que vous pouvez recevoir du modèle s’il examine une invite et détermine que, pour suivre les instructions, il a besoin d’appeler l’un des outils mis à sa disposition. Si le modèle reçoit une invite du type « quel temps fait‑il à Paris ? », il pourrait répondre par un appel d’outil pour l’outil get_weather, avec Paris comme argument de localisation.
Étape 4 : Votre code exécute la fonction. Vous analysez la réponse du modèle, extrayez le nom de la fonction et les arguments, puis exécutez le code réel dans votre runtime. L’API a renvoyé un JSON structuré — à vous de décider quoi en faire.
Étape 5 : Renvoyer le résultat.
Vous renvoyez ensuite l’ensemble de la définition de l’outil, l’invite d’origine, l’appel d’outil du modèle et la sortie de l’appel d’outil au modèle pour finalement recevoir une réponse textuelle
— quelque chose comme « Le temps à Paris aujourd’hui est de 25 °C. »
Un détail que la plupart des tutoriels omettent :
lorsque vous définissez strict: true dans votre définition de fonction, Structured Outputs garantit que les arguments générés par le modèle pour un appel de fonction correspondent exactement au JSON Schema que vous avez fourni.
Définir strict à true garantit que les appels de fonctions respectent de manière fiable le schéma de la fonction, plutôt que d’être au mieux. OpenAI recommande d’activer systématiquement le mode strict.
Toujours. Il n’y a aucune bonne raison de ne pas le faire.
Il existe aussi l’appel de fonctions en parallèle.
Selon la requête de l’utilisateur, le modèle invoquera l’appel parallèle de fonctions si vous utilisez les derniers modèles publiés à partir du 6 novembre 2023.
Cela signifie qu’une seule requête comme « quel temps fait‑il à Londres et à Tokyo ? » peut déclencher deux appels d’outil simultanés plutôt que de les chaîner de manière séquentielle.
Cas d’usage réels de l’appel de fonctions
L’exemple de la météo est partout parce qu’il est propre. Les cas de production réels sont plus complexes et plus intéressants.
Chaînes de support client avec données en direct
L’appel de fonctions est utile pour un grand nombre de cas d’usage — par exemple, un assistant IA qui doit récupérer les dernières données client depuis un système interne lorsqu’un utilisateur demande « quels sont mes récents achats ? » avant de pouvoir générer une réponse.
Le modèle détermine l’intention, extrait l’ID client du contexte et appelle l’API interne de votre CRM. Aucune regex fragile. Aucun modèle d’invite assez fragile pour casser à la moindre virgule manquante.
Extraction de données structurées à grande échelle
Un pipeline d’extraction de données qui récupère du texte brut, le convertit en données structurées et les enregistre dans une base de données est un autre très bon cas. Vous obtenez des schémas cohérents sur des milliers de documents sans ajuster manuellement la logique d’analyse selon le type de document.
Du langage naturel aux API
Des solutions LLM pour extraire et étiqueter des données, des applications qui aident à convertir le langage naturel en appels d’API ou en requêtes de base de données valides, et des moteurs de recherche conversationnels qui interagissent avec une base de connaissances — tous bénéficient de la garantie de format fournie par l’appel de fonctions. Lorsque la sortie doit piloter des systèmes en aval, vous ne pouvez pas vous permettre de variabilité.
Flux agentiques avec plusieurs outils
Pour les développeurs, l’appel de fonctions permet l’accès en temps réel aux données pour contourner les limites de formation en récupérant des cours boursiers, la météo ou des entrées récentes de base de données. Il permet également l’exécution d’actions — transformant le LLM d’un observateur passif en un participant actif qui modifie l’état, comme envoyer des e‑mails, mettre à jour des CRM ou déployer du code.
La différence clé avec un simple chatbot : le modèle ne se contente pas de générer du texte, il orchestre de véritables opérations à travers vos systèmes.
Bonnes pratiques pour l’appel de fonctions — là où les développeurs se trompent souvent
C’est la section que la plupart des tutoriels ignorent complètement, ce qui amène les équipes à déboguer des pannes bizarres en production à 2 h du matin.
Des descriptions trop vagues. Le modèle utilise la description de votre fonction pour décider quand l’appeler. Si votre description est générique — du type « traite les requêtes utilisateur » — le modèle n’a aucun signal fiable pour la déclencher. Soyez précis quant à la condition de déclenchement et à la forme d’entrée attendue. Considérez la description comme un contrat, pas une étiquette.
Exposer trop de fonctions en même temps
Les descriptions de fonctions peuvent consommer un nombre significatif de jetons dans l’invite d’entrée.
Charger les définitions de 50+ outils dans l’invite système crée deux problèmes : le coût et la latence, car les définitions d’outils consomment des jetons d’entrée ; et une dégradation de la précision, car à mesure que le nombre d’options d’outils augmente, la capacité du modèle à sélectionner le bon diminue.
Commencez avec l’ensemble le plus restreint de fonctions dont votre cas d’usage a réellement besoin.
Supposer que le modèle n’hallucinera pas de paramètres. Il le fera.
Le modèle peut halluciner des paramètres
— en particulier pour les champs optionnels qui ne sont pas clairement bornés par un enum. C’est précisément pour cela que strict: true est important : cela supprime la capacité du modèle à inventer des champs en dehors de votre schéma.
Ne pas gérer la boucle multi‑tours. Les développeurs construisent souvent le happy path — l’utilisateur demande, le modèle appelle la fonction, terminé.
Les modèles peuvent générer des appels de fonctions qui ne correspondent pas au schéma que vous avez défini ou tenter d’appeler une fonction que vous n’avez pas incluse. Si le modèle génère des appels de fonctions inattendus, essayez d’inclure une phrase dans le message système indiquant « N’utilise que les fonctions qui t’ont été fournies. »
Prévoyez les cas limites.
Ignorer l’étape de confirmation avant les opérations d’écriture.
Soyez conscient de l’impact réel des appels de fonctions que vous prévoyez d’exécuter, en particulier ceux qui déclenchent des actions comme l’exécution de code, la mise à jour de bases de données ou l’envoi de notifications. Pour les fonctions qui effectuent des actions, il est fortement recommandé d’implémenter une étape où l’utilisateur confirme l’action avant exécution.
Si un appel de fonction peut supprimer des données, envoyer de l’argent ou modifier un état externe, un humain doit l’approuver d’abord.
Considérations de sécurité et de fiabilité
L’appel de fonctions étend ce qu’un LLM peut faire. Il étend aussi ce qu’un attaquant peut le faire faire.
La menace principale ici est l’injection de prompts.
Les objectifs finaux des injections varient, mais peuvent inclure l’exfiltration de données privées via des appels d’outils en aval, des actions mal alignées, ou la modification du comportement du modèle de manière non désirée.
Lorsque vos appels de fonctions peuvent envoyer des e‑mails, interroger des bases de données ou déclencher des webhooks, une attaque par injection n’est pas qu’un chatbot qui sort du script — c’est une possible brèche.
À mesure que les systèmes d’IA vont au‑delà du chat et commencent à appeler des outils et à prendre des mesures, l’injection de prompts devient un problème beaucoup plus sérieux. Une instruction malveillante cachée dans une page web, un document ou un outil externe peut tenter de contourner le comportement du système, d’exposer des informations sensibles ou de déclencher des actions que le modèle ne devrait jamais entreprendre.
La stratégie d’atténuation comporte quelques couches concrètes.
Concevez des flux de travail pour que les données non fiables ne pilotent jamais directement le comportement d’un agent. N’extrayez que des champs structurés spécifiques — tels que des enums ou du JSON validé — à partir des entrées externes afin de limiter le risque d’injection entre les nœuds.
Par‑dessus cela,
vérifiez toujours les appels de fonctions générés par le modèle. Cela inclut la vérification des paramètres, de la fonction appelée, et l’assurance que l’appel correspond à l’action souhaitée.
Une vérité inconfortable :
« L’injection de prompts, tout comme les escroqueries et l’ingénierie sociale sur le web, ne sera probablement jamais complètement ‘résolue’. »
C’est l’évaluation d’OpenAI. La conséquence pratique est que vous ne devez pas architecturer des systèmes agentiques à appel de fonctions en partant du principe que le modèle se comportera toujours comme prévu. La défense en profondeur — validation, permissions à périmètre restreint, humain dans la boucle pour les opérations destructrices — est la seule posture raisonnable.
Appel de fonctions vs ingénierie de prompts — quand utiliser quoi
Cette comparaison revient sans cesse. La réponse courte : ils résolvent des problèmes différents, et les confondre conduit à des invites sur‑ingénierées là où l’appel de fonctions suffirait, ou à des schémas de fonctions fragiles là où une invite système bien conçue serait plus simple.
L’ingénierie de prompts consiste à élaborer des entrées textuelles pour guider le raisonnement interne du LLM — en lui demandant par exemple de « réfléchir étape par étape ».
Elle façonne la manière dont le modèle raisonne. L’appel de fonctions, quant à lui, façonne ce que le modèle produit en sortie et dirige cette sortie directement dans votre système.
L’appel d’outils est la capacité qui permet au LLM d’interagir avec des systèmes externes. Bien que vous utilisiez l’ingénierie de prompts pour aider le modèle à décider quel outil utiliser, l’appel d’outils est le mécanisme qui exécute réellement l’action. Vous aurez probablement besoin des deux, mais ils servent des objectifs différents.
Un avantage technique clé de l’appel de fonctions par rapport à une sortie structurée basée sur l’invite :
l’appel d’outils est un concept intégré au modèle. Inutile de gaspiller des jetons et des efforts à expliquer au modèle qu’il doit renvoyer un format spécifique.
Lorsque vous rédigez une invite qui dit « renvoie ta réponse en JSON avec les champs X, Y et Z », vous dépensez des jetons pour des instructions que le modèle peut suivre de façon incohérente. Avec l’appel de fonctions, l’application du schéma se fait au niveau de l’API.
Les API d’appel de fonctions, désormais prises en charge nativement dans de nombreuses plateformes LLM, fournissent une interface formelle pilotée par schéma qui permet une validation stricte des données et une intégration avec des flux de travail programmatiques.
C’est la raison concrète de le préférer à l’ingénierie de prompts pour toute donnée devant alimenter des systèmes en aval : la fiabilité n’est pas optionnelle une fois en production.
| Dimension | Ingénierie de prompts | Appel de fonctions |
|---|---|---|
| Objectif principal | Façonner le raisonnement et le ton du modèle | Produire une sortie structurée pour l’intégration au système |
| Format de sortie | Texte libre (ou JSON en forme de texte) | Schéma JSON imposé |
| Fiabilité du schéma | Au mieux ; sujet à la dérive | Garantie avec strict: true |
| Coût en jetons | Plus faible pour des sorties simples | Plus élevé (les définitions de fonctions ajoutent des jetons) |
| Quand l’utiliser | Tâches de raisonnement, génération de texte, contrôle du style | Extraction de données structurées, orchestration d’API, actions agentiques |
| Exposition à l’injection | Plus faible (pas d’exécution d’outils externes) | Plus élevée (les appels de fonctions peuvent déclencher des actions réelles) |
L’heuristique pratique : si la sortie doit piloter un système en aval — écriture en base, appel d’API, embranchement de décision dans votre code — utilisez l’appel de fonctions. Si la sortie est destinée à un humain, l’ingénierie de prompts suffit généralement et coûte moins cher.
Points clés
| Sujet | À retenir |
|---|---|
| Ce que c’est | Le modèle produit un JSON structuré décrivant quelle fonction appeler — il n’exécute pas la fonction |
| Surface d’API actuelle | Utilisez tools et tool_choice ; les paramètres functions et function_call sont obsolètes |
| Mode strict | Définissez toujours strict: true dans les définitions de fonctions pour appliquer la conformité au schéma |
| Appels parallèles | Pris en charge sur les modèles sortis après novembre 2023 ; une requête peut déclencher plusieurs appels d’outils |
| Coût en jetons | Les schémas de fonctions consomment des jetons d’entrée ; minimisez le nombre de fonctions exposées |
| Sécurité | Validez toutes les sorties d’appels de fonctions ; ne laissez jamais du contenu externe non fiable piloter directement les appels d’outils |
| vs. prompts | L’appel de fonctions impose la structure de sortie au niveau de l’API ; l’ingénierie de prompts façonne le raisonnement interne |
| Étapes de confirmation | Toute fonction ayant des effets réels (écrire, envoyer, supprimer) doit requérir une confirmation utilisateur avant exécution |
Si vous souhaitez expérimenter l’appel de fonctions sur différents modèles — GPT-5.4, claude opus 4.7, gemini 3.1 pro — sans maintenir des identifiants API séparés pour chacun, CometAPI vous donne accès à tous via un point de terminaison et une clé uniques, ce qui rend les tests inter‑modèles beaucoup moins contraignants.
CometAPI résout la charge d’infrastructure :
✅ Syntaxe d’appel de fonctions unifiée sur plus de 15 modèles
✅ Clé API unique — pas de comptes séparés pour OpenAI/Anthropic/Google
✅ Traduction automatique de schémas — écrivez une fois, testez partout
✅ Suivi des coûts intégré — comparez l’utilisation de jetons par modèle en temps réel
Commencez à tester avec des crédits gratuits → Obtenir l’accès