En route vers les progiciels

Hubert d'Erceville, Erick Haehnsen, Eliane Kan, et François Lazard

01 Informatique

le 08/08/2007 à 07h00

envoyer
par mail

imprimer
l'article

Réduction des coûts, obligation de gagner en productivité, nouveaux chantiers réglementaires comme Mifidou Sepa… Ces besoins remettront-ils en cause les systèmes informatiques des grandes banques de détail ? La question mérite d'être posée. En effet, la maintenance d'applicatifs écrits en Cobol pose actuellement de nombreux problèmes. A commencer par la pénurie des compétences et les coûts de maintenance élevés.

Des difficultés qu'aplanirait l'adoption d'une solution “ best of breed ” (dédiée) pour traiter le back office (gestion administrative et opérationnelle, et systèmes de paiement) et le front office (gestion de la relation client). Une vingtaine d'éditeurs proposent des solutions aux fonctions plus ou moins étendues. Entre autres, Callatay & Wouters, Temenos, ou encore Viveo. A l'opposé, les grands éditeurs de progiciels de gestion intégrés déclinent des offres spécialisées pour la banque. Ainsi Oracle avec Flex-cube (par le rachat d'I-Flex), Oracle e-Business Suite, et Peoplesoft Enterprise. Citons encore SAP avec son logiciel SAP for Banking.

Une architecture spécifique

“ Historiquement, seules les petites et moyennes banques ont adopté des progiciels bancaires ”, remarque Nicolas Ullmo, expert d'Unilog Management. En revanche, les grandes banques de détail hésitent encore à opérer une migration de type big bang sur des milliers d'applications. Celles-ci disposent d'une architecture spécifique qui les contente.

“ Le système informatique bancaire repose sur un interpréteur [EAI pour Enterprise Application Integration, NDLR], qui aiguille les flux issus des différents applicatifs vers les systèmes de comptabilité et de gestion, en fonction de règles préalablement définies ”, décrit Bernard Simon, consultant chez Oracle. L'éditeur fournit un interpréteur avec lequel les banques peuvent alimenter leur comptabilité à partir d'autant d'applications maison et de progiciels que nécessaire.

D'où leur hésitation à remettre en cause l'existant. Certes, les tentatives existent. La Banque postale a lancé l'an dernier un appel d'offres pour un progiciel de gestion intégré bancaire, resté sans suite… Ailleurs, l'idée d'une solution tout-progiciel continue de germer. “ Certaines grandes banques de détail entreprennent de tester des pilotes dans leurs filiales situées sur des marchés émergents ”, indique Gilles Faucheur, responsable du département PGI/SAP chez Steria.

En projet aussi, la mise en place d'architectures orientées service (SOA), qui favoriseraient les échanges entre applications. Cette approche est soutenue par l'éditeur SAS, qui argue de l'intérêt de créer de grandes bases de données globales, exploitées par des outils décisionnels. Patrick Le Nôtre, directeur de la stratégie du secteur finances de SAS, promeut ce scénario : “ Avec ce type d'architectures, les solutions répondant à des problématiques réglementaires peuvent être déployées très rapidement. En outre, cela évite de dupliquer les données huit à dix fois, comme c'est souvent le cas aujourd'hui. ” De quoi gagner sérieusement en productivité.

L'EAI au cœur de l'infrastructure bancaire

agrandir la photo

Les données issues de différentes sources (progiciels ou applicatifs bancaires, logiciels de gestion de la relation client, progiciels de gestion intégrés, systèmes tiers, etc.) convergent vers une base de données transactionnelles pour être acheminées vers l'interpréteur. Ce système d'intégration d'applications (EAI) les injecte dans la compatibilité générale et les systèmes de gestion exploités par des logiciels décisionnels. Grâce à l'édition de tableaux de bord de pilotage, la banque suit la gestion de ses clients et de ses risques, ou sa conformité aux normes.