Le 17 septembre 2026, Anthropic a mis en bêta une refonte complète des Projects dans Claude Code. Jusqu'ici, un « projet » était surtout un espace de rangement : fichiers, artefacts et historique de conversation regroupés au même endroit. La nouvelle version change de nature : la conversation principale du projet devient une couche de coordination capable de faire travailler plusieurs sessions cloud de Claude Code en parallèle, sur des branches différentes du même dépôt.

Concrètement, tu décris un objectif — pas une commande unique, un vrai périmètre de travail — et c'est Claude qui découpe la tâche, lance les sessions nécessaires, suit leur avancement et assemble le résultat. C'est un changement de posture assez net par rapport à l'usage habituel d'un agent de code, où c'est toi qui ouvres, surveilles et fermes chaque session une par une.

Voici ce que ça change vraiment, comment ça fonctionne sous le capot, et où sont les limites à connaître avant de t'y fier pour du travail sérieux.

Un coordinateur, plusieurs threads, un seul dépôt

L'architecture repose sur une distinction claire entre la conversation de projet et les threads qu'elle engendre. La conversation principale sert de coordinateur : c'est là que tu formules la demande, et c'est elle qui garde la mémoire partagée du projet — fichiers, artefacts, décisions passées.

Chaque thread, lui, est une session Claude Code cloud à part entière, avec sa propre branche Git et sa propre copie du dépôt. Les threads tournent en parallèle, continuent de travailler même si tu fermes ton ordinateur, et remontent leur progression dans la conversation principale au fur et à mesure. Le coordinateur ne se contente pas de distribuer le travail : il scope la demande initiale, découpe en tâches, délègue à des threads distincts, puis relit les sorties avant de proposer un résultat assemblé.

Ce découpage rappelle une pratique déjà répandue chez les développeurs qui font tourner plusieurs agents à la main avec des git worktrees :

# La méthode manuelle que Claude Code Projects automatise en partie
git worktree add ../projet-feature-a feature-a
git worktree add ../projet-feature-b feature-b

# Chaque worktree a son propre répertoire de travail,
# une seule instance du dépôt .git est partagée
cd ../projet-feature-a && claude

La différence, c'est que tu n'as plus à créer les worktrees, lancer les sessions et faire le suivi toi-même : le coordinateur s'en charge, et les threads restent visibles comme des cartes dans la conversation de projet.

Ce que fait vraiment le coordinateur (et ce qu'il ne fait pas)

Le rôle du coordinateur se limite à quatre choses : cadrer la demande, répartir les tâches, superviser l'avancement et assembler le résultat final. Quand un thread a poussé une branche ou ouvert une pull request, sa carte affiche des actions rapides — Resolve conflicts, Fix CI, Address comments, Merge — qui envoient directement une instruction au thread concerné sous forme de message, sans que tu aies à rouvrir sa session.

Ce qu'il ne fait pas, en revanche, c'est résoudre automatiquement les conflits d'édition. Si deux threads modifient la même portion de code, le système traite ça exactement comme un conflit de merge Git classique entre deux pull requests concurrentes — pas de magie, pas de fusion sémantique silencieuse.

Les conflits ne disparaissent pas, ils se déplacent

C'est le point le plus important à comprendre avant d'adopter l'outil sur un vrai projet : paralléliser le travail avec plusieurs agents ne supprime pas le risque de conflit, il le déplace au moment de la fusion. Si tu demandes à un projet de « refactorer l'authentification » et « ajouter un nouveau champ au formulaire d'inscription » en parallèle, et que les deux threads touchent au même fichier de validation, tu te retrouveras avec un conflit à trancher toi-même, via les mécanismes Git habituels :

git fetch origin
git checkout feature-a
git merge feature-b
# <<<<<<< HEAD
# ... code du thread A ...
# =======
# ... code du thread B ...
# >>>>>>> feature-b

Autrement dit, la valeur de l'outil dépend directement de la qualité du découpage initial. Plus les tâches confiées aux threads sont indépendantes — des modules séparés, des couches distinctes, des fichiers qui ne se recoupent pas — plus le gain de temps est réel. À l'inverse, sur une base de code fortement couplée, paralléliser peut simplement transformer un problème de conception séquentielle en une série de conflits de merge à gérer a posteriori.

Qui peut l'essayer, et à quelles conditions

La bêta a démarré le 17 septembre pour un groupe restreint d'abonnés Claude Pro et Max qui utilisent déjà les sessions cloud de Claude Code et n'ont pas de projet existant sur la version web ou desktop. Anthropic prévoit d'élargir l'accès dans la semaine suivant l'annonce à davantage d'utilisateurs Pro et Max, puis, dans un second temps, aux plans Team et Enterprise, ainsi qu'à Cowork et aux conversations Claude classiques. Les abonnés Pro et Max qui n'ont pas encore accès peuvent s'inscrire sur liste d'attente.

Ce déploiement progressif n'est pas anodin : faire tourner plusieurs sessions cloud en parallèle consomme davantage de quota que des sessions séquentielles, et Anthropic teste visiblement l'impact avant une ouverture large.

Comment aborder tes premières tâches en parallèle

Découpe ta demande en périmètres qui touchent des fichiers ou des modules distincts, pas des couches transverses du même composant.
Formule l'objectif final, pas la suite d'étapes — c'est le coordinateur qui doit faire ce découpage, sinon tu perds l'intérêt de la fonctionnalité.
Surveille les cartes de threads après un push ou une PR : c'est là que tu récupères la main pour trancher un conflit ou valider une fusion.
Garde un œil sur ta consommation de quota si tu es sur un plan avec des limites serrées — plusieurs sessions cloud simultanées coûtent plus cher qu'une seule.

Ce que ça dit de la direction prise par les outils de code IA

Claude Code Projects s'inscrit dans une tendance de fond : le passage d'un agent qui exécute une instruction à un système qui gère un flux de travail complet, avec plusieurs exécutants et un point de supervision. Ce n'est pas une nouveauté conceptuelle — les équipes qui orchestrent déjà plusieurs agents à la main avec des worktrees ou des scripts maison reconnaîtront le principe — mais c'est la première fois qu'Anthropic l'intègre nativement dans l'interface, avec un suivi visuel des threads et une mémoire de projet partagée entre eux.

La bascule à surveiller dans les prochains mois, c'est moins la technique que l'usage : est-ce que les équipes vont réellement reformuler leurs demandes comme des objectifs de haut niveau à déléguer, ou continuer à piloter chaque session une par une par habitude ? La réponse déterminera si cette fonctionnalité change le flux de travail quotidien ou reste une option pour les tâches ponctuellement massives — grosses migrations, refontes multi-modules, séries de correctifs indépendants.

Si tu as accès à la bêta, le test le plus instructif n'est pas une tâche énorme mais une tâche modeste et bien découpée en deux ou trois lots indépendants : tu verras vite si le coordinateur découpe le travail comme tu l'aurais fait toi-même, ou s'il te faut encore reformuler la demande pour éviter les conflits inutiles.

Quand ça vaut le coup, quand ça ne vaut pas le coup

Après quelques essais, une règle simple se dégage pour décider si une tâche mérite d'être confiée au coordinateur plutôt qu'à une session unique :

Ça vaut le coup : migrer plusieurs modules indépendants vers une nouvelle API, écrire des tests pour des composants qui ne se recoupent pas, appliquer le même correctif à plusieurs services séparés, ou mener de front une tâche backend et une tâche frontend qui ne touchent pas les mêmes fichiers.
Ça ne vaut pas le coup : une fonctionnalité unique qui traverse plusieurs couches du même flux (par exemple un formulaire, sa validation et son endpoint associé), une base de code avec peu de fichiers et beaucoup de couplage, ou toute tâche où tu n'es pas capable toi-même de dire à l'avance quels fichiers vont être touchés.

Dans le doute, commence petit : deux threads sur un périmètre que tu maîtrises bien valent mieux qu'un découpage ambitieux en cinq lots dont tu ne sais pas s'ils se marchent dessus. Tu ajusteras la granularité une fois que tu auras une idée plus précise de la façon dont le coordinateur interprète tes objectifs.

Claude Code Projects : l'IA orchestre plusieurs sessions cloud