COBOL et IA : moderniser un logiciel ne consiste pas seulement à changer de langage
OpenAI publie de nouveaux tests sur des langages peu représentés dans les données d’apprentissage. Les résultats interrogent surtout la capacité à préserver les règles d’un logiciel ancien, au-delà d’une démonstration de génération de code.
Prêt à lire l’article.
Dans cet article
Le 19 octobre, OpenAI a présenté deux évaluations consacrées aux langages de programmation disposant de moins de ressources d’apprentissage. MultiLangBench demande de construire un moteur compatible avec SQLite dans vingt langages. Une seconde épreuve porte sur la migration de programmes COBOL en conservant leur comportement.
L’entreprise rapporte une moyenne de 87,4 % de tests réussis pour GPT‑6 Astra sur MultiLangBench. Pour l’évaluation COBOL, elle annonce jusqu’à 97,9 % avec GPT‑6.1 Sol à un niveau de raisonnement élevé. Ce sont des résultats obtenus dans les dispositifs décrits par leur concepteur, pas le taux de réussite garanti d’une migration en entreprise.
OpenAI précise elle-même que le passage en production exige une revue experte et des tests adaptés aux règles et dépendances du système. Cette limite est aussi importante que les scores.
Notre analyse : préserver une règle parfois invisible
Une application ancienne peut contenir des décisions métier que ses utilisateurs ne formulent plus. Une manière de calculer, de classer ou de traiter une exception peut sembler accessoire dans le code tout en étant essentielle au service rendu. Une réécriture élégante pourrait donc modifier le résultat sans provoquer de panne visible.
Pour cette raison, nous proposons de lire les nouveaux scores comme une indication de capacité, non comme un ordre de remplacement. Avant toute transformation, une organisation devrait identifier ce qu’elle attend réellement : faciliter la maintenance, documenter une fonction, réduire un risque ou changer d’environnement technique.
Un premier projet limité pourrait consister à expliquer un module et à produire des cas de test, sans modifier le programme exploité. L’équipe comparerait ensuite ces explications avec les connaissances de ses spécialistes. Cette étape servirait à découvrir les incompréhensions de l’assistant avant de lui confier une modification plus importante.
Mesurer les différences plutôt que la quantité de code
Notre grille de contrôle comporte un point central : comparer les résultats sur des situations représentatives, y compris les exceptions. Le programme nouveau et l’ancien devraient être examinés sur le même périmètre. Une réussite sur quelques exemples faciles ne suffirait pas à établir que toutes les règles ont été préservées.
Il faudrait aussi prévoir la possibilité de revenir en arrière. Le plan de migration devrait préciser les validations attendues, les responsables et les conditions d’arrêt. Une correction générée rapidement n’a de valeur que si son effet est compris. Cette recommandation s’applique à l’organisation du projet ; elle ne constitue pas une procédure technique universelle.
Pour des banques, administrations ou entreprises africaines, le sujet ouvre une piste : utiliser l’IA pour rendre leur patrimoine logiciel plus lisible. Mais la maîtrise des données et des règles locales resterait déterminante. Copier une démonstration étrangère sans reconstituer ce contexte ferait perdre précisément ce que l’on cherche à conserver.
Le progrès annoncé est donc intéressant parce qu’il élargit les possibilités de travail sur l’existant. La décision de migrer, elle, devrait toujours reposer sur des preuves propres au système concerné.
Source
OpenAI — langages de programmation à faibles ressources, 19 octobre 2026. Tests annoncés par leur concepteur, consultés le 23 octobre ; aucune migration réelle évaluée par MIND AI MEDIA.