Comment un agent utilise-t-il un outil ?
Suivre un appel d’outil : le modèle propose, l’application exécute et le résultat revient au modèle.
La cliente a maintenant précisé ses dates. Notre agence doit rechercher des vols entre Montréal et Agadir. Écrire « voici les vols disponibles » ne suffit pas : il faut consulter une source de disponibilités.
Un outil est une fonction que l’application peut exécuter : rechercher des vols, lire un document ou calculer un total. Dans le mécanisme étudié ici, le modèle demande un appel ; il n’exécute pas lui-même la fonction. Microsoft décrit cette séparation entre génération et exécution.
Décrire l’outil pour permettre son utilisation
L’application fournit au modèle une sorte de fiche : le nom de l’outil, sa description et les paramètres attendus. Ces paramètres sont les champs à renseigner. Leurs valeurs, pour un appel particulier, sont appelées arguments. Le modèle n’a pas besoin de recevoir le code de la fonction pour demander son utilisation. Le cours Hugging Face présente ces éléments.
Pour notre exemple, l’outil rechercher_vols consulte des offres aller-retour, sans réserver. Sa fiche demande l’origine, la destination, les dates, le nombre de voyageurs et l’éventuel filtre « vols directs ».
Supposons que la cliente confirme un départ le 12 octobre 2026 et un retour le 18. Voici une représentation simplifiée de la demande d’appel, pas du code à exécuter :
Outil :
rechercher_volsArguments : origine = Montréal ; destination = Agadir ; départ = 2026-10-12 ; retour = 2026-10-18 ; voyageurs = 1 ; directs uniquement = oui.
Les dates servent à illustrer le mécanisme. Il faudra examiner les horaires pour vérifier que le voyage laisse bien quatre jours sur place. Filtrer les vols directs teste une préférence ; cela ne prouve pas qu’une telle offre existe.
Suivre l’aller-retour
Le modèle produit cette demande dans un format que l’application sait lire. Celle-ci vérifie les champs et les autorisations, puis exécute l’outil. La fonction consulte le service de recherche et renvoie un résultat, que l’application transmet au modèle.
Le résultat devient une information du contexte, pas une connaissance acquise par réentraînement. Le modèle peut alors expliquer les offres, demander une précision ou proposer une autre recherche. Hugging Face appelle ce retour une observation.
Le schéma montre un résultat simulé. Aucun vol n’a été recherché. Dans une application réelle, « je vais chercher » n’est pas une preuve d’exécution : il faut distinguer la demande d’appel du résultat effectivement renvoyé.
Distinguer un résultat vide, une erreur et une réservation
« Aucune offre trouvée » signifie que la recherche a réussi sans correspondance dans la source consultée. Cela ne prouve pas qu’aucun vol n’existe ailleurs. « Service indisponible » signifie que la recherche n’a pas pu aboutir. Présenter cette panne comme une absence de vols serait une erreur.
Même un résultat reçu peut être mal interprété : mauvaise date, devise confondue ou conditions ignorées. Il faut vérifier la correspondance avec la demande. Microsoft rappelle que les outils peuvent échouer et que leurs erreurs doivent être explicites.
Rechercher et réserver sont aussi deux opérations distinctes. L’outil de notre exemple ne réserve rien. Une réservation nécessiterait une autre capacité et les contrôles correspondants.
Ce que les frameworks prennent en charge
En Python, Google ADK peut construire la fiche d’un outil à partir d’une fonction, de sa description et de ses paramètres. LangChain Deep Agents accepte également des fonctions personnalisées dans sa liste tools. La fonction de recherche doit toutefois être fournie : déclarer son nom ne crée pas un accès aux vols.
À retenir : la demande vient du modèle, l’exécution appartient à l’application et le résultat revient au modèle. Ces trois éléments ne sont pas interchangeables.