La fusion est actée et la nouvelle gouvernance se met en place. Sur le papier, les deux organisations n’en font bientôt plus qu’une. Dans le SI, c’est une autre histoire.
Deux référentiels produits continuent de vivre, plusieurs moteurs appliquent leurs propres règles, les documents sont générés ailleurs, les parcours commerciaux ne demandent pas les mêmes informations... Et les systèmes de gestion ne parlent pas toujours le même langage.
Le réflexe peut alors être tentant : faire du SI cible le préalable à toute convergence réelle.
Mais faut-il vraiment attendre d’avoir migré l’ensemble du patrimoine applicatif pour proposer des parcours communs, harmoniser une offre ou commencer à concrétiser les premières synergies ?
Dans de nombreux rapprochements, une autre trajectoire est possible : faire converger progressivement ce que les métiers et les clients doivent déjà partager, tout en organisant la coexistence temporaire de ce qui ne peut pas encore être migré.
Les rapprochements mutualistes récents rendent cette question particulièrement concrète.
Le rapprochement entre Malakoff Humanis et KERIALIS a ainsi franchi son dernier jalon réglementaire en septembre 2026, avant une entrée effective de KERIALIS dans les structures du groupe annoncée au 1er novembre 2026. À partir de ce moment, la question ne porte plus seulement sur l’opération juridique. Elle devient celle de l’intégration des offres, des données, des parcours et des systèmes.
Une autre configuration est celle de la Mutuelle Ociane Matmut et la Mgéfi qui ont approuvé la création de Matmut Santé Prévoyance, prévue au 1er janvier 2027 sous réserve des dernières étapes réglementaires. Le nouvel ensemble doit intervenir sur plusieurs segments, particuliers, entreprises et fonction publique, alors même que la Mgéfi poursuit son développement sur de nouveaux marchés collectifs.
Ces situations sont différentes. Mais elles illustrent une même tension : la date de rapprochement juridique et la date de convergence complète du système d’information ne peuvent pas toujours coïncider.
L’ACPR elle-même a déjà décrit cette logique dans les groupes prudentiels. Les entités peuvent conserver une certaine autonomie tout en cherchant à rationaliser et intégrer progressivement leurs systèmes d’information et de gestion.
Ce n’est pas « quand allons-nous avoir un seul SI ? » qui devrait guider la trajectoire mais « qu’est-ce qui doit réellement fonctionner comme un seul ensemble dès maintenant ? »
L’une des premières erreurs consiste à traiter la convergence comme un bloc unique. Une fusion fait en réalité avancer plusieurs transformations, qui n’ont ni la même complexité ni nécessairement le même calendrier.
Elle détermine les entités, la gouvernance, les responsabilités, les portefeuilles concernés et le cadre réglementaire de l’opération.
Selon la nature du rapprochement, les opérations de fusion ou de transfert de portefeuille sont soumises à des procédures et autorisations spécifiques auprès de l’ACPR. La protection des intérêts des adhérents, assurés et bénéficiaires reste notamment au cœur de l’examen.
Cette convergence crée le nouvel ensemble. Elle ne fait cependant disparaître ni les applications historiques ni les différences de fonctionnement le jour où elle devient effective.
Elle concerne les systèmes de gestion, CRM, référentiels, GED, moteurs de tarification, outils documentaires, data platforms, middleware et interfaces.
À terme, certains systèmes seront probablement mutualisés, d’autres remplacés et d’autres retirés.
Mais cette trajectoire peut prendre du temps, notamment lorsque les deux organisations portent des volumes importants, des portefeuilles historiques ou des applications fortement imbriquées dans leurs opérations.
Vouloir tout faire converger simultanément augmente aussi le nombre de dépendances à résoudre avant de pouvoir délivrer une première valeur métier.
C’est ici que le rapprochement devient tangible. Un distributeur peut-il commercialiser les offres du nouvel ensemble depuis un parcours commun ? Une règle produit est-elle interprétée de la même manière quel que soit le système de gestion concerné ? Les documents utilisent-ils la bonne version ? Une équipe peut-elle piloter plusieurs portefeuilles sans multiplier les modes opératoires ?
Une organisation peut donc être juridiquement unifiée, applicativement encore hybride et déjà beaucoup plus convergée dans ses opérations.
C’est cette dissociation qui ouvre une autre trajectoire que le big bang.
Le véritable risque : faire de la migration complète une condition préalable à toute synergie
Une fusion donne généralement naissance à une longue liste de dépendances : deux catalogues produits, deux modèles de données, deux chaînes documentaires, plusieurs parcours, des systèmes de gestion différents ou encore des règles parfois proches mais exprimées autrement.
La tentation consiste alors à dessiner un SI cible, à programmer les migrations, puis à attendre la fin du programme pour construire les parcours communs. Cette approche paraît rationnelle : d’abord les fondations, ensuite les usages. Mais elle pose une question essentielle : que se passe-t-il pendant la période intermédiaire ?
Si chaque système continue d’alimenter ses propres parcours, ses propres documents et ses propres règles, les équipes doivent maintenir plusieurs chaînes parallèles pendant toute la durée de la convergence. Une nouvelle offre commune peut nécessiter deux implémentations. Une évolution tarifaire doit être reproduite dans plusieurs environnements. Un projet de distribution peut attendre une migration qui n’était pourtant pas nécessaire à son lancement. La convergence SI devient alors elle-même une dépendance du time-to-market.
L’alternative n’est pas de renoncer au SI cible. Elle consiste à découpler le rythme auquel les capacités métier convergent du rythme auquel les applications historiques disparaissent.
Le parcours visible par l’utilisateur n’est que la dernière couche. Pour réellement mutualiser une distribution ou une opération, plusieurs éléments doivent pouvoir être partagés.
Deux systèmes peuvent continuer à gérer leurs portefeuilles respectifs sans exposer leurs données sous la même forme.
La première étape consiste alors moins à migrer immédiatement les données qu’à définir comment elles seront comprises et échangées dans les nouveaux parcours.
Identités, contrats, populations, entreprises, produits, statuts… Certaines entités doivent disposer d’une représentation suffisamment commune pour que les parcours et services puissent les exploiter indépendamment du système qui les héberge.
La donnée reste dans le SI qui doit encore la gérer, mais son utilisation par les nouvelles capacités devient maîtrisée.
Une convergence d’offres ne signifie pas nécessairement supprimer dès le premier jour tout l’historique produit.
Certaines gammes devront continuer à vivre pour les portefeuilles existants. D’autres pourront être harmonisées pour les nouvelles affaires. Le véritable enjeu consiste alors à savoir quelle règle s’applique à quelle population, quel produit, quelle version et quelle date d’effet.
Un référentiel commun devient particulièrement utile dans cette phase. FASST permet de centraliser offres, garanties, éligibilité et tarification, tout en faisant coexister plusieurs versions et en exposant ces règles aux différents parcours. La date d’effet peut ainsi déterminer le barème applicable sans imposer la disparition immédiate de toutes les versions historiques.
La convergence produit peut donc commencer avant la convergence de tous les systèmes qui exploitent ces produits.
L’harmonisation ne s’arrête pas à la règle. Une nouvelle garantie, une nouvelle tarification ou une nouvelle marque doivent également se retrouver dans les propositions, bulletins, notices et documents précontractuels.
Maintenir plusieurs chaînes éditiques indépendantes prolonge mécaniquement la complexité : le produit converge, mais les documents restent synchronisés manuellement.
FASST permet au contraire de produire les documents à partir du même référentiel que les parcours, avec des contenus conditionnels, une historisation et une propagation des éléments communs dans la documentation concernée.
La convergence documentaire devient alors une conséquence de la convergence produit, plutôt qu’un deuxième programme à mener en parallèle.
Faire coexister plusieurs SI n’est pas un objectif. C’est parfois une étape.
Une coexistence subie consiste à multiplier les interfaces point à point et les traitements spécifiques en attendant une migration future. Une coexistence organisée cherche au contraire à isoler ce qui doit rester temporairement différent derrière des services et des règles communes.
C’est là que l’orchestration devient structurante. L’orchestration des parcours chez FASST repose sur une architecture MACH (microservices, API-first, cloud-native et headless) conçue pour connecter des briques métier aux systèmes existants plutôt que leur imposer un remplacement monolithique. Il peut relier notamment CRM, SI cœur, GED, moteurs de tarification ou d’éligibilité et services métier.
Imaginons qu’après un rapprochement, deux systèmes de gestion doivent encore coexister pendant plusieurs années. Le parcours de souscription n’a pas nécessairement besoin de connaître toute leur complexité.
Il doit savoir :
L’orchestration permet ainsi de placer la complexité de la transition derrière le parcours plutôt que de la reproduire dans chaque nouveau projet.
Le SI cible reste la destination. Mais la valeur métier n’attend pas forcément que tout le voyage soit terminé.
C’est probablement l’arbitrage le plus important d’un programme de convergence.
Toutes les briques ne doivent ni être fusionnées immédiatement, ni conservées indéfiniment.
Une grille simple peut aider à décider.
|
Décision |
Quand la privilégier ? |
Exemples |
|
Mutualiser maintenant |
Lorsque la capacité est visible par plusieurs métiers/canaux, évolue fréquemment ou conditionne les premières synergies |
Référentiel de nouvelles offres, règles d’éligibilité, modèles documentaires communs, nouveaux parcours, services de distribution |
|
Faire coexister temporairement |
Lorsque la migration est risquée ou longue mais que le système peut rester derrière une couche d’orchestration |
SI de gestion historiques, portefeuilles legacy, certaines GED, moteurs spécialisés |
|
Retirer progressivement |
Lorsque la capacité est remplacée, que les dépendances ont été supprimées et que les données/processus ont été sécurisés ailleurs |
Anciennes applications front-office, référentiels redondants, interfaces point à point, outils locaux devenus inutiles |
Cette matrice oblige à distinguer deux questions souvent mélangées : « cette application doit-elle disparaître ? » et « avons-nous besoin qu’elle disparaisse pour faire fonctionner le prochain parcours commun ? »
La réponse n’est pas toujours la même.
Avant d’inscrire une brique dans la colonne « migration immédiate », cinq questions permettent de tester la décision.
Si deux réseaux doivent commercialiser une nouvelle offre commune, le référentiel produit ou le parcours peuvent devenir prioritaires. La migration complète d’un portefeuille historique l’est peut-être moins.
Plus une règle, un tarif ou un document évoluent fréquemment, plus maintenir plusieurs implémentations coûte cher. Les capacités soumises à beaucoup d’évolutions sont souvent de bons candidats à une mutualisation précoce.
Migrer un cœur de gestion contenant plusieurs années d’historique n’a pas le même profil de risque que remplacer une application front-office. La trajectoire doit tenir compte de la réversibilité, des volumes, des dépendances et des conséquences opérationnelles d’un incident.
Si deux systèmes peuvent exposer des données ou services via une couche commune, leur coexistence n’empêche pas nécessairement un nouveau parcours d’être mutualisé.
Le progressif ne doit pas devenir une excuse pour repousser toutes les décisions. Un système maintenu temporairement doit avoir une trajectoire, un périmètre et des critères de sortie clairement définis. Une coexistence sans date ni cible n’est plus une transition : c’est une nouvelle architecture permanente par défaut.
Une convergence progressive peut être pensée en plusieurs mouvements.
Deux applications différentes peuvent fournir la même capacité. Une seule application peut aussi mélanger plusieurs responsabilités. Le point de départ consiste donc à cartographier les fonctions : produit, tarification, données, documents, souscription, gestion, identité, affiliation, simulation… Cette lecture permet d’éviter de transformer automatiquement une fusion organisationnelle en projet de remplacement « application contre application ».
Les objets appelés à être utilisés par plusieurs parcours peuvent progressivement être centralisés : produits, règles, modèles documentaires ou modèles de données. C’est ici que les premières synergies deviennent tangibles. Un nouveau produit peut être défini une fois. Les différents parcours utilisent la même version. La documentation suit la même règle.
Les systèmes encore nécessaires restent en place, mais ils deviennent progressivement consommables par la nouvelle architecture. Cette étape évite qu’un nouveau front soit fortement couplé à un ancien back-office. Elle prépare également la migration future. Lorsque le système cible change, le parcours n’a pas nécessairement besoin d’être reconstruit.
Plutôt que de reproduire les anciens parcours des deux entités, les nouveaux projets constituent l’occasion de construire une expérience commune. Distribution, adhésion, simulation ou services de vie du contrat deviennent alors des premières couches réellement convergées. C’est souvent à cet endroit que les métiers commencent à percevoir le rapprochement autrement que comme un programme interne.
Une fois les dépendances détachées, les nouveaux parcours stabilisés et les données sécurisées, la migration ou le retrait d’un système historique devient moins risqué. La transformation du SI n’est donc plus le préalable à la convergence : elle en devient progressivement la conséquence.
Une fusion n’appelle pas automatiquement une nouvelle plateforme destinée à remplacer toutes les autres. La question est plutôt de savoir quelles capacités peuvent être rendues communes pendant que plusieurs environnements continuent de coexister.
C’est dans cette logique que FASST peut intervenir : orchestrer les données, les services et les parcours au-dessus des SI existants, structurer un référentiel commun pour les offres, et leurs différentes versions, et maintenir la cohérence entre règles métier, documents et parcours.
L’ensemble répond à une même logique : faire converger ce qui apporte immédiatement de la valeur métier, sans imposer une migration prématurée de ce qui peut encore rester en place.
Cette approche est particulièrement adaptée aux programmes de transformation où la DSI doit simultanément :
Les dernières actualités font précisément ressortir ce point dans les rapprochements mutualistes. Une fois la convergence juridique engagée ou sécurisée, la question se déplace rapidement vers la coexistence des SI, l’harmonisation des offres et règles, la continuité des portefeuilles et la mutualisation des parcours.
Un programme de fusion est souvent mesuré par la rationalisation : applications retirées, infrastructures mutualisées ou coûts supprimés. Ces indicateurs restent essentiels, mais ils ne racontent pas toute l’histoire.
Quelques mois après un rapprochement, il peut être tout aussi révélateur de savoir :
Ces questions mesurent une autre forme de convergence : la capacité du nouvel ensemble à agir comme un seul groupe avant même d’avoir un seul SI.
Et c’est peut-être là que les premières synergies les plus utiles peuvent être obtenues.
Rapprochement, nouveaux marchés, évolution des offres, ouverture de canaux : les mêmes difficultés réapparaissent lorsque chaque projet recrée ses propres règles, données, documents et parcours.
Notre livre blanc « Industrialiser le modèle collectif » approfondit les principes permettant de construire des capacités réutilisables et intégrables au SI existant afin d’accélérer les transformations successives sans perdre la maîtrise de l’architecture.
En savoir plus sur le livre blanc « Industrialiser le modèle collectif »
Sources