Où est l'IA dans votre éditeur

En bref

Résumé de l’article

Quand on parle d’« IA pour programmer », on pense souvent à une seule chose : une fenêtre de discussion où l’on pose une question. Dans un éditeur comme Visual Studio Code, l’assistance se présente en réalité sous quatre formes distinctes, qui n’ont ni le même usage, ni le même coût, ni les mêmes risques : la complétion au fil de la frappe, la discussion, l’édition en place, et le mode agent.

Cet article décrit ces quatre formes, dit où les trouver dans l’interface, et explique ce qui les sépare : le degré d’autonomie que vous accordez à l’outil. Savoir laquelle vous êtes en train d’utiliser est la première compétence à acquérir : c’est elle qui détermine ce que vous devez relire, et à quel point.

Points clés à retenir

• Quatre formes, une différence de degré. Complétion, discussion, édition en place, mode agent : la frontière n’est pas la marque de l’outil, c’est l’autonomie qu’il prend.
• La complétion est déjà de l’IA. Le texte grisé qui apparaît devant votre curseur est produit par un modèle, au même titre qu’une réponse de chat.
• Le mode agent agit sans vous demander à chaque étape : il crée des fichiers, lance des commandes, relit ses erreurs. C’est le seul mode où l’outil modifie votre projet de lui-même.
• Tout passe par des extensions. Copilot est installé par défaut dans VS Code, mais d’autres outils peuvent s’installer via les extensions.
• Plus l’outil est autonome, plus votre relecture doit être minutieuse. L’inverse serait confortable, mais c’est le contraire qui est vrai.

Contenu de l’article

La complétion au fil de la frappe

C’est la forme la plus discrète, et celle qu’on oublie de compter comme de l’IA. Vous tapez, et du texte grisé apparaît devant le curseur : une fin de ligne, parfois un bloc entier. Tab accepte, Échap refuse, Alt+] propose une autre suggestion (susceptible de changer selon votre système d’exploitation).

Ce qu’il faut comprendre : la suggestion n’est pas une recherche dans une base d’exemples. Le modèle reçoit ce qui entoure votre curseur (le fichier courant, souvent quelques fichiers ouverts à côté) et prédit la suite. C’est pour cette raison que la complétion imite ce que vous venez d’écrire : vos noms de variables, votre façon d’indenter, votre manière de documenter. Vous le vérifierez en activité pratique.

L’état de la complétion se lit dans la barre d’état, en bas à droite de la fenêtre : une icône permet de la mettre en pause, pour le fichier courant ou pour tout l’éditeur. C’est utile quand vous voulez réfléchir sans qu’une proposition vienne s’intercaler.

La discussion

C’est la fenêtre de chat, dans la barre latérale ou en panneau. Vous y posez des questions en langue naturelle : « à quoi sert cette fonction ? », « pourquoi ce test échoue ? », « écris-moi une fonction qui… ».

La différence avec un chat dans un navigateur est le contexte. L’assistant intégré voit votre code ; celui du navigateur ne voit que ce que vous lui collez. Dans VS Code, on désigne explicitement ce que l’assistant doit regarder :

• #file pour joindre un fichier précis,
• #selection pour la portion sélectionnée dans l’éditeur,
• #codebase pour laisser l’outil chercher lui-même dans le projet,
• @workspace pour une question sur l’ensemble du projet.

Cette différence n’est pas un détail d’ergonomie : c’est elle qui décide si l’assistant réutilise vos fonctions existantes ou s’il en réécrit de nouvelles à côté.

L’édition en place

Vous sélectionnez un bloc de code, vous appelez l’édition en place (Ctrl+I, ou Cmd+I sur macOS), vous décrivez la transformation voulue : « ajoute des annotations de type », « extrais ça dans une fonction », « gère le cas de la liste vide ».

L’outil ne répond pas dans une fenêtre à côté : il propose une modification de votre fichier, affichée comme un diff, que vous acceptez ou rejetez. C’est la forme la plus adaptée aux retouches, parce qu’elle vous montre exactement ce qui change.

Le mode agent

C’est le changement de nature. Dans les trois formes précédentes, l’outil propose et vous appliquez. En mode agent, l’outil agit : il crée des fichiers, en modifie plusieurs d’affilée, lance des commandes dans le terminal, lit la sortie, corrige et recommence.

Concrètement, vous écrivez une demande de haut niveau (par exemple « ajoute une commande d’export CSV, avec ses tests ») et l’agent déroule un plan. VS Code vous demande votre accord avant les actions sensibles, en particulier avant d’exécuter une commande, mais l’essentiel du travail se fait sans que vous validiez chaque étape.

Ce mode est le plus puissant et le plus exigeant en relecture. Un agent qui se trompe ne produit pas une mauvaise suggestion : il produit cinq fichiers cohérents entre eux et faux, ce qui est beaucoup plus difficile à repérer.

Ce que ça change pour votre travail

Le tableau ci-dessous résume ce qui distingue ces quatre formes.

Une conséquence pratique : il n’y a pas de « bon » mode. Pour ajouter un try/except autour de trois lignes, l’édition en place est plus rapide et plus sûre qu’un agent. Pour comprendre un projet qu’on découvre, la discussion avec @workspace est imbattable. Pour écrire d’un bloc une fonctionnalité bien spécifiée avec ses tests, l’agent fait gagner un temps réel.

Le choix de l’extension

Copilot est fourni avec VS Code, mais rien ne vous y oblige. La marketplace d’extensions propose d’autres intégrations, qui offrent les mêmes quatre formes avec d’autres modèles derrière : Continue, Cline, Roo Code, les extensions publiées par Mistral, ou encore l’extension de Claude.

Deux critères pour choisir, au-delà de la qualité des réponses :

• Où part votre code. Une extension envoie le contenu de vos fichiers à un serveur distant. Sur du code d’entreprise sous accord de confidentialité, ce point n’est pas négociable, et certaines extensions permettent de brancher un modèle exécuté localement.
• Ce que ça coûte. C’est l’objet de la fiche suivante : Crédits et modèles.

Pour aller plus loin

Ce que fait un agent, étape par étape

Un agent n’est pas un modèle différent des autres. C’est un modèle ordinaire, placé dans une boucle, auquel l’extension donne accès à des outils : lire un fichier, chercher dans le projet, modifier un fichier, lancer une commande dans le terminal, etc.

À chaque tour de boucle :

1. L’extension envoie au modèle votre demande, la liste des outils disponibles, et tout ce qui s’est passé depuis le début de la session.
2. Le modèle répond, soit par un texte destiné à vous, soit par une demande d’utilisation d’un outil (par exemple « lance la commande uv run python -m unittest »).
3. Si c’est une demande d’outil, l’extension l’exécute, après vous avoir demandé votre accord si l’action est sensible. Le résultat (le contenu du fichier, la sortie de la commande…) est ajouté à la conversation, et on recommence.

La boucle s’arrête lorsque le modèle répond sans demander d’outil. En pseudo-code, cela donne à peu près ceci :

# Simplified sketch of an agent loop (not real code)
messages = [instructions, user_request]
while True:

    # The model either answers or asks to use a tool
    answer = model(messages, available_tools)
    messages.append(answer)
    if not answer.tool_calls:
        break

    # The extension runs the requested tools, after approval if needed
    for call in answer.tool_calls:
        result = run_tool(call)
        messages.append(result)

# Final answer for the user
print(answer.text)

Trois conséquences pratiques :

• Le modèle ne touche jamais directement votre machine. C’est l’extension qui exécute les actions. Les demandes d’accord avant une commande sont donc le vrai point de contrôle : les accepter sans les lire revient à le supprimer.
• Chaque tour de boucle est une requête. C’est pour cela qu’une session agent consomme vite (voir la fiche Crédits et modèles).
• La conversation grossit à chaque tour. Après de nombreux tours, le contexte est rempli de sorties de commandes anciennes, ce qui coûte cher et peut dégrader les réponses (voir la fiche Le contexte).

Donner de nouveaux outils à un agent : MCP

Les outils d’un agent ne se limitent pas à ceux fournis par l’extension. Le Model Context Protocol (MCP) est un protocole ouvert qui permet de brancher des outils supplémentaires : interroger une base de données, lire les tickets d’un gestionnaire de projet, consulter une documentation à jour, piloter un navigateur, etc. VS Code permet de déclarer des serveurs MCP, dont les outils deviennent alors disponibles en mode agent.

La complétion voit aussi ce qui suit le curseur

Les modèles de complétion sont généralement entraînés à remplir un trou (en anglais, fill-in-the-middle) : ils reçoivent le texte avant le curseur et le texte après, et produisent ce qui manque entre les deux.

Vous pouvez en tirer parti. Si vous écrivez d’abord la signature d’une fonction, sa docstring et son return, puis que vous placez le curseur au milieu, la suggestion tiendra compte de ce que la fonction doit renvoyer. C’est aussi pour cela que la complétion utilise un petit modèle : elle doit répondre en quelques dizaines de millisecondes, à chaque frappe.

Pour aller encore plus loin

• GitHub Copilot in VS Code

  La documentation officielle de Copilot dans VS Code (en anglais), qui détaille chacune des formes d’assistance.
• Use agent mode in VS Code

  Le fonctionnement du mode agent dans VS Code, ses outils et ses demandes d’accord (en anglais).
• Model Context Protocol

  Le site officiel du protocole MCP, avec sa spécification et des exemples de serveurs (en anglais).
• Building effective agents

  Un article d’Anthropic sur la conception des agents, et sur les cas où une solution plus simple suffit (en anglais).