Un client demande les dimensions d’un produit. Un autre veut savoir si sa commande arrivera demain. Un troisième conteste un remboursement. Ces trois messages ressemblent à des questions de service client, mais ils ne demandent ni les mêmes sources ni le même niveau de décision.

L’autonomie d’un chatbot doit être définie par type de question. Le système peut expliquer une information validée sans avoir le droit de consulter un dossier personnel ou de promettre une décision commerciale. Cette séparation protège le client et évite de transformer une réponse plausible en engagement improvisé.

Le point de départ consiste à classer les demandes reçues, puis à préciser les conditions dans lesquelles une réponse automatique est acceptable. Un chatbot utile sait aussi demander une précision, reconnaître une limite et transmettre la conversation.

Séparer information, consultation et décision

Une question d’information porte sur un contenu stable : dimensions, mode d’entretien ou procédure générale. Le chatbot peut y répondre si la source est identifiée, actuelle et adaptée au produit concerné. Il doit conserver les conditions et les exceptions nécessaires.

Une consultation demande un état propre à un client ou à une commande. Elle suppose une authentification adaptée, une autorisation et un accès au système de référence. L’information ne doit pas être déduite d’une documentation générale ou d’un ancien export.

Une décision modifie une situation : accorder un geste commercial, rembourser, annuler ou changer une adresse. Elle demande des règles, des permissions et un traitement des conséquences. Pour un premier périmètre, il est souvent préférable de laisser le chatbot préparer la demande puis de passer par le circuit humain prévu.

Répondre n’est pas nécessairement décider.

Cette distinction doit être visible dans le fonctionnement, pas seulement dans un document projet. L’interface et les outils autorisés doivent empêcher le système d’effectuer une action que sa mission ne couvre pas.

Identifier les questions autonomes avec leurs conditions

Les horaires du support, les moyens de contact, les étapes d’une procédure et les caractéristiques publiées peuvent constituer un premier périmètre. Il faut cependant vérifier la précision demandée : « comment suivre un colis ? » n’équivaut pas à « où se trouve mon colis maintenant ? ».

Pour chaque famille, notez la source, sa fréquence de changement et le risque d’une erreur. Une condition de retour peut dépendre d’un pays, d’un produit ou d’une situation. Le chatbot ne doit pas transformer la procédure générale en conclusion sur le dossier individuel.

Une grille d’éligibilité peut aider :

Le tableau ne définit pas une règle universelle pour tous les commerces. Il sert à rendre les autorisations discutables et vérifiables. Chaque entreprise doit adapter les cas à son activité, à ses obligations et à la qualité de ses systèmes.

Les sujets sensibles doivent posséder un circuit particulier : sécurité d’un produit, situation personnelle délicate, suspicion de fraude ou contestation complexe. Le chatbot ne doit pas donner une conclusion médicale, juridique ou autre décision spécialisée simplement pour maintenir la conversation.

Faire reposer les réponses sur des sources réellement fiables

Les fiches produits, guides, conditions et procédures doivent être cohérents. Une réponse issue d’une ancienne page peut contredire le panier ou les conditions actuelles. Le chatbot ne résout pas ce conflit en choisissant la formulation la plus fluide.

La constitution d’une base de connaissances pour un assistant aide à préparer les versions, les propriétaires et les retraits. Pour un commerce, ajoutez les dimensions qui déterminent la réponse : marché, devise, référence, période et type de client.

Vérifiez aussi les unités et les variantes. Une mesure peut concerner l’emballage plutôt que le produit ; une composition peut changer selon la version. Le système doit pouvoir demander une référence ou orienter vers la fiche exacte au lieu de généraliser. Les informations précontractuelles doivent rester disponibles dans les espaces appropriés du site. Le chatbot ne doit pas devenir le seul moyen de connaître un prix, une caractéristique essentielle ou une condition importante. La DGCCRF rappelle les obligations d’information lisible et compréhensible dans le commerce électronique.

Un lien de source aide le client à vérifier, mais il ne dispense pas d’une réponse correcte. Le passage cité doit soutenir l’affirmation, et le lien doit être accessible au public concerné. Une citation décorative peut donner une impression de fiabilité sans la preuve correspondante.

Traiter le stock, les prix et les commandes comme des données vivantes

Une base documentaire n’est pas un inventaire en temps réel. Si le chatbot annonce une disponibilité, il doit consulter une source prévue pour cet usage et respecter ses limites d’actualisation. Une valeur mise en cache peut être dépassée au moment où le client commande.

Le stock disponible peut différer du stock physique : réservations, commandes en cours, magasin, entrepôt ou articles bloqués. Le chatbot ne doit pas interpréter seul un champ technique dont la signification n’a pas été définie. L’équipe doit choisir ce qui peut être annoncé au client.

Le prix demande la même rigueur : taxes, devise, marché, promotion et options. Une réponse ne doit pas reconstituer une remise ou appliquer un code sans règle explicite. Lorsque le panier reste la référence finale, expliquez comment le client vérifie le montant applicable à sa commande. Un délai de livraison dépend de la destination, du transporteur, du traitement et du moment de la commande. Le chatbot doit distinguer une estimation, un état de suivi et un engagement. Il ne peut pas transformer « habituellement » en « garanti » pour rassurer le client.

Si la source opérationnelle est indisponible, prévoyez une réponse de repli. Dire que l’information ne peut pas être confirmée vaut mieux qu’afficher une valeur ancienne comme actuelle. Le système doit également éviter de répéter indéfiniment la même requête sans résultat.

Protéger les dossiers des clients dans la conversation

Pour une réponse liée à une commande, l’identification doit être adaptée au risque. Un numéro de commande seul peut ne pas suffire à autoriser l’accès. Le dispositif doit éviter qu’une personne obtienne des informations sur un autre client en modifiant quelques caractères.

La vérification d’accès doit être effectuée par l’application ou le service autorisé. Demander au modèle de décider si l’utilisateur semble être le bon client n’est pas une preuve d’identité. Les données renvoyées doivent être limitées à ce qui est nécessaire à la réponse.

Ne demandez pas un numéro complet de carte ou un mot de passe dans le chat. Préparez un avertissement compréhensible et un traitement des informations envoyées spontanément. Les utilisateurs peuvent partager plus de données que prévu, surtout lorsqu’ils pensent parler à une personne du service client.

La CNIL recommande notamment de définir la finalité, les durées et les mesures adaptées pour les chatbots. Les historiques, les prestataires et les traceurs associés doivent être examinés. Une conversation utile au dépannage ne doit pas devenir une conservation illimitée de toutes les informations personnelles.

Indiquez clairement la nature automatisée de l’interlocuteur et les possibilités de contacter une personne. Cette transparence permet au client d’adapter ses attentes. Elle ne doit pas se limiter à une mention cachée dans un texte juridique inaccessible pendant la conversation.

Préparer une transmission qui ne fait pas recommencer le client

La transmission humaine doit être un parcours, pas une formule « contactez le support ». Définissez le canal, les horaires, les informations utiles et la responsabilité de la reprise. Si aucun agent n’est disponible immédiatement, donnez une suite réaliste.

Le chatbot peut préparer un résumé fidèle : besoin, référence, vérifications réalisées et point restant. Il doit distinguer les déclarations du client des faits confirmés dans les systèmes. Un résumé qui transforme une réclamation en conclusion déjà établie peut orienter à tort l’intervenant.

Transmettez seulement les informations nécessaires et autorisées. Le conseiller doit pouvoir retrouver le contexte sans recevoir un export brut contenant des données sans rapport. Précisez comment les pièces et les identifiants sensibles sont traités.

Les déclencheurs doivent être explicites : demande d’un humain, absence de source, désaccord répété, situation hors périmètre ou risque particulier. Évitez de faire franchir plusieurs boucles au client avant de lui donner accès à la bonne voie.

Une reprise humaine ne doit pas être comptée automatiquement comme un échec du chatbot. Dans certains cas, c’est exactement le résultat attendu. La qualité se juge sur l’orientation et la préparation, pas seulement sur la proportion de conversations fermées sans conseiller.

Écrire des réponses qui aident sans promettre

La réponse doit aller à l’essentiel, puis préciser les conditions utiles. Une longue explication peut cacher l’information recherchée. À l’inverse, un « oui » sans référence ni contexte peut être dangereux sur une compatibilité ou une condition commerciale.

Demandez une clarification lorsque plusieurs interprétations changent la réponse. Le système peut proposer les options compréhensibles : référence exacte, pays de livraison ou type de demande. Il ne doit pas multiplier les questions inutiles pour donner une apparence de personnalisation.

Les formulations doivent conserver l’incertitude. « Le suivi indique une livraison estimée » ne signifie pas « votre colis arrivera ». Une politique générale ne doit pas devenir une approbation individuelle. Vérifiez ces distinctions dans les modèles de réponse et les tests.

Exemple fictif : un client demande si un article peut être installé sur un équipement. La fiche ne précise qu’une compatibilité avec une famille de modèles. Le chatbot doit demander la référence nécessaire ou transmettre, plutôt que conclure que tous les équipements de la marque sont compatibles.

Le ton ne doit pas minimiser une difficulté réelle. Une réclamation demande une réponse respectueuse et une orientation, pas une phrase enthousiaste. La personnalisation du style ne doit jamais masquer l’absence de preuve.

Tester les limites, pas seulement les questions faciles

Avant l’ouverture au public, examinez les cas ordinaires, ambigus et hors périmètre. Ajoutez une référence inexistante, une ancienne promotion, un suivi indisponible et une demande concernant un autre client. Ces essais vérifient la frontière de l’autonomie retenue.

Testez les tentatives de détourner le comportement : demander d’ignorer les règles, fournir une fausse politique ou introduire une instruction dans une donnée. Les contrôles doivent préserver les accès et les actions autorisés même lorsque la conversation insiste.

Analysez les résultats par famille. Une bonne moyenne peut cacher une erreur grave dans les commandes ou les droits. Les réponses fluides, les citations et les formules polies ne doivent pas être confondues avec l’exactitude.

Prévoyez aussi la charge et les indisponibilités. Lorsque le trafic augmente, le chatbot doit conserver un comportement compréhensible, limiter ses appels et proposer la reprise prévue. Un système saturé ne doit pas empêcher l’accès aux pages et moyens de contact ordinaires.

Les versions linguistiques demandent également une vérification du fond. Une traduction peut modifier une condition ou employer un terme qui n’a pas le même sens commercial. Les règles du pays, les unités et les références produits doivent rester alignées avec la source applicable, au lieu d’être adaptées librement par le modèle.

Donnez à chaque famille de questions un responsable de validation. La logistique vérifie ce qui peut être dit sur un suivi ; l’équipe produit valide les caractéristiques ; les personnes compétentes examinent les conditions et les situations sensibles. Une seule validation générale du ton ne couvre pas ces sujets.

Prévoyez enfin la suspension ciblée. Si les prix ou le stock deviennent indisponibles, le chatbot peut continuer à orienter vers les guides stables tout en désactivant les réponses concernées. Cette séparation évite de choisir entre maintenir une réponse devenue douteuse et fermer l’ensemble du service sans nécessité.

Mesurer le service rendu après le lancement

Suivez les réponses utiles, les escalades appropriées, les erreurs, les demandes répétées et les abandons. Une conversation fermée peut signifier que le client a reçu une réponse, mais aussi qu’il a renoncé. Le compteur doit être interprété avec des retours qualitatifs et des contrôles d’échantillons.

Exemple fictif : cent conversations sont traitées et soixante-dix ne sont pas transmises. Il serait abusif d’annoncer soixante-dix problèmes résolus sans vérifier le résultat. Certaines personnes ont pu partir sans réponse correcte ; d’autres ont trouvé l’information dans une page ouverte en parallèle.

Les corrections doivent revenir aux sources et aux règles. Une réponse fausse issue d’une fiche ancienne ne se corrige pas uniquement en ajoutant une phrase au prompt. Définissez un responsable de la base, un responsable du service et un moyen de suspendre une famille de réponses si nécessaire.

Le bon périmètre autonome peut rester limité. Répondre correctement aux questions de référence, puis transmettre les dossiers qui demandent une décision, apporte déjà un service concret. Le client gagne surtout lorsqu’il obtient une information exacte et une suite fiable, quelle que soit la part d’automatisation affichée.