Par Patrick
Soulignac, Manager Conseil Solutions, Guidewire.
Les métiers de
l’assurance IARD 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êmes 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 une 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.