Résumé Technique : REFINE – Une approche multi-agents de type LLM pour le refactoring de code guidé par l'évidence

Énoncé du Problème

Bien que les modèles de langage de grande taille (LLM) démontrent de solides capacités en génération et transformation de code, leur application au refactoring de logiciels se heurte à des défis importants. Un refactoring efficace nécessite non seulement de modifier le code pour réduire les problèmes de qualité (code smells), mais aussi de s'assurer que les changements n'introduisent pas de nouveaux défauts, n'altèrent pas le comportement externe ou ne suppriment pas d'éléments structurels critiques (ex. : API publiques, assertions).

Les approches actuelles de refactoring assistées par LLM manquent souvent de vérification rigoureuse, ce qui entraîne des risques tels que des suggestions hallucinées, des transformations incohérentes et la suppression de structures de code pertinentes pour le comportement. Il existe un besoin pour une approche systématique qui :

1. Guide les LLM avec des preuves issues de l'analyse statique.
2. Orchestre un flux de travail multi-agents pour planifier, générer et vérifier les changements.
3. Fournit une preuve traçable de ce qui a été modifié, des risques restants et de savoir si la sortie est un candidat au refactoring viable plutôt qu'une solution acceptée automatiquement.

Méthodologie : Le flux de travail REFINE

Les auteurs présentent REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), un cadre multi-agents agnostique vis-à-vis des outils et sensible à l'évidence, conçu pour le refactoring de fichiers Java au niveau du fichier. Le système est implémenté comme un prototype de recherche utilisant une interface Next.js, un backend Java Spring Boot (pour l'analyse statique via PMD 7.x), et un service d'agent Python (utilisant LangGraph v1.1) pour l'orchestration.

Le flux de travail opère à travers trois étapes principales :

1. Caractérisation de la tâche

• Entrée : Un fichier Java unique provenant d'un projet open-source.
• Collecte d'évidence : L'analyse statique (PMD) identifie les odeurs de code (code smells) au niveau du fichier et les preuves au niveau de la règle.
• Contextualisation : Le système extrait les signatures d'API publiques, le contexte de l'espace de travail, et priorise les odeurs détectées pour former une tâche de refactoring bornée.

2. Orchestration du Refactoring

Le flux de travail coordonne onze rôles distincts (agents) pour gérer le processus :

• Agent de Planification (Planning Agent) : Combine un guidage déterministe basé sur des règles avec un raffinement optionnel par LLM pour créer un plan de refactoring orienté vers les odeurs.
• Agent de Refactoring (Refactoring Agent) : Invoque un LLM pour générer une transformation candidate basée sur le plan, la source originale et les contraintes (ex. : préserver les API publiques).
• Agent de Vérification (Verification Agent) : Analyse le candidat généré par rapport à des contrôles d'évidence configurés avant qu'il ne soit conservé.

3. Trace de Vérification et Analyse

REFINE ne traite pas la sortie du LLM comme finale. Au lieu de cela, il ré-analyse le fichier transformé pour calculer :

• Réduction des odeurs : Amélioration absolue ($\Delta_{smell} = B - A$) et relative des odeurs de code détectées.
• Proxys de Préservation Statique : Vérifications de la préservation des API publiques, de la gestion des exceptions, des contrats de framework, de la logique conditionnelle et des appels critiques assert/fail.
• Diagnostics d'Échec : Enregistre les raisons spécifiques de rejet (ex. : suppression de méthode publique).
• Traçabilité : Persiste la source originale, le candidat généré, les étapes de l'agent, les métriques et les résultats de vérification pour lier chaque décision à son évidence.

Conception Expérimentale

• Jeu de données : 450 fichiers Java provenant de 15 systèmes open-source (ex. : JHotDraw, Apache Ant, Guava, JabRef), sélectionnés via un échantillonnage aléatoire stratifié basé sur le nombre d'odeurs de code et les lignes de code (LOC).
• Configurations de LLM : Trois modèles de pointe ont été évalués : OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview, et Anthropic Claude Opus 4.8.
• Échelle : Cela a résulté en 1 350 sorties de passage de modèle.
• Référence (Baseline) : Une base de comparaison par prompting direct a été menée sur un sous-ensemble de 150 fichiers pour comparer le flux de travail multi-agents au prompting simple.
• Métriques : Réduction des odeurs de code, indicateurs de qualité (Complexité Cyclomatique, Indice de Maintenabilité, etc.), changements structurels et risques de préservation.

Résultats Clés

1. Réduction des Odeurs de Code (RQ1)

REFINE a obtenu des réductions substantielles des odeurs de code détectées dans les trois configurations de LLM :

• Réduction Totale : 68,26 % (GPT-5.5), 72,79 % (Gemini 3.1) et 68,49 % (Opus 4.8).
• Odeurs Majeures : Les améliorations les plus significatives concernent les odeurs de code majeures (réduction de 86,51 % à 91,60 %).
• Indicateurs de Qualité : Les améliorations des métriques de qualité plus larges ne sont pas uniformes. Bien que Gemini 3.1 ait montré des réductions significatives de la Complexité Cyclomatique et de l'LCOM, d'autres métriques (Maintenabilité, Testabilité, effort de Halstead) ont montré des changements mitigés ou défavorables selon le modèle.

2. Préservation et Risques (RQ2)

• Taux de Réussite Élevés : La plupart des indicateurs de préservation statique (signatures de méthodes publiques, gestion des exceptions, contrats de framework) ont réussi à des taux élevés (81,8 % à 94,2 %).
• Risques Critiques :
  • Appels Assert/Fail : Seuls 57,1 % des sorties ont préservé les appels critiques assert/fail à travers tous les modèles, indiquant un risque systémique.
  • Suppression de Méthodes Publiques : Il s'agit du diagnostic d'échec le plus concret. Gemini 3.1 a présenté le taux le plus élevé de suppression de méthodes publiques (71 cas), suivi de GPT-5.5 (41) et Opus 4.8 (34).

3. Comportement de Refactoring (RQ3)

Différents modèles ont atteint la réduction des odeurs via des profils d'édition distincts :

• GPT-5.5 : A produit les éditions les plus compactes.
• Gemini 3.1 : A présenté un profil "orienté suppression", supprimant le plus de lignes et de méthodes.
• Opus 4.8 : A montré un profil "orienté extraction" avec le plus grand nombre d'extractions de méthodes.
• Corrélation : Des volumes d'édition plus importants étaient corrélés à une réduction absolue plus élevée des odeurs, mais pas nécessairement à une réduction relative plus élevée.

4. Comparaison avec le Prompting Direct

Sur le sous-ensemble apparié de 150 fichiers, REFINE surpasse le prompting direct en termes de :

• Réduction des Odeurs : Médiane de réduction totale de 100,0 % (REFINE) contre 20,8 % (Prompt Direct).
• Empreinte d'Édition : Churn médian plus faible (14 LOC contre 65 LOC).
• Sécurité de l'API : Moins de suppressions de méthodes publiques (46 cas contre 112).
• Compromis : Le prompting direct a préservé les constructions critiques assert/fail plus souvent (100 % contre 58 %).

Signification et Revendications

L'article positionne REFINE non pas comme un remplacement pour les outils de refactoring préservant le comportement, mais comme un mécanisme traçable et sensible à l'évidence pour générer et évaluer des candidats au refactoring.

• Sensibilité à l'Évidence : La contribution principale est de lier le code généré à l'évidence statique spécifique (odeurs) qui a motivé le changement et aux contrôles de vérification qu'il a passés ou échoués.
• Génération Contrôlée : Le flux de travail multi-agents fournit une génération de candidats plus contrôlée que le prompting direct, entraînant des éditions plus petites et moins de suppressions accidentelles d'API, bien qu'il n'élimine pas tous les risques comportementaux.
• Limitations : Les auteurs déclarent explicitement que les sorties générées sont des candidats, et non des refactorings prêts pour la production. Les contrôles de préservation statique sont des proxys et ne prouvent pas l'équivalence comportementale.
• Implication Pratique : Les candidats générés nécessitent la compilation, des tests, une analyse de dépendances et une revue humaine avant adoption, particulièrement dans des contextes dépendants de nombreux composants ou de niveau système.

L'étude conclut que, bien que les flux de travail multi-agents sensibles à l'évidence soient prometteurs pour l'atténuation ciblée des odeurs de code au niveau du fichier, ni le prompting direct ni l'approche multi-agents ne fournissent actuellement de preuves suffisantes de la préservation totale du comportement pour opérer de manière autonome dans des écosystèmes logiciels complexes.