Introduction

Si Microsoft Agent Framework répond à la question « comment construire techniquement un système agentique », alors Copilot dans VS Code répond à une autre question : comment appliquer des principes similaires dans le travail d’ingénierie quotidien sans devoir construire toute la plateforme soi-même ?

Selon la documentation officielle, Copilot dans VS Code n’est déjà plus seulement un outil d’autocomplétion de code ni une fenêtre de chat séparée. C’est un ensemble de modes de travail et de capacités : inline suggestions, inline chat, chat sessions, agent mode, review edits, checkpoints, custom instructions, custom agents, agent skills, MCP servers, hooks, Agent Logs et Chat Debug.

Tout cela permet de couvrir un scénario pratique très important : travailler avec un dépôt vivant, des fichiers, un terminal et un contexte d’ingénierie directement là où les DevOps et les développeurs passent déjà la majeure partie de leur temps.

Où Copilot est plus fort, et où Agent Framework est plus approprié

Copilot dans VS Code et Microsoft Agent Framework résolvent des problèmes proches, mais pas identiques. Il vaut mieux les comparer non pas comme des concurrents, mais comme des outils ayant des centres de gravité différents.

GitHub Copilot dans VS Code est plus fort lorsque le travail se déroule directement dans l’environnement d’ingénierie : avec le code, les configurations, le terminal et la structure du dépôt. Son principal avantage n’est pas d’être « encore un chat avec un modèle », mais d’être intégré là où le travail quotidien du développeur ou de l’ingénieur DevOps se fait déjà.

Copilot est pratique lorsqu’il faut :

• comprendre la structure du projet ;
• ouvrir et comparer plusieurs fichiers ;
• analyser un pipeline YAML ;
• vérifier un Dockerfile ou un Helm chart ;
• apporter des changements ciblés à une configuration ;
• exécuter une commande dans le terminal ;
• regarder le résultat d’une vérification et corriger immédiatement le code.

Autrement dit, Copilot couvre bien le cycle d’ingénierie : analyse → modification → vérification → précision → nouveau passage. Il réduit la friction entre la compréhension du problème et le changement réel dans le projet.

Microsoft Agent Framework est plus approprié dans d’autres scénarios. Il est moins destiné au travail dans l’IDE qu’à la construction programmée de son propre système agentique. Sa force apparaît lorsque le processus agentique doit être une application séparée, un service ou un workflow long.

Agent Framework est plus logique lorsque l’on a besoin de :

• processus multi-step en arrière-plan ;
• scénarios de workflow avec checkpointing ;
• coordination de plusieurs agents ou fonctions ;
• intégration avec des services externes ;
• état persistant entre les exécutions ;
• orchestration où l’execution graph est important ;
• contrôle production, telemetry, hosting et politiques d’exécution.

Pour simplifier, la différence est la suivante : Copilot est plus pratique comme environnement de travail pour le cycle d’ingénierie quotidien, tandis qu’Agent Framework est un cadre pour des systèmes agentiques autonomes et multi-étapes en dehors de l’IDE.

Par exemple, si un ingénieur analyse un pipeline échoué, ouvre le YAML, regarde le Dockerfile, compare la sortie du terminal, modifie une configuration et relance immédiatement une vérification, il est plus naturel d’utiliser Copilot dans VS Code. Il est déjà près des fichiers, du terminal et de l’état courant du projet.

Mais si le processus doit vivre plus longtemps qu’une session de travail, suivre un ensemble fixe d’étapes, coordonner plusieurs rôles, sauvegarder des checkpoints et appeler des services externes comme partie d’une application séparée, Microsoft Agent Framework devient plus approprié.

Fonctions principales de Copilot dans VS Code

Regardons les principales fonctions de Copilot qui peuvent nous intéresser dans le travail DevOps quotidien.

1. Mode agentique et sessions

La principale capacité de Copilot dans VS Code est l’agent mode. Dans ce mode, Copilot cesse d’être simplement un assistant pour des lignes de code isolées et devient un participant à la session de travail.

Dans la Chat view, on peut choisir comment l’agent va travailler :

• où exécuter la tâche : localement, en arrière-plan ou dans le cloud ;
• quel rôle utiliser : par exemple Ask, Plan ou Agent ;
• à quel point l’agent peut utiliser les outils de façon autonome ;
• quel modèle appliquer, si plusieurs options sont disponibles.

C’est important pour les longues tâches d’ingénierie. Par exemple, on peut non pas simplement demander « qu’est-ce qui ne va pas dans le pipeline ? », mais confier à Copilot une tâche : ouvrir les fichiers nécessaires, comprendre la configuration, proposer des changements et vérifier le résultat via le terminal.

Le Plan agent est particulièrement utile. Il est pratique à utiliser avant une tâche complexe : demander d’abord à Copilot de préparer un plan, le vérifier soi-même, puis seulement passer aux changements. Cela réduit le risque que l’agent commence immédiatement à modifier le projet dans la mauvaise direction.

2. Plusieurs modes de travail, pas un seul chat

Copilot dans VS Code ne se limite pas à la Chat view. Il dispose de plusieurs surfaces de travail, chacune adaptée à un type de tâche.

La Chat view est pratique pour les tâches longues : comprendre un projet, analyser plusieurs fichiers, discuter d’un plan, exécuter une série d’étapes.

L’inline chat est utile pour les modifications locales directement dans le fichier ouvert. Par exemple, réécrire une fonction, simplifier un bloc YAML ou corriger un fragment précis de Dockerfile.

Le quick chat convient aux questions courtes, lorsqu’on ne veut pas changer de contexte.

Les inline suggestions et next edit suggestions aident pendant la saisie du code : elles proposent la suite d’une ligne, d’un bloc ou la modification suivante.

Les smart actions couvrent les opérations typiques : corriger une erreur, expliquer du code, chercher par sens, générer un message de commit.

Le sens pratique est simple : toutes les tâches ne doivent pas être confiées à un grand agent autonome. Parfois, une suggestion locale dans l’éditeur suffit ; parfois, il faut un chat ; parfois, un véritable agent mode.

3. Un vrai travail avec le contexte

L’un des points forts de Copilot dans VS Code est son travail avec le contexte du projet.

Copilot peut prendre en compte non seulement le texte de la question, mais aussi ce qui est actuellement ouvert dans l’IDE : le fichier actif, le fragment sélectionné, le nom du fichier, la structure du workspace et d’autres éléments.

Le contexte peut être donné explicitement. Par exemple, avec #file, #codebase, #terminalSelection et d’autres références, on peut indiquer à Copilot quelles données prendre en compte. Avec @terminal et d’autres mentions, on peut s’adresser à des participants ou sources de contexte spécialisés.

C’est important, car dans les tâches DevOps, la qualité de la réponse dépend presque toujours du bon contexte. Demander abstraitement « pourquoi le pipeline échoue ? » est une chose. Donner à Copilot un YAML concret, un Dockerfile, une sortie de terminal et la structure du projet en est une autre.

L’idée principale est que le contexte peut être piloté. Il n’est pas nécessaire de tout jeter dans un seul grand prompt. On peut le doser : montrer à l’agent uniquement les fichiers nécessaires, la sortie de terminal nécessaire et la partie pertinente du dépôt.

4. Modifications, review et checkpoints

Pour travailler avec du code, il ne suffit pas que Copilot puisse proposer des changements. Il faut aussi pouvoir contrôler ces changements.

VS Code propose un circuit de review pratique :

• on voit quels fichiers ont été modifiés ;
• on peut regarder les inline diffs ;
• on peut accepter ou rejeter des modifications individuelles ;
• on peut revenir à un checkpoint ;
• on peut utiliser le staging dans Source Control comme étape de confirmation supplémentaire.

C’est particulièrement précieux en DevOps. Les changements dans un pipeline, un Dockerfile, un Helm chart ou une configuration Terraform ne peuvent pas être acceptés à l’aveugle. Copilot peut proposer une solution, mais l’ingénieur doit voir exactement ce qui a changé.

En pratique, cela donne un mode de collaboration confortable : l’agent prépare un brouillon de modifications, l’ingénieur vérifie le diff, accepte ce qui est utile, corrige manuellement ce qui est discutable, puis lance seulement ensuite la validation.

5. Terminal et vérification du résultat

Pour le DevOps, le terminal n’est pas une fonctionnalité supplémentaire, mais une partie obligatoire du processus de travail.

Copilot dans VS Code peut travailler à côté du terminal : proposer des commandes, les expliquer, lire la sortie et ajuster les étapes suivantes à partir du résultat.

Cela change fondamentalement la qualité du travail. L’agent ne se contente pas de raisonner sur ce qui pourrait être incorrect. Il peut aider à suivre une itération d’ingénierie normale :

regarder la configuration -> proposer une modification -> exécuter une commande -> lire l’erreur -> préciser la solution -> répéter la vérification

Ainsi, l’aide IA devient une partie réelle du processus de diagnostic : il y a une modification, une commande, une sortie et une étape suivante.

6. Personnalisation pour le projet

Copilot peut être configuré pour un projet spécifique. Mais il est important de ne pas placer toutes les connaissances dans un seul énorme fichier d’instructions.

Si un seul fichier commence à contenir tout à la fois — style de code, architecture, commandes de build, règles de sécurité, rôles des agents, workflow et instructions métier — il se transforme rapidement en bruit. L’agent commence à tirer du contexte inutile dans chaque requête, et maintenir une telle structure devient difficile.

Il vaut mieux séparer les réglages par couches.

copilot-instructions.md doit servir au cadre général du projet : style, contraintes, règles de base, critères de finition.

AGENTS.md est pratique comme carte du dépôt : ce qui se trouve où, quelles zones sont responsables de quoi, quelles commandes sont utilisées pour le build et les tests.

Les fichiers *.instructions.md conviennent aux règles locales. Par exemple, une partie du dépôt peut avoir ses conventions Terraform, une autre ses conventions backend, une troisième ses conventions pour les YAML de déploiement.

Les fichiers *.prompt.md et *.agent.md sont mieux adaptés aux tâches répétables et aux rôles séparés : planner, executor, reviewer, critic.

SKILL.md est utile pour les playbooks étroits, nécessaires non pas toujours, mais seulement dans certaines situations.

.vscode/mcp.json et les hooks ne concernent plus les instructions textuelles, mais les intégrations et les règles strictes d’exécution.

Le sens de cette séparation est simple : chaque fichier doit résoudre sa propre tâche. Les règles générales ne doivent pas être mélangées aux conventions locales, les rôles aux playbooks, ni les intégrations aux instructions textuelles.

7. Observabilité et débogage du processus IA

Une autre capacité importante de Copilot dans VS Code est le débogage du travail agentique lui-même.

Pour le DevOps, il est important non seulement d’obtenir un résultat, mais aussi de comprendre comment l’agent y est arrivé : quels fichiers il a consultés, quels tools il a appelés, quel contexte il a utilisé, où il s’est trompé et pourquoi il a choisi tel chemin.

Pour cela, VS Code propose des outils d’observabilité :

• Agent Logs montrent la chronologie des événements, les tool calls et les LLM requests.
• Summary view aide à voir un résumé de l’usage des tokens, de la durée et des erreurs.
• Chat Debug view permet de voir le system prompt, le user prompt, le contexte et les payloads des outils.
• La commande /troubleshoot aide à analyser le comportement de la session courante directement via Copilot.

C’est précisément là que Copilot devient particulièrement utile pour le travail d’ingénierie. L’assistance agentique doit être non seulement « intelligente », mais aussi vérifiable. Quand on voit ce que l’agent a réellement fait et sur quelle base il a proposé une solution, l’ingénieur peut plus facilement faire confiance au processus et l’utiliser en sécurité dans un vrai projet.

Comment utiliser tout cela

Dans VS Copilot, le processus de travail ressemble généralement à ceci.

D’abord, le Plan agent ou l’ingénieur fixe le plan des étapes.

La tâche est lancée dans une session locale, car c’est là que l’agent a un accès complet au workspace, aux tools et aux modèles.

Le contexte est fourni via les fichiers actifs, #file, #codebase, #terminalSelection et les instructions du projet.

L’Agent effectue des modifications multi-fichiers et, si nécessaire, travaille à côté du terminal.

L’ingénieur examine les inline diffs, Keep/Undo et les checkpoints.

Si une vérification séparée est nécessaire, on lance un passage critique via un autre agent, une session séparée ou un custom agent de type reviewer.

Si le comportement de l’agent semble étrange, on utilise Agent Logs ou Chat Debug view, et non des suppositions.

Comment nos principes de cet article se réalisent dans le processus Copilot

Avant, nous avons analysé les principes et approches établis des systèmes multi-agents. Voyons maintenant comment les implémenter dans Copilot.

Plan-and-Execute

Il ne faut pas demander directement à Copilot : « corrige tout ». Pour les tâches complexes, il vaut mieux séparer planification et exécution.

D’abord, on demande au Plan agent de préparer un plan : quels fichiers consulter, quelles hypothèses vérifier, quelles modifications sont possibles et comment valider ensuite le résultat. Ensuite, on exécute la tâche étape par étape : soit une étape par message, soit une étape par session séparée.

Pour le DevOps, c’est particulièrement utile lorsque la tâche touche plusieurs endroits à la fois : pipeline YAML, Dockerfile, Helm chart, variables d’environnement et commandes de vérification. Le plan aide à ne pas mélanger tout cela dans une seule grosse modification.

Context engineering

La qualité de la réponse de Copilot dépend fortement du contexte qu’on lui donne.

Il vaut mieux indiquer explicitement les sources nécessaires : un #file précis avec la configuration du pipeline, le Dockerfile concerné, un fragment d’erreur sélectionné via #terminalSelection. #codebase est utile pendant la recherche et la première découverte du projet, mais il ne faut pas l’utiliser dans chaque requête sans nécessité.

La règle principale : donner à l’agent exactement le contexte nécessaire à l’étape en cours.

L’erreur typique consiste à charger immédiatement tout le dépôt, tout l’historique du chat et toutes les instructions du projet. La réponse ne devient pas forcément plus intelligente. Souvent, c’est l’inverse : l’agent commence à relier des parties non pertinentes du projet et produit des conclusions moins précises.

ReAct : regarder, formuler une hypothèse, vérifier

Dans Copilot, cette approche est pratique sous forme de cycle d’ingénierie court :

regarder les fichiers et la sortie du terminal -> formuler une hypothèse -> faire une action ciblée -> vérifier le résultat -> proposer l’étape suivante

Par exemple, si le pipeline a échoué après une modification du Dockerfile, il ne faut pas demander immédiatement à Copilot de réécrire massivement la configuration. Il vaut mieux d’abord lui demander de regarder l’erreur, de nommer une ou deux causes les plus probables, puis de vérifier une hypothèse, et seulement ensuite de proposer une modification.

Cela réduit le risque que l’agent passe d’un symptôme à une grande modification insuffisamment justifiée.

Critic isolation

Il vaut mieux sortir la vérification du résultat dans une étape séparée.

L’idée est simple : celui qui a effectué les changements ne doit pas se relire lui-même dans le même passage. Sinon, Copilot peut continuer à défendre sa propre logique au lieu de chercher honnêtement les problèmes.

En pratique, on peut faire ainsi :

• d’abord Copilot en agent mode exécute la tâche et propose des changements ;
• ensuite, une session de review séparée ou un reviewer agent séparé vérifie le résultat.

Il vaut mieux donner au reviewer non pas tout l’historique initial, mais des matériaux précis à vérifier :

• le diff ;
• la liste des fichiers modifiés ;
• les critères d’acceptation ;
• les commandes de validation ;
• le résultat attendu.

Le reviewer regarde alors précisément le résultat du travail : ce qui a changé, si cela correspond à la tâche, s’il y a des erreurs, des risques ou des vérifications manquantes.

Plus simplement : d’abord un passage séparé pour l’exécution, puis un passage séparé pour la critique du résultat. La review devient ainsi plus indépendante et plus utile.

Rubric-based review

Il vaut mieux ne pas formuler la review comme « vérifie si tout va bien », mais selon des critères définis à l’avance.

Pour les changements DevOps, ces critères peuvent être simples :

• Blocker — ce qu’il ne faut absolument pas laisser passer ;
• Warning — ce qui ne bloque pas, mais exige de l’attention ;
• Missing validation — quelles vérifications manquent ;
• Rollback risk — existe-t-il un risque de problème de rollback ;
• Security impact — y a-t-il un impact sur la sécurité.

Cette rubric peut être enregistrée dans copilot-instructions.md, dans un prompt de review séparé ou dans les paramètres d’un reviewer agent.

Ainsi, Copilot vérifiera les changements non pas en texte libre, mais selon une structure compréhensible. À la sortie, on n’obtiendra pas « ça a l’air bon », mais une liste concrète : ce qui bloque le merge, ce qu’il faut corriger, quelles vérifications ajouter et où se trouvent les risques.

Reflexion

Si une tentative n’a pas fonctionné, il ne faut pas simplement répéter la même requête. Copilot peut reprendre le même mauvais chemin.

Il vaut mieux fixer brièvement avant la prochaine tentative :

• ce qui a déjà été essayé ;
• quelle commande a été lancée ;
• quelle erreur reste ;
• quelles hypothèses n’ont pas été confirmées ;
• ce qu’il ne faut pas répéter.

Par exemple :

Nous avons essayé de modifier le Dockerfile et de remplacer l’image de base.

Après cela, le build échoue toujours sur la restauration des dépendances.

L’hypothèse d’un problème d’accès au registry n’a pas été confirmée.

Ne répète pas la vérification des droits sur le registry ; passe à l’analyse de NuGet/source mapping.

Copilot n’a pas de bouton séparé « Reflexion », mais cette approche est facile à utiliser manuellement : à la fin d’une tentative infructueuse, demander un court résumé, puis le transmettre à la session suivante ou à l’étape suivante.

Il est important de comprendre que les checkpoints aident à revenir en arrière sur les fichiers, mais n’expliquent pas pourquoi la tentative n’a pas fonctionné. En plus d’un checkpoint, il est donc utile de sauvegarder une courte conclusion textuelle : ce qui a été fait, ce qui a été obtenu et quelle conclusion en tirer.

Session context

Il vaut mieux diviser un long travail en sessions par phase.

Par exemple :

• session 1 — discovery et plan ;
• session 2 — exécution ;
• session 3 — review ;
• session 4 — documentation ou message de commit.

Au début de chaque session, il est utile d’écrire explicitement l’objectif, les contraintes et le critère de fin.

Si le chat devient trop long et trop bruyant, il vaut mieux commencer une nouvelle session et y transmettre un court handoff plutôt que de continuer à traîner tout l’historique.

Step logging / trace

Pour les tâches DevOps sérieuses, il est important de comprendre exactement ce qui a été fait.

Copilot fournit la partie technique de l’observabilité via Agent Logs, Summary, Agent Flow Chart et Chat Debug view. On peut y voir les tool calls, le contexte, les LLM requests et les erreurs.

Mais cela ne suffit pas toujours. Pour une trace d’ingénierie exploitable, il est utile de conserver aussi un court journal :

• ce qui a été vérifié ;
• quels fichiers ont été modifiés ;
• quelles commandes ont été lancées ;
• quel résultat a été obtenu ;
• quelles conclusions ont été faites.

Un tel journal aide à revenir plus tard sur la tâche ou à la transmettre à un autre ingénieur sans perte de contexte.

Stop and escalate

Il faut définir à l’avance quand l’agent doit s’arrêter.

Par exemple :

• pas plus de deux ou trois tentatives sans progrès ;
• arrêt en cas de contexte insuffisant ;
• arrêt avant modification de secrets ou de permissions ;
• arrêt avant changements critiques pour la production ;
• arrêt en cas de risque de suppression ou d’écrasement de données.

Dans Copilot, cela est pris en charge à la fois par le processus et techniquement. Les permission levels limitent l’autonomie de l’agent, et l’ingénieur peut arrêter l’exécution à tout moment pour passer en mode manuel.

C’est particulièrement important en DevOps, où une erreur peut toucher l’infrastructure, les accès ou la production.

Least privilege tools

Il ne faut pas donner à chaque rôle un accès maximal.

Le planner et le reviewer peuvent généralement travailler en read-only. Il leur suffit de lire les fichiers, d’analyser le diff et de proposer des conclusions.

L’executor peut recevoir le droit de modifier des fichiers et d’utiliser le terminal de manière limitée.

Les systèmes externes ne doivent être connectés que via les MCP servers réellement nécessaires pour la tâche concernée.

Ce n’est pas seulement une question de sécurité. Moins l’agent a d’outils inutiles, plus son comportement est prévisible. Si l’on donne trop de capacités à un rôle, il fera plus souvent des étapes inutiles et compliquera le processus.

En réunissant tout cela, Copilot dans VS Code permet d’appliquer les principes multi-agents sous une forme très pratique : planifier séparément de l’exécution, gérer le contexte, vérifier le résultat par un passage reviewer séparé, tracer les étapes, limiter les accès et arrêter l’automatisation à temps. C’est ce qui transforme Copilot d’un « chat intelligent dans l’IDE » en outil de travail pour un processus d’ingénierie contrôlé.

Quelles tâches DevOps se prêtent bien à cette approche

Copilot en agent mode aide surtout là où la tâche ne se compose pas d’une seule action, mais de plusieurs étapes : regarder les fichiers, comprendre les liens, proposer une hypothèse, effectuer une modification, vérifier le résultat et évaluer séparément les risques.

Analyse de pipeline CI/CD

C’est l’un des scénarios les plus évidents.

Un pipeline se compose souvent de nombreuses étapes, conditions, variables, templates et dépendances. Comprendre rapidement à la main où la logique s’est cassée peut être difficile.

Copilot peut aider à traiter la tâche par étapes :

• d’abord analyser la structure du pipeline ;
• puis trouver les zones suspectes ;
• ensuite proposer une cause possible de l’erreur ;
• après cela vérifier si la correction risque de casser d’autres environnements.

Ici, la valeur ne vient pas d’une seule « réponse intelligente », mais d’une analyse séquentielle à côté des vrais fichiers YAML, des logs et des paramètres du projet.

Travail avec Dockerfile et conteneurs

Un Dockerfile se casse rarement tout seul. Le problème est généralement lié au contexte concret du projet : image de base, ordre des layers, installation des dépendances, variables d’environnement, entrypoint, runtime ou différences entre le build local et le déploiement.

Copilot est utile parce qu’il peut regarder non pas un Dockerfile abstrait, mais les fichiers concrets du projet.

Par exemple :

• l’executor analyse le Dockerfile et les configurations liées ;
• propose une modification ciblée ;
• le reviewer vérifie séparément les risques.

Le reviewer peut remarquer des layers trop volumineux, un ordre de COPY étrange, des commandes risquées, des dépendances implicites ou des problèmes de reproductibilité du build.

Diagnostic de déploiement et d’incidents

Un incident commence généralement par du chaos : logs, erreurs, derniers changements, pipeline, configurations et comportement de l’environnement. Il faut rapidement relier tout cela en une image cohérente.

Ici, il est pratique de diviser le travail en rôles :

• un rôle collecte les symptômes ;
• un autre formule des hypothèses ;
• un troisième vérifie quelles hypothèses sont faibles et lesquelles méritent d’être vérifiées ensuite.

L’ingénieur obtient ainsi non pas un long récit général, mais un chemin plus court vers le diagnostic : ce que l’on sait, quoi vérifier en premier et quelles versions peuvent déjà être écartées.

Review des changements d’infrastructure

Copilot convient bien à la review des changements dans les pipelines, scripts de déploiement, Terraform, Helm charts ou manifests Kubernetes.

Ici, il est important de vérifier non seulement la syntaxe, mais aussi les conséquences opérationnelles :

• le changement peut-il casser le déploiement ;
• existe-t-il un rollback ;
• d’autres environnements sont-ils affectés ;
• la validation est-elle suffisante ;
• y a-t-il des hypothèses cachées ;
• existe-t-il un impact sur la sécurité.

Pour le DevOps, c’est particulièrement important, car une erreur dans un changement d’infrastructure n’apparaît pas toujours immédiatement sous forme de test échoué. Elle peut parfois devenir un déploiement instable, un problème d’accès ou un incident nocturne.

Support de la documentation et du contexte repo

Un autre scénario fort est la mise à jour de la documentation en parallèle des changements.

Après un diagnostic ou une correction, il faut souvent fixer une nouvelle connaissance : mettre à jour le README, le runbook, la description du pipeline, les instructions de déploiement ou le contexte repo.

Copilot peut aider ici aussi :

• un rôle collecte les faits depuis le dépôt ;
• un autre écrit un brouillon de documentation ;
• un troisième vérifie qu’il n’y a pas d’affirmations non confirmées ou de simplifications dangereuses.

Ainsi, la documentation est mise à jour non pas séparément « un jour plus tard », mais directement dans le contexte du vrai travail sur le projet. Cela réduit le risque que les connaissances importantes restent uniquement dans la tête de l’ingénieur ou dans une longue conversation.

Limites de Copilot

Même si Copilot est intégré directement dans l’IDE, cela ne rend pas automatiquement le processus agentique qualitatif et sûr. Cette approche a ses limites.

Premièrement, beaucoup dépend des instructions et des rôles. Si l’on ne sait pas clairement ce que l’executor doit faire, ce que le reviewer doit vérifier et quand la tâche est considérée comme terminée, Copilot peut commencer à perdre du temps sur des actions inutiles. Il vaut donc mieux définir explicitement les rôles, les règles et les critères de fin.

Deuxièmement, l’agent peut se tromper avec assurance. Il peut expliquer élégamment la cause d’un problème, mais manquer un fichier important, ne pas tenir compte d’un paramètre d’environnement ou tirer une conclusion sans contexte suffisant. La validation d’ingénierie reste donc obligatoire : diff, commandes, logs et résultats de tests sont plus importants qu’un texte confiant.

Troisièmement, il existe un risque de surcompliquer le processus. Toutes les tâches n’ont pas besoin d’un planner, d’un executor, d’un critic et d’un reviewer séparé. Parfois, une seule requête à Copilot, une modification locale et une vérification manuelle suffisent. L’approche multi-agent est utile là où la tâche est réellement multi-étapes et risquée.

Quatrièmement, il faut faire très attention aux accès. Si l’agent peut lire des fichiers, modifier du code, exécuter des commandes et accéder à des systèmes externes, une mauvaise configuration des permissions devient dangereuse. Cela concerne particulièrement les secrets, les configurations de production, les droits d’accès et les commandes destructrices.

Copilot peut fortement accélérer le travail d’ingénierie, mais il ne supprime pas le contrôle d’ingénierie. Il faut l’utiliser comme un assistant dans un processus maîtrisé, et non comme un remplacement entièrement autonome de l’ingénieur.

Conclusion

Le principal bénéfice de Copilot dans VS Code se ressent très vite : il y a moins de bascule manuelle entre le dépôt, le terminal, les fichiers et une discussion séparée de la tâche.

Si l’agent peut lui-même parcourir les configurations, collecter le contexte, proposer des changements et transmettre le résultat à une vérification séparée, une partie de la routine disparaît tout simplement. L’ingénieur n’a plus besoin de déplacer constamment des fragments de code, des logs et des erreurs dans un chat séparé. Tout se passe à côté de l’endroit où se trouve la tâche elle-même.

C’est pourquoi la force de Copilot dans VS Code ne réside pas seulement dans l’accès à un modèle. Sa force est que le modèle travaille à l’intérieur d’un véritable circuit d’ingénierie : près des fichiers, des commandes, des instructions du projet, des diffs et des résultats de vérification.

Lorsque l’agent voit non pas un résumé du problème, mais le dépôt lui-même et la sortie du terminal, il aide non pas de manière abstraite, mais dans le contexte d’un projet concret.

Mais il faut se rappeler une chose : plus l’agent est proche du projet réel, plus le contrôle devient important. Il faut vérifier les diffs, regarder la sortie des commandes, limiter les accès, séparer les rôles et ne pas accepter les changements sans validation d’ingénierie.

Donc :

• nous avons d’abord divisé le travail en rôles ;
• puis nous avons regardé comment assembler techniquement ce schéma ;
• ensuite, nous avons rapproché l’approche agentique du vrai dépôt, des fichiers et du terminal.

Après cela apparaît une question pratique suivante : si ce schéma fonctionne, comment éviter de le reconstruire depuis zéro dans chaque nouveau projet ?

Nous parlerons ensuite d’un framework portable : un ensemble de règles, instructions, rôles, prompts, skills et conventions que l’on peut réutiliser entre projets.