Utiliser un agent d'IA dans VS Code

L'extension est en place, et la question n'est plus de l'installer : c'est de savoir ce qui se passe quand vous basculez sur « agent ». Utiliser un agent d'IA dans VS Code ne se joue pas sur la puissance du modèle mais sur le cadre que vous lui posez avant de cliquer : un périmètre écrit, des critères d'acceptation, une liste de ce qu'il ne touche jamais, et un diff relisible. Pour la méthode générale — cadrage, niveau d'autonomie, spécification, recette —, savoir créer un agent d'IA donne le cadre dans lequel tout ce qui suit s'applique.

Utiliser un agent d'IA dans VS Code : agent, chat ou complétion

Trois choses cohabitent dans le même éditeur et s'appellent indistinctement « l'IA ». La complétion écrit à la suite de votre frappe. Le chat explique, propose, répond. Le mode agent prend un objectif de haut niveau et l'exécute en plusieurs étapes. La différence n'est pas de puissance mais de surface : le premier touche une ligne, le dernier touche un dépôt. La bonne question n'est donc pas « est-ce que l'IA sait le faire ? », mais « est-ce que je peux vérifier le résultat rapidement ? ».

Ce qu'on appelle « agent » dans l'écosystème VS Code agents : autonomie, outils, sessions, multi-fichiers

Un agent dans un environnement de développement n'est pas un « chat qui code » : quatre mots le séparent du reste. L'autonomie : il enchaîne des actions sans vous redemander l'autorisation à chaque étape. Les outils : il ne produit pas seulement du texte, il lit des fichiers, lance des tests, appelle un terminal. Les sessions : son travail a un début, une fin et un état que vous pouvez inspecter. Le multi-fichiers : il agit sur un ensemble cohérent, pas sur le fichier ouvert.

Là où un assistant propose une suggestion, l'agent opère une boucle : il agit, observe le résultat — tests, analyse statique, journaux —, puis recommence. Ces quatre propriétés ne se retrouvent pourtant pas dans toutes les extensions ni dans tous les modes : certaines n'offrent qu'une complétion, d'autres un chat sans droit d'écriture, d'autres une exécution sans planification ni historique de sessions inspectable ; le même mot recouvre des capacités différentes d'un outil et d'une version à l'autre. Vérifiez donc extension par extension ce qui existe réellement, au lieu de le déduire du mot « agent ». Quand une liste unique de sessions est proposée — exécutions sur votre machine, en ligne de commande ou à distance —, c'est cette vue qu'il faut regarder avant de juger ce qui s'est passé. Le tableau ci-dessous résume ce que chaque niveau fait, et à quoi on le contrôle, là où il est disponible.

Quand un simple assistant suffit, et quand l'agent devient utile

Un assistant suffit quand vous savez déjà quoi changer et que vous voulez aller plus vite sur une unité de travail courte : une fonction, une requête, un test. Un agent devient utile dès que la tâche traverse le projet : tâches longues, refactorings répartis sur plusieurs modules, migration d'une interface, écriture puis exécution d'une batterie de tests. Le critère de bascule n'est pas la difficulté intellectuelle de la tâche, c'est le nombre d'endroits qu'il faut toucher pour qu'elle soit finie.

Dans le cycle de développement, l'agent se place surtout entre la spécification et le code : il transforme une intention en plan, puis en modifications vérifiables. Il apporte aussi de la valeur en aval, sur la revue et sur les runbooks : procédures de diagnostic tirées des journaux, mise à jour de documentation, listes de contrôle de déploiement. L'agent accélère l'exécution, la responsabilité produit et la qualité restent humaines.

Conduire une session d'agent

Un agent est performant quand vous le nourrissez comme un contributeur qui arrive sur le projet : un objectif, des contraintes, et une définition claire du « fini ». Une session mal ouverte ne se rattrape pas en cours de route : elle produit un gros diff qu'il faudra relire en entier, ou accepter par fatigue. Avant toute modification, imposez un format de sortie et un déroulé : plan, fichiers impactés, commandes lancées, résumé des changements.

Ce qu'on écrit avant de laisser l'agent modifier quoi que ce soit

Quatre éléments se posent au début de la session, et ils se recopient d'une session à l'autre. Le contexte projet — conventions, structure de dossiers, versions, style de journalisation — évite que l'agent invente les règles de la maison. Les consignes disent ce qu'il doit produire, les limites où il s'arrête, les critères d'acceptation et la definition of done à quoi on reconnaîtra que c'est terminé.

• Objectif : le résultat attendu côté utilisateur, pas la manière de l'obtenir.
• Contraintes : cadre technique, versions, style, exigences de performance et de sécurité.
• Critères d'acceptation : tests qui doivent passer, comportements attendus, cas limites couverts.
• Déroulé : un plan avant écriture, puis une implémentation par étapes, chacune vérifiable.

Le test est simple : un collègue qui ne connaît pas la tâche doit pouvoir dire, en lisant les critères d'acceptation, si une sortie est conforme ou non. Si la réponse dépend de votre jugement, l'agent n'a aucun moyen de s'arrêter au bon endroit.

Régler l'autonomie selon le risque et la complexité de la tâche

Le réglage se refait à chaque tâche, et il dépend de deux variables. La surface de changement d'abord : plus il y a de fichiers touchés, plus vous devez réduire l'autonomie et multiplier les points de validation. Le risque ensuite : une zone couverte par des tests solides tolère une exécution large, une zone sans test n'en tolère aucune. Un agent très autonome sur du code non testé ne va pas plus vite ; il déplace le travail de vérification vers un moment où il coûte plus cher.

Quatre garde-fous se posent au niveau de la session elle-même. Lecture seule d'abord : la première passe produit une analyse et un plan, jamais une écriture. Branche dédiée : l'agent travaille à côté, avec des validations atomiques et réversibles. Une branche isole l'historique, rien de plus — elle ne restreint ni l'accès aux fichiers du poste, ni les commandes lancées, ni ce qui part dans le contexte. Revue systématique du diff : aucune modification non expliquée n'est acceptée. Conditions d'arrêt enfin : si un test échoue deux fois de suite, l'agent s'arrête et demande une clarification au lieu de tenter une troisième correction.

Ce qu'un agent ne doit pas toucher dans votre dépôt

La liste des interdits s'écrit avant la première session, pas au moment où l'agent demande l'autorisation : à cet instant, vous voulez que la tâche avance, et vous approuvez. C'est le mécanisme par lequel un périmètre se perd. Cette liste est courte, elle tient dans le fichier de consignes du dépôt, et elle se relit en équipe. Elle a deux moitiés : ce que l'agent n'a pas le droit de modifier, et ce qu'il n'a pas le droit de lire. Une précision, avant de la dérouler : un fichier de consignes est une instruction adressée au modèle, pas une barrière technique. Il n'empêche ni la lecture d'un fichier de secrets présent sur le disque, ni l'exécution d'une commande hors du dépôt ; c'est du texte, que le modèle peut négliger et qu'un contenu lu ailleurs peut contredire. Ce qui empêche relève du système : droits du compte qui exécute l'agent, secrets sortis du poste et placés dans un coffre, approbation obligatoire des commandes de terminal, environnement d'exécution isolé. Les consignes réduisent la fréquence des écarts, les barrières en réduisent la portée : il faut les deux.

Fichiers, secrets, dépendances et commandes

Le périmètre de fichiers se déclare en positif : les dossiers dans lesquels l'agent peut écrire, et rien d'autre. Une liste d'exclusions s'oublie dès qu'un fichier nouveau apparaît, une liste d'inclusions non — à condition qu'un mécanisme l'applique : déclarée dans un simple fichier de consignes, elle reste une intention que rien n'oblige à respecter. En sont exclus par défaut les fichiers d'environnement et tout ce qui porte un secret — jetons, identifiants, clés —, les configurations d'environnements de recette et de production, les fichiers de migration déjà appliqués, et les artefacts générés qu'un outil reconstruit.

• Dépendances : l'agent propose un ajout, il ne l'installe jamais seul. Une dépendance entre dans le projet par une décision humaine.
• Exécution de commandes : autorisée sur les commandes de vérification — tests, formatage, analyse statique —, soumise à approbation explicite pour tout le reste, et jamais sur une commande qui atteint un système extérieur au poste de travail.
• Écriture hors du dépôt : interdite sans exception, et l'interdiction se pose dans l'environnement d'exécution plutôt que dans une consigne, sans quoi elle n'est qu'un souhait. Un agent qui modifie votre configuration globale produit un changement que le diff ne montrera jamais.
• Historique et branches protégées : aucune réécriture d'historique, aucune action sur la branche principale. Le travail sort en proposition et se relit avant d'entrer.

Ces quatre règles protègent ce que le diff ne montre pas : une dépendance installée en silence, une commande hors périmètre ou un fichier écrit à côté du dépôt échappent à la revue.

Ce qui ne part pas dans le contexte

La seconde moitié de la liste concerne la lecture, et c'est la plus facile à oublier : elle ne laisse aucune trace dans le dépôt. Un point s'énonce avant tout le reste : un agent qui s'exécute dans votre éditeur n'est pas pour autant un agent local. Sauf modèle installé sur votre poste, chaque étape transmet à un service distant ce qu'il a lu — extraits de code, chemins, sorties de commandes, messages d'erreur, et parfois le contenu de fichiers que vous n'avez jamais ouverts. Le réflexe d'ouvrir largement le contexte pour « que l'agent comprenne mieux » est ce qui fait sortir des données de votre machine. Le risque n'est pas théorique : l'entrée de données sensibles non contrôlée concerne 4,7 % des utilisateurs en entreprise (Chad Wyatt, 2026) — un ordre de grandeur, qui varie selon les organisations et les outils, mais suffisant pour justifier une règle écrite. Ces repères et leurs variantes sont regroupés dans notre relevé de statistiques sur ChatGPT et l'IA générative.

Donnez le contexte minimal suffisant : conventions, objectif, chemins des fichiers pertinents, extraits nécessaires — pas le dépôt entier au motif qu'il est indexé. Restent dehors les secrets et les fichiers d'environnement, les données personnelles et les jeux de données clients, les exports de journaux de production et les documents contractuels qui traînent dans le projet. Quand un cas de test a besoin de données réalistes, des données synthétiques les remplacent. Si votre politique interne l'exige, l'exécution du modèle sur votre propre machine devient la seule réponse acceptable, et elle se décide avant le projet.

Évaluer une extension avant de l'autoriser

Une extension d'IA a souvent accès à l'espace de travail, parfois au terminal, et peut déclencher des actions qui dépassent largement « un prompt ». L'évaluation se fait donc avant, sur cinq points, et elle se conclut par une décision d'équipe : autorisée, autorisée sous conditions, ou refusée. Une extension qu'on « teste pour voir » sur un dépôt réel a déjà été autorisée, sans que personne ne l'ait décidé.

Cinq points à vérifier avant d'installer une extension

Les données envoyées et les permissions disent ce que l'extension peut voir et faire. La journalisation dit si vous pourrez reconstituer ce qui s'est passé. La réversibilité dit si vous pourrez revenir en arrière, et la supply chain dit qui maintient le code que vous installez et à quelle fréquence. Ces deux derniers points sont les plus discriminants, et ce sont ceux qu'on saute.

Les limites de robustesse qu'aucune extension ne corrige

Quatre limites tiennent à la nature des modèles et se retrouvent dans toutes les extensions. La gestion des erreurs : un agent qui échoue tend à réessayer une variante plutôt qu'à remettre en cause son hypothèse de départ. La cohérence multi-fichiers : une modification juste dans chaque fichier pris isolément peut être fausse à l'échelle du module. Les limites de contexte : au-delà d'une certaine taille, l'agent perd des éléments qu'il avait pourtant lus, et rien ne vous le signale. Les comportements non déterministes enfin : la même demande, deux fois, ne produit pas le même diff.

Les modèles restent probabilistes : ils peuvent produire un résultat convaincant mais incorrect, ou inventer une interface qui n'existe pas. L'indexation de l'espace de travail réduit la fréquence du problème sans le supprimer, et rend les réponses plus plausibles, donc plus difficiles à contester en lecture rapide. Pour tout changement multi-fichiers, exigez donc une liste explicite des impacts et une exécution automatisée des vérifications, avant de regarder le code.

Réduire les itérations

Le temps perdu avec un agent se perd rarement d'un coup : il se perd en allers-retours. Un bon prompt d'agent est un mini-brief technique. Et il demande explicitement un résultat vérifiable — commandes à lancer, tests à ajouter, critères de succès — plutôt qu'un résultat satisfaisant.

• Objectif : « ajouter un point d'entrée X avec validation des entrées et erreurs explicites », pas « améliorer l'API ».
• Contraintes : versions, conventions, structure de dossiers, style de journalisation.
• Formats attendus : liste des fichiers touchés, diff, tests, note de migration.
• Exemples minimaux : un cas d'entrée et sa sortie attendue, le plus court possible.
• Anti-exemples : « refais toute l'API » sans périmètre ni critère — et, plus utile encore, un extrait de ce que vous ne voulez pas voir dans le résultat.

L'anti-exemple est le plus rentable des cinq, et le moins utilisé : il coûte deux lignes et supprime la classe d'erreurs que vous avez déjà rencontrée deux fois. Le second réflexe rentable : faire produire un plan d'action avant toute écriture — étapes, fichiers, risques —, puis avancer par lots. Le découpage en tâches a un effet mécanique sur la relecture : quatre diffs de trente lignes se relisent, un diff de cent vingt lignes se survole.

Entre les lots, posez des checkpoints de validation : l'agent s'arrête, montre ce qu'il a changé et comment il l'a vérifié, et attend. Le déroulé complet tient en quatre temps — plan d'implémentation, première étape et petit diff, tests puis correction, récapitulatif final indiquant ce qui a changé, comment le vérifier et comment revenir en arrière. Ce dernier point permet d'abandonner une session ratée au lieu de la réparer.

Exiger des preuves : tests, diff et artefacts

Un agent produit du code plausible. Votre travail n'est pas de juger cette plausibilité à la lecture, mais d'exiger des preuves qui ne dépendent pas de votre appréciation. Trois familles suffisent : des tests qui échouent quand le code est faux, un diff qui se relit ligne à ligne, et des artefacts qui expliquent pourquoi une décision a été prise. Les deux premières protègent la version d'aujourd'hui, la troisième celle que quelqu'un reprendra dans six mois.

Faire produire les scénarios, les cas limites et les critères de non-régression

Pour déboguer, faites d'abord expliciter les hypothèses : cause probable, fichiers impliqués, manière de reproduire. Un agent qui annonce un correctif sans avoir reproduit le problème corrige autre chose. Imposez ensuite une stratégie de test en trois temps — cas nominal, cas limites, non-régression —, et demandez les cas limites avant le correctif : produits après, ils sont écrits pour passer.

Le critère de non-régression est celui qu'on oublie et le plus discriminant : il vérifie que ce qui fonctionnait avant fonctionne encore, ce que ni le diff ni la relecture ne montrent. Exigez enfin des correctifs vérifiables : la commande exécutée, le résultat observé, et le lien explicite entre la cause identifiée et la modification apportée.

Relire le diff, et ce que l'agent doit laisser derrière lui

Votre meilleure assurance qualité reste un diff lisible et des validations atomiques. Un agent qui produit un diff illisible n'est pas relu : il est approuvé. Demandez des conventions respectées, des messages de commit qui expliquent l'intention et non la mécanique, et une mention des risques quand le changement touche une zone sensible. La traçabilité et l'auditabilité ne s'ajoutent pas après coup : ce sont elles qui vous permettront de dire, dans trois mois, pourquoi cette ligne existe.

Restent les artefacts, que l'agent maintient bien et que personne ne met à jour spontanément : README, journaux de décision d'architecture, changelog, runbooks. Ils se relisent comme du code. Exigez-en la même chose que du reste : des exemples exécutables, des extraits reliés au code réel, des conventions stables et les pièges connus. Si le sujet devient d'écrire vous-même la boucle qui fait tout cela — structure de projet, état explicite, outils déterministes, tests —, c'est un agent d'IA en Python que vous construisez, et ce n'est plus le même travail : ici, un agent écrit du code pour vous.

Savoir si ça vous fait gagner du temps

Le gain est maximal sur les tâches standardisées : génération de squelettes, écriture de tests, documentation, refactorings mécaniques. Le résultat attendu y est connu d'avance, la vérification est rapide, et votre valeur ajoutée était nulle. Le coût caché apparaît ailleurs, quand la sortie est difficile à maintenir : incohérences de style, abstractions inutiles, duplications discrètes, dette technique que personne n'a décidé de contracter. Le point de bascule est presque toujours le même — le temps de relecture dépasse le temps d'écriture épargné.

Ce jugement ne se rend pas à l'impression. Quatre indicateurs suffisent à trancher, sans outillage particulier.

• Temps de revue : le temps de relecture d'un changement produit par l'agent, comparé à un changement équivalent écrit à la main. S'il est supérieur, le gain d'écriture a déjà été annulé.
• Part de correctifs rejetés : la proportion de propositions abandonnées en cours de session. Au-delà d'un tiers, c'est le cadrage des sessions qu'il faut revoir, pas l'outil.
• Retouches après fusion : les corrections apportées dans les jours qui suivent, sur du code que l'agent avait produit. C'est l'indicateur le plus honnête, parce qu'il compte ce que la revue a laissé passer.
• Dette constatée : les zones du projet que l'équipe évite de toucher. Si elles apparaissent là où l'agent a beaucoup écrit, le gain de vitesse a été prêté, pas acquis.

Une équipe qui relève ces quatre points pendant un mois obtient une décision documentée sur les tâches qu'elle confie à un agent et celles qu'elle garde. Et elle ne sera pas la même sur un projet neuf, largement testé, et sur un système ancien dont personne ne connaît plus toutes les dépendances.

FAQ sur les agents d'IA dans VS Code

Comment coder plus vite avec l'IA dans VS Code sans dégrader la qualité ?

Allez vite sur ce qui se vérifie vite : squelettes de code, tests, documentation et refactorings mécaniques. Imposez une boucle courte — plan, petit diff, tests, revue — plutôt qu'un gros changement en une seule passe. Et utilisez l'agent comme relecteur, générateur de cas limites, autant que comme auteur : c'est dans ce rôle qu'il réduit la dette technique au lieu de l'augmenter.

Comment créer un agent dans VS Code (et quelles limites fixer) ?

Vous pouvez utiliser les modes intégrés — questionner, planifier, exécuter — et définir des agents personnalisés en leur donnant un rôle, une liste d'outils disponibles et un modèle. Fixez les limites avant l'exécution : périmètre de fichiers autorisé, interdits explicites (secrets, configurations de production), obligation de tests. Plus le changement est risqué, plus vous exigez d'approbations explicites en cours de session.

Comment utiliser Copilot dans VS Code, y compris le Copilot agent mode ?

Ouvrez la vue de conversation de l'assistant, activez le mode agent dans les réglages si votre organisation ne l'a pas déjà fait, puis basculez sur ce mode pour les tâches multi-étapes : modifications multi-fichiers, commandes, tests. Démarrez toujours par une demande de plan, puis laissez l'implémentation se faire par étapes avec des points de validation entre chacune.

Quelles extensions IA prennent en charge des agents (et comment les évaluer) ?

Évaluez une extension sur cinq axes : données envoyées, permissions, journalisation, robustesse — erreurs et cohérence multi-fichiers — et réversibilité. Privilégiez celles qui rendent leurs actions auditables et qui s'intègrent proprement à vos tests et à vos conventions. Si vous devez trancher entre deux, choisissez la capacité à prouver — tests, journaux, diff — plutôt que la capacité à produire vite.

Quelle différence entre un agent, un chat et l'autocomplétion dans VS Code ?

L'autocomplétion accélère la frappe sur des motifs connus. Le chat vous aide à comprendre et à décider, mais il ne modifie rien : vous appliquez vous-même. L'agent exécute une tâche complète en plusieurs étapes, avec des outils, et touche plusieurs fichiers. Le bon choix dépend de la surface de changement et de votre capacité à vérifier rapidement le résultat.

Quels garde-fous activer avant de laisser un agent modifier plusieurs fichiers ?

Travaillez sur une branche dédiée, imposez des validations atomiques et rendez les tests obligatoires avant toute fusion. Déclarez le périmètre de fichiers en positif, excluez secrets et configurations sensibles, et interdisez l'écriture hors du dépôt. Ajoutez des conditions d'arrêt : au second échec d'un test, l'agent s'arrête et demande une clarification.

Comment fournir le bon contexte projet à un agent sans exposer des données sensibles ?

Donnez le contexte minimal suffisant : conventions, objectif, chemins des fichiers pertinents, extraits nécessaires. Excluez secrets, données personnelles et exports de journaux de production, et remplacez les données réelles par des jeux synthétiques dans les cas de test. Si votre politique interne l'impose, l'exécution du modèle sur votre propre machine devient la seule réponse acceptable.

Comment éviter les erreurs plausibles et améliorer la vérifiabilité (tests, logs, preuves) ?

Demandez une preuve à chaque étape : commande exécutée, résultat observé, lien explicite entre la cause identifiée et le correctif appliqué. Faites produire les cas limites avant le correctif, jamais après, et ajoutez systématiquement des tests de non-régression. Une sortie sans preuve se traite comme une proposition, pas comme un résultat.

Peut-on utiliser un agent en local, et dans quels cas c'est préférable ?

Distinguez deux choses. Un agent peut s'exécuter sur votre machine, y compris en arrière-plan depuis une ligne de commande, tout en appelant un modèle distant auquel il envoie son contexte : c'est le cas le plus courant, et il ne garde rien chez vous. Le local au sens fort suppose en plus un modèle installé sur votre poste. C'est celui-là qui s'impose quand le dépôt contient du code sensible, ou quand votre conformité limite l'envoi de contexte à un fournisseur externe. Il se paie en charge d'exploitation : dépendances, performances, reproductibilité des résultats.

Un agent d'IA dans VS Code peut-il aider à maintenir des fonctionnalités d'IA en production ?

Oui, surtout pour accélérer la mise en place de motifs répétitifs — encapsulations, validations, tests, documentation — et maintenir la cohérence multi-fichiers. Mais l'agent ne remplace pas l'architecture : exigez des décisions tracées, des tests et un runbook d'exploitation, faute de quoi vous maintiendrez à l'aveugle un système que personne n'a conçu.

Continuez votre lecture

• Le diff est relu et validé sur votre poste, et la suite se joue sur le dépôt distant : revue automatisée, déclenchement et chaîne d'intégration continue relèvent de l'agent d'IA sur GitHub.
• Vous ne décidez plus pour vous seul mais pour une équipe, et la question devient celle des licences, des droits de compte et des politiques : c'est le terrain de l'agent d'IA Copilot.
• Vous voulez faire tourner l'agent ailleurs que dans votre éditeur : modèles, éditeurs et outils d'automatisation se comparent sur une plateforme d'agent d'IA.
• Le code ne doit pas quitter votre machine, et cette contrainte passe avant le confort d'usage : matériel, modèles et charge d'exploitation se comparent sur l'agent d'IA en local.