Pourquoi la plupart des logiciels essentiels des banques, assurances, etc sont des logiciels écrits en Cobol ?

 

Pourquoi la plupart des logiciels essentiels des banques, assurances, etc sont des logiciels écrits en Cobol ?

Parce que ces systèmes ont été construits à une époque où COBOL était le langage idéal pour l’informatique de gestion, puis ils sont devenus trop critiques, trop vastes et trop risqués à remplacer brutalement.

COBOL n’est pas là par hasard : il a été conçu dès la fin des années 1950 pour traiter des opérations administratives, financières et comptables à grande échelle. Banques, assurances, administrations, compagnies aériennes et grandes entreprises l’ont massivement adopté pour leurs systèmes de cœur métier.

Pourquoi COBOL s’est imposé

COBOL est très adapté aux traitements de gestion :

• Transactions massives : paiements, virements, retraits, remboursements, primes d’assurance, pensions, salaires.
• Calculs décimaux précis : essentiel pour l’argent, où les erreurs d’arrondi sont inacceptables.
• Traitements batch : clôtures journalières, relevés, calculs d’intérêts, facturation, rapprochements comptables.
• Lisibilité métier : sa syntaxe ressemble davantage à de l’anglais structuré qu’à des langages plus mathématiques.
• Fiabilité : ces programmes ont souvent tourné pendant des décennies, avec des bugs connus, corrigés et maîtrisés.

Un système bancaire central doit privilégier la stabilité plutôt que la nouveauté. Si un langage fait correctement le travail depuis 40 ans, le remplacer juste parce qu’il est ancien n’est pas forcément rationnel.

Pourquoi ils ne les ont pas simplement remplacés

Le vrai sujet n’est pas seulement COBOL, mais tout l’écosystème autour : mainframes, bases de données, fichiers, processus batch, règles métier, interfaces, procédures opérationnelles, conformité, audit, sécurité.

Dans une grande banque ou assurance, un ancien système peut contenir :

Élément	Pourquoi c’est difficile à remplacer
Millions de lignes de code	Personne ne connaît toujours toutes les règles métier implicites
Données historiques	Migration risquée, coûteuse et réglementée
Interfaces nombreuses	Le système parle avec agences, applis web, cartes, reporting, partenaires
Règles métier anciennes	Certaines règles ne sont documentées que dans le code
Disponibilité critique	Une panne peut bloquer paiements, retraits ou sinistres

Réécrire un cœur bancaire ou assurantiel peut coûter des centaines de millions, prendre des années, et introduire de nouveaux bugs dans des fonctions qui marchaient déjà.

Le paradoxe : vieux, mais solide

COBOL est souvent associé à du “vieux code”, mais les systèmes COBOL ne sont pas nécessairement mauvais. Beaucoup sont :

• extrêmement optimisés pour les volumes de transactions ;
• très fiables parce qu’ils ont été testés par des décennies de production ;
• bien adaptés aux traitements de masse ;
• hébergés sur mainframes, qui restent très robustes pour certains usages.

Le problème principal n’est pas que COBOL “ne marche plus”. Le problème est plutôt que :

• il y a moins de développeurs COBOL ;
• l’intégration avec le cloud, les API modernes et les applications mobiles est moins naturelle ;
• la documentation est parfois insuffisante ;
• les coûts de maintenance peuvent devenir élevés ;
• les cycles d’évolution sont souvent plus lents.

Pourquoi les banques modernes utilisent quand même autre chose autour

Aujourd’hui, les banques et assurances ne font pas “tout en COBOL”. Souvent, elles ont une architecture hybride :

Les interfaces modernes, les applis mobiles, les moteurs de recommandation, les parcours client ou les outils analytiques sont souvent écrits en Java, JavaScript, Python, C#, Go, etc. Mais le système de référence - comptes, contrats, soldes, sinistres, historique - peut encore être en COBOL.

Pourquoi une nouvelle banque peut éviter COBOL

Une banque créée aujourd’hui n’est pas obligée d’utiliser COBOL. Elle peut démarrer avec des systèmes modernes, cloud, API-first, microservices, bases relationnelles ou distribuées.

Mais une banque historique n’a pas le même problème : elle ne part pas d’une page blanche. Elle a des décennies de données, de règles, d’audits, d’obligations réglementaires et de dépendances. C’est comme changer les moteurs d’un avion en plein vol.

En résumé

COBOL reste présent dans les banques et assurances parce qu’il est au cœur de systèmes qui sont :

• anciens, mais très fiables ;
• critiques, donc difficiles à modifier ;
• énormes, donc coûteux à réécrire ;
• riches en règles métier, parfois non documentées ailleurs ;
• performants pour les traitements transactionnels et batch.

Le mouvement actuel n’est généralement pas “tout jeter et réécrire”, mais plutôt moderniser progressivement : exposer des API, isoler les vieux composants, migrer certaines fonctions, documenter le code, et remplacer petit à petit ce qui peut l’être sans mettre en danger le système central.

 

Claude (Anthropic) 

 

Minçalors ! même avec une AI/IA on n'y arrive pas !  Dire que nos étudiants d'IUT ont fait des choses  "

anciennes, mais très fiables ;

critiques, donc difficiles à modifier ;

énormes, donc coûteux à réécrire ;

riches en règles métier, parfois non documentées ailleurs (on a jeté les dossiers d'"analyse" des analystes-programmeurs ? ) ;

performants pour les traitements transactionnels et batch.

Mais sans beaux écrans où on cherche où cliquer, avec de l'écriture de couleur noir sur fonds bleu foncé.