Interview

Aimé Achard, BCV: «Pour des motifs économiques et stratégiques, le rapatriement coulait de source»

| Mise à jour
par Interview: Rodolphe Koller

En décembre 2012, la Banque Cantonale Vaudoise a rapatrié à l’interne le développement et la maintenance de sa plateforme bancaire. Entretien avec Aimé Achard, Directeur général.

Aimé Achard est Directeur général de la Banque Cantonale Vaudoise, notamment en charge de l’informatique. Il estime que la plateforme bancaire Osiris employée par l’établissement n’a rien à envier aux solutions standard du marché. (Quelle: BCV)
Aimé Achard est Directeur général de la Banque Cantonale Vaudoise, notamment en charge de l’informatique. Il estime que la plateforme bancaire Osiris employée par l’établissement n’a rien à envier aux solutions standard du marché. (Quelle: BCV)

La BCV a annoncé en décembre dernier qu’elle rapatriait à l’interne le développement et la maintenance de sa plateforme bancaire, alors confiés à IBM. Qu’est-ce qui vous a amené à prendre cette décision?

La réponse mérite un peu d’historique. Dans les années 90, la BCV a créé la société Unicible avec les banques cantonales de Genève, de Neuchâtel et du Valais, pour développer une plateforme bancaire commune, à savoir Osiris. Dans le milieu des années 2000, les autres banques cantonales, comme d’autres acteurs du secteur, ont alors opté pour d’autres solutions telles que Finnova ou Avaloq.  La BCV, devenue ainsi seule utilisatrice d’Osiris, a alors réfléchi à sa stratégie informatique et, en 2007, la direction a décidé d’opter pour une solution commune avec la Banque Cantonale de Zurich (ZKB). Ce faisant, nous abandonnions tant notre plateforme qu’Unicible. Il fallait donc d’une part trouver un avenir aux quelque 300 collaborateurs et protéger l’opérationnel jusqu’à la fin de la transition en 2011. La BCV a décidé de transférer les actifs d’Unicible à IBM, qui était la seule société à avoir fait une offre complète avec une vision d’avenir. L’idée était qu’IBM reprenne le personnel d’Unicible et ne s’occupe d’Osiris que jusqu’à la fin de la migration.

Mais le projet avec la ZKB a finalement avorté…

En effet. En 2008, après avoir entrepris des travaux de détails approfondis sur le projet, nous nous sommes rendu compte que le projet entraînerait des difficultés sur les plateformes, des frais de migrations très importants et des coûts récurrents consécutifs au changement de plateforme beaucoup plus élevés avec un planning incertain de mise en œuvre. D’un commun accord avec la ZKB, nous avons donc arrêté. IBM a alors accepté de prolonger notre contrat couvrant le hosting et le développement jusqu’en 2016, avec une extension possible jusqu’en 2018. Ce qui nous a conduits à nous réorganiser pour passer en mode d’outsourcing sur la durée, notamment en termes d’analyse et de suivi du partenaire. Il fallait aussi réfléchir à notre avenir au-delà de 2016-2018.

Pourquoi avoir finalement décidé de rapatrier les opérations confiées à IBM? Pourquoi seulement fin 2012?

Tout d’abord, durant les années 2009 et 2010, nous avons été très occupés à adapter notre mode de fonctionnement au vu de la nouvelle donne. Ensuite, la question de ce qui se passerait après 2016 s’est rapidement posée, tant pour nous que pour IBM, avec laquelle nous avons entamé des discussions courant 2012. D’un point de vue stratégique, cela ne faisait pas de sens de continuer à outsourcer le développement et la maintenance d’une plateforme dont nous sommes les seuls utilisateurs. Idem pour IBM, qui ne pouvait pas se comporter en éditeur et mutualiser ses coûts. De plus, nous avons pu entretemps apporter de considérables améliorations à Osiris. Pour des motifs économiques et stratégiques, le rapatriement coulait donc de source. Sans compter que, pour les collaborateurs d’Unicible-IBM travaillant sur Osiris, le fait de réintégrer la BCV était plus porteur d’avenir.

Pour IBM, c’est un contrat juteux qui s’arrête et pour vous des coûts réduits…

Pour IBM, le maintien de cette activité et de ces compétences pour un seul client n’était certainement pas stratégique. Certes, le contrat représentait un certain cash-flow, mais ils se sont montrés compréhensifs à l’heure de négocier. Mais j’insiste, le rapatriement a été décidé pour des raisons plus stratégiques qu’économiques. 

Pour quelles raisons avez-vous décidé de rester sur la plateforme Osiris?

Nous avons analysé nos options. Après examen de la plateforme, y compris avec les métiers, il nous est apparu qu’Osiris était fonctionnellement satisfaisante – sans être extrêmement moderne. Elle date de 94, ce qui est tout à fait comparable à d’autres solutions. De plus, c’est une plateforme solide et stable. Nous avons des taux de disponibilité de 100% pour la partie centrale et nos relevés sortent à J+2. Au niveau technologique, la plateforme a également montré qu’elle pouvait évoluer. Nous avons pu introduire des systèmes aussi sophistiqués que les revenus clients, construire un CRM, ou encore y brancher une plateforme internet qui fonctionne très bien. En résumé, Osiris a été améliorée sur tous les points qui avaient conduit, à l’époque, au rapprochement avec la plateforme zurichoise. Elle est fonctionnellement satisfaisante, pérenne et fiable. Si bien que nous avons décidé de conserver cette plateforme pendant au moins les six prochaines années.

Aujourd’hui, beaucoup d’établissements misent sur des plateformes bancaires standard du marché pour mutualiser leurs coûts…

Ce n’est pas toujours vrai et cela dépend de la taille des banques. UBS, Credit Suisse ou la ZKB ne recourent pas à des plateformes standard. Il faut analyser les coûts-bénéfices du passage à une telle plateforme. Pour une banque comme la BCV, qui compte plus de dix métiers et 500 000 clients, les coûts d’une migration sont très élevés. A eux seuls, ils rendent cette option difficilement justifiable. De plus, les plateformes du marché, comme Avaloq et Finnova, ne sont pas plus récentes qu’Osiris et n’apportent pas de gain fonctionnel majeur. Aujourd’hui, la question ne se pose donc pas. Ce qui ne veut pas dire que dans quelques années nous n’étudierons pas l’option d’une migration, notamment en cas de besoin d’une refonte profonde de la plateforme.

En misant sur une plateforme standard, vous profiteriez d’évolutions incrémentales à moindre coût. Cela ne suffit-il pas à rendre cette option intéressante?

En toute modestie, si l’on regarde les dernières évolutions liées à FATCA et Rubik, nos coûts d’implémentation n’ont pas été beaucoup plus élevés que pour les autres banques. Tant qu’il n’y a pas de saut quantique imposé, nous n’avons pas trop de problème, même si j’admets que nous sommes un peu plus chers. Par ailleurs, les plateformes standard conviennent à des établissements avec un business mix plus simple, à l’instar des banques privées ou des banques de détail orientées crédit hypothécaire et épargne. En revanche, les établissements avec des métiers plus diversifiés sont contraints d’entretenir une certaine complexité de leur informatique. Nous avons par exemple des solutions connexes pour l’asset management et le crédit documentaire. Cette complexité réduit de beaucoup les avantages de la mutualisation.

Quels changements organisationnels entraîne le rapatriement des activités de maintenance et de développement à l’interne? Où en est le projet?

Le projet a démarré fin novembre 2012 et les collaborateurs transférés travailleront à la BCV dès le 1er juillet. Cela faisait longtemps que nous n’avions pas eu une telle équipe d’informaticiens à l’interne. Il ne s’agit toutefois pas d’un projet de transformation, mais de transition. Nous reprenons une activité en marche, avec des procédures – établies par IBM – et nous n’allons pas réinventer la roue. De plus, nous avons entamé dès 2009 une réorganisation de l’informatique de la BCV, qui facilite cette transition. La nouvelle structure comprend un pôle évolution – le change – qui regroupe des collaborateurs auparavant disséminés dans les métiers. A partir de juillet, le développement va naturellement rejoindre cette entité. Le second pôle concerne les opérations – le run – avec la double mission de faire le suivi du fournisseur et des applicatifs, notamment en termes de paramétrage pour les utilisateurs. Nous avons également créé un troisième pôle architecture suite à la décision de piloter notre IT par l’architecture et d’éviter les ajouts applicatifs non-coordonnés. Nous sommes donc prêts sur le plan de la structure et il va falloir un peu d’accoutumance au niveau de la gestion des équipes. En ce qui concerne l’interface avec le partenaire, nous avions déjà commencé à mettre en place des processus qui se terminaient à la frontière avec IBM. Désormais, cette frontière s’est déplacée d’un cran; elle est passée du développement à la production. Avec également des implications au niveau du réseau, de la gouvernance ou de la sécurité.

Quels bénéfices attendez-vous de ce contrôle de votre architecture IT?

Comme nous n’avons pas de mutualisation, nous devons être encore plus vigilants quant à l’évolution des coûts IT. Nous devons sans cesse penser à la rationalisation et je suis très heureux lorsque l’on parvient à supprimer une application. Notre approche est la suivante: réutiliser plutôt qu’acheter, acheter plutôt que développer. Il faut exploiter au maximum les outils existants. Si j’ai une solution qui remplit 80% de la demande, je ne vais pas prendre le risque de la remplacer pour atteindre 100%. C’est aussi un message que nos analystes portent aux métiers.

Tous les coûts informatiques sont-ils imputés aux métiers?

Oui, tous les coûts informatiques sont ventilés. Nous sommes à même de calculer le prix de chaque applicatif et de le déverser sur les métiers. L’informatique d’une banque est assez chère et c’est la seule manière de sensibiliser les utilisateurs. Je constate cependant une évolution heureuse chez mes collègues qui prennent conscience du prix à payer pour satisfaire telle ou telle demande. Les relations entre l’IT et les métiers s’en trouvent changées. A l’inverse, cette évolution fait qu’il devient extrêmement difficile de vendre des projets d’infrastructure ou d’architecture qui n’amènent pas de gain métier immédiat. Nous sommes par exemple en train de passer à un cloud d’entreprise et, avant de démarrer, il a fallu démontrer un retour sur investissement. Pour l’IT, il s’agit en l’occurrence d’un gain technologique, mais pour les métiers ce sont surtout des économies à la clé: on sera moins cher. Les temps de réponse seront également beaucoup plus rapides, il n’y a pas photo. Actuellement, les projets de sécurité sont en revanche bien plus vendeurs; tout le monde y est sensible pour les raisons qu’on connaît, même si je ne pense pas qu’il soit bon de subir les évènements.

Que pensez-vous de la menace de nouveaux entrants venant concurrencer les banques sur la base d’atouts technologiques?

C’est à surveiller. Je pense que le prochain saut quantique dans le domaine bancaire arrivera de ce genre d’innovations. Swisscom et Orange seront peut-être un jour nos concurrents. Cela concerne néanmoins l’interface publique de la banque. Pour le reste, il y a un savoir-faire bancaire qui reste très complexe.

Kommentare

« Plus