Systèmes informatiques des banques : pourquoi le COBOL ne disparaît pas
Les systèmes informatiques des banques s’appuient sur des millions de lignes de COBOL que plus personne ne maîtrise entièrement — un langage de programmation conçu en 1959, avant que l’homme ne marche sur la Lune. Pendant que vous payez sans contact avec votre téléphone, que vous virez de l’argent en quelques secondes depuis une app au design soigné, les systèmes qui traitent réellement ces transactions tournent sur du code écrit avant que l’homme ne marche sur la Lune. Le secteur bancaire mondial repose en grande partie sur le COBOL — Common Business Oriented Language — un langage de programmation conçu en 1959 par Grace Hopper, une informaticienne de la marine américaine, à une époque où les données étaient stockées sur des cartes perforées. Soixante-cinq ans plus tard, il fait encore tourner les grandes banques mondiales. Et la question n’est plus de savoir si ce modèle va craquer — mais quand.
Ce que le COBOL fait — et pourquoi personne ne l’a encore remplacé
Le COBOL n’a pas survécu soixante-cinq ans par accident. Il a été conçu spécifiquement pour traiter des volumes massifs de données financières avec une fiabilité maximale. Gestion des comptes, calcul des intérêts, traitement des salaires, virements : les opérations de base d’une banque sont exactement ce pour quoi ce langage a été taillé. Il traite aujourd’hui encore environ 95 milliards de transactions commerciales par jour dans le monde, et on estime qu’il existe davantage de lignes de code COBOL actives que de lignes de code écrites dans n’importe quel autre langage.
Le problème, ce n’est pas le langage lui-même. C’est l’accumulation. Chaque grande banque s’est retrouvée, au fil des décennies, à empiler des milliers de programmes interconnectés, modifiés par des générations de développeurs différents, souvent sans documentation à jour. Migrer un tel système vers une architecture moderne ne prend pas quelques mois — cela prend dix à quinze ans, coûte des centaines de millions d’euros, et comporte un risque opérationnel que peu de directions informatiques sont prêtes à assumer. Comme l’a formulé crûment un expert dans les colonnes du Monde Informatique : « il faut un courageux directeur de la technologie pour envisager cela ».
Résultat : personne ne bouge. Et les systèmes vieillissent.
Le problème qui s’aggrave : les développeurs partent à la retraite
Le COBOL serait un problème gérable si des milliers de développeurs maîtrisaient encore ce langage. Ce n’est plus le cas. Les ingénieurs formés dans les années 1970 et 1980 sont en fin de carrière ou déjà partis. 68 % des développeurs COBOL étaient attendus à la retraite d’ici 2025. Malheureusement, les universités n’enseignent plus ce langage — il n’y a pas de filière qui forme de nouveaux talents sur une technologie perçue comme morte, même si elle fait encore tourner les plus grands systèmes financiers du monde.
Les banques se retrouvent dans une situation absurde : elles font tourner du code que leurs propres ingénieurs ne comprennent plus entièrement. Personne ne sait avec certitude ce que font certains modules vieux de quarante ans, ni quel sera l’effet de bord d’une modification sur les systèmes en aval. Des rapports sectoriels de 2025 documentent ce phénomène : des banques modifient du code sans comprendre sa fonction complète, et s’exposent à des risques opérationnels qu’elles ne peuvent pas vraiment quantifier. En parallèle, les quelques spécialistes COBOL encore disponibles sur le marché se négocient à des tarifs exorbitants — certains consultants seniors facturent plus de 500 euros de l’heure pour maintenir des systèmes que plus personne d’autre ne sait toucher.
Il y a un autre horizon que personne n’aime mentionner : en 2049, un nouveau bug similaire à celui de l’an 2000 pourrait se produire. Le timestamp utilisé dans certains systèmes COBOL repassera à zéro, menaçant une nouvelle fois les infrastructures financières mondiales. De fait, les banques devront à nouveau investir des milliards pour corriger le problème — sans pour autant abandonner le langage.
Les grandes pannes qui ont tout révélé
Chaque grande panne bancaire révèle la fragilité des systèmes informatiques COBOL encore en production. L’état des systèmes legacy bancaires ne resterait qu’un sujet de spécialistes si ses conséquences restaient invisibles. Elles ne le sont pas. Voici les épisodes les plus marquants — et les plus coûteux.
RBS, 2012. La Royal Bank of Scotland connaît une panne majeure due à un bug dans un logiciel de planification de traitements batch — exactement le type d’architecture qui équipe les systèmes COBOL. 6,5 millions de clients se retrouvent sans accès à leurs comptes pendant plusieurs jours. Des salaires ne sont pas versés, des paiements hypothécaires sont bloqués. La banque est condamnée à une amende de 56 millions de livres sterling par les régulateurs britanniques.
RBS encore, 2015. Trois ans après, rebelote. 600 000 paiements échouent à entrer dans les comptes des bénéficiaires overnight — dont des salaires et des aides sociales. La banque invoque un « défaut technique » sans entrer dans les détails. Ces incidents répétés finissent par éroder durablement la confiance des clients.
TSB, 2018. La catastrophe de référence. Banco Sabadell, qui venait de racheter TSB, décide de migrer les données de la banque britannique vers sa propre plateforme informatique. La migration est précipitée, les tests insuffisants. Dès le basculement, des centaines de milliers de clients ne peuvent plus accéder à leurs comptes en ligne — pendant plusieurs semaines. Certains voient les transactions d’autres clients apparaître sur leurs relevés. 1 300 clients sont victimes d’attaques frauduleuses dans la foulée, des escrocs ayant profité de la confusion. La crise coûte à Sabadell plusieurs centaines de millions de livres, 80 000 clients perdus, et la tête de son PDG. Le Financial Times a qualifié cet épisode de « plus grande catastrophe informatique de l’histoire bancaire britannique ». C’est aussi l’événement qui, depuis, dissuade les autres banques de tenter des migrations de grande ampleur.
CrowdStrike, juillet 2024. Celui-là n’est pas directement lié au COBOL, mais il illustre la fragilité systémique du secteur. Une mise à jour défectueuse du logiciel de cybersécurité CrowdStrike déclenche un écran bleu de la mort sur des millions de machines Windows dans le monde. JPMorgan Chase, Bank of America et Wells Fargo sont touchées simultanément. Des clients ne peuvent plus se connecter, des transferts sont bloqués, les activités de trading de JPMorgan subissent des retards. L’action de CrowdStrike chute de 11 % dans la journée.
Lloyds, Halifax et Bank of Scotland, mars 2026. Le plus récent, et peut-être le plus inquiétant par ce qu’il révèle. Le 12 mars 2026, des clients des trois banques ouvrent leur application mobile le matin et voient… les transactions d’autres clients apparaître sur leur relevé. Certains ont accès aux comptes de parfaits inconnus. Downdetector enregistre une explosion des signalements entre 7h00 et 9h00. Martin Lewis, le célèbre expert en finances personnelles britannique, reçoit près de 3 000 témoignages en quelques heures via sa page Facebook. Lloyds Banking Group affirme avoir résolu le problème rapidement, sans en préciser la cause. Les actions du groupe chutent de 3,4 % dans la journée.
Crédit Mutuel et CIC, France. Une panne informatique frappe en fin d’après-midi un samedi, bloquant les paiements et les retraits de millions de clients du Crédit Mutuel, du CIC et de Monabanq pendant plus de deux heures. Clients bloqués aux caisses de supermarché, paiements refusés, impossibilité de retirer du liquide : le scénario, banal à force d’être répété, continue de surprendre à chaque occurrence.
La modernisation : possible, mais rare
La modernisation des systèmes informatiques bancaires coûte des centaines de millions et prend dix à quinze ans. Cependant, quelques banques ont réussi des transitions sans catastrophe industrielle — mais en prenant le temps qu’il fallait. ING a entamé une migration progressive vers des architectures cloud en conservant le COBOL comme couche de traitement centrale, en y greffant des API modernes pour exposer les données vers les interfaces numériques. DBS Bank à Singapour est souvent citée comme la référence mondiale : la banque a reconstruit ses systèmes core banking sur plusieurs années, en parallèle de l’existant, sans jamais couper le service. ING et BBVA ont suivi des chemins similaires, avec des budgets de transformation qui se comptent en milliards.
Ce que ces succès ont en commun : une direction exécutive qui a traité la modernisation informatique comme une priorité stratégique sur cinq à dix ans, pas comme un projet IT à gérer entre deux trimestres. Et une acceptation du fait que le coût de la transformation, aussi élevé soit-il, est inférieur au coût cumulé des pannes, des amendes réglementaires et de l’érosion de la confiance client.
McKinsey estime que seulement 30 % des banques ont réussi à mettre en œuvre leur stratégie numérique de manière satisfaisante. Les 70 % restantes continuent d’avancer avec des rustines sur des infrastructures que leurs propres équipes ne maîtrisent plus entièrement.
Ce que ça dit de nous
Il y a une ironie profonde dans la situation. Le secteur le plus régulé du monde, celui auquel on fait confiance pour garder notre argent, faire tourner les économies nationales et financer les entreprises, repose sur une technologie que les nouvelles générations de développeurs n’apprennent plus. Pendant ce temps, les néobanques comme Revolut, N26 ou Neon — pour citer un exemple suisse — construisent leurs systèmes sur des architectures cloud modernes, dès le premier jour, sans héritage à gérer. Elles peuvent déployer de nouvelles fonctionnalités en jours là où une grande banque traditionnelle met des mois.
En conclusion, la vraie question n’est pas « le COBOL va-t-il céder ? » — il cédera, un jour, parce que la pénurie de compétences y contraindra les banques. La vraie question est : à quel prix, et pour qui ? Chaque panne bancaire a des victimes concrètes — des gens qui ne peuvent pas payer leurs factures, des entreprises qui ratent des échéances, des clients âgés qui n’ont plus accès à leur épargne un samedi après-midi. Ce ne sont pas des bugs. Ce sont les symptômes d’une dette technologique que des décennies de report ont transformée en bombe à retardement.
Une fragilité systémique qui n’est pas sans rappeler les questions que pose l’essor des agents IA autonomes — quand des systèmes critiques vieillissants doivent composer avec des technologies qui évoluent à toute vitesse.
Article rédigé le 27 mars 2026 par Adrien Hassler, passionné d’astronomie, d’IA et de nouvelles technologies, et créateur d’AdrienTech.com
