Comment tester un chatbot d'entreprise avant de le mettre en ligne

Un assistant automatique ne se teste pas en lisant quelques conversations et en concluant qu'« il répond bien ». Il répond bien aux questions que vous posez vous-même, vous qui connaissez déjà les réponses et utilisez vos propres mots. Les questions réelles arrivent mal écrites, incomplètes, sur des cas que personne n'avait prévus. Le test sert à les rencontrer avant qu'un client ne les pose.

La méthode ne nécessite pas d'outils particuliers : une liste de questions, une réponse attendue pour chacune, un résultat noté à la main. Elle exige en revanche la discipline de la refaire à chaque changement.

Les questions de test proviennent des demandes réelles

Les questions inventées en réunion ressemblent aux réponses que le système connaît. C'est un défaut systématique : celui qui les écrit sait déjà ce qu'il y a dans les documents.

• On part des demandes reçues : messages d'assistance, demandes venues du site, notes de celui qui répond au téléphone. On retire les données qui identifient les personnes et on garde la question telle qu'elle était écrite, fautes comprises.
• On couvre l'ordinaire et le rare : pas seulement les dix questions les plus fréquentes, mais aussi celles qui arrivent une fois par mois et mettent en difficulté celui qui répond.
• On inclut les questions auxquelles il ne faut pas répondre : prix à négocier, cas contractuels, demandes concernant des tiers.
• On ajoute les questions mal formulées : phrase à moitié écrite, deux questions ensemble, un détail erroné donné pour certain.

Une centaine de questions recueillies ainsi valent plus que mille construites en chambre, car elles reflètent la distribution réelle des demandes, y compris les plus gênantes.

Les tests que personne n'a envie de faire

• Des questions avec un présupposé faux : « puisque vous faites aussi ceci… », alors que ce n'est pas le cas. Le système doit corriger, pas approuver.
• Des tentatives de lui faire ignorer les instructions reçues ou de lui faire dire des choses que l'entreprise ne dirait jamais. Ce n'est pas une hypothèse théorique : cela arrive sur les systèmes publics.
• Des questions sur des sujets proches mais hors périmètre, pour vérifier que la limite est reconnue.
• Des demandes qui exigent un engagement : une remise, une date, une garantie.

Ce qu'est une réponse acceptable

Avant de tester, il faut décider de ce que l'on considère comme juste, sinon le jugement change selon la personne qui lit et selon l'heure de la journée.

1. Le contenu : quelles informations doivent être présentes pour que la réponse soit utile, et lesquelles ne doivent pas apparaître.
2. La source : de quel document elle doit provenir. Une réponse juste tirée du mauvais document est un problème différé, qui se présente quand ce document change.
3. L'abstention : pour certaines questions, la réponse correcte est de dire qu'on ne sait pas et d'indiquer une autre voie. Cela doit être écrit comme résultat attendu, sinon celui qui évalue le note comme un échec.
4. La forme : une réponse correcte mais trois fois plus longue que nécessaire, dans un chat, est une réponse que personne ne lit jusqu'au bout.

La fiche d'évaluation

Les tests sont consignés dans un seul tableau, qui sert à comparer deux versions et à montrer aux autres comment cela se passe. Les lignes ci-dessous sont illustratives.

La colonne de la gravité est celle qui fait prendre les décisions. Une imprécision sur un détail ne pèse pas comme un engagement pris au nom de l'entreprise : l'échelle doit être établie au préalable, et la distinction minimale se fait entre réponses imprécises, réponses erronées et réponses qui engagent ou mettent quelqu'un en danger.

Au-delà des erreurs : ce qui vaut la peine d'être compté

• Les abstentions : combien de fois le système s'est arrêté quand il le devait, et combien de fois il s'est arrêté alors qu'il pouvait répondre. Ce sont deux défauts opposés et ils se corrigent de manières opposées.
• Les transferts à une personne, répartis par sujet : ils indiquent où manquent les informations publiques.
• Les réponses correctes mais inutiles : justes, génériques, et elles laissent le lecteur exactement au même point qu'avant.
• Le comportement sur les exceptions : ce qui se passe quand un lien ne répond pas ou qu'un document est inaccessible. Un système qui improvise dans ce cas est plus dangereux qu'un système qui s'arrête.

Répéter les tests après chaque changement

La liste des questions sert surtout après la première fois. Le comportement change quand l'une de ces trois choses change, et au moins l'une d'elles changera.

1. Les sources : un document mis à jour, une page réécrite, un nouveau tarif.
2. Les instructions : une règle ajoutée pour corriger un cas en casse souvent deux autres, et c'est la cause la plus fréquente de dégradations soudaines.
3. Le modèle sous-jacent, qui peut être mis à jour sans que personne dans l'entreprise ne l'ait demandé.

C'est pourquoi les mêmes questions doivent être repassées périodiquement et avant chaque publication. C'est un travail fastidieux, et c'est la seule chose qui empêche les corrections de s'annuler mutuellement.

Quand les tests disent de ne pas publier

• S'il reste des erreurs graves. Une réponse qui engage l'entreprise ou qui touche à la sécurité n'a pas de fréquence acceptable.
• Si le système ne fonctionne qu'avec des questions bien écrites : les clients n'écrivent pas bien.
• Si les sources se contredisent entre elles. Là, le défaut n'est pas celui du système : il révèle une contradiction qui existait déjà, et qui doit être réglée avant.
• S'il n'existe pas de transfert vers une personne qui fonctionne vraiment.

Ce que ce guide ne couvre pas

Il est ici question de la qualité des réponses : comment tester, comment consigner, quand publier. Le parcours de sortie vers une personne — quand s'arrêter et que transférer — se conçoit à part. Et l'évaluation économique du projet, c'est-à-dire s'il est rentable et dans quelle mesure, suit des critères différents et ne se déduit pas du nombre de réponses correctes.