Les chiffres de performance de Fin sont des moyennes calculées par son éditeur, sur des contenus qui ne sont pas les vôtres. Le seul benchmark qui vaille pour une décision est celui que vous faites tourner sur vos questions, avec vos sources. Fin fournit les outils pour ça, et la plupart des équipes ne s'en servent qu'une fois, le jour du lancement.
Trois outils de test, trois usages
Fin distingue Previews, Batch tests et Simulations. Ils ne se remplacent pas.
| Preview | Batch test | Simulations | |
|---|---|---|---|
| Principe | Vous tapez, Fin répond en direct | Jusqu'à 50 questions par groupe, que vous notez | Une IA joue le client et juge le résultat |
| Périmètre | Tous les réglages | Tous les clients Fin | Procedures uniquement |
| Verdict | Aucun, vous jugez | Manuel : Good, Acceptable, Poor | Automatique : Pass ou Fail |
| Appelle vos API réelles | Oui | Non, données d'exemple | Non |
| Rejouable | Non | Oui, avec export CSV | Oui, avec « Run all » |
| Coût | Sans limite | Gratuit | Inclus, 250 à 12 500 exécutions par mois |
Pour un benchmark de la qualité des réponses, l'outil est le Batch test : il est le seul à couvrir un large jeu de questions, à garder une trace et à se rejouer à l'identique. Les Simulations servent à valider la logique d'une Procedure, pas la qualité d'une réponse issue de vos contenus.
Construire le jeu de 50 questions
Le Batch test propose quatre façons de constituer un groupe : générer depuis vos conversations récentes (30 à 90 jours), générer par sujet, importer un CSV, ou saisir à la main. La génération automatique est tentante, mais elle reproduit votre volume, donc vos questions faciles. Un banc d'essai utile est composé à la main, en quatre familles.
| Famille | Part | Ce qu'elle teste |
|---|---|---|
| Questions fréquentes | 20 | La couverture de base, générée depuis vos conversations |
| Questions pièges | 10 | Sujets sans réponse dans vos sources : Fin doit s'abstenir ou escalader, pas inventer |
| Questions dépendantes du contexte | 10 | La même question pour deux plans ou deux pays différents |
| Questions sensibles | 10 | Remboursement, sécurité, données, résiliation |
Les questions pièges sont les plus instructives. Une consigne « si tu ne sais pas, escalade » ne protège de rien, comme nous l'expliquons dans notre guide de configuration de Fin. La seule façon de savoir ce que Fin fait face à un trou est de lui poser la question.
Faire tourner le test dans les bonnes conditions
Par défaut, le Batch test s'exécute avec un utilisateur d'aperçu générique, qui accède à tout le contenu sans aucun ciblage. C'est le cas le plus favorable, et le moins réaliste. Les réglages du test permettent de choisir :
- Un utilisateur ou un lead réel, pour voir comment Fin adapte sa réponse à ses attributs (langue, pays, plan).
- Une audience, pour vérifier le contenu et les consignes ciblés. Dans ce mode, les automatisations ne s'exécutent pas.
- Une marque, si votre espace en gère plusieurs.
Faites tourner les dix questions dépendantes du contexte une fois par segment. Si Fin sert la même réponse à un client gratuit et à un client entreprise, votre ciblage ne fonctionne pas, et aucun tableau de bord ne vous l'aurait montré.
Noter, puis remonter à la cause
Chaque réponse se note Good, Acceptable ou Poor. Pour une réponse Poor, Fin demande de choisir une cause. C'est la partie la plus utile de l'outil, parce que chaque cause pointe vers un réglage différent.
| Cause proposée par Fin | Indice | Correction |
|---|---|---|
| Mauvais contenu utilisé | Source hors sujet, politique ancienne | Corriger ou désactiver la source, épingler le bon article |
| Question non clarifiée | Demande multi-intentions ou vague | Consigne « Context and clarification » |
| Contenu mal utilisé | Étapes dans le désordre, règle du mauvais plan | Restructurer l'article, cibler par audience |
| Ton inadapté | Trop enjoué sur un sujet sensible | Ton dans Basics, consigne de style |
| Longueur inadaptée | Pavé pour une question simple | Longueur dans Basics, consigne par canal |
| Mauvaise langue | Réponse en anglais à un francophone | Langues prises en charge, traduction en temps réel |
En faire un benchmark, pas un test de lancement
Un test devient un benchmark le jour où on le rejoue. Le protocole que nous recommandons tient en quatre règles.
- Geler le jeu de questions. Mêmes 50 questions, mêmes segments, à chaque passage. Vous ne modifiez le jeu que par ajout.
- Rejouer après chaque changement. Nouveau contenu, nouvelle consigne, changement de longueur : un passage avant, un passage après.
- Conserver l'export CSV. Il contient vos notes et vos commentaires. C'est votre historique, hors plateforme.
- Suivre un seul chiffre. La part de réponses Poor par famille de questions. Les réponses Poor sur les questions pièges sont vos hallucinations.
Le guide d'évaluation publié par Fin propose des ordres de grandeur : 50 à 100 questions à réponse connue pour l'exactitude, et un audit d'au moins 200 réponses pour le taux d'hallucination. Un groupe de 50 questions est donc un plancher. Rien n'empêche d'en créer plusieurs.
Ce que le banc d'essai ne mesurera jamais
- Les vraies conversations. Une question de test est propre et isolée. Un vrai client écrit en trois messages, se reprend, s'énerve. Le Batch test ne teste pas la conversation, il teste une réponse.
- Les données réelles. Les connecteurs y utilisent des données d'exemple. Seul Preview appelle vos API.
- La dérive. Votre produit change chaque semaine, vos 50 questions non. Une réponse juste en octobre peut être fausse en décembre sans qu'aucun test ne rougisse.
Le banc d'essai dit si la configuration tient avant la mise en ligne. Il faut ensuite un contrôle sur la production : c'est l'objet de notre rituel d'audit hebdomadaire, et c'est ce que le scoring qualité de ResponZ automatise : la même grille, appliquée à chaque réponse réelle de Fin, en continu.