Modernisation du SI : avec la conteneurisation, la Matmut fait d’une pierre deux coups

Red Hat OpenShift, une « solution clé en main » pour la Matmut

Un coup d’œil dans le rétroviseur s’impose pour expliquer ce choix. Entre 2018 et 2021, Matmut s’est attelée à la rénovation de ses data centers. « Nous avons ramené nos centres de données au 21^e siècle en y installant la fibre et d’autres éléments d’infrastructures physiques, afin d’y déployer des technologies dites “cloud-ready” ou “cloud native” », explique Jean-Jacques Mok.

Une période que le cadre n’a pas vécue. Il a justement été recruté en 2021, en préparation de la rénovation du SI. « Matmut est une société qui a plus de 60 ans et qui dispose d’applicatifs en fonctionnement depuis près de 40 ans sur la base d’une architecture monolithique », évoque-t-il. Un contexte qui n’a rien de surprenant dans le monde de l’assurance français.

« Nous avions la volonté de briser ce monolithe en adoptant un découpage en microservices », poursuit Jean-Jacques Mok. Cette approche promettait une plus forte isolation des charges de travail. Jusqu’alors, plusieurs applications pouvaient interagir « avec le même bout de code ». Cela créait des conflits lors des mises à jour et générait du stress.

La conteneurisation s’est imposée comme la fondation de cette architecture logicielle plus modulaire. Oui, mais il fallait maintenant orchestrer des conteneurs.

 « En 2021, nous avons évalué ce qui était disponible. Nous avons conduit un PoC », raconte Jean-Jacques Mok. Sur la liste finale restait trois distributions d’une fameuse technologie d’orchestration open source : Kubernetes « vanilla », VMware Tanzu ou Red Hat OpenShift. La distribution Rancher de SUSE a été écartée parce qu’elle ne répondait pas aux besoins de la DSI [Rancher appartient à SUSE depuis juillet 2020, N.D.L.R.].

« Kubernetes est un superbe moteur, mais une entreprise a besoin de quelque chose de packagé, qui tient la route », considère le cadre. « À nos yeux, en 2021, Tanzu ressemblait encore trop à une version “vanilla” de Kubernetes gérée par VMware, tandis qu’OpenShift était la solution clé en main ». La Matmut s’est donc tournée vers Red Hat, sa solution et ses services professionnels.

« L’accompagnement a duré un peu moins d’un an, le temps de poser l’architecture, de la valider avec Red Hat en prenant en compte nos pratiques de gestion de data centers », relate-t-il.

Par exemple, la Matmut a adopté un système actif-passif où la DSI interchange le rôle des salles de ses data centers tous les trimestres. Les charges de travail basculent ainsi de salle en salle. « Une fois par an, nous allons même couper électriquement nos salles pour vérifier que nous tenons bien la charge complète sur un data center », ajoute Jean-Jacques Mok. « Cela nous permet aussi d’effectuer les opérations de maintenance (climatisation, puissance électrique, etc.) ».

Après cette phase de conception, la plateforme OpenShift est entrée en service en 2022.

Matmut a mené son PoC dans l’idée de migrer d’abord son application Mav Sérénité depuis ses serveurs Microsoft ISS vers d’autres hébergeant OpenShift. Mav Sérénité correspond à l’offre multirisque, accidents de la vie de l’assureur. Bien qu’importante dans l’activité du groupe, elle n’est pas considérée comme critique. « Nous voulions que la première application qui fasse la bascule soit significative, mais que l’opération ne mette pas la Matmut en péril », indique Jean-Jacques Mok. Ce projet, vu comme la première pierre de la nouvelle architecture logicielle, a été mené en dix-huit mois pour un « go-live » en 2024.

Ce temps relativement long s’explique par la recherche d’un consensus entre les exigences de la DSI et les enjeux des métiers. Il a été décidé de ségréguer les applications et les données associées en domaines d’activité. Cette séparation s’applique également entre les trois strates de ce SI : le back-end, les bases de données et le front-end.

Le mainframe ne perd pas totalement sa place

« Certains traitements en lot sont exécutés par le mainframe et n’ont pas vocation à en sortir. »

La Matmut a choisi de déployer ses clusters Kubernetes – OpenShift en Bare-Metal. « Nous n’avions pas de stockage IP à l’époque », justifie Jean-Jacques Mok. « Derrière nos lames [utilisées pour] OpenShift, nous avons branché directement notre stockage SAN. La limite à cela, c’est que nous ne pouvions faire que du “ReadWriteOnce”. Nous ne pouvions pas distribuer le stockage ».

Du même coup, dans les environnements de développement, les responsables des applications n’ont pas accès par défaut à des bases de données à stockage persistant. « Les développeurs peuvent utiliser des solutions de cache ou des bases en mémoire telles que Redis, sans persistance », précise-t-il. « Cela permet aussi de cranter la montée en compétences des équipes ». Depuis, les équipes IT ont ajouté du stockage persistant géré avec Pure Storage PortWorx. Cela permet par exemple de déployer Elasticsearch et des progiciels.

Les bases de données des applications en production (principalement SQL Server) sont externalisées. Les pods Kubernetes peuvent les interroger. Ces bases ont été instanciées dans le cadre d’une migration d’une partie des données contenues dans les bases DL1 du mainframe IBM de la Matmut. Toutefois, pas question de débrancher le fameux système « Z ». « Certains traitements en lot sont exécutés par le mainframe et n’ont pas vocation à en sortir », indique Jean-Jacques Mok. « Plusieurs systèmes de calcul complexes n’ont pas d’équivalent, ou alors en alignant beaucoup plus de puissance de calcul ».

Un gain immédiat de performance

Il restait à sauter dans le grand bain de la production.

« Un gros travail a été mené avec les développeurs pour placer des métriques, afin de superviser la consommation de ressources. »

« Au déploiement, nous avions tous un peu peur. Nous nous demandions si le cluster tiendrait la charge », se rappelle le directeur du programme cloud. « Finalement, tout s’est bien passé. Un gros travail a été mené avec les développeurs pour placer des métriques, afin de superviser la consommation de ressources ».

Là où l’application s’exécutait sur dix serveurs Windows, elle « tourne » sur une trentaine de microservices (en comptant les répliquas) qui reposent sur des pods consommant « quelques CPU ». Ces pods dépendent de trois clusters – (une sandbox, un environnement de préproduction et un autre de production).

Puisque la Matmut n’a pas de suite d’observabilité centralisée, cette mesure de la performance est fonction des briques fournies par Red Hat dans OpenShift. « La stack OpenShift amène Prometheus pour les métriques. Nous y avions instancié une pile Elastic – Fluentd – Kibana pour le suivi des logs », liste le responsable. « Puisque le framework de développement de la Matmut intègre OpenTelemetry, nous avons pu y acheter les traces avec Jaegger. Tout cela est inclus dans OpenShift », rappelle-t-il. Au travers des différents tableaux de bord, la DSI de la Matmut peut suivre une transaction applicative de bout en bout.

En novembre 2025, la pile Elastic-Fluentd-Kibana était en cours de remplacement. Les changements de version d’OpenShift ont eu raison de son implémentation. Le système qui le remplace n’est autre que Grafana Loki, associé à une couche de stockage compatible S3 (Dell EMC ECS).

La rationalisation des chaînes de déploiement logiciel

Satisfait de cette première rénovation, la refonte applicative s’est poursuivie sur la base des parcours des sociétaires. En parallèle, les équipes IT ont commencé la réécriture du parcours « dégâts des eaux », car c’est « le premier sinistre déclaré en France ». En commençant par le « self care », c’est-à-dire les fonctions de déclaration de sinistre à disposition des sociétaires.

« Le traitement et le dédommagement peuvent être pris en charge automatiquement en dessous d’un certain seuil financier », explique Jean-Jacques Mok. « Désormais, nous attaquons les très gros morceaux : l’assurance habitation et l’auto. Nous avons pour objectif de livrer le parcours habitation en juin 2026 et l’habitation en octobre sur OpenShift ».

Pour le sociétaire, la bascule est transparente. Le front-end ReactJS n’a pas changé. L’usager passe par un portail unifié qui lui permet de déclarer ses sinistres, payer sa souscription, récupérer des documents, etc. Les écrans du front-end ont été portés sur OpenShift. À terme, l’intégralité du portail sera migrée vers la plateforme basée sur Kubernetes, mentionne le responsable.

Le passage sur la plateforme conteneurisée promettait d’accélérer les développements. Matmut a pu valider cette promesse. « Jusqu’alors, il fallait attendre 18 mois de la prise en compte des exigences métiers jusqu’à la délivrance du produit réel. Avec Mav Sérénité, nous sommes restés dans les standards de la Matmut, mais le parcours “dégâts des eaux” a été conçu en douze mois », détaille-t-il.

Ces premiers gains s’expliquent par la rationalisation de la chaîne de livraison logicielle. Un seul outil de gestion des livraisons (DigitalAI Release) a été adopté pour les chaînes d’outils CI/CD OpenShift, .NET Core (le langage standard du back-office des applications « maison » chez la Matmut) et COBOL. « Du côté d’OpenShift, le code est buildé, contrôlé, déployé directement dans un environnement de développement. Il y a un véritable gain en matière d’expérience développeur, même s’il reste à les éduquer sur la gestion des tests ».

Généralement, les équipes techniques de la Matmut sont curieuses des nouveautés et tentent d’appliquer les tendances IT à leur besoin quand elles sont intéressantes. L’adoption va donc bon train. « C’est l’une des grandes forces de la DSI », considère le responsable.

Un véritable cloud hybride

D’un autre côté, les équipes sont en train de revoir le modèle conceptuel de données du groupe. « Cela implique beaucoup de travail, mais n’est plus de l’implémentation, c’est une pure phase de conception », souligne Jean-Jacques Mok.

« Il s’agit de répondre à deux questions : “quelles données envoyons-nous vers le cloud ? Maîtrisons-nous cet envoi ?” »

Oui, les données seront analysées à l’aide de BigQuery sur le Cloud S3NS, un cloud de confiance. Toutefois, « la Matmut doit rester maître de son destin ». Le DSI de la Matmut a demandé à ses équipes de conserver un certain niveau de maîtrise afin de « se déconnecter à tout moment ». « La contrainte que l’on nous a imposée – et c’est déjà un standard chez la Matmut –, c’est le système de fonctionnement par demi-interface », relate l’interlocuteur du MagIT. « Chaque applicatif produit ses propres données, vient consommer qui le veut. Depuis la demi-interface, nous avons posé un sas intermédiaire que nous avons nommé “zone relais” ». C’est le point d’entrée vers S3NS. « Il s’agit de répondre à deux questions : “quelles données envoyons-nous vers le cloud ? Maîtrisons-nous cet envoi ?” », détaille-t-il.

Cette logique est déjà orchestrée sous la forme d’un mécanisme de batch. Un espace disque de plusieurs téraoctets est directement synchronisé avec des buckets Google Cloud Storage (GCS) gérés par S3NS. Une fois dans le data lake, la Matmut applique les transformations bronze, silver, gold, orchestrées à l’aide d’Apache Airflow. « Pour conserver la cohérence des traitements entre ce qui se passe dans le cloud et dans le SI de gestion, nous utilisons notre orchestrateur global qui est AWS où sont gérés les traitements Airflow », indique Jean-Jacques Mok. « Cela permet à nos équipes d’exploitation de garder une maîtrise unique et une vision complète de tout ce qui se passe autour du SI ». Ce projet a débuté dès 2024. Les « derniers coups de tournevis » devaient être prodigués en décembre 2025.

Cette volonté de maîtrise s’accompagne, selon le directeur des programmes cloud, d’une tradition de « make ». Certains architectes échafaudent déjà un plan de sortie de BigQuery, si nécessaire.

L’adoption d’OpenShift répond également à une exigence des partenaires de la Matmut, qui lui demandent d’ouvrir son SI. Les comparateurs d’assurance ont également conduit les assureurs à s’appliquer cette exigence d’ouverture. « Nous ne pouvions pas le faire avec notre ancienne architecture », déclare Jean-Jacques Mok.

Toutefois, l’usage OpenShift entraîne de nouveaux défis, notamment la gestion en parallèle de plusieurs versions. Si les applications de gestion de la Matmut sont amenées à s’exécuter sur des versions prises en charge à long terme, d’autres logiciels ont besoin des dernières versions de la plateforme et de Kubernetes pour se lancer ou pour des raisons de sécurité. « Nous cherchons à “dérisquer” cette contrainte au niveau de nos clusters. Deux options s’offrent à nous : ajouter des clusters sur des serveurs bare-metal ou faire du “nesting” d’OpenShift [de la virtualisation imbriquée, N.D.L.R.] », expose le responsable. Cette deuxième option est pour l’instant la plus intéressante.

La Matmut a déjà de quoi voir venir. Chaque cluster dispose de plusieurs centaines de cœurs. L’environnement de production, près de 1 000. « Si nous pouvons segmenter ces cœurs au travers d’instances OpenShift virtualisées, je suis convaincu que nous allons rationaliser l’usage de la plateforme et pouvoir isoler des solutions qui doivent suivre leur propre cycle de vie, sans perturber les autres », déclare Jean-Jacques Mok.

Il s’agit de réaliser des économies et de soulager les équipes d’infrastructures et DevOps. La DSI compte environ 500 collaborateurs, dont près de 300 développeurs. Une trentaine de collaborateurs ont été formés à OpenShift.