Une interview de la QE Unit partageant l’histoire de Lovys, de start-up à scale-up, où la Qualité a fait la différence.
João Macedo Pinto est le CTO de Lovys, une entreprise qui révolutionne l’assurance traditionnelle en proposant une solution numérique tout-en-un dans un modèle d’abonnement mensuel.
Cette interview partage les différentes étapes de la croissance de la pratique d’ingénierie de Lovys et comment elle a dû accompagner la croissance de l’entreprise durant ses différentes phases.
L’investissement en qualité logicielle et ingénierie de qualité a permis à Lovys de poursuivre sa croissance, montrant la valeur d’un investissement dans une qualité holistique.
Rejoignez la QE Unit pour accéder à du contenu exclusif à la communauté.
À propos de João Macedo Pinto
Dédié à l’alignement de la technologie sur les besoins réels de l’entreprise.
Chez Lovys, nous créons un nouveau concept d’assurance tout-en-un, permettant aux gens d’avoir une interface simple pour tous leurs besoins de protection, de l’intégration aux sinistres, et de payer un seul abonnement mensuel au lieu du mélange compliqué existant.
Il a cofondé et développé Prometheus chez UpType, une solution de gestion en ligne qui organise, compile et analyse automatiquement les données d’une entreprise avec pratiquement aucun coût d’intégration.
Expérience internationale en Business Intelligence, Data Warehousing / Ingénierie et développement de logiciels, ainsi que du conseil pour l’industrie des télécommunications, du commerce électronique, gouvernance et de la santé (Angola, Nigeria, France, USA), de la gestion d’équipe et de projet.
Antoine : Peux-tu commencer par te présenter ?
Je suis actuellement CTO chez Lovys, une InsurTech qui opère dans le domaine de l’assurance. En plus du travail, je suis père de deux enfants avec une belle femme qui est très occupée dans cette période du COVID !
Chez Lovys, j’ai le sentiment que nous avons fait un parcours intéressant dans le domaine de la QA (Quality Assurance). Pour le mettre en contexte, Lovys n’est pas une compagnie d’assurance traditionnelle : c’est une entreprise basée sur la technologie pour rendre l’assurance disponible à tous via une plateforme numérique. Lovys cible de faire avec l’assurance ce que les néo-banques ont fait dans le domaine financier il y a quelques années. Nous avons les exemples de Revolut, N26, Activobank qui ont apporté le mode 24/7 au secteur bancaire, très différent du paradigme existant.
Nous changeons les habitudes tant en termes de processus que de digitalisation. Notre devise est précisément « L’assurance numérique pour tous », consommée par le biais du digital. Il y a deux facteurs de différenciation chez Lovys : nous sommes multi-produits adaptés à la géographie, et nous sommes multi-pays. Nous proposons actuellement quatre produits de base, un autre en France, et par exemple une assurance smartphone au Portugal. Cette logique géographique implique une expansion qui aura lieu dans les prochains mois, que je ne peux pas encore révéler 🙂
Nous vendons des assurances sous un modèle d’abonnement avec une seule mensualité, quel que soit le nombre de polices et d’options. Les clients ont la possibilité d’activer ou de désactiver les services et peuvent interagir avec Lovys à tout moment.
Antoine : Ce modèle 100 % digital crée donc une forte pression sur la disponibilité des plateformes, et in fine sur l’IT ?
Toutes les entreprises numériques ont une exposition 24h/24 et 7j/7 où les services doivent être disponibles. La continuité d’activité est un thème phare pour nous ; nous devons nous assurer que nous sommes en ligne en 24/7, sur tous nos canaux et plateformes. Nous proposons des contacts directs pour nos clients : 2 sites web, 2 applications natives et 1 back-office.
Notre offre étant très libre-service, laissant le client interagir avec son assurance sans passer par un guichet, cela renforce la criticité des dispositifs. L’application doit toujours fonctionner, et pas seulement le front-end mais bien l’ensemble de l’écosystème. C’est un énorme défi, en cas d’échec, l’exposition est très impactante, elle n’affecte pas qu’une seule rue.
Antoine : Quels sont les éléments clés de votre architecture pour fournir cette plateforme numérique ?
Premièrement, comme la plupart des start-up et des scale-up, nous utilisons plusieurs fournisseurs de services Cloud . Nous sommes présents sur Google, Azure, et AWS pour différents besoins. Google Cloud Platform est utilisé pour le Data & Analytics, AWS pour la R&D, tandis qu’Azure supporte 90 % des services coeurs.
D’un point de vue architectural, nous partons d’un monolith en voie de modularisation. La séparation suit une approche par domaine, en Domain Driven Design (DDD), où nous identifions les domaines monolithiques associés à l’entreprise. Le but de cette évolution est de permettre au processus de développement et aux équipes d’évoluer. Une base de code a une limite sur le nombre de développeurs qui peuvent collaborer en même temps. C’est là que la ségrégation nous permet d’allouer plus d’équipes sur différentes bases de code.
Au niveau des technologies, nous utilisons beaucoup la stack Microsoft, en particulier .NET Core. Sur le Front-end, nous utilisons Vue JS, Angular, Swift ou Kotlin pour créer des expériences adaptées. Nous avons plusieurs équipes de développement avec un mélange d’expertise, d’expérience et de localisation qui finissent par créer des partages intéressants. De nombreuses améliorations structurelles sont venues de points de vue divergents, je suis convaincu de la valeur de cette mixité.
Antoine : Tu évoquais un parcours intéressant de QA chez Lovys, comment s’inscrit-il ?
En réalité quand nous avons commencé, c’était sans qualité officiellement formalisée. Nous avons eu beaucoup de pression pour créer le produit où les développeurs étaient les principaux contributeurs. Après cette première phase, une première séparation est apparue entre le front et le back-end. Lovys opère sur divers marchés, à des bureaux dans plusieurs pays, c’est dans notre ADN.
Notre équipe back-end était située à Leiria, le front-end complètement déporté en Ukraine. C’est à ce moment-là que j’ai rejoint l’entreprise, j’ai assez vite ressenti le besoin de QA. Nous avons fait un grand saut dans la maturité de l’organisation; nous avons maintenant des full-stack squads, avec de petites unités ayant toutes les compétences nécessaires. Il y a eu une phase où l’équipe Produit n’était pas intégrée, que nous avons fini par rapidement récupérer. Nous sommes maintenant à ce que nous appelons un niveau de maturité 4, avec un Talent Pool pour chaque type de poste, que nous avons composé par missions. C’est le modèle d’organisation qui jusqu’à présent nous a permis de mieux répondre aux besoins et aux projets.
Antoine : Vous avez investi dans la qualité ; nous investissons généralement notre argent pour résoudre un problème. Quel était le vôtre ?
La QA est venu comme une douche froide : le nombre de bugs augmentait considérablement. Au troisième trimestre de l’année dernière, nous avions 74 bugs enregistrés sur le système, et au quatrième trimestre, il y en avait 170, soit une augmentation d’un facteur de 2,5. C’est arrivé non pas par une détérioration forte de la qualité des développements, mais par la forte accélération que nous avons eue. Les bugs ont grandi de la même manière que notre base de fonctionnalités, de code et d’équipes.
Nos cycles de livraisons prévoyaient une période de stabilisation après les déploiements équivalente au temps de développement. Il fallait agir. Chaque nouvelle version avait des impacts sur les services, nécessitant des correctifs en live. Cette problématique était le début d’un cercle vicieux, nous impactions fortement le développement des fonctionnalités à venir. Les équipes devaient se concentrer sur la stabilisation, ce n’était pas facile à déployer ou de réaliser des rollbacks impliquant des changements de code.
« Nous ne voulions pas d’un bataillon de testeurs en bout de chaîne ; nous avons voulu résoudre les problèmes à la racine, dès le début. »
João Macedo Pinto
Nous avons été confrontés à plusieurs sujets pour résoudre le problème de la qualité. Nous n’étions pas seulement concentrés sur la qualité à la fin de la chaîne, nous voulions une qualité intégrée dès le départ. De ce fait, nous ne voulions pas d’un bataillon de testeurs pour tester en environnement hors production; cela n’allait pas résoudre les causes racines, limitantes à la croissance de l’entreprise. Nous voulions inclure la qualité dans les différentes étapes de nos processus Agile, au plus tôt possible.
Nos équipes de développement rencontraient de réelles difficultées tout au long de la chaîne.
Antoine : Étiez-vous en fait confronté aux facteurs limitants de votre système de développement ?
Clairement, nous ne pouvions plus suivre le besoin croissant de développement, sans non plus fournir l’expérience utilisateur (UX) ou le niveau de service convoité.
Le grand défi est que nous n’avions pas de compétences de QA internes; nous ne pouvions pas avancer seul. En parallèle, nous étions submergé de demandes avec un backlog plus que rempli. Être une start-up à à la recherche de capital-risque (VC), le produit doit être constamment prêt et dynamique. Le délai moyen de livraison d’une fonctionnalité est une métrique très importante dans ce contexte d’investissement. A ce stade il nous fallait 1 mois et demi à 2 mois pour stabiliser le site, ce n’était pas acceptable.
C’est cet exercice de réflexion qui m’a amené à « appeler un ami ». La majeure partie de l’équipe d’ingénierie était à Leiria et nous avons opté pour une solution de proximité avec la société atale.io, qui se trouvait dans le même espace de bureau.
« Le grand défi pour permettre à l’entreprise d’avoir une assurance qualité était le manque de compétences internes et un backlog qui ne désemplit pas. »
João Macedo Pinto
Nous avons ciblé d’adresser l’ensemble des problématiques de qualité, depuis les fondations jusqu’à l’accélération tant recherchée. Nous sommes intervenus dans de nombreux domaines, en examinant les processus de développement de logiciels pour y inclure la qualité dès le début ; nous avons demandé de l’aide pour trouver, former et accompagner la création de notre équipe et pratiques de QA.
Il y a eu un effort d’évangélisation avec les équipes de développement, la qualité ne commence ni ne s’arrête avec les tests unitaires.Bien que nous ayons une bonne couverture, cela ne résout pas tout, notamment les problèmes d’intégration. Cette prise de conscience était importante pour les différents acteurs impliqués dans la chaîne de valeur.
Nous avons mis en place des pipelines de Continuous Integration et de Continuous Deployment (CI/CD) à un point de maturité que je ne m’attendais pas. Nous avons des standards de quality gates, reviews, déploiement progressif, rollback et les liens avec les user-stories. Ces fondations et modèles nous aident à la distribution du système, nous avons déjà une recette prête à l’emploi pour les nouveaux développements.
Antoine : Avez-vous inclus les équipes QA dans les processus, rituels et autres mécanismes de collaboration ?
Oui, nous travaillons avec des cérémonies Agiles sans être dans un pur modèle Scrum. La QA fait partie des différents moments de partage entre les équipes. La QA a son mot à dire dans toutes les étapes du processus, pas seulement à la fin. La QA cesse d’être une touche finale pour devenir une partie intégrante de l’ensemble des processus.
“La Qualité a son mot à dire à chaque étape du processus.”
João Macedo Pinto
Nos premiers ingénieurs de QA ont mis un accent particulier sur l’automatisation afin de garantir la couverture des différents domaines déjà présents. Nous nous sommes engagés dans une automatisation pondérée pour capturer la valeur de cet investissement initial et continu dans la maintenance. Nous établissons des priorités en fonction des domaines du produit les plus critiques, essentiels et changeants. C’est le cas du tunnel de conversion, de la création d’un compte, ou de l’abonnement en libre-service, indispensables à nos clients. Nous bénéficions d’une grande confiance dans la stabilité de ces services même avec des modifications apportées.
Antoine : Ce point de confiance que vous évoquez est intéressant ; la valeur de la qualité n’est pas seulement technique ou dans des tableaux de bord. Y a-t-il une part humaine liée à la confiance et à la relation entre Business et IT ?
On peut avoir tous les tableaux de bord du monde, les KPI, les feux tricolores ; certains indicateurs et partages font plus la différence que d’autres. Cette relation de confiance est progressive. Cela commence par « Ce que vous voyez », un site Web qui fonctionne, « Est La Réalité », sur un tableau de bord au vert. Si tout est au vert avec un site Web qui ne répond pas, nous avons un problème. C’est d’ailleurs un point d’attention pour nous, nous limitons le nombre de dashboards pour limiter la complexité et les faux négatifs.
« La relation de confiance est progressive, en montrant l’alignement entre le Business et l’IT. »
João Macedo Pinto
Nous utilisons un certain nombre d’outils différents pour y parvenir. L’outil d’automatisation des tests est Katalon, en mode low-code. C’est un outil relativement puissant, il nous permet d’automatiser les tests pour les plateformes web, mobile native, API, en gardant une flexibilité de scripting. Nous pouvons avoir une approche data-driven avec des fichiers Excel contenant les cas de tests. Katalon TestOps est le module où nous avons les rapports disponibles.
Nous avons une intégration avec notre outil de tâches, Azure DevOps. Au moment où nous référençons les tests liés aux user-stories, nous pouvons obtenir le statut des vérifications dans les exécutions du pipeline. Azure DevOps est plus qu’une gestion de backlog, c’est une verticalisation soutenant le processus de développement. La solution fournit le backlog, le repository de code, les pipelines CI/CD, les cas de test et le référentiel d’artefacts. Cette intégration nous permet d’avoir une vue intégrée entre les exigences, le développement et les livraisons. Pour obtenir une meilleure visibilité, nous souhaitons utiliser la notion de cas de test Azure DevOps.
Antoine : Quel bilan pouvez-vous tirer de cet investissement, de cette expérience et de ces résultats ? Le problème initial est-il résolu ?
En résumé, nous avons une grande confiance dans la robustesse de nos solutions. Les termes sont valables aussi bien pour la part du destinataire, le Business, que du producteur, l’IT. Aujourd’hui, le business sait qu’elle va obtenir quelque chose de stable, tandis que l’IT sait qu’elle peut détecter les anomalies et les corriger en temps et en heure.
« Aujourd’hui, nous sommes confiants dans la robustesse de nos solutions. »
João Macedo Pinto
Tout cet investissement nous a permis de livrer le site à temps et sur lequel nous avions eu de réelles difficultés. Nous arrivons à livrer régulièrement sans downtime et un nombre très faible de défauts; par rapport à l’ancien volume, ils sont même résiduels. Pour nous, en tant que start-up qui se transforme en scale-up, augmenter notre capacité d’exécution et d’ingénierie est essentiel Nous pouvons aujourd’hui agir rapidement sans avoir peur de casser ce qui existe.
Antoine : L’objectif est donc bien de pouvoir soutenir le rythme de transformation et de changement dans l’entreprise ?
Exactement, je peux aujourd’hui contribuer à transformer le visage de l’entreprise, son entrepôt, ses opérations avec peu de risques de défauts. Je le dis avec une grande confiance, nous avons une couverture qui le permet.
Bien sûr, l’assurance qualité seule ne suffit pas. Il existe de nombreux processus interconnectés qui contribuent à cette capacité, la qualité doit être résolue. globalement, dans une perspective holistique, intégrée dans les différents processus. J’associe par exemple la notion de qualité au fait qu’une user-story ait des critères d’acceptation bien rédigés et clairs . La qualité n’est pas seulement une question d’automatisation, il ne s’agit pas seulement d’écrire des tests, elle doit apporter une valeur ajoutée à d’autres domaines.
« Il faut être attentif aux premiers signaux faibles, sans les sous-estimer. »
João Macedo Pinto
Détecter, décider et agir rapidement est fondamental, surtout dans cet écosystème de start-up où la notion de coût/opportunité est très importante. Le temps que nous pouvons perdre en rework a beaucoup plus de valeur s’il est appliqué sur le développement de l’entreprise. De temps en temps, faire des raccourcis peut être nécessaire, en gardant à l’esprit que le coût de la facture va être beaucoup plus élevé par la suite.
Un conseil que je donne est d’inclure la qualité le plus en amont, d’une démarche et des divers processus.
Comme nous l’avons identifié, il s’agit de trade-offs. Dans ce contexte de start-up il n’y a pas de règle unique, il faut choisir et s’adapter en fonction du contexte. Maintenir la transparence et communiquer les impacts des décisions que nous prenons est très important. Encore plus lorsque nous devons faire un raccourci sans QA, le compromis doit être visible.
La QA aide dans cet aspect de communication. Elle ramène sur la table une série d’éléments dus à l’observabilité qu’elle procure. Cela supporte l’amélioration continue des processus.
Antoine : Cette communication permet-elle d’atteindre toutes les parties prenantes ?
Nous pouvons utiliser l’exemple d’un nouveau bouton sur l’interface. Si on se contente de répondre qu’il faut une semaine dans la seule perspective de développement, la personne pense « Une semaine pour mettre un bouton ? Es-tu sérieux? ». Considérant que ce changement implique une implémentation sur divers devices, plateformes, des tests, gérer les différents cas nominaux et d’erreur, la perspective change. Être ouvert, créer un espace de discussion avec un langage commun facilite la collaboration.
Antoine : Quelles sont vos perspectives, priorités et axes de travail ?
Grâce à l’investissement réalisé en conseil pour créer cette capability de qualité, nous avons pu travailler avec une équipe relativement junior. La priorité est de compléter notre Talent Pool de QA avec des profils plus seniors afin d’étendre le modèle et son impact dans l’organisation. Nous devons supporter la croissance et prévoyons de doubler nos effectifs d‘ ici la fin de l’année.
Une partie importante de mon travail consiste à recruter ; pouvoir collaborer avec les différents éléments afin de tracer un chemin partagé.
Désormais, c’est une question de rapidité et de qualité d’exécution, sans retour arrière.
References
Lovys, « La première assurance que vous allez adorer » : https://www.lovys.com
Atale.io, l’entreprise qui a soutenu Lovys : https://atale.io
Katalon et Katalon TestOps : https://katalon.com ; https://www.katalon.com/testops/
Azure DevOps : https://azure.microsoft.com/en-us/services/devops/