Chatbot IA pour configurateurs de produits : vérifier les variantes et préparer les devis

Un configurateur de produits B2B doit permettre de sélectionner une option techniquement adaptée à partir de nombreuses caractéristiques. Un chatbot IA peut poser des questions de manière compréhensible, expliquer les termes techniques et structurer les exigences. Cependant, il ne doit pas décider lui-même quels composants sont compatibles, quel est le prix applicable ou si une variante est disponible. C'est précisément cette séparation qui rend un chatbot IA pour configurateurs de produits fiable.

Ce guide montre comment les exploitants de sites web peuvent mettre en place un configurateur guidé par le dialogue : des données produits stables aux règles déterministes, jusqu'à la transmission qualifiée aux équipes commerciales. L'objectif n'est pas d'obtenir une suggestion de produit rédigée librement, mais un parcours traçable allant des exigences à une sélection valide ou à une vérification manuelle clairement identifiée.

La configuration de produit n'est pas un entretien de conseil libre

Les modèles linguistiques excellent dans la compréhension des formulations naturelles et la restitution claire des informations. Cependant, la logique des variantes relève d'une autre tâche. Pour savoir si un profil s'adapte à un connecteur, si un moteur supporte la charge requise ou si une surface est conçue pour le lieu d'installation, il faut s'appuyer sur des données et des règles validées. Des réponses d'apparence vraisemblable ne suffisent pas.

Le NIST qualifie de confabulations les contenus générés de manière convaincante mais faux. Dans le domaine du conseil produit, de telles erreurs ne sont pas seulement un manque de rigueur rédactionnelle. Elles peuvent entraîner des demandes de devis inexploitables, de fausses attentes ou des combinaisons techniquement impossibles. C'est pourquoi le modèle doit guider le dialogue pendant qu'un moteur de règles détermine les résultats autorisés.

Séparez le dialogue, le moteur de règles et les données de référence

Une architecture solide repose sur trois couches distinctes. La couche de dialogue identifie la demande, pose la question suivante la plus pertinente et explique les résultats. La couche de règles vérifie les dépendances, les exclusions, les caractéristiques obligatoires et les seuils critiques. La couche de données fournit les ID produits, les propriétés, les documents, les prix et la disponibilité issus des systèmes référents.

• Le chatbot formule les questions, résume les exigences et explique une sélection vérifiée.
• Le moteur de règles détermine quelles combinaisons sont valides, invalides ou soumises à vérification.
• Le PIM, l'ERP ou le système e-commerce fournissent les données produits, tarifs et stocks validées.
• Le CRM ou le processus de devis prend en charge le jeu de données qualifié avec une origine traçable.

Ces frontières doivent également être visibles sur le plan technique. Un outil de vérification des variantes reçoit des caractéristiques structurées et renvoie des ID, des statuts et des codes de justification. Il ne doit pas y avoir d'extraction massive de base de données transmise au modèle. Plus le contrat est restreint, plus il est facile de contrôler les autorisations, la journalisation et les tests.

Modélisez les variantes avec des ID stables

Les humains parlent de « la version large en anthracite », mais les systèmes ont besoin d'identifiants stables. Utilisez donc des ID uniques pour les familles de produits, les variantes, les caractéristiques et les valeurs. Les noms d'affichage peuvent être traduits ou modifiés par l'équipe rédactionnelle sans rompre les relations logiques définies par les règles.

Google recommande également un groupe de produits commun et des propriétés définissant les variantes pour les déclinaisons de produits. Dans les données structurées, on peut notamment utiliser ProductGroup, variesBy, hasVariant et un productGroupID commun. Il ne s'agit pas d'un modèle de configuration complet, mais cela illustre un principe clé : les caractéristiques communes appartiennent au groupe, les caractéristiques distinctives appartiennent à la variante concrète.

Enregistrez également la version du jeu de règles. Si une combinaison change ultérieurement, il doit rester possible de savoir quelles règles s'appliquaient lors d'une demande antérieure. Une équipe commerciale peut alors déterminer si une configuration est toujours d'actualité ou si elle doit être réévaluée.

Guidez des exigences vers des options valides

Un bon dialogue ne commence pas par la présentation de l'intégralité du catalogue. Il s'informe d'abord sur les caractéristiques qui éliminent de nombreuses options invalides. Pour un système d'ombrage modulaire, il peut s'agir de l'emplacement d'installation, de la largeur utile, du type de fixation, des conditions météorologiques, du mode de commande souhaité et de la finition de surface. Après chaque réponse, la couche de règles vérifie les options encore autorisées.

Le chatbot peut alors traduire les termes techniques en langage courant : Pourquoi le type de fixation est-il nécessaire ? Quelles sont les conséquences d'un montage extérieur ? Qu'est-ce qui différencie une commande manuelle d'une commande motorisée ? L'explication ne doit provenir que de connaissances validées. Les limites techniques ne sont pas devinées à partir d'un texte rédigé, mais vérifiées sous forme de règles structurées.

Comparer plusieurs résultats pertinents de manière compréhensible

S'il reste plusieurs variantes, le bot ne doit pas en désigner une comme étant arbitrairement la « meilleure ». Il peut comparer les différences vérifiées, telles que le matériau, le domaine d'application validé, les accessoires nécessaires ou le mode de livraison documenté. Les recommandations nécessitent un critère d'évaluation transparent. Sans ce critère, une sélection neutre accompagnée d'une question de précision est plus honnête.

Les prix et la disponibilité restent des données sources

Les prix et les disponibilités changent plus fréquemment que les descriptions techniques. Ils n'ont donc pas leur place dans une section de connaissances générales restituée librement par le modèle. Interrogez ces deux valeurs au besoin auprès de la source référente et associez au résultat la devise, le contexte de validité et un horodatage.

La spécification du Google Merchant Center exige que le prix et la disponibilité dans les données produits correspondent à la page de destination et au processus d'achat. Pour un configurateur guidé par le dialogue, cela implique une règle pratique : si la source ne fournit pas de valeur actuelle, le chatbot n'affiche aucun substitut estimé. Il indique plutôt que la valeur sera vérifiée lors de l'établissement du devis.

De même, les remises dégressives, les conditions spécifiques aux clients, le montage, la livraison ou les surtaxes liées aux projets doivent rester distincts. Un prix de base visible ne doit pas être automatiquement présenté comme un prix total ferme. La réponse doit préciser exactement quels éléments sont confirmés et lesquels restent à définir.

Les informations incomplètes ne doivent pas générer de faux résultats

Les utilisateurs sautent des questions, utilisent des dimensions approximatives ou ne connaissent pas les contraintes techniques. Le système a donc besoin de trois états de résultat : valide, invalide et soumis à vérification. « Soumis à vérification » n'est pas une erreur, mais une réponse rigoureuse lorsque des informations manquent ou qu'une vérification technique est prévue.

Exemple : Une cliente indique la largeur approximative, mais ne connaît pas la nature du support de fixation. Le chatbot peut cibler les familles de produits adaptées, mais ne doit pas confirmer un kit de montage concret. Il signale la caractéristique manquante, explique pourquoi elle est nécessaire et l'inclut dans le brief de demande de devis. Cela permet de créer un brief exploitable sans fausse certitude technique.

Du résultat de configuration au brief de devis

À la fin du processus, il ne faut pas se contenter d'un simple historique de conversation. Générez un brief structuré contenant l'ID du groupe de produits, les ID des variantes vérifiées, les caractéristiques sélectionnées, les points ouverts, la version du jeu de règles et les horodatages des sources. N'ajoutez que les coordonnées nécessaires pour lesquelles un objectif clair est établi.

Affichez le récapitulatif avant l'envoi. Le demandeur peut ainsi corriger les dimensions, le lieu d'installation et sa sélection. Ce n'est qu'ensuite que la demande est transmise avec un identifiant d'idempotence, afin qu'un nouvel appel ne génère pas de leads ou de dossiers de devis en double. L'équipe commerciale reçoit ainsi les faits essentiels à la prise de décision au lieu d'une longue conversation non structurée.

Un bon transfert indique également le statut : « techniquement vérifié », « pré-sélectionné » ou « vérification technique requise ». Il ne promet ni devis ni délai de livraison avant que le processus compétent n'ait confirmé cette information.

La protection des données et les autorisations limitent le contexte

Un service de conseil produit public n'a généralement pas besoin de connaître l'identité de l'utilisateur. Les coordonnées ne deviennent utiles que lorsque quelqu'un souhaite enregistrer une configuration ou demander un devis. Ne collectez que les champs nécessaires et expliquez leur finalité au moment exact où les données sont requises.

Les prix spécifiques aux clients, les projets antérieurs ou les produits contractuels doivent être réservés à un espace authentifié. L'application vérifie les autorisations ; le modèle ne les détermine pas. L'article sur le chatbot IA authentifié dans le portail client décrit cette frontière plus en détail.

Les variantes multilingues nécessitent des identifiants communs

Traduisez les noms d'affichage, les explications et les questions, mais pas les ID internes. « Pulverbeschichtet », « powder-coated » et « revêtu par poudre » doivent pointer vers la même valeur de caractéristique. La vérification des règles reste ainsi indépendante de la langue et une équipe commerciale multilingue travaille avec les mêmes objets.

Testez les formats de nombres, les séparateurs décimaux, les unités de mesure et les synonymes traduits. Un utilisateur peut mentionner « 2,5 mètres », « 250 cm » ou une valeur arrondie. La normalisation doit enregistrer explicitement l'unité et la précision. Le guide sur la qualification multilingue des leads montre comment combiner le changement de langue et le transfert structuré.

Testez les règles, la langue et la transmission ensemble

Un dialogue fluide n'est pas un test suffisant. Construisez une matrice composée de combinaisons valides, de combinaisons interdites, de valeurs limites, d'informations manquantes, de prix obsolètes, de stocks indisponibles et de pannes système. Pour chaque cas, vérifiez l'explication affichée, l'appel d'outil (tool call), le résultat des règles et les données transmises.

• Une instruction de l'utilisateur peut-elle contourner les règles ou les autorisations ?
• Le bot reste-t-il honnête en cas de prix ou de stock manquant ?
• Les combinaisons invalides sont-elles expliquées de manière compréhensible ?
• Chaque langue reçoit-elle les mêmes ID et résultats de règles ?
• Une nouvelle tentative (retry) évite-t-elle de créer un second dossier de devis ?
• La transmission fonctionne-t-elle également pour des exigences inconnues ?

Testez également les saisies de formulaires typiques, les fautes de frappe et les corrections. L'article sur les chatbots IA comme aide aux formulaires montre comment l'aide à la saisie et la validation côté serveur interagissent.

Liste de contrôle pour la mise en production

1. Choisissez une famille de produits bien délimitée pour le projet pilote.
2. Définissez des ID stables et des responsables pour chaque champ de données.
3. Traduisez la compatibilité et les valeurs limites en règles testables.
4. Séparez les explications des requêtes de prix, de stock et de devis.
5. Identifiez clairement les résultats valides, invalides et soumis à vérification.
6. Gérez les versions des règles, des sources de données et du format de transmission.
7. Minimisez les données personnelles et spécifiques aux clients.
8. Testez toutes les langues avec les mêmes cas de référence.
9. Mesurez les configurations validées, les corrections et les transferts d'experts.

Commencez avec une seule famille de produits, un parcours de questions restreint et un processus de transmission clair. Lorsque les règles, les sources et les responsabilités sont proprement séparées, un chatbot IA peut rendre compréhensible une sélection complexe sans simuler un engagement ferme. Le configurateur devient ainsi une porte d'entrée utile vers un devis fiable, plutôt qu'une nouvelle source d'erreurs.

Sources et normes

• Google Search Central: Structured data for product variants
• Google Search Central: Product structured data
• Google Merchant Center: Product data specification
• NIST AI 600-1: Generative Artificial Intelligence Profile