Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 54

Tester, publier et vérifier un script en conditions réelles

Recommended resources

Bonjour ! Bienvenue dans cette dernière leçon du module sur les scripts d'agent.

Au cours des leçons précédentes, nous avons assemblé les briques d'un script de plus en plus sophistiqué. Vous avez appris à :

  • Utiliser des composants dynamiques.
  • Naviguer entre plusieurs pages.
  • Recevoir des données depuis un flux Architect via Set Screen Pop.
  • Appeler une Data Action pour interroger un service externe.
  • Afficher les données récupérées dans l'interface de l'agent.

Chacune de ces étapes est puissante, mais leur véritable valeur se révèle lorsqu'elles fonctionnent ensemble de manière fluide. L'objectif de cette leçon est de consolider toutes ces connaissances en maîtrisant le processus final et crucial : tester, publier et vérifier le comportement d'un script en interaction réelle.

À la fin de cette leçon, vous saurez comment mener un cycle de test complet, de la publication de votre script à sa validation en conditions réelles, vous assurant ainsi que l'agent dispose d'un outil fiable et fonctionnel.

1. Le Cycle de Vie d'un Script : Brouillon, Publication et Versions

Avant de tester, il est essentiel de comprendre comment Genesys Cloud gère les scripts. Un script peut exister dans plusieurs états, formant un cycle de vie simple mais sécurisé.

  • Brouillon (Draft) : C'est votre version de travail. Toutes les modifications que vous effectuez dans l'éditeur sont enregistrées dans le brouillon. Un brouillon ne peut pas être utilisé par les agents lors d'interactions réelles.
  • Publication (Publish) : L'acte de "Publier" un script crée une version statique, en lecture seule, de votre brouillon à un instant T. C'est cette version publiée qui sera présentée aux agents.
  • Version Publiée : Chaque fois que vous publiez un script, une nouvelle version numérotée est créée (v1, v2, v3, etc.). Une seule version peut être "active" à la fois. Ce système de versionnage est une sécurité : si une nouvelle version introduit un bug, vous pouvez rapidement revenir à une version précédente qui fonctionnait.

Le bouton "Preview Script" (Aperçu) que vous connaissez déjà ne fonctionne que sur le brouillon. Il est utile pour vérifier l'aspect visuel et la navigation simple, mais comme nous l'avons vu, il a des limites importantes.

Interface de Conception de Script Genesys Cloud
Dans l'éditeur de script, les boutons "Save" et "Publish" en haut à droite sont vos outils principaux pour gérer le cycle de vie. Le bouton "Preview Script" est utile pour un premier aperçu du design, mais insuffisant pour un test complet.

Un test complet nécessite de passer par une interaction réelle, car le mode aperçu ne peut pas :

  • Simuler des données d'interaction réelles (nom de la file, numéro du client, etc.).
  • Recevoir des données envoyées par l'action Set Screen Pop d'un flux Architect.
  • Exécuter réellement une Data Action pour récupérer des données externes.

Pour ces raisons, le processus de test que nous allons voir est une compétence non négociable.

2. Le Processus de Test de Bout en Bout

Mettons en pratique le test complet de notre script qui appelle une Data Action. Ce processus méthodique garantit que chaque partie de la chaîne fonctionne comme prévu.

Shelf Genesys Cloud Integration Configuration Guide

Pour vous guider, nous allons nous appuyer sur certaines étapes décrites dans un guide d'intégration. Bien que ce guide concerne un autre produit, les étapes de publication et de test dans l'interface Genesys Cloud sont identiques à ce que nous devons faire. Concentrez-vous sur les actions dans l'interface (cliquer sur 'Publish', passer 'On Queue', passer un appel).

Veuillez consulter ce document pour visualiser les étapes clés. D'abord, dans la première partie, repérez l'étape 9 qui montre les boutons 'Save' et 'Publish'. Ensuite, dans la seconde partie (intitulée 'Inbound Call Flow Configuration'), parcourez rapidement les étapes 14 à 17 pour voir la séquence : assigner une route, se mettre 'On Queue', et passer l'appel. Ne vous préoccupez pas du contenu spécifique à 'Shelf', observez juste la procédure générale dans Genesys Cloud.

Voici les étapes détaillées à suivre, en appliquant les concepts vus dans le document :

Étape 1 : Publier le Script
Dans l'éditeur, après avoir sauvegardé vos dernières modifications sur le brouillon, cliquez sur Publish. Une fenêtre de confirmation apparaîtra. Validez pour créer une nouvelle version publiée de votre script.

Étape 2 : Assigner le Script à la File d'Attente
Ceci est un rappel d'une leçon précédente, mais c'est une étape critique.

  1. Allez dans Admin > Contact Center > Queues.
  2. Sélectionnez la file d'attente que vous utilisez pour vos tests.
  3. Dans l'onglet Scripts, assurez-vous que votre script est sélectionné comme Default Script pour le type d'interaction que vous allez tester (par exemple, Voice).
  4. Enregistrez les modifications de la file d'attente.

Étape 3 : Préparer l'Agent et l'Interaction

  1. Connectez-vous à Genesys Cloud en tant qu'agent.
  2. Assurez-vous que votre station est bien configurée (par exemple, un téléphone WebRTC).
  3. Passez au statut On Queue. Cela indique au système que vous êtes prêt à recevoir des interactions de la file d'attente.
  4. Depuis un téléphone externe (votre mobile, par exemple), composez le numéro de téléphone (DID) qui est routé vers votre flux Architect de test. Ce flux doit transférer l'appel vers la file d'attente à laquelle votre script est assigné.

Étape 4 : Vérifier le Comportement en Direct
Lorsque l'appel arrive, répondez-y. Le script doit s'afficher automatiquement. C'est le moment de vérité.

Interface Agent Genesys Cloud avec Script d'Agent en Cours d'Appel
Voici à quoi ressemble le résultat final : l'interface de l'agent avec l'appel actif et le script chargé sur la droite, prêt à être utilisé.

Procédez à une vérification méthodique :

  • Vérification A (État Initial) : Le script s'affiche-t-il correctement ? Les données envoyées via Set Screen Pop (si vous en utilisez) sont-elles déjà visibles ? Les champs de résultat de la Data Action sont-ils bien masqués, comme nous l'avons configuré avec la propriété Visible ?
  • Vérification B (Action de l'Agent) : Saisissez un ID client valide dans le champ de saisie de votre script.
  • Vérification C (Déclenchement) : Cliquez sur le bouton "Rechercher" qui exécute la Data Action.
  • Vérification D (Résultat) :
    • Cas nominal : Les informations du client (nom, statut) apparaissent-elles correctement ? Cela valide que la Data Action a été appelée avec succès ET que les variables de sortie sont correctement mappées et affichées.
    • Cas d'erreur : Essayez avec un ID client invalide. Le script se comporte-t-il comme prévu (par exemple, ne rien afficher ou afficher un message d'erreur si vous l'avez configuré) ?

3. Itération et Déploiement d'une Nouvelle Version

Que faire si le test échoue ? Le processus d'itération dans Genesys Cloud est conçu pour être simple.

  1. Terminez l'interaction de test.
  2. Retournez dans Admin > Contact Center > Scripts et ouvrez votre script. Vous modifierez toujours le brouillon.
  3. Apportez les corrections nécessaires (par exemple, corriger le nom d'une variable, ajuster une condition de visibilité).
  4. Sauvegardez puis Publiez à nouveau le script. Cela créera une nouvelle version (par exemple, la v2).
  5. Cette nouvelle version devient automatiquement la version active. Il n'est pas nécessaire de la réassigner à la file d'attente.
  6. Répétez les étapes 3 et 4 du processus de test pour valider votre correction.

Dans l'interface du script, l'onglet "Versions" vous permet de voir l'historique de toutes vos publications et, si nécessaire, de restaurer une version antérieure en la publiant à nouveau. C'est un filet de sécurité très appréciable.

Conclusion

Félicitations ! Vous avez bouclé la boucle du développement de scripts dans Genesys Cloud. Vous ne savez pas seulement construire des scripts complexes, mais vous maîtrisez aussi la méthodologie indispensable pour les tester et les déployer en toute confiance.

Les points clés à retenir :

  • La publication est l'action qui rend un script utilisable par les agents.
  • Le test de fonctionnalités dynamiques (Data Actions, Screen Pop) exige une interaction réelle ; le mode aperçu est insuffisant.
  • Le cycle de test complet est : Publier -> Assigner à la file -> Se mettre "On Queue" -> Lancer une interaction de test -> Vérifier.
  • Le versionnage automatique à chaque publication fournit un historique et une capacité de retour en arrière pour sécuriser vos déploiements.

Et ensuite ?

Maintenant que vous savez construire et déployer des flux de routage et des scripts d'agent, l'étape logique suivante est de mesurer leur efficacité. Le prochain module, "Analyse de Performance et Qualité", vous plongera dans les outils d'analyse de Genesys Cloud. Nous apprendrons à naviguer dans les vues analytiques, à créer des tableaux de bord et à évaluer la performance de vos files d'attente et de vos agents. Vous passerez du rôle de constructeur à celui d'analyste et d'optimiseur.