Claude dans VS Code · mettez 3 IA au travail en parallèle et avancez trois fois plus vite

Pour qui est-ce ?

Pour celui qui construit déjà avec un agent de code (comme Claude Code) et qui veut avancer plus vite en travaillant comme un pro — sans programmer davantage. C'est la suite naturelle du [guide GitHub](/recursos/guarda-todo-en-github-antes-de-que-la-ia-lo-rompa) : là vous avez appris à sauvegarder et à revenir en arrière ; ici, à travailler sur plusieurs fronts à la fois.

Quand le besoin apparaît-il ? (le moment exact)

Le moment arrive quand votre projet grandit et qu'une seule IA, qui fait une chose à la fois, ne vous suffit plus. Vous voulez avancer plus vite : que pendant qu'une session construit une fonctionnalité, une autre corrige un bug et une troisième teste une idée neuve — le tout en même temps. Ou encore quand vous hésitez entre deux chemins (« je fais comme ci ou comme ça ? ») et que vous voulez voir les deux avant de décider. Ou quand vous voulez tester quelque chose de risqué sans toucher à ce qui marche déjà. Dans tous ces cas, y aller une chose à la fois sur votre unique version est lent et fragile.

La douleur d'où ça naît · lent et avec la peur au ventre

Deux douleurs à la fois. Celle de la vitesse : avec une seule session vous avancez en file indienne — vous finissez une chose pour pouvoir commencer l'autre, et le gros projet devient d'une lenteur infernale. Et celle de la peur : comme tout se passe sur votre unique bonne version, vous craignez que l'IA casse quelque chose en « améliorant » autre chose, alors vous demandez des changements timides. Travailler en parallèle, dans des versions isolées, tue les deux : vous avancez sur plusieurs fronts à la fois ET sans risque.

C'est quoi, un « worktree » ? (en clair)

Dans le guide GitHub vous avez vu les branches : des copies parallèles de votre projet. Un worktree va un cran plus loin : il vous laisse avoir plusieurs de ces branches ouvertes et vivantes en même temps, chacune dans son propre dossier, sans que l'une touche à l'autre. Pendant qu'une IA travaille sur l'« idée A », une autre peut être sur l'« idée B », et votre version principale reste intacte. Ce n'est pas une par une — c'est toutes à la fois.

Imaginez-le ainsi · les photocopies vivantes

Votre projet principal, c'est le document original. Un worktree, c'est une photocopie qui prend vie propre : vous pouvez gribouiller dessus à fond pendant que l'original reste propre sur une autre table. Et vous pouvez avoir cinq photocopies à la fois, chacune avec une idée différente. À la fin, celle qui a bien tourné, vous la reportez sur l'original ; les autres, à la poubelle. L'original n'a JAMAIS été en danger.

Le super-pouvoir · une branche par idée, avec Claude dans VS Code

Claude Code a une extension officielle pour VS Code (elle fonctionne aussi dans Cursor et compatibles). De là vous ouvrez plusieurs sessions d'IA en parallèle, chacune dans son propre worktree, et vous voyez les changements qu'elle propose avec un diff visuel (côte à côte) que vous approuvez ou rejetez. Le mieux : créer un worktree isolé tient en une seule commande.

Créer un worktree pour une idée (une commande)bash

claude --worktree mi-idea-arriesgada

Cela crée une copie isolée de votre projet (dans .claude/worktrees/mi-idea-arriesgada/) sur une branche neuve, sans toucher à votre version principale. Vous travaillez l'idée là ; si ça marche, vous la fusionnez ; sinon, vous l'effacez et il ne s'est rien passé. Vous pouvez ouvrir une autre session avec claude --worktree otra-idea et avoir les deux en compétition en même temps.

N'apprenez pas les commandes · demandez-le à votre IA

Comme dans toute la série : si vous ne voulez pas toucher au terminal, vous parlez à votre agent. « Ouvre un worktree pour tester [ton idée] sans toucher à ma version principale » — et il le fait. Vous, vous décidez seulement quelle idée tester et laquelle vous gardez.

3 scénarios où ça vous sauve

1 · Le changement risqué

Vous voulez repenser quelque chose de gros mais vous avez peur de casser ce qui marche. Vous le faites dans un worktree : si ça tourne bien, vous le fusionnez ; si ça foire, vous le jetez. Votre bonne version n'en a rien su.

2 · Les deux chemins (comme ci ou comme ça ?)

Vous ne savez pas si une fonctionnalité se fait d'une façon ou d'une autre. Vous ouvrez DEUX worktrees, vous laissez l'IA tester chaque approche en parallèle, vous les comparez sur des résultats réels, et vous gardez le gagnant. Vous décidez sur preuves, pas sur intuition.

3 · La session coincée

Une conversation avec l'IA s'est emmêlée ou est partie sur une mauvaise piste. Au lieu de la perdre, vous ouvrez une autre session en parallèle (son propre worktree) et vous repartez à frais, sans jeter le travail de la première.

C'est comme ça qu'on travaille · plusieurs sessions à la fois (le grand accélérateur)

C'est le plus grand bénéfice, et c'est exactement comme ça qu'on construit : au lieu d'une seule IA qui avance en file indienne, on a plusieurs sessions qui travaillent en parallèle, chacune dans son propre worktree. La session 1 construit une partie du produit, la session 2 monte autre chose, une session 3 pourrait être en train de tester une idée neuve — les trois avancent EN MÊME TEMPS, sans se marcher dessus. C'est comme avoir trois employés au lieu d'un, chacun à son bureau, sans se gêner.

Le flux complet (parallèle + C-A-R + merge)

La clé pour que ça ne vire pas au chaos : chaque session boucle bien son travail avant de le fusionner. Le cycle : (1) chaque session travaille sur SA branche/worktree · (2) quand elle finit quelque chose, vous lui appliquez le [protocole C-A-R](/recursos/protocolo-car-construir-sin-bugs) — vous auditez, vous déboguez, vous le rendez irréprochable · (3) c'est seulement là que vous faites le merge de cette branche vers la principale · (4) vous recommencez avec la suivante. Ainsi vous avancez trois fois plus vite, mais chaque pièce entre propre dans votre bonne version.

La règle qui évite le désastre · push vers TA branche, pas la principale

L'erreur classique quand on travaille en parallèle : faire un push vers la branche principale depuis une session à moitié finie et écraser le travail d'une autre. La règle d'or : chaque session sauvegarde et fait push vers SA PROPRE branche, jamais directement vers la principale. La principale ne reçoit des choses que via merge, et seulement après audit. En cas de doute, demandez-le à votre IA : « fais un push vers la branche de cette session, pas vers main ».

Imaginez-le ainsi · plusieurs cuisiniers, une cuisine bien rangée

Trois cuisiniers dans la même cuisine qui se percutent, c'est le chaos. Mais si chacun a son plan de travail (son worktree) et n'apporte le plat sur la table principale que lorsqu'il est terminé et goûté (le merge après C-A-R), la cuisine vole : trois plats sortent dans le temps d'un seul, et aucun ne sort à moitié fait. Ça, c'est du travail en parallèle bien mené.

La revue visuelle · vous approuvez ou rejetez, c'est vous qui commandez

Dans VS Code, quand l'IA veut modifier un fichier, elle vous montre une comparaison côte à côte : ce qu'il y avait vs. ce qu'elle propose. Vous décidez : accepter, rejeter, ou lui dire quoi changer. Rien n'est modifié dans votre dos. C'est comme avoir l'employé qui vous montre chaque changement avant de l'appliquer, au lieu de tout toucher et de vous mettre au courant après.

Attente honnête

La revue se fait fichier par fichier (diff côte à côte, accepter/rejeter), ce n'est pas encore un « tout approuver d'un coup » parfait. Et fusionner des branches (merge) donne parfois des conflits qui se résolvent avec le flux git habituel — même si l'IA vous aide en langage naturel. Sans enfumage : c'est puissant, mais c'est un outil de travail, pas de la magie en un clic.

La routine en or · avancer en parallèle sans chaos

L'habitude

Une session = une branche/worktree : chaque front de travail dans sa copie isolée. Jamais plusieurs sur la version principale.
Push vers TA branche, jamais la principale : chaque session sauvegarde chez elle ; la principale ne reçoit que via merge.
Auditez avec C-A-R avant de fusionner : aucune branche n'entre dans la principale sans passer d'abord son audit/débogage.
Revoyez le diff dans VS Code avant d'accepter — c'est vous qui commandez, pas l'IA.
Ne fusionnez que ce qui est irréprochable : la pièce terminée et auditée est fusionnée ; les idées qui n'ont pas pris, on les efface sans culpabiliser.

Prompt prêt · montez votre flux de travail en parallèle

Copiez-le et collez-le à votre agent de code pour qu'il vous guide à travailler sur plusieurs fronts à la fois, sans avoir à apprendre de commandes :

Collez-le à votre agent · travailler en plusieurs sessions en parallèletexto

Je veux avancer plus vite sur mon projet en travaillant en PLUSIEURS sessions en parallèle, chacune dans sa propre version isolée (worktree), sans qu'elles se marchent dessus ni cassent ma version principale. Guide-moi en langage simple, en supposant que je ne connais rien à git.

1. Explique-moi en une phrase ce qu'est un worktree (une copie vivante et isolée de mon projet).
2. Je vais travailler sur ces fronts en même temps : [liste tes tâches, ex : "1) repenser la page d'accueil, 2) corriger le login, 3) tester une idée neuve"]. Crée un worktree dédié pour chacun, en ramifiant depuis ma version stable.
3. Dis-moi comment ouvrir VS Code dans chaque worktree pour voir le diff et approuver/rejeter les changements visuellement.
4. RÈGLE IMPORTANTE : chaque session doit faire un push vers SA PROPRE branche, JAMAIS vers la principale (main). La principale ne reçoit des choses que via merge.
5. Quand je termine une tâche dans son worktree, avant de la fusionner : applique-lui le protocole C-A-R (audite, débogue, rends-la irréprochable). C'est seulement alors que tu fais le merge de cette branche vers la principale, et que tu résous tout conflit en langage naturel.
6. Si une idée n'a pas pris, aide-moi à écarter son worktree sans que mon projet principal ne s'en aperçoive.

Règle d'or : j'avance en parallèle, mais dans la branche principale n'entre que ce qui est audité, via merge — jamais à moitié fait.

Dans NeuralOS, l'isolement est déjà intégré

Dans NeuralOS, chaque session de travail avec un agent naît déjà isolée — vous testez des choses sans qu'elles se marchent dessus, sans avoir à penser aux worktrees ni aux branches. L'idée « expérimente en parallèle sans peur » fait partie de la conception du produit. Si vous voulez ce super-pouvoir sans la courbe d'apprentissage, c'est le raccourci.

Sauvegarde tout dans GitHub · la base de tout ceciLes worktrees s'appuient sur les branches de git. Si vous avez sauté le guide GitHub, commencez par là.Le protocole C-A-R · audite chaque branche avant de fusionnerAvant de fusionner une idée à votre version principale, auditez-la avec C-A-R. Se combine parfaitement avec le travail en parallèle.

#claude-code#vscode#worktrees#productividad