Chatbot : ce qu’il doit refuser de répondre

Toutes les pages qui vendent un assistant conversationnel décrivent ce qu’il sait répondre. C’est la partie facile, et c’est aussi celle qui ne décide de rien : un modèle récent répond à peu près à tout, avec assurance, y compris quand il a tort.

Ce qui décide de la survie du projet est l’inverse : la liste de ce que l’assistant n’a pas le droit de traiter seul. Cette liste est courte, elle s’écrit en une réunion, et sa rédaction est la seule partie du travail qui engage vraiment quelqu’un.

Cet article décrit ce qu’elle doit contenir, ce qui se passe quand elle n’existe pas, et les trois ou quatre vérifications que vous pouvez faire vous-même avant de parler à un prestataire — nous compris.

Un modèle généraliste à qui l’on demande votre politique de retour en produira une. Elle sera formulée exactement comme une vraie politique de retour, avec un délai plausible et un ton professionnel, et elle sera fausse. C’est le comportement normal de ces systèmes : ils sont construits pour produire la suite la plus vraisemblable, pas pour vérifier qu’elle existe.

Le dégât n’est pas l’erreur, c’est la crédibilité. Un client à qui votre page de contact ne répond pas sait qu’il n’a pas de réponse. Un client à qui votre assistant annonce quatorze jours de rétractation croit qu’il en a quatorze, agit en conséquence, et découvre le contraire au moment le plus coûteux pour vous.

La parade est structurelle, pas rhétorique. On n’obtient pas la prudence en demandant au modèle d’être prudent : on l’obtient en l’ancrant sur un corpus fermé — vos pages, votre catalogue, vos procédures — et en lui faisant renvoyer la source de chaque réponse. Une réponse sans source ne sort pas.

Il faut insister sur un point que les prestataires contournent volontiers : on n’obtient pas ce comportement en demandant au modèle d’être prudent dans ses instructions. Une consigne du type « ne réponds que si tu es sûr » améliore les statistiques sans supprimer le cas, parce que le modèle n’a pas de mesure interne de sa propre certitude à laquelle se référer. Ce qui supprime le cas est de couper l’accès : pas de source, pas de réponse, en dur.

La liste tient sur une page et contient toujours les mêmes familles : tout ce qui engage un prix, tout ce qui engage une date, tout ce qui touche à une réclamation ou à un litige, et tout ce qui relève d’un conseil réglementé — médical, juridique, financier.

À côté de chaque ligne il faut un nom, pas un service. « Transféré au service commercial » n’est pas une procédure ; « transféré à la personne qui tient l’agenda des livraisons, et à défaut au responsable du magasin » en est une. Sans nom, le transfert arrive dans une boîte partagée que tout le monde considère comme celle de quelqu’un d’autre.

Cette page doit être signée avant la mise en service, pas découverte après. Elle est aussi le document que vous relirez dans six mois pour comprendre pourquoi le système fait ce qu’il fait, et le seul livrable du projet qui reste lisible par quelqu’un qui n’était pas là.

La liste se relit, et le bon rythme est trimestriel. Elle vieillit dans un sens précis et prévisible : les entreprises desserrent avec le temps, parce que chaque transfert coûte visiblement du temps à quelqu’un tandis que le risque évité ne se voit jamais. Une relecture datée, avec la personne qui reprend les transferts, est ce qui empêche la limite de se dissoudre en six mois sans qu’aucune décision ait été prise.

Ces systèmes se facturent à l’usage, auprès de fournisseurs étrangers, dans des devises que vous ne gagnez pas. Le coût dépend du nombre de conversations, de leur longueur, et de la quantité de vos contenus consultée à chaque réponse — trois variables dont aucune n’est connue avant la mise en service.

Nous ne mettons volontairement pas de graphique dans cette section. Un tarif par requête publié aujourd’hui est faux dans six mois : les fournisseurs révisent leurs grilles sans préavis, retirent des modèles du catalogue, et facturent en euros ou en dollars, de sorte qu’un chiffre daté d’un trimestre ne se transporte pas jusqu’au suivant. Une courbe donnerait à cette instabilité l’apparence d’une tendance.

Ce que vous pouvez exiger à la place est un plafond. Un seuil mensuel défini à l’avance, une alerte avant qu’il soit atteint, et un comportement décidé au-delà — bascule en prise de message plutôt que facture qui continue de courir. C’est une clause de contrat, pas une caractéristique technique, et elle vaut plus que n’importe quelle estimation. Le plafond borne l’usage ; ce qui fait varier le prix de la mise en service est ailleurs, et cinq décisions de périmètre en rendent compte.

Nous lisons vos conversations passées, nous écrivons la liste des refus avec vous, nous construisons l’assistant sur vos contenus, et nous le surveillons deux semaines avant de le laisser tourner. Nous relisons le journal des refus avec vous tous les mois. C’est l’intégralité de l’offre.

Le chiffre que nous ne donnerons pas est le taux de traitement autonome — la part des conversations qui se terminent sans intervention humaine. Nous l’avons pour les systèmes que nous exploitons, il est réel, et le publier comme moyenne serait malhonnête : ce taux est décidé par la composition des questions que reçoit chaque client, pas par la qualité de la construction. Une entreprise dont les clients demandent surtout des horaires obtiendra un taux élevé avec n’importe quel prestataire ; une entreprise dont les clients négocient des prix obtiendra un taux bas avec le meilleur. Une moyenne entre les deux mesure nos clients et pas notre travail, et vous ne pourriez rien en faire.

Ce que nous acceptons de faire à la place est de le mesurer chez vous, sur vos propres messages, avant que vous ayez signé quoi que ce soit. Et il y a un cas où nous vous dirons de ne pas faire le projet : celui de la section précédente. Si vos cinq questions tiennent sur une page que vous n’avez pas écrite, écrivez-la — nous ne facturons pas cette conversation, et nous préférons la perdre proprement que vendre un système pour compenser un texte absent.