JetBrains présente Air Teams, un espace de collaboration dédié au développement logiciel avec des agents IA

Permettant de partager les workflows agentiques et d'automatiser les tâches

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 développeurs et aux chefs de projet. L'entreprise a son siège social à Amsterdam et dispose de bureaux en Chine, en Europe et aux États-Unis. JetBrains propose divers environnements de développement intégrés (EDI), tels que IntelliJ IDEA, PyCharm, WebStorm et CLion. Elle a également créé en 2011 le langage de programmation Kotlin, qui peut s'exécuter dans une machine virtuelle Java (JVM).

Début septembre 2026, JetBrains a annoncé JetBrains Air : un système de produits ouvert et cohérent qui s’adresse aux développeurs, aux équipes et aux organisations, dans les EDI JetBrains et au-delà. Il s’agit d’un système qui s’étend sur plusieurs interfaces et plusieurs services. Chaque produit résout un problème distinct, mais les produits fonctionnent mieux ensemble. JetBrains Air intègre JetBrains Air Teams, l’espace de collaboration dédié au développement agentique. Il fournit aux équipes et aux agents le contexte, les environnements, les outils et les instructions partagés dont ils ont besoin pour collaborer efficacement tout au long du cycle de développement.

Air Teams : des développeurs individuels aux équipes

Il y a plusieurs mois, JetBrains a présenté l’application Air comme étant un premier pas dans le développement agentique. En travaillant au développement de Air, JetBrains rapporte deux éléments qui sont devenus de plus en plus évidents. Premièrement, les développeurs n’ont pas besoin d’une énième application autonome : les outils et les agents doivent être intégrés à l’environnement dans lequel ils travaillent déjà. Deuxièmement, à mesure que les développeurs individuels gagnaient en productivité grâce aux agents, le véritable goulot d’étranglement s’est déplacé au niveau de l’équipe.

Dans ce contexte l'équipe de JetBrains a déclaré : « Nous avons donc décidé de faire évoluer Air pour aller au-delà d’une simple application de bureau autonome et proposer un système plus vaste et intégré. Air prend désormais en charge le développement agentique à trois niveaux : développeurs individuels, équipes et organisations. » Air Teams est un espace de travail partagé dans lequel les équipes d’ingénierie exécutent des agents de programmation et réutilisent ce qui fonctionne. Aujourd’hui, la majeure partie du travail agentique se fait sur les ordinateurs portables des développeurs : chacun a sa propre configuration et ses propres prompts, et ce qui fonctionne pour l’un ne se transmet pas facilement au reste de l’équipe. Air Teams rassemble les workflows agentiques en un seul endroit : ce qu’un développeur découvre, toute l’équipe peut l’utiliser.

Air Teams comporte quatre parties :

- Les automatisations prennent en charge de manière autonome les tâches récurrentes, comme les révisions de code, les corrections de tickets et les mises à jour des dépendances. Un événement ou une planification déclenche chaque exécution.

- Les environnements cloud partagés fournissent aux agents les outils, les dépendances et les identifiants dont ils ont besoin pour compiler et tester le code. L’équipe le configure une fois, et tout le monde le réutilise.

- Les tâches cloud s’exécutent dans ces environnements, en parallèle, sans monopoliser l’ordinateur portable de qui que ce soit. Vous pouvez les démarrer et les suivre depuis votre IDE ou votre navigateur, et bientôt depuis votre téléphone.

- Les projets relient le tout, avec des crédits partagés, des rôles clairs et des automatisations qui ne dépendent d’aucune personne en particulier.


Automatisations : fini de surveiller les agents en permanence

Les agents peuvent travailler vite, mais ils attendent encore que des humains démarrent les tâches, fournissent des instructions et passent à l’étape suivante. À un moment donné, orchestrer manuellement chaque exécution devient le goulot d’étranglement.

Les automatisations de Air sont des workflows agentiques qui s’exécutent seuls, dans le cloud, déclenchés par un événement ou une planification plutôt que par une personne. Ce sont des ressources partagées par l’équipe : un développeur peut créer une automatisation, et toute l’équipe peut l’exécuter, la réutiliser et l’améliorer. Ce qui fonctionne bien pour une personne peut devenir une pratique commune à toute l’équipe. Par exemple, une automatisation peut relire chaque nouvelle pull request dès son ouverture, ou mettre à jour les dépendances deux fois par semaine. Air Teams est fourni avec 10 modèles d’automatisation, notamment pour la révision de code, la correction de bugs, la mise à jour des dépendances et la maintenance de la documentation. Vous pouvez utiliser les modèles tels quels ou les adapter à la façon de travailler de votre équipe.


Comment fonctionnent les automatisations

Les automatisations sont conçues pour le travail récurrent qui suit un schéma : une pull request à relire, un ticket étiqueté à examiner, ou des dépendances à vérifier chaque semaine.

Vous configurez quatre éléments une seule fois, et l’automatisation les réutilise à chaque exécution :

Instructions : ce que l’agent doit faire ;

Environnement : où l’agent s’exécute ;

Outils : ce que l’agent peut utiliser, y compris Jira, Figma et Linear via des connecteurs ;

Déclencheur : le moment où l’agent démarre, qu’il s’agisse d’un événement GitHub ou Jira, d’un webhook ou d’une planification, avec d’autres types de déclencheurs à venir.

Voici un exemple : une automatisation déclenchée par l’ajout d’un libellé. Lorsque quelqu’un ajoute le libellé Bug, l’automatisation lance un agent. L’agent lit le ticket et le ticket Jira associé, identifie la cause dans le code, puis ouvre une pull request avec une proposition de correctif qu’un ingénieur pourra vérifier.

Les automatisations font partie d’un projet d’équipe, si bien que toute l’équipe utilise la même automatisation au lieu que chacun crée la sienne. Une fois qu’une automatisation a fait ses preuves, elle peut aller au-delà du projet : l’équipe peut la réutiliser sur un autre dépôt ou l’enregistrer comme un modèle que n’importe qui dans l’organisation peut utiliser tel quel ou adapter.


Exemples d’automatisations

Voici trois automatisations présentées par l'équipe de JetBrains :

Révisions de code. À l’ouverture d’une pull request, un agent analyse le code et les échanges concernés, publie des commentaires directement dans le code ainsi qu’un résumé, et peut approuver la pull request ou demander des modifications. Chaque nouveau commit déclenche une nouvelle exécution : l’agent relit sa révision précédente ainsi que les éventuelles réponses, note les problèmes qui ont été corrigés et ceux qui subsistent, puis réduit ses anciennes révisions afin que seule la plus récente reste visible. Un agent d’IA doit faciliter votre workflow, pas le bloquer. Lorsque vous décidez de traiter un problème dans une pull request distincte, l’agent respecte votre choix et termine sa vérification.

Corrections de tickets. Lorsqu’un membre de l’équipe attribue à un agent une tâche simple et bien définie dans YouTrack, l’agent rassemble le contexte nécessaire, tente d’effectuer la tâche et ouvre une pull request pour revue. Cette même automatisation gère également les retours concernant les révisions. Lorsqu’une pull request ouverte par une automatisation reçoit des commentaires de relecture, qu’ils viennent d’un membre de l’équipe ou de l’automatisation de révision de code, l’agent les prend en compte et fait les corrections.

Mises à jour des dépendances. Deux fois par semaine, un agent met à niveau les dépendances du projet, en ignorant celles que ses instructions indiquent de laisser telles quelles. Il compile le projet et exécute les tests. Lorsqu’une mise à niveau casse quelque chose, l’agent corrige le code concerné sans en modifier le comportement, ou annule la mise à niveau s’il n’y parvient pas. Il ouvre ensuite une pull request répertoriant les mises à niveau appliquées, ignorées ou annulées. Si la pull request précédente n’a pas encore été fusionnée, l’agent la ferme, de sorte que l’équipe dispose toujours d’une seule pull request à jour à fusionner quand elle est prête.

Gardez le contrôle

Une préoccupation légitime avec les agents IA est le bruit : des commentaires que personne ne lit et des pull requests que personne n’a demandées. Les automatisations laissent les décisions à l’équipe. Les ingénieurs choisissent les tâches à confier aux agents et leurs instructions permettent de limiter leur périmètre d’intervention, comme dans les exemples ci-dessus : une seule pull request pour les mises à jour de dépendances et une seule révision en cours par pull request.
Chaque exécution conserve également la conversation complète de l’agent et ses appels d’outils, de sorte que lorsqu’un résultat semble incorrect, l’équipe puisse en comprendre la raison. Chaque modification de code arrive sous forme de pull request, et un ingénieur décide de la fusionner ou non.

Environnements cloud partagés : une configuration que votre équipe et vos agents peuvent réutiliser

Chaque automatisation, comme chaque tâche cloud, s’exécute dans un environnement, et un agent ne peut pas faire mieux que ce que son environnement permet. Avant de pouvoir construire ou tester quoi que ce soit, il lui faut ce dont tout nouvel ingénieur a besoin dès son premier jour : les bons outils, les dépendances, les identifiants et les accès réseau nécessaires. Un petit projet peut fonctionner avec les paramètres par défaut, mais la plupart des bases de code nécessitent des éléments supplémentaires, comme un registre privé de paquets, des versions figées de la chaîne d’outils ou un outil interne de suivi des tickets auquel l’agent doit pouvoir accéder. Quelqu’un doit configurer cela, et une seule fois devrait suffire.


Dans Air Teams, cette configuration se trouve dans un environnement cloud partageable. Vous en créez un pour un dépôt dans votre projet d’équipe. Vous choisissez la taille de la VM, déterminez quels domaines la machine peut atteindre, et ajoutez les variables et les secrets dont le build a besoin. La configuration elle-même se trouve dans votre dépôt, à l’emplacement .air/cloud/startup.sh, ce qui permet à votre équipe de la versionner et de la relire avec le reste du code.

Vous pouvez aussi confier la première ébauche à un agent. Il inspecte le dépôt, exécute réellement l’installation et le build, demande les secrets manquants, puis valide un script de démarrage testé dans une branche distincte. Puis vous vérifiez, comme pour n’importe quelle autre modification. Une fois l’environnement prêt, Air l’enregistre sous forme d’instantané, et vous le partagez avec l’équipe. Partager la configuration ne signifie pas partager les identifiants. Les secrets partagés permettent aux membres de l’équipe et à vos automatisations d’utiliser une valeur sans la voir, tandis que les secrets personnels et l’accès au dépôt restent propres à chaque personne.

À partir de là, les membres de l’équipe choisissent l’environnement dans lequel exécuter leurs tâches dans le cloud, et les automatisations du projet s’exécutent dans cet environnement. Aucun agent ne perd de temps ni de tokens à redécouvrir comment compiler le dépôt. Chaque tâche commence directement par le travail à effectuer.

Tâches cloud : travaillez depuis votre EDI et n’importe quel appareil

Une fois les environnements configurés, vous pouvez commencer à confier du travail aux agents. Choisissez un environnement et un agent, puis décrivez la tâche. Si votre dépôt n’a pas besoin d’une configuration personnalisée, utilisez l’environnement par défaut. Vous pouvez exécuter une tâche localement ou dans le cloud. Le bon choix dépend de la tâche, de la configuration qu’elle nécessite et du degré d’interaction que vous souhaitez avoir avec l’agent.


La différence essentielle est que les tâches cloud ne sont pas liées à l’appareil sur lequel vous les avez démarrées. Vous pouvez démarrer une tâche dans votre IDE et la reprendre plus tard sur le web. L’agent continue de travailler même après que vous ayez fermé votre ordinateur portable.

Projets d’équipe : le travail appartient à l’équipe

Un projet d’équipe est un espace commun pour le travail agentique d’une équipe. Il rassemble les membres de l’équipe, les environnements partagés, les connecteurs MCP et les automatisations. Deux rôles définissent qui peut faire quoi. Les administrateurs du projet gèrent l’appartenance à l’équipe, les environnements, les connecteurs et les automatisations. Ils peuvent également autoriser certains membres à modifier un environnement. Les membres utilisent les environnements partagés, créent leurs propres automatisations et voient les résultats de chaque exécution.

Les automatisations ne dépendent pas nécessairement de la personne qui les a créées. Chaque projet dispose de son propre compte de service et de ses propres crédits IA, et un administrateur décide si les automatisations du projet consomment ces crédits ou ceux de leurs créateurs. Avec les crédits du projet, les automatisations s’exécutent au nom du compte du projet et continuent de fonctionner même après le départ de leur créateur.

Premiers pas avec Air Teams

Avec Air Teams, le travail agentique devient une activité partagée par toute l’équipe. Les automatisations gèrent le travail récurrent, les environnements partagés donnent la même configuration à chaque tâchn, les tâches cloud continuent de s’exécuter après la fermeture de votre ordinateur portable, et les projets d’équipe garantissent que rien de tout cela ne dépende d’une seule personne.

Essayez Air Teams