Un système core banking n’est pas une application de plus dans le portefeuille IT. C’est le grand livre central de la banque, celui dont dépendent les soldes de comptes, les règlements, le calcul des intérêts et le reporting réglementaire. Quand ce système ralentit ou s’arrête, il ne s’agit pas d’un désagrément mais d’un risque financier, réputationnel et réglementaire. Pour un Head of IT ou un Head of Operations dans une banque, la question n’est donc pas s’il faut maintenir le core banking, mais comment le maintenir pour qu’il se comporte de façon prévisible et puisse être piloté au niveau du service.
D’après notre expérience, la prévisibilité ne vient pas de quelques héros qui éteignent des incendies. Elle vient d’un processus reproductible et de SLA clairement définis. C’est pourquoi nous entrons le plus souvent dans une banque par un modèle de services gérés : nous prenons en charge la maintenance, la surveillance et les intégrations, et la banque nous tient à des délais de réponse et à une disponibilité plutôt qu’à un nombre d’heures travaillées.
Pourquoi la maintenance et le support du core banking sont-ils si critiques ?
Une banque fonctionne en continu, et ses systèmes sont densément reliés. Chaque minute d’indisponibilité du core banking se transforme en virements bloqués, en paiements par carte refusés et en file d’attente qui grandit sur la ligne de service. S’y ajoute la pression réglementaire : le superviseur attend une continuité d’activité documentée, un contrôle des changements et une responsabilité complète sur les incidents.
En pratique, trois choses comptent en même temps. D’abord, la disponibilité pendant les heures bancaires et les traitements batch de nuit. Ensuite, l’intégrité des données, car une erreur de règlement coûte plus cher qu’une brève interruption. Enfin, la rapidité de réaction quand quelque chose se passe mal. Une maintenance qui ne traite qu’un seul de ces points laisse la banque avec un risque non maîtrisé.
Que sont les services gérés et le SLA dans la maintenance bancaire ?
Les services gérés signifient que nous prenons la responsabilité d’un périmètre de systèmes défini, au lieu de simplement prêter des bras. Nous convenons d’un résultat décrit dans un SLA (Service Level Agreement) : à quelle vitesse nous répondons, à quelle vitesse nous résolvons les incidents et quelle disponibilité nous garantissons.
Pour le core banking, ce SLA couvre généralement :
- des niveaux de priorité (P1-P4), chacun avec ses délais de réponse et de résolution,
- une disponibilité cible du service (par exemple sur les fenêtres ouvrées et de traitement batch),
- des fenêtres de maintenance pour les changements, les mises à jour et les travaux planifiés,
- un chemin d’escalade et un reporting sur les paramètres réellement atteints.
La différence essentielle avec un simple support est qu’un SLA déplace la conversation de « combien de personnes travaillent » vers « quel résultat nous livrons ». C’est précisément ce résultat que la banque présente ensuite à son auditeur et à son superviseur.
À quoi ressemblent la surveillance, le support et l’administration au quotidien ?
Nous bâtissons le travail quotidien sur trois piliers qui doivent fonctionner ensemble. Nous surveillons le système et son environnement, nous traitons les tickets sur les lignes de support et nous administrons les environnements pour qu’un incident ne survienne pas.
À ce niveau, nous faisons généralement ceci :
- observer la performance, la disponibilité et les traitements batch avant qu’un utilisateur ne signale un problème,
- prendre en charge les tickets en 1re, 2e et 3e ligne, avec un partage clair des responsabilités,
- administrer les environnements, les droits d’accès, la configuration et les travaux récurrents,
- analyser les données et les journaux pour distinguer un incident isolé d’une tendance qui se forme.
Le principe est que le support ne s’arrête pas à la clôture d’un ticket : il clôt la cause racine.
Comment intégrons-nous le core banking aux autres systèmes de la banque ?
Le core banking fonctionne rarement en vase clos. Autour de lui vivent les systèmes de paiement, la banque en ligne et mobile, l’entrepôt de données, le CRM, les modules de reporting réglementaire et des services tiers. La maintenance signifie donc aussi veiller sur les intégrations et sur la couche d’échange de données, car c’est là qu’apparaissent le plus souvent les erreurs silencieuses.
Nous maintenons la stabilité des interfaces et des API entre les systèmes, et nous rendons les flux de données auditables et reproductibles. Nous surveillons la cohérence des données entre le core banking, l’entrepôt et le reporting, et chaque fois qu’un système change, nous vérifions ce qui arrive aux autres. Dans une banque, l’intégration n’est pas un projet ponctuel mais un domaine de maintenance continu qu’il faut versionner, tester et surveiller comme toute autre partie du service.
Comment assurons-nous la continuité d’activité et la sécurité ?
Nous traitons la continuité et la sécurité comme une part de la maintenance, pas comme un sujet séparé pour plus tard. En pratique, cela signifie travailler selon des procédures : nous planifions les changements dans les fenêtres de maintenance, nous tenons les sauvegardes et les scénarios de reprise, et nous contrôlons les accès selon le principe du privilège minimal.
Pour la sécurité et la continuité, nous faisons généralement ceci :
- gérer le changement pour qu’aucune modification n’atteigne la production sans contrôle,
- tester la reprise et les procédures de bascule au lieu de supposer qu’elles fonctionneront,
- veiller sur les droits d’accès et les pistes d’audit, car dans une banque chaque opération doit être imputable,
- documenter les incidents et les changements d’une manière qui tienne devant un contrôle du superviseur.
Comment mesurons-nous le SLA dans la maintenance du core banking ?
Un SLA ne fonctionne que s’il est mesurable et visible des deux côtés. Nous rendons compte du délai de réponse et du délai de résolution par priorité, de la disponibilité du service et de l’efficacité (combien d’incidents nous avons résolus dans les seuils convenus). Nous publions ces chiffres à une cadence régulière, avec une analyse des causes racines et des recommandations, pour que la maintenance s’améliore de mois en mois au lieu d’être simplement « assurée ». Pour un Head of IT, c’est le jeu de données qui transforme la maintenance en quelque chose que l’on peut prévoir, budgéter et défendre en audit.
Quelles compétences fournissons-nous pour la maintenance bancaire ?
Nous construisons l’équipe autour de l’environnement bancaire concerné, pas autour d’un gabarit générique. Dans les équipes de maintenance bancaire, nous affectons des rôles comme administrateurs systèmes et bases de données, ingénieurs de support applicatif, spécialistes intégration et analystes de données capables de lire réellement ce que fait le système. Quand la banque a besoin de souplesse, nous combinons services gérés et renfort d’équipe, afin de faire varier l’effectif avec la charge et la feuille de route.
Comment faisons-nous chez RITS ?
Nous le faisons sur la base d’une expérience bancaire réelle. Pour un groupe né dans la banque coopérative et devenu un acteur international, nous assurons depuis 2017 l’administration IT, le support technique et l’analyse de données. Au fil du temps, l’engagement a grandi jusqu’à près de 80 spécialistes travaillant en modèle de body leasing, ce qui a permis au client de maintenir et de faire évoluer son environnement sans bâtir tout un département de zéro.
Qu’est-ce que cela signifie pour une autre banque ? Que la maintenance peut reposer sur une équipe stable et dédiée qui connaît l’environnement et grandit avec l’organisation, au lieu de réagir seulement quand quelque chose casse. Comme partenaire nearshore depuis la Pologne, nous travaillons dans un fuseau horaire proche : nous nous insérons donc dans le rythme de travail de la banque, ses revues et ses fenêtres de maintenance sans longue montée en charge, et nous rendons compte de notre travail par des SLA plutôt que par des heures enregistrées.
Par où commencer une maintenance du core banking selon des SLA ?
Partez d’une carte de vos systèmes et de vos intégrations et de la question de savoir quels services sont vraiment critiques pour la banque et pour le régulateur. Cela définit vos priorités, vos niveaux de SLA et les compétences nécessaires dans l’équipe de maintenance. Si vous pesez les services gérés face à une équipe dédiée ou au renfort de vos propres collaborateurs, nous avons traité les différences dans notre article sur les modèles de collaboration IT.
Vous voulez maintenir et intégrer le core banking selon des SLA fermes ? Parlons-en - nous accorderons une équipe et un modèle de service à votre banque.
Organisez avec nous la maintenance du core banking selon des SLA