Gestion des crises IT dans le secteur bancaire

Philippe Desforges, DSI de Transition, nous livre un témoignage de trois incidents IT majeurs qui ont marqué sa carrière dans le secteur bancaire, en révélant des enseignements indispensables pour toute organisation souhaitant renforcer sa résilience. 

Crise incendie : quand le data center prend feu

Fin août 2005, il est 17 h dans les bureaux de La Défense lorsque retentit l’alerte : un incendie détruit le data center principal de Lognes. « Nous n’étions ni prévenus, ni formés, ni prêts », confie Philippe Desforges. Les pompiers inondent les salles techniques. Une partie de l’équipe doit rester sur place pour gérer la crise et la remise en état quand les salles seront sèches et que nous pourrons relancer le data center. À 20h, l’électricité est enfin rétablie : c’est le signal de départ d’une longue nuit de redémarrage. Plusieurs centaines de serveurs sont rallumés selon les priorités – d’abord la tenue de comptes, puis les paiements internationaux – sous la direction d’une poignée de volontaires. Pas de pause dîner, pas de possibilité de sortir (car les portes étaient verrouillées à partir de 20h dans l’immeuble de La Défense) : l’équipe, affamée et exténuée, lutte contre le sommeil et la tension jusqu’au petit matin.

Dans ces situations de crise, il faut connaître les forces de son équipe : qui tient sous pression, qui garde la tête froide, qui relance les scripts sans flancher , explique Philippe.

Leçons clés

• Connaître et valoriser les compétences-clés : identifier les collaborateurs capables de gérer la pression et de maintenir l’effort jusqu’au bout.
• Leadership clair : un management serein est vital pour maintenir la cohésion et l'efficacite ce qui permet de répartir les rôles et encourage les volontaires.
• Résilience collective : passer la nuit sans manger ni sortir, dans un immeuble verrouillé, nécessite une force mentale partagée ; l’esprit d’équipe devient alors le moteur de la reprise.

“Quand on s'entend bien dans une équipe parce qu'on est un bon manager et qu'on évite d'avoir des conflits avec les gens et que l'on travaille en confiance, le jour où cela se passe mal, nos salariés ne sont pas paniqués. L'équipe, cela compte beaucoup !”

Dysfonctionnements logiciels et tests inadéquats : quand l'erreur de test se transforme en menace

Autre épisode critique, toujours dans une banque. "J’étais alors responsable des études des virements internationaux. J'ai piloté la migration de notre plateforme de mainframe vers une nouvelle machine multi-CPU, vantée comme “quatre fois plus puissante”. Forts de benchmarks en laboratoire sur des volumes limités, la production juge inutile les tests de charge en conditions réelles : “La machine est plus performante, pourquoi s’embêter ?”

• Jour J, lundi matin – La bascule s’effectue sans incident apparent et les premiers lots de transactions sont traités.
• 10 h – Nous constatons un retard de près de 30 % sur le lot critique du lundi matin.
• 12 h – Seule la moitié du volume habituel a été traitée ; les clients corporate, dépendants de ces flux pour leurs virements de masse, menacent de quitter la banque.
• Lundi soir et mardi – Défilé de comités de crise : développeurs et infrastructure cherchent en vain à optimiser le code et les configurations.
• Mercredi – Malgré des bricolages successifs, les performances restent décevantes ; la pression monte de tous côtés.
• Jeudi matin – Après trois jours de blocage, un test de charge en conditions réelles révèle la cause : l’OS n’exploite qu’une seule carte sur les quatre cartes. Ça veut dire que le système d'exploitation, ne tourner que sur une carte à la fois, même s’il y en a quatre.
• Jeudi après-midi – Décision est prise de désinstaller la « super machine » pendant le prochain arrêt weekend, et de la remplacer par un serveur déjà éprouvé en préproduction.
• Week-end – En deux jours, nous démontons la machine multi-CPU, installons la machine Unix de secours, rechargeons les données, et refaisons l’intégralité des tests.
• Lundi suivant – La plateforme redémarre sur la machine provisoire, les flux retrouvent immédiatement leur rythme normal.

Après ces événements, il faut bien évidemment prendre le temps de remercier les équipes, de leur laisser le temps de souffler, de prendre une journée off le lendemain. Il faut appeler les responsables des prestataires pour souligner l’implication et le bon travail.

Répercussions et pression

Les répercussions de la crise ont été à différents niveaux :

• Clients et réputation : les blocages de transferts de virements ont poussé plusieurs entreprises à utiliser d’autres prestataires, ébranlant à la fois la confiance des clients et l’image de solidité d’HSBC.
• Opérationnel : l’ouverture quotidienne de comités de crise, les help-desks saturés et les nuits courtes ont créé une atmosphère de tension et d’épuisement généralisé.
• Hiérarchie : une enquête a été ouverte par HSBC Londres sous la forme d'un Major Incident Report, proposant des améliorations de gouvernance d'architecture

Leçons clés

Ce qu’on peut tirer comme leçons de cette crise :

• Ne jamais écarter les tests sur cible : la documentation constructeur ne remplace pas un essai grandeur nature, avec les volumes et les scénarios de production.
• Impliquer métiers et infrastructure dès le début : co-construire les scénarios de test et partager les critères de succès pour éviter les zones d’ombre.
• Plan B et réversibilité : anticiper une solution de secours éprouvée, planifier sa mise en œuvre rapide, et répéter les procédures pendant les phases de test.
• Reconnaître l’effort des équipes : après une semaine de tensions et de nuits blanches, un mot de remerciement, une mise en lumière des réussites, voire une récompense symbolique, renforcent la cohésion et préparent à relever le prochain défi.

L'Incident des virements avant Noël : quand la pression transforme l'erreur en crise nationale

Autre crise dans le milieu de la banque, pendant la période de Noël. Les agences bancaires sont prises d’assaut par les particuliers venus effectuer des virements, notamment pour les étrennes. Ce matin-là, le Président de la banque se rend dans une agence pour transférer de l’argent à ses enfants ou petits-enfants. À sa grande surprise, son virement échoue. Son courroux, relayé instantanément à la direction, place la cellule IT sous une pression extrême : il faut corriger le problème en un temps record.

Déroulé de la crise

• Correctif « express » et tests au siège
  Pour « rassurer » le plus haut niveau, un patch est développé dans la foulée et testé en quelques heures dans les conditions « bureau » du siège, selon un scénario linéaire où l’on saisit, valide, et soumet le virement sans interruption.
• Omission cruciale des essais terrain
  Aucun test n’a été mené en agence, avec de vrais guichetiers utilisant l’application : navigation entre plusieurs écrans, retours en arrière fréquents, réouverture de formulaires déjà saisis…
• Effet immédiat en production
  Lors de la première transaction d’un client, chaque virement est dupliqué : côte à côte, deux débits identiques apparaissent. La faute ? Une boucle de code mal ajustée qui, lorsqu’un utilisateur revient sur l’écran de confirmation, renvoie deux appels au serveur. En quelques heures, des centaines de virements doublés génèrent plus de 80 M€ de mouvements (40 M€ de perte nette).
• Diagnostic par reproduction terrain
  Seuls les essais en vraie condition d’agence permettent de dévoiler le bug : en reproduisant exactement le parcours d’un guichetier, l’équipe identifie la double-exécution de la boucle de validation.
• Correction et enquête
  Un nouveau patch est conçu et déployé dans la journée. Le Major Incident Report britannique souligne l’absence d’essais terrain et la précipitation dictée par la pression.

Leçons clés

• Ne pas céder à la panique 
• Réaliser une recette métier exhaustive jusqu’au terrain
  Un correctif validé en conditions contrôlées peut échouer face aux pratiques réelles des utilisateurs. Il est impératif de tester dans les agences, avec de vrais guichetiers et leurs parcours non linéaires (retours, multi-écrans, interruptions).
• Processus de validation inaltérable
  Même sous forte pression, respecter un plan de recette structuré, documenter chaque scénario et exiger la validation formelle des utilisateurs finaux avant tout déploiement.
• Intégrer la complexité des usages dès la conception
  Anticiper et modéliser, dès la phase de spécification, tous les scénarios alternatifs et « hors-process » des guichetiers pour garantir que le correctif fonctionne réellement en production.

“Ce n'est pas seulement une question de code, c'est une question de compréhension des usages réels et de la capacité à ajuster nos procédures en conséquence” conclut Philippe.

Conclusion : transformer les crises en opportunités d'amélioration

Les trois expériences de Philippe Desforges démontrent que dans le secteur bancaire, une crise ne se limite pas à une simple défaillance technique ; elle révèle également des failles en matière de communication, de gouvernance et de préparation. Pour tirer profit de ces situations d'urgence, il est indispensable d’anticiper les signaux faibles et investir dans des systèmes de redondance fiables ainsi que des plans de continuité d’activité adaptés. Réaliser des tests en conditions réelles pour combler le fossé entre la théorie et la pratique. Renforcer la communication entre tous les acteurs, qu'ils soient techniques ou opérationnels, afin d'assurer une réponse collective et coordonnée. Faire preuve de leadership et de calme, capables de transformer l'expérience de crise en un levier d'amélioration continue pour l'ensemble de l'organisation.
Comme le souligne Philippe Desforges,

“Un bon manager de crise n'est pas seulement un expert technique, c'est avant tout un leader capable de fédérer ses équipes et de transformer chaque épreuve en une opportunité de progresser.”

A travers ses retours d’expériences, il nous rappelle que la crise, bien qu'imprévisible et éprouvante, est également une occasion de repenser nos méthodes, d'améliorer la coordination entre les équipes et de bâtir des systèmes plus robustes pour l'avenir.

‍