Le modèle exécute-t-il lui-même les actions ?

Non. Le modèle demande une action avec des paramètres ; c'est le code de l'application qui vérifie la demande, décide de l'exécuter et garde une trace. Le modèle ne peut appeler que les outils déclarés.

Tool calling et function calling, est-ce la même chose ?

Oui. Function calling est le nom introduit par OpenAI en juin 2023 ; d'autres fournisseurs parlent de tool use ou d'appel d'outil. Le principe est le même : une action décrite en JSON Schema que le modèle peut demander.

Qu'est-ce que l'appel d'outil (tool calling) ?

Un modèle de langage produit du texte. Il ne peut pas, à lui seul, consulter un agenda, enregistrer un contact ou vérifier l'état d'une commande. L'appel d'outil, tool calling ou function calling en anglais, lui donne cette possibilité de manière encadrée : le modèle peut demander l'exécution d'une action précise, avec des paramètres structurés, et c'est le système qui l'exécute puis lui renvoie le résultat.

Comment ça marche

Le mécanisme suit toujours le même schéma :

La déclaration : le système décrit au modèle les outils disponibles. Pour chaque outil, un nom, une description en langage courant et la liste des paramètres attendus, décrits dans un format standard appelé JSON Schema
La décision : en lisant la conversation, le modèle juge qu'un outil est utile. Au lieu d'écrire une réponse, il renvoie une demande structurée : « appeler l'outil enregistrer_contact avec nom = Sophie Martin, e-mail = ... »
L'exécution : le système vérifie la demande, exécute l'action et récupère le résultat
La suite : le résultat est renvoyé au modèle, qui rédige sa réponse au visiteur en en tenant compte

Le point essentiel est la troisième étape. Le modèle ne fait que demander ; c'est le code de l'application qui décide d'exécuter ou non, contrôle les paramètres et garde une trace.

D'où ça vient

OpenAI a introduit le function calling dans son interface pour développeurs en juin 2023. Les autres grands fournisseurs de modèles ont rapidement proposé des mécanismes équivalents, sous des noms proches. C'est cette capacité qui a permis de passer d'assistants qui répondent à des assistants qui agissent, et qui sert de base aux agents IA.

Ce qu'on peut faire avec des outils

Dans un assistant d'entreprise, les outils servent surtout à :

Recueillir des informations structurées : enregistrer les coordonnées d'un visiteur ou les éléments d'une demande de devis
Transmettre : demander la reprise par un humain avec un résumé de la situation
Consulter une information à jour : un stock, une disponibilité, l'état d'un dossier dans un logiciel métier
Prévenir un autre système : envoyer un webhook à un CRM ou à un outil de suivi
Signaler une lacune : noter qu'une question est restée sans réponse pour que l'équipe complète les documents

Les règles de sécurité

Donner des outils à un modèle, c'est lui donner un pouvoir. Quelques principes limitent les risques :

Déclarer, pas improviser. Le modèle ne peut appeler que les outils qu'on lui a décrits. Il ne peut pas en inventer un
Contrôler les paramètres. Le système vérifie que les valeurs demandées respectent le schéma déclaré et les règles métier avant d'exécuter
Limiter les pouvoirs. Un assistant public peut lire une disponibilité ou enregistrer une demande ; il ne devrait pas pouvoir accorder un remboursement ou supprimer une donnée
Distinguer lecture et écriture. Consulter une information est moins risqué que la modifier. Les actions d'écriture méritent des règles plus strictes, voire une confirmation humaine
Journaliser chaque appel. Qui a demandé quoi, avec quels paramètres, avec quel résultat. Ce journal sert à vérifier, corriger et rendre des comptes
Protéger les appels sortants. Un outil qui appelle une adresse web doit refuser les adresses internes ou non prévues, pour éviter qu'une conversation serve à atteindre un système privé

Ces règles font partie des garde-fous de l'assistant. Elles rendent les tentatives de détournement beaucoup moins dangereuses : même si un visiteur parvient à faire « demander » une action non souhaitée, le système refuse de l'exécuter.

Les limites

Le modèle peut se tromper d'outil ou mal remplir un paramètre. Des descriptions claires et des essais réduisent ces erreurs
Un outil lent ralentit la conversation. Le visiteur attend pendant l'appel
Les données renvoyées par l'outil entrent dans la conversation. Si l'outil renvoie trop d'informations, ou des informations personnelles inutiles, le modèle risque de les répéter. Il faut limiter ce qu'il renvoie
Chaque outil est une intégration à maintenir. Quand le logiciel métier change, l'outil doit suivre

Faut-il des outils dès le départ ?

Pour une PME, rarement. Un assistant qui répond à partir des documents, recueille les coordonnées et passe la main couvre la plupart des besoins. Les outils de consultation d'un logiciel métier se justifient quand une question fréquente dépend d'une information qui change tous les jours et qu'aucun document ne peut tenir à jour.

L'appel d'outil dans KernChat

Dans KernChat, les actions sont des lignes déclarées, pas du code écrit pour chaque client. Le modèle voit chaque action sous la forme d'un outil décrit en JSON Schema ; le serveur l'exécute avec un exécuteur générique et chaque exécution est enregistrée dans un journal. Les actions courantes sont intégrées : recueillir un contact, créer une demande commerciale, demander la reprise par l'équipe, signaler une question sans réponse, retenir une information. L'organisation peut en déclarer d'autres, comme l'appel d'un webhook ou la consultation d'un service externe, dont les adresses sont contrôlées avant chaque appel.