Une expérience menée par JetBrains a montré que donner aux agents d’intelligence artificielle un accès direct au moteur de refactorisation de Rider peut modifier radicalement la manière dont les tâches C# sont exécutées, au lieu d’obliger l’agent à modifier le texte puis à lancer le compilateur pour découvrir ce que ses changements ont détérioré. Lors d’un test portant sur 15 tâches, le temps médian par tâche est passé de 157,9 secondes à 26,6 secondes, soit une amélioration de 83 %, tandis que le nombre d’appels d’outils a diminué de 17 à 6,2 par tâche.
Cette fonctionnalité est fournie sous la forme d’une compétence intégrée appelée refactoring-code, disponible dans Rider à partir de la version 2026.2.1. Selon JetBrains, l’utilisateur n’a pas besoin de l’activer manuellement : l’agent l’invoque automatiquement lorsqu’on lui demande d’effectuer une refactorisation de code C#. Le moteur s’appuie sur les technologies de ReSharper et sur l’architecture analytique de Rider pour comprendre les relations entre les symboles et les références au sein du projet.
Le problème de l’approche « modifier puis compiler »
Avant de rendre la compétence disponible, JetBrains a observé un modèle avancé lors de l’exécution des mêmes tâches. Sur 2 513 appels à différents outils, l’agent n’a effectué directement aucune opération de refactorisation structurelle, car il ne disposait pas d’un outil dédié à cette fin. À la place, il a utilisé des commandes interactives pour insérer du texte à 468 reprises, appelé git 422 fois et sed 392 fois, et exécuté dotnet build 163 fois.
Cela ne signifie pas que l’agent évitait les opérations de refactorisation, mais qu’il tentait de les approcher au moyen de recherches et de modifications textuelles, puis utilisait les résultats de la compilation pour évaluer ce qui s’était produit. JetBrains explique que renommer un symbole, par exemple, nécessite de distinguer les références associées à une définition donnée, les appels de méthodes polymorphes, les classes partielles, les implémentations explicites d’interfaces et les références dans la documentation. Ces relations ne peuvent pas être garanties par une simple expression régulière.
En revanche, le moteur de Rider fonctionne sur un arbre syntaxique résolu qui détermine la définition associée à chaque identifiant, la surcharge appelée par chaque appel et les emplacements des références dans l’ensemble de la solution. La partie structurelle de la tâche est ainsi transférée au moteur, au lieu que l’agent redécouvre progressivement ces relations au fil de cycles répétés de modification, de compilation et de lecture des erreurs.
Qu’a mesuré JetBrains ?
L’évaluation s’est concentrée sur huit opérations dont les résultats pouvaient être vérifiés clairement :
- Renommer un symbole et toutes ses références.
- Extraire un ensemble d’instructions vers une nouvelle méthode.
- Extraire une interface à partir d’un type existant.
- Extraire une classe de base et y déplacer les membres.
- Modifier la signature d’une API et mettre à jour les emplacements d’appel.
- Déplacer un type vers un autre espace de noms et corriger les instructions using.
- Réorganiser les espaces de noms pour les faire correspondre à la structure des dossiers.
- Supprimer un symbole en toute sécurité lorsqu’aucune autre partie n’en dépend.
Les tâches comprenaient des cas simples et d’autres plus complexes, avec un plus grand nombre d’emplacements d’appel ou des dépendances imbriquées. Les deux configurations ont exécuté le même modèle, gpt-5.5, via Codex CLI, environ dix fois par tâche. La seule différence résidait dans la disponibilité ou non de la compétence refactoring-code. Les comparaisons se sont fondées sur les traces enregistrées et sur un test de permutation apparié.
Résultats pratiques et coût
Lorsque la compétence était activée, le nombre d’exécutions de dotnet build est passé de 163 à seulement trois, et le nombre total d’appels d’outils lors de l’évaluation a diminué de 2 513 à 926. Les modifications textuelles n’ont pas disparu, sed restant l’outil le plus utilisé, mais la répartition des rôles a changé : les modifications ordinaires sont restées prises en charge par les outils d’édition textuelle, tandis que le moteur s’est chargé des changements structurels susceptibles d’étendre leurs effets à des parties que l’agent ne voyait pas directement.
Le temps au 95e percentile est passé de 346,4 à 56,9 secondes, une amélioration particulièrement liée à la disparition des cas bloqués dans le cycle de modification, de compilation et de traitement des erreurs. Le coût médian par tâche a quant à lui diminué de 0,33 dollar à 0,12 dollar, et le coût par tâche réussie de 0,52 dollar à 0,19 dollar. Le nombre de jetons saisis est également passé de 436 745 à 208 524 par tâche, les lectures de la mémoire tampon de 2 973 158 à 1 257 600, et les sorties de 32 532 à 15 538.
Qu’est-ce que cela signifie pour les utilisateurs ?
L’expérience montre que l’utilité des outils destinés aux agents ne dépend pas uniquement de la capacité du modèle à produire du code, mais aussi du type d’outils qu’il peut appeler. Dans huit tâches sur 15, la configuration dotée de la compétence a été plus rapide et moins coûteuse, sans utiliser davantage d’outils, les deux configurations réussissant les tests. Les six tâches dont l’exécution prenait plus de deux minutes dans la configuration de référence ont été améliorées de 82 % à 94 %.
Ces résultats ne constituent toutefois pas un gain généralisé pour tous les cas. Les deux configurations ont échoué dans deux tâches, la configuration de référence a réussi une tâche que la configuration dotée de la compétence n’a pas réussie, tandis que quatre tâches étaient déjà suffisamment rapides pour que l’appel au moteur de Rider ne soit pas économiquement avantageux. Les chiffres apportent donc des éléments en faveur de l’utilité de la compétence pour un ensemble déterminé d’opérations de refactorisation, et non la garantie que chaque tâche s’améliorera dans la même proportion.
Pour illustrer la différence, JetBrains a présenté une tâche d’extraction d’une classe de base à partir du type ReportExporter. Sans la compétence, l’exécution a pris 336,7 secondes et 24 appels, pour un coût de 1,15 dollar, et a comporté plusieurs cycles de modification des fichiers et d’exécution de la compilation afin de traiter les erreurs d’héritage, de constructeurs et de droits d’accès. Avec la compétence, elle a pris 19,8 secondes et trois appels, pour un coût de 0,09 dollar : l’agent a exécuté l’opération extract_base_class, créé ExporterBase, mis à jour quatre fichiers et réécrit 11 références.
La fonctionnalité peut être essayée en mettant Rider à jour vers la version 2026.2.1, puis en ouvrant une solution C# et en demandant à l’agent de renommer un élément, d’extraire une interface ou de déplacer un type. L’article recommande de formuler des demandes précises en indiquant le nom de l’opération, par exemple demander d’extraire une interface de OrderProcessor, plutôt qu’une formulation générale comme « nettoie cette classe ».