Pourquoi je préfère le scraping aux API

Il y a maintenant plus d’un an, lorsqu’on me demandait si je ne craignais pas la quantité de travail qui serait nécessaire pour réécrire les connecteurs scraping pour utiliser les API PSD2, je répondais naïvement qu’avec l’expertise que nous avions acquise à interagir avec des interfaces instables, ce serait un jeu d’enfant de passer à des interfaces stables, qui plus est, documentées et standardisées.

La réalité, évidemment, me rattrape aujourd’hui, puisqu’il s’agit d’un investissement important en temps pour Budget Insight, et cela dépasse la technique.

Le scraping, c’est l’analyse technique du comportement d’une application fonctionnelle, pour le reproduire, l’automatiser et l’étendre dans la limite du possible. Lorsque je le fais, je suis seul face à ma machine et tant que l’application fonctionne pour l’utilisateur, rien ne m’empêchera d’atteindre mon objectif. Évidemment, il y a des tas d’obstacles techniques, à commencer par les protections mises en œuvres pour lutter contre le scraping (captcha, obfuscation, blocages, etc.), mais aussi la compréhension de la cryptographie utilisée lorsqu’il y en a, le décryptage (au sens propre) de protocoles mal conçus, l’analyse de code sources, etc.

Passer par une API publique fait sauter tous ces aspects, puisque par définition j’ai accès à la documentation. Néanmoins, celle-ci n’est pas nécessairement exhaustive, encore moins à jour ou exacte, et je n’ai pas à ma disposition du code source l’utilisant en production, ce qui fait qu’au moindre problème, je suis seul… face au support.

Et c’est là que les ennuis commencent, parce que l’expérience me montre que constituer un support API est loin d’être évident. Il faut des personnes connaissant suffisamment la technique, mais qui ne sont pas rebutées à l’idée de traiter des tickets, de répondre à des questions triviales, de passer des heures à analyser les requêtes pour se rendre compte que le problème était entre la chaise et le clavier.

Tous les développeurs de Budget Insight qui travaillent sur les API PSD2 sont frustrés par le temps qu’ils passent à échanger avec le support des banques, qui peut être plus ou moins réactif, qui peut être plus ou moins pertinent, mais en tout cas qui rajoute un délai lors duquel ils ne peuvent pas avancer et doivent passer à autre chose. De fait, ils ont chacun en charge un certain nombre d’API à intégrer, et dès qu’ils se retrouvent bloqués, créent ou mettent à jour un ticket au support, passent à l’API suivante, et ainsi de suite.

Un autre aspect important est que, contrairement à l’accès direct, les API PSD2 sont récentes et aucune n’est largement utilisée (le fameux widely used mal compris des régulateurs). À moins d’un bug affectant les utilisateurs, lorsque je scrape je suis certain que l’interface est fonctionnelle, aussi mon connecteur le sera également. Ce n’est pas le cas des API, et beaucoup d’énergie est dépensée car nous faisons la recette des API bancaires.

Pour terminer, la fameuse standardisation, comme prévu, n’est pas là. Les trois frameworks que constituent STET, BerlinGroup et OpenBanking.Uk sont des bases plus ou moins respectées, étendues. Même si nous avons fait des abstractions, il n’y a pas aujourd’hui un seul connecteur vers une API implémentant l’un des trois formats qui n’ait pas du code spécifique. Le côté « Un connecteur STET pour toutes les banques françaises » n’est pas là, et quitte à devoir faire des tests et du développement pour chaque ASPSP que l’on connecte, j’aurais préféré qu’ils exposent tous un format proche de leur modèle de données, car il aurait reflété leurs réalités métiers, au même titre que le fait leur site, plutôt que de le distordre pour le faire rentrer tant bien que mal dans un standard, perdant au passage données et fonctionnalités…