COBOL n’est pas le problème : l’IA révèle la mémoire oubliée des banques

Et si le plus difficile, pour faire abandonner COBOL à une banque, n’était pas de comprendre COBOL ? Les derniers résultats d’OpenAI donnent à penser que la barrière syntaxique est enfin en train de devenir négociable. La conclusion la plus dérangeante, c’est que le véritable héritage des banques n’est pas un langage de programmation. C’est un ensemble de décisions, d’exceptions et de connaissances institutionnelles jamais documentées, enfouies dans des logiciels que plus personne ne sait expliquer sans prendre de risques.

OpenAI affirme que ses modèles peuvent migrer des programmes COBOL existants vers C++, Java, Kotlin, Python ou Rust tout en préservant leur comportement. Dans l’évaluation de migration COBOL de l’entreprise, GPT-6.1 Sol atteint une précision de 86,6 % avec un faible niveau de raisonnement, et de 97,9 % avec un niveau supérieur. Comme le rapporte Engadget, une migration n’est considérée comme réussie que lorsque tous les tests passent. C’est un résultat impressionnant, et un avertissement utile contre l’idée d’y voir un feu vert pour les systèmes bancaires en production.

L’IA progresse en traduction, pas dans la définition de ce qui est « correct »

Le point fort du travail d’OpenAI, c’est qu’il ne définit pas la migration comme le simple fait que « le nouveau code compile ». L’entreprise vérifie que le programme réécrit se comporte comme l’original, y compris dans des détails faciles à manquer lors d’une traduction superficielle. L’arithmétique en virgule fixe de COBOL, par exemple, supprime les chiffres décimaux excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit à la place peut fonctionner parfaitement tout en produisant des résultats financiers différents.

Cette distinction compte, car le code ancien est souvent une archive des politiques métier. Une ligne qui paraît maladroite ou obsolète peut coder la manière dont un système gère un enregistrement manquant, un montant fractionnaire ou un état inhabituel d’une transaction. Dans ce contexte, l’IA est utile non parce qu’elle modernise le code, mais parce qu’elle peut contribuer à révéler et à reproduire un comportement que les ingénieurs ne peuvent pas se permettre de réinterpréter à la légère.

Cela dit, un modèle ne peut préserver que le comportement représenté par son évaluation. Le test d’OpenAI utilise des cas cachés et vérifie une correspondance octet par octet des résultats observables. Une véritable institution doit établir si ces résultats sont eux-mêmes ceux qui sont souhaités. Si une règle a été créée il y a plusieurs décennies, recopiée dans plusieurs systèmes et jamais documentée, « correspondre à l’ancien système » peut préserver une erreur avec autant de fidélité qu’une exigence.

Le résultat le plus important de l’évaluation, c’est l’écart qui subsiste

L’évaluation MultiLangBench, plus large, demande aux modèles de construire un moteur de base de données compatible avec SQLite dans 20 langages. GPT-6 Astra atteint un taux moyen de réussite aux tests de 87,4 %, contre 26,8 % pour GPT-5.6 Sol. Pourtant, COBOL reste le langage le plus difficile de l’évaluation, avec 72,1 % pour Astra. La publication d’OpenAI présente ce résultat comme un progrès, et c’en est un. Mais elle montre aussi pourquoi « l’IA sait coder en COBOL » est une affirmation bien plus limitée que « l’IA peut moderniser une banque ».

Un benchmark de moteur de base de données fournit au modèle un objectif défini et un dispositif de test objectif. Une banque, elle, a autour de ses programmes des moniteurs de transactions, des calendriers de traitements par lots, des magasins de données, des interfaces et des dépendances opérationnelles. Les travaux fournis n’établissent pas que ces systèmes environnants ont été migrés, et ne montrent pas non plus qu’un modèle peut découvrir de manière autonome toutes les dépendances importantes.

C’est ici que le discours commercial devient moins intéressant que le diagnostic organisationnel. OpenAI explique que la documentation peut être incomplète, que les développeurs d’origine peuvent être partis et que des règles métier importantes peuvent n’exister que dans le code. Ce ne sont pas seulement des obstacles pour un assistant d’IA. Ce sont les signes que l’institution a laissé ses connaissances devenir indissociables d’un artefact exécutable.

La ressource rare sera constituée par les tests, pas par le code généré

La phrase la plus lourde de conséquences dans cette histoire n’est pas le score de 97,9 %. C’est la condition qui le sous-tend: tous les tests doivent passer. Cette exigence transforme la migration en une question de preuves. Quels cas faut-il tester ? Quels résultats ont une importance juridique ou financière ? Quelles exceptions étaient intentionnelles, et lesquelles sont des accidents que personne n’a osé supprimer ?

Nous pensons que les banques dotées de solides suites de tests de régression tireront le meilleur parti de la migration assistée par l’IA. Elles pourront utiliser des modèles pour traduire le code, expliquer le flux de contrôle, proposer de la documentation et générer des implémentations candidates, tandis que leurs tests existants fixeront les limites du comportement acceptable. Les institutions dont les tests sont faibles s’exposent à une perspective plus dangereuse: une réécriture rapide et bien présentée, qui passe les vérifications limitées disponibles et modifie silencieusement les cas que personne n’a consignés.

L’IA ressemble donc moins à un remplacement de l’expertise COBOL qu’à un test de résistance de la rigueur des équipes d’ingénierie. Un modèle peut réduire le coût de production des solutions alternatives. Il ne peut pas, à lui seul, attribuer la responsabilité d’une modification du calcul des intérêts ni prouver qu’une exception non documentée pouvait être supprimée sans danger. OpenAI affirme explicitement que l’utilisation en production exige toujours une revue par des experts ainsi que des tests au regard des règles métier et des dépendances; cette réserve devrait être le titre de l’article plutôt qu’une note de bas de page.

COBOL pourrait devenir un atout plutôt qu’un stigmate

La tentation est grande de présenter COBOL comme un poids mort attendant qu’un langage moderne vienne le sauver. Cette vision est trop commode. COBOL conserve sa valeur précisément parce qu’il exprime des systèmes qui ont survécu à des années d’utilisation dans le monde réel. Le problème n’est pas que le langage soit ancien; c’est que les connaissances qui l’entourent n’ont pas été rendues transférables.

L’IA pourrait contribuer à changer cet équilibre. Utilisée avec prudence, elle peut transformer des procédures opaques en explications lisibles, repérer la logique répétée, cartographier le comportement entre différentes versions et créer des cas de test à examiner. Dans ce rôle, elle tient davantage de l’outil archéologique que de l’ingénieur autonome de remplacement: utile pour reconstituer une structure, dangereuse si on l’autorise à déclarer les fouilles terminées.

Les gagnantes ne seront pas les banques qui se précipiteront pour supprimer COBOL. Ce seront celles qui profiteront des projets de migration pour capturer les règles actuellement piégées dans ce langage. Notre verdict est simple: considérez les résultats d’OpenAI comme la preuve que la traduction devient moins coûteuse, et non comme la preuve que la modernisation est réglée. Avant de déplacer une seule ligne de code critique, construisez les tests, documentez les exceptions et nommez les humains responsables du résultat. L’avenir des logiciels bancaires sera peut-être écrit en Python ou en Rust, mais leur fiabilité restera une réussite sociale et institutionnelle, pas une simple conversion syntaxique.