--- title: "Offrez aux agents un outil pour vous envoyer des retours" description: "Les agents utilisent actuellement votre MCP et rencontrent des frictions dont vous n'avez pas connaissance. Un outil supplémentaire leur permet de vous signaler ce qui a échoué, ce qu'ils attendaient, ainsi que le modèle et le harnais utilisés. Voici le format que j'utilise et un rapport réel que j'ai reçu." date: 2026-09-17 language: fr canonical: https://gduv.club/fr/articles/agent-feedback-tool source: gduv.club --- Si vous déployez un serveur MCP, la plupart des utilisateurs ne sont pas des humains. Un agent lit les descriptions de vos outils, en choisit un, envoie une charge utile, reçoit un résultat et décide de la suite. Toute cette boucle s’effectue sans que personne ne la surveille. Par conséquent, quand un problème survient, personne ne vous prévient. L’agent réessaie, contourne le problème ou abandonne en informant l’utilisateur que la tâche est impossible. Vous ne voyez rien de tout cela. La solution est simple : ajoutez un outil supplémentaire à votre MCP et laissez l’agent vous signaler le problème. ## Un seul outil, et une description précisant quand l’utiliser Cet outil n’agit pas sur le produit. Il récupère la description de ce qui a échoué et vous la transmet. Son efficacité repose sur la description lue par l’agent, car c’est sa seule instruction. Voici celle que j’utilise sur [AI Glot](https://ai-glot.com/docs/mcp/standard-tools) : ```text Utilisez cet outil lors de l’utilisation d’AI Glot lorsqu’un outil, une réponse, une erreur ou un flux de travail d’AI Glot se comporte différemment de ce que vous attendiez, ou lorsque vous souhaiteriez qu’une fonctionnalité operate différemment. Appelez-le une fois le problème clairement identifié. Décrivez la situation, ce que vous avez observé et ce qui aurait dû se produire. Si vous les connaissez, incluez l’outil concerné, l’opération API ou la commande CLI, le modèle d’IA et l’interface de l’agent. N’incluez pas de clés API, de jetons, d’URLs signées ou le contenu complet de fichiers. Cet outil enregistre uniquement les retours, ne relance pas et ne modifie pas votre traduction, et ne coûte aucun crédit. ``` Trois éléments sont ici cruciaux. « Une fois le problème clairement identifié » évite qu’il ne se déclenche à la première erreur passagère. « Ne relance pas » empêche l’agent de s’en servir comme étape de récupération après l’échec d’un appel. « Ne coûte aucun crédit » est important car les agents sont prudents avec tout ce qui pourrait dépenser l’argent de l’utilisateur, et un outil dont ils ne sont pas sûrs est un outil qu’ils n’appellent pas. 1. **L'agent rencontre un problème**. Un rejet, une surprise, un outil manquant 2. **Il appelle l'outil de feedback**. Tout en conservant l'intégralité du contexte 3. **Votre serveur ajoute ses données**. Espace de travail, surface, horodatage 4. **Le rapport arrive où vous voulez**. Un webhook, et voilà votre problème _L’agent est déjà en situation d’échec lorsqu’il appelle cet outil. Rien n’a besoin d’être reconstruit a posteriori, ce qui rend le rapport précieux._ ## Les champs C’est là que se trouve la valeur ajoutée. Un champ de texte libre vous donnera un « ça n’a pas marché ». Des champs nommés vous donnent des informations exploitables. Voici ce que demande [l’outil d’AI Glot](https://ai-glot.com/docs/mcp/standard-tools), avec les trois champs obligatoires en premier : **Six champs : problème observé, situation et solution attendue sont obligatoires ; action liée, modèle d’IA et interface de l’agent sont optionnels.**
observed_problem Ce qui a échoué, a été confus ou devrait fonctionner différemment
situation Ce que l’agent essayait de faire et le contexte autour du problème
expected_solution Ce qui était attendu à la place, ou comment améliorer cela
related_action L’outil, le point de terminaison ou la commande concernée
ai_model Si connu. Ne pas deviner
agent_harness Claude Desktop, Cursor, un CLI
`expected_solution` est le champ que je garderais si je ne pouvais en avoir qu’un. Un utilisateur vous dit que quelque chose est cassé. Un agent vous dit ce qu’il pensait que l’appel allait faire, ce qui permet de savoir immédiatement si la description de votre outil correspond à sa fonction réelle. Les trois champs optionnels existent car « ne pas deviner » est une instruction réelle qu’un agent suivra. Je préfère un champ vide qu’un champ rempli avec un nom de modèle plausible. Lorsqu’ils sont remplis, vous pouvez trier par modèle et par interface, et un problème qui ne survient que sur l’un d’eux cesse de paraître aléatoire. **Ne demandez pas à l’agent ce que vous savez déjà** L’espace de travail, l’identifiant, la surface, l’horodatage et l’ID de feedback sont ajoutés par mon serveur, pas par l’agent. Tout ce que l’agent pourrait mal rapporter ou inventer doit être retiré de ses mains. Cela permet aussi de garder l’appel de l’outil peu coûteux, ce qui fait la différence entre un outil utilisé et un outil ignoré. ## À quoi ressemble un rapport réel En voici un vrai, tel qu’il m’est parvenu le 10 septembre : _Personne n’aurait signalé cela. L’exécution s’est terminée, la traduction a eu lieu et la solution de contournement n’a nécessité qu’un appel supplémentaire. C’est exactement le genre de friction qui ne vous parvient jamais._ C’est un rapport de bug avec une reproduction, un diagnostic et une proposition de correction, écrit par l’entité qui a rencontré le problème, quelques secondes après l’événement. Je ne l’ai pas demandé et je ne l’ai pas payé. ## Pourquoi c’est mieux que les retours habituels Je ne dis pas que les agents remplacent les utilisateurs. Je dis que ce canal particulier a des propriétés que les retours utilisateurs n’ont pas. **Un utilisateur vous informe** (Heures ou jours plus tard) - Rappelé, et partiellement reconstruit - Filtré par ce qu’ils jugent utile de rapporter - Atténué, car se plaindre semble impoli - Précise rarement ce qui était attendu - Provient seulement des rares personnes qui prennent le temps **L'agent vous informe** (Quelques secondes plus tard) - Écrit pendant que tout le contexte est encore chargé - Aucun jugement sur la pertinence du signalement - Indique ce qu’il attendait, car c’est le champ demandé - Nomme l’appel, le modèle et l’interface exacts - Provient de chaque exécution rencontrant le problème _Les deux sont utiles. La colonne de droite est celle que vous n’avez actuellement aucun moyen de collecter._ L’aspect impartial est ce qui me frappe le plus. Un agent n’a pas de relation à protéger avec vous et ne craint pas de paraître exigeant. Il a lu votre description, a formé une attente, et l’attente n’a pas correspondu à la réalité. Cet écart constitue l’intégralité du rapport, et c’est la revue de documentation la plus honnête que vous puissiez obtenir. ## Où vont les rapports Les miens sont envoyés via POST à un webhook et arrivent dans un canal que je lis. C’est toute l’installation, et c’était suffisant pour être rentable. Vous pouvez aller plus loin, et les options deviennent intéressantes une fois les rapports structurés : - **Les stocker** et les grouper par `related_action`. Trois rapports sur le même outil constituent une spécification, pas une anecdote. - **Être notifié sur les points critiques**, filtrés selon vos priorités : un outil, un modèle, une interface. - **Placer un agent sur la file d’attente** pour dédoublonner, prioriser et rédiger une proposition de correction pour votre repo. Les rapports contiennent déjà une reproduction et un comportement attendu, soit l’essentiel pour un correctif. - **L’exécuter en pilote automatique**, si vous faites assez confiance à vos tests. Ce n’est pas encore mon cas. Rien de tout cela n’est requis. Le webhook seul change votre perception de votre propre produit. ## Deux règles à ne pas ignorer **Cela ne doit jamais casser la conversation qui l’a appelé.** Si votre webhook est hors service, l’outil doit renvoyer un simple « ceci n’a pas pu être livré, rien d’autre à faire », et non une erreur. Un agent qui reçoit une exception d’un outil de feedback commencera à traiter l’échec comme faisant partie de la tâche en cours. Le mien a également un timeout court pour la même raison : un webhook suspendu bloque le tour de l’agent. **Précisez ce qu’il ne faut pas envoyer.** Les agents sont serviables, et une demande de contexte vous rapportera sinon des clés API, des URLs signées et des contenus de fichiers. Les nommer dans la description suffit, et cela signifie que vous ne stockez pas de données dont vous ne vouliez jamais. **Une version simplifiée convient parfaitement** Sur mon framework de documentation, l’outil est `report_issue` et prend trois champs : la page, le problème et un type optionnel parmi quatre. Le serveur ajoute l’URL de la page, le nom du produit de l’agent, la version du site et l’horodatage. Cela a pris un après-midi. ## Essayez-le sur votre propre MCP Si vous déployez déjà un serveur MCP, il s’agit d’un seul outil, d’un webhook et d’une description que vous réécrirez deux fois. Le premier rapport qui arrivera vous révélera quelque chose sur votre produit que vous ignoriez, et cela concernera un outil que vous pensiez être correct. Les agents sont désormais vos utilisateurs. Donnez-leur un endroit pour se plaindre. ## Sources - [Mon post original sur l’idée](https://www.linkedin.com/posts/guillaume-duvernay_idea-give-your-users-claude-code-a-tool-activity-7503753518369980416-g46b) - [Max Tkacz m’a filmé en train de l’expliquer](https://www.linkedin.com/posts/maxtkacz_mcp-llm-kewl-ugcPost-7506271906975686657-sq8X) - [Model Context Protocol : spécification des outils](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)