Accueil › Glossaire › Code Translation IA

Code Translation IA (Traduction de Code par Intelligence Artificielle)

La code translation IA (traduction de code, transpilation assistée par IA) est l’utilisation de modèles de langage (LLM, code LLM) pour convertir automatiquement du code source d’un langage de programmation vers un autre, en préservant la logique métier, l’intégrité algorithmique et le comportement fonctionnel du programme original.

Réécrire manuellement une application de COBOL vers Java, de Python 2 vers Python 3, ou de Java vers Kotlin est un processus lent, coûteux et sujet aux bugs. La traduction de code IA accélère ce processus de manière spectaculaire. Mais traduire du code n’est pas comme traduire du texte : un programme « syntaxiquement correct » dans le langage cible peut avoir un comportement complètement différent si les idiomes, les conventions et les subtilités du langage cible ne sont pas respectés. C’est cette nuance qui fait toute la complexité du domaine.

Comment fonctionne la traduction de code IA

L’approche traditionnelle : transpileurs à règles

Avant l’IA, la traduction de code se faisait par des transpileurs (transcompilateurs) basés sur des règles syntaxiques. Le processus : parser le code source en arbre syntaxique abstrait (AST), appliquer des règles de transformation écrites manuellement, puis générer le code dans le langage cible. Les limitations étaient sévères : cela nécessitait une expertise approfondie des deux langages, la gestion des types entre langages dynamiques et statiques était souvent impossible, et le code résultant était rarement idiomatique (il « sentait » encore le langage source).

L’approche par LLM

Les code LLM transforment la traduction de code en un problème de compréhension sémantique plutôt que de transformation syntaxique. Le modèle ne convertit pas des tokens d’un langage vers l’autre. Il comprend ce que le code fait, puis le réécrit dans le langage cible en utilisant les idiomes, patterns et bibliothèques standards de ce langage.

Le processus typique avec un LLM :

Analyse et compréhension. Le modèle lit le code source, identifie les structures (fonctions, classes, boucles), comprend la logique métier et les dépendances. Avec des fenêtres de contexte de 128K à 1M+ tokens, les modèles modernes peuvent ingérer des fichiers volumineux ou des modules entiers.

Traduction idiomatique. Le modèle génère le code dans le langage cible en utilisant les conventions propres à ce langage. Un for...in Python devient un forEach en JavaScript, un struct Go avec méthodes plutôt qu’une classe Java, etc. Le code résultant est lisible et maintenable, pas une translittération mécanique.

Préservation de la logique métier. Le défi principal. Le modèle doit conserver le comportement exact du programme original, y compris les cas limites, la gestion d’erreurs et les effets de bord. C’est ici que les LLM font des erreurs subtiles, surtout sur les types numériques (précision flottante, overflow), les conventions de null/None/nil, et la gestion de la concurrence.

Les modèles spécialisés : TransCoder et Granite

Au-delà des LLM généraux, des modèles spécialisés ont été développés pour la traduction de code. Facebook AI (Meta) a publié TransCoder en 2020, un modèle entraîné par apprentissage auto-supervisé sur des corpus de code non appariés (pas besoin de paires source-cible). TransCoder traduit entre C++, Java et Python avec une précision de traduction computationnelle significative.

IBM a développé un modèle Granite de 20 milliards de paramètres, entraîné sur 1,6 trillion de tokens de code, puis affiné sur des milliers de paires de programmes COBOL-Java d’entreprise. Ce modèle alimente watsonx Code Assistant for Z, spécifiquement conçu pour la modernisation COBOL vers Java optimisé pour les mainframes IBM Z.

Le cas COBOL : l’événement de février 2026

La modernisation COBOL est le cas d’usage le plus médiatisé et le plus stratégiquement important de la traduction de code IA. Et février 2026 a marqué un tournant.

Le contexte

COBOL, créé dans les années 1950, traite encore 95% des transactions ATM aux États-Unis. Plus de 220 milliards de lignes de COBOL tournent en production quotidiennement dans la banque, les compagnies aériennes et les administrations publiques. Plus de 43% des systèmes bancaires mondiaux reposent sur COBOL. Les 10 systèmes legacy fédéraux américains les plus urgents à moderniser coûtent 337 millions de dollars par an en maintenance, consommant environ 80% du budget IT de ces agences.

Le problème : les développeurs COBOL prennent leur retraite (10% de l’effectif chaque année) et emmènent avec eux des décennies de connaissance non documentée. Réécrire manuellement est prohibitif : un projet de modernisation COBOL typique prend des années et coûte des dizaines de millions de dollars.

L’annonce d’Anthropic

Le 23 février 2026, Anthropic publie un blog technique détaillant comment Claude Code peut accélérer la modernisation COBOL. L’outil lit, interprète et traduit des programmes COBOL en Java, Python et Go, en préservant la logique métier, en gérant les dépendances copybook, et en générant des tests unitaires pour le code traduit. Anthropic affirme que des équipes peuvent désormais moderniser des bases COBOL en trimestres plutôt qu’en années.

L’impact boursier est immédiat : l’action IBM chute de 13% en une séance, sa pire journée depuis 2000. Accenture et Cognizant chutent aussi. Bloomberg rapporte un déclin de 27% en février pour IBM, le pire mois depuis au moins 1968. Les analystes de Morgan Stanley estiment que les services liés à COBOL représentent 5 à 7 milliards de dollars de revenus annuels pour IBM.

La réponse d’IBM

IBM contre-attaque immédiatement. Rob Thomas (SVP et Chief Commercial Officer) distingue clairement traduction de code et modernisation de plateforme : « Traduire du code est une chose. Moderniser une plateforme est tout autre chose. L’écart entre les deux est l’endroit où la plupart des entreprises rencontrent des problèmes. » IBM pointe vers watsonx Code Assistant for Z, lancé dès 2023, qui inclut l’analyse d’applications, le mapping de dépendances, le refactoring automatisé et la validation. Le PDG Arvind Krishna avait déclaré en juillet 2025 que l’outil avait « une adoption très large ».

La National Organisation for Social Insurance rapporte une réduction de 94% du temps d’analyse du code COBOL legacy avec watsonx (une tâche de 8 heures réduite à 30 minutes). Royal Bank of Canada utilise l’outil pour cartographier les dépendances et construire des plans de modernisation.

IBM annonce aussi Project Bob, un IDE IA construit sur VS Code avec une architecture multi-modèles (Claude, Mistral, Llama, Granite), qui remplacera watsonx Code Assistant for i et couvrira COBOL, RPG, CL, SQL, Java et Python.

Les outils de traduction de code IA

LLM généraux (Claude, GPT, Gemini)

Les LLM de pointe (Claude Opus 4.6, GPT-5.4, Gemini) sont les traducteurs de code les plus polyvalents. Ils gèrent des centaines de langages, comprennent le contexte, et produisent du code idiomatique. Claude Code, en mode agentique, peut naviguer un projet entier, analyser les dépendances et traduire fichier par fichier. L’avantage : flexibilité maximale, pas besoin d’outil dédié. La limite : pas de garantie de préservation comportementale sans tests exhaustifs.

IBM watsonx Code Assistant for Z

L’outil spécialisé de référence pour la modernisation COBOL → Java. Basé sur un modèle Granite de 20B paramètres affiné sur des paires COBOL-Java d’entreprise. Nommé Leader dans le MarketScape IDC 2025-2026 des assistants de code IA. Inclut l’analyse d’applications, le mapping de dépendances, le refactoring automatisé, et la validation. Le code Java résultant est optimisé pour interopérer avec CICS, IMS, DB2 et les runtimes z/OS.

CodeConvert AI / AI Code Converter

Outils web gratuits ou freemium pour la traduction rapide de snippets de code entre langages. Simples d’utilisation (coller le code, choisir le langage cible, cliquer). Adaptés pour des conversions ponctuelles de fonctions individuelles, pas pour des projets complets. CodeConvert AI supporte Python, JavaScript, Java, C++, Go, Rust, TypeScript et bien d’autres.

IDE et agents de code

Cursor, Claude Code, GitHub Copilot et Qwen Code peuvent tous traduire du code à la demande. Sélectionnez un fichier, demandez « traduis ce fichier Python en TypeScript », et l’agent produit la traduction. Pour les projets multi-fichiers, les agents agentiques (Claude Code, Codex CLI) peuvent naviguer le projet, identifier les fichiers à traduire et gérer les dépendances inter-fichiers.

Cas d’usage au-delà de COBOL

Migration Python 2 → Python 3. Malgré la fin de support de Python 2 (2020), de nombreuses bases de code n’ont pas été migrées. L’IA gère les changements d’API (print statement vs function, division entière, unicode), les incompatibilités de bibliothèques et les patterns obsolètes.

Java → Kotlin. Migration courante dans l’écosystème Android. L’IA produit du Kotlin idiomatique (data classes, null safety, extension functions) plutôt qu’une traduction littérale du Java.

JavaScript → TypeScript. Ajouter du typage à une base JavaScript existante. L’IA infère les types, génère les interfaces, et gère les cas de typage dynamique.

Migration de frameworks. Bootstrap vers Tailwind CSS, React class components vers hooks, AngularJS vers Angular, jQuery vers vanilla JavaScript. L’IA comprend les patterns du framework source et produit l’équivalent idiomatique dans le framework cible.

COBOL, RPG, Fortran → langages modernes. Le marché enterprise le plus lucratif. Au-delà de COBOL, les langages IBM legacy (RPG sur AS/400) et les bases Fortran scientifiques sont des cibles de modernisation IA.

Défis et limites

Logique métier non documentée. Le plus grand défi. Des décennies de modifications ont accumulé des cas limites, des workarounds et des règles métier encodées directement dans le code sans documentation. L’IA peut traduire le code mais ne peut pas deviner pourquoi un calcul de taux d’intérêt utilise une formule spécifique différente du standard. Un humain qui comprend le domaine métier reste indispensable.

Équivalence comportementale. Vérifier que le code traduit se comporte exactement comme l’original nécessite des tests exhaustifs. Les différences subtiles entre langages (précision flottante, gestion des dates, encodage de caractères, comportement des null/undefined/None) peuvent introduire des régressions invisibles. La génération automatique de tests par IA aide mais ne garantit pas la couverture complète.

Dépendances et intégrations. Le code ne vit pas en isolation. Il interagit avec des bases de données, des API, des middlewares, des systèmes de fichiers. Traduire le code sans migrer ou adapter ces dépendances produit un programme qui ne peut pas s’exécuter. C’est ce qu’IBM souligne avec l’intégration CICS/IMS/DB2 de watsonx.

Échelle des projets. Les LLM fonctionnent bien sur des fonctions et des fichiers individuels. La traduction d’un projet complet de 100K+ lignes nécessite une approche incrémentale : analyser les dépendances, prioriser les modules, traduire par blocs, tester à chaque étape. Les agents agentiques (Claude Code, Codex CLI) automatisent partiellement ce workflow mais nécessitent une supervision humaine.

Valider une traduction de code : le workflow critique

La traduction est la partie facile. La validation est ce qui fait la différence entre un projet réussi et un désastre en production. Voici le workflow recommandé.

Étape 1 : Tests de l’original. Avant toute traduction, assurez-vous d’avoir une suite de tests (unitaires, intégration, end-to-end) qui couvre le comportement du code source. Si ces tests n’existent pas (cas fréquent avec le code legacy), utilisez l’IA pour les générer (génération de tests automatique). Ces tests constituent votre « contrat comportemental » : le code traduit doit les satisfaire tous.

Étape 2 : Traduction incrémentale. Ne traduisez pas tout d’un coup. Commencez par les modules les plus simples et les mieux testés. Traduisez un module, exécutez les tests, corrigez les écarts, passez au suivant. Cette approche incrémentale permet de détecter les problèmes tôt et de construire la confiance dans le processus.

Étape 3 : Tests d’équivalence. Au-delà des tests unitaires, comparez les sorties de l’original et de la traduction sur les mêmes entrées. Pour les systèmes critiques (banque, assurance), exécutez les deux versions en parallèle (« dual-running ») pendant une période suffisante pour détecter les divergences comportementales subtiles (arrondis différents, gestion de dates, edge cases numériques).

Étape 4 : Review humaine. Un développeur expert dans le langage cible doit relire le code traduit. L’IA produit du code fonctionnel mais pas toujours optimal. Les patterns non idiomatiques, les anti-patterns de performance, et les choix architecturaux sous-optimaux doivent être corrigés avant la mise en production.

Étape 5 : Monitoring post-déploiement. Après la mise en production du code traduit, surveillez attentivement les métriques de performance, les taux d’erreur, et les comportements inattendus pendant plusieurs semaines. Les régressions les plus insidieuses (corruption de données silencieuse, dérive de calcul, fuites mémoire) ne se manifestent parfois qu’après des jours ou des semaines d’utilisation réelle.