Insights — Agents et outils
Un agent utile n'est pas un agent libre.
La différence entre un agent qui travaille pour vous et un gadget qui impressionne tient rarement au modèle choisi. Elle tient à ce qu'on lui a donné le droit de faire, aux outils qu'on a mis dans sa boîte, et à ce qu'on garde sous contrôle humain. Voici notre doctrine de conception.
01 — Le constat
Un agent sans cadre prend des initiatives coûteuses — et parfois irréversibles.
Un agent branché sur vos outils avec un accès large finit toujours par faire une action que personne n'a validée : envoyer un courriel à un client, modifier une fiche, supprimer un fichier, déclencher un paiement. Ce n'est pas une question de qualité du modèle, c'est une question de périmètre.
Nous partons donc du principe inverse de la démonstration : on commence par écrire ce que l'agent n'a pas le droit de faire, et on n'élargit qu'après avoir observé son comportement réel en production surveillée.
01Borner les outils, pas seulement les instructions
Dire à un agent « ne supprime rien » dans son invite de départ ne protège de rien : un modèle n'est pas un mécanisme de sécurité. La seule borne qui tient est technique.
Chaque outil exposé à un agent est donc une fonction étroite, avec ses propres contrôles de droits : lecture d'un dossier documentaire, lecture d'une commande client, création d'un brouillon de courriel. Jamais un accès générique à une base entière, jamais un accès en écriture qui contourne les règles de l'application.
- Un outil = une action precise, avec ses controles de droits
- Aucun acces direct a la base : l'agent passe par les API metier
- Les identifiants sont ceux de l'utilisateur, jamais ceux d'un compte administrateur
- Separation stricte entre lecture et ecriture
02Trois niveaux de validation
Toutes les actions ne se valent pas. Nous classons chaque capacité de l'agent selon son risque, et le niveau de contrôle suit.
- Automatique : lecture, recherche, calcul, préparation de brouillon — sans effet sur le monde réel
- Confirmation simple : écriture dans un outil interne, envoi à un collègue — l'utilisateur voit et valide
- Double validation : engagement client, écriture comptable, suppression, envoi externe — validation par un second rôle, tracée
03Journaliser, parce qu'un agent doit pouvoir s'expliquer
Chaque exécution enregistre la question posée, les outils appelés, les données renvoyées, la décision prise et le coût consommé. Sans ce journal, un incident devient une enquête impossible et une réclamation client devient indéfendable.
Ce journal sert aussi à améliorer : on y voit les demandes mal comprises, les outils inutiles, les étapes que l'agent rate systématiquement. C'est le matériau de la mise au point, et il est propre à votre métier.
04Le cas d'usage qui justifie un agent — et ceux qui ne le justifient pas
Un agent se justifie quand la tâche demande plusieurs étapes, plusieurs sources et une décision intermédiaire : préparer un dossier technique à partir de pièces éparses, qualifier une demande entrante, rapprocher une commande et une facture, surveiller un indicateur et alerter.
Il ne se justifie pas pour ce qu'une règle simple fait mieux et moins cher. Un envoi automatique, un calcul, un tri : une automatisation classique est plus rapide, plus prévisible et gratuite à l'usage. Nous le disons à nos clients, même quand cela réduit le projet.
- Decider d'un agent : plusieurs etapes, plusieurs sources, une decision intermediaire
- Decider d'une automatisation : une regle stable, un declencheur clair, aucun jugement
- Ne rien automatiser : ce qui engage une personne ou une relation sans controle possible
L'architecture d'un agent encadré : sources, recherche, outils bornés, journal d'exécution et validation au bon niveau.
02 — Questions courantes
Ce qu'on nous demande avant de brancher un agent
L'agent peut-il agir sans que personne ne valide ?
Seulement sur les actions sans effet réel : lire, chercher, préparer un brouillon, calculer. Toute écriture ou tout envoi externe passe par une validation, et les actions à fort impact demandent une seconde validation tracée. Ce n'est pas un réglage optionnel : c'est la condition de mise en production.
Nos données sensibles peuvent-elles fuir par les outils ?
Chaque outil ne voit que ce que l'utilisateur qui pose la question a lui-même le droit de voir. Un agent lancé par un commercial ne peut pas lire un dossier RH réservé. Les accès sont vérifiés à chaque appel, pas au moment de la connexion.
Combien de temps pour un premier agent en production ?
Quatre à huit semaines pour un périmètre fermé et un outil métier, tests compris. Le temps est passé sur les règles, les droits et le jeu d'évaluation, pas sur le modèle : c'est ce qui fait la différence entre un prototype et un agent que vos équipes utilisent réellement.
Vous avez un cas d'usage d'agent en tête ?
Décrivez la tâche et les outils concernés : nous vous dirons si un agent se justifie, quel périmètre lui donner et ce qui doit rester sous contrôle humain.