Avant de chercher le meilleur agent, définir la tâche, les actions autorisées, les critères de réussite et le point d’arrêt.
La démonstration est souvent séduisante : l’agent comprend une demande, choisit un outil, récupère une information et termine le travail. La question qui suit devrait être très terre à terre : avec quelle identité a-t-il agi, et jusqu’où pouvait-il aller ?
Une décision d’architecture
Dans Building effective agents, Anthropic distingue les enchaînements définis dans le code des agents qui déterminent eux-mêmes une partie de leur chemin. Son conseil de départ reste utile : commencer avec une solution simple, puis ajouter de la complexité lorsque le besoin le justifie. L’article date de décembre 2024 ; il sert ici de cadre architectural, pas de catalogue des outils actuels.
Ce choix change la manière de vérifier le résultat. Pour une chaîne connue, on contrôle chaque étape. Pour un agent plus autonome, on doit aussi observer les chemins qu’il peut emprunter, les erreurs qui s’accumulent et les conditions dans lesquelles il s’arrête.
Le risque des droits disponibles
L’OWASP décrit l’excès d’autonomie opérationnelle à travers trois dimensions : trop de fonctions, trop de permissions ou trop de liberté d’action. Une erreur du modèle devient dommageable à la mesure des capacités du système auquel il est connecté. Restreindre les outils et les droits, puis encadrer les actions sensibles, limite cette portée.
Ma lecture : rédiger un contrat d’action
Je traiterais le périmètre d’un agent comme un contrat d’action. Prenons un assistant chargé de préparer une réponse à une demande technique : lire les documents utiles, produire un brouillon et transmettre ce brouillon à un agent humain constituent déjà un service complet. L’accès en écriture à tout le système documentaire ne découle pas automatiquement de cette mission.
Ce contrat doit répondre à quatre questions :
- Que peut-il consulter ? Des sources et des périmètres explicitement identifiés.
- Que peut-il modifier ? Des opérations nommées, avec des paramètres contrôlés.
- Quand doit-il s’arrêter ? Lorsqu’une information manque, qu’un plafond est atteint ou qu’une action dépasse son mandat.
- Comment vérifie-t-on son travail ? Avec des critères observables, pas seulement une réponse qui paraît convaincante.
Ce cadre rend aussi le projet plus facile à expliquer aux métiers. La discussion porte sur un service précis, sur ce qu’il permet et sur la façon de reprendre la main. C’est une base beaucoup plus solide pour décider d’un passage en production.
Lire la version en mots simples
Une IA qui rédige un texte peut se tromper dans sa réponse. Une IA qui a aussi le droit d’envoyer des messages ou de modifier des fichiers peut transformer cette erreur en action réelle. C’est cette différence qui m’intéresse ici.
Qu’appelle-t-on un agent IA ?
Dans ce contexte, un agent est un programme qui s’appuie sur une IA pour choisir une partie des étapes de son travail et utiliser des outils. Il peut, par exemple, chercher un document, en tirer une information puis préparer une réponse. Le chemin est moins figé que dans une suite d’étapes entièrement prévue à l’avance.
L’article d’Anthropic cité en bas de page propose de commencer simplement. Il date de décembre 2024 : je l’utilise pour réfléchir à la conception du service, pas pour comparer les produits du moment.
Les outils sont aussi des clés
Imaginons qu’un assistant doive préparer un courrier. Il a besoin de lire certains documents et de rédiger un brouillon. Cela ne lui donne pas automatiquement besoin d’effacer les dossiers, de modifier tous les fichiers ou d’envoyer le courrier lui-même.
Les recommandations de l’OWASP invitent à limiter les fonctions accessibles, les autorisations et la liberté d’action. L’idée peut se dire simplement : ne confions que les clés nécessaires au travail demandé.
Écrire une mission compréhensible
- Ce qu’il peut lire : quels documents et quelles informations sont utiles ?
- Ce qu’il peut faire : préparer un brouillon, enregistrer un fichier, envoyer un message ? Chaque action est un choix distinct.
- Quand il doit demander de l’aide : information manquante, doute ou action qui dépasse la mission.
- Comment son travail sera vérifié : qui relit, avec quels critères et quelles possibilités de correction ?
Ces questions ne demandent pas de savoir programmer. Elles permettent aux utilisateurs et aux équipes techniques de se mettre d’accord sur le service attendu. Une démonstration impressionnante devient alors une proposition que l’on peut réellement examiner.