Moderniser un système bancaire central : stratégies de migration
Remplacer le système central d'une banque est l'un des projets informatiques les plus risqués qui soient. Quatre stratégies de migration, ce qu'elles exigent, et comment choisir.
Le système central d’une banque tient les comptes, calcule les intérêts, passe les écritures et alimente presque tout le reste. Beaucoup tournent depuis des décennies, sur des technologies dont les compétences se raréfient. La core banking modernisation, ou modernisation du système bancaire central, est pourtant un projet que de nombreux établissements repoussent : les échecs publics de migrations bancaires rappellent ce qu’une bascule ratée coûte en clients, en amendes et en réputation. Ce guide compare les stratégies et donne une méthode pour choisir.
Avant de choisir : trois diagnostics
Aucune stratégie n’est bonne dans l’absolu. Trois éléments orientent le choix.
- La complexité du catalogue : nombre de produits, de variantes, de règles de tarification héritées. Un catalogue chargé de produits anciens rend toute migration plus lourde ; le rationaliser d’abord paie souvent.
- La qualité des données : doublons de clients, champs mal renseignés, écarts entre le système central et la comptabilité. Elle se mesure avant de lancer le projet, pas pendant.
- Le tissu d’interfaces : nombre de systèmes branchés sur le cœur (paiements, cartes, crédits, déclarations réglementaires, canaux). Chaque interface est un point de rupture potentiel.
Quatre stratégies de migration
| Stratégie | Principe | Convient quand | Risque principal |
|---|---|---|---|
| Bascule unique | Tous les comptes migrent en une fois, souvent sur un week-end | Banque de taille modeste, catalogue simple, données propres | Concentration du risque ; retour arrière difficile après réouverture |
| Migration progressive | Par produit, par segment de clientèle ou par entité, en vagues successives | Catalogue large, plusieurs entités | Coexistence longue de deux systèmes, interfaces doublées, coût de fonctionnement en parallèle |
| Banque parallèle | Une nouvelle plateforme accueille d’abord les nouveaux clients et produits, puis les anciens migrent | Volonté de lancer une offre nouvelle rapidement | Deux banques à gérer ; migration des anciens clients sans cesse repoussée |
| Évidement du cœur | Les fonctions sont extraites une à une autour du système existant, qui rétrécit jusqu’à disparaître | Système ancien stable mais rigide, besoin de réduire le risque | Durée longue ; risque de ne jamais terminer |
Dans la pratique, les banques combinent souvent ces approches : une couche d’intégration (interfaces de programmation, bus d’événements) découple d’abord les canaux du cœur, puis une migration progressive ou une bascule par entité suit.
La migration d’un système bancaire central échoue rarement sur la technologie ; elle échoue sur les données, les interfaces et les répétitions qui n’ont pas eu lieu.
La méthode, du cadrage à la bascule
- Rationaliser le catalogue. Fermer à la commercialisation les produits marginaux, regrouper les variantes. Chaque produit supprimé est une règle de moins à migrer et à tester.
- Nettoyer les données à la source. Dédoublonner les clients, compléter les champs obligatoires, rapprocher le système central de la comptabilité. Fixer un seuil de qualité à atteindre avant toute migration.
- Découpler les interfaces. Placer une couche d’intégration entre le cœur et les autres systèmes, pour que la bascule ne touche pas chaque canal.
- Industrialiser la migration. Outils d’extraction, de transformation et de chargement rejouables, contrôles automatiques de rapprochement : soldes, nombre de comptes, encours, intérêts courus.
- Répéter la bascule. Plusieurs répétitions générales complètes, chronométrées, avec des données de production anonymisées ou protégées. La bascule réelle doit être la répétition de trop.
- Définir le retour arrière. Jusqu’à quel moment peut-on revenir à l’ancien système, sur quels critères, et qui décide ?
- Accompagner après la bascule. Renforcer les équipes de support et la surveillance pendant plusieurs semaines ; publier une information claire aux clients.
Ce que DORA change
Le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique (DORA), applicable depuis le 17 janvier 2025, s’applique aux entités financières de l’Union. Il ne vise pas spécifiquement les migrations, mais plusieurs de ses exigences s’y appliquent directement.
- Gestion du risque lié aux TIC, sous la responsabilité de l’organe de direction
- Tests de résilience des systèmes critiques
- Gestion du risque lié aux prestataires tiers de services TIC, contrats compris
- Notification des incidents majeurs liés aux TIC
- Migration traitée comme un risque majeur, suivie par la direction
- Répétitions et tests documentés, avec critères d’acceptation
- Clauses de sortie, d’audit et de réversibilité avec l’éditeur
- Procédure d’incident prête pour le week-end de bascule
Pour les banques hors Union européenne, les autorités de supervision régionales et nationales ont des exigences de même nature en matière de risque opérationnel et de continuité d’activité. Associer le superviseur tôt reste une bonne pratique partout.
Un calendrier fixé par le terme d’un contrat de maintenance de l’ancien système pousse à sacrifier les répétitions. Mieux vaut négocier une prolongation que basculer sans être prêt.
Liste de contrôle avant de décider
- Le catalogue a-t-il été rationalisé ?
- La qualité des données est-elle mesurée, avec un seuil cible ?
- Les interfaces sont-elles inventoriées et découplées ?
- La stratégie de migration est-elle justifiée au regard de ces trois diagnostics ?
- Le nombre de répétitions générales est-il fixé, et protégé dans le calendrier ?
- Les critères de retour arrière sont-ils écrits et approuvés par la direction ?
- Le contrat avec l’éditeur couvre-t-il réversibilité, audit et continuité ?
L’offre gouvernance de DOSOBE intervient en appui indépendant sur ces projets ; le dossier banques et assurances replace la modernisation dans l’ensemble de la transformation du secteur.
Questions fréquentes
La bascule unique est-elle à proscrire ?
Non. Elle convient à une banque de taille modeste au catalogue simple, avec des données propres. Elle concentre le risque sur un week-end, ce qui exige des répétitions et un plan de retour arrière.
Combien de temps dure une modernisation de système central ?
Plusieurs années pour une banque de taille moyenne ou grande, selon la stratégie. Les annonces de délais très courts portent souvent sur un périmètre partiel.
Faut-il migrer tout l'historique ?
Pas toujours. On migre souvent les comptes actifs et un historique limité, en archivant le reste dans un système consultable conforme aux obligations de conservation.
Quel rôle pour le régulateur ?
La banque doit pouvoir démontrer la maîtrise du risque : gouvernance, tests, continuité, sous-traitance. Il est prudent d'informer tôt l'autorité de supervision du projet et de son calendrier.