Utiliser un agent d'IA dans VS Code

L'extension est en place ; la question est de savoir ce qui se passe quand vous basculez sur « agent ». Cette page s'adresse au responsable technique, et au dirigeant qui l'arbitre, pour décider ce qu'une équipe confie à un agent d'IA dans VS Code, avec quels droits et contre quelles preuves.

Elle permet de trancher quatre points : agent, chat ou complétion selon la tâche ; le cadre d'une session ; ce que l'agent ne touche jamais ; les indicateurs qui disent si le temps est gagné. La méthode générale est celle qui sert à créer un agent d'IA.

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

Trois outils cohabitent dans l'éditeur sous le même nom d'« IA ». La complétion écrit à la suite de votre frappe. Le chat explique, propose, répond. Le mode agent, celui de GitHub Copilot par exemple, prend un objectif de haut niveau et l'exécute en plusieurs étapes. La différence est de surface, pas de puissance : le premier touche une ligne, le dernier un dépôt.

Autonomie, outils, sessions, multi-fichiers : le sens du mot « agent » dans VS Code

Un agent dans un environnement de développement n'est pas un « chat qui code » : quatre propriétés le séparent du reste.

• Autonomie : il enchaîne des actions sans redemander l'autorisation à chaque étape.
• Outils : il ne produit pas seulement du texte, il lit des fichiers, lance des tests, appelle un terminal.
• Sessions : son travail a un début, une fin et un état que vous pouvez inspecter.
• Multi-fichiers : il agit sur un ensemble cohérent, pas sur le fichier ouvert.

L'agent opère une boucle : il agit, observe le résultat (tests, analyse statique, journaux), puis recommence. Ces propriétés varient selon l'extension et le mode : vérifiez-les une par une, et lisez la liste des sessions avant de juger.

Le tableau ci-dessous résume ce que chaque mode fait et à quoi on le contrôle ; ces paliers s'échelonnent sur les quatre niveaux de droits d'un agent d'IA du pilier, qui classe aussi les sept familles d'agents.

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

Un assistant suffit quand vous savez déjà quoi changer sur une fonction, une requête ou 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 et exécution de tests. Le critère de bascule n'est pas la difficulté, c'est le nombre d'endroits à toucher pour que la tâche soit finie.

L'agent se place surtout entre la spécification et le code : il transforme une intention en plan, puis en modifications vérifiables. Il sert aussi en aval, pour la revue et les procédures d'exploitation. 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 nouveau sur le projet. Une session mal ouverte ne se rattrape pas en route : elle produit un gros diff à relire en entier, ou à accepter par fatigue.

Le cadre à écrire avant la première modification

Le cadre se recopie d'une session à l'autre. Le contexte projet évite que l'agent invente les règles de la maison ; la définition de fini dit à 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, attentes 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.

Un collègue qui ne connaît pas la tâche doit pouvoir dire, en lisant les critères, si une sortie est conforme ; sinon, l'agent ne sait pas où s'arrêter.

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

Le réglage dépend de deux variables, à chaque tâche. La surface de changement : plus de fichiers touchés, moins d'autonomie et plus de validations. Le risque : une zone couverte par des tests solides tolère une exécution large, une zone sans test n'en tolère aucune.

Au niveau de la session elle-même, quatre garde-fous se posent.

• 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. La branche isole l'historique, rien de plus : ni l'accès aux fichiers du poste, ni les commandes, 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 : 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 a trois caractéristiques, et la première est la plus importante.

• Écrite 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 ainsi qu'un périmètre se perd.
• Courte : elle tient dans le fichier de consignes du dépôt et se relit en équipe.
• En 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.

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 sur le disque, ni une commande hors du dépôt. Ce qui empêche relève du système.

• Les droits du compte qui exécute l'agent, réduits à ce que la tâche demande.
• Les secrets sortis du poste et placés dans un coffre.
• L'approbation obligatoire des commandes de terminal.
• Un 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 où l'agent peut écrire, et rien d'autre. Une liste d'exclusions s'oublie au premier fichier nouveau ; une liste d'inclusions non, si un mécanisme l'applique. En sont exclus par défaut les fichiers d'environnement et tout ce qui porte un secret, les configurations de recette et de production, les migrations déjà appliquées et les artefacts générés.

Quatre autres règles portent sur ce que le diff ne montre pas.

• 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 le reste, jamais sur une commande qui atteint un système extérieur au poste.
• Écriture hors du dépôt : interdite sans exception, et bloquée par l'environnement d'exécution plutôt que par une consigne. 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.

Le contexte qui reste sur le poste

La seconde moitié de la liste concerne la lecture, la plus facile à oublier : elle ne laisse aucune trace dans le dépôt. Un agent qui s'exécute dans votre éditeur n'est pas pour autant un agent local : le plus souvent, il tourne sur votre machine et appelle un modèle distant auquel il envoie son contexte.

Sauf modèle installé sur votre poste, chaque étape transmet donc à un service distant ce qu'elle a lu : extraits de code, chemins, sorties de commandes, messages d'erreur. Ouvrir largement le contexte « pour que l'agent comprenne mieux » fait sortir des données de votre machine. Donnez le contexte minimal suffisant, pas le dépôt entier ; quatre catégories 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.
• Les documents contractuels qui traînent dans le projet.

Dans les tests, des données synthétiques remplacent les données réelles. Si votre politique interne l'impose, le modèle s'exécute sur votre propre machine : c'est le local au sens fort, qui se décide avant le projet et a un coût d'exploitation.

Évaluer une extension avant de l'autoriser

Une extension d'IA accède à l'espace de travail, parfois au terminal. L'évaluation se fait donc avant et se conclut par une décision d'équipe : 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 décision.

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

Le tableau ci-dessous donne les cinq points et la décision qu'ils appellent. Les deux derniers, la réversibilité et la chaîne d'approvisionnement logicielle, sont les plus discriminants.

Les limites de robustesse qu'aucune extension ne corrige

Certaines limites tiennent à la nature des modèles et se retrouvent dans toutes les extensions, quelle que soit la qualité de l'intégration.

• Gestion des erreurs : un agent qui échoue tend à réessayer une variante plutôt qu'à remettre en cause son hypothèse de départ.
• Cohérence multi-fichiers : une modification juste dans chaque fichier pris isolément peut être fausse à l'échelle du module.
• Limites de contexte : au-delà d'une certaine taille, l'agent perd des éléments qu'il avait lus, et rien ne vous le signale.
• Comportements non déterministes : la même demande, deux fois, ne produit pas le même diff.

Les modèles restent probabilistes et l'indexation de l'espace de travail réduit la fréquence des erreurs sans la supprimer, et rend les réponses plus convaincantes en lecture rapide. Pour tout changement multi-fichiers, demandez la liste des impacts et les 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 un résultat vérifiable 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 et le moins utilisé : deux lignes suppriment une classe d'erreurs connue. Vient ensuite le plan d'action avant toute écriture, puis le découpage en tâches : quatre diffs de trente lignes se relisent, un diff de cent vingt lignes se survole.

Entre les lots, posez des points de contrôle : l'agent s'arrête, montre ce qu'il a changé et vérifié, et attend. Le déroulé se joue en quatre temps : plan, premier petit diff, tests puis correction, récapitulatif final (ce qui a changé, comment le vérifier, 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 d'en juger à la lecture, mais d'obtenir des preuves indépendantes 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 les décisions.

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 propose un correctif sans avoir reproduit le problème corrige autre chose. Imposez des tests 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. Demandez enfin des correctifs vérifiables : commande exécutée, résultat observé, lien entre la cause et la modification.

Relire le diff et les artefacts laissés derrière

Votre meilleure assurance qualité reste un diff lisible et des validations atomiques : un diff illisible n'est pas relu, il est approuvé. Demandez des conventions respectées et des messages de commit qui expliquent l'intention. La traçabilité ne s'ajoute pas après coup : c'est elle qui dira, 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, journal des modifications, procédures d'exploitation. Ils se relisent comme du code, avec des exemples exécutables. Si vous écrivez vous-même la boucle qui fait tout cela, c'est un agent d'IA en Python que vous construisez ; 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 (squelettes, tests, documentation, refactorings mécaniques), où le résultat est connu d'avance et la vérification rapide. Le coût caché apparaît 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é. Quatre indicateurs permettent de trancher sans outillage.

Relevés pendant un mois, ces quatre points donnent une décision documentée sur ce que l'équipe confie à un agent.

Continuez votre lecture

Selon où se joue la suite, quatre articles prennent le relais.

• La suite se joue sur le dépôt distant : revue automatisée et chaîne d'intégration continue relèvent de l'agent d'IA sur GitHub.
• Vous décidez pour une équipe : licences, droits de compte et politiques sont le terrain de l'agent d'IA Copilot.
• Vous voulez faire tourner l'agent hors de 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 : matériel, modèles et charge d'exploitation se comparent sur l'agent d'IA en local.

Si l'agent à cadrer travaille sur vos données et vos règles métier plutôt que sur du code, c'est le terrain d'une IA personnalisée pour votre entreprise.

FAQ sur les agents d'IA dans VS Code

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

On code plus vite sans dégrader la qualité en réservant l'agent aux tâches qui se vérifient vite : squelettes, tests, documentation, refactorings mécaniques. La boucle reste courte (plan, petit diff, tests, revue) et l'agent sert aussi de relecteur et de générateur de cas limites.

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

Un agent se crée dans VS Code à partir des modes intégrés (questionner, planifier, exécuter) ou d'un agent personnalisé doté d'un rôle, d'outils et d'un modèle. Les limites se fixent avant l'exécution : périmètre de fichiers autorisé, interdits explicites (secrets, configuration de production), obligation de tests.

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

Le mode agent de GitHub Copilot s'utilise, à la date de rédaction, depuis la vue de conversation, après activation dans les réglages. On y bascule pour les tâches multi-étapes, en commençant par une demande de plan, puis en avançant par étapes validées une à une.

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

Une extension d'agent s'évalue sur cinq points : données envoyées, permissions, journalisation, réversibilité et chaîne d'approvisionnement logicielle, avant toute installation sur un dépôt réel. Les extensions dont les actions sont auditables passent devant ; entre deux candidates, la capacité à prouver l'emporte sur la vitesse.

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 aide à décider sans rien modifier, l'agent exécute une tâche complète en plusieurs étapes, avec des outils et sur plusieurs fichiers. Le bon choix dépend de la surface de changement et de votre capacité à vérifier le résultat.

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

Avant un changement multi-fichiers, l'agent travaille sur une branche dédiée, avec des validations atomiques et des tests obligatoires avant fusion. Le périmètre de fichiers est déclaré en positif et l'écriture hors du dépôt bloquée par l'environnement. 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 ?

Le bon contexte est le contexte minimal suffisant : conventions, objectif, chemins des fichiers pertinents, extraits nécessaires. Secrets, données personnelles et journaux de production restent dehors, et les cas de test utilisent des jeux synthétiques. Si la politique interne l'impose, le modèle s'exécute sur votre propre machine.

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

Une erreur plausible se détecte par la preuve, pas par la lecture : à chaque étape, l'agent fournit la commande exécutée, le résultat observé et le lien entre la cause et le correctif. Les cas limites sont produits avant le correctif, et des tests de non-régression s'ajoutent systématiquement.