Ma banque a modifié son UI et ça m’embête !

J’avais prévu de parler d’un tout autre sujet mais ma banque vient de mettre à jour son application de banque à distance et ça m’embête. Il faut dire que l’interface était vieillotte et il était grand temps de faire quelque chose. Dans la nuit de mardi à mercredi elle a déployé une nouvelle version de son application. Je n’ai pas encore eu le temps de tester toutes les fonctionnalités et je ne pourrai donc pas commenter l’ergonomie. Toutefois je trouve que le look est plus moderne et cela donne envie d’utiliser cette application.

Vous vous demandez donc pourquoi je suis mécontent si je trouve que l’interface est plus jolie ? Il se trouve que j’ai développé une application me permettant de suivre mes dépenses et ainsi mieux gérer mon budget. Pour ce faire j’utilise l’application de banque en ligne afin de télécharger un relevé de mes opérations au format CSV. Avec la mise à jour de l’application le format des données de ce fichier a été modifié. Cela casse la rétrocompatibilité et de ce fait mon application ne fonctionne plus. Si je vous parle de cela aujourd’hui c’est que je trouve que c’est un exemple de ce qu’il faut éviter quand on expose des données via une API ou tout autre méthode.

Afin que vous compreniez mieux la situation je vais vous présenter rapidement l’architecture de mon application. C’est une architecture serverless déployée sur le Cloud AWS. Après avoir téléchargé mon fichier CSV je le dépose sur un bucket S3, ceci déclenche l’exécution d’une lambda qui parse le fichier et attribue une catégorie à chaque transaction. Les transactions sont ensuite poussées individuellement dans une file d’attente SQS, chaque message déclenche à son tour l’exécution d’une deuxième lambda qui va écrire la transaction dans un fichier Google Sheets. Ceci me permet à la fin du mois d’avoir un listing complet de mes dépenses et de pouvoir vérifier le total par catégorie.

Venons-en aux modifications du format de données. Tout d’abord il y a l’extension du fichier qui avant était en majuscule et maintenant est en minuscule. Ce n’est pas le problème principal car il suffit de mettre à jour le déclencheur dans la configuration de la lambda pour régler le problème. A l’intérieur du fichier plusieurs surprises, dans la version précédente une ligne de débit contenait quatre champs délimités par un point-virgule tandis qu’une ligne de crédit contenait cinq champs délimités par un point-virgule. Je me basais sur cette différence pour pouvoir faire la différence entre les différents types de ligne. Maintenant toutes les lignes contiennent cinq champs, toujours délimités par un point-virgule. D’autre part le libellé des opérations est maintenant en majuscule alors qu’avant seule la première lettre de chaque mot était en majuscule. Je constate d’ailleurs que sur les applications web et mobile c’est également le cas, je trouve cela dommage car moins lisible. Enfin il y a une chose qui aurait pu être modifiée mais qui ne l’a pas été. Le fichier CSV est au format windows-1252 alors que j’aurais préféré qu’il soit au format UTF-8.

Au final je devrais pouvoir survivre, j’ai commencé à mettre à jour l’application et le bon découpage des classes au sein cette application me permet d’avancer rapidement. Ce qui m’intéresse le plus c’est d’imaginer comment cela aurait pu être évité. La première des choses c’est que personne n’est probablement au courant de l’utilisation que je fais de cette fonctionnalité d’export. Ensuite cet exemple montre qu’une erreur dans votre API sera parfois exploitée par vos utilisateurs comme une fonctionnalité, ici le fait que certaines lignes n’ont pas le même nombre de champs que les autres. Une fois l’erreur exposée il devient difficile de la corriger car certains clients risquent de s’en plaindre. Enfin l’exposition de données à travers un format CSV aurait pu être remplacée par une API de type REST. Cela permet par exemple mieux sécuriser les échanges en mettant en place une authentification de type Oauth2. De plus l’utilisation du versionning d’API permettrait potentiellement de casser la rétrocompatibilité sur une nouvelle version mais de continuer à exposer l’ancienne version.

En définitive cette péripétie me donne l’occasion de réfléchir à la conception des APIs et à leurs utilisations. Je pense qu’à l’avenir les clients d’un fournisseur de services en ligne augmenteront les fonctionnalités possibles en passant par des application tierces. C’est déjà le cas dans certains domaines d’activités mais je pense que cela va se généraliser à tous les domaines. Il est donc important de bien concevoir ses APIs afin de catalyser cette utilisation possible.

J’espère que cet article vous a plu !
Le code de mon application est sur GitHub : https://github.com/jbleduigou/budgetcategorizer
La PR qui m’a permis de fixer le problème : https://github.com/jbleduigou/budgetcategorizer/pull/6
N’hésitez pas à me faire part de vos commentaires ou questions en bas de cet article ou en m’envoyant un message sur LinkedIn :
http://www.linkedin.com/in/jbleduigou/en.
Photo de couverture par Christian Erfurt.
Cet article a initialement été publié sur Medium.