Préparé avec l’aide de l’IA et relu pour la clarté, la pertinence et les affirmations non étayées.
Les critères d’acceptation d’un chatbot WhatsApp doivent répondre à une question pratique : peut-on lui confier ce périmètre commercial dans les conditions prévues ? Une conversation agréable ne prouve ni l’exactitude des informations ni la bonne transmission d’une demande à l’équipe.
Un pilote sert à observer des comportements convenus sur des scénarios représentatifs. Les ventes peuvent dépendre du produit, du prix, de la disponibilité et de nombreux autres facteurs. Elles ne remplacent donc pas une vérification du fonctionnement de l’assistant.
1. Fixer le périmètre et la référence de chaque test
Définissez d’abord ce que le chatbot peut faire : répondre à partir d’informations approuvées, poser des questions utiles et transmettre une demande. Écrivez aussi ce qu’il ne peut pas confirmer seul, comme une remise exceptionnelle ou une disponibilité absente de sa source.
Constituez un dossier de test avec la version du catalogue, les conditions commerciales utilisées, les règles de transfert et les langues retenues pour le pilote. Sans référence datée, deux évaluateurs peuvent juger différemment la même réponse.
- Message fictif du client et contexte déjà connu.
- Information autorisée pour répondre.
- Comportement attendu, sans imposer une phrase unique.
- Actions ou affirmations interdites.
- Preuve à conserver : conversation, fiche ou dossier de transfert.
- Résultat et gravité d’un éventuel défaut.
Testez d’abord avec des données fictives clairement identifiées. Les cas réussis doivent être rejoués après une correction susceptible de les affecter.
2. Vérifier l’exactitude, y compris les omissions
Une réponse est acceptable si elle respecte la source et conserve les réserves importantes. Elle peut être fausse sans inventer un produit : oublier que la disponibilité reste à confirmer suffit à transformer une information prudente en promesse.
Dans un exemple hypothétique, une boutique de sacs possède une fiche indiquant les dimensions d’un modèle, ses coloris de référence et la nécessité de vérifier le stock. Le client fictif demande : « Le bleu est disponible et mon ordinateur entre dedans ? »
La fiche décrit un coloris bleu, mais je dois faire vérifier sa disponibilité. Pour les dimensions, pouvez-vous préciser celles de votre ordinateur afin de les comparer aux dimensions utiles indiquées pour ce sac ?
Cette réponse n’est acceptable que si les dimensions utiles sont réellement documentées. Si seules les dimensions extérieures sont connues, le chatbot doit signaler cette limite plutôt que conclure sur la compatibilité. Préparez aussi un cas où le client suggère lui-même une caractéristique fausse : l’assistant ne doit pas la reprendre comme un fait.
3. Tester une collecte utile, pas un questionnaire maximal
La collecte est réussie lorsque le prochain intervenant dispose des informations nécessaires à l’étape suivante. Demander une adresse complète pour une simple question sur les dimensions ajoute une friction sans faire avancer la demande.
Pour la boutique fictive, une demande de vérification de stock peut nécessiter le modèle et le coloris. Le mode de remise devient utile si le client souhaite poursuivre l’achat. Les informations de livraison viennent ensuite, selon le processus défini.
Testez une conversation où le modèle est déjà connu, une autre où le client change de coloris et une troisième où il refuse de donner une information non indispensable. Le chatbot doit exploiter le contexte, actualiser le choix et éviter de poser plusieurs fois la même question.
Le guide pour valider les variantes avant de confirmer une commande aide à définir les champs importants. L’acceptation doit porter sur leur utilité et leur exactitude, pas sur la quantité de données récoltées.
4. Évaluer le transfert humain de bout en bout
« Je vous transfère à un conseiller » n’est pas une preuve de transfert. Vérifiez que la demande atteint effectivement l’emplacement prévu, que l’équipe la voit et que le contexte transmis permet de poursuivre.
Dans le scénario fictif, le client demande une réduction pour plusieurs sacs. Le dossier transmis devrait distinguer sa demande des engagements de la boutique : modèle choisi, quantité envisagée, demande de remise et point restant à valider. Aucune réduction ne doit apparaître comme acceptée.
- Le client peut demander une personne sans rester bloqué dans une boucle.
- Le destinataire retrouve les informations utiles et les incertitudes.
- Le chatbot ne promet pas un délai de réponse non convenu.
- La reprise humaine n’est pas interrompue par des réponses automatiques concurrentes.
- Une demande hors horaires reste visible pour le traitement suivant.
La procédure de transfert avec le bon contexte doit être testée avec le membre de l’équipe chargé de recevoir les dossiers, pas seulement depuis l’écran du client.
5. Prévoir les cas incertains et les dépendances indisponibles
Ajoutez des messages ambigus, une référence inconnue, une information contradictoire et une source temporairement inaccessible. Testez également un format non couvert par le pilote. Le chatbot doit proposer une suite exploitable, par exemple demander une référence écrite, plutôt que prétendre avoir interprété un contenu qu’il ne sait pas traiter.
Le critère n’est pas « répondre à tout ». Il est « ne pas fabriquer de réponse et orienter correctement la suite ». Une clarification courte peut être préférable à un transfert immédiat ; un transfert devient préférable lorsque la décision dépend d’une vérification humaine.
Le guide sur la réponse utile lorsque le chatbot ne sait pas permet de formuler ces attentes. Rejouez les scénarios sensibles avec plusieurs formulations, notamment dans les langues réellement incluses. Un seul essai réussi ne démontre pas un comportement constant.
6. Décider selon la gravité des défauts
Convenez avant les tests de ce qui bloque le lancement. Une confirmation de stock sans source, une remise inventée ou un transfert perdu peuvent être classés comme bloquants. Une formulation trop longue peut relever d’une correction secondaire, sauf si elle empêche le client de comprendre l’étape suivante.
Attribuez à chaque scénario le résultat « conforme », « à corriger » ou « non testé », puis consignez la cause et la correction attendue. Évitez une note globale qui masquerait un défaut grave derrière plusieurs réponses simples réussies.
La décision finale peut être un lancement limité, un nouveau cycle de test ou une réduction du périmètre. Par exemple, la boutique pourrait conserver les réponses documentaires et le transfert, tout en reportant la collecte de demandes complexes. Un lancement accepté doit encore prévoir une surveillance, un responsable et une possibilité de pause.
Le service WhatsApp Chat Bot couvre les demandes commerciales et le transfert humain dans un périmètre à définir. Vous pouvez discuter de vos scénarios d’acceptation avec FlowAgent pour cadrer un pilote autour de comportements vérifiables.