Introduction
Ce projet de plateforme hypothécaire en ligne auquel j’ai participé représente indubitablement l’apogée de ma carrière professionnelle, il s’est passé 6 ans entre mon tout premier job en tant que développeur indépendant et la concrétisation de cette plateforme d’hypothèque, qui a d’ailleurs été récemment mise en lumière par un reportage de renom, l’ICT Journal.
Sollicités par la banque Crédit Agricole Next Bank (CA next bank), nous avons été mandatés pour réaliser un projet d’envergure qui avait été relégué aux oubliettes depuis un certain temps. La raison pour laquelle la banque ne souhaitait pas confier cette tâche à son équipe interne d’experts en technologies de l’information résidait dans leur manque de flexibilité et de vitesse, deux caractéristiques essentielles pour le secteur bancaire, mais peu adaptées au développement web.
Analyse préliminaire
Dans un premier temps, notre mission consistait à concevoir un POC (proof-of-concept) visant à identifier et à anticiper tous les problèmes auxquels nous pourrions être confrontés lors de la phase de développement effective. Nous avons ainsi pu apporter des correctifs préliminaires, garantissant ainsi le déroulement optimal du projet. Sans entrer dans les détails, nous avons identifié plusieurs risques majeurs et élaboré des solutions adaptées.
Après avoir identifié clairement les risques et prévu des solutions correspondantes, nous avons entamé le développement avec un bon élan. Toutefois, nous n’avions pas anticipé un risque majeur, qui s’est révélé plus complexe que prévu et pour lequel nous n’avions pas de solution claire : la complexité des choix et des options possibles !
Complexité
En effet, notre objectif était de concevoir une plateforme où chaque réponse apportée influencerait les questions suivantes. Bien que cela puisse sembler facile à réaliser avec Symfony, j’avais déjà mis en place un tel système pour l’ouverture de compte en ligne pour une autre banque, il était clair que nous étions confrontés à une tout autre échelle cette fois-ci. Il ne s’agissait plus simplement de proposer quelques variations d’un parcours commun, mais bien d’interconnecter chaque réponse avec les 400 autres questions. Pour vous donner une idée de la complexité absurde à laquelle nous avons été confrontés, les règles d’affichage ressemblaient à ceci :
| # | Question | Affichage | Choix | Spécificités |
|---|---|---|---|---|
| 1 | Type de projet | Toujours | Achat, Reprise, Construction, Rénovation, Autre | - |
| 2 | Déjà trouvé | Si #1 = Achat | Oui, Non | - |
| 3 | Travaux | Si #1 = Reprise ou #2 = Oui | Oui, Non | Si #1 = Reprise, changer le libellé |
| 4 | Pays | Si #1 = Construction ou Rénovation ou #2 = Non ou que #3 est rempli | Pays | Si #2 = Non, changer le libellé |
| 5 | Usage | Après #4 | Types de résidences | - |
| 6 | Résident Suisse | Après #5 ou directement après #1 si #1 = Autre | Oui, Non | - |
Avec plus de 400 questions et des règles aussi complexes, notre approche initiale, consistant à utiliser les événements de formulaire de Symfony pour générer dynamiquement les questions, s’est avérée inefficace. Même après avoir intégré seulement les dix premières questions, nous nous sommes retrouvés submergés par des conditions if imbriquées jusqu’à des profondeurs abyssales, qui nous empêchaient d’avancer.
Il a fallu trouver rapidement une solution répondant à plusieurs critères :
- Ne pas être confronté à une complexité exponentielle au fur et à mesure que nous avancions dans les questions.
- Respecter toutes les règles spécifiées.
- Éviter les parcours incomplets.
- Être facilement compréhensible, évolutif et maintenable.
- Permettre la modification d’une question en milieu de parcours sans avoir à refaire entièrement le code du site.
GPS
J’ai donc décidé de prendre le problème à dans l’autre sens, de repenser la grille de règles et de questions sous un angle différent, et de développer simultanément un moteur de contrôle pour le système de génération de formulaires de Symfony, ainsi qu’un générateur qui produirait les règles pour le moteur.
Mon idée était la suivante : plutôt que de considérer le parcours utilisateur comme une succession de pages et de questions, j’ai cherché à l’assimiler à un système de navigation GPS un peu simpliste. Chaque question est une route, chaque réponse possible est un carrefour, et le rôle du GPS est de mémoriser les routes déjà empruntées pour anticiper les futures possibilités et identifier les voies désormais inaccessibles.
Cela signifiait que nous devions envisager les questions non pas comme une question = plusieurs options, mais comme un parcours utilisateur = une liste de réponses. Par exemple, voici quelques parcours possibles :
| # | Parcours | Question 1 | Question 2 | Question 3 | Question 4 |
|---|---|---|---|---|---|
| 1 | Achat en Suisse | Achat | Oui | Non | Suisse |
| 2 | Simulation | Achat | Non | - | Suisse |
| 3 | Reprise en Suisse | Reprise | - | Non | Suisse |
En isolant chaque parcours individuel, j’ai pu les fournir au moteur que j’avais développé précédemment, permettant ainsi de créer un arbre logique considérable comprenant chaque question, les choix possibles, et les questions suivantes en fonction des réponses sélectionnées, etc. Ce système permettait au moteur de gestion des formulaires de Symfony de suivre cet arbre, question par question, réponse par réponse, afin d’afficher les questions déjà répondues par l’utilisateur, la question suivante et les options disponibles.
De cette situation apparemment insurmontable devant la montagne, ou plutôt devant la planète de conditions if que nous devions intégrer, nous sommes passés à la simple gestion individuelle des parcours par le moteur “cartographeur”, qui a été en mesure d’identifier et de regrouper les embranchements communs, de créer un arbre et de le stocker sous forme de fichiers PHP prêts à être chargés par Symfony. Par la suite, le moteur de formulaire n’a eu qu’à jouer le rôle d’un GPS un peu simpliste, ignorant quelle est la destination finale, mais connaissant les étapes précédentes et le prochain carrefour à atteindre.
Conclusion
Pour vous donner une idée de l’efficacité du système, lors du tout premier sprint, celui où nous avons été confrontés à la complexité des règles à mettre en place, le diagramme de progression n’a pas évolué, et aucun ticket n’a réellement été résolu. Cependant, après la mise en place de ce système de GPS et de cartographie, nous avons pu terminer entièrement chaque sprint, le temps étant désormais consacré à l’isolation de chaque parcours individuel au lieu de coder les règles directement dans le code. De plus, l’arbre final nous permettait de parcourir plus de 650 millions de chemins différents…
En fin de compte, le projet s’est déroulé de manière extrêmement satisfaisante, et il a été l’expérience la plus passionnante sur laquelle j’ai eu la chance de travailler jusqu’à présent, un véritable coup de cœur ! Cette reconnaissance a été renforcée lorsque la plateforme a été mise en avant dans l’ICT Journal.
Depuis lors, je continue d’assurer la maintenance de la plateforme hypothécaire en ligne et d’ajouter de nouveaux parcours lorsque le client souhaite effectuer des évolutions.