Construire un agent : outils, boucle, garde-fous

Un chatbot répond. Un agent agit : il consulte des systèmes, exécute des actions, enchaîne des étapes vers un objectif. Techniquement, la brique de base est simple ; ce qui sépare un agent utile d'un agent dangereux, ce sont les garde-fous.

La brique de base : l'appel d'outil (function calling)

Vous déclarez au modèle une liste d'outils (« chercher_commande(numéro) », « envoyer_email(destinataire, texte) »). Face à une demande, le modèle ne répond plus seulement en texte : il produit un appel structuré, « chercher_commande(4812) ». Votre code exécute réellement la fonction, renvoie le résultat au modèle, qui décide de la suite. Point crucial : le modèle propose, votre code dispose. C'est votre programme qui exécute, valide, filtre.

La boucle agentique

Un agent, c'est cette brique dans une boucle : observer la situation, décider d'une action, l'exécuter, observer le résultat, recommencer jusqu'à l'objectif (ou l'échec). Des standards comme MCP permettent de brancher des outils (bases de données, messageries, navigateurs) sans réécrire une intégration par fournisseur.

Les règles de conception qui évitent les catastrophes

• Moindre privilège. L'agent n'a accès qu'aux outils strictement nécessaires à sa mission. Lecture seule par défaut.
• Confirmation humaine pour tout ce qui est irréversible ou engageant : envoyer, payer, supprimer, publier. L'agent prépare, l'humain valide.
• Budgets et limites. Nombre d'étapes maximal, plafond de dépense, timeout : une boucle qui déraille doit s'arrêter seule.
• Journal complet. Chaque action est tracée : qui, quoi, quand, pourquoi. Sans logs, impossible d'auditer un incident.

Et surtout : avez-vous vraiment besoin d'un agent ?

Si les étapes de votre tâche sont connues d'avance (extraire, classer, notifier), un workflow classique qui appelle le modèle à des étapes fixes est plus fiable, moins cher et plus facile à déboguer. Réservez l'agent aux cas où le chemin est imprévisible et dépend de ce qu'on découvre en route.