Le client, une boutique de pièces détachées automobiles vendant plusieurs milliers de références, recevait chaque semaine des dizaines de messages de support qui se ressemblaient tous : « Où en est ma commande », « Avez-vous reçu mon retour », « Quand sera livrée la référence X ». Une analyse rapide du volume de tickets sur trois mois a montré que 61 % des messages entrants concernaient exclusivement le statut d’une commande déjà passée — une information que WooCommerce connaît parfaitement, mais que personne n’allait consulter automatiquement avant de répondre au client.
Le projet a consisté à brancher un agent conversationnel, exposé sur le formulaire de contact et sur une messagerie externe déjà utilisée par le client, à un serveur MCP donnant accès en lecture aux commandes WooCommerce. Ce cas ne couvre volontairement pas la génération de contenu produit, un sujet à part entière traité ailleurs.
Le périmètre volontairement restreint de l’agent
Dès le cadrage, une limite stricte a été posée : l’agent ne répond qu’à partir des outils MCP mis à sa disposition, jamais en improvisant une réponse à partir de sa connaissance générale des délais de livraison ou des politiques de retour. Trois outils ont suffi à couvrir la grande majorité des cas : consultation du statut d’une commande à partir de son numéro et de l’adresse e-mail du client, consultation de l’historique d’un retour associé à une commande, et consultation du délai de traitement moyen actuel du transporteur utilisé.
{
"name": "statut_commande_client",
"description": "Retourne le statut, la date d'expédition prévue et le transporteur d'une commande, après vérification de l'identité du demandeur.",
"inputSchema": {
"type": "object",
"required": ["numero_commande", "email_client"],
"properties": {
"numero_commande": { "type": "string" },
"email_client": { "type": "string", "format": "email" }
}
}
}La vérification d’identité, non négociable
Chaque appel à l’outil de consultation de commande exige à la fois le numéro de commande et l’adresse e-mail associée, vérifiés côté serveur avant toute réponse. Sans cette double vérification, un agent conversationnel exposé publiquement deviendrait un moyen trivial de retrouver les commandes d’un tiers en devinant simplement un numéro de commande, qui n’a rien d’un secret en soi.
Ce que l’agent ne fait jamais
Le cadrage du projet a explicitement exclu toute action d’écriture : l’agent ne modifie aucun statut, n’initie aucun remboursement, ne déclenche aucune réexpédition. Face à une demande de ce type (« Pouvez-vous annuler ma commande »), l’agent est instruit, via le prompt système du serveur qui l’orchestre, à transmettre systématiquement la demande à un conseiller humain plutôt qu’à tenter une action qu’aucun outil MCP ne lui permet d’exécuter de toute façon.
Traitement des cas ambigus
La difficulté n’est pas venue des cas simples, qui se sont réglés rapidement avec les trois outils décrits plus haut. Elle est venue des messages ambigus : un client qui écrit « ma commande n’est jamais arrivée » sans préciser de numéro, ou qui confond deux commandes passées à quelques jours d’intervalle. Plutôt que de tenter de deviner, l’agent a été configuré pour toujours redemander l’information manquante avant d’appeler un outil, et pour transmettre la conversation à un humain dès qu’une même clarification échoue deux fois de suite.
Résultats après trois mois
- Réduction significative du temps de première réponse sur les tickets de statut de commande, traités désormais en quelques secondes plutôt qu’en plusieurs heures.
- Aucune plainte remontée concernant une réponse erronée sur un statut de commande, l’agent n’ayant jamais inventé d’information hors de ce que ses outils renvoyaient.
- Une part résiduelle de tickets (environ un sur six) transmise à un conseiller humain, principalement des cas de litige ou de demande de remboursement, exactement le périmètre exclu dès le départ.
Le succès de ce projet ne tient pas à la sophistication du modèle de langage utilisé, mais à la discipline du périmètre : un agent qui sait dire « je ne sais pas faire cela » inspire davantage confiance qu’un agent qui essaie de tout faire et se trompe parfois.
En résumé
Automatiser le service client d’une boutique WooCommerce avec un agent branché en MCP fonctionne bien sur un périmètre volontairement restreint aux questions factuelles vérifiables — le statut d’une commande, l’état d’un retour — et échoue dès qu’on lui laisse deviner ou improviser au-delà de ce que ses outils lui permettent réellement de consulter. La vérification d’identité systématique et le renvoi vers un humain en cas d’ambiguïté restent les deux garde-fous qui ont fait la différence sur ce projet.
