Compte-rendu du Comptoir : Une vision de plateforme sans leadership tech n’est qu’hallucination
Le 20 juin 2023 s’est tenu un nouvel épisode des Comptoirs OCTO, suite à une réalisation d’OCTO Technology chez Wakam : Une vision de plateforme sans leadership tech n’est qu’hallucination.
Voici son descriptif :
La littérature promeut les plateformes digitales comme un levier de croissance pour les entreprises et un vrai avantage stratégique dans l’économie numérique.
Force est de constater que les entreprises qui se lancent dans cette aventure échouent : elles n’arrivent pas à dépasser le Proof Of Concept ou bien s’enlisent dans la paralysis analysis après des millions d’euros dépensés.
Nous vous partageons un retour sur l'expérience Wakam. Nous avons réussi à amorcer une dynamique pour construire une plateforme (tunnel de distribution en marque blanche, APIs, web apps, blockchain...) qui permet d’innover, de fournir des capacités métiers sous forme de commodité et d’assurer une expérience hyper personnalisable aux partenaires, en moins de 6 mois.
Voici le compte-rendu, ainsi que le replay vidéo (disponible ici), de ce comptoir animé par Etienne Debost (Head of Architecture chez Wakam), François-Xavier Bouffant (Engineering Manager chez Wakam) et Wassel Alazhar (Architecte @ OCTO), qui est intervenu chez Wakam.
Platform Strategy @Wakam
Wakam, anciennement la parisienne assurance, est un assureur qui existe depuis presque 200 ans et qui investit de plus en plus dans la tech pour accompagner sa forte croissance.
En centrant son modèle économique sur du B2B2C, Wakam a une stratégie business qui s’apparente à une plateforme qui met en relation plusieurs acteurs : d’un côté, les investisseurs et de l’autre côté, les distributeurs.
Wakam crée des produits d’assurance sur-mesure pour ses partenaires distributeurs (courtiers traditionnels, insure-tech, non-spécialistes de l’assurance…) qui commercialisent les produits d’assurance aux assurés finaux qui cherchent à se protéger contre le risque.
Pour supporter l’ensemble de la chaîne de valeur, Wakam a construit sa vision de plateforme technologique comme une composition de sous-plateformes spécialisées et ouvertes sur l'extérieur (en privilégiant une approche self-service).
Naissance d’une nouvelle plateforme
Vue de l’extérieur, la plateforme digitale de Wakam offre une expérience intégrée et plus ou moins uniforme aux partenaires, tout au long de leurs interactions avec celle-ci. Sous le capot, plusieurs écosystèmes autonomes et ouverts sur l'extérieur sont interconnectés et sont considérés comme des plateformes à part entière.
C’est dans cet environnement que les équipes d’Octo et Wakam ont pu construire une nouvelle plateforme (de Policy Admin System), et ont pu la mettre en service en 6 mois.
Cette nouvelle plateforme doit répondre à trois enjeux principaux :
L’innovation : Wakam réinvente son métier et se renouvelle continuellement. Elle fait le pari d’apporter plus de transparence en publiant les contrats d’assurances (ainsi que les actes de gestions liés) sur une blockchain publique. Ce pari a de nombreuses implications sur les processus métier qu’il faudra redécouvrir et repenser en même temps qu’on construit la nouvelle plateforme.
La commoditization : En ciblant en priorité les non spécialistes de l’assurance, cette nouvelle plateforme doit fournir des capacité de gestion clé en main qui exposent les processus métier en tant que commodité en abstrayant toute complexité.
La personnalisation : En s’adressant à un panel diversifié de partenaires (maturité tech hétérogène, canaux et stratégie de distribution variées…), la nouvelle plateforme doit leur offrir une expérience très personnalisable. Elle doit fournir des assets techniques modulaires (webapp, tunnel de vente marque blanche, APIs) afin que les partenaires puissent s’intégrer facilement.
En répondant à ces enjeux, la plateforme requiert un éco-système riche mais qui vient avec son lot de complexités.
Pour que de tels écosystèmes puissent se concrétiser, il faut faire face à 3 défis :
La “sur-spécification” : se mettre dans une dynamique de delivery en cycle court et éviter des cycles d’étude trop long en amont (aka analysis paralysis ou procrastination)
La “sur-spécialisation” : pouvoir passer à l’échelle (et éviter d'enchaîner des Proof Of Concepts trop simplistes)
Ne pas tenir compte de l’organisation.
Tech Leadership
Nous pensons que le leadership technique joue un rôle clé dans la concrétisation d’une vision plateforme.
Par leadership technique, nous faisons référence aux pratiques techniques à promouvoir pour des environnements propices à la création et à la réalisation.
Nous nous sommes appuyés sur 3 outils dans cette aventure :
Accelerate : 28 aptitudes (techniques, de process et culturels) pour un delivery performant et des organisations qui atteignent leurs objectifs.
Domain-Driven Design (DDD): une discipline de conception logicielle évolutive qui est centrée sur le métier (domaine fonctionnel).
Team topologies : un cadre de référence qui permet d’organiser les équipes de manière à optimiser le flux de delivery.
L’étude Accelerate démontre que les organisations qui atteignent leurs objectifs sont celles qui livrent le plus souvent et le plus vite en production, et elles sont également les plus stables.
L’étude explique également les 28 aptitudes qu’il faut développer pour améliorer la performance de delivery.
Nous allons faire un focus sur les aptitudes techniques, mais il est clair que nous avons bénéficié d’autres aptitudes qui nous ont été tout aussi utiles, comme par exemple :
Permettre aux équipe d’apprendre et leur donner la possibilité d’expérimentation en équipe
Travailler en lot réduits : concevoir avec les métiers et responsables produits le lot de fonctionnalité minimal viable à prioriser pour mettre en service rapidement afin d’éviter un effet tunnel
Le2 aptitudes techniques directement corrélées à la performance de delivery: “Cloud infrastructure” et “Continuous Delivery”.
Ce qui est intéressant à noter au sujet de ces 2 aptitudes c’est qu’elles sont souvent perçues comme des produits qu’il suffit d’acheter ou de contractualiser.
Il ne suffit pas de contractualiser avec un cloud provider, pour faire du cloud computing !
La première caractéristique du cloud computing, tel qu’il a été défini par le NIST, est “On demand self-service”: les consommateurs peuvent allouer des ressources informatiques selon leurs besoins, sans interaction humaine.
Cette caractéristique se trouve annihilée quand une équipe centrale gère les souscriptions cloud et qu’il faut leur ouvrir des tickets jira pour demander la ressource dont on a besoin.
Chez Wakam, les équipes sont autonomes sur leurs souscriptions et peuvent instancier à la demande les ressources dont ils ont besoin.
Les équipes sont encouragées à privilégier les services managés et à déployer leurs applications en conteneurisé sur du PAAS ou du FAAS et à privilégier les produits et protocoles open-sources. C’est une stratégie claire qui est communiquée à toutes les équipes et revues périodiquement.
On fait du Continuous Delivery et on ne peut pas l’acheter !
De même, souvent on réduit le continuous delivery à l’outil qu’on utilise pour orchestrer les pipelines ou jobs d’intégration continue (gitlab-ci, jenkins, Azure Devops, Github Actions…).
Accelerate nous démontre que livrer en continu nécessite de développer de nombreuses autres aptitudes techniques (12 précisément). Parmi elles, on trouve le trunk based development, le test en continu et les architectures modulaires faiblement couplées. Le Domain-Driven Design nous a été très utile par rapport à ce dernier point.
Lors d’un précédent comptoir, nous avons expliqué comment le DDD nous apporte des réponses concrètes pour favoriser un alignement à tous les niveaux (entre métier et techs et code) et nous avons vu des exemples de comment les équipes s’en servent au quotidien.
Aussi, les pratiques et techniques issues du DDD nous ont été d’une grande utilité pour décomposer la complexité (et la maîtriser), concevoir une architecture évolutive modulaire (qu’on maîtrise tout au long du delivery) et nous organiser efficacement.
Un des outils puissants que le DDD nous met à disposition est la modélisation en “Bounded Contexts” (Contextes délimités ou bornés). Le postulat de base est qu’un domaine métier complexe ne peut pas être efficacement exprimé par un modèle unique et avec un vocabulaire universel, et doit donc être séparé en “Bounded Contextes” (Contextes Délimités). Le DDD, pousse une approche qui s’oppose aux autres approches de modélisations universelles (ou canoniques) et leur préfère des modèles plus spécialisés.
Dans notre cas, nous avons pris le parti de contenir la complexité de “distribution des produits” indépendamment de celle de “l’opération des polices d’assurance”.
Lors d’une des premières sessions d’Event Storming, il nous a semblé évident que les problématiques que doit résoudre la nouvelle plateforme avaient des propriétés différentes avant et après l’événement de signature d’un contrat d’assurance par un assuré.
Par exemple, tant que le contrat n’est pas signé, l’assuré peut faire autant de modifications qu’il souhaite, la complétude des informations n’est pas requise et le pricing peut changer (le devis sera mis à jour). Tandis qu’une fois le contrat signé, toute modification donnera obligatoirement lieu à un avenant.
En prenant cette hypothèse, ça nous permet d’avoir 2 modèles spécialisées à des besoins différents avec des représentations différentes (et nous éviter d’avoir des gros objets avec plusieurs attributs tous optionnels, par exemple).
Cette décomposition nous a également permis de faire un choix opportuniste et de ne pas coder nous même la partie “distribution”, mais plutôt de se tourner vers un outil no-code pour configurer le tunnel de distribution en marque blanche que les partenaires vont intégrer dans leurs sites e-commerce.
Il faut garder en tête qu’un “bounded context” n’est pas juste un “mot” mais une délimitation claire et formulée explicitement et partagée d’un problème à résoudre (pro tip : méfiez vous des bounded contexts de type “Client”, “Produit”, “Facture”...).
Au niveau des équipes de développement de la nouvelle plateforme, nous nous sommes grandement inspirés des bounded contexts qui ont émergés pour nous organiser.
Néanmoins, pour avoir un modèle organisationnel efficace, il a fallu aussi que les rôles et les niveaux de collaboration inter-équipes (avec les équipes externes aux équipes de réalisation de la nouvelle plateforme) soient clairs et définis.
Ce retour d’expérience s’est conclu par ce témoignage de François-Xavier Bouffant, l’engineering Manager de l’équipe Wakam qui a repris le relai après le départ des équipes Octo :
Cette collaboration avec Octo a fait énormément mûrir la culture tech de nos équipes !
Voici le compte-rendu, ainsi que le replay vidéo (disponible ici), de ce comptoir animé par Etienne Debost (Head of Architecture chez Wakam), François-Xavier Bouffant (Engineering Manager chez Wakam) et Wassel Alazhar (Architecte @ OCTO), qui est intervenu chez Wakam.