JetBrains Air dans les IDE ouvre son EAP, mais l’orchestration est le vrai pari

JetBrains a ouvert JetBrains Air dans les IDE en accès anticipé, réunissant cinq agents de codage pris en charge dans un espace de travail conçu pour les tâches parallèles. L’enjeu consiste moins à ajouter un chatbot de plus qu’à déterminer où les développeurs superviseront le code généré par l’IA.

Air prend en charge Codex, Gemini, GitHub Copilot, Claude Agent et Junie, l’agent de JetBrains, dès l’installation. Il peut également connecter d’autres outils compatibles via l’Agent Client Protocol, ou ACP, une interface commune entre les agents de codage et les environnements de développement.

JetBrains s’oppose ainsi à une vision du développement logiciel centrée sur le modèle. Dans ce modèle, les développeurs suivent l’agent qui obtient actuellement les meilleurs résultats. JetBrains parie que le produit durable sera l’environnement qui fournit le contexte, suit les travaux simultanés et aide les humains à examiner chaque modification.

L’annonce initiale évoquait un EAP disponible dans cinq IDE. La documentation actuelle de JetBrains indique désormais que le plugin prend en charge sa gamme d’IDE, à l’exception d’Android Studio, ce qui élargit la portée finale par rapport à ce premier cadrage. Le chiffre le plus important reste celui des cinq agents, car Air les traite comme des intervenants interchangeables dans une même surface de contrôle.

JetBrains ne demande pas aux développeurs d’abandonner Codex, Claude, Gemini, Copilot ou Cursor. L’entreprise veut que ces systèmes fonctionnent au sein des produits JetBrains. Cette distinction fait du JetBrains Air EAP un test : l’IDE peut-il rester au centre du développement logiciel lorsque les agents réalisent une part croissante de l’implémentation ?

JetBrains Air dans les IDE sépare l’espace de travail du modèle

JetBrains Air dans les IDE est une couche d’orchestration, et non un nouveau modèle ou un nouveau nom pour AI Assistant.

JetBrains a lancé l’EAP début octobre via le Marketplace et les versions 2026.3 EAP de ses IDE. L’annonce Air EAP de l’entreprise indique que le plugin est fourni sans agent installé et qu’il ne fait pas office de fournisseur d’IA.

Cette conception importe, car elle distingue trois produits que les utilisateurs rencontrent souvent comme une seule expérience intégrée. Le modèle génère ou interprète du texte. L’agent de codage planifie des tâches, utilise des outils, modifie des fichiers et exécute des commandes. Air organise ces agents et leur travail dans l’IDE.

Les développeurs peuvent connecter les agents qu’ils utilisent déjà, sous réserve des règles d’authentification de chaque fournisseur. Ils n’ont pas besoin d’un abonnement JetBrains AI simplement pour exécuter un agent tiers compatible. Air peut détecter les installations locales d’agents, proposer des agents via un registre et réutiliser les méthodes d’autorisation prises en charge.

Cinq agents bénéficient d’une prise en charge explicite de premier plan : Codex, Gemini, GitHub Copilot, Claude Agent et Junie. Cursor et d’autres outils peuvent être intégrés grâce à la compatibilité ACP, même si l’interface exacte et le parcours d’autorisation peuvent varier selon l’agent.

Le produit organise le travail autour de sessions plutôt que d’une conversation unique et continue. Chaque session représente une tâche, son agent, son contexte, son avancement et les modifications qu’elle produit. Les développeurs peuvent consulter le travail actif dans plusieurs projets, identifier les sessions en attente d’une intervention et ouvrir les modifications terminées pour les examiner.

Air prend également en charge les préréglages. Un préréglage mémorise un agent, la sélection du modèle, l’effort de raisonnement, le niveau d’accès et d’autres paramètres de lancement. Une équipe peut ainsi créer différentes configurations pour les corrections courantes, les refactorisations importantes, les revues ou les expérimentations.

Cette structure transforme l’IDE en répartiteur. Un développeur peut envoyer un test en échec à Codex, confier des modifications de documentation à Gemini et demander à Junie d’examiner un problème de performances. Air ne prétend pas que ces agents coopéreront comme une intelligence collective. Il donne à chaque tâche une place visible et conserve leurs résultats dans un flux de revue.

Cette distinction évite un malentendu important autour de l’expression « exécute cinq agents d’IA ». Air prend en charge cinq agents nommés dès l’installation, mais n’exige pas que les cinq fonctionnent simultanément. Il ne garantit pas non plus que des agents exécutés en parallèle produiront du code compatible.

La documentation Air actuelle de JetBrains indique que les agents locaux s’exécutent sur la machine du développeur. Air communique avec les agents compatibles ACP par le protocole, tandis que les agents en ligne de commande peuvent conserver leurs interfaces de terminal dans l’IDE.

Le plugin peut être installé sur les versions 2026.2 et est intégré aux versions 2026.3 EAP. JetBrains documente désormais la prise en charge de tous ses IDE, sauf Android Studio. La disponibilité, l’autorisation des agents et l’exécution dans le cloud peuvent toutefois encore dépendre de la version du produit utilisée et des paramètres de l’organisation.

Ces détails en font davantage qu’une mise à jour de distribution. JetBrains réorganise son interface IA autour du travail délégué, tout en gardant son éditeur, son débogueur, ses inspections, ses outils de navigation et de contrôle de version à proximité du résultat.

Pourquoi JetBrains dépasse le panneau de discussion IA

La pression qui s’exerce sur JetBrains vient d’un changement dans le comportement des développeurs, et pas seulement de modèles de langage plus puissants.

La première génération de fonctions d’IA intégrées aux IDE était centrée sur l’autocomplétion et le chat. Un développeur sélectionnait du code, posait une question, recevait une réponse, puis décidait quoi copier, coller ou appliquer. Cette interaction s’intégrait facilement dans un panneau latéral.

Les agents de codage créent un problème de gestion différent. Ils peuvent lire plusieurs fichiers, élaborer un plan, exécuter des commandes, modifier un dépôt et lancer des tests avant de rendre le contrôle. Un développeur peut également démarrer une autre tâche alors que le premier agent reste actif.

JetBrains indique avoir essayé d’intégrer davantage d’agents dans le chat existant d’AI Assistant. L’entreprise a conclu que la supervision de tâches simultanées nécessitait un produit organisé autour de l’état du travail plutôt que de l’historique des conversations.

Cette conclusion explique pourquoi Air et AI Assistant restent distincts durant l’EAP. AI Assistant continue de proposer le chat, la complétion, les analyses de code, les suggestions de prochaine modification et l’accès aux agents dans l’expérience IDE établie. Air traite les agents et les sessions comme les principales unités de travail.

JetBrains prévoit qu’Air devienne au fil du temps son interface agentique principale, mais n’a pas annoncé la suppression d’AI Assistant. Les utilisateurs peuvent conserver AI Assistant installé, bien que l’installation d’Air via une notification AI Assistant désactive l’ancien plugin afin d’empêcher les deux interfaces de fonctionner simultanément. Il peut être réactivé dans les paramètres des plugins.

L’enjeu concurrentiel plus profond est la maîtrise de l’attention des développeurs. Les éditeurs axés sur les agents et les outils en ligne de commande peuvent détourner le travail de l’IDE traditionnel. Si les développeurs passent la majeure partie de leur temps à formuler des prompts et à examiner des correctifs ailleurs, l’IDE risque de devenir un lieu secondaire, utilisé uniquement pour le débogage difficile.

Air tente d’inverser ce flux. Au lieu de forcer les développeurs à choisir entre JetBrains et un agent externe, il invite l’agent externe dans l’environnement JetBrains. L’agent fournit la planification et la génération, tandis que l’IDE apporte le contexte du dépôt et les outils de vérification.

Cette approche répond également à l’évolution rapide des modèles. Le modèle de codage de référence peut changer plus vite qu’une organisation ne change son environnement de développement. Une entreprise peut préférer un agent pour les migrations Java, un autre pour le travail d’interface, et un agent interne pour les dépôts contenant du code restreint.

JetBrains n’a pas besoin que Junie remporte toutes les comparaisons si Air reste l’endroit où ces systèmes sont gérés. L’entreprise peut profiter d’agents tiers plus performants, car ils rendent l’espace de travail partagé plus utile.

C’est pourquoi ACP joue un rôle central. Le contrat ACP définit une connexion commune entre un client, tel qu’un IDE, et un agent. L’agent conserve sa propre sélection de modèles, ses outils, son authentification et son comportement de planification.

JetBrains compare cette frontière au rôle du Language Server Protocol. Un éditeur n’a pas besoin d’une intégration privée distincte pour chaque serveur de langage compatible. ACP vise à réduire le besoin d’un plugin sur mesure entre chaque agent et chaque environnement de développement.

L’analogie a ses limites. Les agents de codage peuvent exécuter des commandes et modifier de grandes portions d’un dépôt ; leurs autorisations et leurs effets de bord comportent donc davantage de risques. Néanmoins, une couche de connexion commune réduit le travail d’intégration et rend le changement d’agent moins perturbant.

Pour JetBrains, cela crée une ouverture stratégique. Cursor, Codex, Claude, Copilot et Gemini n’ont pas besoin d’être vaincus au niveau du modèle. Ils peuvent devenir des choix au sein d’un IDE JetBrains multi-agents.

L’IDE devient le plan de contrôle du travail des agents

Le pari central d’Air est que la vérification gagne en valeur à mesure que la génération de code devient plus facile.

Générer un correctif n’est qu’une partie du développement logiciel. Quelqu’un doit déterminer si le correctif répond à l’exigence, préserve l’architecture, réussit les tests, respecte les limites de sécurité et se comporte correctement dans des conditions réelles.

JetBrains possède déjà de nombreux outils utilisés pour ce travail. Ses IDE comprennent les symboles, les types, les références, la structure des projets, les exécuteurs de tests, le contrôle de version, les bases de données, les débogueurs et les profils de performances. Air relie l’activité des agents à ces surfaces existantes.

Un agent peut recevoir des fichiers, des commits, des captures d’écran et des instructions réutilisables comme contexte. Le développeur peut examiner les fichiers modifiés, comparer les différences, naviguer dans le code associé et exécuter le projet sans transférer le résultat dans une autre application.

Cette connexion peut réduire l’exploration redondante. Un agent de codage dépense souvent des tokens à lister des répertoires, ouvrir des fichiers de configuration et localiser les symboles pertinents. Le contexte fourni par l’IDE peut l’orienter plus tôt vers le bon code, même si les gains varieront selon l’agent et la tâche.

Air donne également aux agents pris en charge accès à des compétences IDE pour des activités telles que le débogage, le profilage, l’exploration de bases de données et la recherche sémantique de code. JetBrains affirme que ces outils peuvent améliorer les résultats pour certaines tâches, mais cette affirmation doit encore être largement testée sur différents dépôts et langages.

La session de l’agent devient le conteneur de ce flux de travail. Elle enregistre l’agent sélectionné, la conversation, l’activité, les fichiers modifiés, les commits et le coût signalé. Les sessions peuvent rester visibles dans plusieurs projets, ce qui aide le développeur à repérer le travail terminé ou nécessitant une intervention.

Ce modèle diffère de l’ouverture de cinq onglets de chat. Un onglet de chat conserve principalement une conversation. Une session Air relie la conversation à l’état du dépôt et aux actions de revue.

Prenons le cas d’un développeur responsable d’un service présentant un test d’intégration en échec. Une session peut examiner l’échec. Une deuxième peut mettre à jour une dépendance associée dans une branche isolée. Une troisième peut examiner la documentation affectée par la modification.

Le développeur peut continuer à travailler dans le checkout principal pendant que ces sessions progressent. Lorsqu’une session se termine, l’IDE devient l’endroit où examiner le diff, exécuter les inspections, vérifier les tests et décider si le résultat doit rejoindre la branche cible.

Ce processus correspond à une évolution plus large du travail d’ingénierie. Les développeurs coordonnent de plus en plus des modifications générées au lieu de saisir directement chaque élément d’implémentation. Leur responsabilité ne disparaît pas. Elle se déplace vers la définition des tâches, la fourniture du contexte, l’examen des éléments de preuve et la résolution des conflits.

JetBrains positionne l’IDE comme le plan de contrôle de ces responsabilités. Le terme désigne une surface qui coordonne les intervenants et l’état sans être elle-même l’intervenant. Air n’a pas besoin de générer le meilleur correctif pour devenir utile s’il facilite la supervision de plusieurs agents.

Le modèle préserve également le choix de l’utilisateur. Un développeur peut connecter un abonnement existant lorsque le fournisseur l’autorise, sélectionner JetBrains AI ou utiliser un agent ACP configuré localement. Air ne fournit pas lui-même de modèle propriétaire.

Cette flexibilité est stratégiquement importante. Un espace de travail fermé lié à un seul modèle hérite des faiblesses et des évolutions commerciales de ce modèle. Un espace de travail multi-agents peut permettre aux développeurs de remplacer l’agent tout en préservant les habitudes de projet et les outils de revue.

Les équipes qui développent déjà un contexte d’ingénierie interrogeable reconnaîtront peut-être la même logique. L’actif durable n’est pas une réponse isolée, mais la structure qui relie le code, les décisions, les documents et la revue. Une base de connaissances technique peut compléter les sessions d’agents en préservant les informations qui doivent survivre au-delà d’une tâche de programmation.

Air ne résout pas seul ce problème plus large de connaissance. Une session contient un contexte de travail utile, mais les équipes ont toujours besoin de dossiers durables pour les décisions d’architecture, les incidents et les exigences. L’IDE peut coordonner l’implémentation tandis que les systèmes de connaissances partagés préservent la raison d’être de celle-ci.

Les agents parallèles créent un problème de fusion et d’attention

Exécuter davantage d’agents n’augmente le débit que lorsque les développeurs peuvent examiner, concilier et faire confiance à leurs résultats.

Air permet aux développeurs de démarrer des sessions depuis une branche et de placer le travail dans un Git worktree temporaire. Un worktree est une copie de travail distincte liée au même historique de dépôt. Il garde les modifications d’un agent à l’écart du checkout actuel du développeur.

Cette isolation est essentielle au travail en parallèle. Deux agents modifiant les mêmes fichiers dans un même espace de travail peuvent écraser des hypothèses ou créer des changements qui réussissent séparément mais échouent ensemble. Des worktrees distincts réduisent les interférences directes.

Air peut afficher le résultat et permettre au développeur de transférer certains commits vers le projet actif. Son flux de travail de session documenté prend en charge la revue des changements avant leur cherry-pick dans la branche cible.

L’isolation ne supprime pas le travail d’intégration. Si cinq agents modifient des zones liées, le développeur peut se retrouver face à cinq branches, des modifications dupliquées, des abstractions incohérentes et des conflits de fusion. Chaque agent peut produire un résultat local plausible tandis que le système combiné devient moins cohérent.

Le goulot d’étranglement passe alors de la production de code à l’attention humaine. Un développeur doit comprendre ce que chaque agent a modifié et pourquoi. Il doit aussi décider quels tests apportent des preuves significatives, plutôt que d’accepter un résumé au vert généré par le même système qui a écrit le code.

La liste des sessions d’Air aide à rendre cette charge de travail visible. Elle peut afficher les sessions actives, les mises à jour non lues, les fichiers modifiés, les commits sortants et les tâches en attente d’entrée. Cette visibilité est utile, mais elle ne peut pas déterminer si les décisions sous-jacentes sont correctes.

C’est le compromis central derrière le JetBrains Air EAP. Le parallélisme peut réduire le temps d’attente, mais il peut aussi multiplier les obligations de revue. Une équipe qui lance des agents plus vite qu’elle ne peut vérifier leur travail ne fait que créer une file plus longue de correctifs incertains.

Les préréglages introduisent une autre préoccupation de gouvernance. Ils rendent la configuration reproductible, mais les équipes doivent décider quels modèles, permissions et niveaux d’effort conviennent à chaque catégorie de tâche. Un agent bénéficiant d’un accès étendu, adapté à un dépôt de test jetable, peut être inacceptable pour une infrastructure de production.

L’authentification reste également inégale. JetBrains prend en charge plusieurs voies, notamment les connexions gérées par les fournisseurs, les identifiants tiers et JetBrains AI. Toutefois, un abonnement utilisable dans une interface peut ne pas autoriser le même agent dans une autre surface.

Claude illustre cette complexité. JetBrains indique qu’un abonnement Claude peut être utilisé via l’interface terminal, tandis que Claude Agent dans le chat structuré nécessite JetBrains AI ou une clé API Anthropic avec facturation API. Les développeurs doivent vérifier les règles d’autorisation actuelles avant de considérer Air comme un hub universel d’abonnements.

L’exécution dans le cloud ajoute d’autres limites. Les sessions locales s’exécutent sur la machine du développeur, mais les organisations éligibles peuvent envoyer certaines tâches vers l’infrastructure JetBrains. Les exécutions cloud peuvent continuer après la fermeture de l’IDE, même si leur disponibilité dépend des paramètres de l’organisation, de l’hébergement du dépôt et d’un abonnement JetBrains AI.

La gestion des données dépend donc du chemin choisi. JetBrains affirme que les données des agents tiers sont transmises directement à ce fournisseur dans le cadre de l’accord existant de l’utilisateur lorsqu’un abonnement tiers est utilisé. JetBrains AI et les fonctionnalités cloud fonctionnent selon leurs conditions applicables.

L’accord EAP rend également explicite le niveau de maturité. Les logiciels en accès anticipé peuvent contenir des erreurs, se comporter de manière inattendue et évoluer pendant leur développement. Les équipes ne doivent pas considérer le label EAP comme une simple mention de routine lorsque des agents peuvent modifier des fichiers et exécuter des commandes.

Un déploiement prudent commencerait avec des dépôts non critiques et des permissions limitées. Les équipes devraient exiger une revue humaine, conserver des branches récupérables et exécuter des tests indépendants avant la fusion. Le code sensible nécessite une décision claire concernant le fournisseur et le routage des données avant qu’un agent ne reçoive le moindre contexte.

Ces contrôles ne sont pas des arguments contre JetBrains Air dans les IDE. Ce sont les conditions dans lesquelles son modèle parallèle devient utile. L’orchestration ne crée un avantage que lorsqu’elle rend la responsabilité plus visible au lieu de la masquer derrière des tableaux de bord d’activité.

JetBrains transforme ses rivaux en composants remplaçables

Air défie les éditeurs centrés sur les agents en intégrant leurs agents tout en préservant l’environnement de développement JetBrains.

L’adversaire le plus important n’est pas une entreprise en particulier. C’est l’idée que l’agent de programmation devrait posséder l’ensemble de l’espace de travail du développeur.

Un éditeur centré sur les agents peut optimiser chaque interaction autour d’un système intégré. Cela crée une expérience ciblée, mais peut aussi rendre le flux de travail du développeur dépendant du routage des modèles, des décisions d’interface et du calendrier de publication de ce produit.

JetBrains adopte la position opposée. L’IDE reste stable tandis que les agents rivalisent pour accomplir des tâches à l’intérieur. Les développeurs peuvent conserver les outils familiers de navigation, de refactorisation, de débogage et d’inspection tout en changeant le système qui génère le code.

ACP rend cette proposition crédible. Sans protocole partagé, la prise en charge de nombreux agents exigerait une collection croissante d’intégrations privées. Chaque mise à jour de fournisseur pourrait casser un connecteur ou rendre les fonctionnalités incohérentes entre les produits.

Avec ACP, l’unité remplaçable comprend plus qu’un modèle. Un agent embarque sa logique de planification, ses outils, ses permissions, son routage de modèles et son comportement d’interface. Air se connecte à cet ensemble complet via une frontière client commune.

Cela donne à JetBrains un moyen de bénéficier de l’innovation externe. Si Codex progresse dans les modifications à l’échelle d’un dépôt, les utilisateurs d’Air peuvent le choisir. Si Gemini devient meilleur pour une autre charge de travail, l’espace de travail n’a pas besoin de changer. Un agent ACP interne peut traiter des tâches restreintes.

Les cinq agents nommés constituent donc une liste initiale, et non un plafond fixe. Codex, Gemini, GitHub Copilot, Claude Agent et Junie offrent à l’EAP des choix facilement identifiables. Le registre et la configuration personnalisée élargissent l’ensemble possible.

Cursor est un exemple révélateur. Il concurrence JetBrains pour l’attention des développeurs en tant qu’environnement de programmation orienté IA, mais son agent peut également se connecter aux produits JetBrains via ACP. JetBrains peut transformer un produit associé au changement d’éditeur en travailleur disponible au sein de son propre IDE.

Cela ne garantit pas que les utilisateurs resteront. Un produit natif centré sur les agents peut encore offrir une interface plus cohérente, une livraison de fonctionnalités plus rapide ou une intégration plus étroite avec son modèle privilégié. La compatibilité des protocoles rend rarement chaque expérience client identique.

Air doit aussi justifier la complexité du choix. Cinq agents avec des permissions, abonnements, modes et forces différents peuvent devenir plus difficiles à gérer qu’un outil familier. L’espace de travail a besoin d’un état clair, d’une configuration prévisible et d’informations de revue fiables.

La propre gamme de produits de JetBrains ajoute un autre risque. Les utilisateurs rencontrent déjà AI Assistant, Junie, Air, les agents ACP, les comptes fournisseurs et JetBrains AI. Air crée une séparation conceptuelle plus nette, mais la période de transition peut néanmoins sembler fragmentée.

L’entreprise tente de résoudre ce problème en faisant d’Air l’environnement dédié aux flux de travail agentiques tout en conservant AI Assistant pour le chat et l’assistance en ligne. La question de savoir si les utilisateurs comprennent et préfèrent cette répartition sera un résultat clé de l’EAP.

JetBrains a d’abord présenté l’environnement autonome Air comme un espace construit autour des agents plutôt qu’un éditeur auquel l’IA aurait été ajoutée. Son aperçu public de mars a établi la délégation simultanée comme l’idée centrale du produit.

L’intégration de cette expérience dans les IDE établis modifie la proposition. Les développeurs n’ont plus besoin d’adopter une application distincte pour tester le flux de travail. JetBrains peut distribuer Air via des produits déjà ancrés dans les équipes d’ingénierie.

Cet avantage de distribution est significatif, mais l’adoption dépend de l’utilité au quotidien. Les développeurs ne garderont pas une fenêtre d’outil supplémentaire simplement parce qu’elle reconnaît plusieurs agents. Air doit rendre le travail simultané plus facile à comprendre, à examiner et à fusionner que des terminaux séparés ou des applications de fournisseurs.

Ce qu’il faut surveiller après le JetBrains Air EAP

Le prochain test ne porte pas sur le nombre d’agents répertoriés par Air, mais sur la capacité des équipes à accomplir un travail réel avec moins de changements de contexte et des coûts de revue maîtrisables.

Le premier signal est l’adoption dans les dépôts ordinaires. JetBrains doit démontrer que les développeurs continuent d’utiliser Air une fois passée la nouveauté du lancement de sessions parallèles. Une utilisation répétée pour le débogage, la maintenance, les tests et le refactorisation étayerait la thèse de l’orchestration.

La métrique utile n’est pas le nombre de prompts. Les équipes devraient examiner les tâches terminées, les changements acceptés, le temps de revue, les défauts rouverts et l’ampleur des corrections manuelles nécessaires après la fin d’un agent. Un volume élevé de sessions peut masquer une production de faible qualité.

Le deuxième signal est la fiabilité de l’intégration fondée sur les worktrees. Air devrait rendre évidents l’état des branches, les changements non commités, les conflits et les cibles de transfert. Un système conçu pour des agents parallèles doit empêcher les développeurs de perdre du travail ou d’appliquer un correctif correct à la mauvaise branche.

JetBrains documente des garde-fous et des contrôles de revue, mais l’EAP révélera leur comportement sous la pression quotidienne. Les grands dépôts, les fichiers générés, les monorepos et les refactorisations qui se chevauchent constitueront des tests plus difficiles que des démonstrations isolées.

Le troisième signal est la réponse concurrentielle des fournisseurs d’agents et des éditeurs rivaux. Une adoption plus large d’ACP renforcerait la stratégie d’espace de travail ouvert de JetBrains, car les développeurs pourraient déplacer les agents entre les clients compatibles. Les fournisseurs pourraient au contraire privilégier des fonctionnalités propriétaires qui fonctionnent mieux dans leurs propres applications.

La prise en charge de capacités communes comptera autant que le nombre d’agents. Les permissions, appels d’outils, pièces jointes de contexte, rapports de coûts, reprise de session et attribution des diffs doivent avoir un comportement cohérent. Un protocole qui connecte de nombreux agents mais n’expose que leurs fonctionnalités communes les plus limitées restreindrait l’avantage d’Air.

Les organisations devraient aussi surveiller les contrôles administratifs. JetBrains affirme que les entreprises peuvent désactiver Air via l’accès IA géré, mais sa documentation indique que la gestion d’IDE Services n’est pas encore terminée. L’adoption en entreprise exige des politiques claires pour les fournisseurs, les identifiants, les exécutions cloud, le routage des données et l’auditabilité.

La relation entre Air et AI Assistant est un autre signal concret. JetBrains indique qu’AI Assistant restera pris en charge, tandis qu’Air deviendra l’expérience agentique privilégiée. Les prochaines versions montreront si cette répartition se simplifie ou engendre des interfaces qui se chevauchent.

Une transition réussie offrirait aux développeurs un espace clair pour les tâches déléguées et un autre pour une aide contextuelle légère. Une transition confuse obligerait les utilisateurs à comprendre quel plugin gère chaque agent, abonnement ou mode de chat.

Les cinq agents pris en charge révéleront également si la spécialisation apporte une valeur concrète. Les développeurs doivent avoir des raisons observables de choisir Codex pour une tâche, et Junie ou Gemini pour une autre. Dans le cas contraire, le sélecteur deviendra un choix administratif plutôt qu’une fonctionnalité de productivité.

JetBrains Air dans les IDE repose en définitive sur une prémisse défendable : le code généré accroît la valeur du contexte et de la relecture. La question non résolue est de savoir si un IDE peut organiser suffisamment d’agents sans transformer les développeurs en gestionnaires de files d’attente à plein temps.

Essayez l’EAP sur une branche récupérable et confiez-lui une tâche couvrant plusieurs fichiers, tests et étapes de relecture. Comparez ensuite l’ensemble du flux de travail avec votre configuration actuelle d’agents. Air a-t-il réduit les changements de contexte, facilité l’inspection des modifications et préservé le contrôle du dépôt ? Ou a-t-il simplement réuni cinq interfaces dans une seule fenêtre ? Cette réponse, répétée au sein d’équipes réelles, déterminera si JetBrains Air devient la couche opérationnelle du développement agentique ou reste une expérience intéressante.