Modernisation du SI gestion de l'assurance vie

Contexte

Cet assureur vie français gérait depuis 1988 l’intégralité de ses contrats dans un SI mainframe articulé autour d’une base IMS (Information Management System). Un système fiable, éprouvé, mais hermétiquement fermé : accéder à une donnée contrat nécessitait de passer par un écran CICS ou une extraction batch nocturne.

En 2023, la direction métier a imposé une contrainte nouvelle : les conseillers en agence devaient pouvoir consulter les données de contrat en temps réel depuis leur CRM Salesforce. Et la DSI devait exposer ces mêmes données à un agrégateur financier partenaire via Open Insurance.

La réponse “simple” — extraire nuitamment et synchroniser — ne satisfaisait pas la latence exigée (sous 500ms) ni la fraîcheur des données (les mises à jour contrat se faisant tout au long de la journée sur le mainframe).

Défi

L’architecture IMS posait un défi spécifique : contrairement à DB2, IMS n’offre pas de mécanisme natif de CDC (Change Data Capture) compatible avec les outils modernes d’intégration. Les données de contrat étaient accessibles via des segments IMS hiérarchiques, une structure totalement étrangère aux APIs REST JSON.

L’autre contrainte : aucune modification du code COBOL existant. Les programmes de gestion de contrats, certifiés par l’ACPR et auditables, ne pouvaient pas être touchés. La nouvelle couche d’API devait cohabiter avec l’existant sans intrusion.

Approche

Architecture choisie : CQRS avec IMS comme source of truth.

Un service de lecture (Query Service) a été développé en Java/Spring Boot, connecté à une base PostgreSQL répliquée. La synchronisation IMS → PostgreSQL est assurée par une solution de CDC développée spécifiquement : un programme COBOL de capture installé sur le LPAR, publiant les changements dans un topic MQ Series, consommé ensuite par Kafka Connect.

* Programme de capture des changements IMS (simplifié)
       PERFORM UNTIL WS-END-OF-QUEUE = 'Y'
           CALL 'MQGET' USING MQ-HCONN
                              WS-HOBJ
                              MQ-GMO
                              WS-MSG-BUFFER
                              WS-MSG-LENGTH
                              MQ-COMPCODE
                              MQ-REASON
           IF MQ-COMPCODE = MQCC-OK
               PERFORM PROCESS-CHANGE-EVENT
           ELSE
               MOVE 'Y' TO WS-END-OF-QUEUE
           END-IF
       END-PERFORM.

Ce programme tournait en continu sur le LPAR et détectait les modifications en interceptant les appels DL/I (les opérations de base d’IMS) via un exit programme.

Exposition API. 15 endpoints REST ont été définis en collaboration avec les équipes métier et le partenaire Open Insurance. Chaque endpoint respecte les normes OpenAPI 3.0. Une couche d’anonymisation à la requête a été intégrée dès la conception pour satisfaire les exigences RGPD (les données fiscales notamment ne pouvaient être exposées qu’à certains profils habilités).

CI/CD. Pour la première fois dans cet établissement, un pipeline GitLab CI déployait automatiquement le service Java sur Azure Kubernetes Service. Les équipes mainframe — initialement réticentes — ont participé aux code reviews via Git, une première culturelle significative.

Résultats

L’impact culturel a été aussi important que l’impact technique. La cohabitation des équipes mainframe et cloud sur un même repository Git a initié un transfert de connaissances spontané qui a transformé la perception interne des deux mondes.

[À COMPLÉTER PAR ABDERRAHMANE] — Validation des KPIs avec le client, données anonymisées à confirmer