Moderniser le système central : le dossier pour le comité, pas le guide technique

Imaginez un comité qui autorise le lancement du remplacement du système central de l'institution pendant un week-end. Il y a plus de quatre ans de planification derrière, des répétitions, un pilote interne et les garanties des fournisseurs. Sur le papier, la préparation semble complète.

C'est, pour l'essentiel, ce qui s'est passé dans une banque britannique : le conseil de TSB et son sous-comité ont autorisé, entre le 18 et le 19 avril 2018, le lancement de la migration, exécutée pendant le week-end du 20 au 22. Presque aussitôt sont apparus de sérieux dysfonctionnements, et le lundi suivant a montré que préparation et assurance suffisante ne sont pas la même chose.

Par « système central » (le « core »), nous entendons ici le système de référence dont dépendent des opérations critiques : clients, comptes, polices, commandes, stocks, encaissements, rapprochements ou états, selon le secteur, et avec lui les autres systèmes (canaux, paiements, comptabilité). Cet article n'est pas un guide technique. C'est le dossier de celui ou celle qui doit décider : ce qu'un comité peut apprendre du cas public de TSB lorsque la migration de données et de fonctions critiques est concentrée en un seul événement, quelle alternative existe, et comment présenter cette alternative à un comité qui s'interroge sur le risque, le coût et les dates. Il est écrit pour qui répond des opérations, du budget ou du risque dans une banque, une fintech, un assureur, une chaîne de distribution ou une entreprise réglementée.

Ce que TSB et la PRA ont publié sur le cas

TSB, une banque britannique, a exécuté sa migration principale vers une nouvelle plateforme en avril 2018. La banque elle-même a décrit le programme comme le changement le plus complexe qu'elle ait entrepris et « l'un des plus complexes de l'histoire de la banque britannique », avec plus de quatre ans de planification [2]. Selon la banque, le conseil d'administration a autorisé l'événement principal de migration sur la base d' « un volume significatif de preuves objectives » : attestations de la direction, garanties écrites et orales des fournisseurs, neuf répétitions générales et événements de transition réussis, et un pilote auprès de plus de 1 600 employés [2]. La migration n'a pas non plus été un événement unique de bout en bout : selon TSB, elle s'est faite par étapes (distributeurs automatiques, paiements par carte, prêts immobiliers et application mobile, entre autres), et ce qui s'est fait d'un seul coup a été l'événement principal de migration des données des clients [2].

Autrement dit, ce n'était pas de l'improvisation. Il y a eu planification, répétitions et assurance. Pourtant, selon le régulateur prudentiel britannique (PRA) [1] (TSB lui-même ne partage pas certains aspects de la revue indépendante [2][5]) :

• Toutes les agences de TSB et une proportion significative de ses 5,2 millions de clients ont été touchées par les problèmes initiaux.
• TSB a mis jusqu'en décembre 2018 à revenir à son fonctionnement normal.
• La banque a versé 32,7 millions de livres d'indemnisations [1] aux clients qui ont subi un préjudice.
• En décembre 2022, la PRA et la FCA ont infligé conjointement à TSB une amende de 48,65 millions de livres [4].
• En avril 2023, la PRA a infligé une amende de 81 620 livres [1] au directeur des systèmes d'information de l'époque, pour ne pas avoir veillé à ce que la banque supervise de façon adéquate la sous-traitance de son programme de migration de 2018. Entre autres choses, selon le régulateur, il n'a pas réévalué suffisamment les capacités du tiers ni obtenu l'assurance nécessaire sur la préparation de la plateforme avant de donner des garanties au conseil.

Il y a deux leçons pour un comité, et aucune n'est technique.

La première : la préparation déclarée ne remplace pas une assurance suffisante. Le conseil disposait de beaucoup de documentation. Ce que le régulateur a mis en cause, c'est la solidité de l'assurance qui la sous-tendait : selon la PRA, le responsable n'a pas pris de mesures raisonnables pour que la banque obtienne une assurance suffisante du tiers sur sa préparation, ni examiné assez si une enquête plus poussée était nécessaire avant de donner des garanties au conseil [1]. Un « tout au vert » dans une présentation n'est pas la même chose que cette assurance.

La seconde : la responsabilité peut atteindre des personnes, pas seulement des entreprises. L'amende au directeur des systèmes d'information relève du régime britannique de responsabilité individuelle des dirigeants ; au Mexique, le cadre applicable est autre et chaque institution doit le vérifier. Le cas montre que, sous le régime britannique applicable, la supervision d'un tiers peut entraîner une responsabilité individuelle en plus des sanctions à l'institution ; il ne permet pas de transposer automatiquement cette conséquence au cadre mexicain.

Ce que cet article ne fait pas compte aussi. Le comité d'une institution mexicaine pourrait demander si la même chose se passe ici, mais cet article ne compare pas les sanctions ni les incidents mexicains. Pour une décision concrète, l'institution doit identifier le cadre sectoriel qui lui est applicable et le valider avec ses services juridique, conformité et risques.

Pourquoi la bascule unique concentre le risque

Martin Fowler, auteur et référence en architecture logicielle, le dit sans détour à propos des remplacements de systèmes hérités : « nous avons vu ce plan d'apparence simple partir à la dérive la plupart du temps » (traduction propre) [3]. La raison qu'il donne est commerciale, non technique : remplacer un système sérieux prend beaucoup de temps, et pendant ce temps les utilisateurs ne peuvent pas attendre de nouvelles fonctions [3].

Traduit dans le langage du comité, une bascule unique réunit en un seul moment trois choses qu'il convient de séparer :

1. La valeur tend à arriver à la fin. Pendant des années on investit et l'activité ne reçoit rien qu'elle puisse mesurer. Si le projet prend du retard, il n'y a rien de partiel à montrer.
2. Le risque se concentre sur un seul jour. Les clients, les agences, les canaux numériques, les paiements et les rapprochements changent en même temps. Si quelque chose échoue, tout peut échouer ensemble.
3. Le retour arrière est souvent difficile ou inexistant. Quand les données ont déjà migré et que les opérations du lundi ont été écrites dans le nouveau système, revenir à l'ancien cesse d'être un bouton et devient un autre projet.

Voir ces trois points sur une feuille aide le comité à changer la conversation. La question cesse d'être « quand terminons-nous ? » pour devenir « que se passe-t-il si quelque chose tourne mal le jour de la bascule et quelle part de l'activité est exposée ? ».

L'alternative : par étapes, avec retour arrière

Fowler a donné un nom à l'alternative, emprunté à une plante qui grandit autour d'un arbre jusqu'à le remplacer : le figuier étrangleur (strangler fig). L'idée est simple à expliquer à un comité : au lieu d'éteindre le système ancien et d'allumer le nouveau, on construit autour de l'ancien, pièce par pièce, et l'on transfère une fonction à la fois. Pendant qu'une fonction est transférée, le système précédent peut continuer à assurer celles qui ne l'ont pas encore été, selon la conception des données, de l'exploitation et des contrôles. Fowler, citant Ian Cartwright, Rob Horn et James Lewis, mentionne quatre activités (l'ordre dans lequel elles sont listées n'implique pas une séquence) : comprendre les résultats que l'on veut atteindre, décider comment découper le problème en parties plus petites, livrer ces parties avec succès et changer l'organisation pour que cela puisse se produire de façon continue [3].

Et il est honnête sur le coût : construire cette couche transitoire peut sembler du gaspillage, mais « le moindre risque et la valeur plus précoce de l'approche graduelle l'emportent sur son coût » [3]. Cette affirmation est son critère, non une mesure universelle ; c'est pourquoi il convient que votre comité la mette à l'épreuve avec ses propres chiffres, comme expliqué plus bas.

La différence pratique avec la bascule unique se voit dans une comparaison :

La dernière ligne compte. Le chemin par étapes n'est pas gratuit, et celui qui le présente ainsi perd sa crédibilité devant un directeur financier.

Le retour arrière ne se produit pas non plus tout seul. Qu'une étape puisse être annulée est une propriété qui se conçoit : quelle fonction est transférée, quel trafic elle reçoit, quel signal indique qu'il faut revenir en arrière et qui a l'autorité d'en décider. Il existe des étapes irréversibles légitimes, mais elles conservent une exposition concentrée dans leur périmètre et doivent être justifiées explicitement devant le comité : ce qui les rend irréversibles, comment le dommage est limité et quels contrôles compensent l'absence de retour arrière.

Comment le présenter au comité

Pour cette décision, le comité peut privilégier trois choses, dans cet ordre, plutôt que le détail technique.

1. Le risque, avec son retour arrière

La question à laquelle il convient de répondre en une page : quel est le pire qui puisse arriver à chaque étape, et comment revenons-nous en arrière ? Pour chaque étape, trois données : quelle part de l'activité elle touche, quel indicateur signale que quelque chose va mal et combien de temps il faut pour revenir à l'état précédent.

Scénario (illustratif, sans client). Un assureur dont une police de frais médicaux est gérée dans un système central vieux de deux décennies décide de commencer par les devis plutôt que par les polices émises. La première étape transfère le calcul du devis vers une pièce nouvelle, tandis que le système central continue d'émettre. Si le devis nouveau donne des résultats différents de ceux du système actuel dans un pourcentage que le comité a fixé à l'avance, le trafic revient au calcul précédent. Ce qui est exposé est une fonction, non l'activité entière.

2. Le coût de ne rien faire

C'est la partie que l'on omet souvent et qui peut peser davantage. Un comité qui ne voit que le coût de la modernisation compare un chiffre à zéro, et le zéro l'emporte souvent. Mais maintenir le système actuel coûte aussi, et ce calcul doit être fait avec des données propres, non avec des chiffres de tiers. Nous n'utilisons pas ici de pourcentages génériques du marché sur la part du budget consacrée aux systèmes hérités ou sur l'échec des remplacements, car ils ne sont pas nécessaires pour décider de ce cas. Le calcul du comité doit sortir de sa propre comptabilité, de ses incidents et de ses délais de changement :

• combien l'on dépense par an pour maintenir, corriger et exploiter le système actuel ;
• combien de temps il faut aujourd'hui pour lancer un produit, un tarif ou un changement réglementaire, et quel revenu est différé entre-temps ;
• combien de personnes concentrent la connaissance du système et ce qui se passe si l'une d'elles part ;
• quels incidents ou clôtures manuelles vous attribuez aujourd'hui aux limites du système central.

Si le comité n'a pas ces chiffres, c'est en soi le premier constat et le premier livrable.

3. Des jalons mesurables, pas un pourcentage d'avancement

« Nous en sommes à 60 % » est une phrase qu'un programme de remplacement peut dire jusqu'au jour où il échoue. Les jalons d' une modernisation par étapes peuvent se mesurer dans l'activité et non dans le projet :

• quelle part du trafic ou des opérations passe déjà par la pièce nouvelle ;
• combien de temps met désormais à sortir un changement de tarif, de produit ou de règle, par rapport à ce qu'il fallait au début ;
• combien de fois le retour arrière a été exercé et testé, et avec quel résultat ;
• combien coûte le maintien de la couche de cohabitation et à quelle date son retrait est prévu.

Ce dernier point évite un risque connu des approches par étapes : que la couche transitoire devienne permanente. Son retrait doit figurer dans le plan dès le premier jour, avec une date et un responsable.

La partie réglementaire ne se laisse pas pour la fin

Si l'une des étapes implique de déplacer des fonctions vers le cloud ou vers un tiers, les exigences de votre régulateur font partie du calendrier, elles ne sont pas une formalité postérieure. Au Mexique, la réponse dépend de l'entité et du tiers : les établissements de crédit, les institutions de fonds de paiement électronique (IFPE), les assureurs et les sociétés de cautionnement ont chacun leurs propres règles sur la contractualisation et la supervision des tiers, qui peuvent prévoir un avis préalable ou une autorisation selon le service et le lieu où il est fourni. Avant d'autoriser une étape, le juridique et la conformité doivent confirmer l'obligation, l'autorité, le dossier et le délai applicables. Trois questions concrètes à leur poser : cette étape requiert-elle un avis ou une autorisation préalable auprès de la CNBV (commission bancaire et boursière) ou de la CNSF (commission des assurances et des cautionnements) ? Avec combien d'anticipation ? Quelle preuve d'assurance du tiers le régulateur s'attend-il à voir documentée ? L'obligation, l'autorité compétente et le délai dépendent de l'entité, de la fonction, des données, de la localisation du service et du tiers contractant. Le cas de TSB illustre que le régulateur britannique n'a pas seulement demandé si le système fonctionnait : il a demandé qui avait donné l'assurance, devant qui et avec quelles preuves [1].

C'est pourquoi il convient que chaque étape, lorsqu'elle est présentée au comité, soit accompagnée d'une page de ce type : ce qui est déplacé, qui est notifié, quelles preuves de tests existent et qui répond.

Cinq questions pour votre prochain comité

1. Quelle part de notre activité serait exposée le pire jour de la première étape, et combien de temps mettrions-nous à revenir à l'état précédent ?
2. Avons-nous chiffré le coût annuel de ne pas moderniser, avec les données de notre comptabilité et non d'une présentation de fournisseur ?
3. Quelles preuves indépendantes de tests de charge et de données avons-nous aujourd'hui, et qui, autre que celui qui construit, les a examinées ?
4. Quel jalon de l'activité, et non du projet, verrons-nous dans les six premiers mois ? Par exemple, une fonction tournant sur la pièce nouvelle avec du trafic réel.
5. Quel organe, quelle fonction et quelle personne responsable notre cadre applicable désigne-t-il pour superviser le tiers, et quelles preuves faut-il conserver ?

Si plusieurs réponses sont « je ne sais pas », ce n'est probablement pas un fournisseur qui manque : ce sont des informations pour décider.

Par où commencer cette semaine

Avant d'autoriser un programme plus large, vous pouvez commencer par une feuille avec une seule colonne de fonctions du système central (création de client, devis, émission, encaissement, rapprochement, états réglementaires) et, en face de chacune, trois marques : à quel point elle change chaque année, combien d'autres systèmes en dépendent et ce qui se passerait si elle s'arrêtait une demi-journée. Le comité peut noter chaque fonction selon cinq critères : valeur métier vérifiable, dépendance à d'autres systèmes, réversibilité, représentativité des données et de la charge, et condition réglementaire. La première étape sera celle qui offre le meilleur équilibre pour son contexte, pas nécessairement la plus facile ; une fonction dont la pause ne fait aucun mal peut donner un pilote sans portée. Avec ce critère, le comité dispose d'un ordre à défendre.

Ce que fait Hábil

Hábil accompagne les organisations qui doivent décider comment moderniser leurs systèmes centraux sans perdre de vue la continuité, le contrôle et la traçabilité. C'est l'idée de la page Moderniser le système central sans freiner l'activité ; pour unir vos systèmes et vos canaux, la page Unifier votre activité et vos canaux.

La première conversation de diagnostic est sans frais et sert à délimiter le système, la décision en suspens et les informations dont votre comité aurait besoin pour l'évaluer. Écrivez-nous sur WhatsApp.