L’IA progresse sur COBOL. Le score de traduction ne résume pas une migration
OpenAI progresse dans ses tests de migration COBOL. Méthode, scores d’éditeur et réserves des spécialistes sur les systèmes réels.
Traduire un programme COBOL et remplacer un système critique ne représentent pas le même résultat. Une enquête de The Verge publiée le 26 octobre confronte les avancées annoncées par OpenAI aux difficultés de la modernisation. Le débat porte sur la portée des évaluations. Il ne faut pas confondre leur réussite avec une migration complète déjà démontrée.
Deux exercices annoncés par OpenAI le 19 octobre
Dans sa publication originale, OpenAI présente MultiLangBench et une évaluation de migration COBOL. Le premier exercice demande de construire un moteur compatible avec SQLite dans plusieurs langages. Le second demande de traduire des programmes COBOL vers un langage moderne. Les deux exercices n’évaluent donc pas la même opération.
Pour la migration, les tests contrôlent une égalité des sorties observables octet par octet. Tous doivent réussir pour qu’un cas soit considéré comme réussi. OpenAI annonce 86,6 % pour GPT-6.1 Sol avec un faible effort de raisonnement. Le résultat atteint 97,9 % à un effort supérieur. Ce sont des mesures publiées par le fournisseur sur son évaluation, pas une reproduction indépendante. À faible effort, OpenAI annonce aussi un coût API inférieur de 39 % à celui de GPT-5.6 Sol dans cet exercice.
Un programme peut fonctionner et calculer autrement
OpenAI prend l’exemple des décimales. En COBOL, certains calculs éliminent les chiffres excédentaires si aucun arrondi n’est demandé. Une traduction qui les arrondit peut s’exécuter sans erreur tout en changeant le résultat financier. Cet exemple montre pourquoi la présence d’un code compilable ne constitue pas à elle seule une preuve d’équivalence.
Les dépendances dépassent le texte du programme
Les spécialistes interrogés par The Verge examinent un autre périmètre. Vadim Zaytsev explique qu’un système comprend aussi des données et des interactions avec d’autres logiciels. Les attentes des utilisateurs interviennent également. Arie van Deursen souligne la difficulté de découper un ensemble complexe en éléments que l’on peut remplacer séparément. Ces observations portent sur les limites d’une extrapolation vers la production.
Le reportage rapporte aussi une réponse d’OpenAI reconnaissant que les langages anciens restent un problème loin d’être résolu. Les réserves ne signifient donc pas qu’un résultat de test n’apporte aucun progrès. Elles demandent de préciser ce qui a été réussi et ce qui reste hors de l’exercice. Un score élevé peut coexister avec des questions importantes sur l’intégration.
La modernisation commence aussi par la compréhension
Dans un guide publié le 23 février, Anthropic présente Claude Code comme une aide à l’exploration des systèmes anciens. Le fournisseur décrit la cartographie des dépendances et la documentation des flux. Il propose de procéder par composants avec une validation continue et une supervision des spécialistes. Cette démarche constitue une proposition de méthode du fournisseur. Elle n’apporte pas un score directement comparable à celui de l’évaluation OpenAI.
Déplacer un logiciel sans changer son langage et le réécrire répondent à des objectifs différents. Définir le changement recherché permet de choisir les vérifications utiles. Une traduction peut préserver un ensemble de sorties testées tout en laissant ouvertes des questions de performance ou d’exploitation. Ces questions doivent rester visibles au moment d’interpréter une démonstration.
Lire le score à la bonne échelle
Le point décisif est le périmètre de la preuve. Il faut savoir quel programme a été traduit et quels comportements ont été vérifiés. Une progression sur un exercice bien défini mérite d’être suivie. Elle ne fournit pas automatiquement une garantie pour tous les systèmes écrits dans le même langage. Les écarts les plus rares peuvent compter lorsque les opérations concernées sont critiques.
Notre article sur les gains de temps et la relecture dans l’open source revient sur une autre frontière entre une tâche et son résultat collectif. Je retiens ici la valeur d’une preuve précisément délimitée. Savoir traduire davantage de code est utile. Savoir ce qui reste à vérifier permet de comprendre jusqu’où ce progrès peut être employé.