TSB, avril 2018 : le week-end où une banque n'a pas pu revenir en arrière

Le dimanche 22 avril 2018, vers 13 h, une banque britannique a autorisé la dernière étape d'un projet de près de trois ans. Pendant ce week-end, elle avait basculé la plus grande partie de son activité vers une nouvelle plateforme technologique : ses systèmes, ses services et les données de ses clients. À 18 h, la banque par téléphone et la banque en ligne étaient de nouveau accessibles. L'application mobile a mis un peu plus de temps : elle a démarré à 18 h 45 [1].

Quinze minutes plus tard, la banque a coupé tous ses canaux numériques.

Environ 40 clients avaient signalé ce qu'aucune banque ne veut entendre : en se connectant à leur compte, ils voyaient l'argent d'une autre personne, le plus souvent un proche. Il a été confirmé plus tard que cela était arrivé à 440 clients [1]. La banque s'appelait TSB, elle comptait environ 5,2 millions de clients [1], et cette nuit-là a commencé une crise qui, selon le régulateur, ne s'est pas tout à fait achevée avant le 10 décembre 2018 [1].

Cet article s'adresse à celles et ceux qui signent la décision de changer un système central : direction générale, finance, opérations ou systèmes d'information. Ce n'est pas une histoire technique. C'est l'histoire d'une décision de comité qui a laissé la banque sans retour arrière viable, avec des signaux de préparation incomplets sur la table, et des questions qui auraient dû exiger des preuves plus claires avant d'autoriser le démarrage.

Une précision avant de commencer : Hábil n'a pas participé à ce cas. Nous le racontons à partir de ce que les régulateurs (FCA et PRA) ont communiqué publiquement et du rapport indépendant publié par TSB.

D'abord, quatre mots

Pour que tout le monde autour de la table entende la même chose :

• Système central (« core ») : le système où vivent les comptes, les soldes, les mouvements et les règles de l'activité. Dans une banque, c'est lui qui décide si un paiement a été appliqué.
• Migration : faire passer l'activité et les données d'un système à un autre.
• « Big bang » : concentrer l'essentiel d'une migration en un seul événement, presque toujours un week-end. Il peut y avoir des étapes préalables, mais le risque principal se concentre à ce moment-là.
• Retour arrière (ou roll-back) : la possibilité de revenir au système précédent si le nouveau échoue.

Retenez le dernier. Il explique tout le reste.

Le lundi où tout s'est vu

Le lundi 23 avril, à deux heures du matin, la banque a rallumé la banque en ligne et l'application. Mais une partie de la nouvelle plateforme consommait d'énormes quantités de mémoire, et la banque a dû limiter les connexions pour que l'application ne s'effondre pas [1].

Ce jour-là, il y a eu environ 900 000 tentatives de connexion à la banque en ligne. Seules 10 % environ des tentatives par internet ont abouti. Parmi les paiements que les clients ont tenté d'effectuer, 48 % n'ont pas abouti dans l'application et 59 % sur internet [1].

Les clients qui n'ont pas pu se connecter ont fait ce qui est logique : ils ont appelé. À 14 h, le centre d'appels avait déjà reçu 69 000 appels. La banque s'était préparée à jusqu'à 50 % d'appels de plus que la normale, mais un problème de configuration n'a laissé disponible qu'environ un quart de la capacité de lignes prévue. L'attente avoisinait 90 minutes, et sept personnes sur dix raccrochaient avant d'être prises en charge [1].

Ceux qui n'ont rien obtenu par téléphone sont allés en agence. Là, l'application de caisse tombait en panne et les lecteurs de cartes ne fonctionnaient pas. De longues files se sont formées [1].

Le régulateur décrit un effet en cascade : la défaillance numérique a poussé les gens vers le téléphone, le téléphone s'est saturé, et les gens sont arrivés dans des agences qui défaillaient elles aussi [1]. Le téléphone et les agences avaient leurs propres problèmes, si bien qu'aucun canal n'a pu absorber la demande des autres.

Les canaux numériques sont restés « instables et presque inutilisables » jusqu'au jeudi 26 avril [1]. Ce jour-là, la banque avait enregistré 10 315 réclamations, contre les 1 146 qu'elle attendait [1]. Certains défauts ont persisté jusqu'en juin [1].

Le coût de la crise

La suite se raconte en chiffres, tous issus de documents officiels :

• 225 492 réclamations entre le 22 avril 2018 et le 7 avril 2019, émanant d'environ 4,3 % de ses clients [1].
• 32,7 millions de livres versés aux clients en indemnisation sur la même période [1].
• Près de 12 mois pour traiter les réclamations liées à la migration [1].
• 48,65 millions de livres d'amendes le 20 décembre 2022 : 29,75 millions de la Financial Conduct Authority (FCA) et 18,9 millions de la Prudential Regulation Authority (PRA), les deux régulateurs du Royaume-Uni. Sans la réduction de 30 % accordée pour un règlement amiable, elles auraient atteint 69,5 millions [1][2][3].
• Une amende personnelle en avril 2023 : la PRA a sanctionné l'ancien directeur des systèmes d'information de 81 620 livres pour ne pas avoir pris de mesures raisonnables afin que la banque supervise correctement son prestataire pendant la migration [5].

Et un fait change la lecture de tout ce qui précède : la migration des données a été réussie [1]. Cela n'a pas évité les défaillances d'accès et d'exploitation, ni les cas de clients ayant vu des informations qui n'étaient pas les leurs. La leçon est inconfortable : réussir la migration des données ne prouve pas qu'une plateforme est prête à servir des millions de clients en même temps. Selon la FCA, les causes directes tenaient à la configuration, à la capacité et au code de la plateforme [1].

Comment on en est arrivé à ce dimanche

Pour comprendre la nuit du 22 avril, il faut remonter presque trois ans en arrière.

TSB est née en 2014, en se séparant du groupe Lloyds, et continuait d'utiliser la plateforme technologique de Lloyds sous contrat. En 2015, elle a été rachetée par la banque espagnole Sabadell, pour 1,7 milliard de livres selon Reuters [7], une banque qui avait l'expérience de la migration de banques vers sa propre plateforme, appelée Proteo [1]. La migration de TSB vers cette plateforme faisait partie de la logique économique du rachat [1].

Après la crise, le conseil d'administration de TSB a confié au cabinet Slaughter and May une revue indépendante. Le rapport, daté d'octobre 2019 et publié par TSB en novembre de cette année-là, reconstitue l'histoire [4][6]. Trois de ses constats expliquent le dimanche d'avril.

1. La date est arrivée avant le plan

Dès le 1er juillet 2015, le lendemain du jour où l'offre de rachat est devenue ferme, une date avait déjà été choisie pour allumer le nouveau système : le dimanche 5 novembre 2017 [4]. Le premier plan formel, achevé neuf mois plus tard, a conservé cette même date.

Le rapport la qualifie d'« ambitieuse et irréaliste » et relève quelque chose de plus grave que la date elle-même : une habitude s'était installée, fixer la date souhaitée puis construire un plan qui y tienne, qu'il soit réaliste ou non [4].

En septembre 2017, la banque a repoussé le démarrage et refait le plan, sans examiner en profondeur les raisons du retard, et neuf jours plus tard elle annonçait publiquement une nouvelle date. En janvier 2018, le projet avait de nouveau dérapé [4].

2. La migration principale, en un week-end et sans discussion approfondie

La façon de migrer est l'une des décisions les plus importantes d'un tel projet : par étapes ou d'un seul coup. Le rapport l'explique sans détour : le faire d'un seul coup est « la méthode la plus rapide, la moins chère et la moins complexe », mais cela suppose de comprendre ses risques et de tester la plateforme à fond avant de la mettre devant tous les clients [4].

Et il ajoute une nuance importante : ce n'aurait pas nécessairement été la mauvaise décision si les mesures voulues avaient été prises pour compenser le risque [4]. Le problème était ailleurs : le choix n'a pas été discuté en profondeur au conseil, les options ne lui ont pas été présentées avec leurs risques, et aucun avis externe n'a été demandé sur ce point [4].

La banque avait bien déplacé certains éléments au préalable : les paiements instantanés, l'application et les distributeurs [1]. Mais le rapport conclut que ces étapes préalables n'ont couvert qu'une petite partie de la plateforme, et que le pilote avec de vrais utilisateurs n'avait pas l'ampleur suffisante pour montrer ce qui se passerait avec tous les clients [4].

Les raisons avancées par la banque pour tout faire en un seul événement sont raisonnables, et c'est pourquoi il vaut la peine de les lire : la difficulté de procéder par étapes d'un prestataire à un autre, le coût d'une migration par étapes, l'idée que le prestataire précédent ne la faciliterait pas, et l'avantage pour le client de voir tous ses produits au même endroit [1].

3. Ce que le conseil n'a pas pu voir

Voici le point central de l'histoire. Plusieurs signaux existaient, mais ils ne sont pas parvenus complets à celui qui décidait :

• Les défauts. Le conseil a été informé d'« environ 800 défauts » qui passeraient dans le système en production. Le rapport a conclu qu'il y en avait en réalité 3 317 : les 800 étaient des groupes de fonctions qui rassemblaient plusieurs défauts, et ceux trouvés lors d'autres tests manquaient [4]. Le problème n'était pas seulement le chiffre, mais que le rapport ne disait pas ce qu'il comptait et ce qu'il laissait de côté.
• Les objectifs de test. Lors des tests de charge de la banque en ligne et de l'application, les objectifs ont été abaissés après que les tests n'avaient pas réussi avec la charge d'origine. Le résumé n'a pas rendu le changement clair, et l'usage réel après le démarrage a dépassé les objectifs réduits [4].
• La configuration réelle n'a pas été testée en entier. L'exploitation reposait sur deux centres de données fonctionnant ensemble, mais les tests de performance ont été réalisés sur un seul. Les problèmes de configuration entre les deux, qui ont frappé les clients numériques dès le premier instant, ne pouvaient pas apparaître dans ces tests [4]. La FCA ajoute qu'une décision prise en dehors de l'instance compétente, fin février 2018, a écourté un test qui aurait probablement détecté le problème [1].
• Le prestataire. Le prestataire qui construisait et exploiterait la plateforme, une filiale de Sabadell, dépendait lui-même de 85 tiers [1]. Un rapport d'un cabinet d'audit, commandé par ce prestataire, qui relevait des déficiences dans ses contrôles internes, n'a pas été communiqué à TSB [4].

Le rapport résume sa conclusion en deux phrases : la nouvelle plateforme n'était pas prête à servir tous les clients, et le prestataire n'était pas prêt à l'exploiter [4]. Au sujet du conseil, il dit qu'il a posé des questions pertinentes mais qu'il lui en a manqué certaines « de bon sens », et que sa réunion du 10 avril 2018 a été une occasion manquée de s'arrêter pour réfléchir [4].

Par honnêteté, il faut dire que le conseil de TSB n'était pas d'accord avec tout le rapport. Il a soutenu qu'une cause essentielle tenait à ce que les deux centres de données avaient été configurés différemment, alors qu'ils avaient été spécifiés à l'identique, et qu'il avait décidé d'avancer sur la base de tests approfondis, de rapports de préparation et de garanties du prestataire [6]. Les constats de cette partie viennent du rapport indépendant ; la position du conseil est celle que TSB a publiée.

Le mot qui manquait : retour arrière

De tout ce qui a échoué, une décision transforme un mauvais démarrage en une crise de huit mois.

La FCA l'explique ainsi : lorsqu'on migre presque tous les clients en même temps, un problème grave peut nuire à un très grand nombre de personnes. C'est pourquoi on prépare parfois un plan pour revenir au système précédent. Pour TSB, ce plan n'était pas possible [1]. Par contrat, en notifiant à Lloyds qu'elle partirait par une migration, TSB renonçait à son autre option de sortie : une copie de la plateforme exploitée par un tiers. Et une fois les données migrées, il ne restait qu'une fenêtre très courte avant la désactivation de la plateforme précédente. En pratique, revenir en arrière était techniquement presque impossible [1].

Le risque n'était pas secret. En décembre 2015, le procès-verbal du conseil de TSB consignait que le conseil ne pouvait pas se retrouver dans une position où il renoncerait à son option de sortie, où la migration s'enliserait ou deviendrait irréalisable, « laissant la banque sans infrastructure technologique » [1].

Et la préparation à une crise n'était pas à la hauteur de ce pari. Les manuels de gestion d'incident étaient conçus pour les 48 premières heures [1]. Les exercices supposaient que les incidents se résoudraient en quelques jours ; beaucoup ont duré des semaines [1]. La FCA conclut que, sans retour arrière possible et en dépendant d'un seul prestataire pour corriger plusieurs problèmes à la fois, la banque aurait dû se préparer bien davantage [1].

Ce qu'un directeur retient de cette histoire

TSB n'est pas un cas de mauvaise technologie. C'est un cas de risque concentré en un seul moment, sans issue, avec des informations incomplètes sur la table. Cela peut arriver à toute entreprise qui change son système central, son ERP (le système qui intègre la finance, les achats, les stocks et l'exploitation) ou son système de gestion des contrats d'assurance, quelle que soit la marque. Six leçons, en langage d'entreprise.

1. Si la date l'emporte sur les preuves, le plan est un vœu. Quand chaque retard se résout en resserrant le plan plutôt qu'en déplaçant la date, le risque s'accumule en silence. Demandez des critères mesurables pour démarrer, et que le comité puisse déplacer la date sans que cela ressemble à un échec.

2. La question n'est pas « est-ce que ça marchera ? », mais « que se passe-t-il si ça ne marche pas ? ». Un démarrage d'un seul coup peut être le bon choix. Mais s'il n'y a aucun moyen de revenir en arrière, le coût d'une erreur n'est plus un mauvais week-end : c'est toute l'exploitation pendant des mois. Avant d'approuver, demandez quelle est la voie de retour arrière, combien de temps elle reste disponible et qui décide de l'utiliser.

3. Exigez de voir les options, pas seulement la recommandation. Au conseil de TSB, les façons de migrer n'ont pas été présentées avec leurs risques [4]. Un comité qui ne voit qu'une proposition ne décide pas : il approuve.

4. Le chiffre qui compte est celui que personne ne veut présenter. Des défauts comptés à la baisse, des objectifs de test ajustés sans prévenir, un test écourté sans passer par l'instance compétente. Aucun ne paraît grave pris isolément. Demandez le chiffre brut, qui a modifié chaque critère et quand, et qu'un tiers indépendant le confirme avant la réunion de démarrage.

5. Votre prestataire critique doit démontrer qu'il peut exploiter, pas seulement construire. Ce sont deux capacités distinctes. Si votre prestataire dépend de dizaines de tiers, vous aussi. Demandez des preuves d'exploitation, pas seulement des lettres de garantie.

6. Préparez-vous à des semaines, pas à 48 heures. Demandez ce qui se passe le dixième jour : qui répond aux appels, comment les clients sont indemnisés et comment on repère les plus vulnérables.

Et une septième, que le cas rend évidente : la responsabilité atteint les personnes. L'amende à l'ancien directeur des systèmes d'information sanctionnait l'absence de mesures raisonnables pour que la banque supervise correctement son prestataire [5]. La garantie d'un prestataire ne remplace pas les preuves que l'entreprise elle-même doit obtenir et examiner.

L'alternative : moderniser par étapes, en cohabitant avec le système central

Le cas TSB ne prouve pas que tout changement de système central échoue, ni que moderniser par étapes soit possible dans tous les contextes. Il montre en revanche ce que doit exiger un comité lorsqu'il concentre en un seul moment les changements critiques, tous les clients et l'absence de retour arrière.

Si le risque de TSB a été de tout concentrer en un seul moment sans issue, l'alternative consiste à le répartir : moderniser par étapes, avec le système actuel en service pendant ce temps, et avec une voie de retour arrière à chaque étape.

En termes d'entreprise, cela se présente ainsi :

• Le système central actuel continue de fonctionner. On ne l'éteint pas le vendredi pour en allumer un autre le dimanche. Autour de lui, on construit une couche qui le relie aux canaux, aux partenaires et aux nouvelles fonctions, sans toucher à ses règles internes.
• On change une fonction à la fois. Par exemple, d'abord la consultation des soldes pour un petit groupe de clients ; ensuite les paiements ; ensuite un autre produit. Chaque partie est validée avant de commencer la suivante.
• Chaque étape a son retour arrière convenu. Avant de commencer, on convient de la manière de ramener cette fonction vers le chemin précédent si quelque chose tourne mal, sans entraîner le reste de l'exploitation.
• L'ancien et le nouveau sont rapprochés. Tant qu'ils cohabitent, on compare ce que dit l'un à ce que dit l'autre. La nouvelle fonction gagne sa place par des preuves, pas par une date.
• La montée en charge est progressive. D'abord un groupe de clients, puis un autre. Les problèmes tendent à apparaître lorsqu'ils touchent peu de monde et sont plus faciles à corriger.

Ce chemin n'est pas gratuit : tant que les deux mondes cohabitent, il faut entretenir des connexions, un rapprochement des données et deux équipes. Il prend souvent plus de temps, et exige de la discipline pour ne pas laisser la cohabitation ouverte indéfiniment.

Il n'élimine pas non plus le risque : il change ce qu'il faut démontrer avant d'élargir le périmètre, et sa faisabilité dépend des systèmes, des données et des contrats de chaque entreprise. Mais il change la nature du risque. Dans un démarrage d'un seul coup, on parie presque tout sur la réussite du premier jour. Dans une modernisation par étapes, chaque étape expose surtout ce qui y est en train de changer. Quand votre système central décide si un client reçoit son argent, cette différence vaut plus que les semaines gagnées.

Scénario (illustratif, sans client). Une compagnie d'assurance veut renouveler la façon dont ses agents font des devis et émettent des contrats, mais son système de gestion des contrats est ancien et personne ne veut y toucher. Au lieu de le remplacer d'un coup, on lui connecte une nouvelle couche. D'abord, seul le devis d'un produit passe par cette couche, pour un petit groupe d'agents. Pendant une période convenue, chaque nouveau devis est comparé à celui du système précédent. Lorsqu'ils concordent, on ajoute des agents ; ensuite, l'émission. Si quelque chose ne concorde pas, cette fonction revient au chemin habituel grâce au retour arrière convenu avant de commencer. Le système de gestion des contrats reste celui qui fait autorité.

Cinq questions pour votre prochain comité

1. Si le nouveau système échoue le premier jour, comment revenons-nous en arrière, en combien de temps et qui en décide ? Si la réponse est « ce n'est pas possible », le conseil le sait-il ?
2. Quelles options de mise en œuvre ont été évaluées, avec le coût et le risque de chacune, et pourquoi les autres ont-elles été écartées ?
3. Quels critères mesurables doivent être remplis pour démarrer, et qui peut déplacer la date s'ils ne le sont pas ?
4. Combien de défauts ouverts y a-t-il aujourd'hui, et un objectif de test a-t-il changé depuis l'approbation du plan ? Qui l'a autorisé ?
5. Quelles preuves avons-nous que le prestataire peut exploiter le système à grande échelle, et pas seulement le construire, et de quels tiers dépend-il ?

Si, pour deux de ces questions ou plus, la réponse est « je ne sais pas », votre risque se trouve peut-être là.

Par où commencer cette semaine

Prenez le projet de modernisation que vous avez en cours, ou celui qui est sur le point d'être approuvé, et dessinez sur une feuille son moment de risque maximal : le jour où le plus de clients, le plus de fonctions et le plus d'argent changent en même temps. Écrivez à côté ce qui se passerait si ce jour tourne mal et comment on reviendrait en arrière. Si ce moment couvre tous vos clients et n'a pas d'issue, vous savez déjà quelle conversation avoir avec votre comité.

Ce que fait Hábil

Hábil est un cabinet mexicain d'ingénierie, fondé en 2006, qui s'intègre aux systèmes centraux que votre entreprise possède déjà. Nous ne remplaçons pas votre système central : nous construisons autour de lui la couche qui permet de moderniser par étapes, avec le système actuel en service, avec un rapprochement entre l'ancien et le nouveau, et avec un retour arrière convenu à chaque étape. Ainsi, chaque nouvelle fonction gagne sa place par des preuves, et la modernisation est conçue pour que votre activité se poursuive entre-temps. Découvrez la page Moderniser le système central sans freiner l'activité.

Demandez votre première conversation, sans frais. Elle part de votre projet actuel : où se concentre le risque, ce qui dispose aujourd'hui d'un retour arrière et ce qui n'en a pas. Écrivez-nous sur WhatsApp.

Questions fréquentes

Que s'est-il passé chez TSB en avril 2018 ?

Du 20 au 22 avril 2018, TSB a basculé la plus grande partie de son activité vers une nouvelle plateforme. Les données ont été bien migrées, mais la plateforme a défailli sur tous les canaux, et la banque n'est pas revenue à la normale avant décembre [1].

Quel a été le montant des amendes et qui les a infligées ?

Le 20 décembre 2022, la FCA a infligé à TSB 29,75 millions de livres d'amende et la PRA 18,9 millions : 48,65 millions au total, avec une réduction de 30 % pour règlement amiable [1][2][3]. En avril 2023, la PRA a sanctionné l'ancien directeur des systèmes d'information de 81 620 livres [5].

Une migration d'un seul coup est donc toujours une erreur ?

Non. Le rapport indépendant dit que ce n'aurait pas nécessairement été la mauvaise décision si les mesures voulues avaient été prises pour compenser le risque [4]. Ce qui ne tient pas, c'est de la choisir sans évaluer les alternatives, sans tests à l'échelle réelle et sans issue en cas d'échec.

Moderniser par étapes ne coûte-t-il pas plus cher ?

Cela peut coûter plus cher en délai et en entretien de deux systèmes à la fois. En contrepartie, chaque étape expose moins. TSB montre l'autre côté du calcul : indemnisations, amendes et près d'un an à traiter des réclamations [1].

Cela ne concerne-t-il que les banques ?

Non. Cela concerne toute entreprise qui change le système qui décide de son exploitation : le système de gestion des contrats d'une compagnie d'assurance, l'ERP d'une entreprise industrielle, le système de commandes d'un commerce. La taille change ; le risque de tout concentrer en un seul moment sans issue, non.

Quand vaut-il mieux ne pas moderniser par étapes ?

Lorsque les fonctions ne peuvent pas être séparées les unes des autres, lorsque les données ne peuvent pas être rapprochées entre l'ancien système et le nouveau, ou lorsqu'un contrat oblige à abandonner le système précédent à une date fixe. Dans ces cas, la conversation change : quelle part du risque peut être réduite et laquelle doit être acceptée les yeux ouverts.

Hábil remplace-t-il notre système central ?

Non. Hábil s'intègre à votre système central actuel et construit autour de lui la couche qui permet de moderniser par étapes. Le système central continue de fonctionner et chaque étape a son retour arrière convenu.

Les citations sont traduites de l'anglais. Les chiffres, dates et sanctions proviennent des décisions de la FCA et de la PRA ; l'analyse des décisions du projet, du rapport indépendant de Slaughter and May, publié par TSB ; la position du conseil, du communiqué de TSB. Sources consultées les 20 et 21 octobre 2026.