Un agent expert du catalogue au service du conseil en magasin

Pour le consommateur, une expérience de conseil plus fluide et plus personnalisée. Pour le vendeur en boutique, un expert du catalogue capable de retrouver une référence, proposer une alternative, vérifier une disponibilité ou accéder instantanément aux informations produit.

Le catalogue est réparti entre un référentiel produit, une base de stock et de prix, et un moteur de recherche. Chacun de ces systèmes répond correctement à la question pour laquelle il a été construit, à condition de savoir quelle référence on cherche.

Une demande réelle ne se formule pas ainsi. Un client décrit une occasion, un goût, une contrainte de peau ou de tenue. Une équipe de vente cherche l'équivalent d'un produit épuisé. L'information existe. Elle n'est simplement pas interrogeable dans les termes où la demande se pose.

Nous avons construit un agent qui reçoit la demande en langage naturel, décide des sources à interroger, et compose sa réponse à partir des données de production. Trois serveurs MCP spécialisés lui donnent accès au stock et aux prix, au référentiel produit et à la recherche.

• Demande en langage naturel→
• Agent→
• Serveurs MCP et outils→
• Règles d'arbitrage→
• Réponse au client

Ces trois serveurs exposent une vingtaine d'outils, chacun dédié à une opération précise sur le catalogue. L'agent ne dispose de rien d'autre : il ne peut agir que par ces outils, et sur le périmètre qu'ils définissent.

L'agent est exposé par API et par protocole A2A. Il n'est lié à aucune interface. Le même socle sert le conseil au client final et l'usage par les équipes de vente, sans que la logique métier soit réécrite pour chaque canal.

Un agent qui expose le catalogue d'une maison de luxe ne peut pas improviser. Ce qu'il est légitime de recommander, ce qui vaut comme équivalent, ce qu'il faut vérifier avant de proposer une pièce : ces règles appartiennent à la maison, pas au modèle.

Nous les avons inscrites à deux endroits. Dans les outils eux-mêmes, qui déterminent ce qu'ils renvoient et sous quelles conditions. Et dans les instructions de l'agent, qui déterminent la manière de les mobiliser et l'ordre dans lequel il les appelle.

Le modèle raisonne, il n'arbitre pas. Ce partage est ce qui rend le comportement de l'agent explicable, et corrigeable sans réentraînement.

Les outils, les règles d'arbitrage et les instructions de l'agent sont des éléments de configuration, pas du code figé. Ouvrir un nouveau cas d'usage revient à composer autrement des briques qui existent déjà.

Chacun de ces usages mobilise les mêmes serveurs et les mêmes outils. Ce qui change, ce sont les règles d'arbitrage et le périmètre confié à l'agent.

• Un jeu de test par intentionRecherche, recommandation, information, réassort : chaque intention a son propre jeu d'évaluation, construit sur des demandes réellement formulées.
• Tests de non-régressionL'agent est réévalué à chaque évolution des outils, des règles ou du catalogue. Une modification qui dégrade une réponse déjà validée est détectée avant la mise en service, pas après.
• Traçabilité bout en boutChaque échange est tracé, du message reçu jusqu'aux appels aux systèmes métier. Une réponse discutable peut être reprise, expliquée, et rejouée.
• Boucle d'améliorationLes écarts relevés en évaluation alimentent les règles d'arbitrage et les jeux de test. La qualité se corrige, elle ne se constate pas.

1. 01

   Cadrage

   Identification des intentions à couvrir et des systèmes à mobiliser.

2. 02

   Socle de données

   Construction des serveurs MCP et des outils donnant accès aux systèmes de production.

3. 03

   Agent

   Développement de la boucle de raisonnement et des règles d'arbitrage métier.

4. 04

   Évaluation

   Jeux de test par intention, non-régression et traçabilité bout en bout.

5. 05

   Déploiement

   Mise en service progressive sur les canaux retenus.