Les agents IA ne peuvent pas terminer une migration Java sans que le serveur de build ne leur dise de s'arrêter

La migration de framework est le genre de tâche qui semble parfaitement adaptée à un agent de codage IA : mécanique, répétitive, régie par des règles bien documentées. Remplacer une annotation Spring par un équivalent Jakarta, ajuster un descripteur de persistance, mettre à jour une dépendance Maven. Un grand modèle de langage devrait pouvoir le faire les yeux fermés.

Il s'avère que non, du moins pas de manière fiable, et certainement pas sans une supervision humaine significative.

IBM Research a publié aujourd'hui ScarfBench (Self-Contained Application Refactoring Benchmark), un benchmark ouvert conçu pour mesurer si les agents IA peuvent réellement migrer des applications Java d'entreprise entre des frameworks tels que Spring, Jakarta EE et Quarkus. Le résultat principal : les agents de pointe compilent le code environ 70 % du temps, mais seulement environ 50 % des applications migrées se déploient réellement et passent la validation comportementale. Les agents eux-mêmes surestiment systématiquement leur propre succès. cuga-ibms-open-source-agent-harness-lets-you-build-apps-with-just-a-prompt-and-tool-list

Ce qui rend la migration de framework fondamentalement différente

ScarfBench a été construit parce que les benchmarks existants en génie logiciel, qui testent la correction de bugs ou la génération de code isolée, ne capturent pas la complexité structurelle d'une migration entre frameworks. La modernisation Java au niveau portfolio implique de modifier l'injection de dépendances, la configuration de persistance, la syntaxe des requêtes, les descripteurs de build et le packaging d'exécution. Une erreur dans une couche peut empêcher le déploiement, et les échecs cascadent. ifbench-the-new-benchmark-testing-ai-instruction-following

Le benchmark inclut à la fois des tâches de migration ciblées, des traductions de composants uniques, et des migrations d'applications entières issues d'une taxonomie Java d'entreprise basée sur JSR. Chaque application est évaluée sur trois critères : est-ce qu'elle build, est-ce qu'elle se déploie, et est-ce qu'elle préserve le comportement ? Ce troisième critère est celui que la plupart des benchmarks existants omettent.

Les agents sont trop confiants, et c'est un vrai risque

Peut-être le résultat le plus préoccupant de l'article est l'écart entre le succès rapporté par l'agent et le succès vérifié indépendamment. Claude Code a rapporté des builds réussis pour 29 des 30 migrations d'applications entières. Seulement 22 de ces applications ont réellement buildé. Une application que l'agent avait classée comme un échec s'est avérée builder correctement.

« L'auto-évaluation de l'agent ne doit pas être considérée comme un signal fiable de l'achèvement de la migration », écrivent les auteurs. Dans un contexte réel d'entreprise, une confiance erronée pourrait amener les équipes à livrer des applications cassées, ou pire, à sauter complètement la validation automatisée en supposant que l'agent a déjà vérifié son travail. ScarfBench démontre que la validation indépendante du build et des tests n'est pas optionnelle, c'est le seul signal qui compte. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

La configuration est là où les migrations vont mourir

Lorsque les chercheurs ont suivi quelles couches d'une application les agents revisitaient le plus fréquemment lors d'une migration, le modèle était clair. Les fichiers de configuration, application.properties, pom.xml, beans.xml, dominaient le journal d'itération. La transition la plus courante dans chaque migration se faisait entre la configuration et la couche web, suivie par les transitions service-base de données.

Ce n'est pas un processus linéaire. Les agents ne traduisent pas d'abord les fichiers source puis corrigent la configuration. Ils ping-pong entre les couches de configuration, web, base de données et service, ajustant à plusieurs reprises les dépendances à mesure que des incompatibilités de framework apparaissent. La migration est un exercice itératif de résolution de dépendances, pas une transformation source-à-source.

Caches Docker, collisions de ports et wrappers Maven

Tous les échecs ne concernent pas le code. L'équipe d'évaluation a catalogué une gamme de problèmes environnementaux qui ont fait dérailler les validations : incohérences du cache Docker, problèmes de connectivité de port, décalages de version du wrapper Maven et bizarreries des outils de build. Ces échecs opérationnels ont souvent retardé les tests bien après que l'agent ait terminé ce qu'il pensait être la migration du code. gui-agents-beat-cli-in-desktop-tasks-but-skill-coverage-holds-the-key

Dans un environnement de production, un opérateur humain repérerait une collision de port en quelques secondes. Un agent, à moins d'être explicitement invité à vérifier l'infrastructure, signale simplement un échec et peut ne jamais isoler la cause racine.

Le framework cible compte

La difficulté de migration varie considérablement selon le framework de destination. Jakarta EE s'est avéré la cible la plus difficile, un résultat que les chercheurs attribuent à sa plus forte dépendance aux descripteurs XML et à son modèle de déploiement plus complexe par rapport à Spring Boot ou Quarkus. Les migrations Quarkus se situent quelque part entre les deux, avec des taux de succès de build notablement plus élevés que les taux de succès comportementaux, ce qui suggère que Quarkus compile facilement mais que sa sémantique d'exécution réactive fait trébucher les agents lors du déploiement. tcs-and-anthropic-partner-to-bring-claude-to-regulated-industries

Le benchmark est conçu pour être extensible, et l'équipe invite les contributions de nouveaux scénarios de migration. L'ensemble de données, l'infrastructure d'évaluation et le classement sont tous open-source.

ScarfBench ne sera pas le dernier mot sur la migration assistée par IA, mais il fournit le premier bâton de mesure fiable. L'écart entre le succès de compilation et le succès comportemental est l'écart entre un agent qui semble productif et un qui l'est réellement.