Prototype en préparation · données fictives
Agent avec outils autorisés
Un agent qui reçoit une demande, consulte une source autorisée, utilise un outil métier, vérifie son résultat et attend une validation humaine avant toute action sensible. À construire et à tester avant d’être publié comme réalisation.
En préparation
État : prototype à construire, non publié comme réalisation. Cette page sera mise à jour quand les tests auront été réalisés. Tant que ce n’est pas le cas, aucune capacité décrite ici n’est présentée comme acquise en production.
01 · Pourquoi
Montrer, pas affirmer
Aucune réalisation publiée ne montre encore un agent qui appelle des outils de bout en bout. Plutôt que de l’affirmer, nous le construisons séparément, sur des données fictives, et nous publierons ce qui aura été réellement testé.
02 · Le cas
Le cas choisi
Une demande de devis arrive par e-mail, en texte libre. L’agent doit retrouver le client, préparer un brouillon de devis dans un outil de facturation factice, vérifier le montant et le client, puis demander la validation d’une personne avant tout envoi.
Ce parcours est illustré en vidéo sur la page Services, sur un scénario fictif ; le prototype devra le reproduire réellement. Voir la démonstration
03 · Architecture
La boucle de l’agent
- Demandee-mail fictif
- Contextesource autorisée, lecture seule
- OutilAPI factice, brouillons
- Vérificationclient, montant, champs
- Validationune personne
- Journal
AgentAPIMCP si l’outil le permetRègles de vérificationValidation humaineJournal
04 · Déroulé prévu
Étape par étape
01
Réception
Un e-mail fictif, en texte libre, avec ou sans pièce jointe.
02
Contexte
Recherche du client et de son historique dans une source autorisée (base fictive), en lecture seule.
03
Outil
Appel d’une API de facturation factice pour créer un brouillon. Permission limitée à la création de brouillons : aucun envoi possible.
04
Vérification
Le résultat renvoyé est contrôlé : client existant, montant sous un plafond, champs obligatoires présents.
05
Reprise
Un appel qui échoue est réessayé une fois, puis signalé. Une vérification qui échoue arrête l’agent, qui explique pourquoi.
06
Validation
L’envoi du devis attend une personne. L’agent présente ce qu’il a fait, ce qu’il propose et ce qu’il n’a pas pu faire.
07
Journal
Chaque étape, chaque appel d’outil et chaque erreur sont enregistrés avec leur résultat, lisibles par quelqu’un qui n’a pas suivi l’exécution.
05 · Tests
Ce qui sera testé avant publication
- Un jeu de demandes de référence (claires, incomplètes, hors périmètre, ambiguës) et le comportement attendu pour chacune.
- Les permissions : l’agent ne peut pas appeler un outil absent de sa liste, ni envoyer quoi que ce soit.
- Les échecs provoqués : outil indisponible, réponse incohérente, montant au-dessus du plafond.
- La lisibilité du journal par une personne qui n’a pas suivi l’exécution.
06 · Publication
Ce qui sera publié
- Le schéma d’architecture et la liste des outils autorisés.
- Les résultats des tests sur le jeu de référence, réussites et échecs compris.
- Des extraits du journal, sur données fictives.
- Les limites constatées.