L’outil de partenariat HomeServe est un projet que j’ai effectué lors de mon alternance chez JeChange durant l’année 2019. Ma mission a été de réaliser un formulaire disponible pour les agents du centre d’appel afin qu’ils puissent proposer aux consommateurs de nouvelles offres et que les informations des différentes souscriptions soient envoyées au partenaire permettant ainsi à la société d’être rémunérée par celui-ci.

Contexte

En plus de fournir des solutions pour aider le consommateur à réduire ses factures en trouvant les meilleures offres, les agents du centre d’appel de la société JeChange proposent parfois à ses clients d’autres services qui sont mis à disposition par des partenaires. Durant l’année 2019, une nouvelle collaboration a vu le jour entre l’entreprise et la société HomeServe, un groupe international qui se spécialise dans les services pour la maison. L’objectif de ce partenariat était que les agents de JeChange puissent remplir une demande de souscription à une offre HomeServe qui était proposée à un client en amont. Celle-ci devait être faite directement sur le back-office puis envoyée chez le partenaire. JeChange était ensuite rémunérée si la demande de souscription avait abouti, c’est à dire qu’une vente réelle avait bien eu lieu.

Il faut savoir que sur le moment, le demande était assez urgente. Cependant, l’ensemble des membres de l’équipe de développement étaient déjà très occupés sur d’autres projets. Il m’a donc été demandé de mettre de côté ce que je faisais afin que je puisse me concentrer totalement sur le développement de l’outil, un formulaire réalisé avec le Framework Angular et qui serait intégré en iframe (permet d’intégrer un contenu dans une page) sur la back-office. Je fus seul à travailler sur ce projet en tant que développeur web Full-stack. Les risques étaient donc nombreux, nottament sur le fait que je pouvais manquer de temps. En effet, le projet était conséquent, j’étais seul et il m’a été demandé de finir à la date imposée.

Mise en œuvre

Dans un premier temps, je fus mis en contact avec l’un des techniciens de la société HomeServe étant donné que j’allais devoir utiliser certaines de leurs APIs (interface de programmation) afin d’envoyer les différentes informations postées par l’agent. Il m’a d’abord été fourni un diagramme de séquence que j’ai étudié pour que je puisse avoir une bonne vision sur les étapes techniques à suivre pour la souscription d’un client. J’ai eu ensuite accès à une documentation détaillée de ces APIs et je me suis formé à leurs utilisations.

C’est avec ces bases que j’ai pu commencer à réfléchir à la conception de l’outil. Tout d’abord, il a été décidé que l’on passerait par des APIs proxy (interface de programmation communiquant avec une autre) que j’allais développer moi-même avec le Framework Lumen afin de contacter les services web fournis par HomeServe. Cela avait pour objectif de contrôler les informations qui transitent tout en s’assurant que celles-ci étaient toujours au bon format que ce soit à la réception ou à l’envoi. Je me suis également demandé comment serait organisé le formulaire que j’allais développer pour les agents. C’est là que j’ai remarqué un point bloquant. En effet, l’envoi de la souscription chez notre partenaire demande en amont plusieurs étapes notamment la vérification de l’existence du client (ou sa création si celui-ci n’existe pas du côté de HomeServe), son éligibilité à l’offre choisie ainsi que la sauvegarde de certaines informations importantes. De même, il fallait garder une trace de notre côté et donc effectuer certaines opérations à un instant T. De plus, certaines APIs fournies par HomeServe demandaient en entrée des informations résultants de l’appel d’autres d’APIs utilisées en amont. Il était donc très compliqué de concevoir uniquement un formulaire capable de réaliser toutes ces étapes en une fois. Cela impliquait un risque d’erreurs important ce qui obligerait potentiellement l’agent à tout ressaisir une nouvelle fois dans le cas d’un nouvel essai.

J’ai alors participé à plusieurs réunions avec mon responsable et je lui ai proposé une solution alternative. Selon moi, il était préférable de réaliser un formulaire en plusieurs étapes dans lequel l’agent pourrait naviguer (en revenant par exemple aux étapes précédentes mais en étant obligé que celles-ci soient valides pour passer à la suivante). Imaginons qu’une étape soit dédiée à l’éligibilité du client sur l’offre. Dans cette solution, s’il s’avère que le client n’est pas éligible à l’offre, l’agent serait tenu informé avant même d’avoir renseigné les informations suivantes et cela lui aura fait gagner du temps car il n’a pas eu à saisir des données qui, au final, n’allaient pas être utilisées. L’idée ayant été validée, j’ai pu commencer les développements.

J’ai commencé par la création des différentes APIs qui allaient appeler celles de HomeServe. Selon moi, il était important de les avoir à disposition avant de travailler sur le formulaire plutôt que de les développer au fur et à mesure. Cela m’aurait fait perdre du temps car j’aurais dû jongler d’une technologie à une autre et j’aurais pu facilement m’y perdre.

Une fois cela fait, je me suis penché sur la conception du formulaire. Tout d’abord, j’ai développé un système de gestion d’étapes. Le fonctionnement est assez simple. Pour passer à une étape suivante, toutes celles qui la précèdent doivent être valides. S’il le souhaite, l’agent peut retourner aux étapes précédentes et modifier les informations qu’il souhaite. Néanmoins, si l’une d’entre elle passe d’un état valide à un état invalide, il ne pourra pas revenir à l’étape où il se situait précédemment.

La première étape du formulaire fut sans doute la plus longue à développer. L’objectif ici était de s’assurer de l’éligibilité entre le client et l’offre choisie. Il faut savoir qu’au niveau du back-office, lorsqu’un client souhaite souscrire à une offre et peu importe le métier, l’agent saisit des données dans un formulaire et créer un « abonnement ». Le but était d’ajouter une case dans ce formulaire qui indiquait si le client était intéressé ou non par une offre HomeServe. Si jamais c’était le cas, l’agent était alors redirigé. Cependant, certaines données étaient communes entre le formulaire de création d’un abonnement et la première étape du formulaire HomeServe (nom, prénom, numéro de téléphone, etc.). Afin de faire gagner du temps à l’agent, j’ai fait en sorte de récupérer toutes les informations saisies précédemment sur le back-office afin de les reporter dans les bons champs de la première étape.

Après cela, je me suis confronté à une autre difficulté. En effet, pour la première étape, il fallait être capable de savoir si la personne est un client HomeServe (j’expliquerai pourquoi par la suite). Pour cela, l’API concernée demandait certaines informations sur le client et notamment son adresse postale. Néanmoins il me fallait respecter plusieurs conditions :

• Pour faciliter la saisie, la recherche d’une adresse se ferait par autocomplétion ;
• Celle-ci est obligatoire pour accéder aux étapes suivantes ;
• Uniquement les adresses respectant la norme AFNOR étaient acceptées.

Bien qu’ayant une API d’autocomplétion déjà disponible, celle-ci ne garantissait pas de retrouver une adresse (bloquant ainsi l’agent) et même si elle y parvenait, elle n’était pas normalisée. J’ai discuté de cela avec mon responsable et mon contact de chez HomeServe et nous sommes finalement parvenus à trouver une solution. Pour contourner le problème des adresses non trouvées par l’API d’autocomplétion, j’ai développé une solution de secours pour que l’agent puisse saisir manuellement l’adresse dans ce genre de cas. Pour ce qui est de la normalisation, HomeServe nous a exceptionnellement donné l’accès à l’une de leur API qui s’occupait de faire le travail (il m’a donc fallu repasser sur Lumen pour développer une nouvelle API proxy).

La dernière fonctionnalité pour cette première étape était de tester l’éligibilité. Dans un premier temps il me fallait savoir si la personne était déjà cliente chez HomeServe. Si jamais c’était le cas, il fallait que je m’assure que celle-ci n’avait pas déjà souscrit à l’offre choisie par le passé (tout cela était possible grâce aux APIs d’HomeServe). Une fois cela fait, je devais vérifier que l’adresse était compatible avec l’offre. Néanmoins, HomeServe ne proposait aucune fonctionnalité pour savoir cela. C’est donc moi-même qui est dû développer cette vérification en fonction des zones non couvertes qui m’avaient été envoyées en amont.

HomeServe étape 1 - informations utilisateurs

HomeServe étape 1 - adresse

La deuxième étape du formulaire consistait à demander des informations de facturation du client. Également, il fallait laisser la possibilité de saisir une nouvelle adresse dans le cas où l’adresse de couverture et l’adresse de facturation étaient différentes.

HomeServe étape 2

La troisième et dernière étape avait pour but de demander au client s’il acceptait l’ensemble des conditions liées à la souscription de l’offre. Une fois l’étape validée, il fallait :

• Créer un client chez HomeServe si celui-ci n’avait pas pu être identifié ;
• Créer et envoyer le contrat lié à la demande de souscription du client ;
• Enregistrer les informations de la vente côté JeChange pour les rendre disponibles sur le back-office.

HomeServe étape 3

Avec le temps qu’il me restait, je me suis permis de faire une session de revue de code afin de rendre celui-ci beaucoup plus clair et compréhensible. Après la mise en place de l’outil et son lancement, je me suis chargé de prendre en compte les retours qui m’ont été faits et de corriger les différents bugs trouvés.

Résultats

Afin de pouvoir terminer ce projet dans le temps imparti, j’ai dû utiliser toutes les ressources dont je disposais tout en restant le plus professionnel possible. Dès la fin de son développement, le formulaire a été rendu disponible aux agents. J’ai reçu de nombreuses remarques positives de leur part notamment sur le fait que l’outil était très agréable à utiliser. J’ai également eu l’heureuse surprise de rencontrer les personnes d’HomeServe avec qui j’ai travaillé et qui m’ont offert des goodies pour me remercier. Aujourd’hui, l’outil est toujours très utilisé car il est devenu l’un des plus importants de la société. En effet, cela a apporté à JeChange la confiance d’un nouveau partenaire, l’extenssion des services proposés aux consommateurs et encore l’amélioration de la rentabilité des fiches clients. Par ailleurs je suis devenu le responsable de cet outil.

Conclusion

Selon moi, ce projet m’a conforté dans l’idée que m’orienter vers la voie de développeur web Full-stack n’était pas une erreur. J’ai dû faire face à beaucoup de difficultés mais grâce à mon expérience passée et parce que j’ai su prendre les bonnes décisions, je suis parvenu à les surmonter et arriver à l’aboutissement de cet outil. Je suis vraiment très fier de mon travail lors de ces deux mois car d’une part j’étais seul (même si cela ne m’a pas empêcher de me tourner vers mes collègues où mon responsable quand j’avais besoin de conseils) et d’autre part, j’ai pu prouver que je pouvais être un élément essentiel et que l’équipe pouvait compter sur moi.