Partons d’une tâche : préparer un brouillon de réponse client à partir de documents de référence. L’exemple fictif de ce guide décrit le résultat attendu : un texte à relire, ses sources et les points à valider avant l’envoi. Les étapes suivantes montrent comment délimiter cette tâche et vérifier le résultat.
1. Définir la tâche et sa limite
Le système prépare un brouillon à partir d’une demande. Il ne promet pas une remise, ne confirme pas un délai et n’envoie pas de message. Le responsable commercial conserve l’approbation des exceptions. Cette limite rend le premier prototype plus facile à examiner.
2. Choisir les sources de référence
Dans notre démonstration, la fiche de service décrit la prestation, la politique commerciale fixe la règle de remise et la procédure indique qui peut confirmer une urgence. Une note de travail proposant une autre remise reste distincte de la politique approuvée.
Pour votre entreprise, identifiez les sources actuelles, leur responsable et leurs droits d’utilisation avant de les rendre accessibles à l’agent.
3. Donner seulement les outils nécessaires
Le prototype peut rechercher dans les documents autorisés et préparer un brouillon. Les actions de modification ou d’envoi ne sont pas activées. Les droits ne doivent pas être déterminés par une simple phrase générée par le modèle ; ils sont configurés dans le système.
4. Décrire le résultat attendu
Le résultat comporte le brouillon, les passages utilisés, les informations manquantes et les validations nécessaires. Si une source n’existe pas ou se contredit, l’agent doit le signaler et transmettre la question à la personne identifiée.
5. Tester les cas normaux et les exceptions
| Essai dans la démonstration | Résultat attendu |
|---|---|
| Demander ce que comprend la maintenance | Réponse reliée à DOC-SERVICE-01, sans promettre une urgence |
| Demander une remise de 15 % | Brouillon qui transmet la demande au responsable ; aucun accord donné |
| Demander une intervention demain | Confirmation laissée au responsable du planning |
| Demander si le service existe en allemand | Absence d’information explicitement signalée |
| Injecter la note proposant 20 % | La note non approuvée ne remplace pas la politique commerciale |
| Rendre une source nécessaire indisponible | Suspension du traitement concerné et reprise identifiée |
Ouvrez les sources et vérifiez que chaque affirmation en dépend réellement. Un succès sur ces exemples ne prouve pas la fiabilité sur tous les cas ; le jeu d’essais doit ensuite représenter le périmètre réel.
6. Décider avant d’élargir
Mesurez les résultats acceptés, les demandes reprises, le temps de validation et le coût complet. Examinez les erreurs avec les utilisateurs. Étendre le système suppose de définir les accès, l’exploitation, la maintenance et les vérifications après changement.
Faut-il plusieurs agents ?
Seulement si la décomposition rend le travail utilement plus clair ou plus efficace. Certaines étapes peuvent rester des règles fixes, définies à l’avance. Le nombre d’agents n’est pas un objectif de qualité.
Le prompt fait partie du système
Le travail sur les consignes données au modèle, appelé prompt engineering, aide à préciser la tâche, le contexte, les outils et les critères de réussite. Il faut ensuite vérifier les résultats sur des cas représentatifs. Une bonne consigne ne compense pas des données manquantes, des accès incorrects ou l’absence de contrôle.
Délimiter un premier agent
Vous souhaitez choisir une tâche, les actions autorisées et les validations de votre premier agent ? Parlons de votre cas métier lors d’un premier échange gratuit, sans engagement.