Déployer son premier agent en production

Le premier agent d’une équipe compte plus que les suivants : s’il rend service, les autres suivront ; s’il déçoit, il faudra des mois pour regagner la confiance. Voici la démarche que nous recommandons, étape par étape, pour passer d’une idée à un agent qui tourne en production, sous contrôle.

Choisir un premier usage étroit

Le bon premier usage n’est pas le plus ambitieux, c’est celui où l’agent peut réussir vite et où ses erreurs se rattrapent facilement. Il coche la plupart de ces cases :

• Une tâche répétitive, faite souvent, par plusieurs personnes.
• Un processus déjà décrit quelque part : une procédure, un modèle, des exemples.
• Un résultat que l’on sait vérifier d’un coup d’œil.
• Une erreur qui se rattrape avant d’avoir des conséquences.
• Une équipe demandeuse, prête à relire les premiers résultats.

Le tri des tickets entrants, la préparation de réponses types, la synthèse de comptes rendus ou la saisie de factures sont de bons candidats. Une décision qui engage l’entreprise, comme un prix ou un recrutement, ne l’est pas.

Décrire l’agent

Décrivez l’agent comme vous le feriez pour un nouveau collègue : son objectif, ce qui le déclenche, les actions qu’il peut faire et le résultat attendu. Dans Scalt, l’Agent Builder part de cette description pour proposer une première version : il compose les compétences nécessaires, détecte les outils à brancher et planifie les tâches. Une bonne description tient en quelques phrases ; si elle en demande dix, l’usage est probablement trop large.

« Quand un ticket arrive dans la file support, lis-le, retrouve le client et ses tickets précédents, classe la demande selon notre grille, propose une réponse à partir de la base de connaissances, et laisse-la en brouillon pour validation. »

Choisir les sources et les outils

Branchez le minimum : une ou deux sources, celles où se trouve vraiment l’information utile. Chaque source garde ses droits d’accès, et l’agent ne lit que ce que son utilisateur peut lire. Pour les outils, commencez par la lecture ; n’ouvrez l’écriture, comme envoyer un message ou modifier une fiche, qu’action par action, une fois les validations définies.

Tester à blanc

Avant tout déploiement, discutez avec l’agent et faites-lui appeler ses outils en bac à sable. Puis rejouez à la main quelques cas réels déjà traités par l’équipe, et comparez : ce que l’agent aurait fait, ce que l’équipe a fait. Les écarts disent quoi corriger dans les instructions ou les sources. Recommencez jusqu’à ce que les écarts restants soient acceptables.

Définir les validations et les limites

Écrivez noir sur blanc ce que l’agent a le droit de faire. Dans Scalt, chaque agent est packagé en application avec ses règles d’approbation, ses objectifs de délai, un plafond de dépense quotidien et une plage horaire d’activité. Au-dessus, un profil de gouvernance fixe les modèles autorisés, les outils permis, les approbations obligatoires et les plafonds communs à plusieurs agents.

Publier, versionner, revenir en arrière

Un agent se publie comme du logiciel : une version, un déclencheur, des règles. Il peut être appelé depuis le chat, une commande Slack, une tâche planifiée, un webhook ou une API. Chaque exécution garde la version d’agent qui l’a produite ; si une nouvelle version déçoit, vous revenez à la précédente.

Superviser les débuts

Les premières semaines, relisez les dossiers de l’agent, pas seulement ceux qui échouent. L’Inbox rassemble ce qui attend une validation et ce qui a échoué ; chaque dossier montre les étapes, les sources lues et les décisions. Élargissez le périmètre quand l’équipe valide sans corriger, pas avant.

Mesurer honnêtement

Mesurez ce que l’agent fait réellement : les tâches menées au bout, la part des résultats validés sans modification, les erreurs arrêtées à la validation, le coût par exécution. Méfiez-vous des indicateurs flatteurs, comme le nombre de conversations ou d’agents créés : ils disent que l’outil est utilisé, pas qu’il est utile.

Et après le premier agent ?

Ce que le premier agent vous a appris se réutilise. Les instructions qui marchent deviennent une compétence, avec ses outils et son format de sortie, installable sur d’autres agents. Les applications, compétences et outils éprouvés se publient dans la Factory de votre organisation, où les autres équipes les installent au lieu de repartir de zéro. Le deuxième agent se construit alors plus vite, et sur des bases déjà vérifiées.

La checklist

1. Un usage étroit, choisi avec l’équipe qui s’en servira.
2. Une description de quelques phrases : objectif, déclencheur, actions, résultat.
3. Une ou deux sources, avec leurs droits d’accès vérifiés.
4. Des outils en lecture d’abord ; l’écriture ouverte action par action.
5. Un test à blanc sur des cas réels déjà traités, écarts corrigés.
6. Les validations obligatoires écrites pour chaque action qui engage.
7. Un plafond de dépense et une plage horaire d’activité.
8. Une version publiée, et la possibilité de revenir à la précédente.
9. Une personne qui relit les dossiers pendant les premières semaines.
10. Des indicateurs d’utilité, pas seulement d’usage.