AKUR8 — Assurance / SaaS
Plateforme de tarification assurantielle
Stabilisation et évolution de la plateforme d’optimisation de tarification assurantielle. Travail sur la fiabilité, la performance et l’ajout de nouvelles fonctionnalités pour répondre aux besoins croissants des assureurs clients de la plateforme SaaS.
Le contexte
Une plateforme d’optimisation de tarification n’est pas un outil d’analyse parmi d’autres. Ce qui en sort devient un prix, appliqué à de vrais contrats, et devra être expliqué. La conséquence technique est exigeante : le résultat doit être reproductible — mêmes données, même paramétrage, même résultat, y compris longtemps après.
Le mode SaaS impose la contrainte inverse de l’artisanat. Plusieurs assureurs travaillent sur la même plateforme, avec des portefeuilles de volumétries incomparables : un traitement bien dimensionné pour l’un devient un problème d’exploitation pour l’autre. La charge suit en outre les cycles de travail des équipes de tarification, pas une courbe lissée.
La mission portait sur la stabilisation et l’évolution : fiabilité, performance et nouvelles fonctionnalités pour des besoins croissants. Ces trois demandes se contrarient à court terme, puisque chaque fonctionnalité ajoute de la surface à stabiliser.
Notre intervention
Deux régimes cohabitent dans le produit : le calcul en Python, où se joue le travail de Machine Learning, et l’interface en React et TypeScript, où se joue l’usage. Ils ne se stabilisent pas de la même façon. Nous avons d’abord rendu observable ce qui se passait, avant d’optimiser quoi que ce soit : sur une plateforme de calcul, l’intuition sur l’endroit où passe le temps est presque toujours fausse.
Côté données, PostgreSQL supporte des portefeuilles de tailles très inégales. Un modèle acceptable sur un petit volume devient le facteur limitant sur un gros, et l’addition se présente chez le plus gros client, c’est-à-dire au pire moment. Le travail porte autant sur la forme des requêtes que sur la puissance allouée.
L’élasticité d’AWS répond au caractère irrégulier de la charge. Dimensionner en permanence pour le pic revient à payer toute l’année une capacité utilisée quelques heures ; dimensionner pour la moyenne rend la plateforme inexploitable au moment précis où les équipes en ont besoin.
TypeScript sur le front n’est pas un choix cosmétique ici : il matérialise le contrat entre ce que le calcul produit et ce que l’écran affiche. Sur un outil de tarification, une colonne mal interprétée ou un arrondi mal propagé n’est pas un défaut d’affichage, c’est un incident métier — et il se découvre tard.
Résultats
- Plateforme stabilisée et scalable
- Nouvelles fonctionnalités déployées
- Performance optimisée
Technologies & outils
« Plateforme stabilisée et scalable » signifie que la croissance du nombre d’assureurs et de la taille de leurs portefeuilles cesse d’être une menace pour l’exploitation. C’est la condition d’un SaaS : le succès commercial ne doit pas dégrader le service rendu aux clients déjà présents.
Les nouvelles fonctionnalités déployées et la performance optimisée comptent surtout parce qu’elles ont été obtenues ensemble. Le résultat n’est pas une livraison, c’est la capacité à continuer de livrer sans que chaque évolution rouvre le dossier de la fiabilité. C’est ainsi que nous abordons le développement produit : rendre l’équipe capable d’avancer après nous.
06 — Contact
45 minutes.
Sans engagement.
Décrivez la décision technique devant vous. Nous vous disons ce que nous ferions, si c’est pour nous, et ce que ça coûte. Réponse sous 24 h ouvrées, par un associé.