Pourquoi JetBrains Air mérite l’attention d’un ingénieur senior
JetBrains vient de lancer Air, un système global dédié au développement logiciel agentique qui relie l’IDE, les agents de codage, la coordination d’équipe, la gouvernance et la visibilité des coûts. Ce qui est intéressant, ce n’est pas qu’un autre éditeur ait annoncé un produit de codage basé sur l’IA. Ce qui est intéressant, c’est le cadre de réflexion : l’IA peut produire du code, mais les organisations doivent toujours produire des logiciels. Cette distinction est importante pour les ingénieurs seniors, car la plupart des gains de productivité réels ne proviennent plus du fait de demander à un modèle d’écrire une fonction. Ils proviennent de la conception d’un workflow dans lequel les agents peuvent effectuer un travail utile tandis que les humains restent maîtres de l’architecture, de la révision, des risques et de la mise en production.
Air se positionne comme une famille de produits multi-surfaces plutôt que comme un simple chatbot. Elle inclut des capacités d’agents au sein des IDE JetBrains, une coordination au niveau de l’équipe pour le travail effectué par les humains et les agents, ainsi que des contrôles de gouvernance issus de JetBrains Central. Elle s’appuie également sur l’Agent Client Protocol, un protocole ouvert créé en collaboration avec Zed, afin que différents agents de codage puissent se connecter à des éditeurs compatibles sans que chaque éditeur ne doive développer un plugin spécifique. Concrètement, JetBrains affirme que l’avenir du développement sera multi-agents et multi-éditeurs, mais que les équipes professionnelles ont besoin d’un espace unique pour visualiser ce qui se passe.
Cette thèse est très proche de la manière dont les équipes logicielles expérimentées travaillent déjà. Un développeur senior souhaite rarement un assistant de type « boîte noire » qui réécrit discrètement un référentiel. Nous voulons un collaborateur rapide capable d’inspecter le code, de rédiger des modifications, d’exécuter des commandes, de générer un diff, d’expliquer les compromis, puis de s’arrêter à une limite où un humain décide de ce qui est acceptable. Air est un outil utile à suivre car il s’efforce de rendre cette limite visible : les agents peuvent être pilotés depuis l’IDE, leur travail peut être coordonné au niveau de l’équipe, et leur activité peut être régie au niveau de l’organisation.
En quoi consiste cet outil ?
JetBrains Air s’apparente avant tout à une couche opérationnelle dédiée au développement assisté par l’IA, s’articulant autour des outils de développement existants de JetBrains. Au niveau individuel, Air, intégré aux IDE de JetBrains, offre aux développeurs un espace pour diriger des agents de codage tout en tirant parti de l’intelligence de code déterministe d’IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, PhpStorm et du reste de la famille JetBrains. Au niveau de l’équipe, Air Teams est conçu pour coordonner les workflows de livraison logicielle auxquels participent à la fois des humains et des agents autonomes. Au niveau de l’organisation, Air Governance, anciennement JetBrains Central, assure la définition des politiques, l’auditabilité, la gestion des coûts, la visibilité et la responsabilité pour le travail assisté par l’IA.
Le produit est également connecté à Junie, l’agent de codage de JetBrains destiné au développement professionnel, mais Air ne se limite pas à Junie. Les pages consacrées à l’IA de JetBrains décrivent la prise en charge de Junie, d’OpenAI Codex, de Claude Agent, de Gemini CLI, de GitHub Copilot, de Cursor et d’autres agents via des intégrations compatibles ACP. Il s’agit là d’un choix architectural important. Si votre équipe compte déjà des développeurs utilisant différents modèles pour différentes tâches, l’imposition d’un fournisseur unique peut s’avérer irréaliste. Une couche de gouvernance capable d’observer et de contrôler plusieurs agents correspond davantage à la manière dont l’adoption se déroule réellement.
Pour une utilisation au quotidien, la documentation relative à l’assistant IA donne un aperçu concret de l’expérience au sein de l’IDE. Les développeurs peuvent utiliser un chat contextuel, invoquer des agents de codage pour des tâches en plusieurs étapes, connecter des agents externes via l’ACP, utiliser des outils MCP, importer leurs propres clés de modèle lorsque cela est pris en charge, et revoir ou annuler des modifications. L’important est que l’agent ne fonctionne pas dans un onglet de navigateur isolé avec un contexte vague. Il se trouve aux côtés de la structure du projet, des symboles, des inspections, des refactorisations, de l’état du contrôle de version, des tests et des outils de build.
Comment l’installer ou y accéder
Le déploiement d’Air se fera progressivement au fil d’une série de versions ; le moyen le plus sûr de l’adopter dès aujourd’hui est donc de commencer par les composants que JetBrains documente déjà publiquement. Si vous utilisez régulièrement les IDE JetBrains, mettez à jour votre IDE via JetBrains Toolbox ou le programme de mise à jour habituel de l’IDE, puis installez ou activez AI Assistant lorsqu’il est disponible. JetBrains précise que l’AI Assistant n’est pas actif par défaut dans IntelliJ IDEA ; vous devez installer le plugin, activer un abonnement JetBrains AI ou un autre moyen d’authentification pris en charge, puis accepter explicitement les conditions d’utilisation de l’IA avant qu’il ne puisse accéder au contexte du projet.
Pour les workflows d’agents, ouvrez la documentation de l’Assistant IA et consultez les pages consacrées aux agents de codage, à Junie, à Codex, à Claude Agent, à GitHub Copilot, à ACP, à MCP et aux scénarios d’activation. Le modèle d’accès est important car les équipes peuvent choisir différents modes : un abonnement JetBrains AI pour une expérience sur mesure, l’utilisation de votre propre clé pour les fournisseurs approuvés, l’autorisation directe accordée à un fournisseur d’agents, ou encore des agents locaux et externes lorsque la politique l’autorise. Dans un contexte d’entreprise, ne laissez pas chaque développeur improviser seul à ce sujet. Déterminez quels fournisseurs sont autorisés, quels dépôts sont concernés, quelles données peuvent quitter l’environnement et quelles commandes nécessitent une validation manuelle.
Si vous vous intéressez davantage à l’interopérabilité qu’à JetBrains en particulier, consultez la documentation ACP. L’ACP normalise la communication entre les éditeurs et les agents à l’aide de sous-processus locaux et, de plus en plus, de transports à distance. Cela signifie qu’un éditeur compatible peut héberger un agent sans avoir besoin d’une intégration sur mesure pour chaque association. Pour les équipes chargées des plateformes, cela mérite d’être suivi de près, car cela permet d’obtenir une interface plus fluide entre l’environnement de travail du développeur et le harnais de l’agent. Les agents internes peuvent cibler le protocole plutôt que chaque IDE séparément.
Cas d’utilisation concrets pour un développeur senior
1. Orientation vers le référentiel avant de toucher au code. Un goulot d’étranglement courant chez les ingénieurs seniors n’est pas l’écriture de la première ligne de code, mais la construction d’un modèle mental fiable d’un service. Un agent connecté au contexte de l’IDE peut résumer les limites des modules, identifier où une fonctionnalité est implémentée, lister les tests couvrant ce domaine et signaler les dépendances à risque. C’est toujours l’humain qui décide de la conception, mais la phase de recherche est considérablement raccourcie.
2. Refactoring multi-fichiers en toute sécurité. Les IDE JetBrains sont performants car ils combinent syntaxe, informations de type, index, inspections et opérations de refactoring. Un agent capable d’exploiter cet environnement est mieux adapté à des modifications telles que le renommage d’un concept de domaine, la mise à jour des emplacements d’appel d’API ou la migration d’un format de configuration. Le gain de productivité intervient lorsque l’agent rédige les modifications techniques et les mises à jour des tests, tandis que l’ingénieur senior vérifie l’intention sémantique, la compatibilité et les risques liés à la migration.
3. Génération de tests et triage des échecs. Les agents sont utiles lorsqu’ils peuvent exécuter des tests, analyser les échecs et proposer un petit correctif. Dans un workflow de type Air, un développeur peut déléguer la boucle répétitive consistant à : reproduire le test qui échoue, examiner les traces de pile, identifier la régression probable et préparer une solution candidate. L’humain doit toujours examiner le diff final et ajouter les assertions manquantes, mais la boucle d’investigation fastidieuse peut passer au second plan.
4. Préparation de la pull request. Une bonne pull request ne se résume pas à un diff. Elle nécessite une description, des preuves issues des tests, des notes sur les risques, une réflexion sur la restauration en cas d’échec et des liens vers les tickets pertinents. Un agent disposant du contexte du dépôt peut rédiger ce contenu à partir des modifications réelles. Il s’agit d’un cas d’utilisation à faible risque et à fort rendement, car l’humain peut rapidement modifier le texte tout en bénéficiant d’un ensemble de révision plus cohérent.
5. Tâches de maintenance en arrière-plan. L’annonce d’Air souligne que le travail sera de plus en plus déclenché par des événements du référentiel, des calendriers et des processus de livraison, et non plus uniquement par une invite dans un éditeur. Cela ouvre la voie à des utilisations pratiques telles que la préparation des mises à jour de dépendances, le regroupement des tests instables, les vérifications de dérive de la documentation, les inventaires de migration et les brouillons de notes de version. Ces tâches sont importantes mais faciles à reporter ; les agents peuvent les préparer en vue d’une révision humaine.
6. Gouvernance des activités des agents au niveau de l’équipe. Le véritable problème d’évolutivité ne réside pas dans la capacité d’un développeur à tirer profit d’un agent, mais dans la capacité d’une équipe à comprendre ce que tous ces agents ont fait, combien ils ont coûté, quel code ils ont modifié et qui a validé le résultat. Air Governance est pertinent car il traite la visibilité, la politique et la responsabilité comme des préoccupations de premier ordre, et non comme des considérations secondaires.
D’où provient le gain de productivité ?
Le gain réaliste ne consiste pas à « remplacer les développeurs ». Il s’agit de réduire le temps consacré par les compétences hautement qualifiées à des boucles ne nécessitant que peu de jugement. Les ingénieurs seniors perdent des heures à naviguer dans la base de code, à effectuer des modifications répétitives, à mettre en place la structure initiale des tests, à rédiger des descriptions de pull requests, à rédiger des notes de mise à jour et à mener des investigations qui suivent un schéma familier. Si un agent peut effectuer 60 % de ce travail et laisser un diff lisible accompagné d’une explication, le temps de l’ingénieur est alors consacré à déterminer si la modification est correcte.
Il y a également un gain en termes de coordination. Lorsque les agents travaillent dans des outils isolés, les connaissances se fragmentent rapidement : une conversation dans un terminal, une dans un navigateur, une dans une application de bureau et une dans une pull request. La proposition de valeur d’Air réside dans le fait que le travail des agents doit être visible dans le même système que celui où les équipes planifient, révisent et gèrent les logiciels. C’est important car le coût de vérification des résultats générés par l’IA peut annuler le bénéfice de cette génération si le travail ne peut pas être retracé.
Pour les organisations qui expérimentent déjà plusieurs outils, l’aspect « multi-fournisseurs » est peut-être l’aspect le plus important. Différents modèles et agents excellent dans différentes tâches, et les classements évoluent rapidement. Une équipe de direction doit éviter de verrouiller son processus sur l’avantage actuel d’un seul fournisseur. Une couche gouvernable, basée sur des protocoles, offre aux équipes davantage de liberté pour choisir l’agent adapté à une tâche tout en préservant des contrôles partagés.
Limites et risques
Air est un système stratégique, pas un filet de sécurité magique. Certains éléments sont déjà disponibles, d’autres sont en cours de déploiement, et les équipes doivent consulter les pages actuelles de JetBrains avant de supposer qu’une fonctionnalité spécifique est généralement disponible dans leur environnement. L’annonce précise clairement que le système évoluera au fil du temps. Considérez l’adoption précoce comme un déploiement technique, et non comme un simple bouton à activer à l’échelle de l’entreprise.
Les résultats des agents restent également probabilistes. Même avec l’intelligence de l’IDE, les agents peuvent émettre des hypothèses plausibles mais erronées, surajuster les tests, passer à côté de contraintes métier ou introduire de subtils écarts architecturaux. Plus ils sont capables de générer de code, plus il devient important de limiter la taille des modifications, d’exiger des tests, de préserver la responsabilité des propriétaires de code et d’utiliser la protection des branches. Un développeur senior doit optimiser le flux de travail afin que les agents produisent des incréments vérifiables, et non des correctifs gigantesques sans propriétaire.
La gouvernance peut échouer si elle se réduit à un simple rapport a posteriori. Avant de généraliser l’utilisation des agents, définissez une politique : quels dépôts sont autorisés, quelles informations confidentielles sont bloquées, quelles commandes nécessitent une validation, quelles données peuvent être envoyées aux fournisseurs de cloud, comment les journaux sont conservés et qui est responsable du travail fusionné. La gouvernance de l’IA doit être étroitement liée aux pratiques d’ingénierie, et non pas un document rédigé après coup, une fois l’adoption déjà effective.
Une démarche d’adoption concrète
Commencez par un seul dépôt et un seul workflow. Par exemple, utilisez AI Assistant ou un agent connecté à l’ACP pour analyser les tests instables, rédiger des tests unitaires manquants ou préparer des pull requests de mise à jour des dépendances. Mesurez la durée du cycle, l’effort de révision, le taux de défauts et la satisfaction des développeurs. Exigez que chaque modification produite par un agent inclue des preuves de test et une brève explication des modifications apportées. Laissez au réviseur humain la responsabilité des décisions de fusion.
Ensuite, normalisez les instructions de projet que reçoivent les agents. Documentez les commandes de compilation, les commandes de test, le style de code, les limites architecturales, les contraintes de sécurité et les exigences de mise en production. Si vous utilisez MCP ou des outils externes, indiquez précisément lesquels sont approuvés. La qualité du travail des agents s’améliore lorsque l’environnement leur indique comment l’équipe fonctionne réellement, plutôt que d’obliger chaque développeur à répéter les règles dans le chat.
Enfin, mettez en place la couche de gouvernance avant d’étendre l’utilisation. Si les agents doivent travailler sur plusieurs dépôts, la direction doit disposer d’une visibilité sur les coûts, les accès, les pistes d’audit et les résultats. JetBrains Air arrive à point nommé, car il prend en compte cette couche organisationnelle. Les gagnants du développement assisté par l’IA ne seront pas les équipes qui génèrent le plus de code. Ce seront les équipes capables de déléguer la mise en œuvre en toute sécurité tout en laissant aux humains le contrôle des logiciels qu’elles livrent.
