L'originalité n'est d'ailleurs pas une surprise puisqu'il s'agit d'un exercice que Gartner appelle "Maverick Research", dont je suis un inconditionnel et qui se caractérise justement par une volonté de s'écarter des sentiers battus et d'apporter un éclairage non conventionnel et disruptif, pas nécessairement partagé par tous les analystes de la firme, sur un sujet donné. Dans le cas présent, le titre annonce la couleur : "les banques devraient miser sur des apps et des APIs, pas sur des applications".
Si le message ne semble pas clair, peut-être faut-il préciser que la notion d'application dont il est question est celle qui prévaut depuis des décennies dans les institutions financières, basée sur un modèle monolithique, alors que le concept d'app, en référence aux logiciels que nous utilisons tous sur nos smartphones, suggère une extrême focalisation sur les besoins (individuels) des clients. Quant aux APIs ("Application Programming Interfaces"), ce sont des fonctions mises à disposition des développeurs, pour leur permettre de créer de nouvelles solutions à partir de services existants.
Une fois ces définitions posées, le raisonnement présenté par Gartner devient plus compréhensible. Les applications historiques des banques n'offrent pas la réactivité indispensable dans le monde d'aujourd'hui, qui évolue toujours plus vite. En créer de nouvelles, en appliquant les mêmes principes archaïques, ne fait qu'ajouter à la complexité du SI et renforce l'inertie de l'entreprise. Le salut ne peut donc venir que d'un changement de paradigme.
Le modèle alternatif que proposent les analystes de Gartner est un monde d'APIs, celles-ci pouvant être construites à partir des applications existantes dans la mesure où elles auront été préalablement rationalisées. Grâce à cette approche, la banque, devenue agile, pourra construire les "apps" dont ses clients ont réellement besoin et qui savent s'adapter au contexte de l'utilisateur (sa localisation, son équipement, les conditions "environnementales" telles que, par exemple, l'évolution des taux d'intérêt...).
Les institutions financières deviendraient ainsi capables de répondre aux opportunités dès qu'elles émergent, voire même de les anticiper, au lieu d'opérer dans le mode réactif (parfois proche de la panique) qu'ont leur connaît aujourd'hui. L'ouverture sur l'extérieur leur permettrait, de surcroît, de capitaliser sur des compétences diverses et variées de développeurs venus de tous horizons, pour construire les solutions que demandent et qu'attendent leurs clients.
Les obstacles sur la route de cet avenir radieux ne sont pas obligatoirement là où on les imagine. Les difficultés techniques (autour de la sécurité, des performances, de l'intégration, de la conformité réglementaire...) ne peuvent être négligées mais sont surmontables. Plus sérieuses sont les absences de gouvernance formelle et de paradigmes de conception clairs et partagés, adaptés à cette approche. Mais la barrière principale est la peur qu'engendre la perte de contrôle sous-jacente au modèle proposé.
Les analystes de Gartner ne précisent pas leur pensée sur ce sujet mais elle est facile à imaginer, puisque cette perte de contrôle touche tous les nerfs de la banque : depuis les équipes internes qui préfèrent (encore trop souvent) re-développer des composants plutôt que d'utiliser ceux de leurs collègues jusqu'à, comble de l'horreur (!), l'idée d'ouvrir le SI à des tiers...
Alors, ces réflexions n'aboutissent-elles qu'à une utopie ?
Sans être une démonstration exhaustive du contraire, l'expérience du CA Store (du Crédit Agricole) esquisse une réponse optimiste. Oui, il est possible d'ouvrir le SI et de publier des APIs accessibles à tous les développeurs (sous conditions). Oui, cela stimule une certaine créativité (même si on aimerait la voir exploser), visant à mieux répondre aux attentes des clients.
Il ne s'agit certes pas, dans ce cas, d'une stratégie d'évolution du SI dans son ensemble mais la démonstration est faite de la possibilité de faire sauter quelques verrous tenaces dans les banques...