Monzo, un modèle de résilience

Alors que j'évoquais récemment les avancées des communications photoniques au service de la résilience des institutions financières, je vous propose aujourd'hui de plonger dans les arcanes – techniques, mais que je vais m'attacher à vulgariser – de l'approche de Monzo en la matière, qui représente, à mon avis, une référence pour l'industrie.

D'emblée, il faut comprendre que la néo-banque dispose d'une première ligne de défense relativement classique contre les défaillances de son infrastructure. L'ensemble de son système d'information est en effet déployé sur l'infonuagique d'Amazon (AWS), avec un principe de redondances multiples, réparties sur différentes « régions » (c'est-à-dire des centres de production distincts), opérant simultanément de matière totalement synchrone, grâce aux mécanismes intrinsèques proposés par l'hébergeur.

Mais les ingénieurs qui l'ont conçu sont conscients que ce modèle reste exposé à deux risques, l'un, minime, que constituerait une défaillance majeure de son fournisseur, affectant plusieurs de ses sites, et l'autre, beaucoup plus probable… et plus fréquent, d'un défaut logiciel entraînant une indisponibilité inacceptable pour les clients. Un second socle informatique, indépendant du principal et couvrant exclusivement les fonctions critiques, se tient donc prêt à pendre le relais rapidement en cas de besoin.

La notion d'indépendance dont il est question ne fait pas dans la demi-mesure : non seulement les applications sont-elles installées dans un environnement entièrement séparé de l'« original », émanant d'un autre prestataire (Google, en l'occurrence), mais elles sont en outre re-développées séparément, bien qu'elles remplissent le même rôle que celles qui assurent le service en temps normal, un peu à la manière dont sont doublées les capacités électroniques les plus sensibles des avions modernes.

Les modalités de synchronisation des deux plates-formes sont évidemment élaborées avec le plus grand soin, afin de garantir un fonctionnement transparent en cas de bascule. Le secours, « Monzo Stand-in », est ainsi abonné à une sélection des événements que génère le site primaire pour tous les changements d'état et autres actions enregistrées (l'architecture interne est 100% événementielle), correspondant aux 18 services qu'il prend en charge (consultation de solde et des transactions, virements entrants et sortants, paiement par carte…) parmi les 3 000 existants.

Quand un problème survient, dont un cas en août 2024, les serveurs de remplacement sont activés, manuellement, à ce stade. L'application mobile de la jeune pousse détecte le changement et ajuste alors automatiquement son interface graphique pour ne présenter que les opérations qui restent effectivement disponibles (avec un message d'explication). Notons que le système autorise également des transferts partiels d'activité, par fonction, par client…, selon la nature de l'interruption identifiée.

Le principe de « Monzo Stand-in » paraît simple mais le diable se cache dans les détails. La jeune pousse décrit notamment les compromis qu'elle doit accepter avec les limitations des transmissions d'information (et l'incertitude quant à leur exhaustivité), sa philosophie de maintien d'une version initiale des données copiées, jamais modifiée, les contorsions auxquelles elle se livre avec, par exemple, les numéros de carte tokenisés (via des clés distinctes pour ses deux plates-formes de production)…

Dans le contexte de réglementations de plus en plus contraignantes sur la résilience (DORA dans l'Union Européenne) et de l'inquiétude suscitée par les défaillances répétées des établissements britanniques, Monzo démontre son indiscutable avance technologique… dont il faut souligner, incidemment, qu'elle est maîtrisée en termes de budget : son environnement répliqué représente environ 1% du coût de fonctionnement du socle primaire (en revanche, elle ne chiffre pas sa mise en place initiale).