Sortir du core banking historique : big bang, migration progressive ou évidement du cœur

Une banque tourne depuis une vingtaine d’années sur le même système central. Il tient les comptes, calcule les intérêts et les commissions, produit les écritures comptables, alimente le reporting réglementaire et passe chaque nuit les traitements qui font démarrer la journée suivante. Autour de lui, des dizaines d’applications sont venues se greffer : canaux, crédit, monétique, risques, conformité. Beaucoup lisent directement sa base de données. Les équipes qui le connaissent en détail sont de moins en moins nombreuses, et chaque évolution réglementaire y coûte plus cher que la précédente.

La décision de le remplacer finit par être prise. Le programme s’organise alors autour d’une question : quel progiciel choisir ? Les consultations sont lancées, les éditeurs font leurs démonstrations, les grilles de comparaison se remplissent. La question de la manière de passer de l’ancien système au nouveau est renvoyée à plus tard, à une phase de « migration » que l’on imagine technique.

Le choix de la stratégie de sortie engage davantage que le choix du progiciel cible. C’est elle qui décide combien de temps la banque vivra avec deux systèmes, ce qu’elle s’interdira de faire évoluer pendant ce temps, et à quel moment se concentrera le risque. Deux banques qui choisissent le même progiciel peuvent vivre des programmes sans rapport selon la façon dont elles en sortent.

Ce que le cœur fait réellement

Avant de choisir une stratégie, il faut savoir de quoi l’on sort. Un système central bancaire n’est pas une fonction, c’est un empilement de fonctions qui ont fini par partager la même base et le même calendrier.

La tenue des comptes. Les soldes, les mouvements, les dates de valeur. C’est la fonction que tout le monde associe au cœur, et c’est celle qui porte la responsabilité la plus lourde : un solde faux est un incident visible par le client.

Le référentiel des tiers. Les clients, leurs liens, leurs données d’identification et de connaissance client. Il est souvent consulté par toutes les autres applications, et rarement par une interface prévue pour cela.

Le catalogue des produits et la tarification. Les conditions de chaque produit, les grilles, les dérogations négociées client par client. Une partie de ces règles n’existe que dans le paramétrage ou dans le code.

Les calculs. Intérêts, agios, commissions, frais, avec leurs conventions de calcul et leurs cas particuliers accumulés au fil des années.

Les traitements de fin de journée. Arrêtés, échéances, prélèvements, mises à jour en masse. Ils fixent le rythme de toute la banque, et beaucoup d’applications périphériques sont réglées sur eux.

La génération des écritures comptables et l’alimentation du reporting. Chaque opération produit des écritures selon un schéma comptable que le système applique ; le reporting réglementaire, les risques et le contrôle de gestion se nourrissent de ses extractions.

Cette décomposition n’est pas un exercice théorique. Elle détermine ce que l’on peut séparer. Une banque dont les applications périphériques lisent toutes la base du cœur n’a pas les mêmes options qu’une banque où ces accès passent par des interfaces identifiées. C’est la même lecture que celle de la carte des capacités métier, appliquée à un seul système : on ne sait pas remplacer ce qu’on n’a pas découpé.

Trois façons d’en sortir

Les programmes de remplacement varient beaucoup dans le détail, mais ils relèvent presque tous de trois stratégies, ou d’une combinaison de celles-ci.

Tout basculer d’un coup

Le nouveau système est construit et paramétré en parallèle de l’ancien. Lorsqu’il est prêt, l’ensemble des clients, des comptes, des produits et des encours est migré en une seule opération, le plus souvent sur un week-end ou une période de faible activité. Le lundi, la banque fonctionne sur le nouveau système.

L’avantage est réel : il n’y a jamais deux systèmes de référence en même temps. Pas de client dont une partie des comptes est d’un côté et une partie de l’autre, pas de synchronisation à maintenir, une seule réconciliation à réussir.

Les exigences le sont aussi. Le gel des évolutions d’abord : pendant toute la construction, chaque changement apporté à l’ancien système doit être reporté dans le nouveau, ou refusé. Or la réglementation, elle, n’attend pas, et les directions métier non plus. Plus la construction dure, plus la cible bouge. Les répétitions ensuite : une bascule unique ne se réussit qu’après plusieurs migrations à blanc, complètes, chronométrées, réconciliées. Le retour arrière enfin : il est prévu dans tous les plans, mais il n’est réaliste que pendant quelques heures. Dès que des opérations ont été passées sur le nouveau système, revenir à l’ancien suppose de les y rejouer, ce que peu de banques savent faire.

Le risque est concentré sur une date. C’est à la fois la force et la faiblesse de cette stratégie.

Migrer par lots

La bascule est découpée. Par produit : l’épargne d’abord, puis les crédits, puis les comptes courants. Par population : les nouveaux clients sur le nouveau système, le stock ensuite. Par entité ou par pays, pour un groupe. Chaque lot est une bascule de taille réduite, qui permet d’apprendre avant la suivante.

Le risque est réparti, mais la coexistence a un coût que les plans sous-estiment presque toujours. Pendant toute la durée du programme, la banque a deux systèmes de référence. Un client peut avoir son compte courant dans l’un et son crédit dans l’autre. Il faut alors lui produire une vue consolidée, un relevé cohérent, des plafonds et des limites calculés sur l’ensemble de ses engagements, une connaissance client unique. Les traitements de fin de journée tournent deux fois et doivent s’enchaîner. La comptabilité reçoit des écritures de deux sources.

Le découpage « nouveaux clients d’abord » mérite une mise en garde particulière. Il paraît le plus simple, parce qu’il n’oblige pas à migrer de données au départ. Mais il ne fait jamais décroître l’ancien système : le stock reste entier, et c’est lui qui contient les produits les plus anciens, les cas les plus particuliers, les contrats les plus difficiles à reprendre. Le dernier lot est toujours le plus dur, et c’est celui qu’on est tenté de reporter.

Vider le cœur avant de le remplacer

La troisième stratégie ne commence pas par le cœur. Elle commence par ce qui l’entoure. On place d’abord une couche d’interfaces entre le cœur et ses consommateurs, pour que les canaux et les applications périphériques cessent d’en lire la base. Puis on en sort, une à une, les fonctions qui peuvent vivre ailleurs : le référentiel des tiers, le catalogue des produits et la tarification, les canaux, les paiements. Le cœur se réduit progressivement à ce qu’il est le seul à savoir faire — la tenue des comptes, les calculs, la comptabilité. Son remplacement, en dernier, porte alors sur un système plus petit et mieux isolé.

Cette stratégie demande un investissement initial dans la couche d’interfaces, qui ne produit aucun bénéfice visible pour les métiers pendant un temps. Elle pose aussi, à chaque fonction sortie, la question de la référence : pendant la transition, qui fait foi pour l’adresse d’un client, le référentiel nouveau ou le cœur qui continue d’en avoir besoin pour ses traitements ? Elle crée enfin un risque particulier : un cœur réduit, bien isolé, qui continue de fonctionner, peut sembler suffisant. Le remplacement final est alors reporté sans fin.

Ce qui décide vraiment entre les trois

Aucune de ces stratégies n’est la bonne en général. Le choix dépend de quelques caractéristiques de la banque, que l’on peut examiner avant de consulter le moindre éditeur.

La séparabilité du cœur. Si les applications périphériques accèdent directement à la base du système central, ni la migration par lots ni l’évidement ne sont possibles en l’état : il faut d’abord couper ces dépendances. Ce travail est souvent la première vraie phase du programme, quelle que soit la stratégie retenue ensuite. Il relève de ce que l’article sur le contrat d’interface décrit : tant qu’une interface n’a ni propriétaire ni définition, on ne peut pas changer ce qu’il y a derrière.

La capacité à geler. Une bascule unique suppose que la banque accepte de ne presque plus faire évoluer son système central pendant la construction. Il faut regarder le calendrier réglementaire et les ambitions commerciales des années concernées. Si ce gel n’est pas tenable, la stratégie de bascule unique se transforme en double développement permanent, ce qui est la pire des combinaisons.

La répartition du risque acceptable. Certaines organisations préfèrent un risque élevé sur une date connue, préparé et répété, à un risque plus faible mais réparti sur plusieurs années. D’autres non. Les autorités de supervision s’intéressent aussi à cette question : selon les juridictions, un changement de système central peut devoir leur être présenté, avec le plan de bascule et les dispositifs de continuité. Le contexte réglementaire et opérationnel pèse ici directement sur l’architecture du programme.

La qualité des données. Une bascule unique exige que toutes les données soient reprises en même temps et réconciliées au centime. Une migration par lots permet d’apprendre sur un premier périmètre et de corriger avant le suivant. Une banque dont le référentiel des tiers comporte de nombreux doublons ou des données incomplètes n’a pas intérêt à le découvrir le week-end de la bascule.

La disponibilité des compétences. Plus la coexistence dure, plus longtemps il faut garder les personnes qui connaissent l’ancien système et former celles qui maîtrisent le nouveau. Dans un marché où ces compétences sont rares, la durée du programme est aussi une contrainte de ressources humaines.

Le degré de standardisation visé. Remplacer un cœur très spécifique par un progiciel suppose de renoncer à une partie des particularités accumulées, ou de les reproduire à grands frais. L’arbitrage entre standard et spécifique se pose ici fonction par fonction, et il influence la stratégie : il est plus facile d’adopter les règles standard d’un produit sur un lot de nouveaux clients que sur un stock de contrats anciens.

Si l’on évide : dans quel ordre

L’évidement est souvent la stratégie la plus adaptée aux banques dont le cœur est fortement couplé à son environnement, parce qu’elle commence par réduire ce couplage. Elle demande en revanche un ordre de sortie réfléchi.

Un principe simple guide en général cet ordre : sortir d’abord ce qui est lu par beaucoup et modifié par peu, et en dernier ce qui porte des soldes.

Les canaux et l’accès au cœur viennent en premier. Tant que la banque en ligne, les agences et les partenaires appellent le système central directement, chaque fonction sortie oblige à les modifier. Une fois qu’ils passent par une couche d’interfaces, ce qu’il y a derrière peut changer sans qu’ils le voient.

Le référentiel des tiers et le catalogue des produits suivent. Ils sont consultés par presque toutes les applications et modifiés par un nombre limité de processus. Les sortir permet de les rendre cohérents pour toute la banque, et prépare la migration des comptes : un client déjà présent dans le nouveau référentiel est plus facile à faire basculer.

Les paiements et les traitements périphériques peuvent ensuite être déplacés, à condition de savoir comment ils s’articulent avec les traitements de fin de journée.

La tenue des comptes, les calculs et la comptabilité sortent en dernier, ensemble. Ils sont trop liés pour être séparés sans risque : un solde, l’intérêt qu’il produit et l’écriture qui le constate doivent rester cohérents à tout instant. C’est cette dernière étape qui ressemble le plus à une bascule unique, mais sur un périmètre beaucoup plus réduit qu’au départ.

À chaque étape, la question de la référence doit être tranchée explicitement. Lorsqu’un référentiel des tiers est sorti, le cœur continue souvent d’en garder une copie pour ses propres traitements. Il faut décider laquelle fait foi, dans quel sens circulent les mises à jour, et ce qui se passe quand elles divergent. Une transition où les deux font foi selon les cas est la source la plus fréquente d’incidents difficiles à expliquer.

La réconciliation, quelle que soit la stratégie

Les trois stratégies ont un point commun que les plans traitent souvent trop tard : il faudra démontrer, à chaque bascule, que le nouveau système dit la même chose que l’ancien. Pas approximativement, mais au niveau de chaque compte.

Cette démonstration porte sur plusieurs objets : les soldes, les encours, les intérêts courus non échus, les échéanciers des crédits, les positions comptables. Elle suppose de faire tourner les deux systèmes sur les mêmes opérations pendant une période, et de comparer. Elle suppose surtout de définir à l’avance ce qu’est un écart acceptable. Deux systèmes qui n’appliquent pas exactement la même convention de calcul des jours, ou qui n’arrondissent pas au même moment, produiront des différences légitimes. Si l’on ne les a pas qualifiées avant, chacune deviendra une alerte à analyser pendant la période la plus tendue du programme.

La comptabilité est le point où tout se rejoint. Pendant la coexistence, les écritures viennent de deux systèmes, avec deux schémas comptables qui doivent produire les mêmes comptes. Le reporting réglementaire, qui s’appuie sur des chaînes d’alimentation construites autour de l’ancien cœur, doit être alimenté par les deux sans rupture. Un programme qui ne traite pas ces chaînes dès sa conception découvre tardivement que c’est la comptabilité, plus que le système central, qui fixe le rythme de la bascule.

Le piège commun : la sortie qui ne finit pas

Chaque stratégie a sa manière de s’arrêter en route.

La bascule unique est reportée, une fois, puis deux. Pendant ce temps, l’ancien système continue d’évoluer, parce que le gel n’a pas tenu, et l’écart à reprendre grandit. La migration par lots migre les produits simples et laisse le dernier lot sur l’ancien système, sans échéance. L’évidement sort les fonctions périphériques, et le cœur réduit, désormais stable et bien isolé, ne trouve plus de sponsor pour son remplacement.

Dans les trois cas, la banque se retrouve dans un état intermédiaire qui n’avait pas été conçu pour durer. C’est la situation décrite dans l’article sur la trajectoire d’architecture : la transformation s’arrête toujours quelque part, et il vaut mieux que ce soit dans un état vivable. Pour un système central, cela veut dire que chaque étape doit pouvoir être exploitée durablement si la suivante n’arrive pas : une coexistence outillée, une réconciliation automatisée, une référence clairement attribuée pour chaque donnée.

Deux disciplines limitent ce risque. La première est d’écrire, au moment de choisir la stratégie, les conditions de retrait de l’ancien système : à quel moment il cesse d’être modifié, quand il passe en lecture seule, ce qui doit être vrai pour l’éteindre. La seconde est de consigner les hypothèses sur lesquelles repose le choix de stratégie — la tenue du gel, la disponibilité des compétences, la qualité des données — dans un registre de décisions, pour savoir à quel moment il faut le reconsidérer. Une stratégie choisie parce que le gel paraissait tenable doit être réexaminée le jour où il cède, pas deux ans plus tard.

Reste la question du financement. Un programme de sortie se joue sur plusieurs exercices budgétaires, et chaque arbitrage annuel peut le défaire sans le dire, en finançant une évolution de l’ancien système plutôt qu’une étape de la sortie. C’est ce que montre l’article sur le portefeuille de projets : la trajectoire réelle se lit dans ce qui est financé.

La question à poser avant de choisir un progiciel

Le choix d’un nouveau système central reste une décision importante. Mais il se fait mieux lorsqu’on sait déjà comment on compte en sortir, parce que la stratégie de sortie change ce qu’on attend du progiciel : sa capacité à coexister avec l’ancien, à reprendre des données par lots, à exposer ses fonctions par interfaces, à accepter qu’on lui confie le référentiel des tiers ou au contraire qu’on le garde ailleurs.

Avant de lancer la consultation, une banque gagne à pouvoir répondre à quelques questions simples. Quelles applications lisent aujourd’hui directement la base du système central ? Combien de temps peut-elle accepter de ne plus le faire évoluer ? Quelle donnée fera foi pour chaque client pendant la transition ? Et si le programme s’arrêtait à mi-chemin, dans quel état se trouverait-elle ? La réponse à cette dernière question dit, plus que toutes les grilles de comparaison, quelle stratégie elle peut réellement se permettre.