Une agence cliente gère le support d’une dizaine de boutiques en ligne avec un CRM externe qui centralise les tickets. L’équipe passait un temps disproportionné à retrouver, pour chaque ticket, la bonne page d’aide ou la bonne politique de retour dans WordPress avant de répondre. L’idée du projet : laisser un agent préparer la réponse, jamais l’envoyer.
Voici l’architecture retenue, les rôles de chaque brique, et pourquoi la validation humaine reste au centre du dispositif plutôt qu’une simple option de configuration.
Vue d’ensemble de l’architecture
Le système repose sur deux serveurs MCP distincts, chacun avec sa propre responsabilité, et un agent orchestrateur qui les appelle tour à tour :
Ticket entrant (CRM)
│
▼
Agent orchestrateur
│
┌────┴─────┐
▼ ▼
Serveur MCP Serveur MCP
« CRM » « Contenu WP »
(lecture (recherche dans
tickets) pages d'aide,
politiques,
FAQ publiées)
│
▼
Brouillon de réponse
│
▼
File d'attente humaine
(validation ou correction)
│
▼
Envoi effectif via le CRMSéparer les deux serveurs plutôt que d’en écrire un seul monolithique facilite la maintenance : l’équipe qui gère le CRM peut faire évoluer son serveur sans toucher à celui qui expose le contenu WordPress, et inversement.
Le serveur MCP côté CRM
Ce serveur expose un nombre volontairement restreint d’outils : récupérer un ticket par identifiant, lister les tickets ouverts d’une catégorie donnée, et déposer un brouillon de réponse associé au ticket. Aucun outil d’envoi direct au client final n’existe côté agent : cette action reste réservée à l’interface humaine du CRM.
{
"name": "get_ticket",
"description": "Récupère un ticket de support par son identifiant, avec l'historique des échanges.",
"inputSchema": {
"type": "object",
"properties": {
"ticket_id": { "type": "string" }
},
"required": ["ticket_id"]
}
}Le serveur MCP côté contenu WordPress
Ce second serveur interroge les pages d’aide, la FAQ et les politiques publiées sur chaque boutique. Il expose un outil de recherche qui renvoie des extraits pertinents plutôt que des pages entières, pour limiter la quantité de texte que l’agent doit ensuite synthétiser.
search_help_content: recherche par mots-clés dans les articles publiés d’une catégorie « support ».get_policy: récupère le texte à jour d’une politique précise (retours, livraison, garantie) pour une boutique donnée.
Chaque boutique étant un site WordPress distinct, l’outil reçoit systématiquement l’identifiant du site cible en paramètre, pour éviter qu’une réponse destinée à une boutique ne cite la politique d’une autre.
La file de validation humaine
Le brouillon généré par l’agent n’est jamais envoyé directement. Il est déposé dans une file d’attente consultée par l’équipe support, avec le ticket original, les extraits de contenu utilisés comme source, et la proposition de réponse. L’agent d’assistance humain peut valider tel quel, corriger, ou rejeter en indiquant la raison — cette raison sert ensuite à ajuster les instructions données à l’agent.
Notre règle de conception : un agent qui prépare bien libère du temps, un agent qui répond mal sans supervision coûte de la confiance client. On a toujours préféré la première option.
Résultats et limites observées
Sur les tickets répétitifs (délai de livraison, procédure de retour), le taux de validation sans correction dépasse 80 % après trois semaines d’ajustement des instructions. Sur les tickets ambigus ou impliquant un geste commercial, l’agent produit systématiquement une réponse trop générique, et l’équipe corrige presque toujours le brouillon.
| Type de ticket | Brouillon accepté tel quel |
|---|---|
| Délai de livraison | Fréquent |
| Procédure de retour | Fréquent |
| Geste commercial demandé | Rare |
| Réclamation qualité produit | Rare |
En résumé
Séparer le serveur MCP du CRM et celui du contenu WordPress clarifie les responsabilités et limite la surface d’action de l’agent. La validation humaine systématique n’est pas une contrainte temporaire en attendant que l’agent soit « assez bon » : c’est la garantie que le ton et l’exactitude de chaque réponse envoyée restent maîtrisés, quel que soit le niveau de confiance qu’on accorde par ailleurs au modèle.
