Pour gérer vos consentements :

SMABTP bétonne sa refonte en mode SOA

Publié par La rédaction le | Mis à jour le

À l'heure où il fait bon parler de projets informatiques de trois mois, la refonte du groupe mutualiste a été planifiée sur 6 ans, pour durer 10 ans. Une bonne moyenne pour une réelle migration selon Jean-Michel Detavenier, son DSI adjoint

Créé en 1859, le Groupe SMABTP (société de mutuelle d'assurance du BTP) est le leader de son secteur avec 120.000 assurés, un chiffre d'affaires de 1,95 milliard pour environ 14 milliards d'actifs gérés, et 2.068 salariés. Ayant misé très tôt sur l'informatique, SMABTP y consacre des moyens conséquents : 47 millions d'euros de budget annuel (soit 2,4 % du CA) pour 144 personnes au service informatique et 110 prestataires (chiffres 2008). Le parc reflète cette stratégie : 3.000 postes de travail, 130 serveurs, 5 téraoctets de données en ligne, et un million de pages vues par mois sur Internet.

Le pionnier a pris du plomb dans l'aile

« Le système d'information de la SMABTP affichait une belle avance technologique dans les années 60, avec une approche favorisant déjà une orientation client », explique Jean-Michel Detavernier, DSI adjoint de SMABTP. « Depuis les années 90, les applications se révélaient complexes à maintenir, peu flexibles, et présentaient de multiples redondances. Des choix d'outils clients/serveur s'étaient finalement avérés malheureux, accentuant la dépendance vis-à-vis des applications grand systèmes. Or, il nous fallait quitter cet environnement mainframe pour gagner en souplesse et en réactivité. Par ailleurs, l'ERP centralisé très simple ne pouvait répondre aux besoins complexes de gestion de l'activité construction. »

Une migration pluriannuelle plutôt qu'un maquillage illusoire

Une refonte informatique démarre alors en 2001, avec le choix d'une orientation SOA marquant une "rupture étalée dans le temps".« Dès le départ, nous planifions une cohabitation du nouveau système avec l'ancien, pendant plusieurs années. Et une migration progressive des règles et des composants permettra, à terme, d'abandonner totalement le grand système en évitant les ruptures. Objectif : disposer d'une informatique agile, contrairement à l'ancien système comptable rigide et ne contenant pas les règles métier de nos activités », se souvient le DSI adjoint. Cette situation est commune dans le secteur de l'assurance. Et pour y remédier, de nombreuses entreprises se contentent de rhabiller les applications.

Certes, les projets sont plus courts dans le temps, mais la dépendance vis-à-vis des anciens applicatifs reste presque totale. En outre, les coûts de maintenance explosent compte tenu de la superposition des couches logicielles. C'est justement le crédo de Jean Michel Detavernier, coauteur du livre "Sustainable IT Architecture" et à l'origine du site www.sustainableitarchitecture.com : « Il est vrai que la création d'un nouveau système avec l'approche que nous avons retenu peut s'étaler sur plus de 5 ans, voire près de dix ans. Mais, nous utilisons le nouveau système depuis le début du projet, et nous abandonnons progressivement des composants anciens, portés sur de nouvelles technologies. Au final, il faut supprimer l'ancien système, car sans abandon de l'ancien : pas de gain ! »

Un concept bien huilé pour orchestrer la manoeuvre SOA

« Notre orientation SOA (basée sur plate-forme EAI ou ESB.) repose sur ce que nous avons baptisé ACMS (Agility Chain Management System ou système de gestion de la chaîne d'agilité). Le principe consiste à conjuguer trois composants majeurs : le BPM (Business Process Management), le MDM (Mater Data Management) et le BRMS (Business Rules Management System) »,annonce Jean Michel Detavernier. Et tout est parfaitement orchestré dans le cycle de remplacement de l'existant. Ainsi, le MDM d'Orchestra Network permet de rationaliser les données de référence et les paramètres de gestion en apportant l'indépendance aux services d'exécution qui reposent sur des modèles de paramétrage. Alors, le moteur de règles du BRMS d'Ilog utilise ces paramètres pour décrire les règles métier. Enfin, les processus utilisent le BPM EProcess de Tibco et les règles dans l'acheminement des informations à travers les différentes étapes.

Sortez les marteaux-piqueurs

Dans la première phase, une approche technique de bas en haut (Bottom-Up) part de l'infrastructure vers l'applicatif, le fonctionnel, puis le métier. Au passage, il s'agit de déterminer ce qui est réutilisable ou non, de séparer le statique du dynamique, d'automatiser si possible. « Nous avons attaqué le code au marteau-piqueur afin d'en extraire les règles de programmation, afin de les réécrire et de les remplacer par celles de la nouvelle infrastructure. On note ici le point difficile à expliquer à des dirigeants et financiers : l'utilisateur final ne voit et ne perçoit pas de différence immédiate dans le comportement des applicatifs. En outre, il faut les convaincre de la nécessité d'investir toujours 10 % du budget informatique pour la refonte progressive du SI pendant une longue période de plusieurs années ! » assure Jean Michel Detavernier. « Le budget informatique représente 2,4 % chiffre d'affaires. Ce ratio étant maintenu dans le temps, il nous permet de lisser l'investissement. Une opportunité pour un projet estimé à 6 ans, et qui finira par durer 10 ans. Par ailleurs, il nous est aussi demandé de rester à effectif constant. »

L'indispensable discours de la méthode

Dans la seconde phase de refonte, SMABTP a opté pour une approche Top-Down, pour réécrire ou compléter les composants lorsque nécessaire, selon les besoins actuels et futurs. Les nouveaux processus et nouvelles demandes sont intégrés. « Après avoir extrait les règles de l'existant, une phase d'optimisation par rapport aux besoins opérationnels des métiers se met en place avant leur recréation dans le nouveau système »,souligne Jean Michel Detavernier. Bien entendu, l'ensemble repose sur une méthodologie (Merise, UML, Open Source.). « Pour pouvoir travailler efficacement ensemble, tous les informaticiens et intervenants du projet sont formés à notre méthodologie open source Praxeme. Remarquons que la refonte et la création de nouveaux composants nécessitent de créer des équipes mixtes intergénérationnelles, conjuguant la connaissance métier des anciens, et les compétences nouvelles technologies des plus jeunes », conclut Jean Michel Detavernier.

La rédaction vous recommande