Context de la mission

Oney+ est une banque en ligne dont l'objectif est de faciliter le financement en plusieurs fois des achats effectués par ses clients. GettingApp est arrivé sur la mission en early stage, le projet était déjà entamé depuis quelques mois mais la mise en production n'avait pas encore eu lieu...

Challenge clès

• Refactoriser la codebase legacy en vanilla js entamé par les équipes et amorcer une refonte en Typescript.

• Construire une codebase commune partagé par tout les développeurs via un monorepo.

• Partage des valeurs du software craftsmanship au sein des équipes.

• Mise en place des reviews de code et des cycles de livraisons continues.

• Mise en place de la logistique technique afin de favoriser une méthodologie de développement commune entre toutes les équipes.

• Découper les différentes expertises métier dans le monde bancaire en différents bounded context.

• Former et faire monter en compétences les développeurs à la mise en place de tests automatisé (unit, integration et end to end).

• Mise en place des bonnes pratiques de conception logicielle au sein des équipes (Clean Architecture, TDD, DDD).

• Mise en place des pratiques de Reactive Programming.

Technologies

• React Native

• Node.JS

• Nx monorepo

• Typescript

• Mongodb

• Jest

• Développement de librairies autour du DDD

• Développement de SUT (System Under Test)

• Instabug

• Azure Service Bus

Approche et solution

Arrivé sur le projet, l'un des plus gros challenge a été de faire accepter au développeur que pour devenir plus productif en équipe, il fallait adopter une nouvelle façon de travailler. Afin de faire emerger cette vision, nous avons adopté une approche constructive visant à utiliser un "ubiquitous language" au sein des meetings. Cela a été fait dans le but de commencer à former petit à petit les équipes (PO comme dev) à l'approche DDD. En effet, le fait d'utiliser le "Domain Specific Language" au sein des échanges s'est retrouvé petit à petit intégré dans la codebase.
Lorsque nous sommes arrivé, la hype voulait que le backend soit construit en micro-service alors que le projet venait tout juste de démarrer. Afin de ne pas avoir une approche trop invasive en terme de conception et afin de ne pas géner les développements en place, nous avons conservé ce paradigme mais nous avons tout de même mis en place une codebase monolithique afin que chaque développeur puisse avoir un visuel sur ce que produit les autres équipes. En effet, il fallait être assez efficace pour pouvoir moduler les équipes et inter-changé les développeurs entre chaque produit issue du monde bancaire.

Nous avons également mis en place différents environnement dédié afin que chaque pôle de compétence puisse travailler dans les meilleurs conditions. La "dev" était dédié au développeur qui réalisait des premiers tests sur les fonctionnalités développées par les équipes backend, l'environnement de "preprod" était dédié aux équipes QA, qui réalisait différents scénario de test afin de valider les comportements de l'application mobile et du backend et la "prod" était dédié aux utilisateurs.

Nous avons dû également faire face aux problématiques lié à un partenaire avec qui l'on travaillait et dont l'on dépendait pour pouvoir ouvrir un compte bancaire, réaliser des virements, commander des cartes bancaires etc ... Ce partenaire était souvent en panne et pour pouvoir réagir à cela, nous avons mis en place une stratégie de monitoring basé sur des healthcheck et des alertes notifiées sur slack. Cela nous a permis d'avoir une vigilance accrue sur l'état des services et de pouvoir réaliser les actions nécessaire à la remise en service des systèmes.

L'authentification devant respecter un certain cadre réglementaire lié aux contraintes DSP2 a été également un réel challenge. Nous avons mis en place une stratégie d'authentification à plusieurs niveaux dépendant des informations fournies par l'utilisateur durant l'onboarding. Ainsi, nous avons réalisé une authentification via otp envoyé par email ou sms, et un mode d'authentification asymétrique par le biais d'un échange de clef entre le front et le backend.
Ce dernier système a permis la sauvegarde d'une information sensible tel le code pin de l'utilisateur sur son propre téléphone. Ce dernier devait simplement signer un challenge envoyé par le backend, qui verifiait l'authenticité de la signature envoyé grâce à la clef publique qui était sauvegardé en base de donnée.

Sur la partie front-end, nous avons utilisé le framework React Native en Typescript et avons également mis en place une petite équipe front-end qui devait s'occuper d'intégrer les vues réalisées par les équipes UX. Nous avons également participé à l'élaboration de l'architecture front-end en mettant au centre de l'application la clean architecture et d'autres pattern tel le reactive programming grâce à l'utilisation des observables.

Côté devops, nous avons facilité le travail des équipes déjà en place par la mise en place de build et test automatisés. Nous avons également mis en place un keyvault afin de protéger les secrets et avoir une gestion saine des variables d'environnements.

Bénéfices

En conclusion, la mission Oney+ s'est soldé par une réussite du projet. Nous avons eu d'excellent résultat lors d'un audit réalisé par la société Zenika. L'outil Sonar, responsable de detecté les failles de sécurité du projet n'a révélé que très peu de failles. Chaque développeur du projet est sorti vraiment enrichi de cette expérience et ont énormément apprécié monté en compétence sur le software craftsmanship et les bonnes pratiques.