Retour d'expérience : le système de paiement chez Club Med

Article mis à jour le 9 août 2023

Arthur : Arthur Morel, Head of Digital Indirect Sales, cela fait 5 ans que je travaille au Club Med. Il y a 3 ans, j’ai lancé le site Club Med Travel Agent (CMTA) afin de pouvoir faire gagner en autonomie et en efficacité nos agents de voyages vendeur de Club Med.

Gauthier : Je suis Gauthier, Développeur Full-Stack, en mission chez Club Med au sein de l’équipe Club Med Travel Agent (CMTA). À ce titre, je développe les nouvelles fonctionnalités et optimise les performances pour l’application CMTA.

Qu'est-ce que Club Med Travel Agent ? Qui constitue l'équipe et comment fonctionnez-vous ?

Arthur : CMTA est un site web à destination des agents de voyages revendeurs de Club Med à travers le monde. Notre objectif est que ce site facilite la collaboration avec nos partenaires en leur donnant un produit tout en un (information, vente et gestion). Pour mettre en place ce produit, nous avons une équipe organisée en agile (Kanban) et qui a maintenant atteint sa taille critique (2 Product Owners, 1 Support, 3 Développeurs, 1 Lead dev, 1 Devops).

Gauthier : L’application CMTA est destinée aux agences de voyages qui souhaitent vendre des voyages Club Med. L'équipe technique de Club Med Travel Agent (CMTA) est constituée de 4 Développeurs et de 1 Développeur opérationnel. Nous fonctionnons avec la méthode agile Kanban.

Quels ont été les chantiers les plus importants ces 6 derniers mois ?

Gauthier : L’implémentation des prestataires de services de paiement est, techniquement, un des chantiers les plus importants car il augmente l'autonomie des agences de voyage, dans le parcours de vente de voyage Club Med. Il est également important en termes de développement, la roadmap s’étend d’ailleurs sur plusieurs mois.

Arthur : La deuxième partie de l’année 2021 a été tournée sur le transactionnel. Dans un objectif d'autonomie de nos partenaires, nous suivons avec attention le taux de ce que l’on appelle des “selfbookings” c'est-à-dire des ventes 100% réalisées par nos partenaires sans intervention d’un call center Club Med. La partie paiement est donc indispensable pour éviter des appels à très faible valeur ajoutée qui, de plus, ne sont pas sécurisés.

Concernant le paiement, quelle est la roadmap ?

Arthur : Afin de proposer des parcours de paiement efficaces et sécurisés, nous nous appuyons sur des Payment Service Provider (PSP) qui peuvent être spécifiques à chaque pays. Pour ne pas surcharger l’équipe et permettre une montée en compétence globale, nous avons décidé de traiter ces développements les un après les autres car même si une logique commune persiste, chaque PSP possède ses propres caractéristiques empêchant un développement unique. Pour la priorisation, nous avons suivi l’impact business en lançant d’abord les plus plus importants. Grâce à cette méthode (toujours un PSP en cours de développement), en 6 mois, 5 PSP ont pu être développés, ce qui nous a permis de déployer notre produit sur 70% du marché Club Med.

Gauthier : En 6 mois, nous avons implémenté 5 prestataires de services de paiement (PSP) pour les pays suivants : Israël (Netpay), USA (Cybersource), Brésil (GlobalCollect), France (Voxpay), Italie (Ogone) et Afrique du Sud (VCS).

Chaque parcours de PSP est différent. En effet les requêtes, selon le PSP, ont des paramètres différents (arguments de méthodes). Les interfaces visuelles sont également différentes ce qui peut impacter le temps d’implémentation de chaque PSP.

Le développement est effectué en PHP. Il s’agit d’un développement orienté objet (POO). Une fois l’objet principal (class) créé, avec ses méthodes génériques et propriétés, nous pouvons développer les parcours de chaque PSP, en ajoutant des conditions.

switch ($providerId) { case ‘VOXPAY’: // execute some code in this way break; case ‘NETPAY’: // execute some code in this way break;

Nous utilisons également le langage Javascript. Celui-ci permet d'exécuter des requêtes asynchrones (sans rafraichissement de page). La structure de nos développements Javascript nous permet d’ajouter de nouveaux PSP sans difficulté.

Quelles ont été les principales difficultés rencontrées ? Comment les avez-vous surmontées ?

Arthur : Le parcours de paiement est très sensible dans le sens où on peut pas se permettre d’avoir une erreur sur cette partie. Cette exigence a été une opportunité pour l’équipe d’augmenter la qualité globale du produit mais à donc coûté cher en refacto. De plus, la spécificité de chaque PSP n’est pas à sous-estimer. Nous avons dû nous appuyer sur l’ensemble des autres features teams Club Med afin de trouver la bonne implémentation et l’ensemble des informations.

Gauthier : Toutes les informations relatives au parcours de paiement sont importantes. Le premier challenge est d'assurer une récolte complète de toutes les informations nécessaires. J'y suis parvenu en les obtenant auprès des autres équipes : Booking Engine, API Data et API Payment.

Le second challenge est de prendre en compte les différences entre les PSP, avant de commencer le développement. Ces différences conditionnent les étapes et les actions du parcours de paiement. Par ailleurs, il est préférable de développer un objet (de type service) ainsi que les méthodes et propriétés qui seront instanciées au début du parcours.

Grâce à ce service, nous gagnons du temps lorsque nous ajoutons de nouveaux PSP.

Il est également intéressant de savoir que la plupart des interactions avec les PSP, pour l’application CMTA, sont faites via des opérations asynchrones AJAX ou CURL. Une partie importante de la conception et du développement est de prévoir et d’intégrer les parcours liés aux différentes erreurs pouvant survenir lors de ces appels.

Les requêtes asynchrones permettent aux utilisateurs un parcours de paiement “sans coutures”.

Lorsque l’utilisateur a validé toutes les étapes, nous le redirigeons sur la page d’un dossier qui affiche une pop-up de validation ou d’échec du paiement, et mettons à jour le statut du dossier, ce qui met fin au parcours de paiement.

Un conseil à partager ?

Arthur : Un bon découpage des features est clé pour ce genre de stories structurantes. Des ateliers de co-conception fonctionnelles ou techniques peuvent être nécessaires pour qu'avant des développements, l’ensemble des parties puissent avoir une bonne appropriation des sujets.

Des tests automatisés permettant d’assurer une partie de la non régression semblent presque indispensables pour garantir la stabilité mais également augmenter la vélocité.

Gauthier : Je conseille à l’équipe technique de bien évaluer, en communiquant, la modularité et la scalabilité des développements qui seront réalisés.

Chez Club Med, des groomings permettent d’affiner la rédaction des Users Stories en présence des Product Owners et des Product Managers. Cette cérémonie, faite en amont, assure une bonne qualité de développement. Il faut poser toutes les questions à ce moment-là.

Rejoignez-nous !

Vous souhaitez rejoindre l'aventure Hubvisory Source ?

Tous nos postes sont disponibles sur notre site !