Appel d’outils

On commence par décrire les outils proposés. Chacun a un nom, une courte description et un schéma JSON de ses paramètres, par exemple une fonction get_weather qui prend une ville. Tu envoies cette liste avec la conversation. Si le modèle juge un outil utile, sa réponse contient un appel d’outil plutôt que du texte final : le nom de l’outil et les arguments, écrits en JSON. Ton programme exécute la fonction, ajoute un message portant le résultat et l’identifiant de l’appel, puis renvoie le tout. Le modèle rédige alors la réponse finale à partir de ce résultat. Pense à un serveur qui note ta commande sur un papier sans jamais entrer en cuisine. Exemples typiques : consulter l’état d’une commande, convertir une devise, interroger une base de connaissances ou créer un événement d’agenda.

La plupart des API permettent d’orienter le comportement. On peut laisser le choix au modèle, interdire les outils, exiger qu’un outil soit appelé ou nommer l’outil précis. Plusieurs appels peuvent venir dans la même réponse, ce qui économise des allers-retours quand ils sont indépendants, et dans une réponse en flux les arguments arrivent par morceaux sous le même indice. Le même mécanisme fait tourner les agents, qui répètent le cycle appel, résultat, décision, et c’est aussi une façon fiable d’extraire des données structurées d’un texte. Certains fournisseurs proposent un mode strict qui impose à la sortie de correspondre exactement au schéma et supprime beaucoup d’appels mal formés.

Il faut rester prudent. Un modèle peut choisir le mauvais outil, inventer un argument ou appeler une fonction avec des valeurs valides mais dangereuses : valide donc les arguments de ton côté et n’exécute jamais plus puissant que nécessaire. Tous les modèles ne prennent pas cette fonctionnalité en charge, et ceux qui le font respectent un schéma avec plus ou moins de constance. Teste sur des cas réels, garde des descriptions d’outils courtes et précises, et donne aux outils des noms qui disent ce qu’ils font. Garde la liste d’outils courte : un long menu perturbe les modèles et grignote la fenêtre de contexte. Défauts typiques : une ville mal orthographiée, un champ obligatoire manquant ou une date au mauvais format.

L’API de NeverNo le prend en charge sur les complétions de discussion. Passe tools, une liste de fonctions avec un schéma JSON, et éventuellement tool_choice (auto, none, required ou une fonction nommée) et parallel_tool_calls. Quand le modèle appelle un outil, la réponse contient tool_calls et finish_reason vaut tool_calls ; tu exécutes la fonction et renvoies un message tool avec le résultat et son tool_call_id. En flux, chaque appel arrive comme OpenAI l’écrit.

Seuls les modèles dont capabilities.tools vaut true dans la liste /models acceptent des outils ; tout autre répond par une erreur 400 claire nommée tools_not_supported. GLM 5.2, un modèle privé de Z.ai inclus dans les offres payantes, a une fenêtre de contexte de 200 000 jetons et un mode de raisonnement optionnel. Consulte la liste avant de construire sur un modèle. La page sur l’alternative à ChatGPT explique pourquoi l’on choisit NeverNo pour la variété des modèles.