Le besoin
Un chatbot classique récite la FAQ. Un agent de support consulte le compte du client, vérifie le statut réel de sa commande, déclenche un remboursement dans les règles, et transfère à un conseiller quand la situation le dépasse. La différence entre les deux, c'est l'accès aux systèmes et la capacité d'agir, et c'est là que tout se joue : un agent qui agit peut aussi se tromper en agissant.
L'architecture
- Un orchestrateur à états (LangGraph ou équivalent) pilote la conversation : comprendre la demande, appeler les bons outils, décider de répondre, d'agir ou d'escalader. Chaque étape est bornée : nombre d'essais limité, boucles impossibles.
- Des outils connectés à vos systèmes via un serveur MCP : lecture du CRM, statut des commandes, création de tickets, remboursements. Chaque outil expose une action précise, avec ses paramètres validés, jamais un accès générique à la base.
- Des garde-fous en écriture : les actions à conséquence (rembourser, modifier une commande) passent par des règles métier codées en dur : plafonds, conditions d'éligibilité, journalisation. Le LLM propose, la règle dispose.
- L'escalade humaine comme citoyen de première classe : quand la confiance est basse, que le client s'énerve ou que la demande sort du périmètre, l'agent transfère avec tout le contexte de la conversation. Un bon agent sait surtout quand s'arrêter.
- La mémoire de conversation : l'historique du client et les échanges précédents, pour ne pas faire répéter, sans jamais fuiter les données d'un client vers un autre.
Les pièges que nous connaissons
- L'agent trop autonome. Donner l'accès en écriture dès le premier jour est une erreur. On démarre en lecture seule plus escalade, on mesure, puis on ouvre les actions une par une, plafonnées.
- Le périmètre flou. Un agent qui essaie de tout traiter traite tout mal. On définit les intentions couvertes, le reste part en escalade proprement, et le taux de couverture s'élargit version après version.
- Le ton hors marque. Les réponses engagent votre marque. Le style se règle avec des exemples réels validés par vos équipes support, et se teste comme le reste.
- La latence qui tue l'usage. Trois appels d'outils en série font attendre le client. On parallélise ce qui peut l'être et on affiche l'avancement, sinon le client raccroche avant la réponse.
Comment on mesure que ça marche
- Taux de résolution sans humain, mesuré sur des conversations réelles, pas déclaré.
- Justesse des actions : chaque action exécutée est journalisée et auditable ; les remboursements se réconcilient avec la comptabilité.
- Qualité d'escalade : combien de conversations transférées trop tard, ou pas assez tôt ? C'est la métrique que les équipes support regardent en premier.
- Coût par conversation et latence par étape, tracés requête par requête.
Un jeu de conversations de test, rejoué à chaque modification, empêche une amélioration d'un côté de casser l'autre.
Ce que vous gardez à la fin
L'agent dans votre dépôt, les outils MCP réutilisables pour vos prochains agents, le jeu d'évaluation branché à votre CI, et vos équipes support formées à superviser et enrichir le système.
