Comment ERGO Hestia a réduit son délai de mise sur le marché grâce à Lakebase et Mosaic AI Model Serving

Bâtir la nouvelle génération de tarification en temps réel

ERGO Hestia, l'une des principales compagnies d'assurance de Pologne, exploite une plateforme de tarification à grande échelle prenant en charge plus de 100 modèles et 1 000 variables. En tant que l'un des plus grands utilisateurs polonais de Databricks, ERGO Hestia a développé de solides compétences en matière de tarification de pointe à la milliseconde près et de vitesse d'exécution leader du secteur.

Cependant, l'équipe cherchant constamment à réaliser la prochaine grande innovation technologique dans le secteur des assurances, elle a vu l'opportunité de maximiser davantage ses revenus en introduisant des fonctionnalités B2C en temps réel. Bien que l'architecture existante ait été très fonctionnelle, le passage à des mises à jour continues des modèles et à une réactivité instantanée vis-à-vis des clients a révélé un nouveau défi : maintenir la vitesse d'innovation à mesure que la complexité augmentait. L'équipe maîtrisait l'art de la tarification compétitive et était désormais prête à ouvrir la voie à la nouvelle génération de tarification en temps réel.

S'appuyant sur un partenariat étroit et productif, ERGO Hestia et Databricks ont discuté conjointement de la manière d'améliorer l'architecture précédente pour la nouvelle génération de tarification en temps réel. Cette excellente collaboration a conduit à l'évolution de la plateforme en utilisant Lakebase to fournir un Online Feature Store aux côtés des endpoints Mosaic AI Model Serving afin de conserver toutes les données et toute la logique au sein de l'écosystème Databricks. Cette architecture maintient à la fois les données et le service de modèles au sein du lakehouse, éliminant les systèmes externes et réduisant le temps de déploiement des modèles. En unifiant la gouvernance via Unity Catalog, l'équipe intègre la gestion des données et des modèles pour garantir une traçabilité complète et la conservation à long terme des ensembles d'entraînement historiques et des versions de modèles. Cette architecture offre aux experts en tarification une piste d'audit fiable pour garantir que chaque décision reste entièrement traçable et vérifiable tout en maintenant des performances de modèle optimales. En fin de compte, cette transformation permet à l'équipe d'accélérer sa vitesse d'innovation et de réagir rapidement aux conditions du marché tout en perfectionnant continuellement ses modèles de tarification de pointe.

Le défi : accélérer la vitesse sans augmenter les frictions

L'architecture précédente suivait un modèle logique dans lequel Databricks ingérait et transformait les données de tarification via son architecture médaillon, puis exportait les ensembles de données traités vers une base de données externe Azure PostgreSQL. Une couche d'adaptation intermédiaire gérait la mise en cache et exposait les données au moteur de tarification. Cela fonctionnait bien lorsque le débit était modéré. Cependant, à mesure que le volume de données augmentait et que l'itération des modèles s'accélérait, le modèle multi-étapes consistant à déplacer les données hors du lakehouse, à travers une base de données externe, puis une couche de mise en cache, jusqu'à l'application, a commencé à limiter les performances et l'agilité.

1. Complexité opérationnelle : La maintenance d'une base de données externe et d'une couche d'adaptation personnalisée créait une charge opérationnelle importante, la lourde tâche de maintenance des tâches d'extraction s'imposant comme le principal défi pour ces cas d'usage critiques. De plus, la gestion d'une gouvernance des données fragmentée entre les systèmes (notamment Databricks pour le traitement des données et PostgreSQL pour le service en production), ainsi que le code applicatif personnalisé pour gérer la logique des requêtes et l'intégration, rendaient le suivi du lignage difficile, ce qui nuisait à la conformité et à l'auditabilité.
2. Vitesse de déploiement des modèles : L'ancienne architecture multi-étapes nécessitait une synchronisation minutieuse entre la logique du modèle et l'infrastructure de service sous-jacente, ce qui créait une dépendance technique vis-à-vis de fenêtres de déploiement coordonnées. Bien que l'équipe possède déjà l'expertise en tarification pour itérer rapidement, la complexité de la base de données externe et de la couche d'adaptation faisait que les mises à jour étaient souvent planifiées en dehors des heures de pointe pour garantir la stabilité du système. Cette orchestration spécialisée limitait la fréquence des mises à jour pendant la journée de travail afin d'éviter les risques de performance dans la couche d'adaptation externe.
3. Goulot d'étranglement de la fraîcheur des données : Les ingestions massives de données créaient des contraintes de performance qui nécessitaient une orchestration minutieuse pour éviter d'impacter les heures d'activité. Plus précisément, ces mises à jour déclenchaient souvent des pics de latence de 10x à 20x dans la couche de service externe, ce qui limitait de fait les rafraîchissements de données à des fenêtres de traitement par lots planifiées. Pour soutenir la transition stratégique vers la tarification B2C en temps réel, l'équipe avait besoin d'une architecture capable d'offrir une disponibilité continue des données tout au long de la journée, sans ces compromis opérationnels.

Pour une organisation gérant plus de 100 modèles sur plus de 1 000 variables dans un secteur réglementé, cette fragmentation créait à la fois des frictions opérationnelles et des risques de gouvernance.

La solution : la consolidation au sein du lakehouse

La transformation d'ERGO Hestia s'est appuyée sur trois piliers techniques fondamentaux qui ont unifié toutes les opérations au sein du lakehouse.

Lakebase pour un service de données unifié. Databricks Lakebase fournit une couche transactionnelle relationnelle directement au-dessus des tables Delta. En utilisant les Sync Tables, l'équipe a permis une synchronisation continue et automatique entre les données traitées et la couche de service. Cela a éliminé le besoin d'orchestration manuelle et de tâches d'extraction externes. Le résultat est une source unique de vérité pour les données de tarification, résidant au sein du lakehouse.

Endpoints Model Serving pour un accès direct par API. Plutôt que de passer par une application intermédiaire avec une couche de mise en cache distincte et une base de données externe, les endpoints Model Serving exposent les données directement à l'application du moteur de tarification. Cela élimine complètement la couche d'adaptation et garantit que la logique de requête est conservée nativement au sein de Databricks. Les requêtes transitent du moteur de tarification vers les endpoints Model Serving et inversement en quelques millisecondes, simplifiant ainsi l'architecture en regroupant l'exécution des requêtes et le service de données dans une seule couche managée.

Model Serving pour une intégration à haute vitesse de l'écosystème. Les modèles sont d'abord enregistrés dans MLflow, puis les meilleures versions sont inscrites dans Unity Catalog avant d'être exposées via des endpoints Model Serving dédiés. Cette architecture étend les capacités de déploiement existantes en fournissant un plan de contrôle unique et gouverné où les experts en tarification peuvent valider les modèles par rapport à des données réelles dans l'écosystème Databricks en temps réel. Ils peuvent exécuter plusieurs versions de modèles simultanément pour comparer les performances via des tests A/B et de régression, tandis que l'ensemble du cycle de vie des modèles reste connecté nativement aux sources de données sous-jacentes. Cette approche garantit une visibilité complète grâce à un suivi du lignage intégré et à des contrôles de gouvernance qui couvrent à la fois les couches de données et de service de modèles dans Unity Catalog.

Les pipelines ETL existants dans Databricks n'ont nécessité aucune modification et les données se sont simplement synchronisées avec Lakebase au lieu d'être extraites vers PostgreSQL. Model Serving pouvait utiliser les modèles GLM et ML existants qui étaient enregistrés dans MLflow, publiés dans Unity Catalog et exposés via des endpoints Model Serving. Un pipeline CI/CD a été utilisé dans Azure DevOps pour orchestrer les déploiements.

Réussir grâce à une migration progressive : réduire les risques de la transformation

Plutôt qu'une bascule globale coordonnée, ERGO Hestia a adopté une approche progressive qui a privilégié la confiance et la continuité des activités. L'équipe a commencé par les endpoints de moindre criticité tout en validant les performances et la stabilité avant de s'étendre aux systèmes critiques. Les opérations de tarification n'ont subi aucune interruption tout au long du processus.

L'équipe a validé l'architecture avec un endpoint de données restreint et bien défini desservant un segment de portefeuille limité. Ils ont synchronisé la table Delta existante avec Lakebase et l'ont exposée via un endpoint Model Serving. Un avantage déterminant de Lakebase est la séparation unique du calcul et du stockage, qui a permis au système d'évoluer sans effort pour répondre aux volumes de requêtes de pointe sans aucun ajustement manuel de l'infrastructure de calcul. Databricks a fourni une observabilité intégrée de la latence et de l'utilisation du CPU, ainsi que du débit et de la consommation de mémoire. Les tests de performance ont démontré que l'architecture dépassait de loin les attentes avec une latence de 20 ms et moins de 5 % d'utilisation du CPU, même sous une charge élevée de 40 requêtes par seconde. Ce succès précoce a éliminé les risques architecturaux avant que le projet ne s'étende à la production.

Le PoC ayant été validé, l'équipe a commencé la migration en production en débutant par les endpoints de faible criticité. À mesure que les endpoints étaient migrés, chacun fournissait des résultats cohérents : une parfaite cohérence des données entre Delta Lake et Lakebase, des performances stables et prévisibles, et moins de composants personnalisés requis par rapport à l'ancienne architecture. À chaque migration réussie, la confiance des parties prenantes grandissait, permettant à l'équipe d'accélérer l'expansion vers des endpoints à plus haut risque.

Plutôt que d'accepter une date de bascule unique, ERGO Hestia a mis en œuvre une répartition du trafic à l'échelle de la production : la moitié de sa clientèle était orientée vers les systèmes existants, l'autre moitié vers le nouveau système. Cette approche a permis d'observer en conditions réelles le comportement des utilisateurs et les profils de charge. Les nouveaux modèles de tarification ont généré des devis de manière cohérente et ont répondu à toutes les attentes en matière de latence. Surtout, l'équipe a pu valider que le nouveau système gérait la charge de production exactement comme prévu.

Pourquoi cette approche a réussi : la stratégie incrémentale a éliminé les risques à chaque étape. La validation sur des éléments à faible criticité a permis d'éviter des pannes catastrophiques à l'échelle du système. Les étapes clés franchies avec succès ont renforcé la confiance de l'organisation et permis une expansion plus rapide. La validation en production réelle et à l'échelle a confirmé que l'architecture fonctionnait comme prévu. Tout au long des différentes phases, les opérations de tarification se sont poursuivies sans interruption et sans aucun impact pour les clients.

Résultats commerciaux : accélérer la vitesse d'innovation

Mise sur le marché accélérée des modèles : les experts en tarification déploient désormais les modèles directement au sein de l'écosystème Databricks, où ils sont automatiquement synchronisés avec les dernières données de production. En servant les modèles via Mosaic AI aux côtés du Lakebase Online Feature Store, l'équipe élimine la latence généralement constatée lors de la synchronisation des sorties de modèles externes avec les flux de données en temps réel. Cette intégration garantit que l'agilité existante d'ERGO Hestia s'accompagne désormais d'une connexion directe à grande vitesse entre les données de marché en temps réel et le moteur de tarification. La possibilité d'exécuter ces modèles synchronisés permet de réagir rapidement aux conditions du marché et à la pression concurrentielle sur les prix, ce qui, à terme, génère des revenus plus élevés pour l'entreprise.

Simplification opérationnelle : la complexité opérationnelle a fait place à la simplicité architecturale. En supprimant la base de données externe PostgreSQL et la couche d'adaptation, ERGO Hestia a unifié sa pile sous un modèle de gouvernance unique avec Unity Catalog. Cette transition a éliminé la charge de travail manuelle liée aux correctifs et à la planification de la capacité, tout en centralisant la logique des demandes de tarification au sein de l'écosystème Databricks. La logique et les données cohabitant désormais dans un environnement haute performance, la capacité d'ingénierie n'est plus consacrée à la maintenance de middleware personnalisés, mais à l'innovation des modèles.

Gouvernance et conformité unifiées : dans un secteur réglementé, la capacité de prouver exactement ce qui a motivé une décision de tarification est essentielle. En unifiant toutes les données et tous les modèles de tarification sous Unity Catalog, ERGO Hestia bénéficie de pistes d'audit automatiques, d'un suivi des versions et de contrôles d'accès. La cohérence des données est désormais vérifiée automatiquement sur l'ensemble du pipeline afin de garantir que la logique utilisée lors des tests correspond parfaitement à celle de la production. Grâce au lignage intégré de la plateforme, il est possible de savoir immédiatement et de manière totalement auditable quel modèle a servi quels clients au cours d'une période donnée. Cela élimine le travail de conformité manuel. Les équipes de conformité peuvent désormais prouver exactement quelles données ont motivé chaque décision de tarification, qui y avait accès et quand les modifications ont eu lieu. Tout est capturé automatiquement pour éliminer le besoin de reconstruction manuelle, tout en fournissant un socle de confiance qui permet à l'entreprise de déployer ses stratégies de maximisation des revenus en toute confiance.

La voie à suivre : déployer l'innovation à l'échelle de l'entreprise

Le succès du service de tarification sert de modèle pour un déploiement à l'échelle de l'ensemble des domaines de tarification. ERGO Hestia étend désormais l'architecture Lakebase et Model Serving à l'ensemble de son organisation de tarification. Chaque domaine consolidera ses moteurs de prise de décision au sein de la plateforme lakehouse, en servant les modèles et les données en tant que services de premier ordre avec une gouvernance unifiée.

La validation initiale avec un petit point de terminaison à faible criticité a prouvé l'efficacité de l'approche. Désormais, le bureau de tarification passe à des charges de travail plus importantes et plus critiques, ainsi qu'à des bases de données plus volumineuses, en utilisant la même méthode incrémentale. Les ensembles de données à plus fort enjeu et les modèles complexes nécessitent une validation plus rigoureuse, mais le modèle de migration incrémentale reste inchangé.

L'objectif est clair : décommissionner la base de données externe Azure PostgreSQL une fois que tous les domaines de tarification auront migré avec succès vers Lakebase. La migration de chaque domaine renforce la confiance pour le suivant, accélérant ainsi le calendrier global vers une infrastructure de tarification unifiée et native de Databricks.

Au-delà des opérations de tarification, la consolidation de toutes les données de tarification au sein du lakehouse ouvre de nouvelles opportunités. Grâce à l'unification de l'intelligence tarifaire dans Databricks, les équipes peuvent s'appuyer sur AI/BI Genie pour explorer les profils de tarification, découvrir des insights et répondre à des questions commerciales ad hoc sans avoir besoin de l'aide de l'ingénierie. Les mêmes données qui alimentent le moteur de tarification propulsent désormais l'informatique décisionnelle et la découverte basée sur l'IA, multipliant ainsi la valeur de l'investissement dans le lakehouse.

Ce modèle éprouvé sert désormais de référence pour d'autres fonctions commerciales afin d'éliminer les dépendances externes et d'accélérer leur propre vitesse de prise de décision.

Conclusion

La transformation d'ERGO Hestia illustre un principe qui s'applique à tous les secteurs : la consolidation au sein d'une plateforme unifiée accélère la vitesse d'innovation tout en simplifiant les opérations. En passant à une architecture native du lakehouse où les données et les modèles sont servis directement via Databricks Lakebase et Model Serving, le service de tarification est devenu plus rapide, plus fiable et capable de soutenir une innovation continue.

Dans un marché qui se joue à la milliseconde près, le facteur de différenciation n'est plus seulement le modèle lui-même, mais l'architecture qui lui permet de réagir à la réalité en temps réel. Les tests A/B natifs, les garde-fous automatisés et les pistes d'audit continues dans Unity Catalog garantissent que chaque décision reste traçable et respecte les limites de risque définies.

Cette architecture sert de référence pratique pour l'ensemble de l'organisation ERGO et pour toute entreprise s'efforçant de déployer des moteurs de tarification à la milliseconde afin de maximiser l'impact sur le marché et la croissance des revenus. Pour le secteur, la question n'est plus de savoir si la tarification en temps réel est techniquement possible, mais à quelle vitesse les entreprises peuvent adopter l'architecture qui en fait une réalité.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original