Retour au blog
WebChat Operations

Comment tester WebChat avant son lancement : une checklist pratique

Une checklist fondée sur les risques pour tester les parcours WebChat, le comportement du widget, le routage, les transferts et la préparation de l’équipe avant que les clients utilisent le canal.

Une équipe d’assistance examine une checklist de lancement WebChat et une conversation de test

Définir le périmètre et les critères de réussite

La présence d’un widget sur une page ne prouve pas que WebChat est prêt. Cartographiez les scénarios retenus avant de les tester, puis comparez le résultat observé au résultat attendu. Cette approche générale de test de bout en bout est notamment décrite par Cekura et Testim : https://www.cekura.ai/blogs/how-to-test-ai-chat-workflows-before-launching et https://www.testim.io/blog/end-to-end-testing-guide/.

Les vérifications de pages, d’appareils, d’accessibilité, de couverture et de dossiers proposées dans cet article sont des recommandations opérationnelles pour votre équipe, pas des affirmations sur des fonctions propres à WebChat.

  • Choisissez quelques parcours représentatifs : une question courante, une réponse inattendue, une demande de parler à une personne ou le suivi d’une conversation.
  • Pour chaque scénario, notez les étapes, le résultat attendu, l’environnement de test, la date et la personne qui effectue le test.
  • Indiquez explicitement les éléments non testés plutôt que de supposer qu’ils fonctionnent.
Définir le périmètre et les critères de réussite

Vérifier le widget et les pages prévues

Le widget WebChat de chaque canal est installable, personnalisable et multilingue. À titre de recommandation opérationnelle, vérifiez son comportement sur les pages et les mises en page que les clients utiliseront réellement, plutôt que de vous limiter à un aperçu interne.

Les vérifications d’accessibilité ci-dessous sont des contrôles pratiques que votre équipe peut intégrer à sa recette. Elles ne constituent pas une évaluation complète de conformité.

  • Vérifiez que le widget apparaît et reste utilisable sur les pages concernées, dans des mises en page pour ordinateur et mobile représentatives.
  • Testez l’état initial et le déroulement d’une conversation dans les navigateurs retenus par votre équipe.
  • Vérifiez la langue et les textes visibles par les clients dans chaque langue concernée.
  • Essayez le clavier uniquement et vérifiez que le focus reste visible. Examinez aussi l’utilisation avec un lecteur d’écran et la lisibilité des libellés et des textes.
  • Pour chaque problème, consignez la page, l’appareil ou le navigateur, les étapes de reproduction et, si utile, une capture expurgée de toute donnée sensible.
Vérifier le widget et les pages prévues

Tester les parcours automatisés et les transferts

Les flux automatisés peuvent envoyer des messages et des fichiers, recueillir des réponses validées, créer des branches, transférer des conversations et passer le relais à une personne. Testez les étapes configurées comme un client le ferait, y compris les cas où une réponse ne correspond pas à ce qui est attendu.

Si un flux dépend d’informations communiquées plus tôt, vérifiez qu’il les utilise correctement après plusieurs échanges intermédiaires. Ce type de test de contexte est également décrit dans la checklist de test de chatbot d’Autonoma : https://getautonoma.com/blog/chatbot-testing-checklist.

Avant de recueillir des informations, vérifiez avec la personne responsable si un avis de confidentialité, une étape de consentement ou un choix proposé au client s’applique. Tester le parcours ne suffit pas, à lui seul, à établir une conformité juridique.

  • Parcourez les principales branches et les réponses valides, invalides ou incomplètes.
  • Si le flux dépend d’appels API, vérifiez que chacun se termine comme prévu.
  • Vérifiez qu’une réponse invalide ou une demande non résolue ne conduit pas à une impasse et que la prochaine étape proposée au client est claire.
  • Confirmez que tout avis ou toute étape applicable intervient avant la collecte d’informations.
  • Vérifiez que le transfert à une personne indique clairement au client ce qu’il doit faire ensuite.

Vérifier le routage et la couverture de l’équipe

Les équipes peuvent organiser les agents et les services et configurer le routage et les horaires. Comme recommandation de recette, vérifiez les règles utilisées par votre canal et comparez le résultat observé à votre plan de couverture.

Incluez un scénario où l’équipe prévue est indisponible, par exemple en dehors de ses horaires de couverture. Notez ce que voit le client et ce que l’équipe doit faire ensuite, sans présumer du comportement avant de l’avoir vérifié.

  • Testez chaque règle de routage prioritaire avec une conversation correspondant clairement au service visé.
  • Vérifiez la destination du transfert et la prochaine étape présentée au client.
  • Consignez les écarts entre le routage prévu et celui observé, ainsi que le responsable chargé de les examiner.

Suivre la conversation dans la boîte de réception partagée

webchat.vip propose une boîte de réception partagée pour les conversations WebChat et WhatsApp. Les équipes peuvent organiser les agents et les services et utiliser des tags. Pour votre recette, suivez une conversation de test jusqu’à son traitement afin de vérifier que votre équipe sait quoi faire.

Les étapes d’attribution et de suivi dépendent des procédures de votre organisation : consignez-les comme critères de test plutôt que de supposer qu’un processus interne particulier est configuré.

  • Vérifiez que la conversation est visible par l’équipe chargée de la traiter et que son contexte permet de comprendre la demande.
  • Vérifiez que la personne qui prend en charge la conversation peut déterminer la prochaine action selon votre procédure.
  • Si votre processus utilise des tags, vérifiez que l’équipe sait lesquels appliquer et comment les utiliser.
  • Effectuez le suivi prévu et vérifiez que la conversation se termine dans l’état attendu par votre équipe.

Protéger les dossiers opérationnels de test

La plateforme enregistre des données analytiques opérationnelles, des journaux de conversation, des évaluations et des rapports exportables. Décidez comment votre équipe distinguera les conversations de test des conversations réelles et comment elle traitera les résultats avant de commencer.

Ces précautions sont des recommandations opérationnelles ; ne supposez pas qu’une fonction précise d’exclusion ou de suppression existe. Vérifiez la procédure applicable auprès du responsable du canal.

  • Utilisez des noms, des coordonnées et des contenus fictifs. Ne copiez pas de dossiers client réels dans une conversation de test.
  • Notez si l’activité de test peut influencer l’interprétation des rapports utilisés lors de l’examen du lancement.
  • Désignez la personne responsable de l’identification et du traitement des conversations de test.
  • Si des informations personnelles réelles apparaissent, arrêtez le test et suivez la procédure de confidentialité et de gestion des incidents de votre organisation.

Traiter les défauts et décider du lancement

Classez les défauts selon leur impact possible sur le client ou les opérations, attribuez un responsable et consignez les décisions. Un parcours essentiel qui échoue ou un transfert sans prochaine étape utile mérite une attention prioritaire.

Après une correction, répétez le scénario concerné de bout en bout. Fondez la décision de lancement sur les résultats consignés, les problèmes non résolus, la préparation de l’équipe et le traitement prévu des conversations de test.

  • Pour chaque problème, notez les étapes de reproduction, le résultat attendu, le responsable et le résultat du nouveau test.
  • Vérifiez les branches ou transferts associés lorsque vous retestez une modification.
  • Consignez la décision, la personne qui l’a examinée, la date et les limites connues.
  • En cas de désaccord sur le feu vert, mettez le lancement en pause et transmettez la décision aux responsables du canal, de l’assistance ou des opérations et de l’équipe web concernée.

Questions fréquentes

Que doit couvrir un test de lancement WebChat ?

Définissez les scénarios à tester et suivez-les de bout en bout, notamment les branches, les réponses inattendues et les transferts. Vous pouvez aussi vérifier les pages et appareils prévus, le routage, la couverture et le traitement des conversations de test selon les procédures de votre équipe.

Faut-il tester avec de véritables informations client ?

Non. Utilisez des données synthétiques. Si des informations personnelles réelles apparaissent, arrêtez le test et suivez la procédure de confidentialité et de gestion des incidents de votre organisation.

Dans quels cas faut-il bloquer un lancement WebChat ?

Envisagez de bloquer le lancement si un parcours essentiel échoue ou si un défaut empêche le client de recevoir une prochaine étape utile. Attribuez le problème à un responsable, retestez le scénario et consignez la décision.

Qui doit participer aux tests de recette WebChat ?

Faites participer les personnes responsables du canal WebChat, de l’assistance ou des opérations, ainsi que l’équipe web responsable des pages concernées. Faites intervenir le responsable de la confidentialité ou de la sécurité si les tests soulèvent des questions sur les informations personnelles ou les dossiers.

Sources et lectures complémentaires

Références primaires et reconnues utilisées pour vérifier la base factuelle de ce guide.

  1. How to Test AI Chat Workflows Before Launching? 5 Methods — Cekura
  2. End-To-End Testing: The One Guide To Rule Them All — Testim
  3. The Chatbot Testing Checklist (Functional, LLM, and ...) — Autonoma