Comment utiliser Claude Code Projects : guide pratique de la bêta

Pour comprendre comment utiliser Claude Code Projects, imaginez une conversation qui sert de fil conducteur à tout un flux de développement. Le coordinateur peut lancer et suivre plusieurs threads cloud, chacun consacré à une tâche distincte. L'intérêt n'est pas d'ouvrir davantage de fenêtres de chat, mais de perdre moins de temps à répéter le contexte du dépôt, à distribuer les sessions et à retrouver la branche ou la pull request qui attend votre intervention.

Cette nouvelle expérience est déployée progressivement depuis le 17 septembre 2026, et son accès reste limité. Ce guide explique comment vérifier votre éligibilité, préparer un dépôt jetable, confier deux tâches indépendantes, contrôler le travail produit et savoir précisément quel contexte accompagne chaque thread.

Claude Code Projects coordonne le travail, ce n'est pas un dossier

Un projet Claude Code réunit une conversation persistante avec Claude et les sessions cloud qu'elle lance sous forme de threads. Voyez cette conversation comme un chef d'atelier : vous lui remettez un brief, puis différents postes prennent chacun une mission. Chaque poste possède son propre espace de travail, sa propre fenêtre de contexte et sa propre branche Git. Le coordinateur, lui, reçoit les comptes rendus et organise la file d'attente.

Le fonctionnement diffère de l'ancienne expérience Projects dans le chat Claude et Cowork. Celle-ci sert à regrouper des conversations et des fichiers de référence. La nouvelle bêta de Claude Code Projects ajoute un coordinateur capable d'orienter le travail vers des threads cloud, de suivre leur progression et de transmettre le contexte du projet aux nouveaux threads.

Chaque thread reçoit au démarrage les dépôts et fichiers du projet, ses instructions et sa mémoire, l'environnement cloud sélectionné, les connecteurs du compte, ainsi que les fichiers CLAUDE.md, les skills et les plugins présents dans les dépôts. En revanche, il n'hérite pas des outils installés uniquement sur votre ordinateur.

Le calcul financier est avantageux si vous payez déjà un abonnement Claude compatible. Claude Pro coûte $20 par mois, ou $17 par mois avec un paiement annuel de $200, tandis que Max commence à $100 par mois. Projects ne facture pas séparément les machines virtuelles cloud. La contrepartie se trouve dans l'usage : chaque thread est une session Claude Code complète, donc le travail en parallèle consomme plus vite les limites de l'abonnement.

À titre de comparaison, les abonnements individuels aux agents de code examinés pour ce guide vont de $10 à $200 par mois chez GitHub Copilot et Cursor. Si Claude est déjà votre agent de code, Projects n'ajoute pas un nouveau poste utilisateur à cette pile. Il change le coût de la coordination, pas celui du jugement technique.

Vérifiez d'abord si votre compte a accès à la bêta

Voir une fonctionnalité appelée Projects quelque part dans Claude ne suffit pas à confirmer l'accès.

1. Connectez-vous avec un compte Claude Pro ou Max.
2. Ouvrez claude.ai/code ou l'onglet Code de l'application de bureau.
3. Cherchez Projects dans la barre latérale gauche.
4. S'il n'apparaît pas, le déploiement n'a pas encore atteint votre compte. Inscrivez-vous sur la liste d'attente d'Anthropic et utilisez les sessions cloud classiques entre-temps.

La première vague privilégie les comptes Pro et Max qui ont déjà utilisé des sessions cloud et ne disposent pas des anciens Projects dans le chat Claude ou Cowork. Les comptes Team et Enterprise n'ont pas encore accès à cette nouvelle bêta. Les anciens Projects existants continuent de fonctionner pendant qu'Anthropic fait évoluer l'expérience.

Si Claude Code n'est pas encore installé, authentifié et cadré par un fichier CLAUDE.md au niveau du dépôt, commencez par le guide général de configuration de Claude Code. Projects s'appuie sur ces pratiques liées au dépôt, sans les remplacer.

Comment utiliser Claude Code Projects pour un premier test

Choisissez un petit dépôt GitHub que vous pourrez supprimer sans conséquence. Ce premier essai sert à observer le routage, le contexte, les branches et l'usage, pas à confier une migration de production à un coordinateur encore en bêta.

1. Réglez l'accès à GitHub avant de créer le projet

Pour travailler sur du code, le dépôt doit être hébergé sur github.com. Le compte GitHub connecté doit disposer des droits de push, et la Claude GitHub App doit être installée sur ce dépôt. Un token créé avec /web-setup peut suffire à une session cloud classique pour cloner un dépôt, mais pas à un thread de projet.

Les dépôts GitHub Enterprise Server, GitLab et Bitbucket ne sont pas pris en charge comme dépôts de code dans cette bêta. Si le dépôt appartient à une organisation, un propriétaire de l'organisation devra peut-être approuver l'installation de la Claude GitHub App et l'autorisation SSO.

2. Créez un projet au périmètre étroit

Ouvrez Projects, sélectionnez New project, puis renseignez :

• Name: un nom manifestement temporaire, par exemple Parser Project Test.
• Goal: une seule phrase, par exemple Improve parser coverage and documentation without changing behavior.
• Context: ajoutez uniquement le dépôt jetable.

Seul le nom est obligatoire. Un objectif précis donne au coordinateur une limite exploitable, tandis qu'un seul dépôt évite les différences de réglages propres aux projets qui en regroupent plusieurs.

3. Ajoutez une instruction permanente

Ouvrez Project settings > Memory > Project instructions. Donnez à tous les threads la même définition du travail terminé et les mêmes limites d'approbation. Par exemple :

Partez de la branche par défaut. Utilisez une branche par thread. Exécutez les tests pertinents avant d'annoncer que le travail est terminé. Ne fusionnez rien, ne modifiez pas la CI et n'ajoutez aucune dépendance sans demander l'autorisation dans le thread. S'il manque un accès, indiquez précisément lequel et arrêtez-vous.

Les instructions de projet peuvent contenir jusqu'à 16,000 caractères, mais ce premier essai doit rester bref. Les commandes de build propres au dépôt ont toujours leur place dans son fichier CLAUDE.md. Les exigences, décisions et pièges découverts au fil du projet doivent rejoindre la mémoire du projet.

4. Contrôlez l'environnement cloud

Ouvrez Project settings > Environment. Tous les nouveaux threads utilisent l'environnement choisi ici. Ce réglage détermine l'accès au réseau, les variables d'environnement, les identifiants d'API et les outils installés par un script de configuration.

L'environnement hébergé par Anthropic utilisé par défaut peut joindre une liste autorisée de services courants et comprend des outils préinstallés. Il n'accède pas automatiquement à votre base de données locale, votre VPN, votre émulateur, votre configuration shell ni aux identifiants présents uniquement sur votre ordinateur. Configurez l'environnement avant d'attribuer une tâche qui dépend de l'un de ces éléments.

5. Envoyez deux tâches qui ne peuvent pas se chevaucher

Placez les deux tâches dans un même message pour observer la façon dont le coordinateur sépare des missions sans lien entre elles. Faites-les porter sur des fichiers différents. Par exemple :

Commencez maintenant sans demander de confirmation. Créez un thread chargé d'ajouter des tests unitaires pour les entrées de parseur mal formées. Créez un second thread pour corriger les exemples obsolètes du guide de l'API. Ne modifiez pas le comportement du parseur en production et ne fusionnez aucune des deux branches.

Selon Anthropic, plusieurs tâches indépendantes placées dans un même message sont converties en threads distincts. Chaque thread de code crée une branche à partir de la branche par défaut du dépôt, sauf instruction contraire. Il reste important de séparer les fichiers : deux branches peuvent toujours entrer en conflit si leurs threads modifient le même code.

6. Examinez les threads, pas seulement le résumé du coordinateur

Ouvrez la fiche de chaque thread et relevez les éléments suivants :

Overview répartit le travail entre Ready for review, Waiting on you, Working, Landing, Idle et Resolved. Ses autres onglets regroupent les fichiers du projet, les pull requests et les routines. Le coordinateur reçoit les rapports des threads, mais ne voit pas chacune de leurs étapes : pour auditer le travail, la transcription du thread reste donc la référence.

7. Vérifiez que le travail suivant retrouve le contexte mémorisé

Une fois les deux threads terminés, demandez au coordinateur de mémoriser une règle sans risque, par exemple Documentation changes must preserve every runnable example. Lancez ensuite un nouveau petit thread de documentation et demandez-lui de rappeler la règle de branche et la règle de documentation du projet avant toute modification.

Ce test couvre deux chemins de contexte. Les instructions du projet doivent parvenir à chaque nouveau thread comme un brief fixe. La mémoire du projet doit transmettre la décision enregistrée via MEMORY.md. Le fichier CLAUDE.md du dépôt constitue une troisième couche distincte, réservée aux règles propres au code source.

Ce qui accompagne un thread — et ce qui reste en local

L'erreur la plus rapide consiste à prendre un thread cloud pour une copie distante de votre ordinateur. Ce n'est pas le cas : il s'agit d'une nouvelle session cloud, assemblée à partir du contexte du projet, du dépôt, du compte et de l'environnement.

Les projets qui regroupent plusieurs dépôts présentent un piège particulier. Tous les fichiers CLAUDE.md, skills et plugins des dépôts sont chargés, mais pas les règles d'autorisation, les hooks ni les réglages env propres à chaque dépôt. Placez les règles transversales dans les instructions du projet, et les variables d'environnement dans l'environnement cloud.

Les threads parallèles ne sont pas illimités

Anthropic ne documente aucun nombre fixe de threads pouvant s'exécuter en même temps. Vous pouvez demander au coordinateur de se limiter à deux, mais cette consigne exprime une préférence, pas un quota contraignant. La limite stricte, distincte, est de 200 nouveaux threads par jour sur l'ensemble de vos projets.

Les threads actifs consomment l'abonnement. Le coordinateur en fait autant lorsqu'il lit les rapports et décide de la suite. Un thread qui surveille une pull request se réveille et consomme de nouveau des ressources si la CI échoue ou si un commentaire de review apparaît. À l'inverse, un projet inactif, sans thread en cours, pull request surveillée ni nouveau message, ne consomme rien.

Les nouveaux projets choisissent par défaut Opus avec un niveau d'effort élevé pour les threads, et faible pour le coordinateur. Avant de lancer un lot important, ouvrez Project settings > General et sélectionnez, pour chaque tâche, le modèle le moins coûteux et le niveau d'effort minimal capable de la mener à bien. Demandez ensuite un petit nombre de threads simultanés. La bonne question n'est pas de savoir combien de threads Projects peut ouvrir, mais combien de résultats vous pourrez examiner avant que la file ne se transforme en bruit.

Les sept cas d'usage les plus pertinents

1. Un responsable plateforme pilote une migration sur plusieurs dépôts

Connectez les dépôts serveur, web et mobile, puis donnez au projet un seul objectif : retirer un endpoint obsolète. Des threads distincts peuvent mettre à jour chaque appelant sur des branches séparées, tandis que le coordinateur suit l'ordre des opérations et les blocages. Au lieu de synchroniser manuellement trois sessions d'agents, vous obtenez une seule file de review. C'est le meilleur cas d'usage, car l'objectif dépasse une session et le travail se répartit proprement par dépôt.

2. Un mainteneur traite la file de bugs d'un service

Un mainteneur peut ajouter au projet les nouveaux rapports de bugs et les traces de pile à mesure qu'ils arrivent. Le coordinateur peut envoyer une régression vers le thread qui enquête déjà sur la zone concernée, ou en créer un autre en lui transmettant les pièges mémorisés par le projet. Le bénéfice : moins de briefs répétés et un historique durable pour savoir quel bug attend un accès, une review ou une décision.

3. Un responsable de release lance des contrôles indépendants

Confiez à des threads séparés la suite de tests, les liens de documentation, l'audit des dépendances et le brouillon des notes de version. Gardez chaque mission en lecture seule jusqu'à l'examen des conclusions. Le coordinateur peut faire ressortir ce qui a réussi et ce qui exige une réponse sans noyer les preuves dans une immense transcription. La checklist aboutit plus vite à une décision, tout en laissant le dernier mot au responsable de release.

4. Un responsable de refactorisation découpe une évolution par périmètre

Pour une migration trop vaste pour une seule fenêtre de contexte, attribuez des modules ou packages indépendants à plusieurs threads et inscrivez l'invariant dans les instructions du projet. Chaque thread valide sa propre branche et rend compte au coordinateur. Le travail avance en parallèle avec une définition commune du résultat attendu. Attention toutefois aux recouvrements architecturaux : deux branches qui modifient la même abstraction partagée peuvent toujours provoquer des conflits de fusion ordinaires.

5. Un ingénieur en agence maintient l'application d'un client

Créez un projet privé par client, avec son dépôt, ses instructions et son environnement. Tout au long de la mission, alimentez-le en petits correctifs, demandes de review et travaux de documentation. Vous gagnez en continuité sans mélanger les contextes clients. Pendant la bêta, chaque projet appartient à un seul utilisateur et ne peut pas être partagé : c'est un cockpit personnel de livraison, pas un portail de collaboration avec le client.

6. Un responsable support analyse des échecs d'intégration récurrents

Projects n'exige pas de dépôt. Importez un export de tickets support et la documentation d'intégration, puis chargez plusieurs threads de classer les échecs, de vérifier les exemples et de rédiger un plan de remédiation. Leurs fichiers de sortie sont déposés dans Library. Vous obtenez ainsi un corpus de contexte réutilisable et des pistes de preuve distinctes pour l'analyse comme pour la rédaction.

7. Un fondateur solo résorbe une liste de tâches hétérogène

Envoyez un petit lot comprenant une tâche de test, une tâche de documentation et un audit du dépôt. Demandez au coordinateur de ne lancer que deux threads et de proposer toute action destructive avant de l'exécuter. Le gain est surtout attentionnel : le fondateur examine des branches terminées au lieu de surveiller chaque session. Le dispositif convient mal si toutes les tâches touchent le même fichier ou dépendent d'un service accessible uniquement depuis son ordinateur.

Trois produits complémentaires qui méritent d'être développés

La bêta ne propose aucune API Projects documentée. À court terme, les produits les plus sensés doivent donc s'installer à côté du workflow : ils préparent le contexte, observent l'état de GitHub ou aident un humain à contrôler les résultats.

1. Project Readiness Auditor, l'opportunité la plus solide

Créez une application GitHub en lecture seule qui vérifie si un dépôt est prêt à accueillir des agents de code cloud. Elle examinerait les instructions du dépôt, les commandes de test, les protections de branches, la couverture de l'application GitHub, les secrets nécessaires et les dépendances réseau. Elle produirait ensuite un brouillon d'instructions de projet et une checklist pour l'environnement cloud.

La demande liée à ce besoin est déjà visible : « ai powered coding agent » reçoit 8,100 recherches mensuelles aux États-Unis, avec une intention commerciale. Les abonnements individuels officiels aux agents de code examinés pour ce guide vont de $10 à $200 par mois. Pourtant, payer une licence ne suffit pas à rendre un dépôt sûr pour le travail cloud en parallèle.

La plus petite version commercialisable analyse un dépôt GitHub, pose six questions sur l'environnement et exporte un brief prêt à coller. Le risque vient de la plateforme : Anthropic ou GitHub pourraient rapidement intégrer ces contrôles de configuration. Le produit doit donc prendre en charge plusieurs agents et conserver un historique d'audit utile, au lieu de se limiter à un modèle dédié à Claude.

2. Un tableau de suivi du cycle de livraison IA

Créez un tableau connecté à GitHub qui regroupe les branches, les pull requests, l'état de la CI, les commentaires de review et les validations humaines par objectif de livraison. Il s'adresse au responsable technique qui utilise plusieurs agents de code et cherche une surface de contrôle neutre.

« AI software development life cycle » reçoit 720 recherches mensuelles aux États-Unis, affiche une difficulté de mot-clé de 4 et un CPC de $18.13. La version minimale lit les événements GitHub et les classe en quatre états : en cours, bloqué, prêt et livré. Elle n'a jamais besoin d'accéder aux transcriptions privées d'un projet Claude.

La difficulté tient à la différenciation. GitHub et les fournisseurs d'agents affichent déjà une grande partie de ces états. Le produit ne gagne que s'il relie le travail entre plusieurs fournisseurs, conserve les preuves d'approbation et explique la cause d'un blocage au lieu de simplement dessiner une file plus élégante.

3. Un routeur automatisé de politiques de review

Créez une application GitHub qui applique la politique de review propre à chaque dépôt aux pull requests produites par des agents. Elle pourrait exiger un artefact de test pour toute modification du parseur, envoyer les changements de facturation à un reviewer désigné et empêcher les commentaires d'auto-correction de déclencher une automatisation privilégiée.

« Automated code review » reçoit 210 recherches mensuelles aux États-Unis et affiche un CPC de $63.33, signe d'une intention à forte valeur au sein d'une audience plus restreinte. Le MVP a besoin d'un fichier de règles, d'un contrôle de pull request et d'une explication concise des preuves manquantes.

Le risque est le chevauchement fonctionnel. Les threads Claude surveillent déjà les pull requests et réagissent aux échecs de CI comme aux commentaires de review. Un nouveau produit doit gouverner les risques entre plusieurs agents et dépôts, pas imiter un énième bot de review.

Ce que Claude Code Projects ne résout pas

Projects fonctionne particulièrement bien lorsque le travail se découpe et que le contexte nécessaire peut résider dans GitHub, des fichiers importés, des connecteurs ou un environnement cloud. Il convient mal à un correctif ponctuel qui tient dans une seule session, à une tâche liée à un appareil local ou à un VPN, ainsi qu'à une équipe dont plusieurs membres doivent piloter le même projet.

Il ne supprime pas non plus les risques habituels de livraison :

• Des threads distincts peuvent provoquer des conflits de fusion si leurs branches se chevauchent.
• Une demande de parallélisme est une instruction donnée au coordinateur, pas un contrôle budgétaire strict.
• Les threads parallèles peuvent épuiser rapidement les limites de Pro.
• Un bac à sable suspendu peut repartir d'un nouveau clone, avec le risque de perdre les modifications non validées par un commit.
• La bêta reste personnelle, sans partage de projet ni contrôles au niveau de l'organisation.
• Un thread ne peut pas être déplacé vers un autre projet par la suite.

Le constat est simple : utilisez Projects pour coordonner des tâches séparables, pas pour déléguer l'architecture ou l'approbation. Commencez par deux tâches, examinez les deux transcriptions, puis n'augmentez le parallélisme qu'une fois les branches et la consommation devenues prévisibles.

Questions fréquentes

Claude Code peut-il accéder aux projets ?

Certains comptes Claude Pro et Max peuvent utiliser la nouvelle bêta Projects depuis claude.ai/code, l'onglet Code de l'application de bureau et les applications mobiles de Claude. Si Projects n'apparaît pas dans la barre latérale de Code, le déploiement n'a pas encore atteint le compte. La commande de terminal claude project gère un état de répertoire local sans rapport avec cette fonctionnalité.

Comment utiliser les projets dans Claude Code ?

Créez un projet dans Claude Code, ajoutez un objectif et le minimum de dépôts ou de fichiers nécessaires, écrivez une courte instruction permanente, sélectionnez l'environnement cloud, puis envoyez une ou plusieurs tâches à la conversation du coordinateur. Dans Overview, examinez chaque thread et contrôlez sa branche, sa transcription, ses validations et sa consommation avant toute fusion.

Claude Code peut-il travailler sur un projet existant ?

Oui. Vous pouvez créer un projet à partir d'un dépôt github.com existant, ou choisir Continue as a project depuis une session cloud en cours. Pour un dépôt de code, le compte GitHub connecté doit disposer d'un accès en écriture et la Claude GitHub App doit y être installée.

Quelles différences entre les projets Claude et Claude Code ?

Claude Code est l'agent de programmation exécuté dans une session locale ou cloud. La nouvelle version des projets Claude Code ajoute la couche de coordination : une conversation lance et suit plusieurs sessions cloud Claude Code, leur fournit le même contexte de projet et rassemble leurs statuts. Tant que la migration ne les a pas atteints, les anciens Projects du chat Claude et de Cowork conservent leur modèle d'espace de travail fondé sur les fichiers et les conversations.

Pour mettre en place autour de vos dépôts, de vos validations et de votre environnement cloud un workflow d'agents réellement prêt pour un projet, découvrez les systèmes d'IA en production.