tools: [{ "name": "get_available_slots", "parameters": { "type": "object", "properties": { "date": { "type": "string" } } } }] — voilà, en substance, tout ce qu’il faut donner à un modèle de langage pour qu’il sache qu’une fonction de disponibilité existe, sans jamais lui donner un accès direct au planning complet d’un artisan.
Le function calling change la façon de concevoir un assistant conversationnel : plutôt que de demander au modèle de deviner un horaire à partir d’un texte libre, on lui décrit un ensemble de fonctions qu’il peut appeler, avec des paramètres typés. Le modèle choisit quelle fonction utiliser et avec quels arguments ; c’est le code qui exécute réellement l’appel, avec ses propres règles.
Le problème du planning exposé tel quel
La tentation la plus fréquente consiste à transmettre l’intégralité du calendrier au modèle sous forme de texte, puis à lui demander de repérer un créneau libre. Cette approche pose deux problèmes concrets : elle expose des informations sensibles (noms de clients, nature des interventions) dans le contexte envoyé à un fournisseur tiers, et elle oblige à renvoyer tout le planning à chaque question, ce qui gonfle rapidement la facture en tokens.
Le function calling résout les deux à la fois. Le modèle ne reçoit jamais le planning brut : il reçoit seulement la définition d’une fonction get_available_slots, qu’il peut appeler avec une date en paramètre. Le code applicatif se charge ensuite d’interroger le planning réel et de ne renvoyer que les créneaux disponibles pour cette date précise.
Deux fonctions suffisent pour la plupart des métiers
Après plusieurs itérations sur des artisans de métiers différents (plombier, électricien, vitrier), deux fonctions couvrent la grande majorité des échanges :
get_available_slots(date, duree_estimee)— renvoie les créneaux libres pour une date donnée, en tenant compte de la durée estimée de l’intervention.propose_booking(slot_id, nom_client, description)— prépare une demande de réservation, qui reste en attente de confirmation humaine avant d’être inscrite au planning.
Ce découpage en deux fonctions distinctes, l’une en lecture et l’autre en écriture différée, évite qu’un modèle inscrive directement un rendez-vous dans l’agenda réel sans validation. C’est un choix délibéré : le modèle propose, l’artisan ou une automatisation supplémentaire dispose.
Exemple de définition envoyée au modèle
{
"name": "get_available_slots",
"description": "Renvoie les creneaux disponibles pour une date donnee",
"parameters": {
"type": "object",
"properties": {
"date": { "type": "string", "description": "Date au format AAAA-MM-JJ" },
"duree_estimee": { "type": "integer", "description": "Duree en minutes" }
},
"required": ["date"]
}
}Côté serveur WordPress, cette fonction correspond à un endpoint register_rest_route classique, appelé une fois que le modèle a décidé de s’en servir. Rien n’empêche de brancher cette route sur un plugin de réservation existant plutôt que sur un développement maison.
Ce qui change réellement d’un métier à l’autre
La durée estimée d’une intervention varie énormément : un dépannage électrique peut se limiter à trente minutes, quand une pose de vitrage nécessite souvent une demi-journée. Le paramètre duree_estimee doit donc être ajusté par métier, sinon le modèle propose des créneaux trop courts et le planning réel se retrouve saturé de rendez-vous mal calibrés.
Autre variation notable : certains artisans travaillent uniquement sur devis préalable, ce qui change la fonction de réservation en une simple prise de contact plutôt qu’en une confirmation de créneau. Il ne s’agit donc pas d’un gabarit universel, mais d’un principe d’architecture à décliner selon les contraintes réelles du métier.
Limiter les appels superflus
Un modèle mal cadré a tendance à appeler la fonction de disponibilité plusieurs fois dans une même conversation, y compris quand la réponse précédente suffisait déjà. Ajouter une consigne explicite dans le prompt système, du type « n’appelle cette fonction qu’une seule fois par date demandée », réduit sensiblement ce comportement, sans jamais l’éliminer totalement.
Un plafond côté code reste indispensable : limiter le nombre d’appels de fonctions à cinq par conversation, par exemple, protège contre une boucle inattendue sans dégrader l’expérience d’un échange normal.
Le function calling ne remplace pas la logique métier, il la rend simplement accessible à un modèle de langage sous une forme qu’il peut manipuler sans jamais y toucher directement.
En résumé
Relier un assistant conversationnel à un planning d’artisan ne demande pas une intégration complexe : deux fonctions bien définies, une séparation stricte entre lecture et écriture, et des paramètres calibrés selon le métier suffisent dans la grande majorité des cas. La prise de rendez-vous complète, avec paiement d’acompte ou synchronisation multi-agenda, reste un chantier à part entière qui dépasse ce cadre.
