Et si votre système d’information était au service de votre entreprise ? S’il permettait le développement de nouvelles applications sans perdre trop de temps à redévelopper certaines fonctions déjà utilisées par ailleurs ? Ou encore s’il vous remontait en temps réel ses données sur son fonctionnement (temps moyen d’une transaction, alerte immédiate en cas d’incident, etc.) ? Ces utopies sont désormais réalité à condition d’imposer une nouvelle architecture à son système d’information, la SOA – Service Oriented Architecture – et d’adopter ses différents corollaires (BPM, BAM, BTM, etc.) à ses besoins. Présentés comme des solutions miracles depuis trois ou quatre ans (voir Revue Banque nº 608 de mai 2006), la SOA et le BPM ont eu du mal à quitter les rêves de la direction des services informatiques pour devenir de véritables outils de production. La crise et les économies qu’elles nécessitent, mais aussi l’arrivée de nouvelles normes réglementaires – comme Sepa, Bâle ou Solvabilité – qui imposent un suivi plus pointilleux des différentes opérations, les remettent au goût du jour, à la demande cette fois-ci des directions opérationnelles.
Les banques centrales montrent l’exemple
Pour Christian Lefèvre, directeur commercial de Software AG, l’un des principaux éditeurs du secteur, « jusqu’en 2009, nous étions dans une phase de pionniers technophiles. Désormais, ce sont des problématiques qui émergent un peu partout sur le marché. Les principales institutions sur la place de Paris y réfléchissent et lancent des projets qui devraient aboutir fin 2010, début 2011 ». Si les banques régulières restent à leur habitude très discrètes sur leur utilisation de la SOA et du BPM, l’exemple vient d’en haut. « Les grandes banques centrales, la BCE, mais également la Banque de France et la Banque d’Italie s’y intéressent, notamment pour travailler plus facilement entre elles », explique Christian Lefèvre. Gilles Leflambe, responsable ventes chez Systar, un éditeur de BAM, le confirme : « Le degré de maturité SOA/BPM est variable. Il y en a dans toutes les banques, mais à des degrés variables. Ces technologies ne sont pas encore largement répandues malgré 10 ans d’existence ». Ainsi, l’un des grands clients historiques de sa société est une des plus grosses banques françaises, qui a d’abord adopté une architecture orientée service à la demande de sa DSI et s’en est servie peu à peu dans une optique métier pour superviser le paiement, les titres et l’infrastructure Swift. « Les motivations étaient historiquement liées à l’informatique et à la réduction des risques, et on s’oriente progressivement vers la mesure de la performance et de l’expérience client (NDRL : les clients de la banque) qui deviennent des enjeux stratégiques. »
Profiter de la refonte du métier pour introduire le BPM
Pour Ludovic Poirier Coutansis, responsable banking et distribution, Sopra Group, ce regain d’intérêts pour la SOA et surtout le BPM et ses corollaires, correspond
à une évolution du métier des banquiers :
« Même si le concept est ancien, sa mise en oeuvre est récente. Il correspond à la restructuration des grands établissements, à la mutualisation des services et à la refonte du système de distribution des banques ». Ainsi, dans le domaine du paiement, les banques profitent du passage obligé vers Sepa et de la refonte du métier qu’il génère pour refondre les outils techniques et introduire du BPM. Pour autant, ce passage au BPM ne va pas sans heurts.
Philippe Bessis, Solutions Sales manager d’HP Software y voit deux obstacles : « Il y a un frein humain. Chacun dans l’entreprise veut avoir ses propres Legos ou services informatiques. La difficulté est alors que chacun ne reconstruise son propre catalogue de services et que ceux disponibles ne puissent s’adapter aux différents départements de la société. En SOA et BPM, les retours sur investissements sont également très difficiles à identifier, ils ne se font pas dans l’année, et le ticket d’entrée est plutôt élevé pour le premier projet qui a du mal à se financer ».
