JetBrains installe un orchestrateur d'agents dans chaque IDE qu'il publie

JetBrains a ouvert l'accès anticipé à Air dans ses IDE le 1er octobre. Il est disponible sous forme de plugin sur le JetBrains Marketplace ou intégré aux builds EAP 2026.3 d'IntelliJ, PyCharm, WebStorm, Rider et du reste de la famille, et il fonctionne à partir de la version 2026.2. Le plugin est gratuit.

La manière de présenter les choses est ce qu'il y a d'intéressant. Air n'est ni un modèle ni un agent. Il est livré sans aucun agent installé. JetBrains le décrit comme un conduit pour les agents et les abonnements qu'un développeur paie déjà, et il détecte ce qui se trouve déjà sur la machine comme l'IDE détecte les terminaux.

Des sessions plutôt que du chat

JetBrains soutient qu'orchestrer plusieurs tâches en parallèle est une activité différente du fait de converser avec un modèle, et que réunir les deux dans une seule interface a été une erreur. L'IA classique des IDE était centrée sur le chat. Air est centrée sur les sessions.

Chaque session est un agent qui travaille sur une tâche, et l'interface les suit toutes ensemble : activité, mises à jour non lues, fichiers modifiés, commits sortants et coût de chaque session dans une seule vue. Les sessions peuvent s'exécuter à travers plusieurs projets, apparaître sous forme d'onglets d'éditeur, ou rester dans un terminal ou un chat graphique selon la tâche. Un double appui sur Ctrl n'importe où dans l'IDE ouvre une fenêtre de saisie avec le contexte courant joint.

L'isolation est assurée par des worktrees Git temporaires. Une session peut démarrer depuis n'importe quelle branche, sur une nouvelle branche ou en mode détaché, et les résultats sont réintégrés au projet principal par cherry-pick. JetBrains précise que la production de l'agent apparaît sous forme de diff vérifiable dans l'IDE, avec les mêmes outils qu'un développeur utiliserait pour examiner une pull request, et que les modifications ne sont pas appliquées automatiquement.

Le pari protocolaire est la partie stratégique

Air connecte les agents qui prennent en charge l'Agent Client Protocol, un standard ouvert que JetBrains a co-construit avec Zed et publié sous licence Apache. ACP utilise JSON-RPC 2.0 via stdin et stdout, et JetBrains, Zed, Google, GitHub ainsi que plus de 25 agents l'ont adopté. Les deux entreprises ont aussi lancé un registre ACP, un annuaire consultable d'agents compatibles intégré à l'IDE.

La comparaison la plus simple est avec le Language Server Protocol. LSP a permis à n'importe quel éditeur de prendre en charge n'importe quel langage via un standard partagé, au lieu d'une intégration sur mesure pour chaque paire éditeur-langage. ACP vise la même chose pour les agents.

JetBrains se bat pour la couche où les agents sont lancés, supervisés et examinés, plutôt que sur la qualité des modèles, et co-écrire le protocole qui régit la façon dont les agents dialoguent avec les éditeurs est un moyen de devenir une infrastructure plutôt qu'une fonctionnalité. L'explication de l'entreprise est plus directe : un IDE qui tient les agents à distance aura du mal à suivre à mesure que le développement agentique se banalise.

Les agents pris en charge incluent Codex, Claude Agent, GitHub Copilot, Gemini, OpenCode et Junie, l'agent maison de JetBrains, ainsi que d'autres outils compatibles ACP. Un utilisateur disposant déjà d'une clé Anthropic, OpenAI ou Google ne paie rien à JetBrains. Pour ceux qui n'ont pas d'abonnement à un agent, JetBrains propose des exécutions gratuites de Junie Lite après connexion avec un compte JetBrains. Les crédits JetBrains AI démarrent à dix dollars par mois pour l'accès aux modèles hébergés par l'entreprise.

La fonctionnalité que Cursor n'a pas

Le différenciateur sur lequel JetBrains s'appuie, c'est que les agents connectés à Air peuvent invoquer l'outillage de l'IDE sous forme de skills. Un agent peut déclencher une exécution de débogage pour enquêter sur un test qui échoue, lancer le profileur, ou utiliser le moteur de refactoring avec un contexte multi-fichiers complet. Les agents peuvent aussi accéder aux outils de l'IDE via MCP et travailler avec un contexte structuré plutôt qu'avec du texte collé.

JetBrains affirme que cela produit de meilleurs résultats sur certaines tâches et, dans certains cas, consomme moins de tokens. L'affirmation sur les tokens vient de l'entreprise, et aucun test indépendant n'a été publié.

L'argument de fond porte sur ce qu'un agent peut voir. Un agent qui sait seulement lire et écrire des fichiers travaille à partir de texte. Un agent capable de profiler une fonction lente et d'inspecter la pile d'appels dispose du contexte qu'aurait un développeur senior pour diagnostiquer le même problème. JetBrains a passé 26 ans à construire cet outillage, et Air est la première fois que les agents y ont accès.

Pourquoi le moment est bien choisi

JetBrains lance ce produit à un moment où l'étape de revue est devenue le goulot d'étranglement reconnu. Écrire du code n'est plus la contrainte pour beaucoup d'équipes. Vérifier ce qui a été écrit l'est.

Ce constat apparaît simultanément dans tout le marché de l'outillage. Qodo a publié sa version 3.0 la même semaine avec la revue comme pièce maîtresse, et Cursor a ajouté un bot de revue à son workflow d'agents. Trois éditeurs qui convergent vers la même conclusion suggèrent que la contrainte s'est déplacée durablement : quand les agents produisent du code plus vite que les humains ne peuvent le lire, la valeur se déplace vers tout ce qui réduit le coût de lecture.

La conception d'Air reflète cela. Le produit traite les sessions d'agents parallèles comme une file de travail à examiner plutôt que comme une conversation à piloter, et il place le coût par session dans la même vue que les fichiers modifiés. Pour un responsable d'ingénierie qui décide combien d'agents lancer, cette ligne de coût constitue la limite pratique.

L'affichage du coût par session est une petite fonctionnalité à l'effet démesuré sur les comportements. Une équipe qui ne voit pas ce que dépense un agent de longue durée a tendance à n'en lancer qu'un seul, avec prudence. Une équipe qui voit le chiffre par session est plus encline à en lancer plusieurs, car la décision devient une allocation plutôt qu'un pari. C'est le même basculement que celui provoqué par les tableaux de bord de dépenses cloud, et cela change la façon dont les gens organisent leur travail.

Air tente aussi de résoudre un problème de coordination. Une équipe qui fait tourner Claude sur une tâche, Codex sur une autre et Copilot sur une troisième se retrouve avec trois interfaces distinctes et aucun registre partagé de ce que chacune a touché. Les regrouper dans un IDE qui gère déjà les diffs, les inspections et le contrôle de version est un changement plus modeste que l'adoption d'un nouvel outil, et pour les équipes qui ont standardisé sur JetBrains pour Java, Kotlin ou Python, cela évite de pousser tout le monde vers un autre éditeur juste pour avoir des agents.

Ce qui n'est pas réglé

Air est une version en accès anticipé. JetBrains prévient qu'il faut s'attendre à des aspérités, à des changements d'interface et de comportement, et à des mises à jour à peu près chaque semaine. L'entreprise n'a pas annoncé de date de disponibilité générale. L'exécution dans le cloud pour les tâches longues est réservée aux organisations disposant de sièges IA, et JetBrains n'a pas communiqué de tarif pour cette option.

Côté confidentialité, l'entreprise affirme qu'aucun agent connecté signifie que rien ne quitte la machine, et qu'avec un abonnement tiers, les données vont à ce fournisseur selon l'accord existant, et non via JetBrains. Désactiver le plugin ne change rien d'autre, et l'AI Assistant distinct reste pris en charge.

L'affirmation qui mérite d'être testée dans le dépôt d'une équipe est celle concernant la revue. Air facilite l'exécution de plusieurs agents en parallèle. Savoir si cela produit plus de travail fusionné ou plus de diffs que personne ne lit est une question empirique, à laquelle la réponse viendra du premier mois d'usage plutôt que d'un article de lancement.