Consultation

Étude de cas · Finance

TSB : une migration informatique qui paralyse une banque

Royaume-Uni, 2018. Une migration de plateforme bancaire échoue dès sa mise en service et perturbe les services pendant des mois.

En une phraseUne date de mise en service est une décision, pas un plan : TSB a planifié à rebours depuis la date, et ses clients en ont payé le prix.

Secteur
Banque de détail
Pays
Royaume-Uni
Date
Avril 2018
Durée
Retour à la normale en décembre 2018
Conséquences réglementaires
Amende de 48,65 M£ (FCA et PRA, 2022)

Analyse fondée uniquement sur des informations publiques. FZ Consultation n'a pas participé à cet incident et n'a aucun lien avec les organisations mentionnées.

Ce qui s'est passé

  1. 2015–2018

    TSB prépare le transfert de ses services de la plateforme de Lloyds vers une nouvelle plateforme conçue et exploitée par une filiale de sa société mère, Sabadell.

  2. 20–22 avril 2018

    Les données sont migrées avec succès, mais la plateforme connaît des défaillances techniques dès sa mise en service.

  3. Semaines suivantes

    Les agences, le téléphone, les services en ligne et mobiles sont perturbés ; toutes les agences et une part importante des 5,2 millions de clients sont touchées.

  4. Décembre 2018

    La banque revient à un fonctionnement normal.

  5. Décembre 2022

    La FCA et la PRA infligent une amende de 48,65 M£. En 2023, la PRA sanctionne aussi l'ancien directeur informatique.

Ce qui a mal tourné

D'après les sources publiques citées plus bas.

Un calendrier fixé à l'envers

Selon les régulateurs, le plan partait d'une date cible au lieu d'estimer de façon réaliste la durée de chaque étape, même après des retards.

Des tests réduits

La portée des tests non fonctionnels des canaux numériques a été ramenée à un seul des deux centres de données.

Une supervision insuffisante du fournisseur

Les régulateurs ont conclu que la banque n'avait pas géré adéquatement les risques liés à son fournisseur informatique externalisé, même intra-groupe.

Les leçons pour votre organisation

  1. 1

    Planifier de gauche à droite

    Estimer chaque phase avant de fixer une date, et réévaluer honnêtement après chaque retard.

    Savoir : mesurer ce qu'un arrêt coûterait
  2. 2

    Tester dans des conditions réelles

    Charge, capacité et bascule sur tous les centres de données avant la mise en service, avec un plan de retour arrière éprouvé.

    Prouver : répéter avant le vrai jour
  3. 3

    Superviser les tiers critiques

    Un fournisseur intra-groupe reste un tiers : exiger des preuves, pas des assurances. C'est aussi une exigence de DORA et des règles FCA/PRA.

    Réglementation

À vérifier lundi matin

Trois questions à poser à votre propre organisation cette semaine. Si vous ne pouvez pas répondre à l'une d'elles en cinq minutes, c'est votre première tâche.

  1. Prenez votre prochain grand changement. Chaque phase a-t-elle été estimée avant que la date soit fixée ?
  2. Existe-t-il un retour arrière que vous avez réellement répété, sur tous les centres de données ?
  3. Demandez à votre fournisseur TI le plus critique, même interne, des preuves de test plutôt que des assurances.
Répéter un retour arrière

Sources

Autres études de cas