SI dans l'assurance : la politique de la rustine, une économie de court terme, source de coûts cachés

Les DSI du secteur de l'assurance sont face à un dilemme, et doivent choisir leur priorité entre innovation technologique et agilité des systèmes.

Les métiers de l’assurance dommage sont sans cesse en mouvement : changements réglementaires, adaptation des offres, mise en place de services digitaux pour les assurés ou de nouveaux partenariats de distribution… Sans compter les opportunités d’innovation : bénéficier d’outils de détection de fraude, d’estimation des dommages, de modèles prédictifs ou encore d’IA générative est susceptible d’améliorer l’efficacité des organisations.

Tous ces changements nécessitent de la part des directions des systèmes d’information (DSI) à la fois une vision prospective en termes de technologies et de compétences, une bonne dose d’agilité opérationnelle et la mise en œuvre de projets informatiques dans un environnement complexe.

Une accumulation de rustines

Le cœur du système d’information des sociétés d’assurance est généralement un système développé dans un langage de programmation ancien (tel que Cobol) ; parfois un progiciel a été adopté il y a plusieurs décennies, et fortement customisé. Si ces systèmes historiques font preuve d’une grande robustesse, ils sont peu flexibles : difficile de les faire évoluer au rythme attendu par les métiers. Une situation exacerbée par la dette technique, avec l’accumulation de composants logiciels vieillissants et difficiles à maintenir. Cette rigidité encourage une forme de procrastination face aux projets de transformation.

Dans ce contexte, les DSI en sont souvent réduits à une logique de « rustines », bricolées au cas par cas. Il s’agit d’adapter l’existant a minima, pour réduire le coût et le risque des évolutions.

Plusieurs tactiques sont déployées. Fréquemment, l’innovation se déploie d’abord par des expérimentations : POCs, Labs ou sandbox, les assureurs peuvent ainsi tester les capacités prometteuses avant de s’embarquer dans un véritable projet d’intégration informatique.

L’APIsation du système cœur pour y intégrer de nouveaux services étant coûteuse, elle porte généralement sur des domaines fonctionnels réduits. Enfin, pour améliorer l’expérience utilisateur, des démarches d’habillage digital rénovent le patrimoine applicatif avec de nouveaux écrans, même si les processus statiques et les tables de codifications ne disparaissent pas pour autant.

Un patchwork complexe pour les utilisateurs...

Le risque qui émerge est celui d’une juxtaposition d’applicatifs qui tentent de coexister, et entre lesquels les utilisateurs doivent jongler : cela peut mener à des dérives comme le doublon de saisies de données issues de délégataires, ou encore la redistribution de fichiers Excel pour traiter les fraudes. De plus, beaucoup d’expérimentations restent malheureusement dans les cartons : le seuil de rentabilité pour déployer en s’intégrant au cœur de métier est difficile à atteindre.

Chaque projet est « petit », mais peut tout de même prendre plusieurs mois, voire années. Le lancement de produit ou la mise en conformité avec un règlement comme RGPD, par exemple, nécessitent des efforts et des coûts importants pour l’informatique – et donc une frustration devant les délais de mise en œuvre.

Ainsi, le pilotage métier lui-même se complexifie : les services doivent réconcilier des sources de données hétérogènes, et manquent parfois d’une vision consolidée de leurs assurés ou de leurs portefeuilles.

…et un rafistolage permanent pour la DSI

Chaque rustine ajoutée renforce la complexité de l’écosystème applicatif, et augmente les coûts qui lui sont liés. En effet, chaque applicatif est susceptible de venir avec son propre socle technologique, et ses propres dépendances (en composants logiciels, infrastructures, etc.). Le pilotage du SI se complexifie également : la maintenance peut avoir des effets de bord entre applicatifs, et chaque projet oblige donc à des tests de non-régression qui pèsent sur les budgets.

Les assureurs finissent par payer un prix élevé pour maintenir des systèmes obsolètes. Chaque amélioration ponctuelle se transforme en un projet chronophage et onéreux. Chaque projet innovant se retrouve confronté aux même défis, même s’ils apparaissent sous un jour apparemment nouveau : l’insertion des outils dans le poste de travail ou l’intégration avec différents modules peuvent s’envisager via un EDI, un ESB, un portail dédié, des APIs, etc. Les solutions envisagées sont diverses, mais répondent en réalité toujours au même enjeu : réconcilier les nouvelles technologies avec un système transactionnel vieillissant, qui n’a jamais été pensé selon un architecture en micro-services.

A mesure qu’apparaissent les coûts cachés de cette approche fragmentaire, certaines initiatives transversales sont parfois entreprises : l’introduction de data lakes, de nouveaux outils de business intelligence, de middlewares, de CRM consolidant des systèmes hétérogènes, etc. Plus ambitieuses, ces approches ont des résultats souvent décevants. En effet, en se concentrant sur des couches périphériques du système applicatif, les projets tendent à réparer les failles sous-jacentes du statu quo, plutôt que d’apporter une véritable agilité aux équipes métiers. C’est alors toute la stratégie d’entreprise qui risque d’être subordonnée aux contraintes des outils en place.

Investir dans la transformation

Les petits ruisseaux font les grandes rivières, c’est pourquoi identifier ces coûts cachés est essentiel. Pourtant, ce constat ne doit pas pousser à l’inaction : il démontre que le retour sur investissement d’une transformation en profondeur existe.

L’essentiel pour l’aborder n’est pas de réparer chaque brique applicative dont l’obsolescence est la plus grande, mais de partir des enjeux stratégiques du métier pour définir une trajectoire adaptée. En redéfinissant l’architecture applicative de demain, les nouvelles technologies retrouvent leur place de facilitateurs, et les DSI leur rôle de conseil dans une stratégie de transformation.