Comment un agent IA utilise des outils

Un outil peut être une simple fonction Python, une API, une base de données, un moteur de recherche ou encore un service externe.

Un LLM seul ne peut pas tout faire

Un modèle de langage est très bon pour comprendre une demande et générer une réponse. Mais certaines informations ou actions se trouvent à l'extérieur du modèle.

Par exemple, si on lui demande :

Est-ce que je dois prendre une veste à Montréal ?

Pour répondre correctement, il peut avoir besoin d'une information externe : la météo actuelle. C'est là que les outils interviennent.

Un outil peut être une simple fonction

Prenons une fonction Python très simple :

def get_weather(city: str) -> str:
    return f"Il fait 24°C à {city}"

Dans un programme classique, c'est le développeur qui décide quand cette fonction doit être exécutée :

get_weather("Montréal")

Le programme suit donc une instruction déterministe. Avec un agent, la logique change : on donne simplement accès à la fonction au modèle.

@beta_tool
def get_weather(city: str) -> str:
    """Retourne la météo d'une ville."""
    return f"Il fait 24°C à {city}"

Puis on déclare cette fonction comme un outil disponible :

tools=[get_weather]

Le modèle peut alors décider s'il a besoin de l'utiliser.

Ce qui se passe réellement

Si l'utilisateur demande « Est-ce que je dois prendre une veste à Montréal ? », le flux ressemble à ceci :

Utilisateur
    ↓
Modèle
    ↓
"J'ai besoin de la météo"
    ↓
get_weather("Montréal")
    ↓
24°C
    ↓
Modèle
    ↓
Réponse finale

Le point important est que le développeur n'a pas directement écrit get_weather("Montréal"). Le modèle a choisi l'outil et les paramètres à utiliser en fonction de la demande. C'est ce qu'on appelle généralement le tool use ou tool calling.

Ce qu'est vraiment un tool

Un tool est une interface entre le modèle et le monde extérieur. Il peut permettre à un agent de :

• lire des informations ;
• rechercher des données ;
• appeler une API ;
• modifier un enregistrement ;
• envoyer un message ;
• exécuter une action.

On peut donc distinguer deux grandes catégories.

Outils de lecture

Ils permettent d'obtenir de l'information.

get_weather()
search_documents()
get_customer()
search_web()

Outils d'action

Ils permettent de modifier quelque chose dans un système externe.

send_email()
create_ticket()
update_customer()
book_appointment()

Cette distinction est importante, car un outil qui lit une donnée et un outil qui effectue une action n'ont pas les mêmes risques.

Tool use ne veut pas encore dire agent complet

Donner un outil à un modèle est une des briques fondamentales d'un système agentique. Mais un agent plus avancé peut faire davantage :

observer
    ↓
décider
    ↓
utiliser un outil
    ↓
observer le résultat
    ↓
ajuster son plan
    ↓
utiliser un autre outil
    ↓
terminer

Anthropic décrit par exemple les agents comme des systèmes capables de diriger leur propre processus et leur usage des outils, plutôt que de suivre uniquement un script fixe.

L'idée essentielle est donc la boucle : comprendre → décider → agir → observer → continuer.

Pourquoi les tools sont si importants

Sans outils, un modèle reste limité à ce qui se trouve dans son contexte et à ce qu'il peut générer. Avec des outils, il peut interagir avec des systèmes externes.

C'est ce qui permet de passer de :

« Voici comment réserver un rendez-vous. »

à :

« J'ai vérifié les disponibilités et créé le rendez-vous. »

La différence ne vient pas uniquement du modèle. Elle vient aussi des capacités que le système lui donne.

Ce qui change quand on passe en production

Tant qu'un agent a trois outils et un seul type d'utilisateur, tout va bien. Les problèmes arrivent quand le système grossit. Voici trois choses que j'ai apprises en opérant un assistant à trente-huit outils sur une plateforme logistique.

Un agent qui a accès à tout est un risque

Le réflexe est de déclarer tous les outils et de vérifier les permissions à l'exécution. Ça marche, mais le modèle voit l'outil, peut le proposer, tenter de l'appeler. Chaque tentative est une occasion de se tromper.

Plus sûr : ne charger que les outils qui concernent l'utilisateur en cours. Un partenaire terrain en reçoit quatre sur trente-huit ; les autres n'existent pas dans son contexte.

La restriction devient structurelle au lieu d'être vérifiée après coup.

Une action irréversible mérite une confirmation

C'est ici que la distinction entre lecture et action prend son sens. Se tromper sur une lecture coûte une requête ; se tromper sur une écriture crée un doublon ou modifie une commande.

Le principe : chaque outil déclare s'il exige une confirmation. Avant toute écriture, l'agent résume en langage clair ce qu'il s'apprête à faire et attend un accord. Ça ralentit d'une étape — c'est exactement le but.

Certaines données ne doivent jamais passer par le modèle

Un LLM reformule, c'est sa nature. Mais une coordonnée GPS, un montant ou un numéro de référence ne doivent pas être reformulés : une décimale déplacée sur une latitude, et le point est à deux kilomètres.

La solution ne relève pas du prompt. Il faut faire passer ces valeurs par un chemin déterministe, hors du modèle. L'agent orchestre ; la donnée sensible transite par du code ordinaire.

---