Netflix accélère ses agents IA sur Java : le moteur d'IntelliJ fait économiser 20–30%, jusqu'à 65% au mieux

Des équipes de Netflix (Application Development Platform, GenAI Platform et Agentic SDLC) ont chiffré le coût du manque de compréhension du code chez les agents IA. Elles ont connecté à Claude Code et Codex une version headless du moteur d'analyse de code de JetBrains, le même que celui qui sous-tend IntelliJ IDEA. Sur des tâches réelles, les agents ont consommé 20–30% de tokens et de temps en moins, et l'économie a atteint environ 65% dans le meilleur cas. La justesse des résultats n'a baissé dans aucune mesure. Les tests se sont déroulés en juillet–août 2026.

Le problème : les fichiers JAR, angle mort des agents

Dans les projets JVM, les bibliothèques sont généralement livrées sous forme d'archives JAR sans les sources. L'agent doit décompresser lui-même les archives en devinant lesquelles comptent, décompiler les fichiers class si nécessaire, puis lancer des grep sur cette vue incomplète. La recherche est lente et peu fiable, et les tokens partent dans des tâtonnements. Paul Bakker, Staff Software Engineer chez Netflix, décrit la situation ainsi : des agents comme Claude Code sont lents et peu fiables pour naviguer en Java/Kotlin, en particulier aux frontières des bibliothèques.

Pendant des années, JetBrains a construit un index déterministe des sources d'un projet, bibliothèques comprises. Il est désormais accessible via LSP, y compris dans les éditeurs compatibles VS Code. Mais le LSP seul n'est pas prêt pour un agent : c'est un serveur doté d'un protocole qu'un agent ne peut pas simplement appeler, et il n'offre aucune gestion de processus pour réutiliser une instance déjà lancée.

Un démon qui garde l'index au chaud

La construction de l'index prend un temps sensible, comme la première ouverture d'un gros projet dans IntelliJ IDEA. Or l'agent sollicite le LSP par une multitude de petites étapes, et une seule tâche demande plusieurs appels de ce type. Si chacun démarre un nouveau serveur, chacun paie un démarrage à froid de plusieurs secondes, même quand l'index a été construit une minute plus tôt.

JetBrains n'avait pas encore publié de démon au moment de l'évaluation, et Netflix a donc écrit le sien :

• chaque appel d'outil est éphémère et sans état : il se contente d'appeler le CLI ;
• le gestionnaire de sessions du démon route l'appel, d'après la racine du projet, vers le bon processus serveur, qui garde l'index en mémoire ;
• un second appel sur le même projet saute l'indexation et passe par stdio vers le serveur « chaud » ;
• le démon et le CLI sont écrits en Java et distribués sous forme d'exécutable GraalVM, de sorte que le démarrage n'entraîne aucun surcoût lié à la JVM.

Méthode de mesure et résultats

Le protocole était simple : un modèle, une tâche, une base de code, et une seule variable, à savoir si l'agent a accès ou non au moteur de JetBrains. Deux bases de code réelles ont servi :

• un service de production interne de taille moyenne, sur Spring Boot 4 et Gradle ;
• le DGS Framework de Netflix, en open source, un framework GraphQL mixte Kotlin/Java.

Les tâches se répartissaient en deux types. Le premier regroupe de petites tâches de navigation : où une interface est utilisée, quelles sont ses implémentations, quelle est la structure d'une classe. Le second regroupe des tâches de bout en bout : implémenter une fonctionnalité, refactoriser une classe, supprimer du code. Les configurations d'agents et de modèles :

• Claude Code avec Opus 5 (effort medium/high) ;
• Claude Code avec Sonnet 5 (effort medium/high) ;
• Codex avec GPT-5.6 Sol (effort medium/high).

Les principales métriques étaient la consommation de tokens et le temps d'exécution. La justesse a été vérifiée par un LLM faisant office de juge : pour les tâches de bout en bout, à partir d'un jeu de modifications de référence ; pour les tâches de navigation, à l'aide d'une métrique déterministe. Les tâches qui ont échoué, atteint la limite de budget ou bouclé dans au moins un des groupes ont été exclues des deux, afin qu'un seul échec ne fausse pas la comparaison. Les exécutions ont été répétées plusieurs fois.

Sur les tâches de navigation, tous les modèles et tous les niveaux d'effort ont consommé moins de tokens, et le modèle le plus puissant a gagné le plus. La justesse est restée identique dans la plupart des exécutions, a augmenté dans deux d'entre elles et n'a baissé nulle part. Une seule anomalie : une combinaison outil-modèle regroupe plusieurs appels de recherche dans une seule commande et n'effectue donc qu'un appel, avec comme sans le moteur.

L'appel au moteur y est un peu plus lent, ce qui supprime le gain de temps ; Netflix ne juge pas ce point représentatif du travail réel. Les tâches de bout en bout sont une base plus fiable : le moteur y s'est montré plus rapide pour chaque modèle et chaque agent, et une partie de l'effet s'explique par un nombre moindre d'appels d'outils pour les mêmes conclusions.

Le gain le plus important est venu des modèles puissants à haut niveau d'effort. Ils coûtent plus cher, donc l'économie y est plus précieuse, et ils exploitent mieux l'index. Netflix souligne que ces chiffres sont un instantané : chaque nouveau modèle change la façon dont les agents cherchent, raisonnent et appellent les outils.

Ce qui a été écarté et la suite

Avant la décision finale, Netflix a écarté deux options. La première était un CLI interne maison connecté à une instance d'IntelliJ IDEA en cours d'exécution : il exige une IDE ouverte et ne convient pas aux environnements headless comme Otto, Bitbot, les outils de refactorisation distribuée et la CI. La seconde était Eclipse LSP, utilisé pour Java dans VS Code : il n'a tout simplement pas fonctionné avec le build Gradle de Netflix.

L'entreprise va ensuite appliquer la même méthodologie à Python, TypeScript/JavaScript et Go, où les agents rencontrent des problèmes similaires, même si la mécanique de chargement des bibliothèques diffère dans ces écosystèmes. JetBrains a déjà intégré l'intelligence Java testée par Netflix à l'extension Java & Kotlin by IntelliJ IDEA, et poursuit ses expérimentations sur l'approche LSP+CLI.

Alexeï Stoukalov, responsable de l'IDE chez JetBrains, pointe le point faible du LSP lui-même : sa primitive de base est la position du curseur dans le texte, alors que les agents raisonnent en symboles, en diagnostics, en liens entre tests et en comportement à l'exécution. Une position dans le texte est fragile : une seule lettre insérée la décale. Selon lui, les agents n'ont pas besoin d'un éditeur virtuel, mais d'un moteur de code offrant des opérations précises sur la structure du programme.

Pour les équipes qui paient déjà des agents sur JVM, la conclusion est pragmatique. Si les tokens des modèles puissants pèsent sensiblement dans les dépenses, une couche déterministe d'analyse de code placée à côté de l'agent s'amortit plus vite qu'une montée en gamme du modèle. Mais il n'existe pas encore de démon prêt à l'emploi : il faut le construire soi-même sur le schéma de Netflix, ou attendre une version de JetBrains.