Intégrer un chatbot e-commerce avec ChatGPT ou Claude

Les équipes support des boutiques en ligne traitent quotidiennement les mêmes demandes : statut de commande, disponibilité d'un article, conditions de retour. Un chatbot e-commerce alimenté par un grand modèle de langage (LLM — Large Language Model) traite ces requêtes à toute heure, libère les agents humains pour les situations complexes et maintient un ton cohérent avec votre charte de communication. Ce guide décrit l'architecture recommandée, les appels API essentiels et les garde-fous à respecter avant la mise en production.

Un chatbot classique à base de règles répond aux scénarios prévus et tombe en défaut dès qu'une question sort du script. Un chatbot alimenté par ChatGPT ou Claude comprend l'intention derrière la question et formule une réponse contextuelle, même pour des variantes non anticipées.

Pour un site e-commerce, cela se traduit par quatre bénéfices opérationnels concrets :

• Disponibilité permanente : le modèle répond la nuit, le week-end et les jours fériés, sans file d'attente.
• Personnalisation contextuelle : en injectant l'historique de commandes dans le prompt, le chatbot connaît la situation exacte de chaque client.
• Cohérence de ton : le system prompt définit le registre de communication ; chaque réponse respecte la charte de la marque.
• Déflection de tickets : les demandes simples — suivi de livraison, échange, FAQ produit — n'atteignent plus votre équipe support.

Le passage à un LLM impose cependant une architecture plus rigoureuse qu'un chatbot à règles. Sans ancrage sur des données vérifiées, le modèle peut halluciner des informations produit — par exemple affirmer qu'un article est disponible alors qu'il est en rupture de stock. C'est le problème que résout l'architecture RAG.

OpenAI (ChatGPT via l'API) et Anthropic (Claude) proposent tous les deux une API REST, un SDK JavaScript et Python mature et un modèle de tarification à l'usage. Le choix dépend de votre priorité éditoriale, de votre volumétrie et de vos contraintes de conformité.

En pratique, les deux modèles donnent des résultats comparables sur les tâches de support e-commerce standard. L'architecture que vous mettez en place importe plus que le choix du modèle : un pipeline RAG bien conçu avec Claude surpassera GPT-4 utilisé sans contexte produit injecté.

RAG (Retrieval-Augmented Generation — génération augmentée par récupération) est l'approche recommandée pour les chatbots e-commerce. Au lieu de mémoriser votre catalogue dans le modèle via un fine-tuning coûteux et figé dans le temps, on récupère dynamiquement les fiches produit pertinentes avant chaque réponse, puis on les injecte dans le prompt.

Le flux se déroule en trois étapes :

1. Indexation : les fiches produit (titre, description, SKU, niveau de stock) sont converties en vecteurs via un modèle d'embedding et stockées dans une base vectorielle — pgvector sur PostgreSQL, Pinecone ou Weaviate selon l'échelle du catalogue.
2. Récupération : à chaque message utilisateur, une recherche sémantique identifie les trois à cinq produits les plus pertinents par rapport à la question posée.
3. Génération : le contexte produit récupéré est injecté dans le system prompt avant l'appel au LLM, qui répond en se basant exclusivement sur ces données vérifiées.

Cette architecture s'intègre naturellement aux plateformes headless e-commerce : le service RAG est un microservice indépendant exposant une API REST, consommé par le frontend Next.js ou Symfony sans couplage fort avec le LLM sous-jacent.

Une fois l'index vectoriel en place, l'appel au LLM se structure en trois blocs : le system prompt, le contexte produit récupéré par la recherche sémantique et les messages de la conversation en cours.

const context = await searchProductIndex(userMessage) // recherche RAG
const res = await fetch('https://api.openai.com/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer CLE_API',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    model: 'gpt-4o-mini',
    messages: [
      { role: 'system', content: 'Assistant boutique. Données produit : ' + context },
      ...conversationHistory,
      { role: 'user', content: userMessage }
    ],
    max_tokens: 300
  })
})

Quelques points de vigilance sur cette implémentation :

• Limitez max_tokens pour contrôler les coûts et forcer des réponses concises.
• Tronquez conversationHistory à une dizaine de tours pour éviter de dépasser la fenêtre de contexte.
• Ajoutez dans le system prompt l'instruction : « Réponds uniquement sur la base des données fournies ; si l'information est absente, dis-le clairement. »

Consultez la documentation officielle de l'API OpenAI pour les paramètres détaillés, la gestion des tokens et les limites de débit. Pour les architectures IA plus larges, notre article sur les cas d'usage IA e-commerce présente des patterns testés en production.

Un chatbot e-commerce traite des données potentiellement sensibles : noms, numéros de commande, adresses de livraison, historiques d'achat. Plusieurs règles s'imposent avant la mise en production pour rester conforme au RGPD.

• Ne pas logger les prompts bruts : si vous activez la journalisation pour le débogage, filtrez les données personnelles identifiables (PII — Personally Identifiable Information) avant stockage.
• Pseudonymiser dans le prompt : remplacez les noms et coordonnées par des identifiants opaques ; résolvez l'information côté serveur uniquement si la réponse l'exige.
• Durée de conservation : les journaux de conversation constituent des données personnelles — définissez une rétention courte et documentez-la dans votre politique de confidentialité.
• Information et consentement : indiquez clairement à l'utilisateur que ses messages sont traités par un modèle de langage tiers et, selon les finalités, recueillez son accord explicite.

La checklist sécurité e-commerce que nous avons publiée détaille les points RGPD et PCI-DSS applicables à l'ensemble d'une boutique en ligne.

Un chatbot sans indicateurs de performance est une boîte noire. Dès le lancement, mesurez ces quatre métriques pour piloter l'amélioration continue.

• Taux de déflection : part des sessions chatbot qui se terminent sans ticket humain ouvert. Un taux élevé valide que les cas simples sont effectivement résolus par le modèle.
• CSAT du chat (Customer Satisfaction Score) : note laissée en fin de conversation — elle aide à identifier les catégories de questions mal gérées.
• Taux de réponse correcte : évaluation manuelle sur un échantillon hebdomadaire — le modèle a-t-il respecté les contraintes du system prompt et évité les hallucinations ?
• Coût par conversation : tokens entrants et sortants multipliés par le tarif du modèle. Ce calcul guide l'optimisation du contexte injecté et de la longueur de l'historique conservé.

Monter un chatbot e-commerce fonctionnel prend quelques jours. Le rendre fiable, conforme et maintenable sur douze mois est un projet à part entière : il faut orchestrer le pipeline RAG, superviser les dérives du modèle, mettre à jour l'index produit en continu et gérer les pics de charge lors des campagnes promotionnelles.

Si vous souhaitez déléguer cette étape, consultez nos expertises IA et automatisation ou prenez contact directement pour cadrer le projet selon vos contraintes techniques et budgétaires.