Automatiser les appels d'astreinte avec Amazon Connect Blog Devoteam Rebirth

Temps de lecture : 7 minutes

Amazon Connect est une solution de centre de contacts, omnicanale et accessible via API. Ce service permet notamment d’automatiser des appels, et nous verrons dans cet article comment nous l’avons utilisé pour répondre à la problématique du traitement des alertes de production. Nous aborderons le fonctionnement du service Amazon Connect, et la logique d’automatisation que nous avons mise en place à l’aide de fonctions Lambda.

Pourquoi automatiser l’exécution de certains appels ?

Au sein de notre équipe projet et pour gérer nos alertes sur la production nécessitant une intervention humaine lors de l’astreinte, nous travaillions avec des prestataires externes situés en Pologne. Leur mission suivait ce processus :

Consulter leur dashboard régulièrement afin de repérer une potentielle alerte,
Quand une alerte est détectée, composer le numéro de la personne de notre équipe étant d’astreinte à l’heure de l’alerte,
Transmettre le message et s’assurer de sa bonne réception en enregistrant le fait que le membre de notre équipe soit désormais concentré sur la résolution du problème,
Si la personne ne répond pas, contacter un N+1 jusqu’à ce que quelqu’un réponde.

Ce processus ayant fait ses preuves à chaque intervention, en changer pour un qui serait plus automatisé comportait une part de risque. En tant que consultant, notre rôle est d’accompagner le changement vers l’automatisation, mais aussi de rassurer. Les coûts engendrés par une solution automatique seraient à terme drastiquement réduits, étant donné qu’elle ne demande qu’un investissement initial de temps de développement, et quelques coûts ponctuels liés à l’entretien et l’amélioration de la solution. En contrepartie, elle permet de s’affranchir du besoin d’avoir recours à une équipe externe, tout en réduisant la complexité (et donc, diminuer le risque d’erreur).

J’ai donc été chargé de réfléchir à une solution d’automatisation des alertes mineures mais nécessitant un appel lors de l’astreinte. Notre choix d’infrastructure s’est porté sur une solution AWS-only.

L’infrastructure

Nos premiers pas dans le design d’une architecture répondant à ce projet furent complexes, et ont impliqué de nombreux services dont nous avons réussi à nous passer par la suite. Après réflexion et quelques tests, nous avons abouti à l’infrastructure suivante :

Fig. 1 — Infrastructure retenue

L’Alert Management System est celui que vous utilisez au sein de votre entreprise. C’est lui qui assure la logique métier quant aux alertes. La seule chose que nous exigions de cette ressource dans notre infrastructure est qu’elle puisse requêter une API en lui envoyant les paramètres suivants :

Message à délivrer
Numéro à contacter

Une fois ces paramètres reçus par l’API, ceux-ci sont envoyés à une fonction Lambda. Cette fonction va s’identifier puis créer un client Amazon Connect, le service d’appels automatiques, pour requêter un appel automatique délivrant le message reçu en paramètre au numéro de téléphone également reçu en paramètre. Finalement, le service Amazon Connect réalise l’appel en suivant le ContactFlow défini au préalable.

Nous allons commencer par décrire le service Amazon Connect avant de parler du ContactFlow puis de la Lambda en elle-même.

Amazon Connect

Amazon Connect est un service AWS développé initialement il y a une dizaine d’années par Amazon pour ses besoins en interne d’un call-center automatisé. Il est principalement utilisé par des entreprises faisant de la prospection téléphonique à grande échelle.

L’interface de configuration est intuitive et pensée dès le départ pour une utilisation par des personnes ne disposant pas de compétences techniques en programmation. Amazon Connect vient avec son lot d’outils d’analyse et de gestion des tâches.

Le service souffre toutefois de quelques limites:

Celui-ci n’est pour l’instant pas disponible en France.
La configuration du service reste pour l’heure très manuelle, l’utilisation d’outils Infra-as-code (IaC) n’est pas encore possible, bien que certains développeurs soient sur le point de push leur implémentation du service en IaC, en Terraform.
La gestion du service Connect s’effectue à travers une interface dédiée, située à l’extérieur de la console AWS. Cela peut être dérangeant et créer de la confusion pour certains utilisateurs.
Finalement, la dernière limite que j’ai relevée est celle du ticket qui a besoin d’être ouvert auprès du support AWS pour permettre les appels inter-pays, le service étant initialement réservé pour les appels au sein du pays auquel l’instance est rattachée.

Le ContactFlow

Vous pouvez définir plusieurs ContactFlow dans votre instance Amazon Connect. Ceux-ci servent à définir les interactions qui auront lieu lors de l’appel.

Ainsi, il est possible de jouer des prompts, d’attendre de l’input utilisateur, de déclencher des lambdas ainsi que d’autres fonctionnalités qui sont très souvent mises à jour. Très simple d’utilisation, il s’agit d’un Visual Programming Language, ressemblant aux blueprints d’Unreal Engine, au langage Scratch (utilisé dans l’éducation des jeunes enfants au code) ou encore à la modélisation UML. L’idée principale est de lier des box entre elles pour créer un circuit fonctionnel pouvant être ensuite interprété en code.

Sur le ContactFlow de POC ci-dessous, “Entry Point” marque le début de l’appel. Connecté à la première boîte, “Set Voice” va choisir la voix pour l’appel. Dans notre cas, il s’agit d’une voix française, Céline, mais il est tout à fait possible de définir une voix américaine, anglaise et même française du Québec (représentée par Chantal).

Puis est connecté le “Play Prompt”, qui va transmettre le message d’alerte transmis par la Lambda qui l’a elle-même reçu en paramètre de l’API Gateway, cette dernière l’ayant reçu du Alert Management System (cf graph d’infra). Nous reviendrons dans un instant sur le “Play Prompt”.

Une fois le message transmis – et donc le rôle du “Play Prompt” terminé – on attend l’input utilisateur. On connecte donc une box “Get Customer Input”, qui va nous permettre d’assigner une touche du clavier à une réponse et donc à une logique d’utilisation. Dans notre cas, si l’utilisateur appuie sur 1, on reconnaît que l’appelé à entendu le message et on lui signifie que sa réponse a été enregistrée. Une piste d’amélioration serait de lancer une Lambda à la suite qui mettrait à jour une base de données en donnant l’information qu’une personne X s’occupe de l’alerte reçue en paramètre.

Autrement, si le bouton 2 est pressé, on répète le message. Si une autre touche que 1 ou 2 est pressée, l’agent robotique indique ne pas avoir compris le message et redemande si la personne a compris le message d’alerte initial diffusé par la box “Play Prompt”. En cas d’erreur ou de non-réponse, l’appel se termine.

Une logique métier supplémentaire doit être mise en place pour pallier une non-réponse de la part de l’agent : appeler un N+1 ? Rappeler la personne quelques fois de plus ?

Play Prompt

En cliquant sur l’une des box, on peut afficher davantage de moyens de la configurer. Dans notre cas, celui du “Play Prompt”, on décide de diffuser un message ayant été reçu dans la requête qu’a fait la Lambda au service Amazon Connect. Pour ce faire, 3 étapes :

On sélectionne text-to-speech (ad hoc)
On ajoute le bout de code XML suivant dans la box :

<speak>
<prosody rate="slow">
$.Attributes.Message
</prosody>
</speak>

Puis on choisit SSML pour “interpret as”.

Ainsi, c’est bel et bien notre message reçu en paramètre qui va être diffusé lors de l’exécution du ContactFlow. D’autres configurations sont possibles et la documentation regorge de tutoriels pour les cas les plus personnalisés.

Lambda

Est décrite ci-dessous la fonction “Call” de la Lambda, rédigée en Go :

func call(body HTTPBody) (*string, error) {
# init session
	mySession, err := session.NewSession(&aws.Config{
		Region: aws.String("eu-central-1"),
	})
# init Amazon Connect client
	svc := connect.New(mySession)
# fill StartOutboundVoiceContactInput with the right attributes
	contactInput := connect.StartOutboundVoiceContactInput{
 	  Attributes: map[string]*string{"Message":	aws.String(body.Message)},
 	  ContactFlowId: aws.String("CONTACT_FLOW_ID"),
 	  DestinationPhoneNumber: aws.String(body.PhoneNumber),
 	  InstanceId: aws.String("AMAZON_CONNECT_INSTANCE_ID"),
 	  QueueId: aws.String(""),
 	  SourcePhoneNumber: aws.String("AMAZON_CONNECT_PHONE_NUMBER"),
        }
# request Connect to make a call
	req, resp := svc.StartOutboundVoiceContactRequest(&contactInput)

L’idée à retenir est que l’on initialise la session là où se situe l’instance d’Amazon Connect (Frankfurt dans notre cas) puis on initialise un client Connect qui va nous servir à remplir une structure de données correspondant à la requête à envoyer au service Connect pour passer un appel de façon automatique. Ainsi, on décide d’utiliser des variables d’environnement:

CONTACT_FLOW_ID: l’unique ID de votre ContactFlow, disponible sur votre interface Amazon Connect,
AMAZON_CONNECT_INSTANCE_ID: l’unique ID de votre instance Amazon Connect,
AMAZON_CONNECT_PHONE_NUMBER: le numéro que votre instance Amazon Connect va utiliser pour passer l’appel. Il est possible d’en obtenir un, avec l’indicatif +33 (FR), en deux minutes depuis votre instance Amazon Connect.

Finalement, on envoie cette structure de données à la méthode StartOutboundVoiceContactRequest de notre client Connect pour passer l’appel.

Limites et améliorations

Etablir un processus influencé par les enjeux métier pouvant renforcer la confiance dans cette automatisation, en impliquant un maximum de décideurs
Une configuration en Infra-as-Code devrait bientôt être disponible pour Amazon Connect