Votre agent IA passe sans cesse à côté du véritable goulot d'étranglement : avec JetBrains Rider 2026.2 EAP, JetBrains présente une fonctionnalité de profilage basée sur dotTrace pour y remédier

Votre agent IA passe sans cesse à côté du véritable goulot d’étranglement : avec JetBrains Rider 2026.2 EAP, JetBrains présente une fonctionnalité de profilage basée sur dotTrace pour y remédier

JetBrains est une société à responsabilité limitée internationale spécialisée dans le développement de logiciels, qui conçoit des outils destinés aux programmeurs (développeurs de logiciels) et aux chefs de projet. JetBrains propose divers environnements de développement intégrés (EDI), tels que IntelliJ IDEA, PyCharm, Rider, WebStorm et CLion. Elle a également créé en 2011 le langage de programmation Kotlin, qui peut s'exécuter sur une machine virtuelle Java (JVM). Rider est l'EDI pour le développement .NET (principalement en C# et F#) et le développement de jeux avec Unity (C#) et Unreal Engine (C++).

Voici un cas qui mérite réflexion : votre application se bloque pendant dix secondes, et vous demandez à un agent IA ce qui ne va pas. Que fait-il réellement ? Pendant longtemps, la réponse honnête était la suivante : il fouille dans votre code et avance une hypothèse au hasard.

Un instantané pris par un outil de profilage constitue une preuve d’exécution. Il indique exactement où le processeur a été sollicité. Mais un agent qui n’a pas accès au profilage ne peut pas l’interpréter. Il fait donc la seule chose qu’il peut faire : il analyse le projet, repère des inefficacités qui semblent plausibles et les présente avec assurance comme étant le goulot d’étranglement. Parfois, il a de la chance. Mais en cas de véritable blocage, ce n’est généralement pas le cas.

JetBrains a développé une solution pour remédier à cela dans Rider : une fonctionnalité de profilage basée sur dotTrace pour les agents de l’assistant IA, appelée dottrace-analyze. Le principe est très simple. Vous fournissez à l’agent un instantané .dtp que vous avez déjà capturé avec dotTrace – à l’aide du profileur autonome, de l’outil en ligne de commande ou de dotTrace intégré à Rider – et, au lieu de parcourir votre code source, il lit d’abord le profil. Il identifie où le temps a réellement été consommé, remonte le chemin d’accès le plus sollicité jusqu’à votre code, et explique ce qui est lent et pourquoi, en proposant des recommandations sur les éléments à examiner ensuite.

JetBrains a procédé aux évaluations. Pour éviter que la notation ne relève d’un jugement subjectif, chaque réponse a été évaluée par rapport à une cause première de référence, selon une grille d’évaluation fixe utilisant un LLM comme juge : l’agent a-t-il identifié le principal point chaud, expliqué le mécanisme, évité les détours trompeurs et proposé une correction découlant des preuves ? Les résultats ont dépassé les attentes, alors pourquoi ne pas commencer par les plus spectaculaires :


Étude de cas : un blocage de l’interface utilisateur que l’agent n’aurait pas pu détecter sans dotTrace

L’un des scénarios de test concernait une ancienne version d’Avalonia qui avait tendance à se bloquer lors de son arrêt. Ce problème s’était même glissé dans Rider lui-même il y a deux ans, ce qui illustre à quel point les baisses de performances issues de projets open source populaires peuvent facilement se répercuter sur vos applications.

Pour clarifier la méthodologie : l'équipe de JetBrains a intentionnellement testé une version d’Avalonia antérieure au correctif apporté dans AvaloniaUI/Avalonia#16633. Il était crucial d’utiliser un bug connu et depuis résolu, car cela fournissait une réponse de référence claire pour l’évaluation.

Ils ont exécuté le même agent sur ce problème dix fois avec la compétence et dix fois sans, puis avons demandé à un modèle de langage de grande capacité (LLM) d’évaluer chaque diagnostic par rapport à la cause première connue, sur une échelle de 0 à 10.

Sans la compétence, l’agent a obtenu une note moyenne de 1,6 sur 10. Il a parcouru le code de rendu, a énuméré quelques suggestions générales, mais n’a jamais identifié le véritable problème.

Avec la compétence, il a obtenu la note de 10 sur 10 à chacune des dix exécutions.


Les résultats n’étaient pas « légèrement meilleurs » : l’agent est passé d’une performance systématiquement erronée à une performance systématiquement correcte, sans aucune variation.

Et ce qu’il a découvert est le genre de chose qui est véritablement difficile à repérer en lisant le code (même si l’on dispose de quelques heures devant soi). Le blocage ne se trouvait pas à un endroit évident. Il provenait d’une simple opération caractère par caractère, enfouie au plus profond du chemin de mise en page du texte, peu coûteuse en soi mais exécutée un si grand nombre de fois qu’elle accaparait la majeure partie du CPU. Ce coût n’apparaît que lorsque l’on peut voir où le temps a réellement été dépensé. L’agent a suivi l’instantané jusqu’à cet endroit précis, a expliqué pourquoi cette opération était si coûteuse et a indiqué la modification qui permettrait d’y remédier.

Le benchmark complet : huit scénarios, 80 exécutions

Ce scénario Avalonia ne représentait qu’une partie de l'évaluation. Après avoir vérifié ce cas au cours d’exécutions répétées, l'équipe de JetBrains élargi le lot à huit scénarios d’analyse des performances .NET issus de différents projets et avons comparé le même agent avec et sans accès au profileur. Voici comment la compétence a modifié le score moyen de précision pour chaque scénario, sur 10 :


Sur l’ensemble des 80 exécutions, le score moyen de précision est passé de 4,71 à 8,15. Le nombre d’exécutions ayant obtenu un score de 8 ou plus a pratiquement doublé, passant de 29 à 59. Les exécutions ayant identifié la cause première avec exactitude (un 10 parfait) ont plus que doublé, passant de 20 à 48.

Il y a deux points dans ce tableau sur lesquels l'équipe de JetBrains tient à être honnêtes.

La première concerne les cas où la compétence fait véritablement la différence : les scénarios où la référence était désespérée. Partout où la réponse se trouvait réellement dans l’exécution (les blocages d’Avalonia, la charge de travail de Cyclops), la référence obtenait un score compris entre 1 et 2, tandis que la compétence le faisait grimper à 9 ou 10. L’agent a cessé de disperser son attention entre diverses idées d’optimisation générales pour se concentrer sur ce qui était réellement à l’origine du ralentissement.

La deuxième concerne le bas du tableau, laissé figurer intentionnellement. Les cas game-of-life, checkers-copy et checkers-update étaient déjà bien gérés sans aucun outil de profilage, et sur les deux cas de checkers, la compétence a fait baisser le score de quelques dixièmes. La leçon à en tirer n’est pas que la compétence nuit aux résultats, mais que certaines tâches n’en ont pas besoin. Parfois, lancer un workflow de profilage complet alors qu’un rapide coup d’œil au code suffirait revient simplement à gaspiller des jetons.

Ce que cela coûte réellement

JetBrains a suivi les coûts avec autant de rigueur que la précision, car une compétence qui produit de meilleures réponses à un prix déraisonnable n’est pas une compétence commercialisée. Commençons par la partie la plus simple : l’analyse d’un instantané représente un véritable travail. L’agent charge les données du profileur, parcourt les arbres d’appels et relie les éléments de preuve à votre source avant de commencer à raisonner. Dans le lot de 80 exécutions ci-dessus, cela s’est répercuté sur la facture. Le coût est passé d’environ 1,91 USD par exécution sans la compétence à environ 2,61 USD avec celle-ci. Le coût total du lot s’élevait à environ 153 USD sans la compétence et à 209 USD avec celle-ci. Compte tenu de l’amélioration significative des diagnostics, JetBrains pense que c’est un bon compromis, mais il s’agit bel et bien d’une augmentation.

Il existe toutefois un deuxième effet, qui va dans le sens inverse. Dans un autre cas de test d’Avalonia, concernant une application qui mettait du temps à se fermer, l’agent sans la compétence n’a jamais trouvé la véritable cause. Sur dix exécutions, il n’a cessé d’élaborer la même théorie plausible mais erronée, effectuant des recherches à grande échelle et parcourant fichier après fichier au fur et à mesure, et a obtenu à chaque fois un score de 0 sur 10. Avec la compétence, il a d’abord effectué des mesures, puis a suivi le profileur directement jusqu’au chemin de code responsable, et a obtenu un score de 10 sur 10. Le fait d’éviter toutes ces digressions a également rendu les exécutions moins coûteuses et plus rapides : 2,58 USD par exécution au lieu de 3,74 USD, et 206 secondes au lieu de 373.

En résumé, on peut donc dire que cette fonctionnalité modifie la répartition des ressources. Elle consacre davantage de temps à l’analyse des indices et moins à l’exploration de fausses pistes. Parfois, cela revient plus cher, parfois moins, mais dans les deux cas, vous payez pour une réponse fondée sur ce que votre application a réellement fait, et c’est là que réside tout l’intérêt.


Ce que vous verriez dans Rider

Le workflow est volontairement simple : capturez un instantané .dtp avec dotTrace, que ce soit depuis Rider, depuis dotTrace Standalone ou avec l’outil en ligne de commande dotTrace. Demandez ensuite à l’agent de votre choix dans la fenêtre de l’assistant IA d’analyser cet instantané en indiquant son répertoire dans l’instruction générative.


En arrière-plan, le système charge la compétence « dottrace-analyze » et utilise le SDK dotTrace pour lire le profil ; le résultat est un rapport ciblé :

- un bref résumé des goulots d’étranglement dominants ;
- les méthodes, les emplacements dans le code source et les chemins d’appel qui accaparent le temps d’exécution ;
- la cause première exprimée dans un langage clair pour les développeurs, et pas seulement sous la forme d’un nom de méthode ;
- des recommandations sur les éléments à examiner ensuite.

Pour des analyses plus approfondies, il peut convertir ces informations en un rapport HTML concis que vous pouvez ouvrir dans un onglet et partager avec l’équipe. Le travail sur les performances est souvent collaboratif, et un artefact clair est très pratique lorsque plusieurs développeurs travaillent à la résolution du problème.

Comment les trajectoires de recherche de l’agent ont évolué

Le signal le plus fort issu de cette deuxième évaluation est la trajectoire : le parcours réel de l’agent à travers les outils et les fichiers. Les exécutions sans expertise n’ont pas échoué parce qu’elles étaient paresseuses ou incohérentes. Elles ont effectué une recherche large, ont identifié un problème de temporisation qui semblait réel et ont construit une explication convaincante autour du mauvais sous-système. Les exécutions s’appuyant sur l’expertise ont commencé par des mesures, de sorte que l’espace de recherche s’est réduit autour du chemin critique avant même que la lecture du code source ne commence.


Les preuves l’emportent sur les suppositions

On peut résumer l’ensemble des résultats en un seul contraste. Sans l’instantané, le mieux qu’un agent puisse proposer est : « Voici quelques anomalies de code susceptibles de ralentir le programme. » Avec cet instantané, l’agent peut affirmer : « Cet instantané indique que 88 % de votre temps a été consacré ici, et voici pourquoi. » Cette deuxième phrase résume tout l’intérêt de la démarche.


L’optimisation des performances impose une exigence stricte que la plupart des tâches de codage n’ont pas : la réponse doit correspondre à ce que le programme a réellement fait, et non à ce qu’il semble pouvoir faire. Les exécutions les plus performantes de nos évaluations présentaient toutes la même structure : elles ne se contentaient pas de nommer une méthode, elles expliquaient le chemin d’appel, quantifiaient la zone critique, séparaient la cause première de ses symptômes et proposaient une correction découlant directement du profil. C’est ainsi que se déroule l’analyse d’un expert, et cela n’est possible que lorsque l’agent part des mêmes éléments de preuve qu’un expert.

dotTrace sait déjà ce qui s’est passé lors de l’exécution. L’assistant IA est déjà capable de transformer ces éléments de preuve en une explication et en une prochaine étape. Cette fonctionnalité fait le lien entre les deux, et dans les cas les plus importants, elle fait la différence entre un agent qui devine et un agent qui sait.

Disponible dès maintenant dans Rider 2026.2 EAP 8

Pendant la durée du programme d’accès anticipé (EAP) de Rider 2026.2, vous pouvez essayer gratuitement ce workflow dans la version EAP. Pour les licences de produit standard, la partie profilage de cette fonctionnalité repose sur dotTrace. Les plugins dotTrace et dotMemory de Rider sont disponibles avec les abonnements dotUltimate ou All Products Pack ; un abonnement Rider seul n’inclut pas le profilage dotTrace.

Il s’agit encore d’une implémentation précoce et expérimentale dans le cadre du programme d’accès anticipé, et il reste encore du travail à accomplir.

Téléchargez la dernière version EAP de Rider