Ce qu’est vraiment un agent IA

Depuis quelques années, le mot « agent » est collé sur à peu près tout ce qui touche à un modèle de langage : un assistant qui rédige des e-mails, un robot de support, un script qui appelle une API. La confusion est entretenue par le marketing, et elle rend difficile une discussion sérieuse sur ce que ces systèmes peuvent faire, et sur ce qu’ils ne doivent pas faire.

Voici une définition de travail, volontairement sèche. Un agent est un programme qui répète une boucle : un modèle de langage décide de la prochaine action, un outil l’exécute, le résultat est remis au modèle, et on recommence jusqu’à ce que la tâche soit terminée ou qu’une limite soit atteinte. Tout le reste, la mémoire, la planification, les « équipes d’agents », est de l’organisation autour de cette boucle.

La différence avec un simple chatbot

Un chatbot reçoit une question et produit un texte. Il ne change rien au monde : si la réponse est fausse, l’utilisateur la lit, la corrige ou l’ignore. Un agent, lui, produit des actions : il lit un fichier, interroge une base de données, envoie une requête HTTP, modifie un brouillon. Le texte n’est plus le résultat final, c’est un moyen de choisir la prochaine action.

Cette nuance change la nature du risque. Une erreur de formulation dans un chatbot est une gêne. Une erreur d’action dans un agent peut supprimer un contenu, envoyer un message au mauvais destinataire ou lancer un traitement coûteux. C’est pourquoi la partie intéressante d’un agent n’est pas le modèle, mais ce qu’on a décidé de lui laisser faire.

Les quatre temps de la boucle

Chaque tour de boucle suit le même schéma, quel que soit le framework utilisé.

1. Observer. Le modèle reçoit un contexte : la consigne de départ, l’historique des actions précédentes et la liste des outils disponibles, chacun décrit par un nom, une explication et un schéma de paramètres.
2. Décider. Le modèle répond soit par un texte final, soit par une demande d’appel d’outil, avec des arguments structurés.
3. Agir. Le programme qui héberge l’agent, et non le modèle, exécute l’outil demandé. Le modèle ne fait que formuler la demande.
4. Vérifier. Le résultat de l’outil, y compris une erreur, est ajouté au contexte. Le programme décide s’il faut s’arrêter : tâche finie, nombre de tours dépassé, budget épuisé.

Ce découpage a une conséquence importante : le modèle n’a jamais de pouvoir direct. Il ne peut agir que par les outils que le programme a branchés, et seulement quand le programme accepte de les exécuter. Toute la sécurité d’un agent se joue dans cet espace entre la demande du modèle et l’exécution.

Le modèle propose, le programme dispose.

Les outils : des fonctions décrites avec soin

Un outil est une fonction ordinaire : « chercher dans les articles », « lire une page », « créer un brouillon ». Ce qui compte, c’est sa description. Le modèle ne voit pas le code, il ne voit que le nom, une phrase d’explication et la forme des paramètres. Un outil mal décrit est mal utilisé, comme une API mal documentée.

Quelques habitudes qui évitent bien des déconvenues :

• Peu d’outils, bien nommés. Plus la liste est longue, plus le modèle hésite ou se trompe d’outil.
• Des paramètres stricts. Un identifiant, une énumération, une date : le programme valide les arguments avant d’exécuter, comme il le ferait pour un formulaire public.
• Des résultats courts et lisibles. Renvoyer dix mille lignes de journal remplit le contexte et noie l’information utile.
• Des erreurs explicites. Un message qui dit ce qui a échoué et ce qu’il faudrait essayer aide le modèle à se corriger au tour suivant.

Le contexte tient lieu de mémoire

Un modèle ne se souvient de rien d’un appel à l’autre. Ce que l’on appelle la mémoire d’un agent est simplement le texte qu’on lui renvoie à chaque tour. Ce texte est borné par la taille de la fenêtre de contexte, et plus il est long, plus le coût et le temps de réponse augmentent.

On gère donc le contexte comme une ressource : on résume les étapes anciennes, on garde les faits utiles dans un stockage externe que l’agent interroge au besoin, et on évite d’y déverser des documents entiers. Un agent qui « oublie » ce qu’il a fait il y a vingt tours n’est pas bogué, il a simplement perdu ces lignes de son contexte.

Permissions : ce qu’un agent a le droit de faire

La règle de base est celle du moindre privilège, appliquée à un nouvel acteur qu’on ne comprend pas parfaitement. Un agent n’a pas à hériter des droits de la personne qui le lance. Il reçoit un jeu de permissions explicite, plus étroit, et le programme vérifie chaque appel avant de l’exécuter.

Deux points méritent d’être posés dès la conception. D’abord, la vérification se fait dans le programme hôte, pas dans l’outil et encore moins dans la consigne : écrire « ne supprime jamais rien » dans un prompt n’est pas une permission, c’est un souhait. Ensuite, on sépare les outils de lecture, sans conséquence, des outils d’écriture, dont chacun doit être justifié.

Les garde-fous qui font la différence

Un agent fiable en production n’est pas celui dont le modèle est le plus brillant, c’est celui dont les limites sont les mieux tenues. Voici ce qu’on retrouve dans les systèmes qui tiennent dans la durée.

• Un plafond de tours, de durée et de coût. Une boucle qui ne s’arrête jamais finit toujours par arriver, souvent un vendredi soir.
• Un journal de chaque action, avec les arguments, le résultat et l’identité de l’agent, pour comprendre après coup ce qui s’est passé.
• La possibilité d’annuler. Un outil qui modifie quelque chose devrait savoir défaire sa modification, ou être clairement marqué comme irréversible.
• Une validation humaine pour les effets de bord sérieux. Publier, supprimer, dépenser, écrire à un tiers : l’agent prépare, une personne confirme.
• Des niveaux d’autonomie explicites. Rapporter seulement, proposer, ou agir : le niveau est un réglage choisi par un humain, pas une propriété du modèle.

C’est le choix que j’ai fait dans Cogenta, le CMS que je développe : les agents y passent par les mêmes outils, déclarés avec leurs permissions, que n’importe quelle autre intégration, et ceux qui ont un effet de bord sont journalisés et réversibles. Ce n’est pas une originalité, c’est de l’hygiène.

Pourquoi ça échoue, concrètement

Les pannes d’agents ont des causes banales. Une erreur d’interprétation à la deuxième étape se propage aux suivantes : sur une longue chaîne, même un taux d’erreur faible par étape finit par donner un résultat peu fiable. Un résultat d’outil ambigu est lu de travers. Le contexte se remplit de bruit et le modèle perd le fil. Ou bien, plus sournois, l’agent réussit techniquement une tâche qui n’était pas celle qu’on voulait, faute d’une consigne assez précise sur le résultat attendu.

La parade n’est pas un modèle plus gros, ou pas seulement. C’est de raccourcir les chaînes, de vérifier les résultats par du code plutôt que par le même modèle, et de prévoir un arrêt propre quand quelque chose sort du cadre.

Quand un agent est le bon outil

Si les étapes d’une tâche sont connues d’avance, un enchaînement classique, éventuellement avec un appel au modèle à un endroit précis, est presque toujours plus simple, plus rapide et plus prévisible. On gagne à laisser un modèle choisir son chemin quand le chemin dépend de ce qu’on découvre en route : enquêter sur une anomalie, rassembler des informations dispersées, corriger un problème dont on ne connaît pas la cause.

La question utile n’est donc pas « est-ce qu’on peut en faire un agent ? » mais « qu’est-ce qu’on gagne à laisser le modèle décider, et qu’est-ce qu’on risque ? ». Si la réponse à la seconde partie est « pas grand-chose, et tout est réversible », on peut y aller. Sinon, on commence par un assistant qui propose, et on regarde ce qu’il propose pendant quelques semaines avant de lui confier quoi que ce soit.