Nettoyer les scripts agents Genesys Cloud avec une Function

Avec le temps, les scripts agents Genesys Cloud deviennent de plus en plus complexes. Passé un certain stade, les refactorings via l’interface graphique deviennent laborieux : difficile de savoir quelles variables et quelles actions sont encore réellement utilisées, et lesquelles ne sont plus que du poids mort.

Cet article décrit un petit outil pour automatiser ce diagnostic, déployé comme Genesys Cloud Function afin d’être disponible à tout moment, sans infrastructure à maintenir.

💡 Le code complet est disponible sur mon GitHub : github.com/antoningar/genesyscloud-script-cleaner. Vous pouvez le cloner et le déployer dans votre propre org.

Le problème : du poids mort dans les scripts

Un script agent vit longtemps : on lui ajoute des variables, des actions personnalisées, des branches conditionnelles, au fil des besoins métier. Mais on supprime rarement ce qui ne sert plus, car l’interface graphique ne dit pas quels objets sont devenus orphelins. Résultat : des scripts alourdis, plus difficiles à lire, à maintenir et à faire évoluer.

Le principe : analyser le JSON du script

Un script agent Genesys Cloud est, sous le capot, un document JSON décrivant ses customActions et ses variables. L’outil récupère cette représentation, l’analyse, et en déduit ce qui n’est jamais réellement référencé.

1. Récupérer le script — la fonction reçoit un script_id et des identifiants OAuth (client credentials). Via le SDK purecloud-platform-client-v2, elle déclenche un export du script (postScriptExport), récupère l’URL de téléchargement et télécharge le JSON.
2. Analyser la structure — le JSON est parsé pour en extraire la liste des actions personnalisées et des variables, chacune identifiée par un id unique.
3. Détecter les objets inutilisés — pour chaque action ou variable, on compte les occurrences de son id dans le contenu brut du script. Si l’id n’apparaît qu’une seule fois, c’est qu’il n’existe que sa définition : l’objet n’est jamais utilisé.
4. Gérer les dépendances transitives — un objet peut n’être référencé que par d’autres objets eux-mêmes inutilisés. L’outil détecte ces cas : une action uniquement appelée depuis une action morte, ou une variable uniquement lue dans une variable morte, est elle aussi considérée comme inutilisée.
5. Retourner la liste — la fonction renvoie la liste consolidée des variables et actions inutilisées, avec leur nom et leur type.

Pourquoi une Genesys Cloud Function

Plutôt qu’un script à lancer depuis un poste, la logique est packagée en Genesys Cloud Function : un handler serverless (modèle Lambda) qui reçoit le script_id dans l’événement et les identifiants OAuth dans le clientContext. L’analyse devient ainsi un service appelable à la demande, intégrable dans n’importe quel processus, sans rien à installer ni à héberger.

Le handler valide les entrées (présence du script_id, des credentials), exécute l’analyse et renvoie un résultat HTTP propre : 400 si la requête est mal formée, 500 en cas d’erreur interne, 200 avec la liste des objets inutilisés sinon.

Stack technique

• Genesys Cloud Functions (handler serverless, modèle AWS Lambda)
• TypeScript pour toute la logique métier
• SDK purecloud-platform-client-v2 (ScriptsApi, authentification client credentials grant) pour l’export du script
• Tests BDD avec Cucumber, lint et build vérifiés en CI GitHub Actions

Le sample sur GitHub

Le code complet de la fonction est disponible en open source : github.com/antoningar/genesyscloud-script-cleaner. Le dépôt contient le handler, la logique d’analyse, les tests et les instructions pour le tester en local ou le déployer comme Genesys Cloud Function.

Pour aller plus loin

Workflows asynchrones natifs sur Genesys Cloud
Infrastructure as Code
À propos de moi
Mes réalisations