JetBrains Air : prendre en main le plugin Alpha pas à pas

JetBrains Air permet de lancer un agent de codage depuis un IDE JetBrains, de lui transmettre une sélection du contexte du projet, puis d’examiner ses modifications là où vous parcourez et testez déjà votre code. Pour bien commencer, oubliez les refactorings à grande échelle. Installez Air Alpha, connectez un seul agent, confiez-lui un fichier et un test en échec, puis n’acceptez rien tant que le diff et le résultat du test ne sont pas parfaitement clairs.

JetBrains Air : l’essentiel

Utilisez Air comme un poste de pilotage pour agents, pas comme un simple bouton d’autocomplétion. L’agent effectue le travail ; Air structure la session, lui transmet le contexte de l’IDE et ramène le résultat dans une interface de revue intégrée à l’IDE.

Pour une première session :

1. Installez Air Alpha depuis la Marketplace de l’IDE.
2. Ouvrez un projet jetable, ou une branche dédiée, avec un test que vous pouvez exécuter.
3. Choisissez un preset New Session et conservez Standard Access.
4. Envoyez un premier message et terminez la connexion si Air vous le demande.
5. Joignez le fichier utile avec @file:.
6. Demandez une petite correction accompagnée d’un test.
7. Examinez chaque fichier modifié dans Agent Sessions.
8. Exécutez vous-même le test, puis conservez, retouchez, commitez ou annulez la modification.

Voilà toute la boucle qui compte. Les sessions parallèles, les agents supplémentaires, les contrôles d’organisation et le transfert vers le cloud peuvent attendre que ce fonctionnement soit digne de confiance.

À quoi sert vraiment JetBrains Air ?

Air fait le lien entre votre projet JetBrains et un ou plusieurs agents de codage. Imaginez un poste de contrôle dans un atelier de prototypage : l’agent dépose une pièce sur l’établi, mais l’IDE reste l’endroit où vous vérifiez les cotes, l’ajustement et la décision finale.

La version du 22 septembre a élargi Air en un système composé de trois éléments nommés : Air dans les IDE JetBrains pour le travail individuel, Air Teams pour la coordination et l’automatisation, et Air Governance pour les règles, la visibilité et le contrôle des coûts. Ce guide reste centré sur le parcours local que vous pouvez réellement exécuter, le plugin Air Alpha pour IDE.

Le plugin pour IDE n’est pas un nouveau modèle de fondation. Il peut faire fonctionner Codex, Gemini, GitHub Copilot, Claude et Junie dès l’installation. Selon JetBrains, d’autres agents peuvent aussi se connecter via ACP. ACP, ou Agent Client Protocol, joue le rôle d’interface commune entre l’IDE et l’ensemble du dispositif de l’agent, outils et routage des modèles compris.

La page actuelle d’Air pour les IDE présente toujours le transfert du local vers le cloud comme une fonctionnalité à venir. Pour un premier essai fiable, gardez une tâche locale et limitée.

Ce qu’il faut vérifier avant l’installation

Air Alpha est une version alpha publique, pas un petit utilitaire stable et discret. JetBrains prévient que l’interface et le comportement peuvent évoluer, avec des mises à jour attendues environ chaque semaine. Avant de chercher une autre cause à un problème, vérifiez la compatibilité.

Au 23 septembre 2026, le paquet Marketplace destiné à la branche 2026.2 était Air 262.8665.463. Il prend en charge IntelliJ IDEA 2026.2 à 2026.2.3, ainsi que les versions 2026.2 correspondantes des IDE JetBrains répertoriés. La Marketplace propose également des builds pour la branche 2026.3 : le numéro exact du plugin peut donc varier selon la branche de votre IDE.

Vérification de compatibilité effectuée pour ce guide

IntelliJ IDEA 2026.2.3, build IU-262.10968.63, a chargé Air 262.8665.463 dans un profil isolé et indexé un projet Node jetable sans erreur de plugin. L’agent détecté était codex-cli 0.153.4, mais il n’était pas connecté et la machine hôte ne disposait d’aucune session graphique. Nous n’affirmons donc pas avoir exécuté une tâche Air interactive, obtenu un diff généré ou fait réussir un test écrit par l’agent. Les étapes d’interface ci-dessous suivent le guide de démarrage actuel de JetBrains et les libellés inclus dans cette version du plugin.

Comment utiliser JetBrains Air, étape par étape

1. Installer Air Alpha

Ouvrez les réglages de l’IDE, choisissez Plugins, passez dans Marketplace, recherchez Air Alpha, puis cliquez sur Install. Redémarrez l’IDE s’il le demande.

Air est gratuit. En revanche, l’agent qui fonctionne derrière peut nécessiter un compte, un abonnement ou une facturation à l’API. Si le coût vous empêche de trancher, JetBrains Air est-il gratuit ? distingue le prix du plugin de celui de l’agent.

2. Partir d’un échec simple à reproduire

Commencez dans un projet existant que vous pouvez supprimer ou réinitialiser sans conséquence. Une bonne première tâche se limite à un fichier pertinent, un échec observable et une commande qui prouve si la correction fonctionne.

Il peut s’agir d’un utilitaire de slug qui gère mal les espaces répétés, d’un formateur auquel il manque un cas limite ou d’une petite fonction de validation avec un test unitaire en échec. Pour ce premier essai, évitez les migrations, l’authentification, le code de déploiement et les mises à niveau massives de dépendances.

Notez l’état initial avant d’ouvrir une session :

• la branche actuelle ou le worktree jetable ;
• la commande de test exacte ;
• le fait que ce test réussisse ou échoue à cet instant ;
• les fichiers que la tâche devrait modifier.

La revue devient ainsi une comparaison factuelle, pas une impression.

3. Choisir un preset New Session

Dans la barre d’outils principale, le bouton New Session lance le preset sélectionné. Utilisez son chevron pour en choisir un autre.

Un preset est une configuration de lancement enregistrée. Il détermine l’agent et peut présélectionner le modèle, le niveau de raisonnement, le niveau d’accès et l’interface de session. Air affiche les agents détectés sur la machine à côté des presets intégrés. Si l’agent sélectionné manque, le plugin peut proposer de l’installer.

Pour une première tâche, choisissez Standard Access. Dans la version actuelle du plugin, Standard Access autorise l’agent à lire, modifier et exécuter des commandes dans le projet ; l’accès à des fichiers extérieurs au projet ou au réseau demande votre validation. Full Access supprime ces demandes de validation pour le réseau et pour les modifications partout sur la machine. Ce n’est pas un bon réglage par défaut pour une première session.

4. Envoyer le premier message et autoriser l’agent

L’autorisation intervient au moment où l’agent en a réellement besoin. Saisissez un premier message court, puis appuyez sur Entrée. Si Air trouve des identifiants déjà utilisés par l’agent sur votre machine, la session se poursuit. Sinon, il affiche Choose a sign-in method to continue.

Le parcours disponible dépend de l’agent :

• la connexion à un agent peut se poursuivre dans un navigateur ou un terminal ;
• une licence JetBrains AI ou un espace de travail d’organisation éligible peut fournir des crédits ;
• Add an AI provider ouvre Tools | Air | Accounts afin de renseigner un abonnement tiers ou une clé d’API.

Dans Accounts, choisissez More Providers, ajoutez les identifiants nécessaires, cliquez sur Test Connection, enregistrez avec OK, puis revenez à la session pour sélectionner ce fournisseur.

Ne collez jamais un secret dans le prompt de la tâche. Les identifiants ont leur place dans le parcours de connexion au fournisseur.

5. Ne fournir que le contexte nécessaire

Air peut joindre des fichiers, des commits et des skills depuis le contrôle d’ajout de contexte. Vous pouvez aussi saisir @file: pour un fichier ou @folder: pour un dossier. La différence compte : joindre le seul fichier utile revient à donner au mécanicien la pièce défectueuse ; joindre tout le dépôt, c’est vider le garage sur son établi.

Pour le premier essai, joignez le fichier d’implémentation et indiquez la commande de test. N’ajoutez un fichier de test que si l’agent doit comprendre une convention existante.

6. Demander une modification bornée et sa preuve

Un bon prompt précise le défaut, le périmètre autorisé et la commande de vérification. Par exemple :

Corrige la gestion des espaces répétés dans @file:src/slug.js. Ajoute ou adapte le plus petit test pertinent. Exécute node --test. Ne modifie pas les dépendances et ne touche pas aux fichiers sans rapport. Si la commande de test ne peut pas s’exécuter, arrête-toi et explique pourquoi.

Ce prompt donne une ligne d’arrivée à l’agent. « Améliore cet utilitaire » n’en donne aucune.

7. Suivre la session sans noter le récit

L’agent signale son avancée et peut poser des questions. Répondez lorsqu’il lui manque une exigence, n’approuvez que les actions que vous comprenez et surveillez les demandes inattendues d’accès au réseau ou à des fichiers extérieurs au projet.

Le texte de progression apporte du contexte, mais ne constitue pas une preuve. La preuve, c’est le diff obtenu, accompagné d’un test que vous pouvez relancer.

8. Relire la modification dans Agent Sessions

Ouvrez Agent Sessions, puis développez la session terminée. Consultez le diff de chaque fichier modifié. La version actuelle comprend les actions Show Diff, Generate summary... et Revert. Le guide de démarrage de JetBrains indique que vous pouvez conserver, modifier, commiter ou annuler les fichiers touchés.

Procédez dans cet ordre :

1. Périmètre : seuls les fichiers attendus ont-ils changé ?
2. Comportement : l’implémentation corrige-t-elle exactement l’échec visé ?
3. Qualité du test : le nouveau test échouerait-il sans la correction ?
4. Effets de bord : la configuration, les dépendances ou les interfaces publiques ont-elles bougé ?
5. Vérification : le test réussit-il lorsque vous l’exécutez hors du récit de l’agent ?

Si le diff est presque juste, corrigez-le vous-même ou laissez un retour précis pour une nouvelle itération. Si le périmètre vous surprend, annulez et recommencez avec un prompt plus strict. Ne transformez pas une explication crédible en commit sans preuve.

Le calcul économique

Air modifie le poste d’orchestration, pas le coût de l’intelligence sous-jacente. Le plugin ajoute $0 de dépense logicielle, tandis que l’agent connecté peut consommer un abonnement existant, un solde d’API ou des crédits JetBrains AI.

C’est un point important pour une équipe qui paie déjà des agents. Une seconde interface de pilotage entraîne souvent l’achat d’une licence supplémentaire avant même de savoir si elle améliore la revue. Comme repère public, GitHub affiche actuellement Copilot Business à $19 par utilisateur et par mois, et Enterprise à $39. Dix licences Business reviennent à $190 par mois avant les usages additionnels. Air peut connecter les agents pris en charge sans ajouter de frais pour le plugin Air, mais il ne fait disparaître ni la licence de l’IDE, ni l’abonnement au fournisseur, ni l’usage de l’API, ni le temps humain consacré à la revue.

La vraie question budgétaire est donc précise : une interface locale gratuite peut-elle rendre les dépenses d’agents existantes plus faciles à diriger et à vérifier ? Testez cette hypothèse avec une seule équipe et une seule catégorie de tâches avant tout achat ou toute standardisation supplémentaire.

Six cas d’usage, classés selon leurs principaux bénéficiaires

1. Les équipes JetBrains qui paient déjà plusieurs agents

Une équipe d’ingénierie qui utilise Codex pour certains travaux et Claude pour d’autres peut les lancer depuis le même environnement d’IDE, leur joindre le même contexte de projet et examiner les fichiers modifiés au même endroit. Le bénéfice n’est pas, par défaut, une baisse du coût des tokens. Il tient à la réduction des changements d’outil et à une méthode de revue cohérente autour d’abonnements déjà en place.

2. Les mainteneurs qui traitent de petits défauts testables

Un mainteneur peut joindre l’utilitaire en échec, décrire une régression précise, exiger un test ciblé et contrôler le diff avant qu’il n’atteigne une branche. L’intérêt apparaît lorsque le diagnostic est clair, mais que la correction mécanique empiète sur un travail plus exigeant.

3. Les consultants qui découvrent le code d’un client

Un consultant peut s’appuyer sur la navigation de l’IDE pour inspecter les symboles, ne joindre que les fichiers pertinents et confier à l’agent une modification limitée. En travaillant dans une branche jetable avec Standard Access, il réduit le risque que des conventions encore inconnues produisent une intervention tentaculaire. Le gain vient d’une prise en main plus rapide, sans prétendre que l’agent connaît les règles implicites du client.

4. Les ingénieurs QA qui transforment un bug reproductible en test de régression

Un ingénieur QA capable de reproduire un bug peut joindre le fichier concerné et la zone de tests associée, demander le plus petit test de régression possible, puis vérifier que celui-ci capture réellement l’échec. L’avantage est un passage plus court entre la reproduction et un livrable technique prêt à être relu.

5. Les développeurs seniors qui enseignent la revue à partir de vrais diffs

Un développeur senior peut laisser un agent proposer une petite implémentation, puis guider un collègue moins expérimenté à travers le périmètre, les hypothèses, la conception du test et la décision d’annuler, le tout dans l’IDE familier. Le résultat ne se résume pas au code : c’est un exercice de revue visible, fondé sur un véritable jeu de modifications.

6. Les équipes plateforme qui comparent des agents sur une même tâche

Une équipe plateforme peut exécuter la même tâche bornée avec plusieurs presets, puis comparer les fichiers touchés, le comportement des tests, les autorisations et l’effort de revue. Cette évaluation est plus utile qu’une comparaison de réponses dans un chat, car l’unité de mesure devient une modification vérifiée dans le même dépôt.

Deux produits à construire autour de ce workflow

1. Un compagnon de preuves de revue pour les modifications produites par des agents

C’est l’opportunité la plus solide. Construisez un petit outil complémentaire qui transforme une session d’agent en dossier de revue : tâche, contexte joint, fichiers modifiés, commande de test, résultat, décision humaine et référence du commit final. Les responsables techniques et les équipes réglementées paieraient pour disposer d’un relevé propre, indépendant de l’agent ayant produit le code.

La demande est assez précise pour compter : ai powered code review platform totalise environ 1,900 recherches mensuelles aux États-Unis, avec une intention commerciale. Les tarifs de GitHub, $19 pour Business et $39 pour Enterprise, montrent également que les équipes consacrent déjà un budget à l’assistance au codage et à sa gouvernance.

La plus petite version commercialisable n’a pas besoin de piloter l’agent. Elle peut ingérer un diff et la sortie des tests, imposer une checklist au reviewer, puis exporter un relevé signé au format Markdown ou JSON. Le risque vient de la plateforme : Air est en alpha, ses interfaces peuvent changer chaque semaine et JetBrains peut enrichir lui-même les fonctions de preuve ou d’audit. L’avantage défendable devra reposer sur des règles multi-agents et des rapports durables, pas sur un simple bouton greffé à un IDE.

2. Un conseiller de configuration d’agents adapté à chaque dépôt

Construisez un outil d’onboarding qui analyse les langages, les commandes de test, les chemins sensibles et les règles de contribution d’un dépôt, puis recommande un modèle de première tâche et des réglages de preset prudents. Il s’adresserait aux équipes qui déploient des agents sur des dépôts hétérogènes, là où chaque développeur répète aujourd’hui le même travail de configuration.

La demande générale est importante : ai coding assistant totalise environ 18,100 recherches mensuelles aux États-Unis, contre environ 8,100 pour ai powered coding agent. Le MVP peut prendre la forme d’un questionnaire sur le dépôt, complété par des notes de configuration générées, des prompts de démarrage bornés et une checklist de smoke tests. Une intégration profonde à l’IDE n’est pas nécessaire au départ.

La difficulté tient à la défendabilité. JetBrains, les fournisseurs d’agents ou les modèles de dépôt peuvent intégrer des conseils génériques. Pour rester viable, le produit doit contrôler des règles propres à l’organisation et prouver que ses recommandations réduisent les échecs et les modifications hors périmètre.

Limites et verdict sans détour

Air est surtout utile si vous préférez déjà un IDE JetBrains et souhaitez choisir entre plusieurs agents sans renoncer à une revue intégrée à l’IDE. Il ne justifie pas de déléguer une modification risquée que vous ne savez pas vérifier.

Trois contraintes comptent aujourd’hui :

• C’est une version alpha. Les libellés et le comportement peuvent évoluer au rythme d’une publication environ chaque semaine.
• Le plugin est gratuit, pas le travail. L’autorisation de l’agent, les abonnements, l’usage de l’API, la licence de l’IDE et la revue humaine restent des coûts distincts.
• Le local est le point de départ fiable. La page consacrée à l’IDE présente encore le transfert vers le cloud comme une fonction à venir ; ne construisez donc pas votre premier workflow autour d’une tâche censée continuer après la fermeture de l’ordinateur.

Standard Access n’est pas non plus un mode lecture seule. Il permet les modifications et les commandes dans le projet. Travaillez dans une branche ou un worktree jetable, examinez le diff et relancez vous-même le test.

Le verdict est simple : Air mérite un essai sur une petite modification si JetBrains est déjà votre environnement de travail quotidien. Il est encore trop tôt pour en faire le passage obligé des dépôts sensibles sans plan de retour arrière, règles pour les fournisseurs et preuves de revue.

Le test à lancer lundi

Choisissez un bug vérifiable avec une seule commande de test. Placez-le sur une branche jetable, installez la version d’Air Alpha correspondant à l’IDE sur la machine d’un développeur, sélectionnez Standard Access, joignez un seul fichier pertinent et demandez la plus petite correction possible avec un test de régression. Ne conservez la modification que si le diff reste limité et si le test réussit lorsque vous l’exécutez vous-même. Cette boucle vous en apprendra davantage qu’une semaine de démonstrations d’agents.

À quoi sert JetBrains Air ?

JetBrains Air coordonne les agents de codage, leur contexte, leurs sessions et leur revue dans les IDE JetBrains et au-delà. Dans le plugin local, vous sélectionnez un agent, lui envoyez une tâche avec le contexte du projet, puis examinez les modifications obtenues dans Agent Sessions.

Quelles sont les principales différences entre JetBrains Air et Claude Code ?

Claude Code est un agent de codage. Air est une interface de pilotage et de revue multi-agents capable d’exécuter Claude aux côtés de Codex, Junie, GitHub Copilot, Gemini, OpenCode et d’agents compatibles ACP, selon les intégrations et autorisations disponibles.

Quel est le meilleur IDE pour le codage agentique ?

Il n’existe pas de vainqueur universel. Air est convaincant lorsque l’équipe dépend déjà de la navigation, des inspections et des outils de diff de JetBrains. Le meilleur choix reste l’environnement dans lequel vous pouvez encadrer, examiner, tester et annuler de manière fiable le travail d’un agent.

JetBrains est-il gratuit ?

Le plugin Air Alpha est gratuit. Votre IDE JetBrains et l’agent utilisé derrière Air peuvent entraîner des frais distincts de licence, d’abonnement ou d’API.

Pour mettre en place un workflow d’agents sûr, adapté à vos dépôts et à vos règles de revue, découvrez notre offre de développement d’agents IA.