Un assistant d'achat qui n'invente jamais une offre : brancher le modèle sur le catalogue réel

il y a 4 jours
4 min de lecture

Le pire échec d'un assistant d'achat n'est pas une réponse maladroite. C'est une offre inventée : un prix qui n'existe pas, une remise expirée, un marchand qui ne vend plus le produit. En prototypant un assistant d'achat branché sur un vrai catalogue d'offres, nous avons posé une règle avant d'écrire la première ligne : le modèle ne cite jamais un prix qu'il ne vient pas de lire.

Cette règle a tout structuré — le nombre d'outils, le partage entre mémoire et données, et jusqu'à la définition du succès. Voici ce qu'un prototype apprend quand on le contraint à ne jamais mentir.

À retenir

Sur un contenu commercial, l'erreur factuelle est binaire : un prix inventé ne se pardonne pas. Le modèle rédige ; le catalogue seul fournit les faits.
Quatre outils étroits et typés battent vingt outils larges : chercher des offres, lire le détail d'une offre, parcourir les catégories, vérifier la validité. Rien d'autre.
Le refus est une fonctionnalité : quand le catalogue n'a pas de réponse, l'assistant le dit et propose ce qui existe — il ne comble jamais le vide avec sa mémoire.

L'erreur fatale du commerce : l'offre inventée

Un texte approximatif se corrige ; un prix inventé détruit la confiance en une seule interaction — et expose, selon les marchés, à des risques réglementaires. C'est la différence entre une erreur de style et une erreur de fait : sur un assistant transactionnel, la seconde est fatale. La conséquence architecturale est immédiate : la mémoire du modèle, si vaste soit-elle, est une source interdite pour tout fait commercial. Prix, remise, dates de validité, disponibilité, nom du marchand — chacun de ces champs vient d'une requête exécutée à l'instant, ou n'apparaît pas dans la réponse.

Quatre outils étroits plutôt que vingt outils larges

La tentation du prototype est d'exposer beaucoup d'outils « au cas où ». Nous avons pris le chemin inverse : une poignée d'outils étroits, aux réponses typées — chercher des offres selon des critères, lire le détail complet d'une offre, parcourir les catégories, vérifier qu'une offre est toujours valide. C'est tout.

Ce resserrement a deux effets mesurables. D'abord, moins d'errance : un agent choisit d'autant mieux son prochain geste que le menu est court — nous l'avions écrit ailleurs, un objectif sans bornes fait vagabonder ; un outillage sans bornes aussi. Ensuite, une traçabilité complète : chaque affirmation de l'assistant se relie à un appel d'outil consigné, ce qui rend la recette (nos cinq portes) applicable à la lettre.

La mémoire du modèle sert au langage, pas aux faits

Alors, à quoi sert le modèle, si les faits viennent du catalogue ? À tout le reste — et c'est immense. Comprendre une demande vague (« un cadeau pour ma mère, autour de cinquante euros ») et la traduire en requêtes structurées. Savoir qu'une demande de « crème solaire » en juin n'a pas le même sens qu'en décembre. Reformuler trois offres brutes en une recommandation lisible, dans le ton de la plateforme. Le partage est le même que dans nos pipelines de distribution : le déterministe fournit les faits, le modèle fournit la langue. Un assistant d'achat n'est pas un catalogue qui parle ; c'est un traducteur entre l'intention humaine et les données réelles.

Le refus est une fonctionnalité

Le moment de vérité d'un assistant branché sur le réel, c'est la requête sans réponse. Le catalogue n'a rien qui corresponde ; la mémoire du modèle, elle, « connaît » des dizaines de produits plausibles. C'est là que la règle paie : l'assistant dit qu'il n'a pas trouvé, montre ce qui s'en approche dans le catalogue, et s'arrête. Nous suivons le taux de refus comme une métrique de qualité, pas comme un échec — un assistant qui ne refuse jamais est un assistant qui invente. La confiance d'un utilisateur ne se construit pas sur l'omniscience ; elle se construit sur la certitude que ce qui est affiché existe.

Prototype d'abord, produit ensuite

Ce que doit prouver une phase zéro, ce n'est pas une interface séduisante : c'est que l'architecture d'ancrage tient de bout en bout — intention comprise, requêtes justes, faits exacts, refus propres. Une démonstration qui ment est pire que pas de démonstration : elle engage la confiance de l'organisation sur des fondations qui n'existent pas. L'ordre des investissements en découle : d'abord l'ancrage, ensuite l'expérience. Le reste — mémoire des préférences, personnalisation, canaux — s'ajoute sur une fondation qui ne sait pas inventer.

FAQ

Pourquoi pas du RAG classique sur le catalogue ? Parce qu'un catalogue d'offres est structuré et périssable : des outils typés interrogeant la source fraîche battent une couche vectorielle pour des données transactionnelles. Le RAG garde sa place pour le contenu éditorial, pas pour les prix.

Quel modèle faut-il ? N'importe quel modèle de frontière comprend l'intention d'achat. La différence ne se joue pas sur le choix du modèle, elle se joue sur l'architecture d'ancrage et la discipline des outils.

Combien d'outils exposer ? Commencez sous cinq. Chaque outil ajouté élargit l'espace d'erreur ; on ajoute un outil quand une classe de requêtes réelles le réclame, pas avant.

ECTIME AI Lab est l'unité de recherche et de déploiement en IA appliquée du groupe ECTIME. Nous construisons, livrons et éprouvons des systèmes agentiques en production, de l'automatisation GEO/SEO aux agents autonomes multi-étapes. Nous maintenons des Claude Skills open source pour le GEO/SEO et accompagnons les marques européennes vers une IA non seulement autonome, mais vérifiable et autorisée.