En clair
Un modèle de langage ne sait faire qu’une chose : produire du texte. Seul, il ne peut ni consulter la météo, ni lire votre agenda, ni faire une addition de façon fiable. L’appel d’outils lui donne des mains. On lui présente une liste d’actions possibles, et il peut répondre, au lieu d’une phrase : « j’ai besoin que l’on consulte le stock de l’article 4512 ».
L’image du chef de cuisine aide à comprendre le partage des rôles. Le chef ne quitte pas son poste : il passe commande à voix haute, un commis va chercher l’ingrédient et le lui rapporte. Le modèle est le chef, l’application est le commis. Le modèle n’exécute jamais rien lui-même. Il formule une demande, et c’est le logiciel autour de lui qui décide de l’exécuter, de la refuser ou de demander d’abord l’accord d’un humain.
Un exemple
Un assistant de service client dispose de deux outils : « consulter une commande » et « créer un bon de retour ». Un client écrit que son colis est arrivé abîmé. Le modèle demande d’abord la consultation de la commande avec le numéro fourni. L’application interroge le système de gestion et renvoie le détail : article, date, montant.
Le modèle constate que le retour est possible et demande la création du bon. L’entreprise a réglé l’application pour que cette seconde action passe par la validation d’un conseiller au-delà de 200 euros.
Comment ça marche
Chaque outil est déclaré au modèle par trois éléments : un nom, une description en langage naturel et un schéma des arguments attendus, en général au format JSON Schema 12. Ces définitions font partie du contexte. Quand le modèle juge un outil utile, il ne répond pas en texte libre : il émet un bloc structuré qui contient le nom de l’outil et des arguments conformes au schéma.
- DéclarerL’application fournit au modèle la liste des outils et leurs schémas.
- DemanderLe modèle émet un appel : nom de l’outil et arguments.
- ExécuterL’application contrôle la demande, puis exécute l’action.
- RenvoyerLe résultat revient au modèle, qui poursuit ou conclut.
Les étapes 2 à 4 peuvent se répéter plusieurs fois au cours d’une même tâche.
L’application intercepte ce bloc, exécute la fonction correspondante et renvoie le résultat dans un nouveau message. Le modèle reprend alors la main : il peut répondre à l’utilisateur ou demander un autre outil, éventuellement plusieurs en parallèle. Cette boucle est la brique de base des agents. Certains outils sont exécutés par l’application du client, d’autres directement sur les serveurs du fournisseur du modèle, comme la recherche web 1.
L’idée qu’un modèle de langage apprenne à décider quand appeler une interface de programmation, et avec quels arguments, a été démontrée en 2023 avec Toolformer, qui utilisait notamment une calculatrice, un moteur de recherche et un calendrier 3. Les modèles actuels sont entraînés pour cet usage. La qualité des descriptions d’outils pèse lourd : un outil mal décrit est mal choisi ou mal utilisé.
Ce que ça change pour une entreprise
L’appel d’outils fait passer un modèle du statut de rédacteur à celui d’opérateur : il peut interroger les systèmes de l’entreprise, obtenir des données à jour et déclencher des actions. C’est aussi un moyen de fiabiliser les réponses, en confiant les calculs à une calculatrice et les faits à une base de données plutôt qu’à la mémoire du modèle.
Chaque outil est aussi une porte ouverte sur un système. Il faut donc décider, outil par outil, ce qui est permis : lecture seule, écriture, validation humaine. Les définitions d’outils et leurs résultats occupent de la place dans le contexte et se paient en tokens. Enfin, le modèle peut se tromper d’outil ou d’argument : les actions irréversibles, comme un paiement ou une suppression, demandent des contrôles côté application.
Idées reçues
- « Le modèle exécute lui-même les actions. »
Il ne fait que les demander. L’exécution appartient à l’application, qui peut filtrer, refuser ou soumettre la demande à un humain.
- « Plus on donne d’outils, plus l’assistant est capable. »
Trop d’outils, ou des outils qui se ressemblent, encombrent le contexte et augmentent les erreurs de choix. Un petit jeu d’outils bien décrits fonctionne mieux.
- « Un appel d’outil est toujours correct puisqu’il respecte un format. »
Le format garantit la forme, pas le fond. Un argument peut être bien écrit et faux, par exemple un mauvais numéro de client.