GitHub Copilot arrive dans JetBrains Air : les tâches cloud utilisent l'offre Copilot et tournent dans Docker sur une VM neuve, mais Air n'affiche ni l'usage Copilot ni plafond de dépenses

Le 3 novembre 2026, GitHub a annoncé dans son journal des modifications que GitHub Copilot est désormais disponible dans JetBrains Air. JetBrains Air est un environnement de développement agentique, et l'intégration utilise l'Agent Client Protocol (ACP). Les développeurs peuvent confier des tâches de code, guider l'exécution et relire les résultats avec Copilot dans Air, que les tâches s'exécutent dans leur IDE JetBrains ou dans le cloud. GitHub précise que Copilot dans Air peut s'utiliser avec le plugin GitHub Copilot existant, afin que les équipes choisissent le flux de travail qui leur convient.

Trois changements sont listés. Copilot apparaît dans le sélecteur d'agents d'Air, et les tâches utilisent l'abonnement Copilot existant du développeur. Air peut suivre plusieurs sessions d'agent à la fois, utiliser le contexte du projet et les outils de l'IDE, et afficher les modifications à côté du code pour la relecture. Enfin, les tâches cloud s'exécutent dans des environnements cloud isolés via Air Teams, depuis l'IDE ou le navigateur, sur l'offre Copilot et non sur les crédits JetBrains AI. Ce dernier point compte pour les budgets : l'usage cloud est facturé via l'abonnement Copilot.

La configuration diffère selon le mode. Pour les tâches locales, le développeur installe Air dans l'IDE JetBrains, choisit GitHub Copilot et connecte un compte Copilot. Pour les tâches cloud, il faut trois choses : un compte JetBrains dans une organisation professionnelle où Air Teams est activé, un abonnement GitHub Copilot, et Copilot activé par l'administrateur d'Air. Dans le navigateur, l'utilisateur connecte GitHub sous Paramètres puis fournisseurs de VCS, crée une tâche, choisit un dépôt et une branche distante, sélectionne Copilot et envoie une consigne. Dans l'IDE, il choisit Cloud dans le sélecteur d'environnement.

Quant à l'endroit où s'exécutent les tâches cloud, le journal indique que Copilot travaille dans un conteneur Docker sur une machine virtuelle neuve, que tout le trafic passe par un proxy et qu'aucun état n'est conservé entre les tâches, si bien que Copilot peut compiler, tester et installer des paquets sans modifier l'environnement local. Un article du blog de JetBrains du 14 octobre détaille la même conception. La machine virtuelle est considérée comme non fiable et n'est pas réutilisée entre les tâches. Par défaut, le proxy n'autorise que des connexions vers une liste prédéfinie de domaines de contrôle de source et de registres de paquets de confiance, comme npm, et les administrateurs peuvent ajouter des domaines, autoriser tous les domaines ou couper l'accès à Internet. Les secrets sont stockés chiffrés et exposés à la tâche comme variables d'environnement, et chaque tâche agit dans les droits de dépôt du développeur. Cet article précise aussi que les agents cloud étaient en préversion, ouverts aux utilisateurs d'organisations, avec une diffusion plus large aux particuliers prévue plus tard, et que les microVM restaient « bientôt disponibles ».

La section « Cloud task considerations » est la plus utile aux administrateurs, car elle énumère des limites. Connecter Copilot à Air ne demande pas de permissions Copilot, et Air peut ne vérifier la disponibilité de l'abonnement ou des crédits qu'au démarrage de l'environnement cloud, de sorte qu'une tâche peut échouer à ce moment avec une erreur dans la session. Un développeur ne peut pas choisir, tâche par tâche, entre son offre Copilot personnelle et celle de son organisation. Les fonctions de gouvernance et d'analyse d'Air n'incluent pas l'usage de Copilot. Les administrateurs d'Air peuvent désactiver Copilot par une politique de gouvernance, mais ne peuvent pas fixer de plafonds de dépenses Copilot dans Air.

Ensemble, ces limites signifient que Air exclut l'usage de Copilot de ses analyses et ne fixe pas de plafond de dépenses ; la disponibilité de rapports et contrôles correspondants chez GitHub doit être vérifiée séparément, et que l'offre utilisée pour une tâche n'est pas un choix par tâche. Les équipes qui ont besoin de contrôle des coûts ou de rapports d'usage devraient décider où ce contrôle résidera avant d'activer la fonction. Le journal n'indique pas non plus quelles offres Copilot sont éligibles, quels modèles s'exécutent ni combien coûte une tâche typique, et ne donne aucun résultat de performance ou de qualité. C'est une annonce de fonctionnalité accompagnée d'un canal de retours, via le retour intégré au produit, un dépôt de retours et un questionnaire privé, de sorte que les détails peuvent évoluer à l'usage.