Il s’agit d’un projet que j’ai réalisé lors de mon alternance chez JeChange durant l’année 2018. Ici, ma mission fut de remplacer la solution de relation client actuelle, Eloquant, par une nouvelle appelée Kiamo tout en adaptant les anciennes fonctionnalités développées et en y ajoutant de nouvelles.

Contexte

Il est important de savoir que l’activité principale de la société agenaise tourne principalement autour de son site internet, jechange.fr, un assistant en ligne gratuit dédié à la réduction de toutes les factures courantes auprès des particuliers mais aussi des professionnels. L’entreprise se voulant être un service personnalisé accompagnant pas à pas le consommateur, celle-ci a, dès son ouverture, mis en place un centre d’appel où des conseillers spécialisés par secteur d’activité aident les clients à trouver les meilleures offres et à prendre en charge leurs démarches administratives. En plus de cela, les agents du centre ont accès à un Back-Office, leur permettant ainsi de traiter l’ensemble des demandes en visualisant l’ensemble des fiches métiers pour un client donné.

Depuis plusieurs années, Eloquant était utilisé en tant que solution pour les relations clients. Néanmoins, et au fur et à mesure de son évolution, l’entreprise commençait à entrevoir les limites quant à l’utilisation de ce service que ce soit pour les agents, les superviseurs ou encore pour l’équipe de développement lorsque celle-ci devait ajouter de nouvelles fonctionnalités. C’est pourquoi la direction a pris la décision de migrer vers une nouvelle solution nommée Kiamo. Par rapport à Eloquant, ce nouveau service apporte de nombreux avantages :

• Le prix est moins élevé ;
• Plusieurs types de canaux sont disponibles (appels entrants / sortants, emails, etc.) ;
• L’administration et le pilotage sont simplifiés ;
• Il y a plus de fonctionnalités utiles à l’entreprise ;
• Les statistiques sont plus nombreuses ;
• L’interface est plus ergonomique.

C’est dans cette optique qu’il a été demandé au service de recherche et de développement et notamment à l’équipe de développeurs Back-end de réaliser cette migration. L’objectif était de pouvoir débrancher Eloquant et de faire en sorte que Kiamo puisse être utilisé en adaptant les fonctionnalités déjà développées par le passé tout en ajoutant de nouvelles. Ici, le plus grand risque auquel nous devions faire face était la paralysie complète du centre lors de la migration ce qui aurait eu des conséquences très graves pour l’entreprise. Quant à moi, je fus intégré à ce projet par mon responsable avec deux autres développeurs.

Mise en œuvre

En amont du début de ce projet, l’entreprise a fait appel à Komeo, le prestataire qui nous a fourni la solution et qui nous a accompagné dans sa mise en place. Dans un premier temps, je me suis formé à l’utilisation de Kiamo grâce à la documentation qui nous a été envoyée. J’ai également réalisé quelques tests étant donné que l’interface administrateur a pu être disponible assez rapidement. Pour nous aider, un intervenant envoyé par Komeo est venu nous former durant trois jours. Grâce à cela, nous avons pu faire le point sur tout ce qu’il était possible de faire. Après avoir bien défini l’ensemble des objectifs à atteindre tout en étant sûr qu’ils étaient réalisables, les développements ont pu débuter.

La première étape a été de développer les différentes fonctionnalités à utiliser lorsqu’un client appelle le centre de contact. En effet, Kiamo donne la possibilité d’appeler des services web externes à certains moments de la conversation pour y effectuer des opérations. Ici, l’objectif était de pouvoir stocker les informations de l’appel en cours et de lier celui-ci à différentes informations et notamment à la campagne d’acquisition concerné et le lead client (fiche client). Pour ma part, je me suis occupé de ces deux derniers points. J’ai donc réalisé deux APIs (interface de programmation). La première va rechercher une campagne d’acquisition et lier celle-ci à l’appel précédemment créé en base de données. Pour faire cette recherche, je me sers des données que m’envoie Kiamo lorsqu’il appelle mon API. La deuxième recherche le lead lié au numéro de l’appelant (et selon certains critères) pour le lier, tout comme la campagne, à mon appel. S’il s’agit d’un client dont le lead n’est plus valide ou bien que celui-ci n’est encore qu’un prospect, on crée un nouveau lead en base. Certaines informations comme l’ID du lead concerné sont retournées ensuite à l’agent directement dans son interface. Ces fonctionnalités avaient principalement pour but d’avoir une trace de la conversation et de permettre à l’agent d’identifier l’utilisateur tout en ayant une idée sur l’origine de son besoin. En effet, les informations étaient directement disponibles sur le back-office tout en étant mise à jour au fur et à mesure de la conversation.

Schéma technique d'un appel entrant vers Kiamo

L’étape suivante était de pouvoir programmer des appels sortants pour un agent et un client donné (dans le jargon JeChange, on appelle cela programmer un ticket). Il s’agit d’une fonctionnalité qui existait déjà et qu’il fallait réadapter pour Kiamo. En cherchant un peu dans la documentation, je me suis rendu compte que Kiamo mettait à disposition une API permettant justement de faire cela. Chez eux, on appelle cela une tâche. Sachant que du côté du back-office, il y avait la possibilité de programmer un appel sur chaque lead en appuyant sur un bouton, il m’aurait fallu tout simplement modifier le script appelé lors du click pour que cela fonctionne. Néanmoins, c’était beaucoup plus compliqué que cela. En effet, un appel doit toujours être redirigé vers ce que l’on appelle un service peu importe le canal utilisé (entrant, sortant, sortant manuel, etc.). Ces services sont directement configurables dans l’interface et dépendent surtout de la façon dont est organisé le centre d’appel de l’entreprise. Justement, l’API permettant de créer des tâches dans Kiamo demandent obligatoirement le service vers lequel l’appel sera redirigé une fois déclenché. Pour pouvoir trouver quel service choisir, il a été décidé d’utiliser certains critères liés au lead concerné par la programmation de l’appel. Cependant, il fallait connaître les critères demandés pour un service donné. C’est pourquoi j’ai développé une interface administrateur permettant de créer des associations entre un service et ces fameux critères. Dans un premier temps, j’ai configuré en base de données la table qui allait enregistrer les différentes associations. Ensuite j’ai développé plusieurs APIs telles que la récupération des services sortants et les critères d’un lead ou encore la récupération, la création ou la suppression d’une association. Enfin, j’ai développé deux interfaces utilisant ces APIs, la première permettant de choisir un service sortant et de l’associer à un ou plusieurs critères de lead et la seconde étant une liste paginée des différentes associations déjà créées et où il est possible de les supprimer. Pendant ce temps-là, un de mes collègues à développer une APIs proxy dont le but était de retrouver le service sortant en fonction des critères du lead envoyés par le back-office et ensuite d’appeler l’API de Kiamo pour déclencher la programmation de l’appel. Une fois tout cela terminé, j’ai pu modifier le script du back-office pour que l’appel soit bien redirigé vers la bonne API.

Interface de création d'une association

Interface listant les associations

La dernière fonctionnalité sur laquelle j’ai travaillé est le déclenchement d’un appel sortant manuel depuis le back-office. Tout comme la programmation d’un appel, il s’agit de quelque chose qui existait déjà sur le back-office. De même, le bouton permettant de faire cela est disponible sur chaque lead. Pour cette fois, il m’a simplement fallu adapter le script pour que celui-ci appelle l’une de nos APIs (développer en amont par un collègue) qui elle-même appelle l’API de Kiamo permettant de déclencher un appel en fonction des données reçues.

Il est important de savoir que j’ai dû quitter le projet durant plus d’un mois car il m’a été demandé de travailler sur un autre qui était très urgent à mettre en place pour la direction. Néanmoins, j’ai eu le temps de revenir pour la préparation et l’exécution de la migration. Bien évidemment, cela implique que j’ai dû m’informer et comprendre les ajouts qu’ils y avaient eu depuis mon départ. J’en ai également profiter pour écrire certaines parties de la documentation et notamment des maquettes qui expliquent le fonctionnement technique pour les différents types d’appel effectués.

Résultats

La migration s’est faite en soirée en pleine semaine. Mon rôle a été, durant celle-ci, de détecter les bugs potentiels et de les corriger si besoin. Cela aura duré quatre heures. Le lendemain matin, je suis arrivé plus tôt afin de faire en sorte que tout se déroule bien mais aussi pour apporter de l’aide aux agents qui utilisaient pour la première fois Kiamo. Grâce à notre rigueur et à notre détermination, tout s’est très bien passé et les agents ont pu commencer leur journée sans soucis avec un outil tout neuf et trois développeurs prêts à intervenir si besoin.

Conclusion

La migration vers une nouvelle solution de téléphonie a été sans doute le projet le plus sensible sur lequel j’ai travaillé jusqu’à maintenant. En effet, le centre d’appel de JeChange est le point central de la société, il n’y avait donc pas le droit à l’erreur (même si des solutions de retour en arrière avaient été prévues bien évidemment). Néanmoins, cela montre que je suis parvenu à avoir la confiance de l’entreprise grâce aux différents travaux que j’ai pu effectuer par le passé. À travers cette expérience, j’ai développé une très forte capacité d’adaptabilité puisque j’ai dû, en plein milieu, quitter le projet pour y revenir quelques semaines plus tard. J’ai également assisté à de nombreuses réunions, ce qui m’a permis de voir plus en détails comment était géré un projet que ce soit du côté de l’équipe qui le réalise mais aussi du côté de la direction d’une entreprise.