Le cas d’Orange Bank

28 millions d’euros, c’est le coût, entre autres choses, du retard à l’allumage de la banque en ligne. Officiellement, ce retard s’explique par la découverte de nombreux bugs dans le système d’informations. L’ambition de ce nouvel acteur bancaire est de proposer toute une gamme de services, temps réels, de manière à contraster avec les délais habituellement observés dans ce secteur par les acteurs historiques. Le temps réel, dans le cas ou cela pourrait réellement exister, implique à première vue de disposer d’un grand nombre d’APIs, en totale interaction les unes avec les autres… et donc, d’une micro-services, dans un souci de scalabilité. On dispose d’énormément de documentations concernant l’implémentation d’une telle , et de nombreuses références : Netflix entre autres… s’il est possible d’apprendre de ces succès, je pense que les échecs sont tout autant, si ce n’est plus, formateurs.

En investiguant sur les difficultés de lancement du système, je suis tombé dans la presse en ligne sur cet article :

Le cas d'Orange Bank

Et des bugs, Orange Bank ne semble pas en manquer : “Certains dysfonctionnements se sont matérialisés dans le parcours client, certains utilisateurs n’ont pas reçu de validation à l’ouverture de leur compte, d’autres se sont vu demander plusieurs fois les mêmes informations”, a indiqué un salarié de l’opérateur à notre confrère des Echos. “Le nombre de bugs régresse mais ce n’est pas parfait”, a indiqué de son côté au Monde une source syndicale. Le lancement officiel de la banque mobile d’Orange est reportée à septembre, sans plus de précision cette fois…

Concevoir un système sans bugs est impossible. Toutefois, ici, la nature des bugs remontés lors des tests révèle que cette version du système d’Orange (probablement corrigée depuis…) n’implémente aucune stratégie d’idempotence. Pour rappel, l’idempotence est la faculté d’un système à encaisser de façon répétée les mêmes commandes, sans que son état ne devienne inconsistant, ou bancal. Pourquoi un système devrait-il être idempotent ? Tout simplement parce qu’il s’agit là d’une énorme sécurité face aux nombreux dysfonctionnements que peut rencontrer une architecture distribuée. Dans le cas d’Orange, il s’agit d’un système bancaire, dans lequel la notion de transaction est aussi centrale que critique. Si vous faites un virement d’un compte vers un autre, il est impossible que votre virement soit comptabilisé plusieurs fois ! Ne pas implémenter l’idempotence lorsque l’on conçoit un système bancaire est le mal absolu !

La société Netflix est souvent citée en exemple lorsque l’on évoque la question des micro-services. Ce style d’architecture peut tout à fait fonctionner, si l’on respecte certaines règles. Dans le cas de Netflix, la refonte n’a jamais été entreprise au niveau des systèmes de paiement de l’arrière boutique, car il a été identifié dès le départ l’immense difficulté à garantir des transactions sur un tel système. Netflix fait du streaming, pas du bancaire… donc, logiquement, les analogies s’arrêtent vite (pourtant elles perdurent dans la sphère IT…).

L’interaction entre APIs que j’évoquais précédemment est logiquement supportée par des web-services. Cela rend le système particulièrement dépendant de l’infrastructure, et exposé à tout dysfonctionnement qui viendrait à apparaître… la gestion des erreurs, comme le permet l’idempotence, est donc une nécessité. Cela permet d’éviter que les clients ne soient invités à envoyer plusieurs fois les mêmes justificatifs. Pour ceux qui n’ont pas reçu le message de validation d’ouverture du compte, il semble que le système n’implémente pas, à contrario, de stratégie de reprise sur erreurs. Si un composant cesse de répondre, les informations entre le début de la panne et sa résolution sont perdues. De l’extérieur, tout semble avoir été codé comme si tout était voué à fonctionner, de l’infrastructure jusqu’au fonctionnel, alors qu’une telle architecture (couplée fonctionnellement…), est au contraire totalement exposée aux aléas du Cloud (surtout lorsqu’il est public, lorsqu’il monte à l’échelle difficilement, et lorsque des défauts d’infrastructure, difficiles à analyser, rendent les systèmes de redondances complètement fous…) : si une API cesse de répondre, ou accuse des latences, c’est tout le système qui s’effondre.

“Le lancement grand public d’Orange Bank, prévu le 6 juillet, a été reporté au dernier moment, “à la rentrée”, à cause de bugs. La banque mobile de l’opérateur, notamment son application, est actuellement testée par 2.000 salariés.”

La Tribune

Pendant ce temps, tout le monde teste, mais cela reste un bon exercice dans l’absolu, même s’il est très éphémère et très illusoire… les architectures micro-services sont difficilement testables, et un test en “off” par 2000 personnes ne suffira jamais à prédire le comportement du système lorsqu’il sera sollicité par 50000 clients.

Les architectures micro-services sont les architectures les plus difficiles à tester, à concevoir, et les plus imprévisibles en conditions réelles de production. Certaines lignes directrices, comme l’idempotence, doivent être suivies le plus rigoureusement possible. Donc, prudence avec les micro-services… car pour un succès observé, combien d’échecs ?

Add a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

− 1 = 7