Workflows asynchrones natifs sur Genesys Cloud

Sur un centre de contact Genesys Cloud, un parcours d’appel entrant doit parfois déclencher une tâche qui prend du temps : appel à une IA, interrogation de plusieurs web services, traitement métier complexe. Tant que cette tâche n’a pas répondu, le flow Architect classique reste bloqué à attendre, et c’est l’appelant qui subit ce silence.

Cet article décrit un patron de conception pour rendre ce traitement asynchrone, en restant 100 % dans l’écosystème Genesys Cloud, sans middleware externe.

💡 Un sample complet et fonctionnel est disponible sur mon GitHub : github.com/antoningar/genesys-cloud-async-worklfow. Vous pouvez le cloner pour partir d’une base concrète.

Le problème : le temps d’attente synchrone

Dans un traitement synchrone, l’appelant subit le temps d’exécution de la tâche. Si une reconnaissance d’intention via IA prend plus de 5 secondes, ou si l’identification du client nécessite trois appels REST successifs, ce sont autant de secondes de silence pendant lesquelles le flow ne fait rien d’autre qu’attendre. Le temps d’attente est purement perdu.

Le principe : un workflow et les participant data

L’idée est de déporter la tâche longue dans un workflow dédié qui s’exécute indépendamment du flow d’appel, et d’utiliser les participant data de la conversation comme canal de communication bidirectionnel entre les deux.

1. Le flow d’appel entrant lance le workflow via un appel REST interne POST /api/v2/flow/execution/{workflowId}, en passant le conversationId et les données utiles dans le body. Cet appel interne est extrêmement rapide.
2. Le workflow s’exécute alors indépendamment du flow d’appel.
3. Les participant data servent de canal partagé : le workflow y publie son statut (ONGOING, puis SUCCESS) et son résultat ; le flow d’appel les relit à intervalles réguliers.
4. Pendant que le workflow travaille, le flow d’appel continue à occuper l’appelant : messages, questions, étapes de qualification… Le temps d’attente devient du temps utile.
5. Quand le statut passe à SUCCESS, le flow récupère le résultat dans les participant data et reprend le parcours normalement.

Cas d’usage 1 : Reconnaissance d’intention par IA

Le STT de l’appelant est capté dans le flow entrant, puis envoyé à un workflow qui interroge une IA externe pour la reconnaissance d’intention. Pendant que l’IA réfléchit (souvent plus de 5 secondes sur une phrase longue), le flow informe l’appelant qu’un événement caritatif est organisé samedi prochain et lui en donne quelques détails. Quand l’intention revient avec le statut SUCCESS, l’appel est routé vers la bonne file.

Cas d’usage 2 : Identification via plusieurs web services

Après le rachat de deux concurrents, l’identification d’un appelant par son numéro nécessite trois appels REST vers trois bases clients distinctes. Le workflow enchaîne ces appels en arrière-plan pendant que le flow demande à l’appelant le motif de son appel et s’il s’agit d’un premier contact. Dès qu’une base renvoie une correspondance, l’identité est publiée dans les participant data et le parcours personnalisé peut démarrer.

Avantages et inconvénients

Avantages : parcours client plus rapide, expérience fluide, nombreux cas d’usage, facile à dupliquer d’un projet à l’autre.

Inconvénients : solution plus complexe, débogage plus difficile, maintenabilité sensible.

Stack technique

• Workflows et flows Architect Genesys Cloud
• Participant data comme canal de communication entre flows
• Appels REST internes (/api/v2/flow/execution/{workflowId}) et externes (web services, IA)

Le sample sur GitHub

L’implémentation complète de ce patron est disponible en open source : github.com/antoningar/genesys-cloud-async-worklfow. Le dépôt contient les flows, le workflow et la documentation pour reproduire la solution dans votre propre org Genesys Cloud.

Pour aller plus loin

Infrastructure as Code
À propos de moi
Mes réalisations