Modèles open-source avec appel d'outils (mesuré)

L'appel d'outils est ce qui transforme un modèle de langage d'une chose qui répond en une chose qui agit : il permet au modèle d'émettre une requête structurée pour appeler une fonction — get_weather, query_database, send_email — puis de continuer à partir du résultat de l'outil. Presque tous les modèles open-source sérieux le supportent désormais en principe. Mais « en principe », c'est le piège. La capacité d'un modèle à renvoyer réellement un tool_call propre avec des arguments bien formés dépend de la pile de service autant que des poids : le même modèle qui appelle des outils proprement chez un fournisseur peut être refusé ou déformer ses arguments chez un autre. C'est pourquoi, quand nous ajoutons un modèle à notre catalogue, nous re-mesurons l'appel d'outils par un appel réel sur chaque lane fournisseur par laquelle nous routons — et c'est pourquoi vous devriez le vérifier sur l'API exacte que vous utiliserez avant de bâtir un agent dessus.

Ce qu'est réellement l'appel d'outils

L'appel d'outils (ou function calling) est le mécanisme derrière chaque framework d'agent. Vous déclarez les fonctions disponibles — avec noms, descriptions et schémas JSON pour leurs arguments — et quand le modèle décide d'agir, il émet un objet structuré tool_calls au lieu de texte brut. L'exécution appelle la fonction et renvoie le résultat ; le modèle continue ensuite. Cette boucle — modèle → outil → résultat → modèle — est toute la fondation des agents, de l'intégration API avec des services externes, et des flux de travail qui touchent le monde extérieur.

Un modèle qui ne peut pas faire cela de façon fiable ne peut pas être un agent ; il ne peut que discuter. La question « quel modèle open-source supporte l'appel d'outils » est donc vraiment « sur quels modèles puis-je bâtir un agent, et quelles lanes servent réellement cette capacité ».

C'est une propriété de la pile de service

Voici la partie qui surprend ceux qui ne lisent que les fiches modèles : l'appel d'outils n'est pas entièrement déterminé par les poids. Cela dépend de la façon dont le framework de service et le fournisseur ont câblé le chemin d'appel d'outils — les tokens spéciaux, le parseur de schéma, le contrat de réponse tool_calls. Un fournisseur peut refuser la fonctionnalité, la renvoyer déformée, ou simplement ne pas la supporter sur un déploiement donné.

Nous avons une preuve concrète dans notre propre routage. Le même Qwen2.5-VL 72B appelle des outils proprement chez l'un de nos fournisseurs mais est refusé en 400 chez un autre — même s'il s'agit du même modèle. C'est pourquoi, sur notre catalogue, toolCalling est un champ par entrée, mesuré par un appel réel sur la lane qui le sert réellement, jamais supposé depuis les poids ni copié entre fournisseurs.

Comment le vérifier en un appel

Vous n'avez pas besoin d'un benchmark pour savoir si une lane sert l'appel d'outils. Faites un seul petit appel réel :

Déclarez une fonction triviale — disons get_weather(city) avec un schéma JSON.
Envoyez un prompt qui l'exige clairement, ex. « Quel temps fait-il à Paris ? ».
Inspectez la réponse : vous voulez un tableau tool_calls valide avec un objet arguments JSON bien formé.

C'est exactement le test que nous faisons sur chaque modèle que nous ajoutons — nos notes du registry enregistrent même la ville utilisée (un get_weather sur Paris pour DeepSeek V4 Flash, Lyon pour Llama 3.3 70B chez OVHcloud). Un tool_call propre et analysable avec du JSON correct, c'est la différence entre un agent qui marche et une chaîne de texte qui ressemble à un appel de fonction.

Les modes de défaillance en pratique

Quand l'appel d'outils n'est pas réellement câblé dans la pile de service, la défaillance est rarement une erreur dure — c'est une dégradation subtile qui donne l'impression que la fonctionnalité marche. Trois schémas dominent.

Le piège de l'argument en chaîne. Un modèle renvoie un tool_call dont arguments est un bloc entre guillemets ou une description en prose au lieu d'un objet JSON analysable. L'appel « réussit » ; votre parseur, qui attend JSON.parse, plante. C'est l'échec de production le plus courant, et c'est pourquoi nous vérifions le JSON bien formé dans chaque test, pas seulement la présence d'une clé tool_calls.

Le repli textuel silencieux. Quand il ne peut réellement pas appeler l'outil, un modèle peut décider de répondre en prose — « je n'ai pas d'outil météo » — au lieu d'émettre un tool_call. Dans une boucle automatisée, cela met silencieusement le workflow en pause au lieu de lever une erreur, ce qui est plus dur à attraper qu'un plantage.

Le nom d'outil halluciné. Le modèle invoque une fonction jamais déclarée, ou avec la mauvaise signature. L'exécution la rejette, et si votre agent ne renvoie pas la requête, ce tour est perdu.

Chacun de ces points explique pourquoi un benchmark qui vérifie « a-t-il renvoyé parfois un tool_call » ne suffit pas. Le test utile est celui que nous faisons par lane : un appel requis, une vérification stricte du nom et des arguments analysables et des valeurs correctes. C'est la barre dont dépend réellement un agent.

Les modèles que nous routons avec appel d'outils

Tous les modèles de chat et de raisonnement de notre catalogue actuel sont servis avec un appel d'outils vérifié sur leur lane. C'est une sélection curée, pas le marché entier, et la liste exacte est publique sur le catalogue de modèles. Elle couvre les Qwen (235B, Qwen3.5 397B, Qwen3 32B, Qwen3 Coder 30B), GLM-5.2, DeepSeek V4 Flash, Llama 3.3 70B, GPT-OSS 120B/20B, Mistral Small 3.2 24B, et la lane accès rapide Kimi K3.

Tous sont facturés de la même façon — au token depuis un crédit prépayé, sans abonnement — donc construire un petit agent pour tester l'appel d'outils coûte une fraction d'euro. Vous ne vous engagez pas dans un contrat pour découvrir si un modèle sait utiliser des outils ; vous le mesurez pour quelques centimes.

Pourquoi c'est crucial pour les agents

Pour du travail agentique, l'appel d'outils n'est pas une case à cocher — c'est la boucle centrale, et les modes de défaillance sont spécifiques :

Arguments malformés. Un modèle qui renvoie les arguments comme une chaîne dans le wrapper, ou avec un décalage de schéma, casse tous les parseurs en aval.
tool_calls manquant. Un modèle qui répond en texte quand vous demandez un appel d'outil casse silencieusement la boucle.
Comportement dépendant de la lane. Le même modèle marche chez un fournisseur et échoue chez un autre — exactement pourquoi la capacité doit être vérifiée sur la lane d'où vous servez.

Le conseil pratique reflète donc notre propre processus : choisissez le modèle, mais vérifiez l'appel d'outils sur la lane fournisseur que vous utiliserez réellement, avec un seul appel réel bon marché, avant de câbler un agent autour.

Appel d'outils sur infrastructure souveraine UE

Les charges de travail agentiques touchent souvent des données sensibles — un appel d'outil peut lire une base interne ou une boîte mail. Si ces données doivent rester sous juridiction UE, il vous faut une lane dont l'opérateur est hors de contrôle non-UE, pas seulement un modèle qui sait appeler des outils. Tous nos modèles à appel d'outils qui tournent sur des opérateurs détenus par l'UE sont étiquetés souverains ; la lane accès rapide Kimi K3 est sous contrôle non-UE et est étiquetée en conséquence, jamais présentée comme souveraine.

La combinaison que vous voudriez réellement — poids open-source, appel d'outils vérifié, et hébergement souverain UE — est exactement ce que la lane souveraine du catalogue existe pour fournir. Un appel compatible OpenAI, un solde prépayé qui s'arrête à zéro, et aucune juridiction non-UE dans la boucle.

FAQ

Quels modèles open-source supportent l'appel d'outils ?

Presque tous les modèles open-weight sérieux de 2026 le supportent en principe, mais le support dépend de la pile de service, pas seulement des poids — le même modèle peut marcher chez un fournisseur et être refusé chez un autre. Chaque modèle du catalogue Frontière AI est servi avec un appel d'outils vérifié par un appel réel sur sa lane ; la liste exacte est publique sur le catalogue de modèles.

L'appel d'outils est-il la même chose que le function calling ?

Oui — l'appel d'outils et le function calling sont le même mécanisme, la requête structurée qu'un modèle émet pour invoquer une fonction externe. C'est la fondation des agents et des assistants IA : le modèle demande un appel, l'exécution le lance, et le modèle continue à partir du résultat.

Ai-je besoin de l'appel d'outils pour construire un agent IA ?

Oui, pour tout agent qui touche le monde extérieur. Sans un contrat tool_call fiable, un modèle ne peut que discuter — il ne peut pas interroger une base, appeler une API ou agir en votre nom. Vérifier l'appel d'outils sur votre lane fournisseur réelle est la première étape du travail agentique.

Pourquoi l'appel d'outils marcherait-il chez un fournisseur et pas un autre ?

Parce que l'appel d'outils est câblé dans la pile de service — tokens spéciaux, analyse du schéma et contrat de réponse tool_calls. Un fournisseur peut refuser, déformer ou passer la fonctionnalité même pour un modèle capable. Nous le re-mesurons par lane parce que nous avons vu le même modèle marcher chez un fournisseur et renvoyer un 400 chez un autre.

Puis-je tester l'appel d'outils avec des modèles open-source à moindre coût ?

Oui. Frontière AI facture au token depuis un crédit prépayé — sans abonnement, sans période d'essai, recharge à partir de 10 €, appels arrêtés à zéro. Un seul petit appel réel avec une fonction déclarée suffit à vérifier l'appel d'outils sur une lane, et il coûte une fraction d'euro.

Les modèles de raisonnement supportent-ils aussi l'appel d'outils ?

Oui — plusieurs des modèles de raisonnement les plus forts routent aussi l'appel d'outils, et sur notre catalogue les deux drapeaux (raisonnement et appel d'outils) sont vérifiés par lane par un appel réel. Comme le raisonnement brûle des tokens de sortie en réfléchissant, un agent de raisonnement à appel d'outils coûte plus par tour au tarif de sortie — à vérifier sur votre propre charge de travail avec un appel bon marché.

Comment construire une boucle d'agent fiable autour de l'appel d'outils ?

Commencez par une vérification de contrat stricte : un appel requis, un nom d'outil vérifiable, des arguments JSON analysables. Puis traitez les trois modes de défaillance — argument en chaîne, repli textuel silencieux, nom d'outil halluciné — en validant la réponse et en renvoyant la requête sur un tour malformé. Vérifier l'appel d'outils sur votre lane fournisseur réelle en premier est l'assurance la moins chère.

Quelle est la différence entre l'appel d'outils et la sortie structurée ?

La sortie structurée force le modèle à renvoyer du JSON dans un schéma donné. L'appel d'outils va plus loin : le modèle émet une requête pour invoquer une fonction déclarée, l'exécution la lance, et le résultat revient au modèle. La sortie structurée est un formatage à sens unique ; l'appel d'outils est une boucle qui permet au modèle d'agir et d'observer le résultat.

L'appel d'outils augmente-t-il la latence ou le coût ?

Marginalement. Un appel d'outil exige au moins un second aller-retour pour exécuter la fonction et renvoyer le résultat, donc le temps de réponse est de quelques appels, pas un. Le coût est négligeable pour les tokens d'outil eux-mêmes ; pour les modèles de raisonnement, les tokens de réflexion de chaque tour dominent. Ni l'un ni l'autre n'est une raison d'éviter l'appel d'outils si votre workflow doit agir.

Puis-je utiliser des outils avec des modèles qui ne les supportent pas nativement ?

Parfois, via un sidecar ou une astuce de prompt engineering, mais c'est fragile : le modèle peut renvoyer de la prose au lieu d'un appel structuré. Si l'appel d'outils compte pour vous, choisissez un modèle dont la lane de service le supporte vérifiablement, et confirmez par un appel réel — c'est ce que nous mesurons par modèle sur notre catalogue.

Prêt à essayer ?

Créez un compte et appelez n'importe quel modèle du catalogue en quelques minutes.

Créer un compte Voir les modèles