Eviter les Hallucinations de Prix et de Disponibilite dans Votre Chatbot E-commerce

Un client qui interroge votre chatbot sur le prix d'un refrigerateur et s'entend repondre « 247 EUR » au lieu de « 1 247 EUR » ne le saura probablement jamais. Mais il quittera votre site avec la conviction que votre marque n'est pas fiable. Dans le e-commerce, une hallucination sur un prix ou une disponibilite n'est pas un simple bug : c'est une rupture de confiance immediate, souvent silencieuse, toujours couteuse.

Les hallucinations ne sont pas un defaut que l'on corrige avec un meilleur prompt. Elles sont une propriete structurelle des modeles de langage, ces moteurs probabilistes concus pour predire le token suivant, et non pour enoncer la verite. La solution n'est donc pas de combattre la nature probabiliste du modele, mais de l'enserrer dans une architecture deterministe qui rend l'hallucination structurellement impossible pour les donnees critiques.

Comprendre l'ennemi : ce qui provoque reellement une hallucination de prix

Une hallucination en environnement e-commerce survient presque toujours pour l'une de ces raisons :

• Le modele n'a jamais vu la donnee. Le prix ou le stock que le client demande n'est pas dans le contexte fourni au LLM. Le modele ne peut pas repondre « je ne sais pas » : il est entraine a completer, pas a s'abstenir. Il genere donc le prix le plus vraisemblable selon ses poids statistiques, qui peut etre totalement errone.
• Le RAG a ramene une information obsolete ou contradictoire. L'architecture de Retrieval-Augmented Generation a bien recupere un prix, mais celui-ci provient d'une version perimee du catalogue, ou deux sources concurrentes renvoient des valeurs differentes. Dans les environnements non gouvernes, jusqu'a 52 % des reponses d'IA peuvent contenir des informations fabriquees.
• Le modele ignore le contexte qu'on lui donne. Meme lorsque la bonne information est presente dans le prompt, un biais de connaissance parametrique peut conduire le modele a faire davantage confiance a ses poids internes qu'au contexte fourni.
• L'architecture agentique amplifie l'erreur. Dans un systeme a plusieurs etapes, un modele selectionne un outil, lui passe un parametre errone, puis un autre modele raisonne sur ce resultat faux. Une petite erreur en amont se propage et aboutit a une reponse finale completement incorrecte.

Ces causes ont un point commun : ce ne sont pas des problemes de modele, mais des problemes d'architecture. Un LLM seul ne pourra jamais garantir la veracite d'un prix. C'est le systeme qui l'entoure qui doit l'y contraindre.

L'architecture a quatre piliers qui rend l'hallucination impossible

La solution que je deploie pour mes clients repose sur quatre couches complementaires. Aucune n'est suffisante a elle seule. Leur combinaison cree un systeme ou une donnee chiffree erronee devient structurellement impossible.

Pilier 1 : La source de verite unique

La premiere decision architecturale consiste a decoupler radicalement la connaissance du raisonnement. Le LLM n'est pas votre base de donnees produit. Il est le moteur de raisonnement qui dialogue avec l'utilisateur, mais la source de verite pour les donnees critiques reside dans vos systemes transactionnels : votre base de donnees produit, votre ERP, votre systeme de gestion des stocks.

Traiter le LLM comme un processeur, non comme un disque dur, et externaliser toutes les donnees factuelles dans une memoire externe est la condition prealable a toute architecture fiable. Concretement, cela signifie que votre chatbot ne « connait » jamais un prix. Il ne peut que l'interroger, via un appel deterministe a votre systeme backend.

Pour les projets Symfony et Sylius que je mene, cette source de verite est le ProductRepository de Sylius, dont les donnees sont exposees via une API interne ou interrogees directement par le pipeline RAG. Jamais un prix n'est stocke dans un embedding vectoriel susceptible de se perimer.

Pilier 2 : Le RAG transactionnel

Un pipeline RAG classique indexe des documents et recherche par similarite semantique. Pour un prix ou un stock, c'est une approche inadaptee qui introduit une couche d'approximation dangereuse.

Le RAG transactionnel remplace la recherche semantique par un appel deterministe a votre base de donnees. Lorsqu'un utilisateur demande « Quel est le prix du canape Oslo ? », le systeme ne cherche pas un document similaire. Il execute une requete SQL sur la table produit et recupere la valeur exacte.

Cette approche s'appuie sur le function calling (ou tool calling). Le LLM ne genere pas le prix ; il genere un appel de fonction structure, que votre backend execute. Le resultat retourne est ensuite injecte dans le contexte pour que le modele le reformule en langage naturel. Le prix n'est jamais emis par le LLM lui-meme, mais par votre base de donnees.

L'integration avec Sylius rend cette approche particulierement elegante. Le plugin Sylius API Platform expose nativement les entites produit, prix et inventaire en REST. Un appel API authentifie a /api/v2/products/{code} retourne le prix exact et le stock en temps reel. Le chatbot ne fait qu'enrober cette reponse dans une formulation naturelle.

Pilier 3 : La sortie structuree et le typage fort

Meme avec un RAG transactionnel, il reste le risque que le LLM interprete mal la reponse de l'API ou invente un chiffre dans sa reformulation. La parade : contraindre la generation a un format structure strict.

Les techniques de constrained decoding (ou structured outputs) permettent d'imposer au LLM un schema JSON precis pour sa reponse. Le modele n'a plus la liberte d'inventer un champ « prix » avec une valeur approximative : chaque token genere doit respecter la grammaire definie.

Vous pouvez specifier un schema qui definit exactement quels champs sont autorises et leur type. Par exemple, une reponse produit doit contenir un champ price de type number avec une valeur minimale. Si le LLM tente de generer autre chose, l'appel echoue et le systeme peut appliquer une logique de secours, plutot que de laisser passer une reponse incorrecte.

Pilier 4 : Les garde-fous de validation

Un systeme de garde-fous (guardrails) vient couronner l'architecture. Il ne s'agit pas d'une simple verification post-generation, mais d'une couche de validation qui opere a chaque etape du pipeline :

1. En entree : verifier que la question de l'utilisateur a bien ete comprise et que les parametres extraits (produit, variante) correspondent a des entites existantes en base.
2. Avant l'appel LLM : s'assurer que le contexte assemble contient bien une valeur de prix et une valeur de stock issues de la source de verite. Si ce n'est pas le cas (timeout API, produit introuvable), le systeme bascule immediatement sur une reponse controlee du type « Je ne peux pas verifier ce prix pour le moment, je vous invite a consulter la fiche produit ».
3. En sortie : confronter la reponse generee au schema attendu. Si la reponse contient un prix, celui-ci doit correspondre exactement a la valeur obtenue de la base de donnees. Toute divergence declenche un rejet et une regeneration, ou l'affichage d'un message prudent.

Cette approche en couches (RAG transactionnel + contrainte de sortie + validation) constitue la defense la plus robuste contre les hallucinations dans un environnement de production.

Au-dela de l'architecture : la strategie de deploiement

La donnee structuree est votre meilleure alliee

Un chatbot e-commerce consomme des donnees produit. Si ces donnees sont incoherentes, incompletes ou mal typees, aucune architecture ne rattrapera le probleme. L'investissement prealable dans la qualite du catalogue est le premier levier de fiabilite. Des attributs produits riches et coherents, des descriptions normalisees, des relations produit/variante explicites sont le carburant d'un chatbot performant. La mise en place de donnees structurees Schema.org sur vos fiches produits renforce encore cette coherence.

Les donnees transactionnelles restent dans les systemes transactionnels

N'indexez jamais un prix ou un stock dans une base vectorielle. Ces donnees changent trop vite, et une base vectorielle n'est pas concue pour garantir la coherence transactionnelle. La seule source fiable pour un prix est l'API qui interroge la base en temps reel. Pour un stock, la verification doit etre instantanee, car un agent consommateur peut verifier la disponibilite a la milliseconde pres avant d'afficher une option d'achat.

Les tests ne sont pas optionnels

Un LLM est un composant probabiliste. Son comportement peut varier d'un appel a l'autre. La seule facon de controler cette variabilite est de tester le systeme comme un logiciel de production : suites d'evaluation, tests unitaires, tests de bout en bout mesurant explicitement le taux d'hallucination sur un corpus de questions connues. Mesurer est la seule maniere de progresser.

Le time to first token ne doit pas compromettre la fiabilite

L'obsession actuelle pour la latence ne doit pas conduire a sacrifier les validations. Les garde-fous synchrones ajoutent quelques millisecondes, mais les architectures modernes permettent de decoupler la generation de la validation sans bloquer l'experience utilisateur. Un prix affiche en 200 ms et faux est infiniment plus dommageable qu'un prix affiche en 800 ms et juste.

Conclusion : l'hallucination est un choix architectural, pas une fatalite

Eviter qu'un chatbot n'invente un prix ou une disponibilite n'est pas une question de magie algorithmique. C'est une question de discipline architecturale. Les quatre piliers que j'ai decrits (source de verite transactionnelle, RAG deterministe, sorties structurees, garde-fous de validation) forment un systeme coherent ou l'hallucination d'une donnee critique devient structurellement impossible.

Cette approche n'est pas theorique. C'est celle que je mets en oeuvre au quotidien pour mes clients e-commerce sous Sylius et Symfony, avec une interface conversationnelle propulsee par React lorsque l'experience utilisateur l'exige. La maturite de l'ecosysteme Symfony (API Platform, Messenger pour les traitements asynchrones, Workflow pour les processus metier) offre un socle ideal pour industrialiser ces bonnes pratiques.

La question n'est pas de savoir si votre chatbot hallucinera un jour. Sans architecture adaptee, c'est une certitude. La question est de savoir si vous avez mis en place les contraintes qui l'en empecheront. Contactez-moi pour securiser votre chatbot e-commerce, ou consultez nos formules et tarifs.