Pourquoi cette mise à jour de JetBrains est importante pour le travail d'ingénierie concret
GitHub Copilot pour JetBrains 1.18.0 n’est pas simplement une nouvelle mise à jour de l’assistant ; c’est un signe encourageant qui montre que les outils de développement basés sur l’IA commencent à devenir utiles pour les ingénieurs expérimentés. Cette version ajoute des validations d'outils assistées par l'IA pour les sessions de l'agent Copilot, la réédition de messages avec restauration du fichier, des compétences pour les organisations et les entreprises, un mode « plan » pour l'agent Codex, ainsi qu'un contrôle plus permanent sur les outils MCP. Aucune de ces fonctionnalités n’est spectaculaire prise isolément. Ensemble, elles s’attaquent au véritable goulot d’étranglement du développement assisté par agent : comment permettre à un agent d’effectuer davantage de tâches sans renoncer au contrôle humain.
Pour les équipes qui utilisent quotidiennement IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, PhpStorm ou un autre IDE de JetBrains, cela revêt une importance particulière, car l’IDE est déjà le lieu où s’effectuent l’architecture, la navigation, les tests, le débogage, la refactorisation et la révision. Un agent de codage fonctionnant au sein de cet environnement peut s’avérer plus utile qu’un chatbot autonome, mais aussi plus dangereux si les mécanismes de validation, de retour en arrière et les limites des outils sont insuffisants. La mise à jour 1.18.0 est intéressante car elle va dans la bonne direction : moins d’interruptions lors des opérations à faible risque, une révision plus explicite avant la mise en œuvre et un meilleur contrôle sur les outils externes exposés à l’agent.
La principale leçon à retenir n’est pas « d’activer toutes les fonctionnalités autonomes ». Un développeur expérimenté devrait considérer cette version comme une invitation à concevoir un meilleur workflow intégrant l’intervention humaine. Laissons l’agent éliminer les frictions répétitives, mais gardons aux humains la responsabilité de l’intention, du risque, de la révision du code, des tests et des décisions de fusion.
Présentation de l’outil
GitHub Copilot pour JetBrains est le plugin Copilot destiné aux IDE JetBrains. La documentation JetBrains décrit GitHub Copilot comme un agent de codage tiers disponible dans AI Assistant. Il peut écrire, déboguer et expliquer du code, effectuer des opérations Git telles que la validation et la création de branches, et gérer les pull requests et les tickets sur GitHub. Cette même documentation décrit plusieurs modes de fonctionnement : le mode Agent, dans lequel Copilot peut lire et modifier des fichiers ainsi qu’exécuter des commandes ; le mode Plan, dans lequel il analyse la requête et élabore un plan structuré avant d’effectuer les modifications ; et le mode Autopilot, dans lequel il exécute une tâche en plusieurs étapes sans interruption entre celles-ci.
Le journal des modifications GitHub du 22 septembre porte principalement sur la version 1.18.0 du plugin JetBrains. La fonctionnalité phare est l’approbation d’outils assistée par l’IA, appelée « approbations assistées », actuellement en préversion publique pour les sessions de l’agent Copilot. Les appels d’outils à faible risque peuvent bénéficier d’une validation automatique, tandis que les actions à plus haut risque nécessitent toujours une décision de la part du développeur. GitHub a également ajouté la possibilité de modifier un message utilisateur précédent dans une session d’agent ; avant l’envoi du message de remplacement, Copilot revient en arrière à la fois sur la conversation et sur les modifications apportées aux fichiers. Il s’agit d’une soupape de sécurité utile lorsqu’une instruction était ambiguë ou que l’agent s’est engagé sur une mauvaise voie.
Cette version intègre également les compétences partagées au niveau de l’organisation et de l’entreprise dans les sessions locales et celles de l’agent Copilot, ajoute un mode « plan » à l’agent Codex et améliore le contrôle du MCP. Un nouveau paramètre permet d’activer ou de désactiver le serveur MCP GitHub intégré sans modifier les serveurs MCP configurés manuellement, et les sessions de l’agent Copilot bénéficient désormais de contrôles persistants par outil pour les serveurs MCP. En termes simples : l’agent peut devenir plus performant, mais le développeur et l’organisation disposent de plus de leviers pour définir ce qu’il est autorisé à faire.
Comment l’installer ou y accéder
La procédure d’accès est simple. Installez le plugin GitHub Copilot depuis le JetBrains Marketplace, connectez-vous avec un compte GitHub ayant accès à Copilot, puis sélectionnez GitHub Copilot dans l’assistant IA ou l’interface de chat de l’IDE. La page du Marketplace constitue le meilleur point d’entrée pour le téléchargement, tandis que la documentation JetBrains explique l’activation, la collecte de contexte, les modes de fonctionnement, la sélection de modèles, le comportement en matière d’approbation, la restauration, l’utilisation du MCP, les fichiers d’instructions et les commandes « slash ».
Après l’installation, vérifiez la version du plugin. Le journal des modifications concerne spécifiquement GitHub Copilot pour JetBrains 1.18.0 ; les équipes doivent donc s’assurer que leur IDE dispose de cette version ou d’une version ultérieure. Les entreprises doivent également vérifier la politique de compte, les modèles activés, les paramètres de facturation basée sur l’utilisation et les instructions gérées par l’organisation avant de demander aux développeurs de s’appuyer sur les nouveaux workflows de l’agent. La liste des modèles visibles et des niveaux de raisonnement dépend des options activées sur le compte GitHub Copilot.
Je recommande un déploiement prudent. Tout d’abord, activez le plugin pour un petit groupe de développeurs expérimentés sur des dépôts non critiques. Ensuite, créez ou mettez à jour les instructions du dépôt afin que l’agent connaisse la structure du projet, les commandes de test, les conventions de codage et les zones interdites. Troisièmement, testez séparément les modes Agent et Plan. Quatrièmement, ne mettez à disposition que les outils MCP dont le projet a réellement besoin. Enfin, évaluez si le nouveau comportement de validation réduit les interruptions sans augmenter le nombre de modifications risquées.
Cas d’utilisation n° 1 : planifier avant de modifier les fichiers
L’habitude la plus utile consiste à privilégier la planification préalable pour les modifications ambiguës. Au lieu de demander à un agent de « corriger la logique de nouvelle tentative de paiement », demandez-lui d’inspecter le package concerné et d’élaborer un plan : fichiers impliqués, comportement actuel, modification minimale proposée, tests à ajouter, commandes à exécuter et risques. L’agent Codex prenant désormais en charge le mode « plan » dans cette version de JetBrains, les développeurs peuvent examiner, affiner ou approuver une approche avant le début de la mise en œuvre.
C'est un aspect crucial dans le travail d'ingénierie de haut niveau, car le plus difficile est rarement d'écrire du code. Le plus difficile est de choisir la modification la plus petite et la plus sûre qui s'intègre à l'architecture. Le mode « plan » offre au réviseur humain un point de contrôle avant que l’agent ne modifie quoi que ce soit. Si le plan touche au mauvais sous-système, ignore une voie de migration ou repose sur une règle métier erronée, vous pouvez corriger le cap à un stade précoce. Cela revient moins cher que de réviser un diff volumineux après que l’agent a déjà émis une hypothèse erronée.
Un workflow pratique consiste à : demander une analyse en lecture seule, solliciter un plan, modifier soi-même ce plan, puis n’autoriser la mise en œuvre qu’une fois que les critères d’acceptation et les commandes de validation sont explicites. Le gain de productivité provient d’une compréhension plus rapide du référentiel, tout en laissant au développeur le contrôle de la conception.
Cas d’utilisation n° 2 : moins d’interruptions lors des appels d’outils de routine
Les invites d’approbation sont nécessaires, mais un nombre excessif d’invites incite les développeurs à les ignorer en cliquant pour passer à autre chose. Les approbations assistées visent à réduire cette fatigue. GitHub indique que les appels d’outils à faible risque peuvent être automatiquement approuvés, tandis que les actions à plus haut risque continuent de nécessiter une décision. Utilisé avec prudence, ce système peut rendre les sessions des agents moins saccadées sans pour autant priver l’humain de choix significatifs.
L’expression clé est « utilisée avec prudence ». Je n’activerais pas en premier lieu une fonctionnalité d’approbation en avant-première sur un dépôt critique pour la production. Commencez par un projet de test, une tâche de documentation ou un nettoyage à des fins de test uniquement. Observez ce que l’agent considère comme présentant un faible risque. Comparez cette expérience au modèle d’approbation traditionnel. Si la fonctionnalité permet de gagner du temps tout en continuant à demander une validation pour les commandes, les chemins d’accès et les accès externes qui méritent un examen minutieux, elle peut alors s’intégrer au workflow par défaut de l’équipe.
Le bon modèle mental est celui de l’autonomie fondée sur le risque. Lire un fichier, lister un répertoire ou exécuter une commande d’inspection inoffensive n’est pas la même chose que modifier une migration, supprimer des fichiers, changer des identifiants ou appeler un service externe. Les validations assistées ne sont utiles que si elles préservent cette distinction dans la pratique.
Cas d’utilisation n° 3 : corriger une invite erronée sans propager l’erreur
La réédition d’un message avec retour en arrière est plus importante qu’il n’y paraît. Dans le travail d’un agent, une invite initiale façonne souvent l’ensemble de la session. Si cette invite est vague ou erronée, les corrections ultérieures peuvent s’avérer compliquées, car l’agent a déjà modifié des fichiers et construit un contexte autour d’une fausse prémisse. La nouvelle possibilité de rééditer un message utilisateur précédent et de revenir en arrière tant au niveau de la conversation que des modifications apportées aux fichiers permet au développeur de revenir plus tôt en arrière.
Cela favorise un flux de travail plus expérimental mais plus sûr. Vous pouvez tester une instruction plus précise, vérifier la direction prise, et si elle s’avère erronée, revenir au moment où l’instruction aurait dû être différente. C’est préférable à l’ajout de clarifications successives sur une session déjà polluée. Cela encourage également les développeurs à traiter les invites comme du code : les réviser, les simplifier et conserver un historique propre lorsque la direction change.
Pour les équipes, la règle doit être claire : valider ou mettre en attente les travaux importants avant les longues sessions avec l’agent, veiller à ce que les tâches restent suffisamment courtes pour que le retour en arrière soit compréhensible, et ne pas utiliser le retour en arrière comme substitut à la lecture des différences. Cette fonctionnalité facilite la récupération ; elle ne remplace pas la relecture.
Cas d’utilisation n° 4 : rendre opérationnelles les instructions organisationnelles
Le partage des compétences organisationnelles et d’entreprise peut réduire l’une des principales sources de variabilité des agents : le fait que chaque développeur reproduise de manière différente un contexte de projet incomplet. Si les équipes chargées de la plateforme ou de l’architecture peuvent publier des compétences réutilisables et des instructions gérées, les agents sont plus enclins à suivre les mêmes conventions, tant au niveau local que lors des sessions d’agent.
Cela s’avère particulièrement utile pour les grandes organisations. Une équipe backend peut codifier la structure des services, la nomenclature des tests, la bibliothèque de journalisation approuvée, la manière dont les erreurs doivent être encapsulées et les répertoires générés. Une équipe de sécurité peut décrire les schémas interdits et les attentes en matière de révision. Une équipe de mise en production peut définir comment les entrées du journal des modifications et les notes de migration doivent être préparées. L’agent a toujours besoin d’une supervision humaine, mais il part d’une base de référence plus solide.
Le gain de productivité concret ne se limite pas à une génération de code plus rapide. Il se traduit également par une diminution des commentaires de révision dus à un manque de connaissances locales. Les ingénieurs seniors passent moins de temps à répéter les mêmes consignes architecturales et davantage de temps sur les décisions exceptionnelles qui nécessitent réellement un jugement.
Cas d’utilisation n° 5 : contrôler les outils MCP plutôt que tout exposer
Les outils MCP sont puissants car ils permettent aux agents d’accéder à des systèmes externes. Ils constituent également une frontière de gouvernance. Un agent de codage ayant accès à des outils de suivi des tickets, de contrôle de version, de déploiement, d’observabilité ou à la documentation interne peut s’avérer nettement plus utile, mais chaque outil supplémentaire élargit le champ d’action d’une instruction erronée.
C’est pourquoi des contrôles permanents par outil sont essentiels. Les développeurs peuvent restreindre l’ensemble d’outils de l’agent pour une session, et les équipes peuvent décider quels outils doivent être disponibles par défaut. L’activation ou la désactivation du serveur MCP GitHub intégré, indépendamment des serveurs configurés manuellement, est un détail mineur mais utile : cela aide les équipes à distinguer l’accès natif à GitHub des autres intégrations.
Je recommande de commencer par une surface d’outils minimale. Pour une tâche de correction de bogue, l’agent peut avoir besoin d’un accès au dépôt, aux tests et peut-être à la ticket concerné. Il n’a probablement pas besoin d’outils de déploiement ni d’un accès réseau étendu. Pour une tâche de préparation de version, il peut avoir besoin du journal des modifications et du contexte de la pull request, mais ne devrait toujours pas disposer de droits illimités. Traitez l’exposition aux outils comme les autorisations en production : accordez le minimum de capacités utiles, puis étendez-les uniquement lorsqu’il existe des preuves justifiant cette extension.
Limites et risques
Il existe des limites évidentes. Les approbations assistées sont en préversion publique, ce qui signifie que les équipes doivent s’attendre à ce que leur comportement évolue. Le journal des modifications indique que les actions à faible risque peuvent être approuvées automatiquement, mais les développeurs doivent tout de même vérifier comment cette classification se comporte dans leur environnement. Un fichier considéré comme «à faible risque» dans un dépôt peut s’avérer sensible dans un autre. Une commande inoffensive dans un projet de test peut s’avérer coûteuse ou destructrice dans un monorepo comportant des scripts personnalisés.
Les workflows de l’IDE Agentic dépendent également de la qualité du dépôt. Des tests rigoureux, des limites claires entre les paquets, des commandes de configuration documentées et de bonnes instructions rendent l’agent plus utile. Des tests insuffisants et des règles métier implicites facilitent la production par l’agent de modifications plausibles mais erronées. L’outil amplifie le système d’ingénierie qui l’entoure ; il ne crée pas comme par magie une gouvernance là où elle n’existe pas.
Enfin, le coût et l’attention sont des facteurs importants. Les appels de modèles, les niveaux de raisonnement, les appels d’outils et les sessions répétées grèvent le budget. Le temps consacré à la révision représente également un coût. Une équipe doit vérifier si les modifications créées par l’agent réduisent la durée totale du cycle après révision et retouches, et pas seulement si elles permettent de générer du code rapidement.
Liste de contrôle pour l’adoption par un développeur senior
- Passez à la dernière version du plugin GitHub Copilot pour JetBrains et vérifiez la version dans l’IDE.
- Lisez la documentation de JetBrains sur les modes de fonctionnement avant d’activer les workflows autonomes.
- Ajoutez des instructions au référentiel comprenant l’architecture, les commandes de test, les fichiers générés, les contraintes de sécurité et les chemins d’accès interdits.
- Utilisez le mode « Plan » pour les modifications ambiguës et exigez une validation humaine avant la mise en œuvre.
- Testez les validations assistées sur des dépôts à faible risque avant de les utiliser sur du code critique.
- Limitez au maximum l’exposition au MCP et désactivez de manière permanente les outils qui ne sont pas nécessaires à la tâche.
- Exigez une révision normale des pull requests, une intégration continue (CI), une protection des branches et l’approbation du propriétaire du code pour les modifications produites par l’agent.
- Mesurez le nombre de PR acceptées, de PR rejetées, le temps de révision, les échecs d’intégration continue, les régressions et le nombre d’interruptions subies par les développeurs.
Le gain de productivité
L’intérêt de cette version ne réside pas dans le fait que Copilot puisse agir sans développeur. L’intérêt réside dans le fait que l’agent peut se charger d’une plus grande partie des tâches répétitives de navigation, de planification, d’édition et de validation au sein de l’IDE, tandis que le développeur garde le contrôle des étapes cruciales. Les validations assistées réduisent les interruptions sans valeur ajoutée. Le mode « Plan » crée un point de contrôle avant toute modification du code. Les fonctions de réédition et de retour en arrière améliorent la récupération. Les compétences organisationnelles réduisent la nécessité de répétitions dans les instructions. Les contrôles MCP garantissent que l’accès aux outils reste intentionnel.
C’est la direction que doivent prendre les outils de développement basés sur l’IA : non pas un battage médiatique générique, mais une meilleure ergonomie d’ingénierie autour de l’autonomie supervisée. Pour un ingénieur senior, l’opportunité consiste à concevoir des flux de travail où les agents gèrent l’exécution délimitée et où les humains conservent l’autorité sur l’architecture, la sécurité et les décisions de mise en production. Utilisé de cette manière, GitHub Copilot pour JetBrains 1.18.0 permet de gagner du temps réel sans demander aux équipes de renoncer à leurs responsabilités.
