Notion · Faire agir l’IA
Function calling (appel d’outil)
La capacité d’un modèle à demander l’exécution d’une fonction : chercher un client, créer un événement, lire un fichier. Le modèle décide, le logiciel exécute.
Comment ça marche
Un modèle de langage ne fait que du texte. Pour qu’il consulte votre CRM, votre agenda ou votre base de données, il faut un relais. Le function calling est ce relais : vous décrivez au modèle les fonctions qu’il peut demander, et quand votre question s’y prête, il répond non par du texte mais par une demande d’appel, structurée, avec les paramètres. Votre logiciel exécute, et renvoie le résultat au modèle, qui poursuit.
C’est le mécanisme de base de tout agent. Lire un fichier, chercher sur le web, créer un ticket, envoyer un e-mail : chacune est une fonction décrite au modèle. Ce que le modèle peut faire se résume à la liste des fonctions qu’on lui donne. Et comme c’est votre logiciel qui exécute, vous pouvez vérifier chaque demande avant de l’honorer, la journaliser, ou la refuser.
Un exemple concret
- Les fonctions décrites au modèle : disponibilites(date_debut, date_fin) qui renvoie les créneaux libres ; creer_rendez_vous(client, date, heure, motif) ; chercher_client(nom) qui renvoie la fiche.
- Le client écrit : « Je voudrais un rendez-vous la semaine prochaine pour un bilan, plutôt le matin. Je suis Mme Lefèvre. »
- Le modèle demande : chercher_client(« Lefèvre »), puis disponibilites(lundi, vendredi). Le logiciel exécute les deux et renvoie la fiche et les créneaux.
- Le modèle propose trois créneaux du matin, en texte. Le client en choisit un.
- Le modèle demande : creer_rendez_vous(Lefèvre, mardi, 9h30, bilan). Le logiciel exécute après vérification que le créneau est toujours libre, et confirme.
Le modèle n’a jamais touché à l’agenda. Il a demandé, le logiciel a fait. La règle « vérifier que le créneau est toujours libre » est dans le logiciel, pas dans le modèle.
Ce que ça change pour une équipe
- Les logiciels de l’entreprise deviennent pilotables par la parole. Toute fonction décrite au modèle devient accessible en langage courant.
- Le contrôle reste dans votre code. Chaque demande du modèle passe par votre logiciel, qui peut valider, limiter, journaliser.
- La description des fonctions est un travail de métier. Dire clairement ce que fait chaque fonction et quand l’utiliser, c’est ce qui fait un agent qui choisit juste.
- Les actions sensibles se protègent au bon endroit. Une fonction qui envoie ou supprime peut exiger une validation humaine dans son exécution, quoi que demande le modèle.
Les limites et les erreurs fréquentes
- Des descriptions floues. « Gère les clients » ne dit pas au modèle quand appeler la fonction. Une phrase précise par fonction, avec un exemple.
- Trop de fonctions. Cinquante fonctions décrites, et le modèle hésite, confond, coûte cher. On donne celles qui servent à la tâche.
- Exécuter sans vérifier. Le modèle peut demander un appel avec des paramètres faux ou dangereux. Le logiciel valide avant d’exécuter, toujours.
- Oublier les erreurs. Une fonction qui échoue doit le dire au modèle clairement, pour qu’il s’adapte au lieu de supposer que ça a marché.
Pour aller plus loin
Le modèle reçoit la description des fonctions disponibles et produit, quand c’est pertinent, un appel structuré avec ses paramètres. L’application exécute la fonction et renvoie le résultat dans le contexte. C’est la brique de base des agents et du MCP.
Où ça se situe chez Opora
Programme 04 · Construire des agentsIngénierie agentique pour les équipes techniques
Donner des outils à un modèle, décrire ce qu’ils font et contrôler ce qu’il en fait, c’est le premier atelier technique du programme Construire des agents.
Questions fréquentes
Le modèle exécute-t-il lui-même la fonction ?
Non, jamais. Il produit une demande structurée : « appelle la fonction chercher_client avec le nom Durand ». C’est votre logiciel qui exécute la fonction, puis renvoie le résultat au modèle. Le modèle décide, le logiciel agit. Cette séparation est ce qui permet de garder le contrôle.
Quelle différence avec MCP ?
Le function calling est le mécanisme de base : un modèle qui demande l’appel d’une fonction. MCP est un standard qui décrit les fonctions disponibles dans un format commun à tous les assistants. MCP utilise le function calling ; il le rend portable d’un outil à l’autre.
Comment le modèle sait-il quelle fonction appeler ?
On lui donne la liste des fonctions avec, pour chacune, un nom, une description en langage courant et les paramètres attendus. La qualité de ces descriptions décide de la qualité des appels. Une description vague donne des appels à côté.