RBC vient de faire une entrée fracassante dans ce dernier groupe avec l'annonce de son nouveau portail dédié aux développeurs. Bien sûr, le principe est plutôt louable, dans un contexte où l'ouverture sur l'extérieur devient incontournable pour l'intégration des services financiers dans le monde « digital ». Malheureusement, son contenu révèle une démarche focalisée sur le désir pour la banque de se proclamer première sur le marché et non sur les attentes réelles des tiers potentiellement intéressés.
En effet, le portail propose aujourd'hui, en tout et pour tout, 6 fonctions, dont 3 sont consacrées à la localisation d'agence, 2 permettent des simulations de crédit hypothécaire et la dernière donne accès au catalogue de cartes de crédit. De toute évidence, elles ne seront pas suffisantes pour inspirer les applications innovantes que RBC prétend vouloir favoriser… et il est douteux qu'elles puissent même être utiles à quiconque. Pour le moins, une telle palette ne mérite certainement pas une communication officielle.
Et là n'est que le moindre de ses défauts, car, outre une documentation extrêmement limitée (qui décourage rapidement d'aller plus loin), les quelques services proposés laissent déjà transparaître de sérieux problèmes structurels. Sans entrer dans les détails, le besoin de créer une session (valable 20 minutes) avant d'interroger le service de localisation d'agence et l'existence d'une interface distincte pour déterminer si une agence donnée est équipée de coffres-forts ne rassurent pas pour la suite.
Selon toute vraisemblance, ces aberrations ne sont que le reflet de l'architecture des systèmes (historiques) sous-jacents. Or ce devrait justement être un des rôles essentiels d'une plate-forme d'API que de masquer aux développeurs cette complexité, inutile et contre-productive. A contrario, à ce stade, il semblerait donc que RBC se contente d'exposer ses fonctions internes vers l'extérieur, sans le moindre effort préalable de rationalisation et d'« urbanisation » (comme on dit dans la profession).
Si les futures API promises (dont on espère qu'elles seront plus intéressantes) adoptent une même logique, il est à craindre qu'elles soient inutilisables, en reportant sur les développeurs, dans une certaine mesure, l'exigence de comprendre le fonctionnement intrinsèque du Système d'Information de la banque pour accéder aux services qu'elle propose, ce qui est à la fois irréaliste (tant les détails d'implémentations peuvent être sordides) et peu engageant pour les amateurs éventuels d'API financières.
L'ouverture de la banque n'est résolument pas un exercice trivial et les établissements qui croient qu'il leur suffit de mettre à disposition les fonctions qu'ils utilisent en interne perdent de vue l'incroyable labyrinthe que constitue leur informatique. La difficulté n'est pas dans la publication de quelques API mais bien dans la conception de services utilisables par des développeurs. Ce qui nous ramène encore une fois à l'impératif universel : toujours placer le client (quel qu'il soit) au centre des réflexions !