Ce qu'est Claude Code Projects : comment Claude répartit les threads, qui y a droit, l'exigence GitHub et le coût en tokens

Le 17 septembre 2026, Anthropic a annoncé avoir reconstruit Projects dans Claude Code. Le nom, lui, n'a rien de nouveau. C'est le mot que le chat claude.ai emploie depuis toujours pour désigner la boîte qui garde ensemble des conversations et des fichiers de référence. Les nouveaux Projects conservent ce nom et remplacent tout ce qui se trouve derrière. Le sous-titre du billet de blog officiel tient à lui seul lieu de réponse : « du dossier à la conversation ».

En une phrase, ce qui change, c'est que le travail de répartition passe de vous à Claude. Vous déposez une demande dans la conversation, Claude la découpe en « threads », les threads tournent en parallèle dans le cloud, et chacun ouvre une pull request et rend compte une fois qu'il a terminé. Fermer votre ordinateur portable ne les arrête pas.

Avant de vous lancer, trois points méritent toutefois d'être vérifiés : les comptes qui peuvent s'en servir restent limités, GitHub est en pratique indispensable, et la vitesse à laquelle la fonctionnalité dévore votre limite d'usage n'a rien à voir avec celle d'une session unique. Cet article remonte aux sources primaires — la documentation de Claude Code et le blog officiel — pour établir si vous pouvez l'utiliser et ce qui se passe une fois que c'est le cas.

1. Ce n'est plus un dossier, mais une seule conversation

Les nouveaux Projects reposent sur deux éléments : la conversation de projet, où Claude joue le coordinateur, et les threads que cette conversation lance.

La conversation est une session unique, de longue durée. Elle lit ce que vous lui envoyez, répond sur-le-champ quand une réponse suffit, et découpe en thread tout ce qui relève d'un vrai travail. Elle ne regarde pas ce qui se passe à l'intérieur de ces threads. Elle ne voit que ce qu'ils lui rapportent.

Les threads, eux, sont l'endroit où le travail a lieu. Chacun est une session cloud indépendante, avec sa propre fenêtre de contexte. Il travaille sur sa propre branche, ouvre une pull request lorsque c'est justifié, et rend compte à la conversation une fois terminé. La documentation décrit les états des threads comme s'alignant dans une liste appelée Overview, de la façon suivante.

Le point à retenir ici, c'est que le parallélisme n'est pas la nouveauté. Claude Code disposait déjà des sous-agents, de l'agent view, des équipes d'agents et des workflows dynamiques. Ce que Projects apporte, ce n'est pas le parallélisme mais deux autres choses : vous ne faites plus vous-même la répartition ni le suivi, et le travail ne s'évapore pas quand vous fermez votre machine. La documentation le dit elle-même, en précisant noir sur blanc que pouvoir lancer des tâches en parallèle n'est pas la raison d'être de Projects.

2. Même nom, mais ce ne sont pas les anciens Projects

Ce qui prête à confusion, c'est que le chat claude.ai a lui aussi ses « Projects ». Celui-là est un conteneur de conversations et de fichiers, sans threads ni coordinateur. Le nom identique invite à la méprise, mais la documentation traite les deux comme des fonctionnalités distinctes.

3. Qui y a droit — comment savoir si la fonctionnalité vous est parvenue

Au 19 septembre 2026, il s'agit d'une bêta publique déployée par étapes. Les conditions sont écrites avec un certain détail ; les voici, au plus près du texte.

La deuxième condition est la plus facile à manquer. Plus vous avez accumulé d'anciens projets du côté chat, plus les nouveaux Projects vous parviendront tard. Le blog officiel indique que les projets existants continuent de fonctionner pour l'instant et qu'ils seront migrés à mesure que le déploiement s'élargit. Autrement dit, ce ne sont pas les gros utilisateurs qui passent en premier : ce sont les comptes partis d'une page blanche.

Si la fonctionnalité n'est pas dans votre barre latérale, votre tour n'est pas venu. Dans ce cas, vous pouvez vous inscrire sur la liste d'attente. Regarder au bon endroit compte également plus qu'il n'y paraît : elle apparaît du côté Code, dans la barre latérale de claude.ai/code ou dans l'onglet Code de l'application de bureau. Vous aurez beau fouiller la barre latérale du chat, ce que vous y trouverez, ce sont les anciens Projects.

4. GitHub est indispensable, et c'est là que beaucoup décrochent

C'est la contrainte qui mord le plus fort en pratique. Le seul code qu'un thread peut toucher est du code hébergé sur github.com, et la Claude GitHub App doit être installée sur ce dépôt. La documentation énumère les conditions ainsi.

• Le code se trouve sur github.com. GitHub Enterprise Server, GitLab et Bitbucket sont exclus
• Le compte GitHub connecté dispose de l'accès en écriture (push) sur ce dépôt
• La Claude GitHub App est installée sur ce dépôt. Un jeton que vous avez ajouté avec /web-setup fonctionne pour les autres sessions cloud mais ne suffit pas pour les threads d'un projet
• Sur les dépôts d'une organisation, seul un propriétaire de l'organisation peut mener l'installation à son terme (tout autre membre déclenche une demande d'approbation)

Ce qui signifie qu'un développeur indépendant travaillant depuis un dépôt nu sur son propre serveur git ou sur un hébergement mutualisé reste hors périmètre en l'état. Il en va de même pour une API derrière un VPN d'entreprise, une base de données sur votre portable, un émulateur d'appareil ou un serveur de production auquel vous accédez en SSH : les threads vivent en dehors de votre machine, ils ne peuvent donc rien toucher de tout cela.

Cela ne laisse-t-il donc rien du tout à ceux qui n'utilisent pas GitHub ? Pas tout à fait. Un projet peut être créé sans aucun dépôt. Téléverser un dossier de contrats ou un export de tickets de support, confier à un thread une mission du type « liste les dix erreurs d'intégration qui reviennent le plus souvent là-dedans » et récupérer le résultat dans l'onglet Library est un usage que la documentation prévoit explicitement. Les fichiers que vous téléversez sont lisibles depuis un thread sous /mnt/project-files.

Si le travail porte sur du code et qu'il réclame votre propre environnement, la bonne option consiste plutôt à faire tourner des sessions locales côte à côte dans l'agent view. Cela s'exécute sur votre propre machine : votre VPN, votre base de données locale et votre SSH continuent donc de fonctionner.

5. Ce qu'un thread possède au démarrage

Un thread ne part pas de rien à chaque fois. Il démarre avec le contexte que le projet lui donne, et il emporte quatre choses.

• Les dépôts et les fichiers du projet — chaque dépôt enregistré est cloné à chaque fois, que la tâche y touche ou non
• Les instructions du projet — un cahier des charges commun qui parvient à chaque thread. Le plafond est de 16 000 caractères
• La mémoire du projet — des notes que Claude écrit pour lui-même. Il lit l'index MEMORY.md au démarrage et ouvre les fichiers individuels quand il en a besoin
• L'environnement cloud — les destinations réseau autorisées, les variables d'environnement, les identifiants d'API et les outils installés à l'avance

Dans ce bagage, la partie la plus susceptible de provoquer un accident est celle-ci : les fichiers de configuration d'un dépôt sont traités différemment selon que le projet contient un seul dépôt ou plusieurs. En remettant au propre le tableau de la documentation, on obtient ceci.

La raison est simple : les permissions, les hooks et les variables d'environnement sont lus uniquement depuis le .claude/settings.json du répertoire dans lequel le thread a démarré. Avec plus d'un dépôt, le thread démarre un niveau au-dessus des clones : les réglages d'aucun dépôt ne se trouvent donc à un endroit qui soit lu. Ajouter un seul dépôt supplémentaire désactive vos hooks en silence, et rien ne vous en avertit. Pour les projets à plusieurs dépôts, la recommandation documentée est de mettre les règles communes dans les instructions du projet et les variables d'environnement dans l'environnement cloud.

Au passage, à propos de MCP : les serveurs MCP qu'un thread peut utiliser sont les connecteurs de votre compte claude.ai. Un serveur MCP installé uniquement sur votre machine ne lui parvient jamais. Et la conversation de projet elle-même n'a aucun connecteur : un travail qui en réclame un doit donc être confié à un thread plutôt que demandé dans la conversation.

6. Combien cela coûte en plus, en tokens

C'est la question que la plupart des gens se posent avant d'activer la fonctionnalité. La documentation est sans détour : un projet puise dans vos limites plus vite qu'une session unique, et sur Pro en particulier, il faut s'attendre à atteindre sa limite plus tôt les jours où l'on en fait tourner un. L'augmentation vient de plusieurs facteurs qui s'empilent.

Le point ④ mérite une attention particulière. Quand le thread d'un projet ouvre une pull request, il surveille cette PR avec l'auto-fix activé par défaut. Même si vous avez désactivé l'auto-fix pour vos autres sessions cloud, les threads d'un projet sont gérés séparément. Il corrigera les CI en échec, répondra aux commentaires de relecture et rendra compte une fois que tout passe — et en échange, il continue de grignoter votre consommation aussi longtemps que vous le laissez là. Pour l'arrêter, demandez à ce thread de cesser de surveiller la PR.

Alors, combien cela coûte-t-il en plus ? Aucun multiplicateur n'a été publié pour Projects lui-même, mais pour les équipes d'agents, qui reposent sur la même idée — répartir une tâche entre plusieurs sessions —, la documentation avance le chiffre d'environ sept fois une session standard lorsque les coéquipiers tournent en mode plan. Paralléliser est une façon d'acheter de la vitesse, pas de faire des économies, et cela, les deux approches l'ont en commun.

Il vaut aussi la peine de savoir où sont les freins et ce qu'ils valent.

• Il n'existe aucun plafond sur le nombre de threads qui tournent en même temps. Vous pouvez dire « n'en garde que deux », mais la documentation est explicite : c'est une consigne que Claude essaie de suivre, pas un réglage imposé. La seule limite dure est de 200 threads par jour (tous projets confondus)
• Un thread qui atteint votre limite d'usage attend de lui-même et reprend automatiquement dès que la limite se réinitialise. Laissez-le tranquille et il commencera à dépenser la fenêtre suivante sans rien demander (pour l'arrêter, appuyez sur Stop sur le thread ou mettez le projet en pause). L'exception est un thread lancé par une routine, qui part en erreur au lieu d'attendre
• Les machines virtuelles du cloud elles-mêmes ne coûtent rien de plus. Seuls les tokens augmentent
• Un projet au repos — aucun thread en cours, aucune PR surveillée, aucun nouveau message — ne consomme rien du tout

7. Choisir entre les cinq façons de travailler en parallèle

Claude Code offre désormais cinq façons de faire avancer le travail en parallèle. Projects en fait partie, et ce qui le distingue des autres, c'est qui répartit le travail et où celui-ci s'exécute. En réorganisant le tableau comparatif de la documentation autour de la façon dont on choisit réellement, on obtient ceci.

Tracer la limite pour votre propre situation revient à peu près à deux questions. Le travail a-t-il besoin de votre propre environnement (base de données locale, VPN, SSH) ? Si oui, Projects n'est pas une option. Le travail sera-t-il terminé aujourd'hui ? Si oui, le passer dans le cloud vous apporte peu et l'agent view suffit. Pour la différence entre sous-agents et équipes d'agents, un article dédié compare les deux en détail.

8. Ce qu'il faut faire avant d'envoyer le premier lot

La documentation énumère quatre choses à faire « avant votre premier lot », et chacune d'elles est coûteuse à corriger plus tard.

1. Écrire les instructions du projet — depuis quelle branche partir, quoi exécuter avant de déclarer quelque chose terminé, ce qui exige d'abord votre validation. L'exemple officiel demande à un thread de nommer précisément ce qu'il ne parvient pas à atteindre dès son premier message et de s'arrêter là, plutôt que de substituer, de simuler ou de deviner.
2. Envoyer exactement une vraie tâche, puis l'ouvrir et la lire — vérifiez comment le thread rend compte et ce qu'il a réellement laissé sur la branche
3. Revenir sur le modèle et le niveau d'effort — laisser le défaut Opus en high est le moyen le plus rapide d'épuiser votre limite
4. Dire « propose avant de commencer » et « n'en garde que quelques-uns à la fois » — abandonnez ces consignes une fois que quelques tours reviennent conformes à ce que vous attendez

Un dernier point, moins reluisant mais bon à connaître. Le sandbox d'un thread se met en pause entre deux tours et reprend au suivant. S'il ne parvient pas à reprendre, le travail redémarre depuis un clone neuf, ce qui veut dire que les modifications non commitées peuvent être perdues. Sur les tâches longues, la recommandation documentée est de dire au thread de committer et de pousser au fil de l'eau.

Résumé

Les nouveaux Projects ne sont pas « une fonctionnalité qui permet de travailler en parallèle » mais « une fonctionnalité qui vous retire la corvée de travailler en parallèle ». La répartition, les relances et la réexplication du même contexte à chaque fois disparaissent toutes. Si vous avez un travail qui dure, qu'il vit sur github.com et que vous êtes sur Pro ou Max, les chances que cela vous convienne sont élevées.

En revanche, cela convient mal à un travail qui réclame votre propre environnement, à votre propre serveur git et aux tâches ponctuelles qui se terminent aujourd'hui. Et ce qui vaut dans tous les cas, c'est que le parallélisme achète de la vitesse en dépensant des tokens. Le réglage par défaut est Opus en high, aucun plafond n'est imposé sur le nombre de threads simultanés, et les threads qui surveillent une PR se réveillent d'eux-mêmes. Faites tourner un projet pendant une journée sans connaître ces trois points et la chute de votre quota vous surprendra. Baissez d'abord les réglages, gardez un nombre de threads réduit, et prenez-en la mesure sur un seul aller-retour avant d'élargir. C'est la façon la plus sûre d'y entrer.

Pour transformer les résultats de vos recherches dans un projet en une proposition ou une procédure à consulter plus tard, voyez aussi le guide de Claude Docs. Choisissez selon votre objectif : un projet pour faire avancer un travail dans la durée, ou Docs pour créer et modifier un document.

FAQ

Q. Qu'advient-il des projets que j'ai déjà dans le chat ?

R. Ils continuent de fonctionner tels quels pour l'instant. Le blog officiel indique que les projets Pro et Max existants restent utilisables et qu'ils seront migrés à mesure que le déploiement s'élargira au chat et à Cowork. Notez toutefois que les nouveaux Projects sont d'abord servis aux comptes sans projets existants : plus vous en avez accumulé, plus votre tour viendra tard.

Q. Puis-je m'en servir depuis Claude Code dans le terminal ?

R. Non. Les trois endroits où cela fonctionne sont claude.ai/code, l'onglet Code de l'application de bureau et l'application mobile. L'accès via Amazon Bedrock, Google Cloud Agent Platform ou Microsoft Foundry est également hors périmètre. La commande claude project du CLI, soit dit en passant, est une autre fonctionnalité qui se trouve porter le même nom.

Q. Je n'utilise pas GitHub. Quelles sont mes options ?

R. Pour exécuter réellement du code, il y en a deux, pour l'instant. Mettre le dépôt sur github.com et installer la Claude GitHub App, ou utiliser l'agent view, qui tourne sur votre propre machine. Cela dit, un projet sans dépôt peut être créé sans GitHub du tout : téléversez votre matière, faites-la explorer ou rédiger par des threads, et récupérez les résultats dans l'onglet Library.

Q. Est-ce réaliste avec la formule Pro ?

R. Oui, mais baissez les réglages avant de commencer. La documentation elle-même prévient que sur Pro en particulier, il faut s'attendre à atteindre sa limite plus tôt les jours où l'on fait tourner un projet. Un nouveau projet place par défaut les threads sur Opus en high : abaissez cela d'abord, gardez un petit nombre de threads simultanés, et élargissez en surveillant ce que vous dépensez réellement dans les réglages Usage du projet.