Ce qu’un agent apporte de plus qu’un assistant
Un assistant conversationnel répond. Un agent agit : il consulte votre base, appelle un service externe, produit un document, met à jour un enregistrement — puis vérifie que le résultat correspond à l’objectif.
Cette autonomie est utile quand la tâche demande plusieurs étapes dont l’ordre dépend du contexte. Vérifier la disponibilité d’un produit, calculer un délai, consulter l’historique client puis formuler une réponse est un enchaînement qu’un agent gère mieux qu’une suite de règles figées.
Les outils comptent plus que le modèle
La qualité d’un agent dépend d’abord de la qualité des fonctions qu’il peut appeler. Un outil dont la description est ambiguë, qui renvoie des erreurs peu explicites ou qui accepte des paramètres trop libres produit un agent erratique — quel que soit le modèle.
Nous consacrons donc l’essentiel du développement aux outils : périmètre étroit, description sans ambiguïté, validation stricte des paramètres, messages d’erreur exploitables et tests unitaires. C’est le travail d’ingénierie classique qui fait la différence, pas le réglage des instructions.
Trois garde-fous non négociables
Le périmètre est technique. Ce que l’agent ne doit pas faire, il ne peut pas le faire : le contrôle est dans le code des outils, jamais confié à une consigne rédigée.
Les limites sont dures. Nombre d’étapes, budget de jetons, délai. Un agent qui dépasse s’arrête et transmet.
Tout est journalisé. Chaque raisonnement, chaque appel d’outil, chaque résultat. Sans cette trace, un incident est impossible à analyser et l’amélioration devient impossible.
