Architecture bancaire moderne : scalabilité et conformité

Beaucoup d'établissements font encore tourner leur cœur métier sur des systèmes centraux hérités, souvent en COBOL, couplés à une base de données unique. Ces plateformes ont l'immense mérite d'être fiables et éprouvées depuis des décennies. Le problème n'est pas leur exactitude comptable, mais leur rigidité : chaque évolution touche l'ensemble, chaque déploiement mobilise des fenêtres de maintenance nocturnes et chaque montée en charge suppose de dimensionner tout le bloc.

Dans un contexte où les paiements instantanés, l'open banking et les parcours mobiles génèrent des pics de trafic imprévisibles, cette architecture en un seul tenant devient un frein économique. On paie de la capacité pour le pire scénario en permanence, et l'on ralentit les équipes produit qui doivent se coordonner sur une base de code commune.

La réponse n'est pas de tout réécrire d'un bloc, ce qui serait à la fois risqué et long, mais de décomposer progressivement les capacités métier en services autonomes, en commençant par les périphéries à forte valeur : onboarding, agrégation de comptes, moteurs de scoring, notifications.

Le piège le plus courant consiste à découper un système en services techniques (une couche API, une couche métier, une couche données) au lieu de le découper par domaine métier. Cette approche recrée un monolithe distribué, plus complexe à opérer et sans les bénéfices d'autonomie recherchés.

Le Domain-Driven Design offre une grille de lecture utile. On identifie des contextes délimités qui correspondent à des responsabilités métier claires : gestion des comptes, exécution des paiements, lutte contre la fraude, connaissance client. Chaque contexte possède ses données, son cycle de vie de déploiement et son équipe. Les frontières suivent le langage du métier, pas l'organigramme technique.

Cette autonomie a un coût qu'il faut assumer consciemment. Plus il y a de services, plus il y a d'appels réseau, de latence à maîtriser et de cohérence à orchestrer. La règle de bon sens : un service doit être assez gros pour porter une capacité métier cohérente, assez petit pour être compris et redéployé par une seule équipe.

• Un contexte délimité égale une équipe propriétaire, une base de données privée, un pipeline de déploiement indépendant
• Communication synchrone réservée aux cas où la réponse immédiate est indispensable
• Contrats d'API versionnés et rétrocompatibles pour éviter les ruptures en cascade

En banque, la plupart des interactions ne nécessitent pas une réponse synchrone immédiate. Un virement déclenche une mise à jour de solde, une notification, une écriture comptable, un contrôle anti-blanchiment. Chercher à enchaîner tout cela dans un appel bloquant fragilise le système : si un maillon tombe, toute la chaîne échoue.

L'architecture pilotée par les événements inverse la logique. Le service qui exécute le virement publie un événement immuable, et chaque consommateur y réagit à son rythme. On gagne en découplage, en résilience et en capacité d'absorption des pics, car un bus de messages comme Kafka amortit les rafales de trafic.

Un principe structurant accompagne cette approche : l'event sourcing. Plutôt que de stocker uniquement l'état courant d'un compte, on conserve la séquence complète des événements qui l'ont produit. On obtient une piste d'audit native, immuable et rejouable, ce qui répond directement aux exigences de traçabilité du secteur.

• Événements immuables comme source de vérité, état reconstructible par rejeu
• Idempotence obligatoire côté consommateur pour tolérer les redistributions de messages
• Schémas d'événements gouvernés dans un registre pour préserver la compatibilité

Passer au cloud ne consiste pas à déplacer des machines virtuelles chez un hébergeur. La démarche cloud-native suppose des services conteneurisés, orchestrés par Kubernetes, dimensionnés automatiquement selon la charge et conçus pour tolérer la disparition d'une instance à tout moment. L'infrastructure devient du code, versionnée et reproductible.

La contrepartie de la décomposition en services est la perte des transactions ACID globales. On ne peut plus s'appuyer sur une transaction unique traversant tout le système. Les patterns comme le saga orchestré prennent le relais : une suite d'étapes locales, chacune avec sa transaction de compensation en cas d'échec, garantit une cohérence à terme sans verrou distribué.

Cette cohérence à terme demande de la pédagogie auprès des équipes métier. Un solde peut être momentanément en cours de synchronisation. Le rôle de l'architecte est de délimiter précisément où la cohérence forte reste non négociable, typiquement l'autorisation d'un débit, et où la cohérence à terme est acceptable.

Le règlement DORA, applicable dans l'Union européenne depuis janvier 2025, a fait de la résilience un objet de conformité à part entière. Il ne suffit plus d'avoir des sauvegardes : l'établissement doit démontrer sa capacité à résister, à réagir et à se rétablir face aux incidents liés aux technologies de l'information et de la communication.

Concrètement, DORA impose une gestion structurée des risques informatiques, un signalement rapide des incidents majeurs, des tests de résilience réguliers et une supervision étroite des prestataires tiers critiques, à commencer par les fournisseurs cloud. L'architecture doit rendre ces obligations vérifiables, pas seulement documentées.

Attention à ne pas confondre les acronymes. Les métriques DORA de la performance d'ingénierie (fréquence de déploiement, délai de livraison, taux d'échec des changements, temps de rétablissement) sont un autre sujet, orienté vitesse et qualité de livraison. Les deux se complètent : une bonne performance de livraison sert directement la résilience exigée par la réglementation.

• Tests de résilience et exercices de bascule planifiés, tracés et rejouables
• Cartographie des dépendances aux prestataires tiers et stratégies de sortie
• Objectifs mesurés de délai et de point de reprise pour chaque service critique

Dans un système distribué, la sécurité ne peut plus reposer sur un périmètre unique. Le modèle Zero Trust part du principe qu'aucun appel n'est fiable par défaut, y compris à l'intérieur du réseau. Chaque service authentifie l'appelant, chaque échange est chiffré, chaque autorisation est vérifiée au plus près de la donnée.

Les exigences réglementaires du secteur, du RGPD aux règles de connaissance client et de lutte anti-blanchiment, doivent être traduites en contraintes techniques dès la conception. Chiffrement au repos et en transit, cloisonnement des données sensibles, journalisation inviolable et gestion fine des habilitations ne sont pas des options ajoutées après coup.

La conformité gagne à être automatisée. Intégrer les contrôles de sécurité et de qualité dans les pipelines de livraison, sous forme de tests et de politiques exécutables, transforme la conformité d'un audit ponctuel en une propriété continue du système. C'est aussi ce qui permet de conserver un rythme de livraison élevé sans dégrader le niveau d'exigence.

La modernisation réussie est rarement une réécriture totale. Le pattern du strangler fig consiste à envelopper progressivement le système hérité, à en extraire les capacités une à une vers de nouveaux services, jusqu'à ce que l'ancien cœur puisse être retiré sans rupture. Le risque est ainsi étalé et chaque étape produit de la valeur.

Cette trajectoire suppose une observabilité forte dès le premier jour. Traces distribuées, métriques et journaux corrélés permettent de comprendre le comportement d'un système éclaté en dizaines de services. Sans cette visibilité, l'exploitation devient une devinette et la résilience un vœu pieux.

Enfin, la technologie ne suffit pas. L'organisation en équipes autonomes alignées sur les domaines, la culture de la fiabilité et l'appropriation de la production par les développeurs conditionnent le succès autant que le choix des outils. L'architecture cible et l'organisation cible se dessinent ensemble.