Il n'y a plus d'informaticien.

Hervé Rincent

Hervé Rincent

11 nov. 2020

MemoBank est une start-up française qui propose aux TPE/PME un service de banque en ligne.

Dans une interview récente, Jean-Daniel Guyot (l’un des cofondateurs) explique avoir choisi de construire le système d’information complet de MemoBank à partir de zéro.

Pourquoi ce choix risqué et coûteux (3 ans de développement), plutôt que d’acheter une solution clé en main déjà éprouvée par les banques traditionnelles ?

Jean-Daniel Guyot évoque quelques raisons :

  1. Pour recentrer le système sur la relation client, et masquer autant que possible la complexité des exigences réglementaires bancaires,
  2. Pour faciliter la vie des conseillers. Leur vrai métier n’est pas de jongler entre plusieurs applications, ni de faire des copier/coller, ni d’expliquer à leurs clients qu’il faut prendre son mal en patience.
  3. Centraliser et fiabiliser les données pour les mettre à disposition en temps-réel.

Dans le contexte actuel “il existe toujours déjà un truc pour faire ça”, je suis admiratif face à cette ambition de construire un SI bancaire à partir d’une feuille blanche.

Car contrairement à la livraison de paniers de légumes en circuit court, ou au coaching de régime minceur, un service bancaire n’a pas droit à l’erreur.

L’exigence de qualité, de fiabilité, mais aussi de performance (on ne va pas attendre 5 minutes pour déterminer si mon paiement par carte bancaire est accepté) sont à un très haut niveau.

Dans un article publié sur le blog de MemoBank, on peut lire les principes d’architecture retenus pour les fondations d’un tel système.

Le cocktail est le pattern CQRS/ES, qui combine deux approches qui se marient à merveille :

En synthèse :

Plutôt que de mettre les données au centre de l’application, on y place les événements qui servent à modifier des données.

Ainsi, la valeur d’une donnée à un instant T est déduite de l’historique de tous les événements jusqu’à l’instant T.

Il est simple de créer une nouvelle donnée à partir d’un même historique d’évènements. Il suffit de décrire la fonction à appliquer à cette donnée en réaction à chaque type d’évènement, puis de “rejouer le film”.

Les requêtes qui ont besoin de lire les données sont indépendantes des événements qui les modifient.

event-sourcing

Illustrons cela par un exemple :

Trois profils, trois besoins différents de données. Mais un historique commun d’événements.

Pourquoi ce choix d’architecture pour une banque ?

Soyons honnête, il y avait quand même plus simple.

On pouvait faire comme d’habitude, avec une grosse base de données relationnelle au centre de l’application, dans laquelle on stocke les comptes bancaires et la liste des opérations. Et tout le monde va lire et écrire dedans.

Et bien non.

Pas cette fois.

Car une architecture CQRS/ES convient peut-être mieux à un système d’information bancaire d’une start-up :

En contrepartie, il faut s’habituer à la désynchronisation entre les événements et les données. Et là ça peut faire mal.

Par exemple, lorsqu’on reçoit un événement “effectuer un retrait de 50€ au distributeur”, il faut connaître le solde du compte bancaire pour répondre positivement ou non. Le problème est que cette valeur n’est peut-être pas encore tout à fait à jour, car il y a un achat sur Internet qui a donné lieu à une transaction juste avant.

Pour une application bancaire, les cas de ce type à traiter peuvent être peu nombreux. Mais ça pourrait devenir un casse-tête pour un autre contexte métier.

C’est le métier qui conditionne l’architecture.

La façon dont on organise son système informatique n’est pas seulement l’affaire d’un prestataire externe. Il n’est pas déterminé par le dernier framework à la mode, ni par les habitudes des développeurs avec lesquels on travaille.

Il ne s’agit pas de choisir un langage de programmation, un type de base de données, ni un outil SaaS réputé.

L’enjeu est de définir ce qui colle à son métier et qui fera la différence.

Aujourd’hui, j’observe beaucoup d’entrepreneurs qui ont l’ambition de ré-inventer des activités traditionnelles en perfusant la tech au coeur du métier, et non pas autour.

Des entrepreneurs qui ont compris que le pur métier d’informaticien n’existe pas vraiment. Mais qu’il y a des banquiers qui codent. Des commerçants qui codent. Des fabricants de voitures qui codent.


Continuer la lecture

Pourquoi faire un site pour Google ?

17 nov. 2020

3 min read

Pourquoi faire un site pour Google ?

Lire l'article
L'IA est-elle créative ?

3 nov. 2020

3 min read

L'IA est-elle créative ?

Lire l'article
Inscription à la newsletter

Recevez chaque semaine un article pour réfléchir à votre prochain projet tech/data

gratuit, sans spam, désinscription en 1 clic

Merci ! Regardez dans botre boite mail. Un lien de confirmation n'attend plus que votre clic.
Arghh il semble compliqué de vous ajouter à la liste de diffusion. Et si vous m'envoyiez un mail directement à contact@camilab.co ?