Assistant IA — Agent e-commerce
Copilote conversationnel connecté au catalogue, aux stocks et aux commandes d’une boutique de démo. Le LLM comprend et formule — les données viennent de la base, pas de sa mémoire.
Le problème
Les chatbots e-commerce classiques sont soit scriptés (arbre de décision rigide), soit « intelligents » mais déconnectés des données réelles — le modèle invente un statut de commande ou un prix. En démo client ou en POC, une seule réponse fausse tue la crédibilité.
Cet assistant sépare clairement les rôles : l’IA gère la compréhension et la formulation, les données factuelles (stock, commande, prix, rupture) sont lues en base. Le même pattern qu’un copilote branché sur un ERP ou un OMS en production.
Comment ça marche
Compréhension du message
L’utilisateur écrit en langage naturel. Le LLM analyse le message et identifie l’intention : suivi de commande, recherche produit, question stock, demande de conseil, ou simple conversation sociale. Les messages sociaux (salutations, remerciements) sont traités directement sans mobiliser la couche données.
Routage par intention
Dès qu’une intention métier est détectée, le système route vers le bon outil : recherche catalogue, statut commande, vérification stock, tops produits, alertes rupture. Ce routage évite les appels LLM inutiles sur des requêtes simples et réduit la latence.
Exécution métier (tool use)
Le LLM ne « devine » pas le stock ou le prix. Il déclenche un appel serveur qui interroge la base de données et retourne un résultat structuré. C’est le pattern function calling / tool use : le modèle sait quoi demander, le serveur sait où chercher. Les chiffres viennent de la base, pas du modèle.
Synthèse et formulation
Une seconde passe LLM transforme les données brutes en réponse naturelle, ton boutique, en français. Le modèle voit explicitement un bloc « données système » qu’il doit respecter — il reformule, il n’invente pas. Le résultat ressemble à un vrai vendeur qui consulte son écran avant de répondre.
Stack technique
| Brique | Détail |
|---|---|
| Backend | Ruby on Rails 8.1 — services objects, orchestration multi-services |
| LLM | RubyLLM + GitHub Models API — GPT-4o-mini (routage + synthèse) |
| Orchestration | AssistantChatService — chef d’orchestre : intent detection → tool routing → synthèse |
| Outils métier | ToolRouter + services dédiés (catalogue, commandes, stocks, analytics) |
| Prompts | Versionnés dans app/prompts/ — system prompt, synthesis prompt (ERB), labels YAML |
| Contexte | Sliding window sur la session — le fil mémorise le contexte sans exploser les tokens |
| Résilience | Fallback multi-niveaux : si LLM down → données brutes, si données indisponibles → message clair |
Ce qui est démontré techniquement
Orchestration LLM complète
Un service central (AssistantChatService) gère tout le flow : analyse du message, détection d’intention, routage vers les outils métier, synthèse de la réponse. Chaque responsabilité est isolée dans son propre service (IntentDetector, ToolRouter, ResponseFormatter).
Pattern tool use / function calling
Le LLM ne cherche pas dans la base lui-même. Il identifie le besoin, le ToolRouter déclenche le bon service métier (recherche produit, statut commande, stock…), et le résultat structuré est passé au LLM de synthèse. Les données factuelles ne transitent jamais par la « mémoire » du modèle.
Double passe : données puis formulation
Premier LLM call = comprendre l’intention et récupérer les données. Second LLM call = formuler une réponse naturelle à partir des données vérifiées. Le prompt de synthèse inclut explicitement le bloc données système que le modèle doit respecter — pas de place pour l’hallucination sur les chiffres.
Détection d’intention fine
L’IntentDetector distingue les conversations sociales (salutations, remerciements), les raffinements de prix (« moins cher », « en dessous de 50€ »), les changements de sujet, et les intentions métier. Les messages sociaux court-circuitent la chaîne données pour répondre instantanément.
Gestion du contexte conversationnel
Un contexte de session léger permet d’enchaîner les questions sans tout répéter : « Et en bleu ? », « Moins cher ? », « Et pour la livraison ? ». Le TextNormalizer nettoie les messages courts, le merge de contexte gère les follow-ups intelligemment.
Résilience multi-niveaux
Trois scénarios de dégradation gracieuse : erreur d’authentification API → réponse avec données brutes si disponibles. Rate limit → message explicatif avec conseil. Erreur inattendue → fallback heuristique puis message générique. L’utilisateur n’a jamais un écran vide.
Scénarios de démo
L’assistant gère un catalogue de boutique sport/outdoor avec des données réalistes :
- SAV & suivi — « Où en est ma commande CMD-2024-0042 ? » → statut, étapes, date estimée, lue en base
- Recherche produit — « Je cherche des chaussures de running pour homme » → résultats avec prix, stock, variantes
- Conseil & panier — « Qu’est-ce qui irait bien avec ce t-shirt ? » → compléments contextuels, tops de la semaine
- Stock & ruptures — « Le modèle X est-il disponible en 42 ? » → vérification temps réel, alternatives si rupture
- Analytics — « Quels sont vos best-sellers cette semaine ? » → top produits, tendances
Toutes les réponses citent des données réelles issues de la base de démo, pas des fabrications du modèle.
Cas d’usage métier
Sales & avant-vente
Démonstration crédible d’un SAV ou conseiller augmenté lors d’un rendez-vous client. Les réponses sont alignées avec un vrai catalogue — pas de promesse en l’air.
Équipe produit
Le découplage compréhension / données clarifie les rôles : l’équipe data branche les sources, l’équipe produit ajuste les prompts et le ton — sans recoder le flow.
Direction technique
Architecture extensible : ajouter un cas d’usage (retours, fidélité, dispo magasin) = ajouter un service métier + mettre à jour le prompt. Le contrat « question → donnée vérifiée → réponse » reste le même.