Un seul tunnel de demande de crédit pour les financer tous
Contexte
Chez Younited Crédit, nous proposons du crédit à la consommation, mais à la différence d’une banque classique, toute la démarche peut se faire en ligne.
Mais tout comme nos concurrents, nous avons besoin de connaître de l’emprunteur, sa situation familiale, professionnelle, son identité etc… pour immédiatement proposer un crédit à un taux adapté. C’est ce qui est le plus laborieux pour le client ! Qui a envie de passer 10 min à saisir un formulaire de demande ? Notre but est de proposer un site agréable. On l’appelle Tunnel en français (pour tunnel d’acquisition) ou Funnel en anglais (pour entonnoir, ce qui est une bonne métaphore car il y a de moins en moins d’utilisateurs à chaque étape).
Besoin
Nous ne voulons surtout pas proposer un formulaire sur une seule page non responsive présentant 40 champs à saisir et qui aurait besoin d’un POST pour afficher les champs incorrects ! L’idée est de présenter à l’utilisateur un tunnel en plusieurs étapes.
Mais le challenge est d’adapter notre tunnel, car Younited est présente dans 4 pays (France, Espagne, Italie et Portugal) et nous proposons des tunnels adaptés pour des partenariats (Conte, Pitagora, BPI) :
Pour ajouter en complexité, nous proposons un tunnel custom en fonction du device : mobile ou desktop.
Enfin la conversion n’est pas une science exacte car en permanence, nous essayons des types de contrôles, des affichages, l’ordonnancement des étapes ou même des wordings différents via un système d’ A-B testing (avec Kameleoon).
Au total, nous générons 9 tunnels depuis une seule base de code.
Solution technique
Après 6 ans d’existence, Younited a développé plusieurs solutions techniques :
- un tunnel en ASP.NET WebForms 🤔
- un tunnel en AngularJs complètement dynamique, se basant sur une complexe configuration, code source dupliqué pour chaque pays 😒
Aucune de ces solutions ne permettant d’adresser le besoin, nous sommes repartis d’une solution from scratch en Angular (aujourd’hui en V7) avec ces souhaits techniques :
- Single page application
- langage typé
- héritage
- gestion native des traductions
- une seule solution, maximiser la factorisation du code
On note que côté backend, les tunnels communiquent avec une seule web api .NET codée en C#.
Build
Dans notre fichier angular.json, nous décrivons les 9 sites à construire :
Voici le nœud “fr” pour le tunnel français desktop :
On note qu’un membre de l’équipe a développé une extension VsCode pour gérer le multi-projet:
Organisation des modules
le champs “main” de la définition du projet, nous permet de définir le bootstrap du module principal:
Et dans ce module français desktop, nous y définissons l’entité légale, la locale, les formats, le type de device, les services et composants spécifiques à la France et les modules à importer :
AppModule|_ bootstrap : DesktopAppComponent (root component)|_ imports :
FR desktop FunnelStepsModule
FR routing module
shared components & service|_ providers :
provide: CREDIT_APPLICATION_CONTEXT,
useValue: CreditApplicationContexts.France provide: DEVICE_TARGET,
useValue: DeviceTargets.Desktop
...
Customisation d’une étape du tunnel
Si nous prenons l’exemple de l’étape de situation familiale du tunnel, nous allons définir les règles métier communes à tous les pays dans un classe abstraite “BaseFamilySituationStepComponent”.
La version française “FrFamilySituationStepComponent” va hériter de la classe de base abstraite, nous pouvons y définir le template, le style et la logique d’affichage de la version française :
Ce sera ce composant qui sera associé à la route française de l’étape de situation familiale.
Test unitaires
Tout comme le reste du code, nous partageons le code des test unitaires :
fr.family-situation-step.component.spec.ts
shared.family-situation-step.spec-helpers.ts
Ainsi, tous les test communs sont testés dans chaque contexte support et régional.
Gestion des traductions
Nous avons choisi d’utiliser l’ internationalisation i18n native. Nous plaçons donc nos attributs i18n dans les templates html :
Ils seront remplacés lors de la compilation en se basant sur les fichiers de traduction xlf :
Un membre de l’équipe a développé l’indispensable extension VsCode pour gérer facilement l’i18n :
Angular CDK Portals
Parfois l’utilisation de l’héritage de composant est trop lourde en terme de boilerplate pour customiser une partie du Template. Voici un exemple de la customisation du logo :
Html du composant :
Code du composant :
Organisation de l’équipe
Nous avons commencé par présenter à toute l’équipe la proposition d’architecture lors d’une séance de mob programming. Le code de la mise en place et de 2 étapes du tunnel avait été préparé à l’avance. Le but était de le re-coder tous ensemble pendant une semaine. Ainsi tous les concepts ont pu être compris et challengés.
Ensuite le focus a été mis sur un seul contexte : France desktop. Assez rapidement après (2 semaines) nous avons démarré la version desktop italienne en parallèle et ainsi de suite.
Conclusion
La solution technique a su répondre au besoins métiers et techniques :
- les tunnels sont stables : pas de régression majeure, pas de divergence de code.
- l’ajout d’un nouveau pays s’est effectué sans douleur et rapidement
Bien sûr, nous étudions la prochaine version V8 d’Angular et son nouveau moteur “Ivy” qui va permettre de faire du lazy-loding des traductions i18n ! Plus rien ne va donc nous empêcher de compiler un seul livrable pour tous pays et supports.
La suite au prochain épisode !
