Créer un moteur de migration PHP vers Java reproductible avec Kiro
Une équipe qui migre une application PHP mature vers Java gagne en sécurité de typage, en richesse de bibliothèques et en prévisibilité à l'échelle. Mais un code construit pendant des années avec Laravel, Symfony ou Doctrine cache des règles métier à des endroits peu évidents, des traits Eloquent aux fichiers de mapping XML. Un portage Java structurellement proche peut donc compiler sans erreur et pourtant se comporter autrement. AWS propose de transformer cette migration en processus mesurable et reproductible grâce à Kiro, un environnement de développement intégré qui associe un agent d'IA au code source pour exécuter des tâches d'ingénierie en plusieurs étapes, avec le développeur dans la boucle. Le dispositif repose sur un moteur réutilisable : une méthodologie partagée, un scanner de découverte mécanique et un flux de travail en huit phases. L'application PHP d'origine y sert de spécification, et le port Java n'est déclaré correct qu'une fois validé par un banc de tests de parité. Tout le savoir du moteur tient dans des fichiers de compétences en Markdown versionnés, notamment php-to-java-migration pour la méthodologie et php-model-discovery pour le scanner.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Concrètement, ces fichiers permettent d'exécuter la même méthode de deux façons. Dans Kiro, le mode interactif, on ouvre la racine du dépôt comme espace de travail et les compétences s'activent dès qu'on demande de migrer une application PHP. L'agent déroule alors les huit phases avec des points d'approbation explicites : le développeur relit le manifeste de découverte, valide le livre de règles, puis signe chaque phase avant la suivante. Avec AWS Transform, le service agentique d'AWS dédié à la migration et à la modernisation à grande échelle, désormais intégré nativement à Kiro, les mêmes fichiers pilotent des exécutions autonomes, avec relecture aux points de contrôle définis. Les prérequis sont modestes : PHP 8.0 ou plus récent pour le scanner, Java 21 et Maven pour les projets Spring Boot générés, et un espace Kiro avec accès aux compétences et aux fichiers de pilotage.
L'enjeu dépasse le simple outillage. Les migrations de ce type échouent souvent parce que la correction est jugée sur la compilation ou sur une relecture visuelle, alors que les écarts de comportement se cachent dans les règles implicites. En érigeant l'application source en référence et un banc de parité en arbitre, la méthode déplace la confiance de l'intuition vers la mesure. Le principe « corriger la boucle, pas le code » signifie qu'une erreur détectée conduit à amender le livre de règles, afin que le défaut disparaisse de toutes les migrations suivantes. Kiro traite une application à la fois et convient aux frameworks inédits, tandis qu'AWS Transform lance de nombreuses applications en parallèle. Comme les deux voies lisent les mêmes fichiers, chaque correction faite dans l'une améliore l'autre.
Cette approche s'inscrit dans la montée des agents d'IA appliqués à la modernisation de code, où l'ambition est de passer de projets artisanaux à des chaînes industrielles. Le principe directeur du dépôt, « un cerveau partagé, plusieurs projets », vise à capitaliser l'expérience acquise à chaque migration plutôt que de repartir de zéro. Le dépôt est ouvert : il suffit de le cloner et d'ouvrir sa racine, celle qui contient le dossier .kiro, pour que Kiro charge compétences et pilotage. La suite logique est l'extension à d'autres frameworks et un usage en portefeuille via AWS Transform, au service des entreprises qui gèrent un parc d'applications PHP vieillissantes.
Pas d'impact direct sur la France/UE