Quel choix pour votre système d'information : progiciel ou développement maison ?

Quel choix pour votre système d'information : progiciel ou développement maison ?
Daniel Dupuy,DSI d’Aviva France

Les systèmes d’information constituent un investissement important pour les acteurs de l’assurance. Mais a contrario d’autres industries, le développement d’outils internes fait encore des adeptes parmi les compagnies, mutuelles ou groupes paritaires. Explications des DSI.

Pas de dogmatisme, du pragmatisme... Tel est le maître mot chez les assureurs quand on aborde le sujet des progi­ciels pour la gestion de leurs activités cœur de métier...

« Il ne peut y avoir une démarche systématique qui considérerait que, désormais, tous les besoins informatiques seraient à satisfaire ­systématiquement à travers des solutions progiciels. Certains contextes y sont favorables, d’autres beaucoup moins. Parmi les critères de choix, figurent la nature du besoin et son niveau de transformation de l’existant », ­résume Claude ­Benzakki, ­directeur études chez Generali France. En résumé, si un système d’information interne est jugé pérenne, et qu’il est possible de répondre à un nouveau besoin sans trop le modifier, l’hypothèse de basculer sur un progiciel est écartée. À l’inverse, si un besoin s’exprime sur un nouveau ­périmètre non encore couvert, alors la piste du progiciel est ­étudiée.

Du « fait » maison pour les éléments différenciants

« Un progiciel est bien adapté sur les activités de gestion très industrialisées, sans nécessité de diffé­ren­ciation. Ainsi, gérer la santé, c’est la même chose chez tous les acteurs : nous calculons des cotisations, nous les encaissons, nous versons des prestations... aussi un progiciel, si c’est une bonne solution, suffit », détaille Claire Mayaux, directrice du digital et des SI à la Mutuelle nationale territoriale (MNT). Par contre, pas question d’utiliser un outil du mar­ché pour tout ce qui est jugé comme générant de la valeur ajoutée ! « Il faut savoir où se trouve la valeur de différenciation de ­l’entreprise. Parfois elle réside dans les processus eux-mêmes. Dans ce cas, il peut être difficile d’envisager de prendre un progiciel, car il y a des éléments concurrentiels forts dans la façon de concevoir les produits et d’organiser les processus », explique Pierre de Barochez, DSI de la Macif.

Ainsi la MNT estime que la transformation numérique ne peut se faire qu’avec des outils développés en interne. Elle a donc développé elle-même son middle office pour pouvoir publier des données sur Internet. Elle a aussi créé les espa­ces digitaux pour les adhérents, les collectivités, ses militants... « Nous voulons maîtriser les codes sources et les coûts. Toutes les interfaces ­utilisateurs, nous les codons nous-mêmes », poursuit Claire Mayaux.

Le groupe Allianz a fait le choix de créer son propre progiciel, ABS, qu’il propose à ses filiales. Cette solution progicielle interne couvre l’IARD, aussi bien pour la gestion de la souscription que l’indemnisation, mais aussi la vie et la santé. « En France nous ne déployons que l’IARD, car sur les autres périmè­tres, nos systèmes sont stables et pérennes. Nous avons démarré les travaux de migration mi-2012 », souligne Alexander Heinrich, direc­teur de l’organisation et des solutions architecture d’Allianz France. À Vienne (Autriche), un cen­tre de compéten­ces avec 200 informa­ticiens, fonctionne comme un éditeur et livre deux versions majeures par ­an.

Daniel Dupuy, DSI d’Aviva France
« Moderniser notre système maison brique par brique »

« S i l’existant est très lourd et très pénible à maintenir, on peut décider de mettre tout à la poubelle et de reconstruire un système coeur de métier basé sur un progiciel. Certaines de nos filiales ont opté pour ce choix en dommages mais aussi en épargne. Les montants d’investissement sont cependant très importants, au-delà des 100 M€, pour au final avoir quasiment le même périmètre fonctionnel qu’avant. En France, notre approche est basée sur la modernisation de notre système maison : peu à peu, nous le déshabillons de toutes les fonctions qui nécessitent des évolutions fréquentes et nous n’y gardons que des choses sanctuarisées. Pour répondre rapidement à des besoins business, nous avons, par exemple, externalisé les tarifs dans un moteur de règles qui nous permet de les faire évoluer en quasi-temps réel. Nous investissons de moins en moins sur notre système maison, et de plus en plus sur des briques de gestion de processus, de règles métier. »

Mutualisation des développements

« Nous mutualisons beaucoup de développements entre les pays, mais aussi de compétences, avec des équipes d’experts pour la conception et le déploiement. C’est un vrai choix de la part de la ­direction générale. Nous avons tous les avantages d’un progiciel du marché, mais totalement adapté à nos besoins, et pas plus d’inconvénients », résume ­Alexander Heinrich. La mutualisation est un élément qui intéresse les assureurs, car leur métier n’est pas de développer des applications, et tout le monde n’a pas les moyens d’Allianz. « L’intérêt principal d’opter pour un progiciel est de permettre de moins se consacrer à la technologie pour s’investir davantage dans la relation client et le développement du digital. Et, en optant pour un progiciel, on bénéficie d’investissements mutualisés entre différentes sociétés, notamment pour la couche réglementaire », résume Pierre de ­Barochez. La promesse est séduisante. Encore faut-il réussir à ne pas abuser des développements spécifiques. Ce n’est pas l’outil qui doit s’adapter à l’organisation de l’entreprise, mais l’entreprise qui doit réussir à s’adapter au fonctionnement de l’outil... Trop de spécificités informatiques comple­xifient la maintenance de l’outil qui parfois n’est plus compatible avec le ­produit de l’éditeur.

Claire Mayaux, directrice du digital et des SI à la Mutuelle Nationale Territoriale (MNT)
« Éviter le spécifique dans les progiciels »

« Quand on retient un progiciel, il ne faut pas faire de développements spécifiques, sinon on s’expose à de gros problèmes « d’évolutivité ». Nous sommes équipés de Cegedim depuis 2003 pour la santé. À la suite d’une succession de développements spécifiques nous avons atteint toutes les limites. Ce progiciel est devenu, par les développements successifs que nous avons souhaités, un monstre qui n’a plus rien à voir avec ce que fabrique l’éditeur et qui ne peut plus répondre à nos besoins. Nous devons donc tout reconcevoir et nous allons certainement devoir refondre le paramétrage. Nous reprendrons un progiciel, mais cette fois en évitant les développements spécifiques. Par ailleurs, seules les parties contrat et gestion devraient y être hébergées. La question se pose pour les données référentielles et les fonctions à forte valeur ajoutée comme le référentiel des adhérents, le catalogue de nos produits et services, les relations commerciales... Afin de rester agiles et en capacité de répondre au Time to Market. » (NDLR : temps de développement de produit).

Un coût moindre ?

Difficile, en outre, de savoir si un progiciel coûte plus ou moins cher qu’un système maison. « Beaucoup de paramètres entrent en jeu dans le calcul des coûts, et tous les cas de figure sont possibles. Le ­progiciel peut paraître moins cher car l’inves­tissement est mutualisé, mais il y a un coût d’intégration à inclure et, souvent, les compétences pour le faire évoluer coûtent plus chères que celles ­nécessaires à la maintenance d’un outil maison », estime Pierre de Barochez. Le DSI de Klésia, ­Jérôme Sennelier, assure, pour sa part, que le coût final d’un système développé en interne est souvent supérieur à un progiciel « car on a rarement la capacité à imaginer toutes les subtilités de ce que l’on va construire, et on se ­retrouve vite avec un système monstrueux ».

Jérôme Sennelier, DSI de Klésia
« Un progiciel en santé et en prévoyance d’ici 2019 »

« Les éditeurs en assurance santé et en prévoyance sont assez nombreux et plutôt sur un marché qui se normalise. Pour ces raisons, mais pas uniquement, nous avons fait le choix, début 2016, d’aller sur une solution progiciel, avec une migration progressive jusqu’en 2019. Les enjeux d’évolution réglementaire et les besoins d’investissements font qu’investir dans des développements spécifiques n’est plus raisonnable. Nous voulions pouvoir mobiliser nos talents et nos ressources sur des éléments plus différenciants et plus structurants comme la relation avec nos clients, nos partenaires de distribution et la maîtrise des données. Cela va nous permettre aussi de nous concentrer sur les évolutions nécessaires au regard des nouvelles réglementations européennes sur la protection des données personnelles. Nous avons retenu une solution en mode SaaS (NDLR : logiciel installé sur un serveur distant), où nous sommes facturés en fonction du nombre de bénéficiaires. Cela nous permet de maîtriser au mieux les coûts sur un marché en forte évolution et où la concurrence est croissante. »

Risque de pérennité

Mais l’un des principaux freins, pour les assureurs reste la peur d’acheter un progiciel qui n’évolue plus, ou pire, que son éditeur disparaisse... « Pour nous, un des premiers critères pour développer une solution en interne ou choisir un progiciel est le nombre d’éditeurs présents sur le marché. Ce nombre est souvent réduit, car l’assurance est un marché restreint pour les éditeurs de progiciels métiers », regrette Pierre de Barochez qui a donc retenu une solution externe pour la gestion de la santé. Il estime que le marché était assez mature, alors que sur l’IARD, il a conservé un système interne. Autre frein : la difficulté de passer d’un système à l’autre. « Il faut être prudent quand il s’agit de migrer des données pour passer d’un ­système propriétaire à un progiciel. En effet, cette migration n’apporte souvent aucune valeur ajoutée ­directe aux clients, et cela constitue un projet comple­xe, où l’expertise est rare, ce qui génère du risque, des délais et des coûts significatifs », prévient Pierre de ­­Barochez.

Le tout progiciel n’est donc pas pour demain chez les assureurs...

Sébastien Renard, Directeur Général du cabinet Enioka Consulting
« Une décision avec la direction générale »

  • Qui doit prendre la décision de basculer ou non sur du progiciel ?
    Ce n’est pas une décision à prendre seulement au niveau de la DSI . Cela doit être un choix partagé avec la direction générale. Elle doit s’interroger sur la capacité de l’entreprise à se différencier de ses concurrents, sur le niveau d’investissement qui peut être consenti... Choisir un progiciel signifie que le service est devenu une commodité, sans véritable valeur ajoutée propre. Ce choix ne se réduit donc pas à des questions de coût ou de technologie.
  • Pourquoi les assureurs utilisent-ils peu de progiciels pour leurs systèmes d’information métier ?
    Ils ont été parmi les premiers à s’informatiser avec les banques. I ls sont nombreux à être encore sur des grands systèmes mainframe (NDLR : ordinateur central relié à un réseau de terminaux) avec des langages anciens comme Cobol. Ces systèmes sont tellement complexes et représentent tant d’années d’investissement que tant que cela fonctionne, ils n’osent pas trop y toucher... O u alors par petites touches, très progressivement. Un progiciel représente un changement souvent trop radical pour gérer le coeur du métier. Il a par contre sa place pour le lancement d’une nouvelle activité sur un produit spécifique ou un nouveau pays.
  • L’offre est-elle aussi un frein ?
    Sur le marché de l’assurance, il y a très peu de clients et la palette de métiers est très large. Ce n’est donc pas évident pour les éditeurs de proposer des progiciels. La plupart sont de taille moyenne ou bien le produit n’est pas leur coeur de métier. Il est donc difficile de prévoir la pérennité de l’outil sur les 5 ou 10 prochaines années.

Emploi

SIACI

Gestionnaire Sinistres Construction H/F

Postuler

KAPIA RGI

Chef de Projet Assurance-Vie H/F

Postuler

+ de 10 000 postes
vous attendent

Accéder aux offres d'emploi

Commentaires

Quel choix pour votre système d'information : progiciel ou développement maison ?

Merci de confirmer que vous n’êtes pas un robot

Votre e-mail ne sera pas publié