893 millions de dollars virés par erreur
En août 2020, Citibank administrait un prêt syndiqué de 1,8 milliard de dollars pour Revlon en tant qu’agent de prêt. Un agent de prêt syndiqué est l’établissement chargé de collecter les paiements d’un emprunteur et de les redistribuer aux différents prêteurs. L’opération du jour était simple: virer 7,8 millions de dollars d’intérêts aux créanciers.
Le virement effectif a été de 893 millions, soit la quasi-totalité du capital qui n’était pas exigible avant 2023. Plusieurs prêteurs ont refusé de restituer les fonds et l’affaire a été portée devant les tribunaux. Citibank a perdu environ 500 millions de dollars avant que la Cour d’appel du Second Circuit ne rétablisse partiellement la situation en 2022.
Comment une institution bancaire de premier rang peut-elle commettre une erreur de cette ampleur sur une opération de routine? La réponse ne tient pas à une défaillance individuelle mais à un enchaînement de contrôles qui ont tous échoué de la même façon.
Le piège d’une interface mal comprise
Le logiciel utilisé était Flexcube, un système bancaire développé par Oracle. Pour virer uniquement les intérêts sans toucher au principal, l’opérateur devait cocher trois cases distinctes (FRONT, FUND et PRINCIPAL) afin de rediriger le montant du capital vers un compte de transit interne. Ce compte de transit, appelé wash account dans le jargon bancaire, est un compte tampon qui empêche les fonds de quitter l’institution. En cochant les trois cases, l’opérateur signalait au système que le principal devait rester en interne et que seuls les intérêts devaient être virés aux prêteurs.
Les opérateurs, employés du sous-traitant Wipro basés en Inde, ont coché une seule case: PRINCIPAL. Leur compréhension de l’interface était identique et erronée. La documentation Flexcube existait, mais personne ne l’avait consultée pour cette opération spécifique. L’erreur n’était pas un oubli de débutant: c’était une interprétation logique mais fausse d’une interface dont la logique interne ne correspondait pas à l’intuition des utilisateurs.
Quand les trois niveaux de contrôle partagent le même angle mort
L’opération suivait une procédure dite “six eyes”: trois personnes distinctes, l’opérateur initial (maker), un vérificateur (checker) et un approbateur (approver), devaient chacune valider la transaction avant son exécution. Ce type de contrôle séquentiel est un standard dans les opérations bancaires à fort enjeu financier.
Les trois ont approuvé. Le mécanisme censé détecter l’erreur a fonctionné exactement comme prévu sur le plan procédural: chaque personne a examiné la transaction et l’a validée. Le problème est que toutes les trois se sont trompées de la même manière. Elles partageaient la même compréhension erronée de l’interface, les mêmes habitudes de travail, la même absence de formation sur ce cas-limite.
James Reason, professeur de psychologie à l’Université de Manchester, a formalisé ce phénomène dans son modèle du gruyère (Swiss cheese model): chaque couche de défense dans un système comporte des failles, comme les trous dans une tranche de gruyère. En temps normal, les trous ne sont pas alignés et une couche compense la faiblesse d’une autre. L’accident survient quand les trous s’alignent parfaitement, ce qui permet à l’erreur de traverser toutes les couches sans être interceptée.
Chez Citibank, l’alignement était presque inévitable. Les trois vérificateurs travaillaient dans le même environnement, utilisaient le même outil, avaient reçu la même formation (ou plutôt la même absence de formation) sur le cas Revlon. Le contrôle multipliait les regards sans diversifier les perspectives. C’est la leçon centrale de cet incident: un processus de validation ne protège que contre les erreurs qu’au moins un des vérificateurs est capable de détecter.
La diversité des contrôles, pas leur nombre
La tentation naturelle après un incident de ce type est d’ajouter des étapes de validation supplémentaires, ce qui est souvent contre-productif. Quatre ou cinq niveaux d’approbation où chaque personne regarde les mêmes champs avec le même cadre mental ne font qu’allonger le délai sans améliorer la détection.
Ce qui manquait dans le processus de Citibank n’était pas un quatrième regard humain mais un regard de nature différente. Un contrôle automatisé comparant le montant saisi au montant attendu aurait suffi. Un seuil d’alerte sur les transactions dépassant un certain pourcentage du principal aurait déclenché une vérification supplémentaire. Un simple message de confirmation affichant en clair “Vous êtes sur le point de virer 893 millions de dollars” aurait probablement arrêté l’opération.
Ces mécanismes relèvent de ce que le Lean Manufacturing appelle le poka-yoke, un terme japonais désignant un dispositif qui rend une erreur impossible à commettre ou immédiatement détectable. Le concept, développé par Shigeo Shingo dans les années 1960 pour le système de production Toyota, s’applique bien au-delà de l’industrie: toute procédure critique devrait intégrer au moins un contrôle qui ne dépend pas du jugement humain.
Ce que le chef de projet peut en retenir
Un chef de projet ne conçoit pas des interfaces bancaires, mais il conçoit des processus de validation pour des livrables, des budgets, des passages de phase. Le cas Citibank pose une question directe: vos contrôles détectent-ils réellement les erreurs probables, ou se contentent-ils de multiplier les signatures?
Clifford Rossi, ancien cadre de Citibank et professeur à la Robert H. Smith School of Business de l’Université du Maryland, souligne dans son analyse du cas que la défaillance n’était pas imprévisible. Le risque lié à Flexcube était documenté. Citibank avait même planifié une migration vers un autre système, Finastra Loan IQ. La migration était en cours mais n’avait pas encore couvert le portefeuille Revlon au moment de l’incident.
Dans un projet, le registre des risques remplit cette fonction: identifier les vulnérabilités connues et s’assurer que les mesures de mitigation sont en place avant que le risque ne se matérialise. Quand un risque est identifié mais que la réponse est différée, le chef de projet doit s’assurer que des contrôles compensatoires existent dans l’intervalle. “La migration est prévue pour le trimestre prochain” n’est pas une mesure de mitigation si le risque est actif aujourd’hui.
L’American Society for Quality (ASQ) propose des ressources détaillées sur l’application du poka-yoke aux processus. Le principe est transposable: pour chaque point de contrôle critique dans un projet, se demander ce qui se passe si le vérificateur commet exactement la même erreur que l’exécutant. Si la réponse est “rien ne l’empêche”, le contrôle est insuffisant.