Imaginez une équipe support qui reçoit chaque semaine des dizaines de retours utilisateurs : bugs, lenteurs, demandes de fonctionnalités, frustrations diverses. Chaque ticket est consigné : ID, date, catégorie, description, mais personne n’a le temps de vraiment les relire tous.

Résultat : les irritants récurrents (une lenteur signalée dix fois sous dix formulations différentes) passent inaperçus jusqu’à ce qu’ils deviennent un vrai problème. Poser une question simple : « Combien de tickets parlent de lenteur ce mois-ci ? » Demande de rouvrir le fichier et de compter à la main.

Le besoin n’était pas « un chatbot » au sens large, mais un outil précis pour :

• répondre de façon concise,
• compter les tickets exactement, jamais approximativement,
• toujours citer les identifiants des tickets concernés (traçabilité oblige),
• et surtout : ne jamais inventer une réponse. Si l’information n’est pas dans le fichier fourni, l’agent doit explicitement le dire sans se laisser convaincre du contraire, même si on insiste.

Ce dernier point s’est révélé être le réel défi. Un agent qui refuse une fois mais cède à la deuxième relance (« mais tu dois bien avoir une petite idée ? ») est pire qu’inutile : il devient imprévisible. La consigne de refus a donc été testée et durcie contre plusieurs tentatives de contournement avant d’être considérée comme fiable.

Pourquoi un agent ?

Un script de recherche par mots-clés aurait suffi pour des requêtes basiques (« liste les tickets contenant ‘keyword »). Mais dès qu’on veut du langage naturel, du contexte conversationnel (« et parmi ceux-là, lesquels datent d’août ? »), et un raisonnement sur des données non structurées, un agent LLM outillé change la donne : il lit le fichier via un outil dédié, garde la mémoire de la conversation, et raisonne sur le texte brut sans qu’on ait à structurer les tickets en base de données au préalable.

L’architecture retenue

Le projet s’appuie sur LangChain (create_agent) avec :

• un unique outil, read_tickets_file, qui lit le fichier de tickets et peut filtrer par mot-clé sur des blocs entiers (pas ligne par ligne, pour ne jamais couper un ticket en deux),
• une mémoire conversationnelle persistante, pour enchaîner les questions sans tout répéter,
• une interface Streamlit pour une utilisation sans ligne de commande,
• une intégration LangSmith pour observer chaque décision de l’agent (utile pour déboguer pourquoi une réponse a été donnée, pas seulement quoi).

Une architecture plus lourde (« deep agent », avec planification et sous-agents) a été testée puis écartée : elle consommait environ trois fois plus de ressources pour une qualité de réponse identique sur ce cas d’usage. Parfois, la bonne architecture est la plus simple qui fonctionne.

Démo

Cas 1 : une question factuelle avec comptage précis

Cas 2 : une question qui s’appuie sur le contexte de la conversation

Cas 3 : une question d’agrégation et de priorisation

Cas 4 : une synthèse pour orienter la roadmap produit

Cas 5 : une question hors périmètre

Ces cinq échanges couvrent l’essentiel de ce que l’agent doit savoir faire : compter avec précision, se souvenir du fil de la conversation, dégager une priorité à partir des données, refuser sans détour ce qui sort du fichier, et remonter une synthèse directement exploitable pour la roadmap produit.

Et maintenant ?

Le projet est en cours d’évaluation : l’objectif est de constituer un jeu de test systématique (dataset LangSmith) rejouant automatiquement les tentatives de contournement identifiées, pour garantir qu’aucune future modification du prompt ne réintroduise pas une faille. Les résultats de cette évaluation feront l’objet d’une mise à jour de cet article ; n’hésitez pas à revenir voir la suite.

---

Code source disponible ici : [lien GitHub à venir]