Article co-écrit par Laura POUDEVIGNE et Anne JACQUET.

La start-up kwiper est issue d’un programme d’intrapreunariat de la Société Générale. Nathalie et Thibaut, ses deux dirigeants, ont fait appel à Ippon il y a un peu plus d’un an afin de poursuivre la conception et le développement de leur solution en vue de sa commercialisation.

Avec son produit, kwiper met à disposition des experts comptables un outil leur permettant d’être accompagnés dans le conseil patrimonial auprès de leurs clients. L’idée de la plateforme est née du constat que les solutions numériques sont insuffisantes dans ce domaine.

Nous sommes deux développeuses de l’équipe technique de kwiper et nous souhaitons donc revenir sur cette année enrichissante afin de présenter les défis techniques et organisationnels rencontrés et les réponses apportées pour mener ce produit à un stade commercialisable, viable puis extensible.

Cet article est le premier d’une série de trois articles. Il présente l’organisation de notre équipe, le métier de kwiper ainsi que les principales décisions techniques qui ont été prises pour concrétiser le projet et le mener à sa commercialisation en moins d’un an. Les articles suivants se concentrent sur la mise en place de la sécurité pour en faire un produit viable et sur le travail réalisé côté développement pour en faire un produit extensible.

Notre organisation

Suite aux premiers mois de maturation de l’idée et aux premières phases de prototypage de l’application, les deux cofondateurs ont souhaité gagner en souplesse dans les processus de spécification et de développement.

Pour répondre à ce besoin, Ippon a construit une équipe aujourd’hui composée de quatre développeurs, d’un Ops et d’un Product Owner.

Afin d’être flexible, nous nous organisons en itérations de deux semaines au cours desquelles l’équipe participe à différentes cérémonies agiles : sprint planning, daily, sprint review et backlog refinement. Cette dernière cérémonie est essentielle. Lors des premiers sprints, nous n'organisions pas de backlog refinement, les user stories étaient découvertes au moment de les chiffrer. Cela pouvait conduire à une mauvaise estimation pour les user stories complexes qui auraient gagné à être redécoupées ou redéfinies. C’est pour cette raison, et pour rendre les réunions plus efficaces, que nous avons décidé de parcourir toutes les nouvelles user stories quelques jours avant d’organiser le prochain sprint. Cela nous permet, en tant que développeurs, de poser toutes les questions au Product Owner et, le cas échéant, de faire une analyse technique de la solution à implémenter.

Le Product Owner est l’interlocuteur privilégié du client pour définir les fonctionnalités et leur priorité mais l’équipe de développement échange aussi beaucoup avec les référents métier. Ainsi, pour les fonctionnalités clés de l’application, nous avons commencé par échanger tous ensemble. Cela donne l’occasion à l’équipe de s’imprégner des enjeux et du gain pour l’utilisateur final et de proposer des solutions pour répondre au besoin.

Les experts de kwiper ont aussi pris le temps de nous former aux différents aspects de l'ingénierie patrimoniale présents dans la plateforme. Ces formations nous ont permis de comprendre l’intérêt du contrat d’assurance-vie, le fonctionnement des donations aux enfants,  ou encore comment l’anticipation de la transmission de son patrimoine permet de limiter les droits de succession. Pour comprendre en quoi cela nous était nécessaire, voyons ce que propose l’application.

Le métier de kwiper

La plateforme kwiper est une application web qui guide l'expert-comptable dans ses missions de conseil patrimonial au travers de trois piliers.

L'utilisateur se forme tout d’abord à travers le kampus. Il y découvre des tutoriels pour savoir quoi proposer à son client. Il consulte les fiches thématiques pour connaître le fond juridique et fiscal puis il voit l’application concrète à travers les cas pratiques.

Il passe ensuite au Diagnostic en saisissant des données générales sur son client, ce qui lui permet d’obtenir très rapidement un document de synthèse au format PDF. Ce dernier offre une vision d’ensemble de la situation patrimoniale du client.

Enfin, l’expert comptable, utilisateur de la plateforme, remplit des données complémentaires, plus détaillées, pour obtenir une Stratégie personnalisée. Pour générer ce document, il doit valider des objectifs mis en avant par la plateforme et naviguer au sein d’un ensemble de suggestions adaptées au client. Ces suggestions et leurs impacts économiques sont détaillées dans un document final au format Word.

Dans le cadre des suggestions, selon les spécificités de chaque client, la plateforme met à disposition des moteurs de calculs. Nous pouvons citer par exemple le calcul sur les droits de succession au moment d’un décès, le calcul de l’impôt sur la plus-value mobilière et immobilière ou le calcul des droits de donation.

Tous ces services sont mis à disposition des utilisateurs au travers de l’application web de kwiper. Le produit étant en pleine naissance, il est amené à évoluer à un rythme soutenu tout au long des sprints. Les déploiements sont donc fréquents pour apporter de la valeur aux utilisateurs, tout en prenant en compte leur feedback. Ainsi l'utilisation du Cloud et d'outils d'Infrastructure as Code nous permet de construire rapidement un environnement de production robuste pour héberger l'application, en gardant la souplesse de bénéficier d'une panoplie de services pré-intégrés. Rentrons maintenant dans le vif du sujet : à quoi ressemble l’infrastructure permettant de proposer ces fonctionnalités ?

Infrastructure de l’application

La plateforme est une application web composée de :

• deux front-end développés avec Angular 10 (TypeScript 3),  l'un pour la plateforme des experts-comptables, l'autre pour le back-office des administrateurs kwiper ;
• onze services back-end dockerisés, développés avec Spring Boot 2 (Java 11).

L’hébergement de l’intégralité de l’application est fait sur AWS, en s’appuyant notamment sur les outils serverless proposés par l’hébergeur. Le déploiement et l’intégration continue sont aussi effectués au sein d’AWS.

Infrastructure de la plateforme kwiper

Les applications front-end sont hébergées sur un bucket S3, sans accès public, diffusées uniquement par CloudFront. CloudFront est le CDN (Content Delivery Network) d’AWS, il est composé d’un ensemble de serveurs répartis géographiquement de manière à accélérer la diffusion des contenus.

Les services back-end sont dockerisés et forment un cluster ECS. Le provisionnement des containers est délégué à AWS à travers l’utilisation de Fargate. Le back-end de l’application est ainsi déployé comme un cluster de conteneurs Docker.

Pour exposer les services à l’extérieur, le service Elastic Load Balancing est utilisé. Ce service permet de répartir le trafic entrant vers plusieurs cibles. Dans notre cas, le load balancer fonctionne au niveau de la couche application et utilise le contenu de la requête pour la diriger vers sa cible. En fonction de l’URL, la requête sera dirigée vers un des conteneurs du cluster ECS.

Enfin, deux autres services managés sont utilisés pour le fonctionnement de l’application :

• RDS PostgreSQL pour la base de données ;
• S3 pour le stockage des fichiers générés par la plateforme.

Toute cette infrastructure est codée et déployée grâce à Terraform.

Optimisation des coûts

La maîtrise des coûts étant un des points d’attention d’une start-up, nous avons cherché des leviers d’optimisation.

Un exemple de diminution des coûts réalisés à notre arrivée sur le projet est la factorisation des load balancer. Il existait avant un load balancer par service, nous avons maintenant un seul load balancer pour tous les services back-end.

Au-delà de ces optimisations spécifiques, la simple utilisation du Cloud et de l’Infrastructure as Code a permis de diminuer les coûts opérationnels liés à l’infrastructure, tout en rendant les développeurs autonomes sur le sujet. L’équipe peut se concentrer sur la valeur à apporter aux clients de kwiper plutôt que d’être sollicitée sur des problématiques de maintenance. Cela permet aussi d’être flexible sur les environnements et les déploiements. Par exemple, nous avons décidé d’arrêter automatiquement l’environnement intégration, destiné aux développeurs, en dehors des heures d’utilisation.

Maintenant que nous avons en tête l’infrastructure sur laquelle s’appuie la plateforme, nous allons parcourir quelques problématiques qui ont nécessité une réponse technique spécifique.

Briques applicatives externes

La conception d’une solution, qui plus est pour une start-up, requiert de constamment chercher l’équilibre entre solution personnalisée et utilisation de services existants. À plusieurs reprises nous avons fait le choix d’utiliser une solution existante afin d'optimiser le time to market.

Prestataire de paiement

L’utilisation de la plateforme est payante et kwiper a mis en place une stratégie de facturation sur 3 axes. Tout d’abord, un abonnement mensuel donne accès à la plateforme. Le reste dépend de l’utilisation des services : les diagnostics et les stratégies sont facturés à l’unité.

Afin d’accélérer le time to market mais aussi pour se concentrer sur le métier et la valeur ajoutée de kwiper, nous avons décidé d'utiliser Stripe pour gérer cette facturation. C’est un prestataire de paiement en ligne qui prélève un pourcentage sur chaque paiement et qui revendique des millions d’utilisateurs.

Nous avons choisi cette solution car elle répondait à tous nos besoins tout en offrant une API simple d'utilisation et très documentée. Le choix s’est porté sur un produit plus spécifique : Stripe Billing. Ce service offre, en plus du paiement en ligne, la gestion des abonnements (paiements récurrents) et des factures.

Cette solution sécurisée et répondant à nos besoins a rapidement été mise en place et nous avons pu nous concentrer sur le cœur de métier de kwiper.

Calcul d’impôts sur le revenu

Parmi le grand nombre de simulateurs de calculs d'impôts proposés par kwiper, se trouve celui de l’impôt sur le revenu.

Toujours dans l’optique de réduire le time to market et de se concentrer sur des services innovants qui n’existent pas encore sur le marché, nous avons pris la décision de ne pas développer ce simulateur mais plutôt d’en utiliser un existant. Notre choix s’est porté sur OpenFisca, un projet open source soutenu par le gouvernement.

Afin de maîtriser totalement la disponibilité de l’API, nous avons décidé d’héberger une instance de cette application Python dans notre infrastructure.

CMS

En plus de commercialiser rapidement la solution, kwiper a besoin de flexibilité sur l’application une fois en production. En outre, un des services proposés par la plateforme est la mise à disposition du kampus : un ensemble de fiches thématiques contenant des informations juridiques et fiscales. Ce kampus doit être fréquemment mis à jour et enrichi de nouveaux contenus.

Afin de donner un maximum de liberté aux gestionnaires de kwiper dans la création et l’alimentation du kampus, nous avons décidé de mettre en place un CMS. Notre choix s’est porté sur Directus, un CMS headless, qui offre une interface pour la saisie du contenu ainsi qu’une API pour délivrer ce contenu.

Pour protéger l’accès à ces fiches, un des services Spring Boot fait office de point d’entrée vers Directus afin de limiter l’accès aux utilisateurs connectés.

Le CMS nous permet également d'afficher des contenus commerciaux ou promotionnels, ainsi que des messages lors des phases de maintenance de l’application. De manière générale, cela rend l’équipe commerciale indépendante sur les contenus textuels ou visuels appelés à changer souvent en leur permettant de modifier ces éléments à travers l’interface de Directus.

Signature électronique

Lors de sa première connexion, l’utilisateur doit signer les conditions générales d’utilisation de la plateforme. Pour respecter une contrainte juridique, nous avons mis en place la signature électronique certifiée par un tiers de confiance.

Nous avons choisi pour cela le service proposé par Universign. Il permet de prouver l’intégrité du document grâce à un horodatage ainsi que d’authentifier le signataire via l’envoi d’un code par SMS. Le document signé est ensuite stocké sur S3.

Nous venons de présenter les premiers éléments de réponses aux enjeux de kwiper : l’infrastructure supportant l’application et quelques-unes des décisions techniques. Ces éléments sont résumés ci-dessous.

Briques applicatives de kwiper

On peut remarquer sur le schéma un élément qui n’a pas été cité jusque-là : HashiCorp Vault. Cet outil est utilisé pour chiffrer les données sensibles stockées dans AWS. Pour plus de détails sur les aspects liés à la sécurité dans cette application, nous vous invitons à lire le deuxième article de ce retour d’expérience qui sera publié le 29 janvier 2021.

L’application est entièrement hébergée sur le Cloud AWS et fait appel à plusieurs services tiers. Cela nous a permis de répondre au premier besoin de kwiper : commercialiser rapidement l’application, sur une infrastructure robuste. Les autres axes de travail ont été la sécurisation de l’application, comme cité plus haut, et le développement de nouvelles fonctionnalités tout en garantissant la qualité et l’évolutivité de l’application. Cet aspect est décrit dans la troisième partie de ce retour d’expérience dont la publication est prévue le 1er février 2021.