AI-First
Peut-on moderniser du code legacy avec Claude Code ? Oui, à condition de traiter le modèle comme un exécutant rapide dont chaque résultat doit être prouvé par un test, et non comme un architecte qu'on croit sur parole. Claude Code est l'agent de programmation d'Anthropic, qui lit un dépôt, planifie, modifie les fichiers et lance les compilations lui-même. Sur du COBOL, du VBA ou du vieux Java, les démonstrations publiques sont convaincantes, mais les erreurs documentées le sont tout autant.
- 📊 Documentation d'abord, Claude rend lisible un code que plus personne ne comprend, avant toute migration.
- ⚠️ Six erreurs relevées, comptage faux, plan inexact, décision usurpée : aucune n'a atteint le commit.
- ✅ Preuve par les tests, l'équivalence du comportement se démontre, elle ne se déclare pas.
- 🚀 Commencer petit, une macro Excel ou un module isolé avant tout mainframe.
Je forme des PME à Claude Code, et la question revient à chaque fois : « on a un vieux système que personne ne touche, l'IA peut-elle nous en sortir ? ». Ma réponse tient en une phrase : l'IA réduit le coût de comprendre et de réécrire, pas celui de vérifier. Voici ce que les sources montrent, et où je mets la limite.
Pourquoi le code legacy est-il si cher à moderniser ?
Le code legacy coûte cher parce que sa logique métier n'est écrite nulle part : elle vit dans le code, et les personnes qui l'ont écrit sont parties. Comprendre ce que fait le système coûte souvent plus que le réécrire, ce que résume le webinaire d'Anthropic « Modernizing Legacy Code with Claude Code » (anthropic.com).
Quel est l'ordre de grandeur du problème ?
Selon un article de juteq.ca qui cite un rapport Business Wire, 74 % des initiatives de modernisation échouent. Le même texte, qui reprend une étude de McKinsey, affirme qu'un développeur passe en moyenne 17,3 heures par semaine sur la dette technique et la maintenance. Je cite ces chiffres tels que leurs auteurs les donnent, sans avoir pu remonter aux études d'origine.
Chez Thoughtworks, un grand constructeur automobile devait traiter 15 millions de lignes de COBOL. Deux spécialistes avaient besoin d'environ six semaines pour reprendre un module de 10 000 lignes. Le goulot n'était pas la frappe du code, c'était la compréhension.
Le vrai coût du legacy, c'est la connaissance perdue.
Pourquoi l'IA s'attaque-t-elle à ce problème précis ?
Parce que lire de grandes quantités de code non documenté et en tirer des règles métier est exactement ce qu'un agent fait bien. La page « Code modernization » de claude.com liste les usages visés : cartes de dépendances, repérage du code mort, génération de tests de régression et de documentation à partir d'un code qui n'en avait pas.
Sur Reddit, un fil de r/TechnologyNewsIndia affirme que Claude traduit du COBOL en Java ou Python avec « 90 % de précision ». C'est une affirmation de l'auteur du post, sans méthode détaillée, et je ne la retiens pas comme un chiffre fiable. Le fil rappelle néanmoins que les tests et le déploiement exigent encore une forte supervision humaine, ce que le reste de cet article confirme.
Comment Claude Code documente et migre un vieux COBOL ?
Dans la démonstration publiée par Anthropic, Claude Code documente d'abord le programme COBOL, puis le migre vers Java 17 en comparant les résultats avec l'original. Le terrain d'essai est le dépôt de démonstration de modernisation mainframe d'AWS : un système de cartes de crédit d'environ 100 fichiers, sans documentation.
Que fait la phase de découverte ?
Un sous-agent spécialisé « documentation COBOL » est créé, avec sa propre fenêtre de contexte pour ne pas polluer la conversation principale. Claude dresse une liste de tâches couvrant les 94 fichiers pour qu'aucun ne soit oublié ni traité deux fois. Il produit deux fichiers de mémoire (un catalogue qui traduit les noms cryptiques comme CBAC04C en rôles métier, et un fichier de dépendances), puis des diagrammes Mermaid du traitement par lots quotidien.
Résultat annoncé : plus de 100 pages de documentation en une heure de fonctionnement continu. Anthropic précise que Claude Code peut tourner plus de 30 heures de façon autonome.
Comment la migration est-elle contrôlée ?
Claude passe en mode planification, donc sans modifier de fichier, et propose un plan en cinq phases pour la fonction de calcul des intérêts : structure du projet, modèles de données en classes Java, couche d'entrées-sorties compatible avec les formats d'origine, logique métier, banc d'essai double. Ce banc compare GnuCOBOL 3.2.0 pour l'original et Java 17 pour la version neuve.
La vérification porte sur les calculs intermédiaires, pas seulement sur les résultats finaux, et Anthropic annonce une fidélité « bit à bit ». Gardons la mesure : c'est une application de démonstration bien plus petite qu'un vrai système bancaire.
Un fil de r/ClaudeWorkflows décrit la même logique à plus grande échelle avec le projet GitGalaxy : GnuCOBOL comme oracle de test, tests « golden master » bloquants en intégration continue, et un agent neuf par problème avec des notes de passation, pour éviter la dérive. Deux sources indépendantes arrivent donc au même schéma : l'ancien programme sert de juge du nouveau.
Quelles erreurs Claude commet-il sur du code existant ?
Claude commet des erreurs plausibles, donc dangereuses, et la différence se fait sur les garde-fous qui les interceptent. La chaîne Legacy to Latest a rejoué des sessions réelles sur ShipTrack, une API REST de suivi de colis : Java 11 et Spring Boot 2.7, jusqu'à Spring Boot 4.1 et Java 25. Durée : environ 2 heures de temps d'agent, pour environ 24 $ au tarif API, avec 47 tests au vert à l'arrivée.
Quelles sont les six erreurs, et qui les a arrêtées ?
Le tableau ci-dessous reprend celles que la vidéo détaille.
| Erreur de Claude | Ce qui l'a révélée | Leçon |
|---|---|---|
| Annonce 56 tests réussis, il y en a 47 | La sortie de compilation Maven | Un résumé décrit le travail, il ne le prouve pas |
| Deux affirmations fausses dans le plan Spring Boot 3.5 | Les métadonnées de configuration des JAR | Relire un plan comme une demande de fusion |
| Choisit seul l'option B d'un changement d'API | La lecture de la transcription et le sous-agent relecteur | Une décision produit reste humaine |
| Contrat d'API modifié malgré des tests verts | Comparaison des réponses ancienne et nouvelle version | Un test ne protège que ce qu'il affirme |
| Cause racine fausse : clé de configuration renommée | Une commande sur les métadonnées | Vérifier avant d'écrire du code de contournement |
SOURCE : Legacy to Latest, vidéo sur YouTube · MAJ 10/2026
La sixième erreur est une vérification qui masquait une compilation défaillante : la première compilation n'était pas propre, donc d'anciennes classes compilées traînaient dans le dossier cible. La transcription fournie s'arrête avant la fin de ce passage, je m'en tiens donc à ce constat.
Pourquoi la troisième erreur m'a-t-elle le plus marqué ?
Parce qu'elle est en partie la faute des humains. Claude avait bien présenté deux options et demandé de trancher. Mais le hook d'arrêt de l'équipe interdisait de s'arrêter tant que la compilation était rouge, alors Claude a choisi lui-même et signalé son choix.
Le raisonnement tenait, la décision n'était pas la sienne. Le correctif a consisté à autoriser l'arrêt quand seuls les tests de caractérisation échouent : un rouge signifie alors que le comportement a changé, et c'est une question pour un humain.
Cela rejoint ma conviction de fond : l'IA doit augmenter l'équipe, pas créer du chaos, et le contrôle humain reste au centre. Si vous voulez voir comment je cadre ces garde-fous pour des non-développeurs, lisez Claude Code sans compromis pour mes clients PME.
Et pour une PME : par quoi commencer ?
Une PME n'a presque jamais un mainframe de 15 millions de lignes. Elle a une macro Excel, un outil sur Access, un script que seul un salarié comprend. Pour ce cas, la démonstration la plus parlante est la plus petite : la chaîne Hay Kel convertit un formulaire VBA de calcul de frais de voyage en application Python avec Tkinter personnalisé, puis la compile en fichier .exe autonome avec PyInstaller.
Que prouve la démo VBA vers Python ?
Elle prouve qu'un outil bloqué dans Excel peut devenir un programme indépendant en une séance. Le test est simple : 100 km en catégorie « compact » donnent 50 $, comme le code VBA d'origine. C'est un seul cas de test, ce qui est mince, mais l'idée de comparer l'ancien et le nouveau sur les mêmes entrées est la bonne.
Sur r/devsarg, un développeur raconte avoir transformé un système VB6 et Access en moteur FastAPI et SQLite exposant 59 outils via MCP. Sa règle de conception : le modèle ne touche jamais le SQL, le backend valide, exécute et audite. C'est la même philosophie que celle de ShipTrack, avec la responsabilité côté logiciel.
Comment démarrer sans prendre de risque ?
Voici la séquence que je recommande, issue de ce que ces sources ont en commun :
- Documenter avant de toucher. Demandez à Claude Code de décrire le système et ses dépendances, et faites relire par la personne qui connaît le métier.
- Écrire les tests de caractérisation sur le comportement actuel, y compris les cas bizarres.
- Migrer un module isolé, en mode planification, avec un plan relu comme une demande de fusion.
- Comparer ancien et nouveau sur les mêmes entrées, champ par champ.
- Garder la décision produit chez un humain.
Un audit utile débouche sur une roadmap, pas sur un grand projet de 18 mois. Pour poser ce cadre technique avec une équipe senior, l'équipe de GoLive Software publie le versant développement. Et pour le budget d'un usage régulier, voyez le vrai budget de mes automatisations avec Claude Code.
Faut-il y aller, et quel est mon verdict ?
Oui, pour documenter et pour migrer des modules isolés, avec une condition non négociable : un banc de tests qui compare l'ancien comportement au nouveau. La preuve vient du build et des réponses réelles, jamais du résumé de l'agent.
Je ne recommande pas, en revanche, de confier un système critique entier à une session sans oracle de test. Les 24 $ et les 2 heures de ShipTrack sont un résultat séduisant, mais six erreurs en chemin rappellent que la vitesse sans contrôle fabrique de la dette technique plus vite qu'avant.
Le signal de marché existe aussi : un fil de r/singularity rapporte que l'action IBM aurait reculé de 10 % après le lancement d'un outil Claude Code pour COBOL. Je le cite comme réaction de marché rapportée, pas comme analyse. Ce que je retiens pour un dirigeant de PME : le coût de comprendre un vieux système baisse nettement, donc le coût de ne rien faire devient plus visible.
Foire aux questions
Claude Code peut-il vraiment convertir du COBOL en Java ?
Oui, dans les démonstrations publiques. Anthropic montre une migration d'un programme de calcul d'intérêts vers Java 17, vérifiée contre GnuCOBOL 3.2.0 avec une fidélité annoncée bit à bit. Il s'agit d'un dépôt de démonstration d'une centaine de fichiers, pas d'un système de production complet.
Combien coûte une migration de framework avec Claude Code ?
Dans le cas ShipTrack relevé par la chaîne Legacy to Latest, la mise à niveau de Java 11 et Spring Boot 2.7 vers Spring Boot 4.1 et Java 25 a pris environ 2 heures de temps d'agent pour environ 24 $ au tarif API. Ce chiffre concerne un petit service de démonstration, pas une application d'entreprise.
Comment s'assurer que le code migré se comporte comme l'ancien ?
En exécutant l'ancien et le nouveau code sur les mêmes entrées, et en comparant les sorties réelles, y compris les champs en trop et les formats de date. Les tests au vert ne suffisent pas : sur ShipTrack, deux changements d'API public étaient passés avec tous les tests réussis.
Un non-développeur peut-il moderniser une macro VBA avec Claude ?
Oui pour un petit outil. La démonstration de la chaîne Hay Kel convertit un formulaire VBA en application Python compilée en .exe. Il faut ensuite tester avec des cas réels et faire relire le résultat par quelqu'un qui connaît le calcul métier.
Faut-il remplacer son prestataire de maintenance par l'IA ?
Non, pas d'un bloc. L'IA accélère la documentation et la réécriture, mais la validation, les décisions produit et la sécurité restent humaines. Mieux vaut un développeur senior équipé de Claude Code que l'un ou l'autre seul.
Vidéos YouTube
- Claude Code modernizes a legacy COBOL codebase — Anthropic
- Claude Code Made 6 Mistakes on Legacy Code. None Reached a Commit. — Legacy to Latest
- Convert VBA UserForm to Python App (.EXE) with Claude AI — Hay Kel
- How AI accelerated mainframe modernization – A Thoughtworks COBOL modernization case study — Thoughtworks
Discussions Reddit
- IBM is the latest company victim of Anthropic — r/singularity
- Anthropic's Claude starts rewriting COBOL code — r/TechnologyNewsIndia
- De un sistema legacy en VB6 + Access a un motor comercial open-source — r/devsarg
- Advanced Workflow: Ensuring Code Equivalence in AI-Driven Legacy Modernization — r/ClaudeWorkflows