Arrêtez de coller du contexte : un meilleur workflow dans l'IDE

Comptez le nombre de fois où, cette semaine, vous avez fait Ctrl+A dans un fichier, copié, basculé dans un chat IA, collé, puis posé votre question. Si le chiffre dépasse cinq, votre workflow est cassé, et la solution n’est pas un prompt plus malin, c’est un câblage plus court entre votre éditeur et le modèle.

Le copier-coller de contexte est le signe que votre outil IA ne voit pas ce que vous voyez. Vous devez manuellement lui donner des yeux, fichier par fichier, sélection par sélection. C’est lent, c’est fragile (vous oubliez un fichier important), et ça consomme de la fenêtre de contexte avec du contenu souvent non pertinent (vous collez le fichier entier alors que seule une fonction compte).

Les trois niveaux d’intégration

Niveau 0 : Le chat séparé (copier-coller)

Vous avez un éditeur d’un côté et ChatGPT/Claude dans un onglet de l’autre. Chaque question nécessite de copier manuellement le contexte pertinent. C’est le niveau où la plupart des développeurs commencent, et où beaucoup restent.

Coût caché : chaque changement de contexte (éditer → chat → éditer) prend 15-30 secondes. Multiplié par 30 interactions par jour, c’est 10-15 minutes perdues en copier-coller pur. Sans compter les fois où vous oubliez de mettre à jour le contexte collé après une modification.

Niveau 1 : L’IDE augmenté (Cursor, Copilot Chat, Windsurf)

Le modèle voit votre fichier actif, votre sélection, et parfois les fichiers ouverts. Vous posez des questions dans un panneau intégré et le modèle a automatiquement accès au contexte de votre éditeur.

Le gain : plus de copier-coller. Le modèle voit ce que vous voyez. La friction tombe à zéro pour les questions « sur ce fichier ».

La limite : le contexte est souvent trop étroit (le fichier actif) ou trop large (tout le projet). Vous devez apprendre à « pointer » le modèle, @file, @folder, @codebase, ce qui est un skill à part entière.

Niveau 2 : L’agent avec accès au projet (Claude Code, Aider)

Le modèle n’est pas dans l’IDE, il est l’IDE. Il peut lire n’importe quel fichier, exécuter des commandes, parcourir le codebase. Vous décrivez le problème en langage naturel ; l’agent décide quoi lire, quoi modifier, quoi vérifier.

Le gain : vous cessez de gérer le contexte. L’agent le collecte lui-même.

Le risque : l’agent peut lire plus que nécessaire, toucher plus que demandé, et prendre des initiatives non sollicitées. C’est pour ça que les barrières de périmètre deviennent essentielles.

Mon workflow actuel

Après six mois d’itération, voici comment je travaille :

Pour les questions rapides (< 1 min) : Cursor ou l’inline chat de l’IDE. Je sélectionne le code, je pose la question, je lis la réponse dans le même panneau. Pas de changement de fenêtre.

Pour les tâches de modification (1-10 min) : Claude Code en terminal, dans le projet. Je décris la tâche en une phrase, l’agent lit les fichiers pertinents, propose un plan, et je valide avant qu’il modifie.

Pour l’exploration (> 10 min) : Claude Code avec un prompt large et la permission de lire tout le projet. Je lui demande de comprendre un module entier, de cartographier les dépendances, de trouver tous les usages d’un pattern.

La règle : plus la tâche est longue, plus l’agent a d’autonomie de lecture ; mais plus la tâche implique des modifications, plus le périmètre d’écriture est restreint.

Ce qui change quand on arrête de coller

Les questions deviennent plus fréquentes. Quand poser une question coûte zéro friction, vous posez des questions que vous n’auriez jamais posées avant, « est-ce que ce pattern existe déjà dans le projet ? », « quels fichiers importent cette fonction ? ». Chacune vous fait gagner cinq minutes de recherche manuelle.
Le contexte est toujours frais. Plus de « oups, j’ai collé l’ancienne version du fichier ». L’agent lit le fichier actuel, pas celui que vous avez copié il y a dix minutes.
Vous pensez en termes de tâches, pas de prompts. Au lieu de « voici mon code, dis-moi ce qui ne va pas », vous dites « corrige le bug dans parseResponse qui cause un crash quand la réponse est vide ». Le shift mental est significatif : vous décrivez le problème, pas le contexte.

Le copier-coller n’est pas un workflow, c’est l’absence de workflow. Câblez le modèle à votre éditeur, et la question passe de « comment donner du contexte au modèle » à « comment contraindre le périmètre de ce qu’il touche ». C’est un meilleur problème à avoir.

Si cela vous a parlé, vous aimerez Fichiers mémoire : donner à ton agent un cerveau de travail et Comment j’empêche un binôme IA de réécrire la moitié du dépôt. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.